Open source and its quiet crisis¶

The Patrician has observed that Ankh-Morpork’s infrastructure relies heavily on systems that nobody officially maintains but that everyone assumes will continue functioning indefinitely. The ancient sewers built centuries ago by people whose names are lost to history, the water supply that somehow continues delivering despite nobody being quite certain how it all connects, and the street lighting maintained by individuals who do it because someone must and they happened to be there when it needed doing.

Open source software occupies a similar position in technology infrastructure. Enormous portions of the internet, cloud computing, and modern applications rest on software written by volunteers, maintained sporadically, and assumed to be reliable because it has been reliable thus far. This arrangement worked adequately during open source’s growth phase when enthusiasm was high and commercial dependencies were modest. It works less adequately now that Fortune 500 companies generate billions in revenue using infrastructure maintained by individuals who do it between other commitments and who receive neither compensation nor even consistent appreciation.

The crisis is quiet because the infrastructure mostly continues functioning and because the people maintaining it are generally too busy maintaining it to complain publicly about the unsustainability of current arrangements. The crisis is real because the gap between the value extracted from open source and the resources invested in maintaining it grows wider annually, because key maintainers burn out and abandon projects regularly, and because eventually something critical will fail at an inopportune moment when the volunteer maintaining it has moved on and nobody else understands how it works.

The Patrician notes that systems maintained through goodwill and volunteer effort are admirable but fragile, that assuming these systems will persist indefinitely without investment is optimistic bordering on delusional, and that the technology industry has constructed commercial empires on foundations maintained by people who could stop at any moment for any reason because they’re volunteers who owe you nothing.

The economics that don’t add up¶

Open source operates on economic logic that makes sense for individuals sharing code but breaks down when the code becomes critical infrastructure supporting billion-euro businesses. A developer writing a library to solve their own problem and sharing it freely is reasonable behaviour. That same library becoming dependency for thousands of commercial products while the developer continues maintaining it unpaid in their spare time is exploitation masquerading as community.

The value extraction is straightforward. Companies build products using open source components, sell those products or services for substantial sums, and pay nothing to the people who wrote the components their business depends on. The economic value created by the products vastly exceeds any costs to the companies using open source because the costs are externalized to maintainers who provide labor voluntarily.

The value creation is concentrated at corporations while the maintenance burden remains distributed across individuals. A company might generate millions in revenue using a particular library while the person maintaining that library does so unpaid in evenings and weekends. This arrangement benefits the company tremendously and benefits the maintainer not at all financially, which is sustainable only while the maintainer remains willing to work for free.

The sustainability problem arises when maintainers realize they’re providing free labor enabling others’ profits or when they simply become tired of maintaining projects that provide them little benefit. Maintainers abandoning projects is common, which either leaves projects unmaintained or forces succession to new maintainers who must learn complex codebases without compensation or adequate documentation from predecessors who left because they were burned out.

The security implications are concerning because critical infrastructure is maintained by individuals who may lack resources, time, or expertise to address security issues properly. The Heartbleed vulnerability existed in OpenSSL for years despite OpenSSL being used everywhere because the project was maintained by a small team with minimal funding. This pattern repeats regularly where critical libraries have security vulnerabilities that persist because nobody is paid to audit them or fix them promptly.

The Patrician observes that expecting critical infrastructure to be maintained by volunteers is the economic equivalent of expecting your city’s water supply to be maintained by people who do it for fun in their spare time. It might work temporarily but eventually someone needs to check whether water system maintenance is actually someone’s job rather than just something that happens through collective goodwill.

The corporate response and its inadequacies¶

Large technology companies have recognized the open source sustainability problem and have responded with contributions that are simultaneously genuine and inadequate. They sponsor some projects, employ some maintainers, and contribute code when it aligns with their interests. These contributions help but don’t solve the fundamental mismatch between value extracted and resources provided.

Corporate open source programs employ developers to contribute to projects the companies use. This is helpful and companies doing this should be acknowledged, but the programs typically focus on projects directly important to the company rather than the dependency tree of smaller projects those projects depend on. The small libraries deep in dependency chains continue being maintained by volunteers while the visible projects get corporate support.

Corporate sponsorships provide funding to prominent open source projects through foundations, direct funding, or employment of key maintainers. GitHub sponsors, corporate donations, and foundation support have improved funding for some projects. The amounts remain modest compared to the value extracted, and distribution is uneven with prominent projects receiving attention while obscure but critical dependencies receive nothing.

The selection bias is substantial where companies support projects important to them while ignoring projects they depend on indirectly. The dependency chains are deep and most companies don’t know their full dependency tree, which means they’re often unaware of which small projects their entire infrastructure depends on. These unknown dependencies remain unfunded until they fail dramatically enough to be noticed.

The contribution patterns show that companies contribute to projects where they need features or fixes rather than sustained maintenance. A company might contribute substantially to add capabilities they need but contribute nothing to ongoing maintenance, security audits, or documentation. The contributions are transactional rather than sustainable support for project health.

The open source foundations provide governance and funding infrastructure for larger projects but don’t solve sustainability for the thousands of smaller projects. The Linux Foundation, Apache Foundation, and similar organizations do important work for their member projects, but membership requires scale and organization that small maintainer projects lack. The foundation model works for large successful projects but doesn’t address the long tail.

The Patrician notes that corporate contributions are welcome but insufficient and that companies are good at contributing what serves their immediate interests while underfunding less visible maintenance work that provides no immediate benefit but prevents future disasters.

The maintainer burnout cycle¶

Open source maintenance is voluntary labor that people undertake for reasons ranging from genuine altruism through resume building to solving their own problems and sharing solutions. None of these motivations are sustainable when projects grow large enough to become demanding while remaining unpaid work.

The initial phase where creating open source projects is fun and manageable gives way to the maintenance phase where projects are established, users are numerous and demanding, and fun is replaced with obligation. Maintainers find themselves responsible for supporting code they wrote years ago for different purposes, answering issues from users who expect free support, and reviewing contributions from people who want features but won’t maintain them.

The demand scales with usage while the maintainer’s time does not. A library used by ten projects generates manageable support burden. The same library used by ten thousand projects generates issues, feature requests, security reports, and general correspondence beyond what a volunteer can reasonably handle. The maintainer is expected to remain responsive despite the work growing beyond hobby project scope.

The criticism and entitlement from users who treat open source as free technical support is demoralizing. Maintainers receive complaints about bugs, demands for features, and criticism about design decisions from people who contribute nothing to the project but who feel entitled to service because the software is free. The emotional toll of public criticism for volunteer work drives maintainers away regularly.

The transition to maintenance burden without corresponding authority or compensation creates situations where maintainers are responsible for projects they no longer control because forks, distributions, and vendors have modified the code and still direct support requests to original maintainers. The maintainer is expected to support versions and use cases they’re not responsible for but that users associate with them.

The burnout results in maintainers abandoning projects, which either leaves projects unmaintained or forces succession. The succession process is often informal and challenging because burned-out maintainers are rarely enthusiastic about training replacements, documentation is often inadequate, and potential successors must volunteer for responsibility that drove previous maintainers away.

The Patrician observes that expecting people to perform demanding, skilled labor indefinitely without compensation or even appreciation is unrealistic and that the surprise when maintainers eventually stop is itself surprising given how obviously unsustainable the arrangement is.

The licensing debates and corporate capture¶

Open source licensing began with idealistic goals about sharing code and enabling collaboration but has encountered commercial realities that complicate the original vision. Companies using open source to build competing services without contributing back has prompted licensing changes that restrict commercial use while maintaining open source principles for non-commercial purposes.

The cloud provider problem is central where companies like Amazon, Google, and Microsoft take open source software, offer it as managed services, and capture the revenue without contributing meaningfully to the original projects. The projects bear maintenance costs while cloud providers capture commercial value. This prompted licensing changes from companies like MongoDB and Elastic attempting to prevent this exploitation.

The licensing modifications create tensions between openness and sustainability. The new licenses restrict commercial use or require source distribution for services built with the software, which preserves some value capture for creators but limits the freedom that originally characterized open source. The debates about whether restricted licenses are truly “open source” are philosophically interesting but practically reflect the tension between openness and survival.

The corporate response to license changes is often hostility because restrictions threaten business models built on freely using and modifying others’ work. Cloud providers in particular resist licensing changes that would require sharing revenue or source code. The resistance is economically rational for the providers but reflects that they’ve built businesses depending on continued free access to others’ labor.

The forking and alternative projects emerge when licensing becomes restrictive. The OpenSearch fork of Elasticsearch and similar projects allow continued open source development under permissive licenses while the original projects move to restricted licenses. These forks sometimes succeed and sometimes fragment the community without solving sustainability problems.

The governance debates about who controls open source projects and who can change licenses create conflicts between original creators, major contributors, and communities of users who have different interests in project direction. The conflicts are about power and control as much as about ideals, and they’re rarely resolved cleanly.

The Patrician notes that the licensing debates reflect the fundamental tension between creating value through open collaboration and capturing value necessary for sustainable maintenance, and that no licensing approach perfectly balances these competing goals.

The security time bombs¶

Open source security depends on maintainers having time, expertise, and resources to address vulnerabilities promptly. Many maintainers have none of these, which creates security risks throughout the software supply chain where vulnerabilities persist because nobody is responsible for or capable of fixing them quickly.

The Log4j vulnerability illustrated this dramatically when a severe vulnerability in widely-used logging library required urgent fixes while the maintainers were volunteers maintaining the project in spare time. The global scramble to patch systems demonstrated how much critical infrastructure depended on a small team of unpaid maintainers. The vulnerability was fixed quickly due to urgency and volunteer effort, but the episode highlighted systemic fragility.

The dependency depth means that vulnerabilities in small libraries affect vast numbers of downstream projects. A vulnerability in a parsing library used by thousands of other libraries potentially affects millions of applications. The maintainers of the small library are expected to fix vulnerabilities promptly despite being unpaid volunteers while companies depending on their work are frantically demanding patches.

The notification and coordination challenges when vulnerabilities are discovered are substantial. Security researchers must locate maintainers who may be unresponsive or unavailable, coordinate disclosure, develop fixes, and manage public disclosure. This process assumes maintainers are available and capable, which is not always true for volunteer-maintained projects.

The long-term maintenance for older versions that companies continue using in production is often unavailable. Maintainers focus on current versions while companies using older versions for stability need security fixes backported. The maintainers have no obligation to maintain old versions and often lack resources to do so even if willing.

The supply chain attacks that compromise open source packages to distribute malware are increasing because attackers recognize that compromising a widely-used package affects many downstream users. The defenses against this require vigilance from maintainers who may lack security expertise or time to properly vet contributions and detect sophisticated attacks.

The Patrician notes that treating security of critical infrastructure as a hobby activity for volunteers is optimistic and that the absence of major disasters thus far reflects luck as much as competence.

The path forward (such as it is)¶

Various approaches to improving open source sustainability are being attempted with varying degrees of success. None solve the problem completely but combinations might eventually create more sustainable arrangements.

Direct funding through GitHub sponsors, Patreon, and similar platforms allows users to support maintainers financially. This works for some prominent maintainers and provides modest income for others, but most maintainers receive little to no funding through these mechanisms. The model helps but doesn’t scale to the thousands of projects that need support.

Corporate funding programs where companies provide grants or employ maintainers of critical dependencies help specific projects but don’t systematically address the broader problem. The programs require companies to identify dependencies and allocate funding, which happens sporadically rather than systematically. The funding helps recipients but leaves most projects unfunded.

Foundation models where projects join organizations that provide governance, infrastructure, and funding work for large established projects but require maturity and organization that small projects lack. The foundations have admission requirements that exclude the long tail of smaller but still critical projects.

License changes that restrict commercial use or require contributions from commercial users are being attempted through licenses like SSPL and BSL. These approaches preserve some value for creators but fragment the ecosystem between truly open and restrictively licensed software. The long-term viability is uncertain.

Government funding for critical open source infrastructure is being explored in some jurisdictions recognizing that software used by government and industry might warrant public support similar to physical infrastructure. The programs are early stage and modest relative to the need, but they acknowledge that critical infrastructure requires investment rather than depending on volunteer labor.

The corporate in-house approach where companies employ their own maintainers for dependencies they use provides sustainable support but requires significant investment and expertise. Most companies lack resources or inclination to do this, preferring to consume rather than support open source.

The realistic assessment is that no single approach solves open source sustainability and that improvements will come through combination of funding mechanisms, license adjustments, corporate responsibility, and possibly government support for critical infrastructure. The pace of improvement is slow relative to growing dependency on open source, which means the vulnerability persists.

The Patrician’s assessment¶

Looking at the state of open source infrastructure with appropriate concern for sustainability, The Patrician concludes that current arrangements are unsustainable, that something will eventually fail dramatically when a critical component loses its volunteer maintainer, and that the technology industry should be embarrassed about extracting billions in value from labor they refuse to adequately compensate.

The fundamental problem is that open source solved the wrong problem first. It solved code sharing and collaborative development brilliantly while failing to solve sustainable maintenance and fair value distribution. The result is that we have excellent mechanisms for creating and sharing code but terrible mechanisms for ensuring that code continues being maintained when it becomes critical infrastructure.

The volunteer model works for hobby projects and for projects maintained by companies as part of their business. It fails for the vast middle ground of projects that became more important than anyone intended and that are maintained by individuals who would stop if they were being rational about their time investment. The industry depends on these individuals continuing to be irrational, which is not a sustainable strategy.

The corporate extraction of value from open source while providing minimal support is economically rational for individual companies but collectively suicidal for the industry. If all companies free-ride on open source, the infrastructure degrades until it fails. Some companies recognize this and contribute meaningfully, but most take freely and give nothing back. The tragedy of the commons is proceeding predictably toward the tragic part.

The security implications of critical infrastructure maintained by unpaid volunteers in spare time should concern everyone but apparently don’t concern everyone enough to change behavior. The industry has been lucky that major security disasters have been relatively rare given the fragility of the maintenance situation. Continuing to depend on luck rather than investing in security seems unwise.

The path forward requires acknowledging that critical infrastructure needs funding, that volunteer labor is not a sustainable model for projects that billions of euros of commerce depend on, and that companies using open source have responsibilities beyond compliance with license terms. This acknowledgment is slowly emerging but not quickly enough to prevent foreseeable failures.

The Patrician suggests that treating open source maintainers as the modern equivalent of ancient Roman aquifer engineers who built critical infrastructure that everyone used but nobody wanted to fund properly is historically consistent with human behavior. The Roman aqueducts eventually required imperial funding when volunteer maintenance proved inadequate. Perhaps open source will follow a similar path toward recognition that critical infrastructure requires systematic investment rather than depending on goodwill.

In the meantime, the infrastructure continues functioning through the efforts of individuals who maintain it because someone must and they happened to be there when it needed doing. This is admirable but not a plan. The industry should develop an actual plan before the next Log4j-scale incident reminds everyone that volunteer-maintained infrastructure is fragile and that the absence of disasters is not the same as the presence of safety.

The quiet crisis continues being quiet because the people most aware of it are too busy maintaining infrastructure to loudly complain and because companies benefiting from current arrangements have no incentive to draw attention to the unsustainability. Eventually the crisis will become loud when something critical fails at an inopportune moment and everyone simultaneously rediscovers that critical infrastructure requires maintenance and that maintenance requires resources. The Patrician hopes this rediscovery happens through gradual recognition rather than catastrophic failure, but his experience with human nature suggests the latter is more probable than the former.