There is a particular kind of optimism that treats a cost reduction on one side of a transaction as a solution to a problem that lives entirely on the other side. When people say they are “contributing to Django with AI,” this is what they are doing. The article “Give Django your time and money, not your tokens” names this clearly, and the Hacker News response (405 points, 162 comments) suggests it touched a nerve that has been exposed for a while.
The argument is not complicated, but it is easy to miss if you are not a maintainer. Generating a pull request has become nearly free. Reviewing it has not moved at all.
What the Django Fellowship Actually Is
Django is stewarded by the Django Software Foundation, a nonprofit that funds two critical things: the infrastructure that keeps the project running, and the Django Fellowship program. The Fellowship, which launched in 2014, pays developers to do the maintenance work that nobody sponsors: triaging tickets, reviewing patches, merging PRs, handling security disclosures, cutting releases. This is not glamorous work. It is the connective tissue that keeps a project used by Instagram, Mozilla, Disqus, and hundreds of thousands of smaller applications from slowly rotting.
The Fellows, people like Mariusz Felisiak who has been doing this work for years, handle the day-to-day continuity of a codebase that has kept a rigorous backwards compatibility policy since the 1.0 release in 2008. That policy is load-bearing. Millions of projects depend on Django not breaking their code across versions. Maintaining it requires judgment that is contextual, historical, and deeply human.
The DSF funds this through individual donations, corporate sponsors, and DjangoCon revenue. The budget is always constrained. When the Fellowship loses funding, that work does not get done by AI. It gets done by nobody.
The Asymmetry Problem
Before large language models, the barrier to submitting a patch was roughly proportional to the barrier to reviewing one. Writing a reasonable fix to a non-trivial Django bug required understanding the codebase, the design philosophy, and the implications for existing behavior. If you could do that, you were probably capable of writing something worth reviewing. The skill floors were matched.
That symmetry is gone. A developer who has never read a line of Django’s source code can now generate a syntactically plausible, test-passing patch in a few minutes. The LLM has absorbed the surface-level pattern of what a Django contribution looks like. What it has not absorbed is the judgment to know whether that patch is correct with respect to Django’s backwards compatibility commitments, whether it introduces subtle ORM behavior changes, or whether it conflicts with a Django Enhancement Proposal that was accepted two years ago.
A maintainer reviewing that patch has to do all of that work. The cost to the contributor approached zero. The cost to the reviewer did not move.
At scale, this is a serious problem. If a project’s incoming PR rate doubles because generation became cheap, but its review capacity stays fixed because it is limited by the number of paid Fellows and engaged core contributors, the project does not get more done. It gets slower. Maintainers spend more time evaluating contributions that do not pan out. The ratio of merged patches to reviewer-hours spent gets worse, not better.
This is not hypothetical. Maintainers across many projects have been describing exactly this dynamic since late 2023, often in the context of shutting down open submissions or adding explicit AI-generated contribution policies.
Why “I’ll Use AI to Contribute” Misses the Point
When the Django community asks for support, there are two separate asks that people frequently conflate.
The first is financial. The DSF needs money to pay the Fellows. Corporate users of Django, companies running significant revenue on a framework they did not build and do not fund, could change this immediately. Sponsorship tiers exist. Most companies that could afford to sponsor choose not to. An LLM subscription does not fix this.
The second is skilled human attention. Django has open tickets that require deep familiarity with the ORM, the template engine, the migration system. The ticket tracker has issues that have been waiting for experienced eyes for years. This is not a writing problem. It is a judgment problem. Generating a response to a ticket with an LLM and submitting it as a contribution is not the same as actually understanding the issue and working through its implications. The maintainer still has to do that work; now they also have to do it in response to your generated text.
The framing of “tokens” in the original article is pointed precisely because it works in both directions. You spend LLM tokens, which are cheap and abundant, to produce something that costs the project time and money to process. The play on words is not decorative. It describes the actual economic transfer.
The Broader Pattern
Django is not alone in this. The Rust ecosystem has the Rust Foundation with its own funding pressures. The Python Software Foundation funds CPython infrastructure and developers. NumPy and SciPy survive partly through grants from the Chan Zuckerberg Initiative and similar programs. These are patches over a structural problem: enormous commercial value extraction from software that is maintained by a small number of funded developers and a larger number of volunteers who eventually burn out.
The reason the original article resonates is that AI tools have given companies and developers a new narrative for why they do not need to engage with this problem. We are “contributing” now. We have AI. The open source sustainability crisis looks like it might be self-solving because the barrier to generating a patch dropped. It is not self-solving. The barrier to reviewing a patch did not drop. The barrier to making an architectural decision did not drop. The barrier to handling a security disclosure certainly did not drop.
What Actually Helps
For individuals: the Django Software Foundation donation page takes recurring contributions. Even small amounts, sustained, fund Fellowship time. If you use Django professionally and have not donated, that is the highest-leverage action available to you.
For companies: the DSF has corporate sponsorship tiers that are modest relative to the engineering value most commercial Django users extract. Sponsoring is not charity; it is paying for infrastructure your business depends on.
For developers who want to contribute technically: the contribution guide describes a path that starts with triaging tickets, not writing code. Reading existing issues, reproducing bugs, and providing clear reproduction cases is unsexy work that genuinely helps maintainers. It requires no special expertise to start, and it builds the contextual knowledge that makes eventual code contributions actually useful.
Using an LLM to do any of these things for you is not contributing. It is adding to the queue.
The economics here are not mysterious. Django has operated as a public good for over twenty years. The cost of that good is real and it falls on a small number of people. AI changed what it costs to generate a pull request. It did not change what it costs to run a software project that half the web depends on. Those are different things, and conflating them helps nobody.