A special characteristic of open source software (OSS) is that you don't need institutional support to get started. It's interesting to compare this to physical infrastructure, like dams or railroads. Before you can begin those projects, you need upfront capital, permits, rights-of-way, environmental impact reviews, community hearings... and so much more.

By contrast, all you need in order to begin a digital infrastructure project is an internet connection and some free time. As a result, OSS projects only confront governance challenges once they've become prominent and complex enough to warrant formal solutions.

It is hard to create new physical infrastructure.
It is easy to start a new open source project.
This low barrier to entry makes software exciting! It's one of my favorite things about this industry. Any developer with a good idea can share it with the world, without asking for permission.

It also means that OSS maintainers are forced to confront questions about governance (e.g. decision-making, funding, and communication) later, often once the project has already become an important dependency to other projects and communities. This has some interesting implications for how projects resolve these challenges.

On one hand, the delayed germination of governance problems makes it harder to find solutions. Here are a few reasons why:
  • The community is larger and more diverse: By the time governance problems rear their head, a wider range of people have a stake in the project. This scale makes it harder to resolve governance challenges, because those involved have competing ideas about what the solutions should be. This increases the likelihood of controversy. Earlier in a project's life, when decisions affect fewer people, the community is nimble and capable of communicating big changes. When important questions are raised later (for example: "Who's in charge?" or "Where does the money come from?"), there are many more actors who want to shape the answers.
  • Users have preset expectations: The increased scope of a project simply makes it harder to change anything at all, regardless of the specific direction of the change. Every project operates by a set of rules, whether or not they are deliberate, and the community that forms around the project will come to depend on that structure. If you create a formal system where there were previously-accidental rules, it changes the way a project functions, upsetting the community's expectations.

    It's similar to what happens when you introduce a bug into an API. By the time you find it and want to fix it, users have come to depend on the buggy behavior, and it would disrupt their integration if you were to change it. It can worth that disruption cost (in the case of both governance and API design), but it is a cost, and it makes that change all the more difficult.
  • The maintainer may not be prepared or eager to solve governance problems: Just as many startup founders discover that running a late-stage company requires a very different skillset than finding early product-market fit, the developers who create OSS are often excited about the early technological experimentation but less so about persuading people, facilitating disputes, securing funding, and establishing communication practices. (There are OSS maintainers who do have this desire and skillset, but it's not the default.)

On the other hand, this delay can in some ways make it easier to find solutions to governance problems:
  • The project has room to grow: One advantage of this dynamic is that OSS projects don't have to spend early effort solving problems that fall outside of their core competency before they even know if the project will work. They can "lazy-load" their governance problems until they know it's worth their time to develop solutions.

    As an analogy, imagine you're thinking of getting into cycling—you should not spend hours researching the perfect bike or forking over thousands of dollars for the perfect carbon fiber frame. Instead, borrow a friend's bike or rent one for a weekend to go for a spin. After all, you're not even sure if you're ready to commit yet! OSS projects are similar. You don't know how useful it is until people start using it, so you're better off focusing on just getting it to work before spending brain cycles worrying about the governance.
  • Problems are solved from experience rather than hazy predictions: Lazy-loading governance also means that you have a better understanding of what problems you're solving for in the first place. In physical infrastructure, governance is decided before a community fully understands the needs and repercussions of that project, which can result in wasting effort to solve nonexistent or misunderstood problems.

    It's like buying furniture before finding an apartment—you're likely to misjudge what you actually need, requiring you to go back to IKEA once you've moved in. The low barrier to entry of software means that an OSS community has a chance to bump into the problem in the real world a few times before they're forced to come up with a solution.

This ability to "lazy-load governance" is an important structural characteristic of OSS. It brings unique challenges, but it's also a great advantage to working with bits rather than atoms. Understanding this dynamic can help communities predict and prepare for some of the challenges they face as they grow.

The urgency of settling questions of governance at different points in a project's life is very different in physical infrastructure compared to OSS.