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'm curious how many external contributors you already have / how consistent they are?
@cthoyt i don't have the stats on hand (in general i don't think we dig too deep into the gitlab stats although it would be useful!) but i think we're in the low triple digits generally, we work closely with our upstreams so a lot of folks in our community may not actually be contributing code directly but rather working on gnome/kde/etc

@cas I guess the question is what percentage of those would be interested in taking up more responsibility. I can imagine that's a big ask for a community that's also busy with their own things, and until now were happy that your component in their ecosystem was taken care of

just for context, I am thinking about similar things, but for much smaller academic projects with a smaller pool of more busy people 🙃

@cthoyt that is a question, but the goal here isn't to grow explicitly, rather to develop a structure that will make it easier to onboard people and grow in the future. We don't want to introduce a bunch of additional process overhead or be in a position where we depend on people stepping up, but if/when they do we wanna be ready

similarly we want to be ready to more officially compete with Android and iOS when the time comes, hence investing in relevant tech