I attended the MySQL Conference all last week, and am feeling very excited about the future of open source databases. I had many interesting discussions and met a ton of Drizzle hackers I was lucky enough to spend Friday with, digging through code.
I was talking with Paul Vallée of the Pythian Group Thursday about Postgres and the future of enterprise support. And he showed me this great graph from indeed.com. It’s acceleration here, not the raw numbers – but still, a neat graph 🙂
We discussed the issues that enterprise customers with certain types of regulatory obligations encounter — such as contractual obligations for PCI-compliant credit card storage or outsourced management of sensitive data. The standard response developers might give for this is “read the spec, and make sure you implement it properly”. But the truth is, for larger companies, that may not be enough.
So, assuming for a moment that the Postgres community would even want to address this problem as a group — could it be possible for the Postgres community to provide the legal and financial assurances that an incredibly huge corporation (ahem – Sun/Oracle) can?
The short answer for Postgres right now is “no”.
Originally, I had thought just in term of liability, but Paul clarified:
The liability is just one component of what gives the guarantee meaning because there is a consequence to failed delivery. An SLA can also do this. As can a simple lucrative contract that can be lost, or canceled early if delivery does no take place. The key here is to ensure that the technology adopter can legitimately be confident that they are provably being responsible by adopting the platform. “I trusted” doesn’t cut it for many.
My view was that this type of agreement helps to determine who exactly is to blame (and who can be sued) in the event of a software failure. But, Paul said, “It’s more about assurance (with evidence) that obligations realistically will be met.”
I sometimes think that this system of liability and assurances is just ultimately broken. But it is a reality. So, would it be possible for us to come up with a new legal framework for community-driven software?
Paul brought up the idea of a cooperative, and that maybe such a legal entity could provide protection for individuals involved in supporting Postgres, and also shoulder some or all of the liability that a corporation using Postgres would want. I’m not sure that core developers of Postgres would join such a thing, or whether they would be allowed to given existing agreements they have with their own companies. But it is an interesting idea.
Creating a blueprint for this type of organization – hackers cooperatives – could be a way for truly community software to be developed across companies and among individuals in a sustainable, and “trustable” way. Maybe?
Continuing this train of thought – maybe these are non-governmental organizations, whose main purpose is to create and maintain infrastructure software for the good of the world.
Funding for mid-sized free and open source projects seems to be a consistent problem. Perhaps NGOs are a fair model for us.
I am curious about what effort may have already been made in this direction. My next step will be to contact Bradley Kuhn and see if there’s something out there that might address this.
At “larger organizations,” the barriers are structural, but not legal. FUD is very, very real, and diffusion of responsibility is the root cause. If a middle manager has a choice between preventing something from failing 99.99% of the time by care and preventing it 80% of the time and blaming any failure on an entity so powerful it can’t be sued like Oracle or Microsoft, he (it’s almost always a he) is going to do the latter.
In this case, no amount of playing along will actually help. Fortunately, people are starting to get more interested in succeeding than in passing the blame for failure 🙂
There are many serious legal considerations with both small and large companies. You can’t make all arguments go away by screaming FUD. PCI-DSS requirements are very real, and very clear. PostgreSQL out of the box fails to meet some of them with “helpers.” We’ve run into this issue a few times and one needs to be very careful and diligent in meeting legal requirements for PCI-DSS (and HIPPA and SOX) though HIPPA tends to be easier on the systems side.
Someone has to take responsibility. If it isn’t your database provider, then it is your database administrator. Out-sourcing can make a lot of sense here as you can shift the cost of that liability (insurance bills).
All I know is that I cry every February when the variety of _extremely_ expensive insurance bills comes due for our organization. However, this is the price we have to pay to make our clients comfortable and keep them safe running PostgreSQL, MySQL or Oracle. After all, there is a lot of money and integrity on the line here.
@David — thanks for the comments. I have to agree with Theo and Paul that the issue is just not one of blame-shifting. There has to be accountability, and when we reach beyond the confines of our fairly tight-knit Postgres community, there is a much larger world out there that does not know or trust us. I think it is right and good to continue expanding the boundaries of our community and the trust in it to include more people, but ultimately, I don’t think that will scale as well or as quickly as a legal framework would.
I’m also not saying that I think our current method of being accountable (deep pockets) is good – I’m asking if there might be a better way.
How should I interpretate this other graph?
http://www.indeed.com/jobtrends?q=postgres%2C+mysql%2C+oracle
@Denis: that oracle and mysql still dominate the industry 🙂 Which we all know. I think the acceleration graph is important for looking at where Postgres is headed — we are growing fast.
@Theo, I’m not “screaming FUD.” I’m describing a very real and common situation in corporate America. HIPAA, which is what I assume you meant when you wrote HIPPA, has quite stringent requirements attached to prison terms…most of which are open to interpretation, and bring on the HIPAA consultants. SOX is even worse because it should have been written by the forensic accountants it’s made to help, but was not. It’s so fuzzy that its only apparent purpose to date has been to enrich SOX consultants.
I agree that someone has to take responsibility, and that it can’t really be the RDBMS provider, as RDBMSs by their nature are far too flexible to be able to guarantee such stuff “out of the box.” I strongly suspect that an “out of the box” system that both functions and meets (PCI-DSS|HIPAA|SOX) requirements is just plain impossible on Halting Problem grounds.
Those insurance bills you pay are appropriate because they’re protecting you, the people who actually put together the system, from the consequences–quite severe–of failure.
Oracle’s disclaimer and muscly legal teams, on the other hand, are totally inappropriate. You would be insane to get within 50 yards of a car that came with a disclaimer like the EULAs proprietary software comes with, let alone actually get in it.
The situation is not one that proprietary software has actually solved. It’s
one where they’ve managed to externalize a gigantic cost, but that’s all.
@DENIS, you have to combine these ;^)
http://www.indeed.com/jobtrends?q=postgres%2C+postgresql%2C+postgre%2C+pgsql&l=
Selena,
If I can add to what David notes about FUD… I think we need to define a ‘target’ – the kind of company, or even the particular company – that would benefit from PostgreSQL. From there it’s possible to determine the best method of approach.
If you are targeting Fortune 500, I think it’s highly improbable that any entity other than a company providing commercial support and SLA’s could get a slice of the mission-critical pie. It’s simply the perception. While larger companies (IBM, Microsoft, Oracle) offer hit-and-miss support – often more miss than hit – they can command high support contract fees (and disclaim all liability) just because they are IBM, Microsoft, and Oracle.
A cooperative as in legal structure (where all workers own a slice of a corporation) may work… but then what’s the difference between that and a standard employee owned corporation? In either case, from the ‘outside’ it still has to appear as a normal company for the perception to fit.
I am having trouble seeing the need for a cooperative or NGO type structure. If I provide support on a mailing list as an individual, my support comes with an implicit lack of liability. (On second thought, maybe I had better follow up all my list postings with liability waivers!) If I want to provide support where I am bonded against IP, SLA, and Legal requirements, then I go work for a corporation or LLC, or form one myself. What benefits would an alternate structure provide, that are not provided by these types of structures?
Cheers,
-JK
@Joshua: I have been thinking about your question today, and still don’t have a good answer.
I was trying to think up a way for contributors spread around the world to be part of a loosely affiliated organization, and still keep their day jobs (if they have them).
The whole notion of corporate accountability is difficult to reconcile with the way that the Postgres project itself is developed. Of course, there are plenty of very good companies that provide support. And I trust the Postgres community – the question of how we scale that trust out to the larger world is what I am interested in.
Typically, this is done by having a huge corporation. Maybe there is another way?
The cooperative seems like a good deal – but I have the same question as you: what is in it for the contributors that is a benefit above and beyond what they get from their current, no-liability contribution status? Why join an organization that suddenly saddles you with responsibility that you didn’t otherwise want?
You’d probably have to have an economic incentive, or a very strong reputation incentive.
In the end, I don’t have a good answer yet, and your question is really important.
@Selena – I think this calls for a tactical solution, not a strategic one. In solving the basic problem, as I read it – the desire to allow folks to be a part of a loosely affiliated organization (as you noted) – we can adopt a strategic position to create a new type of legal structure. Or, we can figure out how to (tactically) reach the end goal with existing structures, namely a standard corporation or LLC.
Am I correct in assuming that the primary goal is to allow folks to contribute code or provide support { with compensation | with protection } and still keep their day jobs? The easiest way to do this is to have everyone sign on as a contractor. This is how many of us do small projects today. There are still questions to be answered, of course, but I would surmise it’s less work than trying to come up with a new structure.
Cheers,
-Josh
@Joshua:
That’s a great suggestion!
I still think some strategery will ultimately be involved. But, to run with what you’ve put together, here are my thoughts:
* When bringing non-US citizens in, there are lots of bizarre issues. If you have an LLC, managing all those details is a problem that would need to be solved.
* Joining an LLC as a contractor can be seen as working for a competitor for a lot of companies and consultancies. I wish that there was another “type of thing” that was not seen as competitive, but additive to an employee’s participation in their company. I’m not sure if I am explaining what I mean properly, but this problem of competition would need to be addressed.
Hi Selena, great article. My blog has an answer for the “mid-sized free and open source projects” problem you mentioned. I read this article after working out the model and even adopting the same name of Hackers Co-op. Have a look. It’s kind of long for a blog post but I was trying to work out the economics as fully as possible. (http://scale-out-blog.blogspot.com/2009/08/building-open-source-hackers.html)
Pingback: Building the Open Source Hackers Cooperative « JZ Talk Blogger