@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.
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."""
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 [ . . . ]"""
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."""
@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.
A private instance for the Finkhäuser family.