Can TYPO3 afford its new governance?

But meetings have this annoying habit of requiring people.

Assume every Unit Council meeting lasts exactly one hour and only the minimum quorum of three people attends. That alone is 216 person-hours per year. Add the Cooperation Panel at minimum quorum and we reach 236 hours.

That still excludes preparation, follow-up, reports, elections and any other kind of additional coordination. Just people sitting in the recurring meetings suggested by the rules.

Obviously, 236 hours will not kill TYPO3. It is simply an interesting lower edge for a structure intended to reduce administrative work for volunteers, and this is where the history of the proposal becomes relevant.

In the earlier governance proposal that preceded the current review, the authors explicitly explained that they had not invented the underlying approach from scratch. The preface said the rules were “largely derived from regulations that the German Red Cross has developed and tested over more than 150 years.”

I can understand the appeal. Why invent governance from scratch when another nonprofit organization has spent more than a century learning how to organize volunteers?

There is just one fairly important detail: TYPO3 is not the German Red Cross. The similarity is that both involve nonprofit structures and volunteers. After that, things become rather different.

The DRK operates emergency services, disaster response, welfare services, hospitals, care facilities and a huge organizational infrastructure. It has more than 470,000 volunteers, more than 217,000 paid employees and around 2.5 million supporting members.

The TYPO3 Association, in comparison, has roughly 1,100 members. In total.

The 217,000 paid employees are the part I find particularly interesting. They give the DRK an enormous professional organization behind its volunteer structures. Councils, reporting lines, administration, coordination and formal responsibilities can be supported by people whose actual job is to make the organization work.

TYPO3 does not have anything remotely comparable to that workforce.

Yes, TYPO3 companies give employees paid contribution time. That is valuable and the project depends on it. But an agency paying a developer to spend some working hours on TYPO3 does not create the equivalent of a professional administrative organization. In most cases that developer still has exactly the same limited hours available for code, documentation, reviews, support and governance.

This matters when we talk about established organizational patterns.

A pattern can be perfectly proven and still be wrong for another system. Its assumptions have to survive the transfer. Otherwise we are doing the organizational equivalent of discovering a very successful enterprise architecture and deploying it on a Raspberry Pi because both are computers.

The DRK comparison therefore does not reassure me. It makes the capacity question even more important, quite apart from another problem we have discussed before: Parts of the DRK framework come from an environment where formal instructions, chains of command and even obedience are legitimate organizational concepts.

So what exactly are we transferring from an organization with hundreds of thousands of paid employees into an Open Source project that depends heavily on volunteer time? Which parts still make sense when the administrative workforce disappears? Which parts become overhead that the contributors themselves have to absorb?

That overhead is the governance tax. Every organization pays one, and some of it is necessary. Decisions need owners, money needs accountability and conflicts occasionally need someone to resolve them. TYPO3 certainly has governance problems worth fixing.

The problem is that administrative capacity and productive capacity often come from the same people. Someone spending an evening on a quarterly report may also be the person reviewing a Core patch. Someone documenting governance decisions might otherwise maintain an extension, improve accessibility or help another contributor.

The proposal itself appears to recognize this. Its FAQ says that some form of compensation for Unit Coordinators will be necessary, and compensation for the Panel Chair is considered likely as well.

Which raises a fairly obvious question. How much, and at what rates?

There is another consequence when the available capacity is smaller than the structure requires. The proposed rules explicitly allow people to hold roles in several Units. That may well become necessary if there are not enough people to fill them all, and then the system starts feeding itself.

The reliable people collect several roles. Responsibility, knowledge and authority accumulate around them. Their workload increases. Somebody eventually steps back. The remaining pool gets smaller, so the remaining people collect even more responsibility.

Keep that going for long enough and you have what I would politely call a bureaucratic death spiral. No evil mastermind is required. Everybody involved can have excellent intentions. A structure that requires more organizational capacity than the community can provide will still concentrate responsibility because somebody has to keep it running.

That is why I think this proposal needs a capacity calculation.

How much administrative work do we have today? Which parts disappear? How much does the new structure add? How many people and hours do we realistically expect to need, and which of those hours will actually be funded?

Maybe the calculation shows that everything is fine. Maybe parts of the structure need to become lighter or some roles need proper funding. Both would be useful results. What I have not seen so far is the calculation that turns “less administrative work for volunteers” from a goal into a plausible outcome.

The proposals are still under public review until 6 September 2026. Most people affected by them will probably never read two long GitHub pull requests and the discussion underneath, which is precisely why I think this deserves a wider conversation. Have a look at those proposals and make up your own mind while the review is still open.

Official call for review:
https://news.typo3.com/article/review-the-proposed-rules-for-typo3-units-and-the-unit-cooperation-panel

Rules for TYPO3 Units, PR #49:
https://github.com/TYPO3-Documentation/Policy/pull/49

Rules for the Unit Cooperation Panel, PR #50:
https://github.com/TYPO3-Documentation/Policy/pull/50