Do any moots know someone who we might be able to consult about restructuring a mid-size FOSS project? Essentially to migrate from a BDFL model to a more flat-structured democratic organisation.

We are discussing how to restructure #postmarketOS so that it can continue to scale up and be a truly community-run project.

We have some idea of how co-ops like Igalia do this, but we have a lot of differences (like being largely volunteer run and having very different goals) which leave us with a lot of unknowns.

To give an example of the kind of structure we're thinking of (by no means final, there hasn't been any broad agreement on a new structure yet):

We have the relevant pieces in place to form an assembly (everyone listed on https://postmarketos.org/team/ ) which could then democratically form teams and delegate responsibilities to them (e.g. finance/budget, technical policy-making, maintainers for various OS components).

The assembly would then also be responsible for deciding on focus areas and long term goals for the project (e.g. improving reliability, building a production-ready immutable version of the distro)

We could then form working groups to enable cross-team collaboration to move towards our specific goals.

Currently we lack a lot of understanding of the potential implications of something like this, how we can ensure the project doesn't get hijacked, that we don't drift too far from our mission statement, etc etc...

If you have a background in sociology and/or relevant experience from other projects then I would love to reach out and be able to discuss this in more detail!

#decentralization #opensource #freesoftware #foss

postmarketOS // Who makes postmarketOS?

Aiming for a 10 year life-cycle for smartphones

postmarketOS

@cas I think the challenge is only people motivated to do particular work, are in the running to do that work.

Certainly how you're structured can get in the way of stuff getting done. But a project structure itself won't bring into being motivated people to write and debug code, ensure that current code works well on old, ignored platforms etc.

In a company, where you pay, you can command it (+/- people leaving) but in FOSS contribution usually only lasts so long as it feels fulfilling.

@hopeless yep that we are volunteer run is definitely an important factor to consider. Our model should take into account trust that people are willing and capable to follow through and do the work without being paid. That being said, this is hardly new territory, many projects including postmarketOS only got to where they are through the dedication and work done by volunteers, so it's not something I'm inherently concerned about.

Of course introducing complicated processes and overhead in order to be able to get involved and do the work is something that can push people away, and definitely something we want to be conscious of.

We already have motivated people and project-wide goals that we all work towards. Changing the structure doesn't mean broadening the scope or expecting to be able to get more done or move faster, rather it's a reaction to the growth of the project up to this point and dealing with the bottlenecks and power dynamics we have today that make it harder to scale up and increasingly drift from our mission statement.

Specifically: the core contributors today have ultimate power over the project, they are unelected, have no term limit, and can only be removed by unanimous vote from rest of the core contributors. This model makes sense for a small project with a dedicated team but the decision making process can't really be scaled beyond ~7 or so people without significant delay.

We also may not properly represent our community, and as we hope to expand postmarketOS and build a true competitor to Android and iOS we need to ensure that our community are empowered to keep the project aligned with its core goals.

Sorry for the ramble, I have a lot of thoughts on this topic so it's useful to get an outside perspective and have to justify them.

In case you're unfamiliar, our current governance structure is documented here https://docs.postmarketos.org/policies-and-processes/governance/groups-and-teams.html

Groups and Teams - Policies and Processes