Governance structure
Given some of the discussions last week, I've spent several hours trying to think around the future of our governance structure, and how to delegate and organize work. From that, you can find below multiple case-studies of organizations around us.
TL;DR: I've been very surprised by the very lean structures of both Arch and KDE, though that might be the fact that their docs are pretty slim, and therefore somehow hide the complexity of the organizations. I really, really like the good documentation and processes from Fedora.
Overall, some things that are different in the approaches and need some decision:
* Which bodies should we have?
* Which bodies should be elected?
* Which bodies can have membership ad-hoc?
And some things that are basically identical:
* There is a split between (they can be disjoint):
* Members of the project
* Developers with merge approval
* Officially elected bodies are often represented by "members"
## GNOME
* Foundation Members:
* Get access to infra (https://handbook.gnome.org/foundation/membership-benefits.html)
* Access to travel grants
* Vote for the Board
* "Developers"
* Anybody that maintains an app under https://gitlab.gnome.org/GNOME/
* Get merge access for the whole namespace
* Foundation Board:
* Top-most body
* Elected by the membership
* Governance and legal work
* Committees (https://handbook.gnome.org/foundation/committees.html)
* Appointed by the Board
* Got (some) processes and "legal" responsibilities delegated by the Board, e.g: "what is GNOME?"
* Teams
* Groups of people working together on a topic
* Ad-hoc, no processes, no official list
## Alpine
No legal entity
* Developers:
* Have merge access to aports
* Get access to infra
* Maintainers
* Get some control over their packages
* TSC
* In charge of technical decisions
* Fixed group of people
* Council
* In charge of governance decisions
* Fixed group of people
## Fedora
Very complicated and big structure, covers a lot of depth and breath. This is just a sneak peak. No legal entity, Red Hat takes all liability and legal work.
* Council (https://docs.fedoraproject.org/en-US/council/)
* Governance and strategic focus
* Complex selection process, with different representatives
* Engineering steering committee
* Technical decision making
* Voted by all contributors (people with merge access)
* Oversees other technical teams (packaging team)
* Fedora Mindshare committee
* Focus on community, events, outreach, recognition
* Has a lot of other groups under them
* Very interesting decision-making process: https://docs.fedoraproject.org/en-US/mindshare-committee/#decisions
## Arch Linux
No legal entity, fiscal host relationship with https://www.spi-inc.org/
* Project Leader
* Legal responsibility
* Untying decisions
* Elected by the other groups
* Developers
* Maintain core parts of the system
* Added by invitation: https://wiki.archlinux.org/title/Getting_involved#Becoming_an_Arch_Developer
* Package Maintainers (https://wiki.archlinux.org/title/Package_Maintainers)
* General package maintenance
* Self-nominated and appointed similarly to TCs: https://package-maintainer-bylaws.aur.archlinux.org
* Support Staff
* All other work: infra, wiki, moderation, etc.
* Teams: https://wiki.archlinux.org/title/Arch_Security_Team, https://wiki.archlinux.org/title/Arch_Testing_Team (maybe more, information is sparse)
* Specific task
* People join and leave ad-hoc
## KDE
German non-profit. Good example of user-facing project with good relationship between legal entity and community. https://community.kde.org/KDE_Culture might be something we want to write too. I don't think we want to have to do this though: https://ev.kde.org/reports/2025-de/
* Board (https://ev.kde.org/corporate/board/):
* Governance, legal responsibility
* Elected by members
* Members (https://ev.kde.org/members/)
* Vote on Board
* Propose themselves, get accepted in similar fashion to TCs
* Working groups (https://ev.kde.org/workinggroups/)
* In charge of specific tasks
* Some require AGM votes, some are ad-hoc
* Fascinating that the Community Working Group (CoC Team) has no rules for joining
issue