I’ve long thought that the definition of “Free Software” is off putting at best. At worst, its viral licensing, moral rigidity, and absolutist value judgements are harmful to actual software freedom. Meanwhile, the definition of “Open Source” makes for more legally compatible software and provides flexibility for software authors and users. However, it’s broad enough as to be almost meaningless, making it easily appropriated by corporate interests. Finally, both put a great deal of emphasis on software distribution and other legal matters while ignoring project governance. A better system would account for equity in distribution, governance, and use of the software.

More recently, I became aware of a post about the “philosophy and understanding of the role of computing and software in our society”:

it’s 2021 and we are still talking about “free software” instead of:

• community software
• liberated software
• anti-capitalist software
• transformative justice software it’s been 35 years, and our philosophy and understanding of the role of computing and software in our society has changed drastically. The FSF and the culture of turning RMS into a ‘great man’ haven’t changed in decades.

This got me thinking about the values I apply to software development, governance, and distribution. I realized that they’re the same values I apply when searching for services to use, or starting a business: cooperative values. Naturally this would be called “cooperative software” or “cooperative technology”: software (or technology more generally) that roughly follows the principals of the 1995 “Statement on the Cooperative Identity”.

Finally, today, I became aware of an early draft of an essay titled “Towards A Communal Software Movement” and the authors decision to rename it “cooperative software”. Since others are thinking about this too, I wondered if we might all come together and try to better define what we mean when we use the term. To start, here is my small contribution.

Definition of Cooperative Technology

Cooperative technology is technology that is jointly-owned and democratically-controlled in accordance with cooperative principals.

If we are talking specifically about software I believe that this means that all Cooperative Software is FOSS, but not all FOSS is Cooperative.

For example, the Go programming language is Open Source Software (OSS) because it is released under a BSD style license and accepts contributions from the community. However, it is not Cooperative Software because it is not democratically controlled by members, instead decisions are made by Google employees. Similarly the Benevolent dictator for life (BDFL) model of governance used by Clojure and Linux means that these projects are not Cooperative Software.

Some projects use a meritocracy model that appears to be cooperative at first blush because it involves individuals working together to establish consensus. However, if only developers who showed a certain level of merit are allowed to govern the project, the users of the software, the designers, the technical writers, etc. become ineligible to participate. This violates the cooperative principle of voluntary and open membership.

Benefits of Cooperative Technology

Just like there are Worker Cooperatives and Consumer Cooperatives in the business world, Cooperative Technology provides a great deal of flexibility in governance while still ensuring equity. A cooperative business can survive in a capitalist market economy, but doesn’t re-enforce the inequities inherent in such a system. It also doesn’t require any major changes to adapt if it becomes a part of a more equitable system in the future.

Co-ops also help prevent the cult of personality that sometimes forms around individual founders because they strive to be inclusive. Even if a member does become a polarizing figure, their impact is limited due to the 1-person-1-vote principal.

Open Questions for Future Posts and Debate

If the software communicates over the network but uses a network protocol that is not documented (so other software cannot communicate with it without reverse engineering the protocol from the code and hoping it does not change and break them), can it still be Cooperative Technology? Likewise, are programming languages that have a reference implementation instead of a spec Cooperative if they meet the rest of the definition, or does this make it too difficult to create alternative implementations? Is this a violation of the “Concern for Community” principle, or the general value of solidarity?

What licenses are acceptable for Cooperative Software to use? These licenses presumably must guarantee user freedoms, but also not hurt or exclude users. Maybe any license is fine and Cooperative Software is more about governance, but I’d also argue that licenses with a viral component are incompatible because it reduces the ability to cooperate with other Cooperative Software using an incompatible license. Cooperatives realize that not everyone will agree on the exact way that the cooperative should be run and they seek to reach consensus, not legally force other groups to agree with them or self-segregate.

What types of cooperative governance map well to developing technology, and which ones make decision making too difficult? In non-cooperative software if every user feature request is honored we just get Jira: over complicated and nobody really knows what it’s for or how to use it. But in cooperative software if users must all come together to reach consensus, does this help them all distill their features and use cases down to the most fundamental form?

Once we begin to answer these questions, should there be a steward for the definition of Cooperative Technology in the vein of the Open Source Initiative (OSI) or the Free Software Foundation (FSF)?

If you’re interested in helping answer these questions, or in improving the definition of Co-op Technology, consider joining the co-op group chat: co-op@mellium.chat.