Community is key to open source success and possibly profit

Kubernetes is king because it put community first. The same strategy may pay off for commercial open source companies.

Video: Open source software is the future of enterprise technology Enterprise companies use open source code because it's useful, reliable, and community vetted. TechRepublic contributor Matt Asay explains the big reasons open source is the future of enterprise tech.

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)

Community wins

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.

SEE: What Kubernetes really is, and how orchestration redefines the data center (ZDNet)

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.

Also see

kubernetes.jpg
Image: 123dartist, Getty Images/iStockphoto

By Matt Asay

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.