When Open Source Foundation Makes Sense

Picture Source: Osuosl.org

Ever since open source took off in the enterprise market, we are seeing more and more vendors using open source as a marketing tool. One of the recent marketing strategies is to talk up the idea of open source foundations. Let me make it clear before I get beaten up on this statement. I am not saying that all the open source foundations are meaningless but I am arguing that more and more vendors are using the idea of a foundation as a way to gain open source credibility in today’s enlightened world. There is nothing wrong with what they are doing. In a free market, anything is acceptable as long as it is not illegal. At the same time, free market works well when there is no information asymmetry between the seller and the buyer. I thought I will bridge the gap by digging a bit more into the idea of open source foundations and when it makes sense.

In the early days of enterprise open source, the lines were clear. On one side, we saw open source vendors running their own community and open source foundations like Apache Software Foundation stepping in to help non vendor open source projects. As open source became more and more commercialized, the landscape started to shift. More and more vendors started embracing open source foundations (either the established ones like Apache Software Foundation or stand alone foundations). Some of the vendors started using open source foundations to set up proper governance for their developer community while others started using the idea of foundations as a way to gain open source karma. The latter strategy is proving to be convenient for proprietary companies jumping into open source world.

This brings into focus when a foundation makes sense and when it doesn’t. If we take out the fact that open source foundation makes complete business sense for proprietary companies wanting to gain open source credo from the discussion, there are certain situations where having a foundation is critical for sustaining open source communities. It is also important for us to remember that the nature of contributors to open source projects has changed from individual users scratching their own itch to organizations trying to meet their business needs. With this in mind, let us look at how the architecture of the open source platform defines the path to community. If the architecture is closed (meaning not extensible/pluggable), contributions to the project are much more complex (impacting many different stakeholders). In the case of open architecture, there are few core components and a plugin model extends the platform to suit the needs of wide range of users. Most of the community contributions goes into the plugin side of the project than the core components. Hence the impact on different stakeholders is much more limited than the previous case. In fact, the core components in an open architecture needs little or no modifications for 99% of the use cases whereas a platform with closed architecture has too many touch points inside the core components. Too many touch points in the core with too many stakeholders makes these open source projects complex beasts. The community building process should take into account this complexity associated with the project based on architectural decisions.

When a vendor’s open source project is a complex beast, they can either run a community with iron fist or take a foundation path to community. The former approach will result in a small community with higher possibility of a fork down the lane. The latter approach is the only way the vendor can build a vibrant community without any increased risk of forking. The governance for the foundation clearly specifies the rights and responsibilities of the stakeholders and ensures that the community stays intact. When the contributors to an open source project are vendors with their business at stake, an open source foundation with a governance model suitable for these vendors helps.

On the other hand, if the open source platform has an open pluggable architecture, it is easy to build a conflict free community without resorting to an open source foundation. The core components are rarely touched and the extensibility is leveraged to meet the needs of the community stakeholders. A pretty good example to this approach is Gluster Forge, a community behind GlusterFS (Disclaimer: Red Hat, my employer, acquired the company behind Gluster community and it is one of the underlying components to Red Hat Storage). Gluster was a vibrant open source community with different stake holders when Red Hat acquired the parent company. Once under Red Hat, they wanted to bring in a formal structure where different stakeholders with business interests can co-exist with each other. Since GlusterFS is a pluggable storage platform, Gluster Forge is serving as a viable structure for their open source community. Any open source platform with an open architecture can avoid the foundation route by embracing the Gluster strategy.

In short, there are three ways to community building in a world where business interests define the community contribution. They are:

• Single vendor controlled project without any importance to the architecture decisions. In this case, the community around the project is usually small
• A community run by a vendor with a Forge like model. This will work well and lead to a vibrant community with an open extensible/pluggable architecture
• A community run by multiple vendors with a Foundation. This could lead to a vibrant community provided the major contributor doesn’t screw up the dynamics. This is particularly useful for platforms with closed architecture

Community building is tough. Not every vendor can do it successfully. There are only handful of vendors with credibility to build successful open source communities. Foundations can come to the rescue in the case of vendors who are new to open source. Either way, it is about choice to end users and none of these approaches work well unless it is properly executed.