[Encode] Discussing "Cooperative Software"

[florimondmanca]

This is a general "discussion" about Encode, not just HTTPX. Hacking this discussion board for that purpose. :-)

Just stumbled upon this Twitter thread expanding on the idea of "Cooperative Software", or "coop source" instead of "open source":

https://twitter.com/zkat__/status/1412478492185305090

The discussion stems from the observation that open source software has been practiced in an asymetric way. Basically: any user can use the software, but also participate (interfere?) in decision-making, via issues, bug reports, spontaneous PRs, etc.

I believe at Encode we know how this can result in an increased burden on maintainers and contributors, and induce difficulties over the long term. Keeping scope in check and reducing the maintenance burden has been a major source of concern and action, especially given the expansion and usage of Encode projects (DRF, HTTPX, Starlette, Uvicorn).

So, Cooperative Software, or "coop source" (instead of "open source"). It doesn't seem formalized at all yet, but as I understand it, coop source would be an attempt to reduce the asymetry and improve both long-term project health and sustainability, as well as maintainer well-being. It doesn't use methods or practices that are fundamentally new, but as I understand it it's more of a packaging / naming / formalization effort, as happened for free software and OSS.

The main difference from open source would be a departure from the permissive licensing model, in the sense that users would only be able to participate in decision-making after having passed some kind of barrier, most likely in the form of becoming a member of the cooperative. The Twitter thread suggests making this "user membership" paid, but I wonder if free membership could also be viable. I assume the mere fact of requiring users to apply for membership to intervene in decision-making could already improve the user/maintainer balance.

Existing examples I know of that sort-of approach this would be:

• The Trio organization. Welcomes users to become a member after a merged PR. No clear "members of the org own everything" though.
• The Jazzband initiative. Manages 50+ projects, mainly for Python and Django. Requires membership application, clear "collective ownership" messaging ("we are all part of this"), guidelines for member projects. Coding is collaborative, but decision-making still seems very much open, without restrictions on users.
• The Collective org, which backs Plone add-ons.

That said, none of these examples follow the "add barrier to entering decision-making as a user" principle, which seems to be the main feat. In "physical" coops (say, a farmer coop, or a transportation coop, or whatever), users can't just come and interfere, they need to become a member (which is most often paid, like when becoming a member of an NGO or non-profit), and contribute in some way to have a say in decision-making.

Honestly though, I'm not even sure that such a barrier would be a good idea or work out well. I also don't know exactly if and how this could apply to Encode. The organization works much like an OSS business, with Tom relying on it for a living. But maybe on top of that, thinking about a more formalized membership program could be interesting. First for contributors (following the lines of Jazzband), then perhaps for users (individual or, more interestingly, corporate).

There's also a fine print around the "paid membership" idea in particular. Eg, once a user starts contributing code, should they be freed of paying for membership? Perhaps so. But after what amount of contribution, or based on what other criteria? Many practical details to figure out.

Even then, how does restricted decision-making intervention play with the notion of "issues" / "tickets"? I assume it could turn out well enough, but how? We've already been moving to a "discussions first; issues by contributors afterwards" model over here. Membership would allow users to participate in the process of escalating discussions to issues, but it is certainly unclear how that would happen in practice, and whether this would be practical for all project sizes. In all cases, existing GitHub tooling seems largely inadequate, but that is most likely normal and okay, since GitHub is aimed at OSS and "as low as possible a barrier to entry for users/contributors to share decision-making", which coop would want to depart from.

Any case, I thought that was an interesting line of thought and organizational research to share. :-)