Skip to the content.

Rule no. 4: Being able to integrate external contributors.

Welcoming external contributions requires careful thought and the implementation of processes to facilitate involvement. In “Producing Open Source Software”, Karl Fogel talks about activation energy, the effort required for a contributor to participate in a project.

The aim is to reduce this needed energy as much as possible. Various elements will reduce this friction, such as the availability of information, the way decisions are made, the complexity of the resource, the digital environment and so on.

The basic practice in the software world is to provide a “contribution guide”, the documentation will be a tool to enable this integration. For example, the Python language offers a guide to contributing: They explain how to retrieve code, submit modifications, link to various tools such as bug tracker, resources for getting started with CPython (Python’s C code)… A contribution guide can also be found on Wikipedia (, or under construction for the open models knowledge brick (

The quality of the code, its structuring and, more generally, the complexity of a resource will influence how easy it is to contribute. If nobody understands it, in a « spaghetti code » for example, this will make participation very difficult.

Potential contributors have a long way to go, and their involvement is not immediate. The speed of involvement will of course depend on the individual, but it will happen in stages. One of the maintainers of homebrew, the (unofficial) Mac package (~application) manager, talks of an “open source contributor tunnel”, analogous to the sales tunnel. First a person will be a simple user, then a contributor, and finally might become a project maintainer. (Original article:

Running an open project requires a whole range of efforts to create an environment suitable to open collaboration and to benefit from this collective intelligence.