How to protect communities from devolving into "open source in name only"?

Question

There are many open source communities that provide good and effective tools and ecosystems for their users. In fact, there is not doubt that the best programming tools available in this age, follow a pattern of a core open source software system that provides the essential functionalities, and a plethora of open source modules and extensions to the core module, so that the end developers can easily tailor their solution to their specific needs.

In almost all cases this works perfectly, with well maintained extensions that are open source and free for everybody to use and extend. For example, I have never seen a closed source or paywalled module for Python, npm. Ruby on Rails, for Java, all the modules needed to make your application work are there to be used.

But there are some specific open source communities, where eventhough there is an open source core module, it is practically unusable unless the user buys a plethora of closed-source extensions. I call these communities "Open Source In Name Only" (OSINO), since their objective seems to be to lure foolish developers into thinking that the ecosystem is open, while in reality it is impossible to use the software even for the most basic use-cases, unless you either spend hundreds of dollars in extensions, or spend hundreds of hours implementing all the missing functionally over undocumented source code. Some notorious examples are Wordpress, where you can't even have two languages in your website, or prestashop, where you have to buy extensions even for basic tasks such as accepting credit cards, or for allowing the user to edit his order while it is in the checkout cart.

A common pattern for these communities is to make it as difficult as possible to determine beforehand if a module is free or not, using shady tactics like not allowing to search by the cost, not disclosing all anti-features that the "open" version of the module provides, etc. To give an example of this, there was a wordpress theme that was "free", but you had to buy the premium version if you wanted it to scale on mobile.

My question is how can an open source community protect itself from devolving into a OSINO? Is there anything that either the core developers, or the community around the software can do to prevent such practices in their ecosystem? What defence do the developers or the end-users in open source communities have in order to in order to protect their community from this, and how have some communities managed to achieve this while others have not? And how can an end-user easily determine that the software they intend to use is really open or an OSINO?

Answer 1

There is no particularly good solution.

Open Source software needs maintenance, which has costs – at the very least, it will cost time. This is a tragedy of the commons scenario where everyone benefits from contributions, but it's not generally advantageous for anyone to contribute.

A potential solution is that one entity shoulders almost the entire cost, in exchange for some kind of (temporary?) monopoly over the project. In an open-core context, a company controlling a project can control which features makes it into the “official” version, thus ensuring a niche for their proprietary addons.

As long as the project license is Open Source, there is a balancing factor: this monopoly only exists with acquiescence of the community. Someone else can take over the maintenance responsibility and fork the project, and the community can migrate to that fork as the new “official” version. This is somewhat rare, but notable examples include the X server (two times!) and OpenOffice vs LibreOffice. More generally, competition for mindshare can encourage continued openness.

For the community, it is important to recognize certain risk factors:

• Open core is a kind of moral hazard, since the privileged maintainer is disincentivized to support Open Source features that would compete with their proprietary offerings.

  Nevertheless, open core can be a good compromise between openness and economic viability.

• Contributor License Agreements (CLAs) paired with copyleft licensing tilt the balance of power towards the original maintainer, since no alternative maintainer can compete with them on an equal playing field. Through the CLAs, the original maintainer is not bound by the public license and will always have more rights over the project.

  Nevertheless, a CLA can be a good compromise to make it economically viable to make some project Open Source – this is still a contribution to the commons.

In contrast, certain factors are more conductive to project health (but not necessarily project success):

• The project is controlled by a diverse consortium of for-profit actors, or by a non-profit foundation.

  Nevertheless, a single for-profit actor can also be a good steward of a project.

• The project has copyleft licensing without any CLA, or permissive licensing. That way, no actor has a substantially more privileged position with regards to copyright/IP.

  Nevertheless, the combination of CLAs with copyleft licensing does have legitimate uses, e.g. for the GNU project.

Understanding such factors can help with deciding what projects to depend upon, and deciding what projects to contribute to. Individuals within the Open Source ecosystem can vote with their dependencies, as a kind of Open Source pendant to voting with your wallet.

A solution that will not work is if every user of Open Source software were taxed in order to contribute to the upkeep. Such a tax will only work if it is mandatory, but mandatory fees are fundamentally opposed to Open Source values. Perhaps this means that the Open Source concept is inherently unsustainable. Perhaps there is an Open Source bubble with far more software being Open Source than actually economically viable. It definitely means that companies should be compelled to “voluntarily” contribute to Open Source maintenance for PR reasons, and that actual tax money should generally benefit Open Source rather than proprietary software.

I have not addressed your issues with confusing marketing, where it's difficult to determine what is Open and what is not. Misleading marketing is not specific to Open Source. One thing that can help is to access software through channels that vets Open Source licensing, or at least requires clear (and machine-readable) indication of licensing. On Linux, the Debian packages are a good example of vetting for license compliance. Package managers like NPM generally have machine-readable license metadata (though NPM is a bad example since the license metadata is frequently incorrect). On a social level, it is important to insist on clarity about what is truly Open and what is not. For example, the SSPL is a fantastic license for what it wants to achieve – but it sure isn't Open Source.

Answer 2

By using the GNU General Public License as the only binding factor between the organization and developers.

License which explicitly requires all the surrounding code needed to build, install and run the software to be libre too.

From the license:

All the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.

Be aware that the company can also request developers to sign a separate agreement that will waive part of their copyright rights. Hence allowing the company to publish their contributions in some other license, and with that allowing proprietary extensions to exist.

But if you haven't signed anything like that, the company MUST publish their extensions under the copyleft license. As they have to preserve the license for your contributed code.

That's why many companies like Apple like Open Source software that is under the MIT, BSD or LGPL licenses. They use contributions to back up their proprietary solutions.