3x09: ASCII code 0x46

Stuart Langridge, Jono Bacon, and Jeremy Garcia present Bad Voltage, in which there is a certain amount of disagreement but it all works out in the end, and:

  • [00:03:20] There's a lot of conversation about "open core", and there's increasing polarisation around the topic. But... what actually is an open core project or product? Does everyone even agree on the terms? And once they do, is that thing a good idea? And how do you do it right? We're going to look into it in some detail; what are the accusations and defences flying back and forth, which projects actually are "open core" and which not, and what's a good business model for open source in the modern age?

Come chat with us and the community in our Slack channel via https://badvoltage-slack.herokuapp.com/!

Download from https://badvoltage.org

News music: Long Live Blind Joe by Robbero, used with attribution.

Thank you to Marius Quabeck and NerdZoom Media for being our audio producers!

My concern with Open Core projects is that it has…I guess the most apt term is “corruptive” influence on the project and surrounding community, because the commercialized features necessarily either become forbidden in the community project or create resentment between the two teams. Projects like Redis are probably exceptions, with a strong pre-existing vision that separates the two missions, but when someone shows up with a “make GitLab act like the enterprise product” pull request, it’s getting rejected; if there are ambitious maintainers on the project, there’s probably going to be a major fork that pulls customers away.

That said, since every other open source business model is basically “don’t be a software company,” it’s hardly the worst idea available. A nicer approach would be to migrate commercial features into the community edition after a couple of years. Companies used to do that all the time for customers (charging for a new feature and temporary exclusive access to it), so it’d probably work for Open Core models.

A lot of this episode comes down to the basic argument of definitions. You have the ancient parable of replacing a ship, the more modern question of how we define a sandwhich, or my personal version of “what is pizza”.

If you use fuzzy definitions, you’ll get fuzzy answers. If you use fuzzy definitions and MAKE them strict, then pretty soon everything edible is pizza. “pizza flavor” means nothing at all. Same with pizza shape, pizza size, or any combination of pizza ingredients. Barbecue Chicken pizza is valid, but so is chocolate, because the definition strictly allows it.

But if we start with a strict definition, then square pizzas might no longer be pizzas. Barbecue Chicken is right out the window. Pizza flavor might makes sense, but a basic cheese pizza might not.

Open Core is a fuzzy definition. So applying strict definitional standards to it will give some weird results. Is Apple open core? I mean, They do have the Darwin project. But as a project of course it doesn’t have many open source merits. And if it has to have open source merits, then “open core” isn’t what you want in the strict sense, and isn’t what you want in the fuzzy sense. In both cases, we would want open source.

We are willing to accept proprietary extras, I think, mostly because the cost/benefit analysis of each person considers how close it is to open source as a benefit, not as a “do or do not” strict line, but as a “pros and cons” calculation. I buy games off Steam that aren’t open source. If the same game was open source, I’d pay an extra sum of money. If it was “open core”, I’d probably pay an amount in between. It’s not much different if the game adds in DRM and the cost benefit analysis changes. When you stack on negatives it really just depends on how good the product is whether or not the game becomes worth the extra non open-source bits.

1 Like