Friday, May 25, 2007

The EnterpriseDB Licensing Model

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.

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.

What are your thoughts about this business model specifically, or the commercialization of open source software in general?

No comments: