Open governance: It’s all about community

In our nearly thirty years of working in open source, one thing IBMers have learned is that communities that are inclusive and adhere to open governance principles tend to attract the largest following and most vibrant ecosystems.

The reality is that not all open source is truly open. Many open source projects are run by a single individual or controlled by a single vendor, and are quite closed in their governance. Other projects are welcoming of outside contributions, but are not open to outside contributors owning leadership roles that let them set technical strategy and direction. The truth is that projects that are controlled by a single individual or organization present a greater risk and lower the opportunity for collaboration and innovation.

Many successful projects have vibrant levels of contribution and a real sense of ownership by the community members. They understand every nuance in the code and can create patches and answer questions as well as any of the project founders. It only takes a few small gaffes by those in control of a project to alienate participants and have them demanding a change in governance. Debates often get heated, and forks happen that split communities and leave discord between once close members. We hope to offer some guidance below on how open source governance helps you to avoid this eventuality.

So, what exactly is open governance? Open governance means that a group of community-elected developers from a project’s contributor base make technical decisions about the project or projects’ future. We’ve found that this often works best when a project sits under the governance of a neutral foundation that holds the copy rights and associated marks. Let’s look at some of the benefits of open governance.

Reduces risk of project abandonment

When a project is under open governance in an ecosystem of active developers, the risk of the project being abandoned or not maintained at all is lower.

A lot of open source code is published with an open source license (or not!) but isn’t being actively maintained. Even in those cases where the code is actively maintained, if it’s controlled by a single individual or company, there is always a risk that the person or company stops maintaining their code or changes the license. When that happens, the community is left to scramble with the dependencies they have on the project, which could have serious security implications or otherwise.

Now, some open source purists might say, “But you still have the software,” which is true. But here’s the rub: Are you really going to maintain a mobile app development platform or NoSQL database by yourself without help from an active community of other developers?

Eliminates single-vendor control

We’ve seen projects reach a certain level of success and then come to a tipping point where users and contributors realize that, without open governance, there is a greater risk of the vendor making choices that are good for their company’s strategy but not good for the greater ecosystem.

If users and contributors feel like they can’t influence decisions about the future of the technology, projects have been known to fail or fork. For example, when the Node.js community felt that Joyent had too much control over the direction of the project, members of the community forked the code into a separate project. Node.js is the most popular framework for Javascript development, but that schism would have likely resulted in a fragmentation and collapse of the ecosystem.

IBM worked with both factions and convinced them that the way to resolve the situation was to bring Node.js development under open governance. IBM worked with other key stakeholders to create the Node.js Foundation (now the OpenJS Foundation) under the Linux Foundation and worked to heal the schism. The io.js fork was merged back into Node.js and the project is now enjoying wild levels of success and an increased maturity.

Safe place to innovate

The Node.js example is unique because the fork was healed. Every year we run into other projects experiencing community unrest, as the level of dependence and enthusiasm grows, participants ask about governance and how they can better contribute.

When a project sits under open governance, developers can trust that their contributions will be accepted based on merit and what’s best for the project—not what’s best for a particular company. Knowing that a neutral foundation owns the trademark, domain, and repository gives developers from various organizations more incentive to participate in a project, bringing their diverse experience and backgrounds, which, in turn, makes the project stronger. This is the way strong ecosystems and even markets develop around a code base.

Conclusion

The reality is that open technology projects managed under open governance—the sort of open governance found in organizations such as Apache, Eclipse, Mozilla, and Linux—are demonstrably more successful (by an order of magnitude), have a longer life, and are less risky than projects that are controlled by a single vendor or are more restrictive in their governance.

While IBM often contributes to and consumes from open source projects that are not under open governance, when our clients or our offering teams feel that a project is important enough, we often work with the individual or vendor that controls the project to help them see the value of open governance. If we can effectively bring the project to open governance, we increase our investment considerably to help ensure that project’s success and work to grow the community and ecosystem.