One of the most powerful—yet most difficult—things in open source is community. "Where a robust community exists," declared Red Hat CEO Jim Whitehurst in a recent interview with Slashdot, "Open source always wins." But building that community is hard. Really, really hard. While it's somewhat straightforward to predict the necessary components of a thriving open source community, it's immeasurably harder to predict when and where the confluence of those components will result in a community like Linux or Kubernetes.
Which is why the smart money seems to follow open source communities, rather than trying to create them.
Lovable open source parasites
This thought struck me while reading Whitehurst's Slashdot interview. Though it tackles everything from the Linux desktop to systemd, Whitehurst's commentary on community proved the most potent for me:
Building a new community is hard. We've started a few at Red Hat, but most of the time we look for existing ones that already have a robust community. Where a robust community exists, open source always wins.
While this approach—tacking on to existing, growing communities—could seem to be a cop-out, it's actually the wisest course of action. Early on, open source almost always seems fragmented, as different projects attempt to gain critical mass. At some point things start to coalesce around two or three winners (think KDE vs. Gnome, or Kubernetes vs. Docker Swarm vs. Apache Mesos). But eventually, it's simply too hard to maintain diverse community "standards," and everyone rallies around one winner (Kubernetes, for example).
SEE: Hybrid cloud and open source: Red Hat's recipe for digital transformation (Tech Pro Research)
This isn't capitulation—it's a smarter way of shepherding resources and driving standardization. One reason that Linux has become such a powerful force, for example, is that it encourages operating system innovation in one place, even if there are disparate tributary communities feeding into it (and wildly different companies and individuals contributing the code). Red Hat has thrived in part because it made smart community choices early on, picking a winner (like Kubernetes) and helping to make it even more successful.
Which, in turn, powers its business model.
Making money from community chaos
The great thing for Red Hat is the more community, the more successful the project. But "success" in open source doesn't necessarily mean that enterprises will embrace a project; it merely means that they want to do so. Red Hat's early intuition, and one that keeps paying dividends, was understanding that dull, stodgy enterprises want the vibrancy of open source without, well, the vibrancy. They need it tamed and made dull and stodgy. Whitehurst captured this perfectly in his interview:
Red Hat is successful because we obsess about finding ways to add value around the code for each of our products. We think of ourselves as helping make open source innovation easily consumable for enterprise customers.
Just one example: For all of our products, we focus on life-cycle. Open source is a great development model, but its "release early, release often" style makes implementing it in production difficult. One important value we play in Linux is that we backport bug fixes and security updates in supported kernels for over a decade, all while never breaking API compatibility. That has huge value for enterprises running long-lived applications. We go through this type of process against all of the projects we chose to productize to determine how we add value beyond the source code.
For most companies that want to make a business with open source, the challenge is that they may recognize the value of community, but can't fathom how not to sell code. Selling software, after all, has been a fantastically profitable business model for decades, and has resulted in some of the most valuable companies on earth.
Open source, however, requires a different approach, as Whitehurst pointed out. "YOU CAN'T SELL FUNCTIONALITY because it is available for free," he asserted in the interview. Instead, you have to find other value, like making open source supportable over long periods of time. Boring work, but worth billions every year to Red Hat.
All of this starts with community. The more vibrant, the better for its ability to both market an open source product and also to monetize it. Why? Well, because more moving parts equal more value tied to making that free-wheeling project just a bit more staid for enterprise consumption. It's a winning formula, and plays to all the good in open source without shackling it to 20th-century business models.
- How Red Hat aims to make Kubernetes boring...and successful (TechRepublic)
- Google's real Kubernetes magic is all about community, not code (TechRepublic)
- Why DIY Kubernetes projects could be a really bad idea for your business (TechRepublic)
- Amazon jumps on Kubernetes bandwagon (ZDNet)
- Why developer evangelism is the secret to the success of Kubernetes (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.