[RHT – Red Hat] On A Bridge Between Clouds

Let’s take it back to ’69.  The Unix operating system was just conceived under Bell Laboratories, the vaunted research joint venture of AT&T and Western Electric.  Protected by the strictures of a consent decree from 1956, which prevented its parent AT&T from commercializing technology that wasn’t related to telephony, Unix thrived as an open research project, absorbing the contributed code and feedback of far-flung programmers outside of Bell Labs, at first mostly from universities but then later from businesses, whose collective efforts drove rapid upgrade cycles.  But then in 1984, after antitrust action led to AT&T’s breakup, the decree no longer applied and AT&T yanked UNIX from its collaborative research confines and crassly commercialized it, to the great consternation of a community of hackers who felt their common values of sharing, transparency, technical excellence, and independence suddenly betrayed.  This provoked Unix developers to build or rally around competing free and open sourced Unix variants excised of commercially licensed Unix code. [When I append the label “open source” to anything in the post, I mean source code that be freely examined, modified, redistributed, and used by others] [it’s hard to believe today, but up until the early ’80s, closed source software and software copyrights and patents (the latter protecting the software program’s “concept” rather than the code itself), were novel ideas]. 

One of those developers was Richard Stallman, a programmer in MIT’s AI Lab, who after quitting his job at MIT in 1984, would begin working in earnest on what became known as the GNU operating system.  Among the significant developments to emerge from this effort was the GNU General Public License (GNU GPL), a “copyleft” (get it?) license that formalized the terms and scope of source code sharing and remains the most popular governing license in the free and open source (FOSS) domain.  There are a number of different open source licensing schemes out there, but what makes GPL notable is that if you modify GPL governed software and distribute it, you must make your modifications publicly available.  Still, despite considerable legal and technical success, the GNU community failed to produce a kernel [the critical part of an operating system that allows applications to communicate with the underlying hardware] even a decade after the GNU’s launch, and its developers haughtily refused to clone a version for the burgeoning minicomputer and PC market, catering instead to powerful and expensive hardware that could appreciate GNU’s impressive technical prowess.

This cleared the way for a young Finnish programmer with communist sympathies, Linus Torvalds.  As an undergraduate student isolated in Helsinki with no access to the uptown resources available to open source programmers with high brow credentials at fancy universities, Linus built a Unix-like operating system tailored for the PC, and made it freely available (free as in both “beer” and “liberty”).  Linux 1.0, a production ready version of the kernel, was released in early 1994 and by the mid/late ’90s, it became the kernel of choice for most free operating systems under development.  Linux was combined with utilities from the GNU project to create dozens, maybe hundreds of GNU/Linux “distributions”, one of which was called Red Hat.  By 1998, Red Hat Linux accounted for 56% of Linux-based server operating system shipments.

Leading up to and during this time, while the desktop market remained captive to proprietary vendors, open source found widespread adoption in web-related infrastructure – Apache became the #1 system for web servers within a year of its 1995 launch, its success complemented by open source scripting languages (PHP, Perl, Python) and the MySQL database – drawing the wrath of Microsoft, who denigrated the usability of open source software even at is it co-opted open standards for its own proprietary products.  But open source adoption could not be stopped and today, the Linux kernel and other open source programs undergird nearly all smartphones, connected devices, blockchains, and enterprise computing clouds.  Microsoft’s former CEO, who once declared Linux “a cancer”, has been replaced by a new CEO who now professes “Microsoft loves Linux”.  Microsoft recently agreed to support Red Hat Enterprise Linux – a Linux-based operating system supported by Red Hat and Red Hat’s largest revenue source – on the Azure Marketplace, and according to Red Hat management, RHEL growth on Azure is “exploding”.

[I learned a lot about the historical backdrop of open source software in the book For Fun and Profit: A History of the Free and Open Source Software Revolution by Christopher Tozzi.  I highly recommend this fine book if this topic interests you].

But despite the ubiquity of open source, commercial success has largely eluded companies supporting it.  Outside of Red Hat, there has not been a single open source software company of note, and even 25 years since its founding, Red Hat’s $3bn of revenue and $25bn of market value pales in comparison to proprietary peers like Oracle ($200bn enterprise value; $40bn revenue), Microsoft ($100bn; $660bn), AWS ($20bn, ~$300bn?), and Salesforce.com ($85bn; $10bn).

Doubts about the viability of open source models are nicely summarized in the following remarks by Peter Levine at a16z from his blog post Why There Will Never Be Another Red Hat: The Economics of Open Source:

“There are many reasons why the Red Hat model doesn’t work, but its key point of failure is that the business model simply does not enable adequate funding of ongoing investments. The consequence of the model is minimal product differentiation resulting in limited pricing power and corresponding lack of revenue…it’s nearly impossible to properly invest in product development, support, or sales the way that companies like Microsoft or Oracle or Amazon can.

Product roadmaps and requirements are often left to a distributed group of developers. Unless a company employs a majority of the inventors of a particular open source project, there is a high likelihood that the project never gains traction or another company decides to create a fork of the technology. The complexities of defining and controlling a stable roadmap versus innovating quickly enough to prevent a fork is vicious and complex for small organizations.

To make matters worse, the more successful an open source project, the more large companies want to co-opt the code base. I experienced this first-hand as CEO at XenSource, where every major software and hardware company leveraged our code base with nearly zero revenue coming back to us.”

For the most part, over the past decades open source companies (including Red Hat) entered existing markets already staked by their closed source counterparts who continually reinvested gross profits in new product R&D and built sales organizations to secure large enterprise engagements.  Without product differentiation, open source vendors were left to compete viciously for low margin support sales.  In the case of Red Hat, even the very notion of product is somewhat squishy.  Red Hat isn’t really any single product category or trend – the way you might think salesforce.com for CRM, Oracle for databases, SAP for ERP, VMWare for virtualization – so one strains to viscerally understand what it is the company actually does.  At a high level, Red Hat stitches together open source projects that allow its customers to create and manage software.  It offers maintenance and support for freely distributed code just like every other open source player…but this description is far too reductive and doesn’t account for how this company has succeeded where nearly every other open sourcer has flopped.

Red Hat does not passively yank code from open source communities, drop it inside enterprises, and simply support it.  It instead identifies the most technically advanced projects that it thinks will have the most significant market impact, brings those projects into a development community like Fedora for further testing, and takes a lead development role as the number of 1 or 2 contributor, as it is in significant open source projects like Linux, Kubernetes, OpenStack, OpenShift.  The company dedicates its own engineers to these projects, working on them as though they were its own. [I’ll get into Kubernetes, OpenStack, and OpenShift later in this post]