Build-Your-Own Starship Enterprise — Reflections on DrupalCon Portland 2024

Why this? Why now? And how are they planning on pulling that off? Excellent questions and a great reason to learn more about Drupal, TYPO3’s PHP cousin, and its community. 

Once upon a time in a country far, far away … (Tell your brain to add dreamy music and a water/droplet transition at this point.)

The Break With the Past

Almost 10 years ago, Drupal took the big decision to rewrite the core for version 8. The move to a more modern code base incorporated moving to object-oriented code, use of PHP-FIG standards, Composer dependency management, and more. Some would say the modernization also created a less beginner-friendly code base. That caused both consternation and jubilation in the CMS's community. Some of those who wanted to keep the benefits of the old core even created a fork of Drupal 7, called Backdrop CMS. Others embraced the new possibilities of the rewritten core to develop Drupal's enterprise-level capabilities further.

Compared to TYPO3’s gradual modernization of the core, Drupal's relinquishing of the past was a hard break. As a result of the rewrite-everything upgrade path, a large portion of all Drupal sites online today are still using version 7, first released in January 2011. Support for Drupal 7 has been extended repeatedly, with the final final for real end-of-life date now set for January 2025. 

If you think TYPO3 is better, remember that TYPO3 also planned and began a similar core rewrite with the Phoenix/Neos project. The choice not to embrace that path was probably just as hotly debated and divisive as Drupal's decision to go ahead.

Power to Whom?

We have long defined TYPO3 as an enterprise CMS and agency toolset. I personally often use the catchphrase “enterprise any-size” and explain that TYPO3 is for everyone with professional website needs.

Drupal markets itself for enterprise too, but its roots lie elsewhere, in activism, politics, education, and science, for example. The Drupal community has also long held the concept of the ambitious site builder — the happy amateur who loves creating great works of website-building art by assembling ready-built pieces, and with little coding involved. Since version 8, the persona of the ambitious site builder had almost disappeared from the project's rearview mirror.

Dries announced that part of the idea behind the Starshot initiative is bringing Drupal back in the direction of the ambitious site builder. But will the effect also be to distance it from the enterprise segment?

Questioning Fundamental Assumptions

To me, the idea of Starshot touches some of my fundamental assumptions about what is possible to do in open source software development.

• Healthy ambition or hubris? Is it really possible to combine an enterprise platform with the requirements of an amateur user? Can a Formula 1 racer ever be a great family car?
   
• Expectation management? Open source projects tend to be driven by personal interest. What happens to the community dynamics when everyone is told to focus on a single goal? I talked with multiple people who were excited about Starshot because their pet project could become a part of it. Will they be disappointed? What about the agencies delivering enterprise projects with Drupal?
   
• What about the core? Will the focus on a separate project take resources away from the development of the core, and how could that affect the project long-term?
   
• Mixed messages? How will Drupal solve the simultaneous marketing of Drupal for enterprise and Drupal for ambitious site builders? During the presentation, I noticed that Adobe Experience Manager was still touted as the main Drupal competitor (and compared with the Soviet Union in Drupal's version of the space race).

The Software Self-Development Retreat

Challenging your own assumptions is necessary for self-development — both for humans and open source software projects. Seeing the questions and challenges others are facing is another great reason why visiting other FOSS and CMS communities’ conferences is important for TYPO3. 

It will be interesting to see how the Starshot initiative develops. And while it does, we in TYPO3 should not be afraid to reflect on our own assumptions. TYPO3 is not Drupal, but we're similar enough that we can recognize the challenges they are facing. Easier onboarding, community recruitment, and retention are high on the list.

Inspiring People to … Vanity Fear?

At my own DrupalCon presentation, Drupal and FOSS CMS Collaboration in a Competitive Market, I spoke about the similarities of recent versions of our CMSs under the hood, with similar dependencies and best-practices. In the past, we often shied away from using other people’s code. I think the limiting not-invented-here mindset is still alive and well, and maintaining duplicate functionality often takes time and energy away from improving our CMSs. 

For example, I recently discovered that Drupal, Joomla, TYPO3, WordPress, and Symfony all implement their own separate transliteration libraries. I cannot picture a world in which maintaining what’s essentially translation tables is going to be the source of ground-breaking, CMS-market-winning innovation. How about we also stop reinventing these wheels?

It is almost as if we're too vain (or afraid?) to look at other systems' implementations. Why don’t we walk the walk? If ours is better, let’s contribute it to the others. If theirs is better, why don’t we adopt it and get on with solving better problems? My new name for not-invented-here is Vanity Fear.

Bringing Two Projects Forward, Together

I'm slowly becoming a DrupalCon regular. This time around, I really noticed that I wasn’t just introducing myself to new people. Some people recognize me, and are excited that I am from ​​TYPO3, and that our project is reaching out to theirs. After announcing the Open Website Alliance, talking about collaboration between our CMSs is no longer a foreign topic. By talking about our differences and what our different choices have brought us, I both see where the TYPO3 community is ahead — and where it is behind.

For example, the Drupal community is wonderful at contributor onboarding, with teams, plans, and dedicated newbie sprints. We can learn a lot from them. We, on the other hand, have made some right choices when it comes to organizational structure that is streamlining the TYPO3 project’s funding and autonomy.

Like all cultural exchanges, new perspectives challenge both you and the other to look at yourselves in a new way. The point is not to lose yourself and become the other, but to learn to know yourself better — and to become a better version of yourself by learning from others. In this way, free and open source gives us the opportunity of training a very human faculty while improving our software products. Maybe it’s even more than a win-win situation?