Sustaining Open Source Software

Updated July 2022

Work in Progress: These are a set of working notes about the problem of creating sustainable ecosystems for resourcing the creation and maintenance of software systems.

Open source software projects have become akin to public utilities, utilized by more than 90% of software applications. But these projects are often fragile, passing along security vulnerabilities, suffering “bit rot,” and abandonment by maintainers.

We believe that the root cause is a lack of project sustainability—stakeholders lack the necessary resources (time, money, and skill) to adequately steward the project for the long-term.

Problem Statement: An Outline

  • Software is eating the world, which is to say, software is becoming an ever-increasing part of everyday life.
    • Software has become "core infrastructure" that we rely on like we rely on running water and electricity.
  • Software exists in several layers:
    • Protocols
    • Languages
    • Libraries
    • Platforms
    • Products
    • Services
  • Each layer is built on the layer above it, with some interesting edge cases
    • Like any taxonomy, this taxonomy is imperfect.
  • There are strong economic models that currently exist for building Platforms, Products, and Services.
    • Easy to make money building these things.
  • There is no strong economic model for sustainably resourcing the development of Libraries and Protocols.
    • Sustainability and Maintaining Systems
  • Problem: Platforms, Products, and Services are built atop Libraries and Protocols.
    • This creates an "unsteady foundation" where Libraries and Protocols are not adequately supported, causing the upper layers to fail.
    • There is also tremendous waste in building the upper layers since Libraries and Protocols are not being optimally developed and maintained, causing churn-having to be rebuilt due to abandonment.
    • Tremendous leverage at lower layers! Yet no strong economic model for developing them, so that leverage is wasted.
      • Each layer has potentially an order of magnitude of impact to the layer above it.
        • a single protocol can support 10x as many libraries. a single library can support 10x as many platforms, and so forth.
  • Traditional solutions to this problem have involved licensing the software itself, which assumes that the point of leverage is literally the source code that is produced.
    • This is a naive and unhelpful view of code/programs. The source only is effective within the context of a living system. Extracted from the system it has little to no value.
    • The bits are not the value!
  • It turns out, the rival, non-fungible good is actually developer time to build and maintain open source software!
    • We should focus on models that properly incentivize the deployment of developer time.
  • The other challenge is coordination.
    • Occasionally a library is maintained principally by a single maintainer with little assistance from the community
    • Most often libraries and protocols are actually a network or community who each play different roles in the maintenance and extension of that resource.
    • The mechanisms we have for coordinating groups of developers and community members are immature and poorly understood.
      • The most obvious organizing mechanism for the creation of software is the corporation. However, for the sake of resiliency and anti-fragility, it's preferable to have developers from multiple organizations all working on the project, together.
      • Another mechanism is the "core maintainer group." This mechanism is widely used, but also poorly documented and understood.
      • A final mechanism frequently used is the open source foundation. I don't know that much about how foundations work, how successful they have been, etc.
    • An emerging model worth exploring is the Networked Organization, which can be thought of as applying some of the principles of decentralization a la software to the corporation itself.

A Way Forward: Maximize the Impact of Developer Hours

We believe that the rivalrous good in the creation and maintenance of open source software is not the software, i.e. the bits, but rather the production process itself. That leads to a tangible goal:

Pioneer new economic systems that maximize the impact of developer hours in the production of open source software.

At a high level, we are interested in solutions that explore one of four strategies:

  1. Increase the total number of available hours.

  2. Increase the efficiency of existing hours.

  3. Eliminate wasteful hours.

  4. Redirect hours to higher priority tasks and projects.