The first Open Source CMS Conference brought together people responsible for Joomla, WordPress, Drupal, TYPO3, and other projects in Utrecht, the Netherlands, on 20–21 October 2026. Among them were leading figures in development, community work, and the organizations behind these CMSs. People who have helped shape their projects for years but rarely meet across project boundaries.
That made the conversations particularly valuable. Those discussing security, funding, and documentation knew the decisions and challenges firsthand. They were also in a position to take ideas from these conversations back to their projects and put them into practice.
Alongside the established CMSs, other approaches were represented, including Webiny with its combination of content management, modern frontends, and AI-assisted development. Developers, agencies, and hosting providers added their perspectives to those of the project leaders.
Benni, David, and Florian attended for b13. We compared experiences from our everyday work with TYPO3 with those of other communities and came away with new perspectives. Three themes stood out: lowering barriers to participation, sustaining shared work, and making collaboration work between competitors.
Different Systems, Similar Barriers to Entry
Open source means that software’s source code is accessible and can be used, modified, and redistributed under its license terms. For a CMS, this allows businesses to adapt their websites independently of a single vendor’s product roadmap. Agencies can build services and extensions on that foundation and contribute improvements back to the shared project.
That openness matters for a system that supports content, editorial workflows, and integrations over many years. It gives businesses choices about development and support. How effectively they can use those choices also depends on how accessible the software and the knowledge around it are.
In Utrecht, we discussed how much knowledge projects expect their users to bring. People who have worked with a CMS for years know its terminology, tools, and processes. For newcomers, those same things can make getting started difficult. The Drupal presentation explicitly addressed the goal of requiring less project-specific knowledge and building on familiar ways of working.
We recognize that question from our own work with TYPO3: How do we make the capabilities of a comprehensive CMS accessible without expecting everyone to learn its intricacies first?
The documentation discussion approached the same challenge from another angle: people who want to contribute. Even a small correction can become unnecessarily difficult. Someone spots an error in a guide but doesn’t know where to report it or how to submit a change.
Experienced contributors take these processes for granted. For newcomers, they can be a barrier. At the same time, existing teams often lack the time to explain every step individually. Good documentation can help—but it needs maintenance too.
It quickly became clear that Joomla, TYPO3, and Drupal face similar challenges. On the second day, a follow-up discussion about documentation was announced, with plans to invite additional communities. This demonstrated the value of the format: the people who understand these tasks and can move them forward were already talking to each other. The technical content differs, but there is plenty to learn from one another about workflows, onboarding, and organizing knowledge.
Who Sustains the Work Behind Open Source?
Comparing funding and participation models was particularly insightful for us. The shared term “open source” covers very different organizational structures.
The TYPO3 presentation explained how membership fees, budgets, and voting on community projects are organized. That includes work that rarely features in a product presentation: running infrastructure, making events possible, maintaining documentation, and keeping the organization functioning. Paid extended support was also discussed as a source of funding.
Joomla emphasized a different aspect: the many hours volunteers contribute to development, testing, translation, support, and helping new contributors get started. The idea of paying support forward was especially memorable. If someone helped you when you were starting out, you can help the next person. Contributing to a project doesn’t have to mean writing code.
A conference focused on a single CMS rarely offers the opportunity to compare these models side by side. In Utrecht, participants could ask each other directly: What has your experience been? Where does the model reach its limits? What work still goes unfinished?
The demands placed on contributors were also discussed openly. Asking the same volunteers to do more and more is not sustainable. Paid work, meanwhile, needs funding and accountability. Who decides on priorities? Which tasks receive a budget? How do projects prevent important but less visible work from being overlooked?
These questions matter to businesses using a CMS. Beyond features and integrations, evaluating a system for the long term means understanding how its maintenance and development are sustained. The discussions showed us the different answers projects have found—and the challenges they share.
Collaboration Works When It Gets Specific
One particularly tangible example came from the WordPress security team. The briefing described how major hosting providers and content delivery network operators exchange information about upcoming security releases and prepare protective rules together. This can help protect websites before an update becomes publicly available.
These companies compete with each other. When it comes to preventing attacks, however, they have a shared interest. Their collaboration has a clear purpose, specific contacts, and a recognizable benefit.
We saw the importance of that exchange firsthand during the conference. On the second day, participants were dealing with two critical vulnerabilities in PHP, the technical foundation shared by Joomla, WordPress, Drupal, and TYPO3. Information was being exchanged across CMS communities on the spot. The people responsible were in the same room and could speak directly.
The speaker from the WordPress security team also saw the conference as an opportunity to strengthen connections with other open-source projects and CMSs. Knowing each other personally makes it easier to assess information and reach the right people when it matters.
That willingness to collaborate extended beyond technical issues. Participants also worked on a shared “Utrecht Statement.” It is expected to be published in the coming weeks and to highlight a joint initiative by the different projects and providers. Its aim is to communicate the strengths of open-source CMSs together and continue collaborating across project boundaries.
For us at b13, the connections between these people are the most important outcome of this first conference. People responsible for Joomla, WordPress, Drupal, and TYPO3 could compare their experiences directly and identify opportunities to work together. The planned documentation exchange and the discussions about security coordination give that work a concrete direction.
At a TYPO3 conference, we learn a great deal about working better with TYPO3. In Utrecht, we could also examine which of our challenges are actually specific to TYPO3. Other projects are already working on many of the same questions. We’re taking home insights from their communities and direct connections with people we can share knowledge and tackle common challenges with.
Want to learn more about the format, participating projects, and program?
Written by:
