Home > Open source, Ubuntu > Why Open Core is wrong

Why Open Core is wrong

Open core is a business model where the base version of a software would be released as open source while some advanced features would be closed source. It’s been under a lot of discussion lately, so I’ll just add my 2 cents…

Outside the obvious workaround of the free software principles, there are well-known issues with this model. In particular, it is difficult to set the right limit between the “community edition” and the “enterprise edition”, and you end up having to refuse legitimate patches that happen to be a feature in your enterprise edition roadmap. So building a real open source community on top of the Open Core model can be quite a challenge. But the main reason why I think it’s wrong is purely technical.

I am a perfectionist. I work on open source software because I truly believe that the open source development methodology ends up creating better code. Having all your code out there, up for scrutiny and criticism, makes you think twice before committing something half-baked. Allowing everyone to scratch their own itch ensures top motivation of contributors and quick advancement of new features. And I could go on and on…

Open Core denies that the open source development model creates better code. Open Core basically screams: for the basics we use open source, but for the most advanced features, the enterprise-quality ones, closed source is at least as good. You end up alienating a potential community of developers for the benefit of writing closed source code of lesser quality. You end up using open source just as a VC honeypot.

Open Core advocates say that open source software companies need some unfair advantage to monetize their efforts, and justify Open Core based on that. I’d argue that selling expertise on a awesome piece of software is a better business model. It’s true it’s a longer road to become rich, but I still think it’s the right one.

Categories: Open source, Ubuntu
  1. Javier Rivera
    July 9, 2010 at 07:56

    I have always think of the open core the other way around.

    The difficult code, the hard bit, where bugs are harder to find, the responsibility for the stability was the core. The open source part.

    The closed one was the polish. The easy (in difficulty) but hard (on time and amount of work). The one that it’s more a kind of art than engineering. The last bit. The more user visible slice. The one where code quality is of lower importance than design.

    This is why I feel that open core makes sense (as least from a commercial stand point), the hard (as difficult) part is make in the open, with a better and cheaper development model. The bit that the consumer feels and sees, the bit that define the product in the consumer eyes is done closed and keep exclusive for one company. That’s the way of Android, NoMachine NX and even kinda of OS/X or Safari.

    • Thierry Carrez
      July 9, 2010 at 08:39

      That’s an important point: it all depends on where you draw the line. Some projects are well-suited for a niche-market-extensions opencore model (which is very close to the “sell expertise” model), some others are well-suited to the polish/GUI route. So it’s not binary… but I still think that facing the risk of losing a community for the benefit of a questionable upsell is not worth it.

  2. July 9, 2010 at 12:14

    I am with you on this. This is especially true when the product your business is selling isn’t the software itself. For example, if your are selling a DVR, a POS system, a cell phone (ala Android powered devices) or some other sort of hardware that is driven by OSS software.
    At that point there are all sorts of services to monetize. The most obvious is the sale of the hardware. The integration between the hardware and the software is a competitive advantage point you can offer over, say, someone building their own.
    You can also offer update support, technical support, and professional installations.
    All of this can allow a business to offer a product developed on a full FOSS software stack and make money and offer their customers a competitive advantage over others.

  3. July 9, 2010 at 12:56

    I agree, it all depends on where you draw the line. Some open core products do it better than others. It is essential that the community edition be comprehensive enough that it’s actually worth using for the majority of community projects. for instance, don’t release as close source a module that uses a very common open standard.

    My rule of thumb would be:
    * Everything that uses or implements open standards or exclusively makes use of open source libraries should be part of the community edition, so you can easily accept patches for those and you don’t artificially cripple the use community projects can make of the product;
    * Everything that uses closed source products or implements non-free standards should be part of the closed source “enterprise” edition: people who have already invested in other closed source technology will be ready to pay a premium for a product that supports them and you won’t cripple community projects.

    But more importantly, it is extremely important that the line is known, well documented and doesn’t change at a whim. There is nothing worse than using an open source product that has a closed source counterpart and one day realise that a feature that you used and was open source has been pulled into the closed source edition thus breaking your project.

    And in an ideal world, I agree with you, a completely open source product upon which you sell services is a better model.

  4. July 11, 2010 at 09:48

    The problem is that open core sets the focus on selling close source, and eventually the open source part isn’t that important because the aim of a company it’s benefit.

    Without community, OSS is useless, and most of the open core companies I know fail to have a healthy community around the project because their model feels like “community stuff it’s for toying and you have to pay for the enterprise version to make some serious work”.

    Open core sounds to me like abusing the OSS idea to be seen like one of the cool guys in the IT block.

  5. September 9, 2010 at 10:42

    A criteria for tracing the line is maybe the “business- and user-relevance” of the code.
    What is specifical of my business, what is completely original, innovative, exclusive, will be closed source. Because if I leave it open, I loose the *big part* of my competitive advantage.

    On the other hand, the most important parts from the user’s point of view should be open source, so he can change/correct/etc them as he likes and change it’s user experience, it’s way of working, …

    The web is made in a similar manner: the code which generate the pages is mostly closed source on the server side, as it’s business-relevant; the client which views the pages is frequently open source, as it’s user-relevant.

    Unfortunately, this criteria is not valid for any kind of application, and it’s not always simple to distinguish business and user points of view.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s