Community open source is open source that is not owned by any particular company. Rather, ownership is shared among a large number of diverse stakeholders. Given the right (read: permissive) license, commercial companies can provide extensions to the community project, earning a living. Since such extensions are a unique selling point of these companies, one might think that they would prefer to keep the community project small and limited in features to facilitate an easy upsell to their more comprehensive offering. This thought becomes particularly intriguing given that commercial companies typically hire the core developers of such community projects to bring the necessary expertise in-house, and as some argue, to influence the project to their liking.
I think that this common belief misses the point.
The foremost competitors of a community-product based software company is not the community product but rather are competing proprietary and open source projects. It is in the interest of the commercial firms around a community project to make the community project as strong as possible to facilitate the overall sales process. Basically, it is best to focus on growing the market first before worrying about how to slice the pie. The struggle for market share between PostgreSQL, MySQL, and Oracle recently provided a great example to see these mechanics (and economics) in action.
PostgreSQL is a relational database system (the most advanced open source database in its own words); to many it is known as the other open source database (next to MySQL). Unlike MySQL, PostgreSQL is not owned by anyone, it is a true community project. What’s more, PostgreSQL is not based on the GPL (license) but rather on the more permissive BSD license, which lets companies distribute the database plus enhancements without having to contribute back their code.
The core system does not contain support for database replication. Naturally then, there are plenty of extensions, many of them open source, that add these features. However, if you need replication, it is rather cumbersome having to add some extension and maintain it separately from the core distribution. So the pressure had been mounting to add replication to the core product, and the core team (basically the community leaders) finally announced their decision to do just that at their recent users conference. The discussion of these new features is refreshingly unpolitical and focussed on the task at hand, as to be expected of a mature open source community.
There are many companies that have built a commercial offering on top of PostgreSQL. One of them is EnterpriseDB, a Boston-based database startup. EnterpriseDB adds many “enterprise-readiness” features to the basic PostgreSQL product, including database replication, and much more. One might argue that it is not in the interest of EnterpriseDB to have replication added to PostgreSQL as it reduces the differentiation between the free community product and their commercial offering. Why pay for EnterpriseDB if you already get what you need from the free version? Won’t adding replication to the core product reduce EnterpriseDBs sales? This tension seems only to get worse when you realize that EnterpriseDB employs several of the core developers of PostgreSQL, suggesting a direct conflict of interest when making decisions like whether to add replication or not.
However, this reasoning is based more on a cynic outlook on the world than rational economic thought. Lets take the questions one by one.
A: I think the opposite will be the case. Officially, EnterpriseDB wants to be a cheaper Oracle, but in the open source arena, its main competitor is MySQL. EnterpriseDB the commercial offering is competing with MySQL the commercial offering, and not with the free community version of PostgreSQL. It is in EnterpriseDB’s interest to have a free PostgreSQL version installed and used in as many IT departments as possible, because it is the first (and important) step to a later sale, as I have discussed elsewhere. Enhancing the free product achieves exactly this.
Q: Won’t a reduced differentiation between EnterpriseDB and the core product reduce their addressable market?
A: If anything, the addressable market will increase. That’s because EnterpriseDB is not only selling additional features, but more importantly to many applications and customers, it is selling “operational comfort”. Operational comfort means that EnterpriseDB is offering its throat (to choke) to customers should something go wrong. For money obviously; this is a core part of their business. Once a database system becomes mission-critical, few companies will want to go without paying for support. What the reduced differentiation does, however, is to increase the possible competition around selling such operational comfort. Other companies may more easily enter this market and compete with EnterpriseDB. However, as I have argued elsewhere, by employing core developers, companies like EnterpriseDB are well positioned to make a believable case that they are the go-to provider of operational comfort.
Now, I’m pretty sure the argument above is a bit naive when it comes to the full differentiation between a community product and commercial offerings. As I wrote elsewhere, I think the freemium model is the evolutionary end-game, for commercial and community open source alike. So there will always be additional features that will not be included in the community product. However, it will be a continuously receding horizon in most projects, for everyone’s benefit.
What I was getting at in this blog post is the observation that the perceived conflict of interest between community and commercial offering isn’t nearly as bad as many are thinking, and I think the PostgreSQL replication example is a good case in point.
Leave a Reply