Talking about EnterpriseDB I used the expression “false positive”, but actually I didn’t provide any test to “detect” if a firm is or not an open source firm, and the community can’t be an effective analysis tool for this.
Symbiotic relationship by georger_gilbert
Researchers found a pragmatic answer, and I am start thinking is pretty correct, but judging firms by their actions could require some effort, though. Google for example is taking advantage of the GPL loophole, but it is also contributing to many projects, Google summer of code included.
Creating open source firms’ categories reflecting the corporate-community relationship could be interesting, but complex distinctions might bring more confusion than clarity, I am afraid.
I firmly believe in the value of open source. There is no question that open source communities produce great software, and do so quickly and with extraordinarily high quality. Yet EnterpriseDB’s principal product — EnterpriseDB Advanced Server — is a closed source product. Why is that?
The answer to this question is a little involved, but stay with me…I think the logic is actually pretty simple.
Like all commercial organizations, EnterpriseDB is in the business of making money. When we created the company, we needed to define a mechanism of delivering value to customers for which those customers would be willing to pay. We originally planned simply to take the same approach as most other open source companies, which is a dual-licensing strategy.
With a dual-licensing approach, the company is protected by a GPL (or similar) license, because both competitors and potential customers who wish to embed/link with the GPL software must also GPL their own code. Since most competitors/customers don’t wish to do so, they are willing instead to pay for a commercial license. This simple yet subtle point is at the heart of the success of nearly every commercial open source organization. I would be remiss (and Matt would surely bonk me on the head) if I didn’t also mention the value that these companies bring via their expert support and services. But the subtle yet powerful truth about commercial open source is that the GPL is an excellent enforcement mechanism for creating commercial value.
Now, unlike most open source projects, which are licensed under the GPL or similar license, PostgreSQL is a BSD-licensed project. As most of you know, BSD is among the most permissive licenses, allowing anyone to do anything with the code, with virtually no restrictions. In other words, the BSD license provides no commercial protection whatsoever, either from competitors or potential customers. With the BSD, anyone can take the code and do anything they wish.
So why not just change the PostgreSQL BSD license to GPL? Remember that, unlike most open source companies, EnterpriseDB did not create the open source project upon which it is based. The PostgreSQL community has been around for more than a decade, and is one of the most strongest and most independent open source communities in the world. EnterpriseDB does not control the copyright or the license to PostgreSQL, which means a dual license business model is simply not an option for us. PostgreSQL is BSD…period. And by the way, the PostgreSQL community strongly supports its staying that way.
I am not sure EnterpriseDB would have ever considered using a double-licensing scheme, if possible. MySQL – the world’s most popular open source database – has a customers/users that is about 1/1000, and is popular by small-to-medium enterprises.
EnterpriseDB (PostgreSQL) is not as popular as MySQL, and EnterpriseDB target audience is different, mostly medium-to-large enterprises, willing to pay for value added services. I believe that the Split OSS/Commercial product business model suites them very well, much better than double-licensing.
So…what to do? How can EnterpriseDB create a business model that honors the PostgreSQL license and community style, while at the same time allowing the company to deliver value for which customers will pay? The answer is fundamentally a 2-part strategy:
First, we created a superset of PostgreSQL called EnterpriseDB Advanced Server, and closed-sourced the code. In other words, atop base PostgreSQL, we added deep Oracle-compatibility, dynamic performance tuning, and world-class tools, including replication, debuggers, browsers, and more. Then we closed-sourced the whole package. In this manner, we have crisply defined a set of value-added features for which we charge, much like SugarCRM’s professional edition. If you want the free-and-open-source version version of the software, though, it’s easily available…and it’s called PostgreSQL.
The second — and equally important — part of our business strategy is to be an excellent citizen in the PostgreSQL open source community. We are building a successful company on the shoulders of one of the world’s most successful open source projects, and we have a responsibility to give back to that community to the maximum extent possible, while still protecting our ability to generate revenue. In addition to our ethical responsibility, we also “do well by doing good” because we promote the wider spread of PostgreSQL, the world’s most advanced and enterprise-class open source database (albeit only the second most popular).
Our efforts at being excellent citizens of the PostgreSQL community are wide-ranging, but tend to fall into the following broad categories:
- Identify important and difficult development community projects, and get these projects done with EnterpriseDB staff
- Employ community leaders, including both titled members (i.e., core team) and thought leaders
- Sponsor non-employee community developers
- Be a major sponsor of community gatherings and other activities
This balanced approach of selling commercial software on one-hand and aggressively supporting the community on the other is our answer to the conundrum of creating a commercial company on a BSD code base. I think there have been some misunderstandings about our approach in the past, and I hope this clears them up.
While I keep thinking that EnterpriseDB business model is not related to a license issue, I totally agree with Andy Astor, EnterpriseDB is an open source firm and… it is also adopting a symbiotic production model!