We’ve created github.com/flathub/governance with the intent of having a more formal governance structure in place.
In my intro thread I hinted on what we’re looking at and would like to outline some thoughts I’ve had on how to proceed. Full disclosure: I will be unaffiliated when working on this with no ties to an individual organization other than Flathub itself.
There are lots of parties which I would consider stakeholders in the project. We’ve got the contributors, end users, distributions, independent app developers, and then any sort of venn diagram combination of all those folks. In my experience a solid neutral governance helps ensure everyone has a level playing field and gives people the confidence to work with us and have a level of trust they they expect.
As I hinted at previously, LVFS’s charter might be a good place to start: https://gitlab.com/fwupd/lvfs-website/raw/master/docs/technical-charter.pdf
We also have the collective expertise of GNOME/KDE/Endless non-profits, so we’re not starting from scratch. I have first hand experience working on the Kubernetes governance and lots of cloud-native projects have followed with similar structure, and I think this “style” that is cleanly documented will help alay fears on the trustworthiness aspect. It’s by no means perfect but it’s not a bad place to start, and as a bonus many of the ISVs that we’d like to engage with already have vetted these governance structures and have their contributors participate, so common values there is probably a good thing.
- Code of Conduct - nobrainer, this is table stakes.
- Affiliation neutrality - we want organizations to participate in flathub, but they need to be who they are. The governance structure should ensure that organizations are represented and you don’t end up in a situation where the governing body is dominated by one group, so we just codify to keep things neutral.
- Open documented governance processes - stuff like this, open discussion, with the documents in git being the single source of truth.
- A values document that captures the “vibe” we want. Here’s Kubernetes’ values.md as an example.
Additionally we probably want to codify how we interact with these organizations, distros, users, and app developers. For example, if you’re using flathub on KDE it should feel like KDE. If you’re using flathub on GNOME it should feel like GNOME. And however your distro integrates it.
We make the infrastructure but we also ensure we’re not alienating groups from using the technology, so we’ll codify it. I don’t think we’re at a spot where we need to figure out elections and turnover and whatnot, but there’s lots of OSS projects that have done this already so probably more of a mid-term goal.
Thoughts and ideas?