Since we announced Nextcloud, an ownCloud fork, many people have asked me how we plan to build a sustainable, healthy open source business. My short answer is that it requires a strong focus on maintaining a careful balance between the needs of all stakeholders: users, contributors, employees, customers, and—of course—investors. Building a solid open source business requires that management has confidence in the abilities of your company, stakeholders must be on board with the business model, and everyone must understand that balance is important for the ecosystem. Like a rising tide lifts all boats, a strong ecosystem benefits all stakeholders.

Building open ecosystems

Being open to outside contributions is a key differentiator for open source businesses. Joy’s law, a management principle that states “no matter who you are, most of the smartest people work for someone else,” is probably the most well-known description of this idea. Company leaders and investors must be confident in the project’s ability to compete with other organizations that might enter the ecosystem. This confidence positions your project to be less tempted to erect roadblocks for others to enter the space. Although legal and practical roadblocks to competition allow for some short-term stability and income, they position the whole ecosystem to be far weaker and are hard to get rid of later.

Roadblocks

As I’ve seen at the various companies I worked at, management often is afraid to open up. They want guarantees, for example by protecting parts of the code, capabilities they consider their “crown jewels.” That way, they would have an edge up on a competitor who might enter the ecosystem. If you have such an “enterprise edition” model, like NGINX or Oracle’s MySQL, you always have to balance the usefulness of the open source version with what functionality you offer in the enterprise version. If not done correctly, closing off enterprise-version features can cause your community members to lose confidence and motivation to use or contribute to your project. Such open core models usually require a Contributor Licensing Agreement, which can be a problem in itself. These often are disliked by contributors or can’t be signed for various reasons.

These models create a fundamental unbalance between The One Company and everybody else and this, in turn, discourages other parties, especially companies and other organizations to get involved. Without ownership, they feel they have less guarantees that their contributions continue to benefit them in the long term. Even though many contributors understand ‘money has to be made,‘ the limitations reduce growth.

Misunderstandings

What often is misunderstood by management is how likely it is that their “crown jewels” will get “stolen.” I use the term stolen here with quotation marks as, obviously, one can’t steal something that is available under a free license. The reality is that even with open licenses, adopting technologies from other companies can come with big costs. Also, equally important, companies tend to be conservative and value their self-built tools and processes, and in general suffer more or less from the “not invented here” syndrome. (For a better understanding of the process of moving from a proprietary to open source mindset, read Stephen Walli’s recent article An in-depth guide to turning a product into an open source project.)

At the same time, companies tend to over-estimate the value of their crown jewels and under-estimate how easy it is to write competing capabilities. More importantly, they under-estimate the benefits a more open ecosystem could bring. In the end, the open ecosystem would often allow more growth for all participants than the closing off of a part might have benefitted the company that started or managed the project. When there is a healthy ecosystem with a healthy company in the center of it, other parties will indeed join, but rarely will they directly compete with each other. Instead, they find other niches for themselves that end up strengthening the entire ecosystem.

Thus, closing up part of the technology to earn more paradoxially limits growth and even creates a risk of a serious rift, as various projects have seen in the past. Joomla (who remembers Mambo?), LibreOffice, MariaDB and of course Nextcloud are the result.

Being open

When you are building something like the OpenStack project, instead of preventing competition, being more open is crucial for success. Rackspace decided to open their code and collaborate with NASA, thus facilitating the healthy OpenStack ecosystem we have today, with nearly 500 companies contributing to the project. Other prominent examples of open ecosystems are the Linux kernel and the Apache Foundation projects.

Nextcloud intends to be a similar project as we collaborate on an app platform, and we already have started conversations about close relationships with Western Digital Labs, Collabora, and others. Yes, there will be competition in the Nextcloud ecosystem. With WD Labs, the community is building an inexpensive, Raspberry Pi-based home cloud device. Do we see this as a threat to one of our main products, the Spreedbox? Technically, it probably is. But we can also collaborate. Instead of being afraid, we will be working close together with other organizations and our own community members. Tide, lift those boats!

Foundation

After core stakeholders are on board, an open source project has a solid foundation for collaboration. When building a large open source project with a growing community, setting up an independent organization to protect trademarks and code helps provide confidence for contributors and prevent bad governance by a single party, which can damage an open ecosystem. In a smaller community, a simple governance model makes sense, and I’ve given a few talks on the subject of open governance, which you might find useful.

As an open community grows, it needs well-defined and structured decision making, like the OpenStack project employs. However, in all cases, transparency and open collaboration are key to open source project health. In the next part in this two-part series, I’ll get into more details about open collaboration.