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.
Getting People to Play
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.
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.
Pillars to Work On
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.
There is a previous issue on the topic but it never truly moved anywhere. I and @barthalion were the only two even interested in it, but feel free to pick it back up.
Something like “kubernetes’ values.md” is weird though, because it reads like an ice-cream koan. Sounds all very meaningful, but it does nothing in terms of governance or process-guidance. It’s the kind of stuff that marketing comes with. The FWUPD Technical Charter is on the other hand excellent, with clear guides and processes. I would prefer that over ‘values.md’ every day.
My primary question would be in relation to third-parties; Packaging some GPL application to rip CD’s or play games is one thing, but how are we going to engage with Slack, Discord, Steam and similar, in an attempt to get them to cooperate?
All the criticisms of Snap aside, Canonical has a long history of engaging and supporting their commercial partners and we are fighting an uphill battle there. The battle amongst the Linux enthusiasts has been won, and you can clearly see the zeitgeist change in favour of Flatpaks, but we will need to grease some palms.
Second important question; how much community vs engineering? I never had strong community-feelings to the people here at Flathub. Mind you, I like contributing and I respect my fellow contributors, but we don’t engage much with each other. Every package is it’s own thing after all.
Interesting. I’m the exact opposite. I prefer values over detailed processes and documents that need continuous updating. The values however works and guidelines for many things over a long period of time. Being a bit parcial as an agile practitioner, but the https://agilemanifesto.org/ is still relevant and very much in use 20 years later.
The “right” answer is actually both - we need clear processes where we know there will be common needs and steps to follow, and we need clear values to guide our decisions when we’re exploring new areas. The purpose of a published and transparent governance model is that when people make decisions about whether they should engage with the Flathub project (including relying on our service, contributing to our community, etc) they need a way to understand what will happen when they try and do certain things.
For common occurences, clearly documented processes are the most specific and easy to understand way to do this - we accept these apps/licenses/whatever, you must include this icon, you send it here, push this button, someone will do XYZ, and your app gets published.
For less common or new occurrences, we can’t write a process for everything, so instead we need to give people ways to reason about our priorities and values, so they can make a reasonable prediction about how we might respond, and gain confidence that reaching out is worth doing even though we don’t have a process in place for what they’re asking about. For this you need a values document because sharing your priorities in decision-making helps people feel confident about putting in the effort to engage with our community.
Part of our interest in making the governance behind Flathub more formal / explicit is so that we can set out clear goals and non-goals for what we’re doing as a project and our roadmap, and start to approach commercial sponsors and potential vendors to gain their support. If we gain some backers and more resources it will make it easier to do this kind of developer engagement and support.
There are (at least) two concentric circles here - there is a small group of individuals (particularly the reviewers and the admins) who shoulder the majority of the effort of running Flathub itself as the service which every app maintainer relies on, and there is the larger group of individuals who are responsible for contributing apps (either their own or on behalf of others). The goal of Flathub is not to be a distro and have a big community of packagers who go out and Flatpak all the things - it’s to be a low-friction way for app developers to reach users. But with some more effective planning and communication we can grow community collaboration amongst those individuals with experience building/packaging/etc, and achieve goals like reviewing/updating/testing apps with old dependencies, tightening up permissions, etc, which can help individual app maintainers, and improve the overall quality of Flathub for users.
I’ve started doing some of this and have had some interest from some of the larger ISVs that support Linux, but in order for us to engage meaningfully we need to have the structures in place, which is why we’re doing this stuff first. I think Rob answered your other questions better than I can.
