Unionize Free Software. Found Software Guilds

aschrijver · July 5, 2022, 6:04am

I want to follow up with some additional thoughts..

Be Unionizable

For Social Coding we are elaborating all the aspects from Inception to End-of-life of the Free Software Development Lifecycle (FSDL).

A healthy, sustainable FOSS project should have “being strong to withstand the forces that lead to exploitation” as a strategic objective, and follow Best-practices to make that so. While the unionization entails organizing as a collective each and every project can organize to:

Taking care to be least attractive for exploitation.
Preparing project organization to be easiest-to-unionize.

Being part of a union and benefit the most from that participation will impact project processes, and point 2) relates to those measures, even before a union is joined. It’ll help lower the barrier to join, and increase the effectiveness of the cooperation after joining.

In summary there is an indivual part to unionization, and that can be combined with the collaborative approach. And there is an equivalence in the business world. In some countries there’s by law the establishment of a Works Council (in Dutch: “Ondernemingsraad”). A union at company level, where a council of employees monitors the management decisions.

Translating to FOSS projects it would relate to people monitoring detrimental forces to the health and sustainability of the project.

“Let’s play and win our own game”

This was the title of an ActivityPub Conference 2020 talk by Darius Kazemi talking about strategies whereby the Fediverse would utilize their own strength. There’s some good advice in it. For instance around the 16 minute mark comparing what is “Easy to centralize” and what’s “Hard to centralize”:

It boils down to “Easy to centralize → Technical features, Hard to centralize → Social features”.

Decentralized unionization

In the discussion and feedback highlighted above there are concerns about the centralization, power and authority of the Union. This is a very sensitive and controversial subject on the Fediverse, and it always pops up in these kinds of discussions. A centralized non-profit would likely be rejected outright by a lot of FOSS projects, and many fedizens would communicate negatively on its existence.

But I believe this problem can be tackled, and that the unionization can be inherently decentralized while still be able to raise a collective fist. Going further on the “Be Unionizable” above, each project could be contributing to a larger organization structure, as decentralized ‘circles’.

I am thinking in particular of organizing along the lines of Sociocracy to make things governable but not centralized. We are holding meetings to define Sociocracy as building blocks on the Fediverse. I will add a reference to this topic as input for next meeting.

“Union” in the abstract

A union doesn’t have to be an organizational form that is similar to how we traditionally know them to be. The “Union” is more of an organizational pattern, and can be embedded / integrated into all different kinds of organization structures. It doesn’t have to be a non-profit / NGO called “FooBar FOSS Union” that is specialized on unionization tasks and to which FOSS projects apply for membership.

Another FSDL and Ecosystem Foundation pattern I recently created a placeholder topic for is the:

FSDL: Ecosystem Alliance

Summary: Strategic cooperation whereby different projects, groups or communities, while each operating independently, agree to collaborate and evolve an ecosystem collectively. They anticipate each other’s needs, align roadmaps, features, etc.

Well, an ecosystem alliance could just as well include a Union to defend it.

→ Proposal: Develop the Union as a pattern and building block that is part of the FSDL

Note that this would aligns very well with the principle that any FOSS project should be able to just pick & choose from the patterns and practices in the FSDL in the way that best fits their own preferences and needs. And this will provide them a range of options to implement unionization strategies. Here I will also cross-reference to FSDL: Open Strategy best-practice placeholder.

Incorporating the Union

In earlier discussion there’s mention about incorporation, e.g starting a non-profit. With my additional feedback of Decentralized Unions, Sociocracy, and Ecosystem Alliances it can be seen that there may be multiple different incorporations, either as non-profit or cooperatives, etc. Each with their own governance, but still part of a larger unionization force / movement.

Non-profit as interface to the biz world

I’d like to mention more on the notion that a non-profit is a centralized entity..

It doesn’t need to be that. The non-profit can be stripped of all tasks except for providing those services to allow it to interface to the traditional business world. So it can have a bank account to collect funds, so it can hire a lawyer to defend union interests, etc. It does the hiring and the funding, the bookkeeping, but the actual activities are not performed in the non-profit itself.

The non-profit may be part of a Non-Profit Venture, where the other part is a Cooperative with its members being FOSS projects and Communities. The Cooperative consumes the services that the Non-Profit buys / obtains.

Advice: Break down into FSDL Patterns

This is a large idea with many moving parts. I must urge anyone when elaborating on it to think about how it can be broken down into separate patterns of the FSDL and how they interact with other patterns already defined. (As a helper think of it like elaborating a software project into modular code).

Example: Licensing protection discussion

In Matrix chatroom this forum topic was discussed, and the interesting idea to use FOSS Licensing strategically to fend off exploitation. The Union here would be the guardian of licensing issues and act on a project’s behalf if some external party is in breach of the license clauses.

Licensing is a separate FSDL component. Licensing strategies are additional pick & choose patterns for a FOSS project to adopt. They encompass a world of expertise in itself.

So, I encourage anyone to think about the breakdown into constituent parts of the FSDL, and add a reply to this thread, but also a new topic when a different Best-practice pattern is discussed. And then create a cross-reference between those.

In this case one thing that was addressed is adoptiing non-free licenses that aren’t recognized by FSF and OSI as FOSS licenses. Still, there may be good reasons to adopt those. But this consideration comes with its own Pros and Cons. It is a pattern that must be separately documented.