GovernanceResearch¶

Introduction¶

The Replicant project sometimes needs to take decisions. The decisions are currently taken by the steering commitee.

It would be better if this is made more horizontal:

• It would remove the single points of failure
• The decisions would be better and less horizontal
• Potential individual bias could be smoothed out by having more people taking decisions.

Challenges¶

The main issues with a more horizontal governance in Replicant are:

• To ensure that the decisions being taken are informed decisions
• The Replicant project doesn't become a nonfree distribution

Examples¶

Project governance can work in completely horizontal way, however to do that projects typically need to implement some rules¹.

Examples:

• Some free software projects require to follow meetings or pay a membership to be able to vote. The goal behind that is to avoid taking uninformed decisions.
• Events organization projects do manage to take very well informed decisions in a very efficient and fast way².

Good practices¶

Explain any project decision¶

The decision we take impact the whole Replicant community and potentially beyond as well. So it's a good practice to explain why a decision was taken.

For instance if we decide not to support devices with non-replaceable battery we need to explain the rationale behind that very clearly, this way people can understand the rationale and challenge it if necessary. For instance the Minimal-requirements explain why this choice was made.

Not doing that could be very violent for people directly affected by the decision, as they would probably feel that the decision is imposed on them in an arbitrary way, when in reality the Replicant had to do it for the reasons stated (which can be challenged).

It's also a good practice to add the rationale with the decision as people are sure not to miss it and understand the decision better.

Having ways to publicly review and/or challenge decisions.¶

Since we took the decision on not supporting devices with non-replaceable battery we explained the decision at several occasions, such as the report from the Replicant conference in Paris, the FOSDEM BoF meetings, on the mailing list, on the IRC. If we had found interesting argumentation challenging that decisions we would have been forced to take it into account and document it.

For instance, if many new smartphones with non-replaceable batteries are added in Linux (that situation may or may not reflect the reality), we could add: "Complete support for many new smartphones were added in Linux and could work in Replicant if we support devices with non-replaceable battery, however despite that we still decided not to support them due to the increased difficulty to support them for a long time, as we expect to support devices for years after they started shipping."

In a case like that, we could also encourage interested people to fork Replicant to collectively maintain them for as long as possible, and see how well it worked for them, and see if their experience in doing that could be taken back into account in such policy to potentially change it. In a case like that it could also depend if maintainers could all be willing to work on and/or use devices with non-replaceable batteries as well.

References¶

¹ https://en.wikipedia.org/wiki/Elinor_Ostrom
fn2. https://media.ccc.de/v/Camp2019-10204-participatory_art_event_tools_co-creation_and_silk_road_networks