Feedback on blog post about Replication Feature decision and its impact

From: Dirk Riehle <dirk(at)riehle(dot)org>
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Feedback on blog post about Replication Feature decision and its impact
Date: 2008-05-30 10:21:53
Message-ID: 483FD541.9020809@riehle.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

Hello everyone, I was about to blog about the announcement of adding
replication to the core product but then thought I should ask for
feedback here. I moved it to advocacy (from hackers). Any thoughts would
be appreciated, thanks! --Dirk

----

Every software community has its peculiar challenges, and open source is
no exception. This post discusses the relationship between a core open
source product (PostgreSQL) and commercial offerings based on it (e.g.
EnterpriseDB).<p>

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.<p>

The core system until now 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 has
been mounting to add replication to the core product, and the core team
of seven committers finally made that decision at their recent users
conference. The <a href="
http://www.nabble.com/Core-team-statement-on-replication-in-PostgreSQL-td17537053.html">discussion
of these new features</a> is refreshingly unpolitical and focussed on
the task at hand, as to be expected of a mature open source community.<p>

<a href="http://www.enterprisedb.com/">EnterpriseDB</a> is a well-funded
database startup whose product builds on PostgreSQL. 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 the more advanced 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.<p>

So they finally made the decision to add replication, and it gives me
the opportunity to discuss what I believe are misunderstandings about
the open source business.<p>

<h3>Won't EnterpriseDB loose sales once replication is added to the core
PostgreSQL product?</h3>

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 <a
href="http://www.riehle.org/2008/04/30/sdn-is-open-source-competing-unfairly/">the
first (and important) step to a later sale</a>, as I have discussed
elsewhere. Enhancing the free product achieves exactly this.<p>

<h3>Won't a reduced differentiation between EnterpriseDB and the core
product reduce their addressable market?</h3>

I'm pretty sure it doesn't. The addressable market size doesn't go down.
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, <a
href="http://www.riehle.org/computer-science/research/2007/computer-2007.html">by
employing core developers, EnterpriseDB is well positioned to make a
believable case that it is the go-to provider of operational comfort</a>.<p>

<h3>There is only one license, the GPL, and everyone should be using
it.</h3>

PostgreSQL is a good example of a community open source project that
does not use GPL and still is flourishing well. Whatever the ideological
background of this statement, the belief seems to be that people should
be forced to contribute back to a project rather than do so of their own
choosing. That's hardly a notion that increases freedom. More
importantly, the rationale behind it makes little sense to me. In
general, firms and individual contributors alike are motivated to
contribute back (non-differentiating) code to reduce their maintenance
overhead. If they don't, they'll only create more non-differentiating
work for themselves as they are trying to catch up with the evolving
codebase. What's more, every possible proprietary extension faces the
problem of possibly being contributed by someone else, if only there is
enough demand for it. If you wait too long to make your contribution,
someone else will do it, and you just created another maintenance and
migration problem for yourself. Which is exactly what we see happening
with the replication feature in PostgreSQL. Pressure had been mounting,
and now it will be included, to everyone's benefit.<p>

--
Into novel software paradigms, tools, processes?
Then submit a short paper to Onward! 2008 by July 2nd!
See http://www.oopsla.org/oopsla2008/cfp/cfp-onward.html
--
Phone: + 1 (650) 215 3459, Web: http://www.riehle.org

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Andrew Sullivan 2008-05-30 13:29:03 Re: Core team statement on replication in PostgreSQL
Previous Message Dimitri Fontaine 2008-05-30 09:02:03 Re: Core team statement on replication in PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2008-05-30 11:19:03 Re: Avoiding second heap scan in VACUUM
Previous Message Teodor Sigaev 2008-05-30 10:08:05 GIN improvements