The last few weeks, we have seen a number of organizations announce they were open-sourcing their technologies – from large companies like Microsoft with its .Net platform, to small startups such as Midokura with its MidoNet technology and most recently, On.Lab with its O.N.O.S. technology. This is on top of Beacon, Floodlight, Ryu, OpenContrail, and a number of others in the networking industry.

As a result, analysts and reporters are constantly asking me what I think regarding their chance of success. Companies are also often asking me my thoughts on whether they should open-source a technology and whether to do it as a separate project or within the sphere of an existing open-source project. Overall, this trend toward open source is very encouraging. Unlike closed-source/proprietary code, open-source licenses allow one to look at the code – to understand the inner workings and spot problems but also to be inspired. The real power of open source is the ability for people to build on top of the original source code.

There is more to building a successful open-source project than simply sticking an open-source license on it. Successful open-source projects gather a strong community. This is critically important when we are talking about something that seeks to be a platform. If a tree falls in the woods and no one is there to hear it, does it make a sound? If a company releases its technology with an open-source license and no one looks at it or builds on top of it, does it matter?

Community is critical for an open-source project. The first reason is the sheer amount of resources a community can bring. Think about a startup with $5 million in funding that chooses to open-source its platform. Assuming the company spends it ALL on developers, it can hire about 10 developers at most to work on its project. The math is no different for a university lab or other similar organization. Note this is for one year. You’ll probably need at least three years of development effort to get a mature platform. Now contrast that with a community project like OpenDaylight. Every single Platinum member to the project contractually commits to 10 FTEs per year. And those are just the formal commitments; there are hundreds who have contributed their time to advancing the platform. To take another example, imagine if you are thinking of competing with OpenStack. Your challenge isn’t just meeting OpenStack’s current functionality but also what the army of OpenStack developers will be able to add/improve/enhance over the next few years. It’s a daunting proposition and not one someone should take lightly.

The second key reason has to do with how a broad community brings a diversity of ideas, technologies and perspectives. Part of what has turned Linux into such a successful project is the wide variety of use cases it has been wrangled to solve. While Linux may not power most desktops, startup Qumranet used it to power server virtualization (KVM), Google used it to power cell phones (Android), Docker uses it to power containers, Tesla uses it to power their cars, etc., etc., etc.

Third, a community can help ensure go-to-market. Every software project has its early challenges. Vendors who embed open source into their solutions or release distributions play a critical role. Vendors identify use cases and solutions, assemble the pieces and invest heavily in identifying and fixing bugs. Their sales forces engage with customers, gather objectives and constraints, and bring this back to the project. Vendors build awareness, support evaluations, perform installations and integrations, and provide ongoing support. In fact, this creates a positive feedback loop where vendors and customers are commercially dependent on the common open-source code. They must improve the code to harden and innovate their products. These improvements then flow back into the project, and everyone benefits. The next release of the project starts this cycle over again in an ever-expanding innovation cycle.

If you look at the most successful open-source projects, such as Linux, Hadoop, OpenStack, and OpenDaylight, one common thread is that they all have significant support from vendors. Are they vendor driven? Maybe, in a sense, but they wouldn’t be successful if they didn’t solve a real end-user problem. Vendor involvement is a critical feature, not a bug. In fact, drawing a distinction between “vendors” and “users” in open source is a common mistake. In open source, everyone is a user: An IT vendor uses code to create products, a cloud service provider uses code to create services, a social network uses code to connect people. Vendors, service providers, Web scale business -- they are all users of open source. This is once again why community is important – not some antiquated view of vendors vs. users.

So how do you build a community? It’s not easy. It starts with having a major problem to solve and rallying both the people who write the checks and the people with the IQ and passion to solve these problems. It requires significant investment -- in governance structures, infrastructure, and the facilitation of engagement and discourse. Look at any major open-source project carefully, and you’ll see a whole set of critical activities that bring the community together. Broad summits, design forums, regional mini-summits, hackfests, community dinners, meet-ups, mailing lists, and project calls. Staff to get new members on board, release managers, community managers, marketing etc. -- each of these plays a different role, but each is critical to the success of the project. Building a successful open-source community is not unlike building a successful corporation. There are a lot of elements that must come together.

How many of these new open-source efforts will grow into successful open-source communities? How many startups grow into successful corporations? VCs often find one out of 10 of their investments hits it big, two to three are modest hits, and the rest fail. In my experience the same is true for open-source projects.