The real problem with Open Core

Yesterday, I wrote down some thoughts on Open Core. I covered how there's no real definition of "open core", and how that's problematic for some when it comes to calling an open core project "open source."

On this topic, I settle into a different place than others. And that's fine. But let's talk about the real problem with open core: open core isn't really open. You (arguably) have the open source part, which is open, but the proprietary part will never be open.

I'm not saying proprietary software is bad — Keygen itself is proprietary software, at least for a couple years (we'll get into this in a second). Without proprietary software, a lot of businesses wouldn't be viable. So proprietary software is not bad.

But what is bad is saying something is "open", yet — in a lot of cases, the important parts — the valuable parts — are not.

Let me explain.

Let's imagine an open core project called Acme, which has an open source Community Edition, and a proprietary Enterprise Edition that offers some additional features that larger businesses find valuable. The CE code is licensed under AGPL, while the EE code is in an ee/ directory, licensed under a one-off commercial license.

Pretty standard stuff.

Now let's imagine we're a software vendor, and we want to use Acme. Because of the FUD-dy AGPL license, we purchase Acme EE. Acme EE also provides us one feature we really need. The feature isn't really complicated, but building it ourselves on top of Acme CE is too ambiguous from a legal point-of-view.

(Okay, I'll relent on my distain i.r.t. the use of AGPL in startup-land.)

We agree on yearly terms for Acme EE.

A couple years pass. All is good — we have Acme EE running in production, and it's become a staple in our technology stack. We've become reliant on the features in Acme EE.

Then we get some bad news —

Acme, the company, is shutting down. (Like startups do.)

In this scenario, what happens to Acme EE?

There are a few ways things could go down:

1. Acme could open source all of its code under a more permissive license, including all of its proprietary code for Acme EE.
2. Acme could issue perpetual licenses for Acme EE to all of its enterprise customers.
3. Acme could simply not do anything.

The first 2 rely on goodwill, which is never a good thing in business. Have the first 2 ever happened? Maybe, sure — but no particular project comes to mind. But we also have to keep in mind that 3 is the default. The default is to simply do nothing and let your dependents fend for themselves.

As a software vendor, what are you supposed to do in scenario 3?

1. You could take Acme CE and (re)build the features you need. This is risky both from a legal POV and an engineering POV.
2. You could run Acme EE anyways, illegally.
3. You could find or build an alternative.

Most are going to land on 3, simply because the other 2 are too risky.

This is the real problem with open core: by default, it's not really open. By default, everybody loses in this (likely) scenario.

To me, it's too risky to rely on the proprietary bits of an open core project like I would an open source project. There's too much reliance on goodwill, and as a business owner, I can't rely on goodwill. Instead, I do risk-assessment like I would any other proprietary project.

By default, open core is inherently closed off to those who rely on its proprietary bits. By design, open core isn't open to them.

I believe there's a better licensing model these days — one that doesn't rely on goodwill, but one that codifies better defaults.

Over the course of the last handful of months or so, I've been involved in an initiative called Fair Source, which is hoping to become: a new term businesses can use, instead of open-washing source-available licenses; and a new suite of licenses that company's can use to safely share their core projects — and eventually open source them.

That last bit — eventually open source — is accomplished through Delayed Open Source Publication (DOSP), which is really just a fancy way of saying that the project converts to an open source license after a certain amount of time, typically 2 years.

Fair source, depending on the license, may not be as close to open source as open core — but it's pretty damn close. Sometimes, it's even closer, especially when you factor in the fact that most commercial open source projects are licensed under the FUD-dy AGPL, which many businesses just can't use.

Under fair source, 99% of users experience the same freedoms as open source. They can read, use, modify, and redistribute the code, with very few limitations. The 1% — those that experience any limitations — are those that want to compete, and it's fair that they have to wait for the open source version eventually published under DOSP to do so.

Without DOSP, words like "longevity" don't mean anything for those using the proprietary features of a project. Like I said, under open core, the default is not longevity for companies relying on proprietary features — the default is abandonware.

And before you think that I'm trying to push open core projects away from open source and into fair source, let me stop you — I'm not^[1][2]. Open core and fair source can live together. If a company is already comfortable sharing their "core" under open source, then I wouldn't want to encourage anything else.

But instead of an open core project adopting one-off commercial terms for its proprietary code, let's think up a commercial license that does the same thing while undergoing DOSP.

Without DOSP, open core is not really open.

[1]: With caveats — particularly around how the AGPL is used as a hush-hush non-compete in startup-land. I don't agree with it, and in those cases, I do think fair source is superior — and also more honest. But I digress.

[2]: Fair source wasn't created to diminish open source; it was created to be an alternative to closed source. An alternative that offers much of the same benefits as open core, while proliferating more open source in the end.