What Makes an Open Source Project Successful?

How can you predict if an open source project is going to be successful? This is a question I’ve thought a lot about. I’ll be honest I’ve made the mistake of underestimating the potential of an open source project a few times in my career. I certainly remember a number of conversations while at VMware when the group all came to the conclusion that OpenStack would never get any traction. How silly do I feel now? But that begs the question: how could I have known? Is it all a crapshoot or are there signs you can point to?

Before we dive into this question it may be useful to first answer why it matters. Matt Asay of MongoDB recently said it well: “Ten years ago, a new open source company or project was news. Not anymore. Open source dominates mobile, with Android displacing the seemingly unbeatable iOS in both smartphones and tablets. Open source also dominates cloud, with every significant cloud platform except Azure built using open source. And even Azure treats open-source technologies as first-class citizens on its platform. And open source dominates Big Data, with Hadoop and NoSQL technologies the major forces used for managing the world's data explosion.”

So we come back to the question of how can you tell a priori whether a given project is going to fail or succeed. This is not an academic question! Whether you’re a user of IT or a vendor the ability to “read the tea leaves” is an important one. Every day you have to make a choice--do I go proprietary or open source and, if the latter, which one?

I just had to make that choice from a career perspective. In deciding whether to join the OpenDaylight Project I had to answer two critical questions: first, could open source succeed in the networking industry; and second, will OpenDaylight specifically succeed? In talking to many brilliant people over the course of the last few months I’ve come to the following requirements for a successful open source project:

1. A real, tangible, significant, pressing market problem exists.
2. Talented developers are highly motivated to work on solving that problem. In other words, people care.
3. Vendors see enough profit potential to devote resources to the effort.

Let’s take each one by one:

1. Everything starts with the end user problem. This is true both in the proprietary world and the open source world, but more so in the latter. In the short term, with a proprietary product you can sell a product even if it doesn’t really solve a problem today. With a good sales force and especially the ability to bundle a new product with strong existing products you can sell shelfware. There is no such thing as open source shelfware. If your open source software is super-duper brilliant and neat but doesn’t solve a pressing problem you’re toast.

2. In real estate the mantra is “location location location.” In open source it’s “developers developers developers.” To modify James Carville, “It’s the developers, stupid.” Open source starts and ends with talented, passionate, developers. They come together to tackle a shared challenge and by nature are highly motivated to succeed. Developers have to care. If they don’t, you’re done. Linux is successful first and foremost because Linus Torvalds cares. BUT Linux isn’t Linus. It’s successful because hundreds of others also care. A lot.

3. Vendors want and need to be involved. This is the curious one. This is not optional, by the way: every single major open source effort has had significant investment by for-profit entities. There is money to be made in open source. Companies are absolutely willing to pay for solutions to their problems. Open source enables those solutions in a fundamentally different way than pure proprietary software, but that doesn’t mean anyone is being purely altruistic. Vendors are necessary for successful open source, and they have to make money. Open source requires strong vendor investment, but the governance has to be such that this involvement supports rather than corrupts the first two points above. The structure and bylaws must be designed so that developers are the ones who call the shots.

Understanding these requirements helped me make the decision to leave the proprietary world for open source and I think can be good guidelines for how to judge the future success of an open source project. There are always outliers, but you see these commonalities among many successful open source projects.

In my next post I’ll dig deeper on why the governance of an open source project matters and what’s important to judge traction.