It was bound to happen. Kubernetes, so often held up as a paragon of community virtue, turned into a petty “more-open-than-thou” battleground between Heptio CEO (and Kubernetes cofounder) Joe Beda and, well, everyone else.
Beda’s argument, strenuously denied by Red Hat employees and supporters, is that Red Hat OpenShift forks Kubernetes and isn’t 100-percent conformant. Beda’s coup de grace, however, is that “many customers” think it matters “a lot” whether OpenShift is a fork or “layers cleanly” on the upstream Kubernetes project.
Except they clearly don’t, given Red Hat’s OpenShift revenue, which keeps rising. Either those customers are blind to Beda’s argument (similar to those made by another competitor, Canonical, over the years), or they don’t agree with the accusations. Or maybe, just maybe, they don’t care.
When a fork is not a fork
The irony of Beda’s Twitter fight is that Red Hat started it, albeit unwittingly. Red Hat’s director of strategy, Brian Gracely, linked to an article by analyst Janakiram MSV and asked him to “please stop spreading this misinformation.” What misinformation? That “Red Hat is criticized for forking Kubernetes.”
As pernicious “misinformation” goes, it’s Milquetoast. It also was just one short phrase in a long article that overwhelmingly sings the praises of Red Hat’s cloud strategy. Most companies would love the positive coverage that article provides. But Red Hat couldn’t ignore the insinuation that it’s doing open source wrong.
Beda, whose company builds a rival service to OpenShift, also chose not to ignore the discussion, jumping in to declare OpenShift a fork: “You can both be a fork and conformant. OpenShift is significantly different from upstream Kubernetes. It is a fork.”
Dan Kohn, executive director of the Cloud Native Computing Foundation, which shepherds the Kubernetes code and community, came to Red Hat’s defense: “OpenShift, like the other 54 distributions and platforms (and unlike Heptio and the other seven installers) carries patches and so is not vanilla, upstream Kubernetes. But as with Linux, distributions and clouds carry patches without being seen as forking the kernel.”
Tremolo Security CTO Marc Boorshtein argued that “Azure, AWS, and Google need customizations to support their customers, and so does Red Hat… [which are] stored in different source trees. All [use] best efforts to use standard hooks as they become available.”
Rishidot analyst Krish Subramanian delved into the details of whether OpenShift could credibly be called a fork, and determined the answer is no.
All this probably should have settled the fight, but it didn’t. Beda pressed on with the fork claims, apparently intent on discrediting OpenShift’s open source bona fides and win purity points for Heptio’s approach.
Red Hat’s ‘fork’ doesn’t matter to customers
Enterprises want stuff that works. As much as we in the open source world chatter and fret about vendor lockin, enterprises have demonstrated a remarkable ability to shrug off that concern and buy deeply into Microsoft, Oracle, and, yes, Red Hat’s OpenShift.
Beda said that customers care whether OpenShift is a fork or not, but Red Hat earnings simply don’t support that claim. OpenShift keeps juicing Red Hat’s revenue, and it looks to be the product that will carry Red Hat through the next two decades of growth, just as Red Hat Enterprise Linux carried the company through the last two decades.
Enterprises want Kubernetes. That’s clear. But they also want it to work with their other infrastructure. As Red Hat’s Gracely told me:
We’ve always said the OpenShift is Kubernetes++. We don’t remove anything from Kubernetes, and customers have full access to all of those APIs. The extensions we’ve made are about the complexity of enterprise IT demands (multitenancy, complex routing, and secure defaults).
Some things we did before they existed in Kubernetes (for example, role-based access control and Router), and we’ve tried to push them back upstream. Things like Router are still ahead of the Kubernetes default Ingress. Other things have evolved because the community created something great (such as Helm Charts), which we’ve adopted as an alternative option to the OpenShift templates we had before Helm.
Is this a fork? No. It’s a way to make Kubernetes work for the real world. As Gracely said, “It’s always going to be somewhat fluid, but we’re 100 percent committed to making Kubernetes successful. Internally we always say that Kubernetes must be successful (and stable and secure) before OpenShift will ever be successful.” That focus on making the underlying (upstream) project successful before one’s own commercial success is probably the single best antidote to forking, because it drives a company to invest heavily in the source project.
If you still harbor any doubts about OpenShift’s forkiness, you can use a tool like Kubernetes by Example to determine if all the main Kubernetes code works with OpenShift. But you needn’t bother. Just look to real-world customers solving real-world problems: They’re going with OpenShift (as well as Microsoft, AWS, Google, and other Kubernetes distributions), and they’re not stopping to split hairs over the open source purity of these different approaches. They just want a Kubernetes that works with their other IT investments. That’s not about forking, it’s about making customers happy.