🧵 Thinking through how a co-operative software governance model could work (again), specifically for a large collection of projects or an Apache-like software foundation:


Each project (comprising one or more related software repos, issue trackers, and other resources) has a project leader and maintainers. Pretty standard stuff. Project leader may be semi-permanent or may be elected from time-to-time from the maintainers. Maintainers can code review and merge, project leader is ultimately responsible for ensuring timely communications and merges, representing the project to the board, etc.

Outside of projects there are "guilds" (is there some better more easily understood name for this? Maybe it's just a committee.) that are groups that operate on many projects. Eg. the UX guild might be responsible for making recommendations and improving the UX for all projects managed by the co-op. They also have leaders and each may handle their own affairs, elections, decision making, etc. separately from the others.

There is also a board of directors. If required they create any legal positions required by law wherever the co-op is incorporated (if it is incorporated), eg. treasurer or president. They also manage the co-ops funds and create requirements/accept projects into the co-op. The board is comprised of all project and guild leaders (this way non-technical contributions are valued, eg. the documentation guild can have a tech writer on the board).

Non-leaders may also be elected to the board. This allows for a Member-At-Large type position to encourage new members to get involved more, or someone who's been a valueable member but can't dedicate the time to a full leadership position to still serve on the board and help out.

Exactly how elections or appointments work is up to the individual co-op, that will be different for different groups. I'm mostly just trying to figure out roughly how things could be organized to avoid some of the problems with meritocracy style approaches that prize developers above everyone else.

@flancian I *really* dislike it when people make up words for things like this, it always feels vaguely corporate-speak to me, or like it's just intentionally confusing, but maybe that's just me? Maybe it's just re-using existing words that I don't like, I'm really not sure. But also I can't think of an existing term that applies or anything better, or even reasonably define why it bugs me so…

@sam interesting! I guess I like RPG-like terms so I don't mind. Of course there's also "working group".

But generally I think as long as we're talking about groups ideally each group can self-name and optionally follow a naming scheme.

@sam so perhaps you could have a UX guild and a backend squad and it shouldn't matter.

@flancian probably still want a word to refer to "any cross project group". Maybe projects and cross project things are all just " teams", I dunno why I differenti

@beckett I haven't heard of this, but it does sound vaguely similar (except I was thinking that each "circle" as they call it could do whatever it wants in terms of consensus building, voting, etc.), I'll have to read up on it. Thanks!

@sam @beckett I heartily recommend the sociocracy book "We The People" for inspiring documentation on this sort of bidirectional decision structure. (The consensus aspect is central to their philosophy of voluntary participation, but tangential to the structural aspect of circles.)

@sam I vigorously recommend the book Many Voices One Song from Sociocracy For All. It’s the new buble for understanding and implementing Sociocracy.



Sign in to participate in the conversation

A Fediverse instance for people interested in cooperative and collective projects.