77 lines
11 KiB
Markdown
77 lines
11 KiB
Markdown
---
|
|
title: "Open Core Is Cancer"
|
|
date: 2019-08-16T09:53:17-04:00
|
|
draft: true
|
|
---
|
|
|
|
# Open-Core software is cancer on the FOSS world
|
|
|
|
In December 2018, I started the Jellyfin project with a few other contributors. The saga is fairly long and complex, but the short version is: "FOSS" branded software closes off portions of their code, "FOSS" branded software does scummy things, "FOSS" branded software goes closed-source, "FOSS" community forks project, original authors call the FOSS community "moochers", "pirates", etc. "FOSS" community fork sees massive support and encouragement regardless. Clearly people like truly "FOSS" software.
|
|
|
|
Now, almost more than 9 months later, this saga has forced me to see something that I cannot unsee: this pattern is everywhere in the "FOSS" software world. It permeates projects, from large Enterprise-backed projects all the way down to small, single-developer projects. This mentality and software monetization paradigm is cancer on the FOSS world. It divides and drags down members of the community. It stifles contributors and users. And it is only getting worse.
|
|
|
|
In this post I hope to record my thoughts on this trend, as a sort-of manifesto for my ideas in developing FOSS software, such as my [PVC](https://github.com/parallelvirtualcluster) hypervisor manager project, and of course [Jellyfin](https://jellyfin.media).
|
|
|
|
## What is "Open-Core" software?
|
|
|
|
Before I can explain why I think Open-Core software is cancerous, it's helpful to have a definition for it. I use the following:
|
|
|
|
> Open-Core software is software that consists of at least two versions.
|
|
> One version is fully FOSS-licensed, distributed, and maintained as FOSS software. It accepts contributions from community members, it is released under a FOSS license, and is generally Gratis. It is often called a "community edition", "free edition", or something of the sort.
|
|
> The other version(s) are NOT FOSS-licensed. They are almost invariably fully closed-source, and are only available for a fee in binary format. They are often called the "enterprise edition", "paid edition", etc.
|
|
> Most critially for the definition, and separating "Open-Core" from two closely-related projects that are simply "FOSS" and "Closed-source", is that the *the non-FOSS components extend the functionality of the FOSS component*. Or put another way, the non-FOSS components offer *features and functionality* that are explicitly missing from the FOSS component.
|
|
|
|
With this definition out of the way, we can begin to talk about the motivations for "Open-Core" software, and why this is destructive to the ethos of FOSS.
|
|
|
|
## Why would anyone choose "Open-Core" as their software model?
|
|
|
|
Money.
|
|
|
|
It's about the money.
|
|
|
|
No, really. It is widely accepted that FOSS software has a "monitization problem". That is, it's hard for programmers to get paid to write software which is given away 100% freely. And even I can conceded that this view has merit. Despite being an avowed Communist, I can accept that in a Capitalist economic system payment for programmer time is important.
|
|
|
|
However, this sort of monitization is also the *easiest* form. It's absolutely trivial to hide functionality behind a paywall. After all, the code is the same. A developer simply has to not release part of the code as FOSS and suddenly, if that feature is high demand, they have a guaranteed revenue stream.
|
|
|
|
This is not the only method to ensure developer time is compensated, nor even is the requirement for compensation guaranteed. The Debian project is able to create a fully-functional (and in my opinion one of the best) operating systems in the world entirely through volunteer effort. Other projects are able to fund developer teams only through donations. These methods are not impossible. But they require work beyond just writing the code. Volunteer-only projects require non-monetary compensation to be worthwhile to the contributors (often in the form of self-motivated goals, and the sense of community the projects provide, important human motivators). And donation-based projects require active effort to ensure a steady stream of donations. But again, this is not impossible, and there are countless examples of 100% FOSS software which is able to succeed with these methods.
|
|
|
|
There is one more method: support. The model of RedHat, the most successful FOSS-based company in history. Provide the product for free, and support it for a fee. Clearly this method also works. But it requires even more effort and process than the donation-based approach. And unfortunately, projects that already use this method can quickly succumb to a desire to boost their monitization by going "open-core"; even RedHat has. the reason is quite simple: you need talent to monitize support, talent that is often very quick to leave for greener pastures. And you have to be able to support complex issues with the software in order to justify the costs. It is a balancing act, and one that is not always successful. But it certainly can be, at least until the Capitalist profit motive overrides moral considerations.
|
|
|
|
## Open-Core, by its very definition, disrespects the ideals of FOSS software
|
|
|
|
This is a pretty spicy take. And of course, I'm not qualified to speak for every FOSS developer, community member, or Richard Stallman out there. But let me break it down.
|
|
|
|
FOSS software, and specifically copyleft (GNU GPL), is built on the 4 key freedoms, laid out by the GNU project:
|
|
|
|
* The freedom to run the program as you wish, for any purpose (freedom 0).
|
|
* The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
|
|
* The freedom to redistribute copies so you can help others (freedom 2).
|
|
* The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
|
|
|
|
In the strictest sense, open-core seems to abide by the letter of these laws. After all, one could easily argue that "any given feature in the closed-edition is simply not FOSS, but the rest of the software is". But I think this is fundamentally missing the *point* of the four freedoms. They speak towards an ethos of collaboration, of sharing the softwrae fully in order to enable each user to have those freedoms.
|
|
|
|
And this is where I think open-core is insidious. If a user of a piece of software is only able to achieve 80% (for example) of the functionality of the software, under traditional FOSS software it behooves them to implement that remaining 20%. Hopefully, with the support of the community, those improvements can then be shared back to the remainder of the community, both to build on, and improve further. But if that remaining 20% is locked behind the non-FOSS portion of an open-core project, a conflict of interest arrises. Community members may want to implement that functionality for themselves, but attempts to contribute it back upstream will inevitably be rejected - the group running the software does not want that 20% being freely available under the FOSS license. This has a chilling effect on the community: seemingly arbitrary pieces of functionality can, at any time, be stripped out in favour of the non-FOSS component. And this in turn leads towards contributors second-guessing features - does X fall under the banner of Y which is a non-FOSS component? Am I even privy to the existence of the functionality? Will my contribution be rejected without explanation and possibly even deleted? Will I be threatened with "infringement" because I accidentally reimplemented non-FOSS code? This is also a clear conflict of interest with the ideals behind the four freedoms. By causing developers to question the nature of their contributions and where they fit in to the grand monitization scheme of the project, they really are having the second, third, and fourth freedoms compromised.
|
|
|
|
## Gratis users are left in the dark
|
|
|
|
So, the "Open-Core" model is harmful to developer effort and the spirit of cooperation in FOSS software communities. But it also harms users as well.
|
|
|
|
Motivations are often unclear and hidden. I'll admit, I've seen examples of Open-Core software that truly does respect their FOSS and Gratis sides. They release all the important features for free, and reserve a select few for their paid version. However, how can any user ever know where the line is drawn? Perhaps a feature that seems "high-end" to the developers is a critical feature for a very small operation. Or perhaps, in the inverse, a very heavy/large user has no use for any of the paid features. No one wins in this scenario.
|
|
|
|
"Open-Core" ultimately results in keeping users, and specifically the Gratis users, in the dark, always second-guessing what might happen next release. Alway second guessing whether a "bug" is legitimate or a scummy attempt to force users to the non-FOSS versions. And this harms FOSS in general - after all, the project is branded FOSS, has a FOSS community, but if users see, for example, a big performance bug, and this bug is not present in the non-FOSS versions, it begs the questions "is this a priority to fix?" and "is this intentional?". Both of which harm the developer, as well as the FOSS community more broadly.
|
|
|
|
Further, it's often hard to tell whether projects are taking a "release-later" "open-core" position. With this sort of position, the software releases a feature as part of the non-FOSS product today, but intends to eventually release it as part of the FOSS project. But of course, if they announced they were doing this, it would cannibalize their attempt to monitize. So this fact is hidden from end-users, until the day the feature is released. Now, I do think that this method of "Open-Core" is probably the least offensive, since the features do eventually make it to the FOSS community. But this is also predicated on the good-will of those behind the project, and can change at any time. All of this leaving users in the dark.
|
|
|
|
## Monitization drives decisions
|
|
|
|
Beyond just leaving users in the dark, with "Open-Core" software, the attempt to monitize will, almost inevitibly, change the motivations of the project for the worse.
|
|
|
|
In a truly FOSS project, 100% set to the ideals of the 4 freedoms, every decision, every feature, exists to make the project better. It has to - otherwise, why would anyone contribute it? Perhaps it only scratches the itch of a single member of the project, but that's still a motivation to improve the project as a whole. And since every change is open to everyone, it can be adequetly critiqued and tweaked to be the best it can be.
|
|
|
|
|
|
|
|
1. Do not respect FOSS ideals
|
|
2. Gratis users left in the dark
|
|
3. Monitization drives decisions
|
|
4. What about the future?
|