# Agree and Amplify: Funding Open Source as Digital Infrastructure

- Link: https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/
- Published: 2026-01-30T15:10:40-06:00
- Author: jeffpaul

## TL;DR

_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._

> I strongly agree with Dries Buytaert’s recent post, _[Funding Open Source for Digital Sovereignty](https://dri.es/funding-open-source-for-digital-sovereignty?utm_source=chatgpt.com)_.

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](https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957)
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](https://openchannels.fm/five-for-the-future-and-contributing/)
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](https://www.redhat.com/en/about/open-source)
   upstream Linux development over decades.
 * Drupal benefits from contribution-aware procurement models where vendors are 
   evaluated on [how they support the upstream project](https://dri.es/solving-the-maker-taker-problem).
 * 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](https://www.sovereign.tech/)
   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.

### Share this:

 * [  Bluesky ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?share=bluesky)
 * [  Mastodon ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?share=mastodon)
 * [  LinkedIn ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?share=linkedin)
 * [  Print ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/#print?share=print)
 * [  Email ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?subject=%5BShared%20Post%5D%20Agree%20and%20Amplify%3A%20Funding%20Open%20Source%20as%20Digital%20Infrastructure&body=https%3A%2F%2Fjeffpaul.com%2F2026%2F01%2Fagree-and-amplify-funding-open-source-as-digital-infrastructure%2F&share=email)
 * [More](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/#)

 * [  Facebook ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?share=facebook)
 * [  Nextdoor ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?share=nextdoor)
 * [  Pinterest ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?share=pinterest)
 * [  Reddit ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?share=reddit)
 * [  Telegram ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?share=telegram)
 * [  Tumblr ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?share=tumblr)
 * [  WhatsApp ](https://jeffpaul.com/2026/01/agree-and-amplify-funding-open-source-as-digital-infrastructure/?share=jetpack-whatsapp)

### Like this:

Like Loading…
