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.
Related posts:
![[FSF Associate Member]](http://www.chesnok.com/daily/wp-content/uploads/2010/02/button.png){kind=small}
26 Comments
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)
Selena Deckelmann: The future of free and open source support models http://tr.im/jGKv
This comment was originally posted on Twitter
@selenamarie Deckelman blogs about a conversation we had about assurance challenges facing Postgres adoption: http://tinyurl.com/dc27mj
This comment was originally posted on Twitter
RT @paulvallee: @selenamarie blogs about a conversation we had re assurance challenges facing Postgres adoption: http://tinyurl.com/dc27mj
This comment was originally posted on Twitter
Depending on what timeframe that Dean was referring to when he said *create*, the two of may completely agree that a commercial entity certainly helped MySQL success (at least in the beginning).
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
“The first is difficulty in accepting contributions back from the community.”
You acknowledged that this was not the result of a business decision, so how does having a central company behind the product create this problem?
Furthermore, how many community contributions do you believe have actually been held up (regardless of reason)?
There is no great horde of experienced database developers anxiously waiting to push their high quality patches into MySQL.
We’ve definitely had problems in this area, and we’re definitely correcting problems in this area, but let’s maintain perspective.
“The second problem is that in trying to monetize MySQL, certain things were irrevocably changed.”
Such as?
“In fact, the real value of the company seems to be documentation and QA.”
I doubt that “The Ecosystem” is at all equipped to “take over” the enormous scope and scale of work performed by the commercial companies at the heart of this product (Sun/MySQL and Oracle/Innobase), which I think you have grossly undervalued.
I could be wrong. I’m certainly not hoping to be proven correct…
“All I am saying is that it is not NECESSARY to have a company behind MySQL.”
As I’ve claimed elsewhere: opportunities would remain without “the company”, but of a different (reduced) number and nature.
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
“Legacy code and hacks were *enabled* by having a centralized place for development.”
Unfortunately, this is not logically sound. Although the characteristics of a distributed development environment might affect the quality of a project, overall the defining factor is how well the software is designed. And a good design is difficult to produce in a centralized or distributed place, it doesn’t really matter much.
For example, take a look at a sufficiently large project as the Linux Kernel. You will surely find good stuff and bad stuff.
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
Steve — absolutely! Mostly, I wanted to point out that arguments on both sides can be made to say “the company made MySQL a success, and may be contributing to things falling apart”, but either way the software will live on.
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
Actually, Dean, your argument contradicts itself. You doubt that the ecosystem can take over all the work that the company has done, yet you say there is more opportunity because the company exists.
So….If the company didn’t exist, the ecosystem wouldn’t be able to take over all the work that the company is currently doing. This means that if the company didn’t exist there would be a lot of shoes to fill, and yet somehow there’s MORE opportunity because of the company?
There is no doubt that more people in the MySQL ecosystem have created more opportunities. The company/ies behind MySQL have, too — whether they’re Pythian, The Monty Program, MySQL AB or Sun.
(As for whether or not the ecosystem can take over the work the company is doing — I believe it can, but not immediately. Developers and engineers leave the company, but most don’t leave the ecosystem!)
Davi — it is logically sound. If you have a project that has decentralized engineering, it depends on contributions from outside the core of the developers. Problems come about if outside contributions are difficult to merge back in. In a decentralized environment, these issues are worked on sooner than in a centralized development environment.
I didn’t say that centralization *created* the difficulties, just that it’s possible to go longer without fixing it, because if you have most of your development centralized, it’s not as critical to be able to accept external contributions.
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
Dean — you’re also completely missing my point. Twice I said I was not making a value judgment of the company itself. You keep making value judgments, I am not.
I said that there are folks outside the company that are fulfilling the *roles* of development, training, support, etc. I did not say whether they surpassed the level of work the company does, or fell extremely short of the level of work the company does. I could — for example, there’s much more support externally, and much less development externally.
However, I was merely stating that there are already frameworks in place for handling the *functions* — I said nothing about the *capacity*. Why? Because I wasn’t making a value judgment.
All I’m saying is that a company behind MySQL isn’t necessary. If there is a company, it will continue to provide development, opportunities, etc. If there isn’t a company, though, there will still be a lot of good MySQL work being done out there.
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
Sheeri,
“You doubt that the ecosystem can take over all the work that the company has done, yet you say there is more opportunity because the company exists.”
The number and nature of opportunities that exist in the ecosystem today are a result of the fact of “the company” existing in the first place, and the work that “the company” performs. It’s a combination of (many) factors.
The opportunities available to “MySQL sans official corporate owner” would be reduced in number and nature simply due to the lack of the organizing “force” of an official corporate owner.
The work performed by “the company” is such that the ecosystem cannot really absorb it, meaning among other things that the product itself becomes immediately less attractive, also reducing the number and nature of opportunities available.
Et cetera.
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
Very nice write-up Sheeri.
The success of MySQL both as a product and as a business is actually described well in “The Innovator’s Dilemma” by Clayton Christensen. Its sequel “The Innovator’s Solution” clarifies where things can go wrong along the way with disruptive innovators. Ironically (given the book titles) these are exactly the things that MySQL the company has tripped over. It reads like a biography. It’s interesting and educational.
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
From my own experience (after working for MySQL – and then Sun – for more than 6 years) both good and bad things came from MySQL having a mothership: MySQL AB/Inc.
Without it, there would be no Users Conference, no commercial partnerships (many grew thanks to these partnerships), no adoption by many of the biggest commercial companies around (their lawyers won’t allow them), etc.
Without it, there would be more community contributions, most likely more modular code (maybe better plug architecture for more than just storage engines) and faster evolution (Postgress has evolved faster over the last few years).
My conclusion, MySQL is what it is today because of MySQL AB/Inc. Without it, it wouldn’t have ceased to exist (and it won’t die if it has no mothership today), but it wouldn’t be what it is today either. It would be better or worse? I don’t know, my crystal ball is being serviced right now.
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
So — has not having a successful mothership HAMPERED PostgreSQL?
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
Gerry — yes, exactly. I’m talking about from this point in time forward.
Steve — If you look at Selena’s post, she seems to say that lack of a mothership has hampered the ability of Postgres to spread.
This comment was originally posted on http://www.pythian.com/blogs)“>Pythian Group Blog
One Trackback/Pingback
[...] don’t know if there are projects already following this model. Selena Deckelman already used the term “Hacker’s Cooperative” though from a somewhat different perspective. If you know of anyone who has worked through the [...]