OSS lazy-loads governance

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.)

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.