Earlier this year I wrote about the importance of treating open source as digital infrastructure in my post Agree and Amplify: Funding Open Source as Digital Infrastructure. The core idea is simple: the software that powers much of the internet should not depend solely on goodwill and spare time. It deserves durable investment.
That is why I am pleased to be a founding donor to the Open Source Endowment, a new initiative exploring a long-term funding model for critical open source infrastructure through community support.
Working in the WordPress ecosystem makes the sustainability challenge very real. WordPress powers a significant portion of the web and continues to evolve thanks to a global community of contributors, companies, and organizations investing time and resources into the project. Programs like Five for the Future have helped encourage that investment, but the broader open source ecosystem still struggles to ensure that essential projects and maintainers have stable, long-term support.
The Open Source Endowment proposes another approach: building a community-funded endowment designed to generate ongoing financial support for maintainers and critical projects. Rather than relying only on sponsorships or one-off donations, the goal is to create a lasting financial base whose returns can sustain open source work over time.
If open source truly is digital infrastructure, then we should be thinking about funding it like infrastructure as well. I am excited to support this effort and encourage others who care about the long-term sustainability of open source to take a look and consider donating.
At first glance those might seem like unrelated conversations. One focuses on sustainability and business models, while the other looks at contributor behavior and code quality. But they are both signals of a deeper change in how developers discover, learn from, and contribute to open source projects.
Having spent years working in open source communities, particularly in the WordPress ecosystem, the patterns maintainers are seeing right now feel meaningfully different. Open source has always been foundational infrastructure for the web for better or worse, but AI is amplifying that role in ways that are both exciting and challenging for the communities that sustain it for better or worse.
Many modern AI systems are built on open source frameworks, and large language models have been trained on enormous bodies of publicly available code. At the same time, developers are increasingly using AI-powered tools to generate code, debug problems, and explore unfamiliar technologies, and the answers those tools produce often rely heavily on open source libraries, patterns, and documentation.
In other words, open source is not becoming less important in the age of AI. If anything, it is becoming even more central to how software gets built.
What is changing is how developers engage with the projects behind that infrastructure. Traditionally, developers discovered and learned about open source projects through documentation, issue discussions, conference talks, blog posts, and direct interaction with maintainers and contributors. Over time they built a mental model of how a project worked, what problems it was designed to solve, and how to contribute effectively.
AI tools reshape that feedback loop. Instead of reading documentation or exploring issues, developers can increasingly ask an AI assistant for an answer and receive working code or configuration suggestions almost immediately. The AI draws from documentation, source code, and examples to generate a solution, often without requiring the developer to interact directly with the project itself.
That shift is incredibly powerful and can dramatically accelerate development, but it also creates a more indirect relationship between developers and the communities behind the tools they rely on. Developers can benefit from open source projects without ever encountering the maintainers, reading the roadmap, or participating in the conversations that shape how those projects evolve. But… is that a good thing, that separation?
Maintainers are also beginning to feel the effects of AI from another direction. Across many open source projects, maintainers are seeing a noticeable increase in AI-assisted contributions. Some of these contributions are thoughtful and well considered, and AI can absolutely help people get started with open source or explore parts of a codebase that might otherwise feel intimidating.
But there is also a growing pattern of pull requests that appear to have been largely generated by AI without a clear understanding of the issue they attempt to address. In those cases the code might compile or appear plausible, but the proposed changes often do not reflect the architectural decisions or design constraints of the project.
Maintainers then spend significant time reviewing, explaining, or rejecting contributions that ultimately add more overhead than value. When multiplied across dozens or hundreds of submissions, that review burden can quickly become a real source of strain for projects that are already maintained by small teams or volunteers.
None of this means AI is bad for open source. In many ways it has the potential to strengthen the ecosystem by helping developers ramp up more quickly, improve documentation, and lower the barrier to entry for contributors who want to participate but do not yet feel comfortable navigating a large codebase.
At the same time, open source communities will likely need to develop new norms around how AI is used within contribution workflows. That might mean encouraging contributors to submit smaller and more focused pull requests, ensuring they understand the problems they are trying to solve before generating code, and being transparent about when AI tools were involved in producing a proposed change. It may also mean thinking more intentionally about how maintainers can manage increasing contribution volume without burning out.
These are conversations already happening in several open source communities, including WordPress. With more than 40% of the web running on WordPress, the ecosystem offers an interesting lens into how large open source projects may adapt to AI-assisted development. The WordPress AI team and initiatives like the AI Experiments plugin are exploring how AI capabilities can be integrated into the platform while still maintaining healthy contributor workflows and sustainable community practices.
The two LeadDev articles that sparked this reflection looked at different problems, but both point toward the same broader transformation. AI is making open source more widely used, more visible, and more deeply embedded in the development process than ever before, while at the same time reshaping the relationship between developers and the projects they depend on.
In many ways, AI is increasing the demand for open source while simultaneously increasing the maintenance burden on the people who sustain it. The tools that make it easier to generate code, build applications, and experiment with new technologies are often powered by the very projects that maintainers are now struggling to keep up with.
Open source communities have adapted to major shifts before. Package managers, centralized collaboration platforms like GitHub, and the rise of cloud infrastructure all reshaped how developers build and collaborate. AI feels like another one of those moments where new tools dramatically expand what developers can do while also forcing communities to rethink how they sustain the projects that make that innovation possible.
AI will continue to make it easier to generate code, explore new tools, and build software faster than ever before. But the infrastructure that makes that possible still depends on maintainers, contributors, and communities that invest their time and expertise into open source projects.
If AI is going to accelerate development, it should also raise the bar for how thoughtfully we engage with the projects we depend on. That means understanding the problems we’re solving, contributing responsibly, and recognizing that open source doesn’t sustain itself.
I recently had the chance to join the Crossword podcast for a conversation about open source, WordPress, and what meaningful contribution really looks like beyond writing code.
On this episode of Crossword.fm, we talked about how I got involved in the WordPress project, why non-technical contributors play such a critical role in open source, and what I’ve learned from spending nearly a decade working at the intersection of product, community, and engineering within the open web.
A few of the themes we explored include the value of organizers and facilitators in large open source projects, how text-first and asynchronous collaboration (meaning Slack-based meetings and regular meeting summaries and decision documenting via WordPress.org posts) helps WordPress scale globally, what sponsored contribution looks like inside agencies, and how to think about the future of WordPress in a way that brings people along rather than leaving them behind.
As with most good conversations, there were a few things I wanted to expand on but simply ran out of time during the recording.
One important example worth calling out is the continued leadership coming from Human Made, particularly through the work of John Blackbourn. During the episode we touched on agencies noticeably contributing to the project and I would be remiss without plugging John’s work. Their sustained investment in leading and supporting the WordPress Security Team is a strong example of what high-impact, long-term contribution looks like when a company aligns its expertise with a critical need in the project.
We also touched briefly on the question of how to get companies to agree to contribute to open source. In practice, the most realistic path forward usually starts with business alignment. What improvements to WordPress would directly support a company’s products, services, or clients? Advocating for and contributing toward those outcomes is often the clearest way to earn leadership buy-in. That contribution may not always be in core, and that’s completely fine. Sustainable participation tends to start where incentives overlap.
Finally, a quick clarification on a phrase used during the conversation. When Luke referenced “skating to where the puck is going to be,” that’s a sports reference that means anticipating demand rather than reacting to it. For folks like my dear friend Weston Ruter and others who do not live in the world of sportsball, that was what Luke meant.
If you’re interested in contributing to WordPress, supporting open source from inside an organization, or just want a grounded look at how large community-driven projects actually function, I think you’ll enjoy the conversation.
Open source software powers critical digital infrastructure, but funding rarely reaches the people maintaining it. Dries Buytaert’s post on digital sovereignty makes a strong case for changing how governments and organizations invest in open source. Recent sustainability challenges in projects like Tailwind show this isn’t theoretical. If organizations rely on open source, contributing back (including funding) should be treated as a baseline responsibility, not optional goodwill.
This post is not a summary or a critique. It’s an agreement and an attempt to extend the argument into the broader open source ecosystem, especially WordPress.
Dries articulates a problem that’s been hiding in plain sight for years. Open source software underpins much of our digital world, yet the people and projects responsible for building and maintaining that software are routinely bypassed when funding decisions are made.
Dries frames this through government procurement and digital sovereignty, but the issue is broader and structural. We see the same dynamics play out across the private sector and across ecosystems of every size.
I’ve been thinking about this recently in the context of projects like Tailwind CSS. Tailwind has enormous adoption, deep influence on modern web development, and a thriving ecosystem built around it. And yet, like many widely used open source projects, it has struggled at times to turn that success into stable, long-term funding for maintenance and stewardship.
That’s the paradox: popularity is often mistaken for sustainability. In reality, widespread usage can increase the maintenance burden faster than funding models evolve to support it.
In many ways, this starts to resemble a modern version of the tragedy of the commons. Open source is a shared resource that everyone benefits from, but when responsibility for sustaining it is diffuse, the rational short-term behavior is to underinvest and hope someone else picks up the slack. The result isn’t sudden failure, but slow erosion through burnout, deferred maintenance, and growing risk.
This is not a Tailwind-specific problem. It’s a pattern.
The same tension exists in the WordPress ecosystem.
WordPress powers businesses, governments, nonprofits, publishers, and educational institutions worldwide. Entire industries are built on top of it. Economic value flows through hosting companies, agencies, SaaS platforms, and integrators, while upstream projects and maintainers often rely on voluntary contribution or a relatively small pool of sponsors.
Programs like Five for the Future have helped normalize contribution as part of doing business, and WordPress has benefited enormously from sponsored contributors who show up across multiple release cycles. But even here, the gap between value extracted and value reinvested remains real. When budgets tighten, open source contributions are often treated as optional, despite supporting mission-critical systems.
What resonates most in Dries’ post is the framing of open source as shared infrastructure.
We already accept this model elsewhere. Roads, utilities, and public services are funded because society depends on them. Open source software plays a similar role in the digital world. If organizations rely on it to operate, scale, and serve people, contributing back (including funding) should be a baseline responsibility, not an act of goodwill. If contribution is a responsibility rather than charity, it’s worth being clear about what responsible, sustainable support actually looks like.
So what does sustainable support actually look like?
We already have working examples:
Red Hat has shown how commercial success can directly fund upstream Linux development over decades.
WordPress has demonstrated the impact of sustained, sponsored contributor programs tied to releases, security, and long-term maintenance.
Government-backed efforts like the Sovereign Tech Fund recognize open source as critical infrastructure worthy of direct public investment.
These approaches differ, but they share a common trait: funding the people and projects doing the upstream work, not just the layers built on top of them.
Dries’ suggestion that procurement and vendor selection should explicitly account for upstream open source contributions is especially compelling. It aligns incentives toward long-term sustainability instead of short-term delivery. It also rewards organizations that treat open source stewardship as part of their operating model, not a marketing line item.
Whether we’re talking about government digital services, enterprise platforms, or widely adopted frameworks like Tailwind, the lesson is the same: popularity is not a funding model.
If we care about digital sovereignty, resilience, and innovation, we can’t assume open source will take care of itself. It won’t. It’s built and maintained by people, and those people need consistent, institutional support to do this work well.
So here’s the question I think every organization should be asking itself:
If your business, platform, or public service depends on open source, how are you directly funding and sustaining the projects and people you rely on?
Dries’ post is an important signal in that direction, and I hope it pushes more organizations to answer that question honestly. If that answer is unclear or uncomfortable, that’s probably the point.
