Every open source project eventually faces the same danger: becoming so busy managing itself that it forgets how to move forward. The challenge is not avoiding structure altogether, but finding the smallest amount of process needed to keep a project healthy without suffocating the people who make it possible.
When Process Becomes the Product
Open source projects love process.
At first, they resist it. Then they add just enough structure to survive. Then someone suggests a committee. Then another committee to oversee the first committee. Before long, a volunteer project starts behaving like a badly managed local council.
That is where the idea of Minimum Viable Bureaucracy (MVB) matters.
Not no bureaucracy. Not chaos. Not "everyone does whatever they want." But the absolute minimum amount of structure required for a project to function, make decisions, resolve disputes, and move forward.
Bureaucracy is like salt. A little improves everything. Too much ruins the meal.
The goal is simple: reduce friction, reduce decision latency, and keep contributors focused on creating value instead of navigating systems.
Volunteers Are Not Employees
For a project like Joomla, this is not theoretical. It is essential.
Joomla is not a corporation. Its contributors are volunteers. They are not paid to sit through meetings, fill in forms, wait for approvals, or decode internal political structures. Every layer of unnecessary bureaucracy drains energy from the people actually building and maintaining the project.
And volunteers do not complain the way employees do.
Employees argue. Volunteers disappear.
That distinction matters.
One of the biggest mistakes mature open source projects can make is assuming that adding process automatically creates stability. Sometimes it creates the opposite. Every additional rule, approval path, reporting requirement, or governance layer increases the cost of participation.
At first, nobody notices. Then contributors stop volunteering for leadership roles. Teams struggle to recruit help. Decisions take months instead of days. Eventually the project becomes incredibly well governed and almost impossible to move.
A project can literally bureaucratise itself into irrelevance.
Governance vs Bureaucracy
This is why Minimum Viable Bureaucracy matters. It forces projects to ask uncomfortable questions:
- Do we actually need this committee?
- Does this process solve a real problem?
- Could this decision be made by the people doing the work?
- Are we creating governance because it is useful, or because it makes us feel organised?
Those are not questions encouraging anarchy. Good governance is essential in open source. Projects need clear responsibilities, transparent decision making, and documented roles.
But governance and bureaucracy are not the same thing.
- Governance is clarity.
- Bureaucracy is overhead.
Healthy projects understand the difference.
The best governance models focus on enabling contributors instead of controlling them. Open source operates very differently from traditional organisations. In a company, bureaucracy is often tolerated because salaries compensate for friction.
In open source, friction is fatal.
Institutional Gravity
Every unnecessary process competes with family time, paid work, sleep, and mental bandwidth. Contributors constantly evaluate whether participating is still worth the effort. If the path between "I want to help" and "I successfully contributed" becomes too complicated, people simply stop trying.
For mature projects like Joomla, institutional layers accumulate naturally over time. Teams are formed to solve immediate problems. Policies appear after incidents. Approval structures emerge to prevent mistakes. Individually, each decision makes sense.
Over time, however, these layers stop being reviewed. What once solved a real need becomes permanent infrastructure by default.
A committee might have been created to address a specific issue at a specific point in time. That is healthy. The problem is not its creation, but the assumption that it must exist indefinitely.
Projects are usually very good at creating structures and very bad at removing them.
Instead of being formally closed when their purpose has passed, committees and processes are often left dormant and kept "just in case." But dormant structures are not neutral. They still create weight. They complicate governance maps, obscure accountability, and increase cognitive load for anyone trying to understand how the project actually works.
Minimum Viable Bureaucracy requires the discipline to retire what is no longer needed. If a structure no longer has a clear role, active work, or measurable value, it should be dissolved gracefully rather than preserved as institutional archaeology.
Left unchecked, this accumulation creates drag. Layer upon layer of historical process builds up because each one was once justified. Eventually, maintaining governance can become almost as heavy as building the software itself.
That is the danger.
What Can We Stop Doing?
Minimum Viable Bureaucracy is not about removing accountability. It is about continuously pruning organisational weight. It means designing systems that are proportional to the reality of the project today, not the reality of ten years ago.
Sometimes the most valuable governance question is not "what should we add?"
It is "what can we stop doing?"
Removing a process or committee can feel risky because they were introduced to solve a genuine problem. But projects rarely revisit whether that problem still exists or whether the solution has become more burdensome than the issue it was meant to fix.
The New Contributor Test
This becomes even more important when projects want to attract new contributors. Newcomers do not experience governance as theory. They experience it as friction.
- Can they understand how decisions are made?
- Can they identify who is responsible?
- Can they contribute without needing a map, a mentor, and three permissions?
If the answer is no, then the project has a bureaucracy problem, even if the intentions behind it were good.
Open source thrives when responsibility is distributed, authority is clear, and contributors are trusted. Overly complicated structures create bottlenecks and contributor fatigue.
That does not mean every decision should be democratic. Projects do not need a vote on everything. Trusted maintainers, delegated authority, and rough consensus are often more effective. What matters is not whether every contributor votes. What matters is whether the system remains understandable, responsive, and fair enough that people still want to participate.
Process Should Serve the Project
That is the real metric.
- Not how many policies exist.
- Not how many committees meet.
- Not how formal the process looks.
The real metric is whether the project still enables people to do meaningful work without drowning them in administration.
Minimum Viable Bureaucracy is ultimately about remembering why the structure exists in the first place.
The process is supposed to serve the project.
The project should never become a servant to the process.
