Who Pays for the Documentation?

Drupal documentation has a funding problem.

I have some thoughts I want to share after nearly two decades in the thick of it.

I’ve spent much of my career producing developer education for Drupal. Video tutorials, written guides, multi-day workshops, demo codebases, conference talks, and the Drupal User Guide. Over 200 video lessons and countless written tutorials. And I’ve helped to keep that content current through six major Drupal versions, which anyone who’s maintained technical documentation knows is a job that never ends.

Through all of that, there’s a question I keep coming back to, and I think it’s one we as a community still haven’t answered well:

Who pays for the documentation that makes Drupal (and open source in general) work?

The commercial model

In the commercial CMS world, the answer is pretty straightforward. If you’re Contentful, Sanity, AWS, a hosting provider, or any platform that needs developers to choose you, documentation is a line item. You hire developer educators. You fund a docs team. You build example apps and starter kits and maintain them. And you do this because you know that great developer education and great documentation attract developers, and developers are what make a platform succeed.

Individual developers might not be the ones paying for your company’s product (the agency or organization they work for is), but they are the ones driving the decision to choose you. And they’re the ones most affected by the quality of your documentation.

So the incentives are aligned. The company that profits from adoption is the same company that funds the resources that drive adoption. Documentation isn’t a nice-to-have. It is a core part of the product.

Open source breaks that alignment

In open source, the software is free. The documentation is free. The tutorials and community guides that help someone go from zero to productive—all free. And crucially that’s the whole point. Open source is powerful precisely because there are no gates.

In the case of Drupal (and many OSS projects), most of what’s available is created by volunteers, or by people whose employers give them a few hours a week to contribute to the project. And that’s awesome—it truly is the engine that makes open source run. For some projects, it’s enough.

But it doesn’t scale.

Earlier I said, “documentation isn’t a nice-to-have,” and that’s just as true for Drupal as it is for Contentful or Sanity. Good documentation can be directly linked to adoption. And for open source projects to thrive, they need to be easy to adopt. Even in the age of AI, technical documentation remains the #1 resource developers use to learn, with 68% relying on it—though that number is declining as AI tools rise, I don’t think that absolves us from figuring out the documentation funding problem.

A project the size of Drupal has documentation needs that can’t be met by volunteers alone. It’s not just about writing or editing individual pages or keeping a README.md up to date. Someone has to plan the information architecture. Someone has to outline the guides, decide what goes where, figure out what’s missing, and create a structure that makes sense to a developer who’s encountering the project for the first time. If you want it to really shine, you need to create demo codebases, optimize for SEO, create coherent learning paths, and translate content into multiple languages. And critically, someone has to wrangle the community of volunteer contributors so that the work they do is meaningful and connected—not just isolated pages that don’t fit into a larger whole.

That’s full-time work. Honestly, that’s multiple people’s full-time work. A volunteer who contributes a few hours can write a great tutorial, but they can’t maintain the big picture. They don’t have the time to ensure consistency across hundreds of pages. They can’t keep the getting-started experience coherent when the underlying architecture is rapidly changing. And it’s unreasonable to expect them to.

A temporary contract can go a long way towards helping with a specific, tightly scoped, project or update. But, that work also always ends up with artifacts that require on-going attention even after the contract is complete.

And there’s the maintenance. Anyone who’s written a tutorial knows that publishing it is maybe 40 percent of the work. The other 60 percent is updating it when the API changes, when a new major version ships, when the ecosystem shifts, and the old way of doing things quietly becomes the wrong way. The internet is littered with the ghosts of tutorials that haven’t been updated in years. Part of the value proposition of Drupalize.Me has always been helping people sort through the noise and find the signal.

That maintenance work is invisible until it doesn’t happen. Then suddenly your getting-started guide doesn’t work, your code examples throw deprecation warnings, your Form API docs are missing critical elements, and the first experience a new developer has with your project is frustration.

I see this all the time. I’ve spent years maintaining the massive collection of Drupal tutorials at Drupalize.Me. And I’ve also contributed content to various free, community-driven resources available to anyone on Drupal.org and embedded in Drupal core. I’ve served in various community roles related to documentation governance, conceived and helped create the Drupal User Guide and later the Drupal CMS Guide, and helped facilitate others contributing their volunteer time to this work. But here’s the uncomfortable truth: that free content and many of the hours I’ve been able to spend on community projects only exist because Drupalize.Me’s paid content is behind a paywall, and that paywall is what paid my salary. The free stuff was subsidized by the not-free stuff.

Based on page visits, it is among the most-visited documentation on Drupal.org. Content that drives Drupal adoption. And I’ve been thinking a lot lately about what happens when I (we) no longer have the resources to maintain it.

It’s not just the code

Dries Buytaert recently wrote about a related problem: open source infrastructure deserves a business model. He argues that package registries, CI pipelines, Git hosting, and all the services that keep open source running cost real money, and the organizations that depend on them most often contribute the least to sustaining them. His proposed fix: a value-exchange model where large-scale consumers pay based on consumption, while individuals and small projects stay free.

I think he makes a good case. And I’d suggest the same structural problem exists one layer up.

If infrastructure is the foundation underneath the code, documentation is the foundation underneath the people who use the code. And the maintenance of both is invisible until they fail. Both are chronically underfunded relative to the value they produce. Both are treated as public goods that someone else will figure out how to pay for, update, fix, and maintain.

Dries notes that “governance tends to follow funding.” The same is true of documentation. Show me a project’s funding model and I’ll show you the state of its getting-started guide.

So who pays?

This is where it gets complicated. Look at who benefits from good Drupal documentation and training:

• Agencies building client sites on Drupal need developers who can get productive quickly and stay aligned with current best practices.
• Product companies building on Drupal need their teams to understand the platform deeply.
• Hosting companies whose infrastructure runs Drupal benefit from a growing ecosystem of sites.
• Individual developers use free learning resources to build careers that earn them good livings. Some of them become contributors.
• The Drupal Project benefits from a growing ecosystem of contributors, and the documentation helps them get involved.

All of these groups extract real, tangible value from the existence of quality educational content. But the line between “benefits from open source education” and “funds open source education” has never been a straight one. As the OpenSSF put it in their joint statement on sustainable stewardship: open infrastructure is not free, and most maintainers of critical projects still receive little or no sustained support.

At Drupalize.Me, we’ve been trying one answer: you pay for access to high-quality, maintained tutorials and video training—and we funnel as much of that back into community resources as we can sustain. It worked, to a degree. We built a sustainable business for over a decade. We used the proceeds to fund the creation of as much free content as we could. But it also meant putting a gate in front of exactly the kind of content that does the most good when it’s freely available. Every paywall is a barrier to the person who could become Drupal’s next great contributor, but who can’t afford $35 a month to learn how.

I’ve also been involved with, and seen, other approaches including gracious companies donating employee hours to work on documentation, the Drupal CMS adopt-a-doc program, and volunteers who do amazing work until they eventually burn out. Thus far, none of them have resulted in sustainable funding for documentation.

AI is changing the equation

And now there’s a new wrinkle. Increasingly, developers are turning to AI to learn. Instead of searching for a tutorial or subscribing to a training site, they ask ChatGPT or Claude how to write a custom Drupal module, how the render pipeline works, or why their migration is failing. It’s fast, and it’s free (or at least that $20/month is doing a lot more for me than a subscription to a single tutorial site). According to the 2025 Stack Overflow Developer Survey, 44% of developers learned to code with AI assistance—up from 37% just one year earlier.

The impact on traditional developer education platforms is already stark. Stack Overflow has seen its monthly question volume drop 76% since ChatGPT’s launch. If that traffic drop is happening to Stack Overflow, it’s happening to every paid tutorial site too (trust me, I’ve seen the numbers). Why pay for a subscription when you can ask an AI and get a reasonable answer in seconds?

One thing to keep in mind is that AI is only as good as the material it was trained on. When an LLM gives you a good answer about Drupal’s Entity API, that answer exists because someone—a volunteer, a paid educator, a documentation maintainer—wrote the content the model learned from. The quality of AI-generated developer education is downstream of the quality of human-created developer education. If the source material degrades, the AI answers degrade with it. Researchers have already documented this phenomenon: a study published in Nature found that training AI models on AI-generated content causes progressive degradation in output quality and diversity—a process they call “model collapse.”

And right now, AI-generated answers about Drupal are often wrong. Sometimes subtly, sometimes completely. They’ll confidently tell you to use hooks that were deprecated two versions ago, or suggest patterns that don’t account for how Drupal actually works. This isn’t just anecdotal, either—researchers have studied exactly this problem, finding that LLMs frequently recommend deprecated APIs and outdated functions in code completion. If the LLM’s training data is “all of the internet,” but the internet is full of out-of-date documentation, you can see how this becomes a problem. And even if you were to train a model specifically on Drupal’s canonical documentation … it only takes a quick search of the issue queue to realize it too has plenty of missing or out-of-date content.

For a lot of open source developers, I think the AI-generated responses are totally fine—80 percent of the way there and free beats 100 percent correct and paid. I know I started using open source in the first place because it was close enough to what I needed and open so I could figure the rest out on my own. That’s a reasonable tradeoff for experienced developers who can spot the errors and fill in the gaps.

But it’s a terrible experience for the new developer who doesn’t know enough yet to recognize when the AI is wrong. And those are exactly the people that good documentation is supposed to serve.

So we’re in a strange loop: AI makes it harder to fund the creation of quality educational content, while simultaneously depending on that content to be any good. If nobody’s paying to maintain the docs and tutorials, the AI’s answers get worse over time. And the developers relying on those answers won’t even know it.

AI is advancing rapidly and will only get better—its ability to generate accurate, reliable answers will continue to improve, and more developers will turn to it first. But that doesn’t mean we should stop investing in human-created educational content.

My stance on this currently is that AI isn’t replacing the need for quality documentation; it is enhancing it.

The tension I’ve never resolved

So here’s what I keep circling back to: in my dream world, everything I’ve spent my time at Lullabot/Drupalize.Me creating would be free. At Drupalize.Me, this has been a topic at every company retreat for as long as I can remember. Not because the work has no value—it has enormous value—but because the impact is greatest when anyone can access it. All developers, regardless of their current role or financial situation, should have the same shot at learning this stuff. Open source education is a public good.

But “it should be free” is not a business model.

People who create and maintain educational content need to pay rent. They need health insurance. The work is skilled, time-consuming, and never finished. So the question becomes: how can the organizations that benefit most from a thriving developer community fund the education that creates and sustains that community? Not as sponsorship. Not as charity. As an investment.

Because every developer who levels up on Drupal is a potential hire, a potential contributor, a potential evangelist. Every getting-started guide that actually works is one less bad first impression. Every well-maintained tutorial is a developer who chose Drupal over the one with better docs.

What would it actually look like?

I don’t have an answer. I’m just a guy with a problem, looking for an answer. And I don’t think there’s a single answer, but I think the conversation needs to evolve. Some of the things I’ve thought about and seen tried over the years:

• Consortium funding: The companies that profit most from a platform pool resources to fund educational content that’s free to everyone. This happens in bits and pieces already—the Drupal Association funds some documentation work—but it’s never been at the scale the need demands.
• Embedded educator roles: Companies that depend on open source hire people specifically to create and maintain community education, not just internal training. Some of the best developer education in open source comes from companies that treat it as part of their contribution, or part of their own internal training efforts, not their marketing. Yet this work often ends up in internal-only knowledge bases and on marketing sites.
• Maintainer stipends for content: We’ve started to see models for paying code maintainers (some of the recent Drupal CMS work, for example). What about applying the same thinking to documentation maintainers? The person keeping the User Guide accurate through a major version upgrade is doing work that’s just as critical as the person reviewing core patches.

Why now?

AI is changing the way developers learn—rapidly. And the funding models for open source education, which were never great to begin with, are under more pressure than ever.

I’ve watched too many good educational resources go unmaintained, too many documentation efforts stall when the volunteer energy runs out, and too many developers bounce off Drupal because the learning path wasn’t there.

Open source has figured out a lot of hard problems. And I think this is another one worth figuring out.

Want to talk about this in person, have related thoughts you want to share? Addison and I are both going to be at DrupalCon Chicago next week (23-26 March 2026) and would love to connect.

Resources

Some additional reading about the state of documentation in an LLM world, and open-source funding in general.