A Million Kakapos

Agentic coding is the hot new thing. I've been doing it since the GPT3 days back in 2021. Everyone doing it has decided that coding is now 'basically free'. Prior to this you needed great programmers to make great software. Becoming a programmer with good skill takes a lot of work. Now that LLMs can code fairly well, where does that leave Open Source software? This article is about Open Source software and what could happen to it in a world where writing code is no longer scarce.

Efficiency vs Robustness

Darwin is often misread. We are taught "Survival of the fittest" (Herbert Spencer coined that term, not Darwin) and imagine a competitive world where the strongest survive. Evolution is often thought of as some kind of optimization process. What is often misunderstood is time horizons and what is being "optimized". If an animal is optimized for its environment, it subjects itself to a huge risk: What if the environment changes?

The Giant Panda is a creature that is hyper optimized for its environment. It's diet is about 99% bamboo, and it has evolved a specialized thumb which helps it strip bamboo. However bamboo can go through synchronous flowerings and die-offs which make it difficult for the panda to survive. The Giant Panda was an endangered species for decades and survives now because we help it survive. In other words, evolution over the short term optimized the panda to be fit for a niche environment, but over the long term has created a very fragile creature, unable to adapt to variance in its environment.

The Kakapo is another creature that became highly optimized for its environment. With no natural land predators, it evolved in New Zealand and optimized for energy conservation. It abandoned expansive flight, grew heavy, and has a long multi-year breeding cycle. Worst of all, it evolved to freeze when startled which make it easy prey for land mammals like rats and cats. It is another species on the endangered list with only 240 left.

If you look at a narrow time scale where the climate has not shifted much, you get animals that are highly optimized for their regions. However, over a much longer time scale, where variance of the environment is felt, you get animals that can adapt to a variety of environments. Think of animals like cockroaches, which have been around almost 400 million years. Cockroaches can digest almost any organic matter. They can survive weeks without food and water. They are found in a huge variety of environments from tropical rainforests, dry deserts, temperate woodlands, caves, and now human habitats.

Think of sharks, which have been around 450 million years. Sharks have an amazing olfactory system and can locate prey from long distances in zero visibility. They have electroreception as well to help them find prey. They occupy a huge assortment of environments like coral reefs, open oceans, abyssal depths, arctic ice sheets, and even fresh water river systems. Their diets are highly flexible and they are able to readily shift their target prey based on the environment.

Over long time horizons, evolution selects for adaptive, robust creatures, not highly optimized performant ones. It selects for creatures with redundancies and adaptive systems. Cockroaches for example have a decentralized nervous system. You can take the head off a cockroach and it will stand, walk around, run away, and react to stimuli for weeks until it dies of dehydration. Sharks have redundant rows of teeth. Instead of evolving a single set of highly specialized teeth, which would give it fragility, Sharks have redundant rows of teeth which migrate forward, replacing older ones, throughout their life. To find prey, sharks have redundant sensory systems like their olfactory system, eletroreception, lateral line systems (which help them detect water movement and pressure), and sight. A blind shark could still feed and survive.

Systems of redundancy and adaptability are not performant. They cost the animal a lot in terms of energy. The metabolic cost for sharks having to replace thousands of teeth over their lifetime requires constantly creating new ones. Maintaining multiple overlapping sensory systems requires a high amount of 'standby power'. For cockroaches, their distributed neural system isn't as efficient as having a centralized brain. Neurons are some of the most energy intensive tissues. In humans the brain consumes 20% of the resting energy.

In other words, Sharks and Cockroaches are not efficient creatures. They burn more energy than animals without these redundancies. However, it is these inefficiencies that allow them to survive over extremely long time horizons as species.

Performant animals cannot be robust, and robust animals cannot be performant.

Scarcity Promotes Cooperation not Competition

There is a widespread misunderstanding about competition. We are taught that competition is about scarcity, innovation, and the efficient allocation of resources. In economics, the playground of competition is the market, traditionally defined as the mechanism to allocate scarce resources. Conventional wisdom holds that competitive markets are the most efficient way to achieve this via the price signal.

But this is a myopic view. We need to look at it systematically. Markets, like evolutionary niches, are engines for local optimization and short-term performance. Competition is really only possible in environments of abundance, not scarcity!

Let's look at ecology for a moment. The ecologists Mark Bertness and Ragan Callaway developed the Stress-Gradient hypothesis. The hypothesis states that as environmental conditions become more severe and resource-scarce, positive non-trophic interactions like facilitation, mutualism, and cooperation systematically replace competition. For example, in lush resource rich grass lands, plants compete with each other to get sunlight and canopy space. However, in salt marshes, alpine tundra, and deserts, plants clump together into tight nurse-plant groups. In tundras they clump to protect each other from freezing winds. In deserts, the clumping creates shade, helping the soil hold more moisture. Solitary competitors die, while cooperating ones survive.

Economics often talks about the "Tragedy of the Commons" which Garrett Hardin famously argued that when critical resources are scarce, individuals acting competitively will deplete and destroy them. However, the political economist Elinor Ostrom studied real-world communities managing scarce resources over centuries. She studied water allocation in the arid Spanish huertas, communal grazing in the Swiss meadows, and coastal fisheries in Turkey. Ostrom proved that when faced with scarcity, people do not default to market competition or centralized tyranny. Instead, they spontaneously develop cooperative self-governance, mutual monitoring, and communal sharing organizations. These sustainably manage resources for generations. She won a Nobel in Economics for this work in 2009.

If you take a moment to think about it, markets require abundant environments because they require slack for failure. For a market to have multiple companies competing for the same product, there needs to be enough resources to waste when inevitably some of them fail. These companies have duplicative functions, competing R&D teams, often working on the same problem, duplicative management functions and overhead. Larger companies can share resources cooperatively across groups. This "slack for failure" is what allows competitors to exist in markets. It is abundance at the systemic level, not scarcity. Competitive markets are the lush grasslands of the economic world, not the cold tundras or arid deserts.

Open Source is an Adaptive Survival Strategy

Building software is some of the most complex endeavors humanity has ever attempted. Doing it well requires highly organized, scarce teams of competent and specialized minds with deep knowledge and skill.

In the early days of computing, hardware was the expensive bottleneck while software was often shared freely. By the 1980s, the microcomputer revolution created a massive surge in market demand, leaving software companies flush with cash. In that environment of surplus capital, the tech sector indulged in the luxury of the proprietary software model. It was the golden age of closed-source software. Microsoft and its peers competed fiercely, locking code behind secret walls and spending enormous sums building parallel, proprietary stacks from the ground up.

However, by the late 90s, a new constraint emerged! The sheer scarcity of software engineering talent.

As the world became more connected because of the internet and digital infrastructure could expand across the globe, the demand for complex software exploded much faster than the supply of skilled developers. The "metabolic" cost of proprietary competition, having dozens of competing corporations pay scarce teams to rewrite operating system kernels, filesystems, network protocols and compilers from scratch, became untenable and economically ruinous. Proprietary duplication became a luxury the market could no longer afford.

In response, the tech industry did what living systems under severe ecological stress have always done, it pivoted from competition to cooperation.

Universities and research labs have always had scarce resources, and it is in that environment the Free Software movement had quietly built a culture of shared software. In the late 90s, the ethos was pragmatically rebranded for enterprise as Open Source. Open source was not some act of corporate altruism or charity, it was an adaptive survival mechanism. Building foundational software became brutally difficult as engineering talent was scarce, so pooling developer hours into a shared commons like Open Source systematically out-survives closed, redundant competitors.

This transition played out across every foundational layer of computing:

• At the turn of the millennium, IBM made a $1 billion bet on Linux. IBM was struggling to maintain five seperate and incompatible proprietary operating systems like OS/400, AIX, OS/2, MVS, and VM. Each of these required dedicated teams of engineers working on the kernel, filesystem, and hardware drivers. Under this expensive weight, IBM made the radical decision to invest $1 billion into the Linux kernel and assigned hundreds of its top engineers to contribute to the community. They recognized that the OS was plumbing, not a differentiator. By sharing the maintenance burden with their rivals like Red Hat, HP, and Oracle, IBM eliminated the wasteful duplication tax of building this plumbing.
• In the mid-90s, webmasters all around the world desperately needed a reliable web server. Instead of fifty separate startups assigning scarce C programmers to write proprietary servers from scratch, a loose coalition of engineers began emailing each other bug fixes and patches, creating "a patchy server". The Apache HTTP server project was born. Eventually Apache would run most of the web, at its peak serving over 60% of all websites.
• In 2018, even the mighty Microsoft surrendered developing a competing browser engine and built their next browser, Edge, on top of the Chromium project. Engines are so hard to make that virtually all tech companies are helping build Chromium and Firefox. Some are saying maybe even Firefox is too much for the industry to maintain.
• For decades, chipmakers and software giants redundantly hired separate compiler teams. By the mid-2000s, most of the industry converged around the open-source LLVM project. Today, Apple, Intel, Google, Sony, and even ARM co-maintain the project. Even fierce commercial competitors share this foundation because no firm has enough compiler geniuses to out-build the LLVM project.

Software development became a digital commons because, like ecosystems, they learned the fundamental rule of systemic robustness. When resources are scarce, cooperation (not competition) is the only viable strategy.

Companies shared the metabolic cost of survival doing what Joel Spolsky called "commoditizing your complement". They stopped wasting building redundant competing systems and instead allowed the software ecosystem to build on a shared foundation.

The Open Source ecosystem ended up with the same shape as that of the shark. It is full of redundancies that look like pure waste if viewed through an efficiency lens. Glibc and musl, GCC and Clang, OpenSSL and LibreSSL. But when the Heartbleed bug hit OpenSSL in 2014, the forks were what let the ecosystem mitigate the damage. These forks buy survival, and they only exist because the cooperative nature of open source had enough shared surplus to sustain them.

Open Source in an Abundant World

Github has been in trouble recently. On August 17th 2026, github was unusable for almost 8 hours. The reason for the failure was surprising, in that it didn't have anything to do with software or configuration updates or hardware failures. The load the servers got was just too high! They showed a graph of the exponential rise of PRs, commits, and new repos.

For all of 2025 and 2026 I have waited for data to show that LLM coding agents have increased productivity of writing software. I contend that the data is now showing this. We don't have an exponential rise in software engineers, but we do have a rise in software coding agents.

In other words, it appears that writing software is no longer scarce. The engineering talent required to write code is no longer necessary. We can argue about the quality of the code but what we can't argue is that coding agents can create code faster than people can, and it kind of works most of the time.

We already know what happens to a commons maintained by too few hands. Log4J had a huge vulnerability in 2021 called Log4Shell that had existed since 2013. It affected roughly 93% of enterprise cloud environments. One under-resourced library became load-bearing for nearly everything. The xz backdoor in 2024 went further. Years-long social engineering against a single volunteer maintainer nearly slipped a backdoor into SSH. It was caught only because one engineer noticed his SSH logins taking half a second longer than before. The commons was already running on fumes before the coding agents arrived.

This rise in PRs, commits, and new repos is NOT a good sign for open source software. Much of this could be private repos but also a huge rise in single person software projects. I argue we are seeing a shift back to a competitive software ecology, away from the traditionally cooperative open source one.

Companies can now cheaply build competing software systems and the social pull to create open source projects by these companies will go away. We don't even need to speculate about abundance ending cooperation because it started to end even before AI coding arrived. Cloud revenue made a lot of SaaS companies rich. One open source company after another pulled out of the commons. Elastic, the company behind ElasticSearch, relicensed the software away from Apache 2.0 in 2021. Hashicorp moved Terraform to the Business Source License in 2023. Redis abandoned its BSD license in 2024. In every case, a company decided it could afford to no longer cooperate.

With resources going into competitive rather than cooperative software building, the Open Source commons will shrink. Don't let the exponential rise in github repos fool you. I'm sure many of them are public, but they are likely all single author and competitive, not cooperative. Even before this explosion in coding, the vast majority of open source projects had one or two contributors. Only the best funded ones had more. You cannot escape the Pareto distribution.

The Era of Private Software

Over the last 6 months I've been talking with so many people who have never coded before but have discovered Claude and have been making software. A lot of it is software that solves some specific personal problem which they never intend to share with others. Some of it is from people trying to create new companies and are leveraging their domain knowledge to build something that would have needed a team of 5 people before.

We are seeing a rise in what I like to call 'private' software. Software that is never shared outside of someone's computer or company. You can buy proprietary software, but you can't even buy private software. We will continue to see a rise of bespoke solutions created and maintained by a single person for themselves or their company.

This is what happens when you reduce scarcity. Jevons paradox has now become a term in the mainstream. We are seeing an explosion of software, a lot of it duplicative, often implementing the same solutions to similar problems, because the scarcity of being able to write code is no longer there.

Private software is a Kakapo. It will be perfectly fitted to one person's environment. To their machine, their workflow, their company's quirks. There will be little code review, no forks, no other maintainers. No protection against the bus-factor. It will thrive as long as someone maintains it (or can afford the tokens to).

The open source commons was created because engineers were scarce. It slowly created robust software used by everyone. Forks created redundancy and robustness. Because coding is no longer scarce, we are abandoning the commons for a million Kakapos. This will only stay possible as long as the tokens keep flowing.

Sources

• Herbert Spencer, Principles of Biology (1864) — origin of the phrase "survival of the fittest"
• IUCN Red List entries for the Giant Panda (Ailuropoda melanoleuca) and Kākāpō (Strigops habroptilus); NZ Department of Conservation, Kākāpō Recovery Programme
• Mark Bertness & Ragan Callaway, "Positive interactions in communities," Trends in Ecology & Evolution 9(5), 1994 — the Stress-Gradient Hypothesis
• Garrett Hardin, "The Tragedy of the Commons," Science 162, 1968
• Elinor Ostrom, Governing the Commons: The Evolution of Institutions for Collective Action, Cambridge University Press, 1990
• IBM's $1 billion Linux investment, announced December 2000
• The Apache HTTP Server Project, Apache Software Foundation
• Microsoft, "Microsoft Edge: Making the web better through more open source collaboration," December 2018 — the move to Chromium
• The LLVM Project (llvm.org)
• Joel Spolsky, "Strategy Letter V," Joel on Software, June 2002 — "commoditize your complement"
• GitHub incident report, August 17, 2026 (link the specific status page / postmortem)
• William Stanley Jevons, The Coal Question, 1865 — origin of the Jevons paradox