How's this for a first draft?

0. The project uses a free software and open source license (approved by both of the FSF and the OSI)

This gives users the formal freedom to adapt and share the software without repercussions.
1. All contributors to the project are afforded the same rights: The same license is used for contributions as for distributing the software to the general public, and only that license.

This gives all members of the community the same formal opportunity to monetize the project, no one participant has the sole opportunity to e.g. sell exceptions.
2. There are documented rules for who controls the project's shared resources, and a documented process for how any contributor might gain nonexclusive control over those resources.

This one needs good lawyering to be both shorter and better. No community member should have the leverage to strongarm the community by taking the project's toys and leaving. Basically there's always a "project core team" and any contributor that doesn't harm the project should have some chance to be on it.
3. There is a documented process for reporting exclusionary and abusive behavior, and the community has rules for who can be excluded from the community for bringing harm to the community or a community member.

Not everyone is going to like this one, as they worry about abuse of the policy. I think it's important, and I think any policy can be abused if you put it in the hands of the wrong people, so ... don't.
4. The project has documented standards that allow end users to control their data.

See e.g. the Franklin Street Statement. This empowers end users to leave to avoid abuse from admin users.
5. The project has documented standards that promote admin usability in terms of installation, backups, restores and upgrades.

This safeguards practical user freedom. If the upstream deviates from the path the person running the software should be easily able to switch to a fork, allowing admins to leave to avoid abuse from developers.
6. The project has documented standards for software craftsmanship and developer experience, including e.g. code standards enforced by a combination of automated and manual processes.

This safeguards practical developer freedom, by making the project understandable and easily modifiable.
My intention with the ordering of these criteria is that each level builds on and enforces the level before it and has little value unless the level before it is fulfilled.

There are too many levels and they all need rethinking and rephrasing.
2 and 3 should probably be switched. There is no point if there is a process for being a core contributor if you've already been discriminated against.

@clacke I like that list very much. I'm going to have a think about it. Something like that makes sense to me.

There's another effort going on with something comparable here:

I like the ordered list approach very much, though. But the communal aspect is what I like about that other document, because it also encompasses things that do not really have to do with the code or project governance, but the wider community.

· · Web · 1 · 0 · 0
@jens """

Communal electronic medical record systems should not be designed for the interests of insurance companies or hospital administrators, but for the interests of patients and the clinicians who directly use it.


Oh wow, I failed to remember the people who aren't even running or interacting with the software.

The purpose of this document is not to proclaim a legalistic set of criteria for determining what software is communal software and what software is not. History has demonstrated that this is not an effective political tactic [ . . . ]


Ouch! I need some cream on that burn.


Moreover, we believe it is counterproductive to have a small self-appointed group of privileged men determine what our movement's terminology, goals, and tactics are.


I'm such a devbro, even when I try to do the opposite.

This document gets everything right, all the way to and including the rejection of copyright licenses as the right tool for safeguarding the ethical use of software.
... all the way to and including the free culture license for the document rather than the nonderivs license of the core philosophical works of free software.

@clacke Some of the critiques I've gotten about the "Towards A Communal Software Movement" essay are that it doesn't make it clear what exactly communal/cooperative software is. So I think your ideas of enumerating some criteria is helpful. However, I still think that treating them as legalistic rules to make a binary judgement whether a project is cooperative or not would be missing the point.

@clacke Instead, let's clarify principles and treat the criteria as best practice guidelines instead of commandments brought down from the MIT AI Lab.

@clacke This approach leaves room for the criteria to evolve over time as technology, the movement, and the world around us changes.

Sign in to participate in the conversation
Finkhäuser Social

A private instance for the Finkhäuser family.