In the first part of this two-part series, Building a business on a solid open source model, I described how an open source business needs to provide a solid ground for all stakeholders, users, contributors, employees, customers, and of course investors. Foundations, licenses, and trademarks can be helpful in building an open ecosystem. Open source communities need supporting organizations to work transparently, otherwise there are barriers to contribution. Code might be public, but code dumps (like Google tends to do with Android) don’t always facilitate collaboration. To encourage collaboration, you must go one step further and be proactive. Development in a place like GitHub or GitLab, and having open feature planning meetings and conferences help toward that goal. But still, open source project leaders can do more.

Open collaboration

The first rule for open source companies is to work as openly as possible—for example, by making source code available on GitHub, having work flow through public merge requests in public repositories, and making the bug tracker open. Open source projects often have public IRC channels and mailing lists where technical decisions are debated and announced. Our new company and open source project, Nextcloud, uses an open collaboration model, with a distributed development team. Although high-bandwidth face-to-face communication must happen occasionally, we make sure meeting results are shared publicly.

Still, open collaboration could be better. Falling into the trap of discussing technology wherever the subject comes up—even on internal development mailing lists—is easy. Thus, we’ve decided to have only one company private mailing list for HR-related business, and forego internal IRC channels. Instead, we’ll discuss the future of Nextcloud on our discourse forum. This forces a topic-based conversation and makes sure that community members consciously decide, for each subject, to open or not.

Being proactive

I have learned that you need to go one step further. Open source communities have a tendency to assume too much knowledge. For current and future contributors, the decision-making process and the role of the company are not always obvious. Documenting community and company culture is important. An open source community’s culture builds over time, so documenting the history of a community helps people identify with and join. Also, regularly sharing reports on development requires significant effort in a large community, but helps keep a project open.

Decision-making

Another more obvious aspect of transparency is decision making. For example, merely stating that decisions are made by consensus is not enough. Consensus is often understood to mean everybody in a group has to agree on a solution. The reality is that in a large and diverse group of people, reaching full agreement on any sufficiently complicated matter is impossible. Consensus, instead, allows a decision to be made even in the face of disagreement.

You’re probably familiar with the phrase, “Let’s agree to disagree.” Eventually in a decision-making process, consensus requires some of the participants to be willing to step out of the way and let a decision actually get made. You can see how this can work well in a community with many different stakeholders, and often better than voting, which can result in more polarized decisions.

This doesn’t mean there is no room for more formal processes. When a community grows big, for example, and has more potentially conflicting interests, a more formal development process helps deal with conflicts. Working groups under an independent foundation, for example, might be a solution, which is something we intend to set up in Nextcloud, following successful examples like OpenStack.

When you have the structural governance well organized, and a transparent and open development process, you’re in a good position to build a healthy community around your project. To participate in the process of building Nextcloud, join our community.