The problem with Open Core
Tuesday, September 17th 2024Zeke Gabrielse, Founder of Keygen
If you imagine "open core", what do you see? Some see an open source project surrounded by proprietary code, others see an open source project with an auxiliary proprietary project. And depending on what you see here, you may have a different opinion on whether open core is actually open source at all.
I've had a handful of conversations lately around open core, and one thing I've noticed is that open core isn't as well defined as I originally thought. So barring my thoughts[1] on the open core licensing model itself and how it's commonly implemented vs other licensing options these days, let's cover the various viewpoints on "open core."
Me, if I see an open core project, I also see an open source project. It
doesn't matter if it has an ee/
directory with proprietary code inside of it,
just like it doesn't matter if there's a separate proprietary project sitting
next to it by the same author. It doesn't even matter if there's proprietary
code protected by license keys intermingling in the code base — because if
it's using an open source license, that proprietary code can be ripped out
(see: GitLab's open source mirror on GitHub). The makes sense to me — the
core is open.
Others see things differently. And I although I don't think it's necessarily wrong (after all — the people holding these views have been involved in open source for a long time), it does introduce some 'hand-wavyness' to what constitutes "open core."
Some may argue that an open core project is not really open source if there's proprietary code inside of the open source project. They want clear separation. But this seems hand-wavy, because you could very easily rip out the proprietary code and then viola — it's "open source."
What's the real difference, though? What does it matter where the proprietary code lives? It's all licensed the same, so functionally there's no real difference. I think this is my big hang up here and why I feel like this view is wrong. It's too hand-wavy to me.
Some may argue that an open core project is only open source if the core is actually useful without the proprietary code, e.g. their bright line may be that 98.3% of features must be available in the core. But I think this view falls a part when you accept the fact that some open source is useless, too — yet it's still open source.
Others may argue that an open core project is not open source, ever. But again, this seems arbitrary, and doesn't align with the common way "open source" is used. You don't see the OSI-zealots storming the castles of Cal.com, PostHog, Plausible, or GitLab screaming about misusing the term "open source."
Under this view, no commercial open source project is actually open source. And that just doesn't feel true — at least if you look at the common vernacular. And like I said, not a lot of people outside of the OSI hold or protect this viewpoint.
I do think it's a problem that there's no real definition for "open core", but evidently, it's not a very big problem.
[1]: I wrote a followup to this post here.