Opting for community-oriented free software business models

Bradley Kuhn starts his opinion piece with a analysis of the Open Core business model, and how it abuses GPL to lock in users to the larger proprietary versions.

He concludes that the FS community should not only look at the license itself, but at the whole community dynamics, and choose the smaller companies that give back to the code commons.

Bradley Kuhn:

The first move we have to make is simply give up the idea that the best technology companies are created by VC money. This may be true if your goal is to create proprietary companies, but the best Free Software companies are the small ones, 5-10 employees, that do consulting work and license all their improvements back to a shared codebase. From low-level technology like Linux and GCC to higher-level technology like Joomla all show that this project structure yields popular and vibrant codebases. The GPL was created to inspire business and community models like these examples. The VC-controlled proprietary relicensing and “Open Core” models are manipulations of the licensing system.

I realize that it’s challenging for a community to create these sort of codebases. The best way to start, if you’re a small business, is to find a codebase that gets you 40% or so toward your goal and start contributing to the code with your own copyrights, licensed under GPL. Having something that gets you somewhere will make it easier to start your business on a consulting basis without VC, and allow you to be part of one of these communities instead of trying to create an “Open Core” community you can exploit with proprietary licensing. Furthermore, the fact that you hold copyright alongside others will give you a voice that must be heard in decision-making processes.

Finally, if you find an otherwise useful single-corporate-copyright-controlled GPL’d codebase from one of these “Open Core” companies, there is something simple you can do:

Fork! In essence, don’t give into pressure by these companies to assign copyright to them. Get a group of community developers together and maintain a fork of the codebase. Don’t be mean about it, and use git or another DVCS to keep tracking branches of the company’s releases. If enough key users do this and refuse to assign copyright, the good version will eventually become community one rather than the company-controlled one.

My colleague Carlo Piana points out a flaw in this plan, saying “the ant cannot drive the elephant”. While I agree with Carlo generally, I also think that software freedom has historically been a little bit about ants driving elephants. These semi-proprietary business models are thriving on the fundamental principle of a proprietary model: keep users from cooperating to improve the code on which they all depend. It’s a prisoner’s dilemma that makes each customer afraid to cooperate with the other for fear that the other will yield to pressure not to cooperate. As the fictional computer Joshua points out, this is “a strange game. The only winning move is not to play.”

The software freedom world is more complex than it once was. Ten years ago, we advocates could tell people to “look for the GPL label” and know that the software would automatically be part of a freedom-friendly, software sharing community. Not all GPL’d software is created equal anymore, and while the right to fork remains firmly in tact, the realities of whether such forks will survive, and whether the entity controlling the canonical version can be trusted is another question entirely. The new advice is: judge the freedom of your codebase not only on its license, but also on the diversity of the community that contributes to it.”

Leave A Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.