Adoption is a double-edged sword.
The adoption rate of a digital solution is typically an indicator of its financial success. Inexperienced funders may think that this rule of thumb extends to open-source work. However, this same measure does not easily apply to infrastructure projects. Too much growth too fast can strain groups who already do not place a high value on the types of work that help a community scale.
- With adoption comes responsibility. Applications and products which make use of a library, or other digital infrastructure, depend on its continued maintenance and development. Widely-adopted FOSS projects, especially one-person-shops and collectives, cannot always reliably deliver under pressure.
- FOSS infrastructure projects therefore take care to scale only to a degree that the community can still support. This can limit the speed by which new technologies and features are adopted, or services are opened up to new groups of users.
- People working on infrastructure projects care about the adoption of their code, but more for abstract reasons (“I want to help people”) than for economic incentives (such as market-share).
- FOSS contributors do not often work actively with other projects to get their work adopted – either in order to avoid an unsustainable growth of dependencies, or simply because of a lack of time.
“We need to trust each other. Growth would make us unhappy.”
“We want deceleration. Slowness.”
“You work on a project and it becomes successful, people start filing bug reports and complain. It’s difficult not to become resentful towards the community.”