TYPO3 already has strong leadership and strategy. What I want to bring to the board is the builder’s perspective.
This is a companion discussion topic for the original entry at https://voting.typo3.org/elections/2026/jo-hasenau
This is a companion discussion topic for the original entry at https://voting.typo3.org/elections/2026/jo-hasenau
Hi everyone,
now that my candidacy is finally online, I’d like to use this thread for real discussion, not just campaign copy.
My focus is on the builder’s perspective: Less friction, more interoperability, and contribution structures that people can actually live with.
So here’s my question:
What currently makes TYPO3 harder to build with, contribute to, or work with than it should be?
Technical friction, process friction, community friction - all of it counts.
I’ll also be at Web Camp Venlo from March 12 to 14, so if you want to discuss this face to face, just grab me there.
As a contributor to the TYPO3 source code, I am looking to have a team of motivated people who all want to steer into the “right direction”. They might have different oppinions, and different focus. But there’s a chance we can all learn from another, improve ourselves and the product.
I want to have an open community, in which I can respectfully disagree with proposals, but also receive constructive criticism to my approach, so that in the end the road can be shaped together. I want a room to ask questions, to get feedback to my questions, and to have the time to not only work on my own agenda, but empower others to proceed with theirs. No matter if those people are “core contributors” or “one-off contributors”.
This gets really hard, when only few people actively work on the product, if there’s no “breathing room” to properly discuss issues, to face social challenges or to align each other on scope and methodology.
In a time where LLM-powered systems enable people to vibe code virtually everything, and scratch their own itch and not even care about other people or sustainability, I wonder how we can bring motivated people into our “product development cellar”. It requires constant effort, personal knowledge growth, communication and the ability to “work with humans”. In short: It’s an unpaid full-time job, and it has little to no appreciation. Often, whatever you do, someone is offended. Either you’re too slow, too unfocussed, too uninterested or too eager.
So in a fast-moving time like ours, how could we even motivate fresh people to actually move development forward - and ideally, not just drive it will full LLM-force into an unmaintainable heap of code?
Then, on the other side, there’s product pressure inside the industry and the wonder, if a CMS is even needed any more today. And an ecosystem full of investments, a GSB-force, agencies and marketing - wanting to have “structure” and the product development speed of a closed-source startup, where few entities drive decisions.
What would you say to someone like me, who’s on the verge of just giving up?
1 Like
Thank you for your openness. And I think we need to be far more honest about what is actually broken.
There is an old Open Source lesson from The Cathedral and the Bazaar: You need enough structure to protect quality, but enough openness that people can actually show up, contribute, and make workable deals.
What worries me is that TYPO3 currently has too much cathedral and too little bazaar.
The Association was never meant to turn volunteers into a managed workforce. At the time, it was founded to keep the backs of core developers free, so they could focus on the one thing the whole ecosystem depends on: Moving the Core forward.
That is also why the Government Site Builder matters here. If public money is used because Open Source is supposed to create public value, then “public money for public code” cannot just be a nice slogan.
It is a two-part promise. First, the money must actually reach the people doing the relevant work on the Core. Second, if funded work on the Core has been contracted, paid for, and delivered to the agreed standards, it must have a reliable path into the Core. Otherwise, public money does not produce public code. It produces distrust.
And we already proved that a better model can work over a decade ago. With Gridelements 2.0, paid and unpaid contributors worked side by side on a clearly defined goal. Some billed their time. Others chose to sponsor their effort. That did not weaken Open Source. It made contribution possible and enabled people to share.
Right now, TYPO3 too often looks like two competing cathedrals. One around merge authority and veto power. The other around money, priorities, and strategic pressure. If those two keep blocking each other, the result is predictable: Volunteers get treated as cheap labour, funded work gets stuck in uncertainty, and both paid and unpaid contributors lose the will to bother.
So what would I say to someone like you who is close to giving up?
I would say this: If you feel that way, I do not think the problem is you. I think the problem is a system that puts too much weight on too few people for too long.
LLMs do not change that. They may make it easier to produce code, and they may even make CMS products look replaceable. But they do not make it easier to build a sustainable Core together. If anything, they make review, trust, maintainability, and a credible contribution model even more important.
And if we want people like you to stay, we have to put the freedom of the bazaar back at the centre of TYPO3, not cheapness, and not overregulation. Volunteers need room to contribute without being managed into unpaid delivery. Funded contributors need a reliable path for contracted work into the Core. And both the Association and the Core team must enable contribution, not suffocate it with process.
Because in the end, Open Source is not about getting work for free. It is about creating the freedom to build. TYPO3 used to understand that much better than it does right now.
And in a time when AI makes many people question whether CMS products are still needed at all, that matters even more. If TYPO3 wants to remain relevant, it must stop exhausting the people who still know how to build the Core sustainably.
If we can get back to that, people may still want to build.
If we do not, we should not be surprised when the ones who still care walk away.
Hello Jo,
serving on the TYPO3 Association Board is a significant responsibility and an important volunteer commitment to the community.
Based on my experience, I estimate that fulfilling the role properly requires roughly 8 hours per week on average, including preparation, meetings, coordination with the Association and the community. In addition, there may be travel for events such as QSA meetings and other in-person gatherings.
Since this is a volunteer position without proper financial compensation, it requires a strong personal commitment of time.
How do you plan to ensure that you can realistically dedicate the time needed to fulfil the responsibilities of a Board member?
Hi Ingo, thanks for asking.
Yes, I can realistically dedicate the time needed.
I know this is not a symbolic role, but an ongoing responsibility with preparation, meetings, coordination, communication, and plenty of invisible work in between. I have seen that up close for years through Petra’s time on the Board, so I do not underestimate it.
I already had enough room for this last year, and my current setup gives me even more flexibility now. I work remotely, I am used to structuring my own time, my children are grown up and living their own lives, and TYPO3 has long been part of both my professional and personal reality.
If elected, I would not treat this as something to squeeze into leftover hours. I would make room for it deliberately.
And since you are running as well and clearly know what this role demands, I would also be interested in any practical advice you would give on how to stay effective and sustainable in it over time.
So yes, I am confident that I can commit the necessary time and energy.
Hi Jo,
as a member trying to make an informed decision, I’d like to ask:
After one year on the Board, how would we as members be able to tell whether you’ve actually delivered on what you’re promising today? What would be a concrete indicator of success that we could point to?
I think it’s fair to ask this before voting – not just “what do you want to do” but “how will we know if you did it.”
**“What currently makes TYPO3 harder to build with, contribute to, or work with than it should be?”
**
- It is the Extbase extension which is very hard to start with and a proprietary thing of TYPO3 and not so well documented. If there would be a set of videos which explain all necessary details how to start writing a new TYPO3 extension in the front and back end with list and single view and a form for complex data entries this would help newcomers to contribute with their own TYPO3 extensions.
- It is even hard to use the composer installation because you need to go to the command shell. The usage of the Extension Manager has been much easier.
- Functionalities of the TYPO3 Core get deprecated in one TYPO3 version and are removed in the next already. This makes it hard because there is not much time left between 2 TYPO3 versions to do all the required code changes. I think this is the main reason for developers giving up.
@matthiash Hi Matthias, that is indeed a fair question.
I do not think it would be realistic to promise that after just one year a new Board member will already have “fixed” the big structural issues. There is a reason the term is three years, not one. And it also depends on which specific role I would take on within the Board after the election, because that is decided by the Board itself only afterwards.
So after one year, I would not ask to be judged by whether everything is already solved. I would ask to be judged by whether my work is clearly moving in the right direction within the role I actually have.
For me, that would mean better visibility into the Board’s work, more trust and less friction across the different parts of TYPO3, and visible progress towards making contribution and Core work more sustainable and more attractive.
So no, one year is not enough to finish everything. But it is enough to show whether someone is making a meaningful difference.
@ghi:
"how could we even motivate fresh people to actually move development forward "
I think that a reminder system is needed to pull the focus on developers waiting for answers to get their code into the system. It makes no sense if developers cannot get their work finished because they do not get the needed answers, feedback and approval.
Otherwise it would frustrate them and they might stop contributing. And at least a monthly list of contributors should be published on the website. Then the developers’ names would be more visible to others and they could gain reputation.
Contributors like ghi should be supported in time in order that TYPO3 can benefit from the patches or improvements. Otherwise not only this but also possible following features would not get contributed. And even more other developers who see this will avoid to contribute.
@franzholz I think what @ghi may be referring to is not mainly an approval issue, since he is currently one of the Core Mergers.
The bigger problem may be the feedback loop around contributions. People report bugs, but often do not return to test a fix, confirm a workaround, or provide follow-up feedback. That creates friction too, even when someone is actively trying to move things forward.
As for visibility, we already have things like Developer Appreciation Day and the monthly contribution reports. So the real question may be less whether these formats exist, and more whether they are visible and effective enough.
And when you say contributors should be “supported in time”, could you clarify what exactly you mean? Are you referring to review speed, technical guidance, testing support, or response times more generally?
It would help more to have a hall of fame page for the current and the last 5 years. This would help contributors to prove to a company where they apply for a job, that they contributed something useful for TYPO3.
I mean with “in time” that a contributor should get a feedback to his patch within a few days. This can be an answer to his questions or an approval to his work. When I look back to the bug tracker then it happens that even patches are lying around for many years. This has a very bad effect that many other possible contributions will not be done any more because many people then think that there would be no chance to get something into the core.
1 Like