Open source companies like Redis Labs and MongoDB may be looking to cordon off code to ensure commercial success, but the correct path to open source project success is openness. Thus spake Kubernetes co-founder Brendan Burns, and thus it is. As he noted in a recent interview, "...especially in the infrastructure space, the [open source projects] that make room for other people to be successful are the ones that ultimately win."
The same may be true of the companies hoping to profit from open source.
SEE: Open source vs. proprietary software: A look at the pros and cons (Tech Pro Research)
I've detailed how the Kubernetes community has carried it beyond rivals like Apache Mesos. These other projects predate Kubernetes but never mustered the community collaboration necessary to give them momentum and staying power. Kubernetes, by contrast, got that community right from the beginning.
Credit for this goes to Burns and his co-founders, Joe Beda and Craig McLuckie. But really they get credit because they've been so quick to assign credit elsewhere, as Burns demonstrates:
"I have to say that I really want to give credit to the community here. It's a group effort. I like to say I threw a pebble or a little snowball off the mountain and it turned into an avalanche, right? It's hard to take a ton of credit because I think there's been so much work by so many people to get us to where we are. I think we set the seeds, we set the trajectory in the right way. I really wanted to have an open project, I really wanted to have a project where people could come and feel like they were empowered and people could come and feel like they could really contribute, because having been a student of a lot of open source communities over the years, I think that especially in the infrastructure space, the ones that make room for other people to be successful are the ones that ultimately win."
Why? Because any project must decide whether it's going to rely on a crowd or one talented individual (or company) to build for the long term. Individuals burn out and companies follow their particular cash needs, but a true community will evolve to meet a diverse array of needs, much as Linux has. In addition, Kubernetes, like Linux, has benefited from self-interested participants like Red Hat that have "connect[ed] it to the real world...[and] real customers." That reality check has pushed Kubernetes beyond what any one talented individual or company could have come up with or coded.
SEE: How to build a successful career as a DevOps engineer (free PDF) (TechRepublic)
The cash dilemma
This is why the open source monetization question is so complicated. It's completely understandable that a CEO like MongoDB's Dev Ittycheria would complain about public cloud providers: "Whenever a new open-source project becomes popular, cloud providers strip mine the technology, put the freeware on their platform, capture most if not all of the value but give little back to the community." While commercial open source sponsors chafe at the cloud providers turning their projects into services the cloud providers sell, it's the last part—the lack of contributing anything back—that makes it particularly galling.
But this problem is more pronounced for commercial open source providers where, as Redis Labs CEO Ofer Bengal has indicated, "Ninety-nine percent of the contributions to Redis were made by Redis Labs." That may be a true statement, but it sounds more like a bug than a feature. This sort of community is a one-way affair, very similar to a proprietary software model.
Yes, great software can and does get built this way, but for an open source project, it feels like a missed opportunity.
Take Magento (acquired earlier this year by my employer, Adobe), for example. Just two years ago Magento, the company, contributed roughly all of the code to Magento, the community. It was open source, but not in any "let's collaborate" sort of way. Today, roughly 60% of the code in Magento is contributed by community members who don't work for the company (up from 50% earlier this year when I wrote about this remarkable feat).
I get to work with dozens of smart Magento engineers now, but even more exciting are the contributions from thousands of Magento community engineers. Most recently that community built the multi-source inventory module that Magento, the company, had struggled to build. With one core Magento engineer and a community numbering well over 100, that functionality was built in a year, and in a way that met the needs of demanding, real-world enterprises.
That's the power of community, and it doesn't need to be antithetical to commercial success; in fact, done right, it should be the heart of that success. Red Hat, for example, has always ensured that it feeds upstream community before it worries about monetizing downstream project success.
So for commercial open source companies that quite reasonably want to make money from their projects, I'd argue that the right strategy is to change "their project" into "our project." The pace and scope of innovation can dramatically increase and, with it, the opportunity to profit therefrom.
- 20 quick tips to make Linux networking easier (free PDF) (TechRepublic)
- What is Docker and why is it so darn popular? (ZDNet)
- Why Kubernetes could be crowned king of container management (TechRepublic)
- Why Kubernetes may be a bigger threat to Amazon than Google's cloud (TechRepublic)
- The Linux Code of Conduct is long overdue (TechRepublic)
- Microsoft buys GitHub for $7.5 billion (ZDNet)
- GitHub: A cheat sheet (TechRepublic)
Matt is currently head of the developer ecosystem at Adobe. The views expressed are his own, not those of his employer.
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.