Your AI Tool Bills More Per Month Than Django Gets From Most Companies

A post on better-simple.com making the rounds on Hacker News this week carries a title that lands harder than it probably intended to: Give Django your time and money, not your tokens. The argument is straightforward. Django, one of the most widely deployed web frameworks in existence, is sustained by a non-profit foundation running on a budget that most engineering teams spend on SaaS subscriptions before lunch. The word “tokens” does double duty: it gestures at AI API usage, but also at the broader habit of treating open source as infrastructure you consume rather than something you maintain.

Both meanings are worth taking seriously.

What the Django Software Foundation Actually Funds

The Django Software Foundation is a 501(c)(3) non-profit. Its primary ongoing expenditure is the Django Fellows program. Fellows are paid, part-time or full-time contractors who handle the maintenance work that keeps Django functional across releases: triaging bug reports on the Django issue tracker, reviewing pull requests from contributors, cutting releases, and managing the relentless administrative overhead of a project used by hundreds of thousands of developers.

Without Fellows, all of that work falls to volunteers with day jobs. The DSF has historically operated with one or two Fellows at a time. Mariusz Felisiak has been a Fellow for several years and is one of the most active contributors to Django’s core. Carlton Gibson served as a Fellow and contributed substantially to Django REST Framework and async Django support before stepping down. These are not peripheral roles. The Fellows are the load-bearing wall.

The DSF funds this through a tiered corporate sponsorship model and individual memberships. Corporate tiers range from Bronze through Diamond. The actual dollar amounts have shifted over the years, but the gap between Django’s economic footprint and its financial support has remained consistently wide. Django powers Instagram’s backend stack (or did for many years), countless e-commerce platforms, news organizations, and government services. The framework’s contribution to global software output is not measurable in a way that rounds to anything small. The DSF budget does not reflect that.

The Fellows Do Work That Doesn’t Show Up in Commit Counts

There is a specific kind of open source labor that is invisible to anyone who only watches merged PRs. Issue triage is one example. The Django issue tracker receives hundreds of reports per year, ranging from genuine bugs to misunderstandings about documented behavior to security disclosures that require careful handling. Someone has to read each one, reproduce the problem or explain why it isn’t a bug, assign it correctly, follow up when reporters go silent, and close it when it’s resolved. That work does not produce a diff. It does not show up in a contributor graph.

Release management is similar. A Django release involves coordinating deprecation warnings from previous cycles, writing release notes, updating compatibility matrices, verifying that the test suite passes across supported Python and database versions, publishing packages to PyPI, and communicating the change clearly to the community. The actual time investment for a minor release can run into days of focused work.

This is what the Fellows program buys: people who show up consistently to do unglamorous maintenance work that keeps the project healthy. It is not glamorous and it does not trend on social media. But when you run pip install django and get a working framework with a functioning security disclosure process, this is what you are benefiting from.

The AI Angle Is Not Subtle

The “tokens” framing in the original article is pointed. Every major AI coding assistant, from GitHub Copilot to Cursor to various Claude and GPT-based tools, was trained on open source code. Django’s codebase, its documentation, the thousands of Stack Overflow answers about Django patterns, the Django REST Framework source code, the countless blog posts explaining Django’s ORM, all of this fed into training corpora. The resulting models are now being sold as productivity tools, billed monthly, often at prices that dwarf what the companies using those tools contribute to the projects the models learned from.

This is not a new argument. The open source community has been having variations of this conversation since Log4Shell made the maintenance cost of critical infrastructure impossible to ignore. But the AI layer adds a specific dimension: the value extraction is now happening at a remove that makes it easier not to think about. When a developer uses Copilot to generate a Django view function, the mental model is “AI tool helped me,” not “the Django codebase and years of community-written examples helped me via AI tool.” The abstraction breaks the feedback loop that might otherwise prompt contribution.

The economics compound in a specific way. A development team paying $50 per seat per month for an AI coding assistant is contributing to a company that built its product partly on Django’s existence. That same team may never have sponsored the DSF, contributed a PR, or paid for an individual DSF membership. The value flows one direction.

How Other Frameworks Handle This

Django’s situation is not unique, but it is instructive to compare it to peers. Ruby on Rails is backed by 37signals (formerly Basecamp), which employs DHH and others who work on Rails as part of their product work. Rails has always had a more direct commercial backer embedded in its governance. Laravel has Spatie and Laravel LLC, and Taylor Otwell has built a commercial ecosystem around the framework (Forge, Vapor, Nova, Envoyer) that funds continued core development. FastAPI is sponsored by Tiangolo’s consulting work and various GitHub sponsors, though it faces its own sustainability questions as adoption has grown faster than funding.

Django’s model is older and more classically non-profit. It relies on the goodwill of corporate sponsors and individuals who understand that the framework they are building on needs financial support to remain viable. That model works when a critical mass of users convert to contributors or donors. It strains when most users treat the framework as ambient infrastructure.

The comparison to curl is worth noting. Daniel Stenberg has maintained curl for decades, a tool embedded in essentially every networked system on earth, largely on a volunteer basis with modest sponsorship. The scale of curl’s deployment relative to its resourcing is staggering. Django is in a similar position at a different layer of the stack.

What Contribution Actually Looks Like

The original post is essentially a call to action, and it is worth being concrete about what that means in practice.

The DSF has a membership program for individuals. Becoming an individual member is a direct, low-friction way to contribute financially. The amount is modest and the process is simple. For corporate users, DSF sponsorship tiers are available and the sponsor page lists current supporters.

Time contributions are different. If you want to contribute code, Django’s contributing guide is detailed and the core team is responsive to well-prepared patches. But code contributions are not the only path. Documentation improvements, answering questions on the Django Forum, reviewing pull requests, and helping triage issues are all legitimate forms of contribution that have real impact.

One underappreciated lever is organizational. If you work at a company that builds on Django, and that company has a tooling budget, making the case internally for a DSF sponsorship is a different kind of contribution. It requires political capital, not just time, but the impact is larger than an individual membership. The DSF’s corporate sponsor list has included Heroku, JetBrains, Lincoln Loop, and others. Many companies building on Django are not on that list.

The Sustainability Math

The deeper issue here is structural. Open source has a free-rider problem that is well-documented and genuinely hard to solve. The frameworks and libraries that power the internet are maintained by a small number of people, most of them working without compensation that reflects their impact. This is not a criticism of individual developers who use Django without contributing; most people are not aware that the DSF exists or that there is a Fellows program to fund.

But the AI moment has sharpened the stakes. The systems being built on top of open source foundations, including the AI tools themselves, are generating significant commercial value. Some of that value should cycle back into the infrastructure it depends on. The DSF is not asking for much. A few thousand dollars in corporate sponsorship, or a few hours per month of code review, moves the needle for an organization operating at that scale.

The better-simple.com post has a simple thesis: Django gave you a framework. Give something back. The AI framing is clever packaging for an argument that stands on its own. Open source sustainability is not solved by awareness alone, but it does require developers and organizations to connect the tools they use to the maintenance costs those tools carry. Django has been maintained well for over twenty years. Whether that continues depends, in part, on whether the people using it decide it is worth supporting.