The Extraction Problem: Why AI Tokens and Django's Future Are Incompatible

A post went up on better-simple.com last week with a pointed title: give Django your time and money, not your tokens. It landed 365 points on Hacker News and sparked 142 comments, which tells you it hit something real. The argument is directed squarely at the current wave of AI-assisted development: instead of spending money on LLM API calls to help you write Django code, put that money toward the project itself. Instead of outsourcing your understanding to a language model, contribute back to the community.

That framing is worth sitting with for a moment, because it identifies something the broader AI productivity conversation tends to skip.

What Sustains Django

Django is maintained by the Django Software Foundation, a 501(c)(3) nonprofit incorporated in 2008. The DSF funds development primarily through the Django Fellows program, which pays a small number of developers to work on Django full-time: triaging tickets, reviewing pull requests, cutting releases, and doing the unglamorous maintenance work that volunteers don’t reliably sustain.

The Fellows program typically employs one or two developers. In recent years that has included Mariusz Felisiak and Natalia Bidart. The DSF’s operating budget runs in the low hundreds of thousands of dollars annually, funded through individual donations and corporate membership tiers that top out at the Platinum level. For a framework that powers a significant slice of the web, from Instagram to Mozilla to NASA, the funding base is thin.

The math is stark. Django has tens of millions of deployments worldwide. The Fellows program costs somewhere around $200,000-$300,000 per year to maintain at its current level. If even a fraction of the companies running Django in production contributed at the lowest corporate membership tier ($2,000/year), the DSF could triple the fellows program overnight.

They don’t.

The Token Economy Argument

The article’s central provocation is this: developers and teams are now spending money on AI tokens, routed through OpenAI or Anthropic or whichever provider, to answer questions about Django that used to get answered on the forums, on Stack Overflow, or in the documentation. That money flows to AI companies, not to the maintainers of the software those AI companies were trained on.

This isn’t a new critique of AI systems generally, but the Django-specific framing makes it concrete. When a junior developer asks an LLM how to write a custom Django manager or how select_related differs from prefetch_related, that question doesn’t generate a Stack Overflow answer that future developers can find. It doesn’t add to the corpus of documented human understanding around Django. The knowledge transfer happens, but it stays private and ephemeral.

Over time, that hollows out the community layer. Stack Overflow answers for Django questions have been declining in volume. Forum participation has shifted. The publicly searchable, linkable, referenceable record of how people solve Django problems is growing more slowly than Django usage.

For the maintainers, this creates a specific problem. Ticket quality degrades when people stop engaging deeply with the framework before filing issues. Bug reports become harder to triage because the reporter has been using AI assistance to work around problems rather than understanding them. Pull requests arrive with AI-generated code that superficially looks correct but reflects no real understanding of Django’s internal conventions.

Comparing Sustainability Models

Django’s situation is interesting when compared to adjacent frameworks. Ruby on Rails has always had Basecamp (now 37signals) as its anchor sponsor. DHH and the 37signals team have strong economic incentives to keep Rails healthy, and they fund significant development time directly. This isn’t purely altruistic; it protects their primary business asset. But it provides structural stability that Django lacks.

Laravel has built a commercial ecosystem around the framework itself: Forge, Vapor, Nova, Envoyer. Laravel LLC captures value from the ecosystem and reinvests it in the framework’s development. Taylor Otwell and the core team are employees of a company whose business depends on Laravel’s quality. The funding alignment is direct.

Django has neither of these structures. No single company has a dominant stake in Django’s maintenance. The DSF depends on voluntary contributions from a fragmented base of companies and individuals. That model works when community engagement is high and the cost of participation is low. It gets fragile when engagement routes away from the project itself.

What AI Actually Changes

The skills atrophy argument deserves examination. When developers rely heavily on AI to answer their Django questions, they may learn the framework more slowly or less deeply. This matters because the pipeline from user to contributor runs through understanding. You can’t submit a meaningful bug fix for the ORM if you don’t understand how the ORM works. You can’t improve the documentation if you’ve never struggled through it yourself.

AI assistance lowers the cost of using a framework without necessarily deepening the user’s relationship with it. That’s useful for productivity, but it changes who is likely to become a contributor. The developer who spent three hours fighting with Django’s form validation and eventually understood why it works the way it does has a different relationship to the project than the developer who asked an LLM and moved on in fifteen minutes.

The counter-argument is that AI lowers barriers to entry and grows Django’s user base, which should eventually translate into more contributors. This is plausible. More users means more potential contributors, and if even a small percentage engage more deeply, the community grows. The question is whether the conversion rate holds when the friction that traditionally drove engagement, the need to seek help from other humans, is reduced.

There’s also a documentation contribution angle. When people answer questions on forums, write blog posts explaining Django patterns, or contribute to Stack Overflow, they generate training data that future AI systems can use. The original article notes that this creates a kind of commons, and using AI to extract answers from that commons without replenishing it is a form of depletion. The Django community’s collective knowledge took decades to accumulate; it doesn’t replenish automatically.

What Contributing Actually Looks Like

The practical recommendation in the article is correct, even if the framing is provocative. Contributing to Django doesn’t require heroic effort.

The DSF donation page accepts one-time and recurring contributions. If your company ships Django in production, corporate membership starts at $2,000 a year. That’s a rounding error in most SaaS engineering budgets.

Time contributions don’t have to be code. The Django ticket tracker has an ongoing backlog of issues that need triage, reproduction, and verification. Confirming that a bug exists, identifying its scope, or testing whether a proposed fix actually resolves it is useful work that doesn’t require deep Django expertise.

Documentation improvements are perennially welcome. The Django docs are good, but gaps and ambiguities accumulate faster than volunteers address them. Writing up a pattern you figured out the hard way, or clarifying a section that confused you when you were learning, has direct value.

Answering questions on the Django forum or in the official Discord generates that publicly searchable record of human expertise. It also develops your own understanding in a way that asking an LLM doesn’t.

The Broader Point

The article’s argument is ultimately about sustainability, not moralism around AI use. Open source infrastructure runs on a combination of volunteer labor and organizational funding, and both of those inputs are sensitive to where developers direct their time and money. Django is one of the few major frameworks that doesn’t have a commercial anchor, which makes it more dependent on community participation than most.

The AI productivity wave is real and it’s not going away. But the tools that make developers productive are built on top of software that someone has to maintain. The Django Fellows program is that someone for a significant chunk of the web. Whether it gets funded adequately depends on whether the people and organizations who depend on Django think about that relationship or treat the framework as an infinite free resource.

Giving Django your time and money isn’t a sacrifice. It’s maintenance on infrastructure you’re already depending on.