The Public Record Drupal Deserves

Watching the DriesNote at DrupalCon Rotterdam, one part of Dries Buytaert's argument felt immediately familiar. He was speaking about Drupal's “reputation gap”: the distance between what Drupal can do today and what people outside the community still believe it can do. Rather than proposing a bigger marketing campaign, he called on Drupalers to make the work easier to see, reuse and discover.

That might mean taking one useful idea from somebody else's session instead of expecting people to watch the entire recording. A demonstration can become a short video. An explanation can travel through translation. A contributor's work can reach people who would never think to look for it on Drupal.org or in a conference programme. The underlying problem is simple: good work does not automatically find an audience.

The Drupal Association has now given that activity a more formal structure through the Drupal Advocacy Program. Advocacy can earn contribution credit, while the Rotterdam Pilot is making material from the keynote and its demonstrations easier to reuse. Dries explicitly encouraged Drupalers to amplify other people's work, not just their own.

For us at The DropTimes, this put clearer language around a problem we have been working inside for nearly five years.

The Work After the Work

Drupal produces more useful work than the wider world ever sees. Maintainers solve difficult problems. Modules gain capabilities that took months to build. Speakers prepare sessions, camps surface ideas worth carrying further, agencies publish lessons from real projects, and contributors explain architectural decisions in posts that may circulate briefly before attention moves elsewhere.

The material usually remains somewhere. The code is still in the repository, the recording may still be online, and the post may still be indexed. What is easier to lose is momentum. The work stops travelling.

Conferences make that especially visible. A presentation may contain one insight another team could use immediately, yet finding it later requires knowing the right session, locating the recording and sometimes sitting through an hour to reach the relevant five minutes. Dries asked people in Rotterdam to interrupt that pattern by taking individual ideas from presentations and giving them another life.

Documentation is part of that life. So are attribution and context. A useful story needs enough explanation to make sense to somebody who was not present when the work happened, and enough structure to remain discoverable after the social feed moves on. Much of what The DropTimes has been trying to do sits in that space.

Nearly Five Years of Building the Record

TDT began with a broad ambition to cover what was happening around Drupal and help more people encounter it. The meaning of that ambition became clearer through the work itself.

News was part of it, though never the whole of it. Module coverage led naturally to the people maintaining those modules. Interviews gave contributors room to explain how projects developed and why decisions were made. Event reporting preserved discussions for people who could not be there. Case studies showed what Drupal was doing outside its own community conversations. Jobs, governance, security, initiatives and technical developments gradually filled in other parts of the picture.

In The Storytelling We Are Passionate About, we tried to describe that range in 2024. A year later, Why We Write, What We Write? went further by describing TDT as a community project and arguing that documentation can make contributors visible while connecting one development to the next.

Those connections give an archive lasting value. A release tells us more when the maintainer behind it is visible. An announcement becomes part of a larger story when earlier work can be traced. A conference session remains useful months later when its central argument can be found without replaying the entire event. Attribution matters for much the same reason: work should not disappear behind the convenient shorthand of “the community” when the people responsible can be named.

Our reporting often depends on that same network of participation. When TDT documented DrupalCamp England from outside the venue, attendees and community members supplied photographs, video, observations and context. At Rotterdam, Alex Moreno Lopez shared the DriesNote transcript that allowed us to check the keynote carefully before publishing our report. One byline may sit above the finished article, but the knowledge behind it can come from many people.

Drupal Does Not Exist in Isolation

Following Drupal closely also makes one thing difficult to ignore: its story does not end at the boundary of Drupal itself. The software depends on PHP, Symfony, infrastructure projects, standards and a broad open-source supply chain. Drupal agencies work with search, analytics, marketing automation, frontend frameworks and cloud services. Public-sector implementations quickly lead into accessibility, procurement, privacy and questions about who controls the infrastructure beneath public services.

Digital sovereignty belongs in that conversation because organisations are examining their dependence on vendors, platforms, infrastructure and data flows. The open web belongs there too. Drupal's future is tied to whether organisations continue to have meaningful choices about how they publish, build and communicate, rather than surrendering every layer to a small number of proprietary platforms.

These subjects describe the environment in which Drupal is chosen, developed and sustained. TDT can remain unmistakably Drupal-centred while making those connections visible.

That could mean a practitioner examining digital sovereignty through a Drupal implementation, a maintainer considering the future of the open web, a public-sector technologist writing about procurement, or a developer challenging an architectural assumption. It could equally mean somebody asking how Drupal presents itself to people who have never attended a Drupal event. Those conversations belong beside release coverage because an ecosystem is shaped by more than the software it ships.

A Better Record Is Not Better Advertising

Making Drupal's work more visible carries an obvious responsibility: the story still has to match the evidence.

Experimental software should be described as experimental. A capability demonstrated on stage should not be presented as generally available unless it is. Contributions should stay attached to the people who made them, and claims should not become more impressive each time they travel from one publication or social post to another.

That discipline strengthens positive storytelling because it gives readers a reason to trust it.

Much of what deserves greater visibility already happens every day. Maintainers solve problems that most users will never see. Contributors improve tools. Organisations provide money, time and people. Local groups sustain relationships that keep participation alive. Agencies find new uses for Drupal, and community members share knowledge that somebody else can build upon. Familiarity can make all of this easy to take for granted, particularly for those of us who encounter it constantly.

TDT exists to notice more of that work, understand it properly, attribute it accurately and help it reach people who might otherwise never encounter it. That does not require inflating its significance.

The new Advocacy Program points in a compatible direction by emphasising proof, attribution and material that can make sense outside established Drupal circles. If somebody's picture of Drupal is ten years out of date, current evidence is more persuasive than simply telling them that their impression is wrong.

The Record Has New Readers

Rotterdam added another reason for taking this seriously. People no longer encounter Drupal only through colleagues, conference talks, search results or technology publications. Increasingly, they ask AI systems, and Dries warned that those systems can repeat outdated perceptions when the information available to them is itself old.

Publishing therefore has consequences beyond the immediate readership. A careful article about Canvas can become a later reference. A maintainer interview may preserve technical history otherwise scattered across issue queues and conversations. Case studies provide evidence of how Drupal is actually used. Reporting on digital sovereignty can connect Drupal to questions being asked far beyond the CMS market.

Once published, this material can be found, cited, challenged and built upon. Search engines index it. Other writers encounter it. AI systems may eventually use it among the sources from which an answer is constructed. Publication does not make something authoritative by itself; it makes accuracy, context and attribution more consequential.

A Platform the Community Can Use

The DriesNote also leaves us with a question about TDT. For years, our editors have gone looking for stories across the ecosystem. We should now make it easier for more people in that ecosystem to bring their knowledge, experience and arguments here directly.

When somebody connected with Drupal has something worth explaining, documenting, debating or preserving, The DropTimes should be one of the places that comes to mind. That contribution does not have to look like news.

A maintainer might want to explain the history behind a module. An organiser may have learned something worth carrying beyond a local event. Designers have experience of accessibility that cannot always be reduced to a checklist. Developers working with AI may have questions that deserve more room than a release announcement gives them. Public-sector practitioners can bring direct experience to discussions of procurement or digital sovereignty.

The same applies to the open web, open-source sustainability, public digital infrastructure, privacy and technologies surrounding Drupal. If the connection to the ecosystem is real and the subject deserves examination, TDT should have room for it.

Nor does everything published here need to agree with TDT, the Drupal Association, Dries or a prevailing community view. A useful community platform should make respectful disagreement possible without making accuracy optional.

For the Community, by the Community

One of the more important parts of Dries's Rotterdam appeal was the reminder that advocacy need not begin with our own work. We can notice what another person has built and decide that it deserves a larger audience.

Sometimes that means returning to a good session with a better question. It may mean explaining why a technical change that looks minor is consequential, preserving an argument before it disappears into a chat archive, or connecting work happening in one part of Drupal with people elsewhere who would never otherwise see it.

TDT can provide a place for those connections, but no newsroom can build a shared community record alone. The knowledge already sits with maintainers, users, agencies, organisers, designers, students, customers and contributors, including people who have spent years solving problems that rarely become headlines. We want more of that knowledge to make its way into published form.

The invitation is simple. If there is a Drupal story that deserves a better record, a connection to the open web that others are missing, a question about digital sovereignty that needs serious treatment, or somebody else's work that should reach a wider audience, bring it to TDT.

Dries asked Rotterdam to “talk louder about Drupal”. We would add that what travels should carry enough evidence, context and attribution to remain useful after the immediate noise has passed.

For nearly five years, The DropTimes has tried to help Drupal's work travel further than the moment in which it happened. The platform can do more of that if more of the community sees it as a place where its knowledge can live.