Unionize Free Software. Found Software Guilds

In the article “The changing economics of open source” Ken Mugrage present the Free Software Sustainability problem from the perspective of companies depending on free software developed by hobbyists.

The article defines three different types of free or open source software:

  1. Free Software developed by companies or individuals trying to make a living by this activity.
  2. Open Source projects used for publicity of Big Tech.
  3. Free Software developed by hobbyists as a recreational voluntary activity.

And provides examples for each of these types of projects, namely ElasticSearch, React and Log4j respectively.

It ends with a recommendation for companies to:

  1. Investigate what project’s they depend on
  2. Review how likely these projects are to change licensing.
  3. Investigate the possibility of maintaining a fork of a FOSS project if the project developers change licensing.

While these recommendations are rational from the perspective of a business depending on free software - which today is almost every business, even if they just use Wordpress for their website - I disagree with the underlying assumption that free software can be exploited for maximum gain and that companies should try to make themselves independent of a free software developer only to then continue to benefit from their work for as long as possible.

The example the article provides of ElasticSearch and AWS I find particularly disturbing:

For instance, ElasticSearch changed its licensing terms in 2021, to include requiring cloud service providers who profit off its work to pay it forward by releasing the code for any management tools they build. […] They prompted Amazon Web Services, which had been offering a managed service based on ElasticSearch until the change, to “fork” the codebase and create a new distribution for its OpenSearch product.

Here the enormous company AWS would not accept that ElasticSearch wanted them to afford the same courtesy they had provided AWS by releasing their source code to others.

This is exploitation by a big tech company of free software. And it cannot stand!

We shouldn’t advise companies to exploit free software as much as possible and to cancel that relationship as soon as it gets inconvenient.

If a company makes the majority of their profits from a service reliant on free software, they shouldn’t be able to dictate to the free software developers the terms of that relationship.

Unionize Free Software

Free Software Developers, regardless of whether they develop software for recreational and hobbyist purposes or to sustain their living should unite into a group.

In this group they should be united to:

  1. Share maintenance of projects by making it possible to quickly find temporary or permanent maintainers for projects in the group or even sharing the maintainer role between two developers permanently.
  2. Defend against exploitation by collective action. The licenses of the group would by synchronized and the group should be able to sue in case of violations to the license terms of any of the member’s projects. In a case like that of ElasticSearch and AWS, the entire group might change their licensing together, making it too expensive for AWS or another big tech company to fork each and every single project and maintain it in house. Thus forcing them to negotiate with the group as equals.
  3. Pool donations and funding. Instead of every developer raising the money to maintain their own development, the group collects donations and funding together and distributes them according to a democratic decision by all members.

Let’s for example ask, why I (@CSDUMMI) or @aschrijver would want to join such a group? @aschrijver is a maintainer of several projects, among them the coding.social website and I’m a developer of free software, such as the maintain-website-tool.

By joining such a group we would gain:

  1. Maintenance sharing and support. Maintenance sharing means developers in the group agree to be maintainers of each others projects, allowing them to take time off from development and having the other taking over either temporarily or permanently even. Support is both financial, social and collaboration.
  2. Defense against big tech by collective action. If my maintain-website-tool for example was integrated into a service by AWS or Google, the group would provide me with a stronger voice to challenge this if I wished, while I personally would think more than thrice about sending a complaint to the overflowing Irish or American mailboxes.
  3. To be allowed to sustain ourselves by our development and our development only. We don’t want to have to split our time between development and fund raising at all times.

Union of Free Software Developers

Free Software development is a peculiar and unique industry. It is the only industry where volunteers, paid employees of third companies and employees of the company developing a piece of software can work side-by-side - without discussing this difference in compensation or incentives.

Due to this situation a Union of Free Software Developers have to be open and accessible to all of these people.
It needs to be as global as free software, directly-democratic and yet be able to sue and represent their members in court.

Thus I propose an organization in two parts:

  1. The group itself, organized through online forums and the Fediverse, holding votes and debates, raising money. Accepting members and the like.
  2. A non-profit foundation cooperating with one or more of these groups that is financially supported by them. They should be able to sue and defend the terms of the licenses of the projects of the group members they cooperate with, hire lawyers and do lobbying work to give these groups a place at the table for negotiations in government. They need to. The exploiters certainly already have an ancestral seat at those tables.

Conclusion

Free Software Sustainability is the problem of free and open source software today. Providing solutions to this problem will not just determine how free software will be developed in the future but also what free software will be developed.

Because the way people are supported and motivated to develop software is an important determinant in what is being developed.

I believe in the force of internal motivation and despise any attempt to demand free software to commercialize or otherwise optimize towards some external quantitative goal - ratings, stars, users, downloads and other such statistics.

If free software development can only be sustained by all of it fulfilling some external standard, neither the freedom 1 nor the freedom 3 makes any sense anymore.

  • 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 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.
    The four freedoms

These freedoms are the basis of collaborative free software development. So, to limit or define what constitutes “proper”,“sustainable” or “reliable” free software is to limit these freedoms by limiting how they are exercised “properly”, “sustainably” or “reliably”. You can make arguments that software ought to be developed using some paradigm or using unit tests but don’t require free software to fulfill these criteria to be considered “proper”, “sustainable” or “reliable” free software. Otherwise you are limiting what free software itself means.

To return to the article I began this post with, Ken Mugrage does just that. The article defines what free software a company should work with, which they should undermine and which they should avoid - once again, this is legitimate from a company or even devops perspective. But the free software movement should not let itself by commercial company interests…

See: socialcoding