Why open core software is bad for the FOSS movement.
Nothing is inherently anti-business about Free and Open Source
Software (FOSS). In fact, a number of different business
models are built on top of FOSS. The best models are those
that continue to further FOSS by internal code contributions and
that advance the principles of Free Software in general. For instance,
there’s the support model, where a company develops free software
but sells expert support for it.
Here, I’d like to talk a bit about one
of the more problematic models out there, the open core model,
because it’s much more prevalent, and it creates some perverse incentives
that run counter
to Free Software principles.
If you haven’t heard about it, the open core business model is one
where a company develops free software (often a network service
intended to be run on a server) and builds a base set of users and
contributors of that free code base. Once there is a critical mass
of features, the company then starts developing an “enterprise”
version of the product that contains additional features aimed at
corporate use. These enterprise features might include things like
extra scalability, login features like LDAP/Active Directory support
or Single Sign-On (SSO) or third-party integrations, or it might just
be an overall improved version of the product with more code
optimizations and speed.
Because such a company wants to charge customers
to use the enterprise version, it creates a closed fork of the
free software code base, or it might provide the additional proprietary
features as modules so it has fewer problems with violating its
free software license.
The first problem with the open core model is that on its face it
doesn’t further principles behind Free Software, because core developer
time gets focused instead of writing and promoting proprietary
software. Instead of promoting the importance of the freedoms that
Free Software gives both users and developers, these companies often
just use FOSS as a kind of freeware to get an initial base of users
and as free crowdsourcing for software developers that develop the
base product when the company is small and cash-strapped. As the company
get more funding, it’s then able to hire the most active community
developers, so they then can stop working on the community edition and
instead work full-time on the company’s proprietary software.
This brings me to the second problem. The very nature of open core
creates a perverse situation where a company is incentivized to
put developer effort into improving the proprietary product (that
brings in money) and is de-incentivized to move any of those
improvements into the Free Software community edition. After all,
if the community edition gets more features, why would someone pay
for the enterprise edition? As a result, the community edition is
often many steps behind the enterprise edition, if it gets many
updates at all.
All of those productive core developers are instead
working on improving the closed code. The remaining community ends
up making improvements, often as (strangely enough) third-party modules,
because it can be hard to get the company behind an open core project
to accept modules that compete with its enterprise features.
What’s worse is that a lot of the so-called “enterprise” features
end up being focused on speed optimizations or basic security
features like TLS support—simple improvements you’d want in the
free software version. These speed or security improvements never
make their way into the community edition, because the company intends that only individuals will use that version.
The message from the company
is clear: although the company may support free software on its face
(at the beginning), it believes that free software is for hobbyists
and proprietary software is for professionals.
The final problem with the open core model is that after these
startups move to the enterprise phase and start making money, there
is zero incentive to start any new free software projects within
the company. After all, if a core developer comes up with a great
idea for an improvement or a new side project, that could be something
the company could sell, so it winds up under the proprietary software
“enterprise” umbrella.
Ultimately, the open core model is a version of Embrace, Extend
and Extinguish made famous by Microsoft, only designed for VC-backed
startups. The model allows startups to embrace FOSS when they are
cash- and developer-strapped to get some free development and users
for their software. The moment they have a base product that can
justify the next round of VC funding, they move from embracing to
extending the free “core” to add proprietary enterprise software.
Finally, the free software core gets slowly extinguished. Improvements
and new features in the core product slow to a trickle, as the
proprietary enterprise product gets the majority of developer time
and the differences between the two versions become too difficult
to reconcile. The free software version becomes a kind of freeware
demo for enterprise users to try out before they get the “real”
version. Finally, the community edition lags too far behind and is
abandoned by the company as it tries to hit the profitability phase
of its business and no longer can justify developer effort on
free software. Proprietary software wins, Free Software loses.