When large companies with diverse product portfolios are acquired, the rationale for acquisition tends to reflect that complexity. This is particularly true when the cost of acquisition is high, as the models used to build the case for the move benefit from multiple paths to revenue, synergistic or otherwise.

In the case of what is likely the largest acquisition in software history, IBM’s addition of Red Hat, this is so much the case that it is difficult to know where to begin taking the deal apart. The number of potential storylines to explore from the combination of one of the industry’s largest and most iconic technology brands and the standard bearer for open source is literally endless, which analyses thankfully cannot be.

While historically large, the deal itself is not a surprise. Logical questions both about Red Hat’s long term strategy and what the company and brand represented as an asset have led, inevitably, to rumors about such a deal. Numerous destinations for the Raleigh based enterprise open source software provider have been debated, projected and calculated, mostly behind closed doors but every so often in public forums.

Until this weekend – or perhaps more accurately, recent weeks – this was mere speculation. Now we have, assuming regulatory approval and the absence of an unlikely third party intervention, an actual buyer. The question then is what this means for the two companies, their competitors and the industry as a whole.

The following won’t address every implication of the deal, for the reasons articulated above, but it will look at this news through five high level lenses: market, rationale, execution, open source and competition with one bonus aside at the close.

The Market

Infrastructure Shift

This deal comes at a unique time, both for the two companies and for the market itself. Most obvious, and much discussed in financial analyses of this deal, is the acceleration of the cloud market currently dominated by Amazon. Since AWS created the Infrastructure-as-a-Service (IaaS) category as we know it in mid to late 2006, the cloud has largely remade the industry around it in its image. Companies that once made money from selling x86 servers to businesses – IBM included – have largely exited those businesses entirely. However powerful, secure and reliable your hardware might be, it’s difficult to sell against a competitive offering that can be instantiated via a credit card for a nominal fee in ninety seconds or less via a browser. But the cloud’s ambitions didn’t stop with eating hardware infrastructure; providers have steadily moved up the stack into software infrastructure as well. Where vendors such as IBM, Microsoft and Oracle used to have an effective monopoly on database software with their proprietary offerings, as one example, today customers are not only turning to open source alternatives in record numbers, they’re increasingly asking the cloud providers to not just sell but manage those open source databases.

Application Platform Shift

But saying the cloud has been big and disruptive is neither informative nor news; this is understood even by the most casual observers of the technology market. What is less well understood and appreciated is that accompanying this surge of cloud adoption is a rare inflection point in enterprise application development models. For almost two decades, businesses building applications would typically select between two development models, one built in and around the Microsoft ecosystem, the other in Java. The result of this is that most if not all enterprises today have hundreds at a minimum and more likely thousands of applications written in Java running on middleware sold to them by the likes of IBM or Oracle. The businesses that wrote all of these applications are now faced with something of a dilemma. Both the way applications are developed today and the manner in which they are hosted has changed. These changes are significant enough that few if any of the old applications can move easily to modern platforms or be improved or modified at the speed with which modern businesses – who recognize that every business today is a software business – require. How should businesses develop applications today, and where should they be hosted? These are questions enterprises haven’t had to contend with for years, but which are now upon them in force.

Consolidation

The options for enterprise suppliers, meanwhile, are gradually becoming fewer. Consolidation is nothing new to the technology industry, clearly, but there are indications that the conflation of infrastructure, software and managed services that the cloud represents – not to mention the economies of scale they can bring to bear – is putting pressure on the market in an unprecedented fashion. In some cases, this means mergers such as Cloudera and Hortonworks. In others, it’s standard M&A as in the case of GitHub, Magento or Mulesoft – the average cost of which was north of $5B. And with one of the industry’s longest tenured and largest independent suppliers now becoming part of IBM, the value of and need for competitive responses from well capitalized major players will only increase.

The Rationale

Among other macro market forces, then, we have cloud disruption, a generational shift in application platforms and a narrowing of the pool of potential suppliers. What do all of the above have to do with IBM’s desire to acquire Red Hat, and Red Hat’s willingness to be acquired – if anything?

Red Hat

Let’s consider the latter first. For most of its history, and particularly since eclipsing the billion dollar revenue market in March of 2012, Red Hat has been held up as the example of what pure play open source companies can achieve. But there were problems with this assertion that went beyond the fact that at least some of Red Hat’s initial success was due to closed source software as Mike Olson has pointed out. Most notably, there is the fact that twenty-five years after Red Hat was founded, there are no other pure play open source companies to have crossed that billion dollar threshold. Which shouldn’t come as a surprise – Red Hat has had to work harder to get there, in part because it makes its money selling software that customers are entitled to download and use for free. Before adding about $8B in value following the IBM news, Red Hat had added an average of $848M to its market cap per year since its founding. For the closed source infrastructure provider VMware, that number is $2.7B.

What that leaves us with is Red Hat as a successful provider of enterprise infrastructure software but one that was something of an outlier, both for the fact that it was as successful as it has been and because of the lower performance relative to some of its proprietary peers. Next we factor in the reality that a huge portion of the enterprise infrastructure growth moving forward is going to come from public cloud suppliers, the same suppliers that are disrupting both the traditional enterprise operating system market and the traditional application platform model. Which is worth expanding on, because two of Red Hat’s core markets are the traditional enterprise operating system and application platform models.

In its earliest days, of course, Red Hat was an operating system vendor. Its flagship offering, Red Hat Enterprise Linux (RHEL), was the de facto victor of the Linux operating system wars and outlasted efforts from others such as Sun Microsystem’s Solaris to seriously challenge the dominance of Microsoft’s Windows on the server. For many enterprises, in fact, Linux became synonymous with Red Hat – a fact that former Sun CEO Jonathan Schwartz used to tweak Linux advocates with, in fact. Recognizing, however, both that platforms have lifespans and – as IBM has proven in the past – that a lot of the value, and therefore revenue, was up the stack from the operating system in the middleware layer, Red Hat made the decision to compete with its partner IBM in open source fashion, purchasing the open source WebLogic/WebSphere alternative JBoss for $420M in 2006. This meant they were officially players in the Java middleware space, a space that had another few years left in it as the unquestioned dominant enterprise development option. Après, le déluge.

• Two months after JBoss was acquired, Amazon released EC2 which would provide the blueprint for an entirely new generation of platform.
• A year later, Force.com and Google App Engine introduced the concept of Platform-as-a-Service.
• Four years after that an open source PaaS called Cloud Foundry was released.
• Cloud Foundry, in turn, eventually had to contend with the explosion in popularity of containers following the release of Docker in 2013.
• The eventual de facto management solution for those disruptive containers arrived in the form of Kubernetes in 2014.
• Five months after Kubernetes dropped, AWS unleashed Lambda, and thus serverless, on the world.

If that seems like a lot to follow in a short span of time, that is in part the point. Enterprises were and are still struggling with this explosion in infrastructure choice. But while they might not have realized what the correct choice is, it’s clear that their traditional practice – both the technology and the processes associated with it – were non-viable over the long term. Which meant that the role of the traditional middleware stack, and to a lesser extent, the operating system it ran on, was no longer as certain as it had once been.

All of which would have been a major problem for Red Hat had it been caught flat footed by these changes, but it had seen this transition coming and planned for it. While its initial efforts in the open source PaaS space were largely considered a failure, this counter-intuitively provided it with the opportunity to embrace the container questions that its counterpart Cloud Foundry struggled with, as OpenShift was rebooted to embed containers and Kubernetes.

Today, then, Red Hat is a company with one foot in the old world of operating systems and Java application servers and the other in containers, Kubernetes and other potential growth opportunities like Ansible. The question for Red Hat, however, was not whether it had a plan for bridging from one world to another, but what that process would look like financially. And even if that bridge was seamless on the Red Hat side, what are the dynamics of a world in which the major cloud providers are aggressively competing in the application platform space – even in the once safe on prem space now with Google’s GKE – and in which they have advantages ranging from adjacent services to customer acquisition to preferential network treatment? There is opportunity certainly in their stated goal of transcending not only on and off prem environments, but by mitigating the differences between the different public cloud providers themselves, much as the Java middleware stack once abstracted customers from individual hardware or operating system suppliers. The shape of the market in which Red Hat competed long term, however, was less than clear.

By agreeing to the acquisition, even with the hefty premium paid to shareholders, Red Hat seemed to acknowledge the uncertainty of their path forward as a large vendor, yes, but one dwarfed by the Big Four hyperscale cloud providers.

IBM

If we have an idea why Red Hat might see benefits to being absorbed into a larger organization with more resources and greater reach, the next question is what IBM sees in Red Hat. The answer, as with any large acquisition, is many things, but big picture Red Hat is the both an opportunity for growth and the path-of-least-resistance for IBM.

Many have argued correctly that Red Hat isn’t an asset likely to materially alter the company’s fortunes with respect to the cloud. It’s not clear, however, what acquirable asset would fit that bill. Nothing on Marketwatch’s list of cloud companies – or to be more accurate, nothing realistically acquirable – would be likely to move the needle for IBM in the cloud. Even the acquisition of a private company with an attractive cloud platform such as a Digital Ocean would be impactful primarily at the margins. As my colleague has discussed in the past, success as a major public cloud player is intrinsically tied to infrastructure spend, and the number of players spending at the requisite levels is limited and does not include either IBM or Red Hat.

While it’s fair to say that declining to invest at the levels necessary was a mistake dating back to Sam Palmisano’s tenure, the present leaders of IBM have to play the hand they have in front of them, not the one they wish they held. If a major public cloud play is not in the cards, what’s the alternative? One option would be maximizing the company’s footprint off the public cloud while attempting to replicate the success of its classic middleware business on it. Red Hat, notably, can help them accomplish both of these goals.

There is, has been and likely will be for the foreseeable future a debate about what percentage of enterprise infrastructure will end up off prem versus what is maintained and managed in house. Partisans abound on both sides, arguing on the one hand that the economies of scale involved among other justifications make private infrastructure a bad investment even before considering all of the other associated difficulties of competing with the public cloud. At the other end of the spectrum, advocates of private infrastructure point to examples like Dropbox – for better and for worse – as evidence that the economics of the public cloud are much less compelling at scale than is commonly realized.

Both sides have ammunition, but seem to rely on the faulty assumption that infrastructure decisions are made by strictly rational actors. In truth, technology decisions are at least as much about inertia and convenience as they are cost, efficiency or performance. Which suggests that while the cloud growth will easily outpace private infrastructure spending, in house datacenters and infrastructure will remain common for the near to medium term.

If this assumption is correct, it means that Red Hat’s core infrastructure capabilities from its flagship operating system and associated technologies down to its core OpenStack platform will have value for those businesses that choose to maintain or even grow their own infrastructure rather than outsource it to the hyperscale cloud vendors.

But while much of their attention may be on the world beyond the public cloud, both IBM and Red Hat need access to those markets to be successful. A world in which they only service on premise workloads is a world in which they’re locked out of the highest growth market in the industry. Which is where OpenShift, and more specifically Kubernetes, come in. The third version of OpenShift, Red Hat’s Cloud Native platform, was built on and around Kubernetes and thereby the container infrastructure that proved to be such a developer phenomenon. This allowed Red Hat to rapidly ramp up an effective successor to its classic middleware business, JBoss. Between the strong account presence and salesforce Red Hat has built over the years and the surging demand for container based infrastructure, OpenShift became another platform success story for Red Hat.

This platform success story is likely to be what sealed the deal from an IBM standpoint. The RHEL business is larger, without question, but the OpenShift business better projects into the future – and not just an on prem future. Instead, OpenShift offers IBM an opportunity to run a play it knows well, one it has run before with great success.

In 2001, IBM committed to spending a billion dollars on Linux. Interestingly, however, this did not include selling the operating system itself, but rather making it better, making it more credible and making it more visible. IBM was content instead to leave the potential operating system revenue on the table for the likes of Red Hat and SuSE. This was because the company had determined that the real commercial opportunity wasn’t in the baseline platform, but rather up the stack in the layer of abstraction that sat on top of the operating system. This software came to be called middleware, and IBM’s offering in the space WebSphere generated an enormous amount of revenue for the company’s software business – far more, in fact, than the creator of the Java technology it was based on, Sun Microsystems, ever saw from such an offering. The promise of middleware ultimately was that enterprises could build an application and be assured that it would run independent of hardware or operating system concerns. A customer could pick or even migrate to the hardware and operating system of its choice and the application (at least in theory) would work: this was the essence of Java’s “Write Once, Run Anywhere” tagline.

In OpenShift, IBM has a similar opportunity. Just as applications once upon a time were written to Java application servers in part because of the promise of portability, so to are they now being written to various cloud native platforms – OpenShift included – to avoid being explicitly tied to a given platform. Twenty years ago the vendor names were Dell, HP and IBM; today it’s Amazon, Google and Microsoft. The principle, however, is the same: vendors who can offer an enterprise the promise of independence have something of value to offer.

Much of the rhetoric accompanying the announcement of the deal cited “hybrid cloud” opportunities as a primary justification for the move. If one assumes that that term implies highly integrated on and off premise environments, however, the use of that term might be aspirational. While many organizations have extensive on and off premise infrastructure investments, comparatively few of them are sophisticated in the way that those environments are tied to each other. If expectations are scaled back to the more realistic “multi-cloud” – the idea that an organization may have investments in more than one environment – the relevance and importance of OpenShift becomes more clear.

A combined IBM and Red Hat can go to market with a message that tells customers that they can write an application once, and deploy and run it in any environment – and any cloud – they choose. That includes the IBM Cloud, importantly, which would presumably be paired with incentives to drive workloads, much as Oracle is currently doing to capture Oracle-centric workloads. While Amazon, Google and Microsoft have all experimented with extending their clouds into customer environments – from Azure Stack to GKE on Prem to RDS on VMware – they are to on prem as IBM and Red Hat are to the public cloud. Hence, the middleware-style opportunity.

The Execution

If those are, at least in part, the goals from both sides, what are the odds of the combined entity achieving them? While it’s always preferable to have a clear answer, or failing that an estimate of probability, the truth is that in transactions of this size there are too many variables to be calculated with any reasonable degree of precision. Here’s what can be said with substance.

Much depends on questions of execution, and in this case in particular, independence. It is true that as a general rule, the majority of acquisitions fail. Of battle plans, Helmuth von Moltke the Elder once said “No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength.” The same principles apply to acquisitions. What may seem like an obvious and inevitably successful combination on paper can be undone by cultural mismatches, integration difficulties or poor leadership.

Even if both parties believe in their individual justifications for the move, justifications built in part on a shared vision, there is always reason to be skeptical of potential acquisitions. Many of the initial reactions to the news from the rank and file, particularly those working for Red Hat, echo this skepticism. One example read that IBM has an “an almost wholly bad reputation for acquisitions.”

That view isn’t necessarily shared here, however. Certainly the company has had its share of acquisitions that have gone poorly, but the company’s track record here is better than some. Having been through the acquisition process 167 times not including Red Hat since 2001, it’s safe to say that IBM has learned a few things about what works and what does not. Nor have all the acquisitions been tactical; Lotus, PwC, Rational, Tivoli and others represented large capital outlays that were ultimately successfully integrated into IBM’s portfolio.

In part, this is because IBM has made a habit of acquiring close partners. This reduces the risk, because there are existing organizational relationships in place, the respective salesforces are often familiar with each other, and so on. In at least one sense, then, this transaction has a higher probability for success because Red Hat is and has been for years a a close IBM partner. This is not an inorganic strategy grab, but the absorption of a business that is known and respected within IBM. Many Red Hat developers, in fact, have been working closely with their IBM counterparts for years on a wide variety of open source projects.

That being said, Red Hat’s culture is distinct not just from IBM but from the industry as a whole. As the only truly large pure play open source organization, Red Hat’s developers and employees have a passion for their mission and for open source that is entirely unique amongst similarly sized organizations. Many of its customers share this passion, if not quite so ardently and for possibly more pragmatic reasons.

IBM reportedly understands this fact, and has as part of the transaction provided assurances of appropriate firewalls between the organization to maintain Red Hat’s independence. But these assurances will be tested, particularly if the financial fortunes of its acquirer continue to be mixed.

In the end, the success or failure may come down to leadership, a subject we’ll come back to.

The Open Source Implications

Because of Red Hat’s status as the world’s largest open source company, and its employees commitment to those ideals, much of the attention paid to this deal has centered around the question of what it means for open source. A variety of narratives around this theme have emerged, but the two most common are:

• That IBM fundamentally doesn’t get open source and will therefore ruin Red Hat.
• That in combination with other large open source deals the Red Hat acquisition is both validation and victory for open source.

Taking those reactions in order, the first is simple enough to address. IBM as a company has many failings, but a lack of understanding of open source is not among them. Even aside from its contributions to hundreds of projects over the years, its work to support multi-party governance, foundations and more, IBM has played a central role in establishing the mainstream credibility of open source generally and projects like Linux specifically.

The company’s track record in open source is not perfect, of course. Like most commercial organizations that have engaged in open source communities at scale, they have certainly had left disgruntled parties in their wake on occasion when IBM’s interests diverged from a given project’s. But this kind of friction is inevitable when you engage in as many projects as IBM has historically and across the broad canvas of open source IBM’s contributions are numerous and substantive.

The company may not be receiving the same credit today that Microsoft is receiving for its excellent VS Code, then, but the folks from Redmond are merely following in IBM’s footsteps in that regard: the release of Eclipse as open source software in 2001 democratized access to a usable, high end IDE for developers all over the world. The CNCF’s Chris Aniszczyk, then, is correct to characterize the open source lines of criticism of IBM as lacking substance.

At the other end of the spectrum is the view that the acquisition of Red Hat is a blessing for open source – see headlines like “A breakout year for Open Source businesses,” “The true lesson of IBM’s move for Red Hat: Open-source has truly arrived” and “IBM’s acquisition of Red Hat takes open source’s 2018 tally to nearly $55 billion.” Unquestionably, the fact that the largest acquisition in the history of software is for a provider of open source tools is significant and a signal. The question is whether it’s also a turning point.

It’s not clear that open source needed to be validated, precisely, since it has been a foundational technology for businesses large and small for years now. It’s been five years since Mike Olson wrote that you could no longer win with a closed source platform, and sixteen since the same IBM questioned for its open source credentials deprecated its own web server in favor of the open source Apache alternative. But the billions of dollars funneled into open source businesses this year is a counter to the argument that open source cannot make money.

The question is how sustainable this commercial model is moving forward. In recent years we’ve begun seeing businesses avoid, bend or break open source models; CockroachDB and MariaDB have embraced non-open source, source available licenses, Elastic (2018 IPO) has commingled open and source-available code, MongoDB (2017 IPO) has dropped its open source license in favor of one that the company hopes will ultimately be considered open source, and Redis Labs and others embraced a license rider that converts open source code to source available.

The driver behind these moves was, unsurprisingly, the cloud. As RedMonk has been arguing for several years, as much as the cloud has created opportunities for commercial open source providers as well as net new open source projects, it also represents an existential threat to those would would take open source and sell it. Every company that has pursued these non-open source licensing strategies understood or was advised that they would face a backlash for pursuing a course that compromises the Open Source Definition. All felt compelled to accept the risk and proceed anyway, such is the fear that cloud providers have put into them.

While on the one hand, then, one of the world’s most iconic technology companies is paying north of thirty billion dollars for a commercial open source organization, its would be successors are increasingly turning away from open source as a commercial model – or are forced into essentially defensive mergers. Which begs the question as to whether Red Hat is a sign of things to come, or the last of its kind. Will there be another Red Hat, in other words?

Peter Levine, the former CEO of XenSource, says there will not. This is likely correct. It’s difficult to imagine a pure play open source company, even one that began its life with a differentiated proprietary offering, becoming as large as Red Hat was at the time of sale. It is not accurate to say that the problem of commercialization is strictly an open source phenomenon – The Software Paradox doesn’t discriminate between closed and open source software for the most part – but it may be more acutely felt. In either case, the most efficient and reliable commercial model moving forward is not likely to be on prem software that is either open or closed, but rather software offered as a managed service. This very realization may have, as described above, contributed to Red Hat’s willingness to be acquired.

The implications of which for open source are less than promising. The best way to summarize the significance of the Red Hat acquisition for open source ultimately may be to say that it validates its past while raising significant questions about its future. The industry tends to take open source for granted, but this deal is an indication that it shouldn’t.

The Competition

Having discussed the implications of this transaction for the two companies involved, it’s time to turn our attention to the wider market. What are the implications for IBM and/or Red Hat competitors? There are too many to assess broadly, but let’s look at a select few.

• Amazon: Amazon’s reaction to this internally was likely muted. It is currently the dominant platform in the cloud, and while it got caught on the back foot to some extent with containers and Kubernetes, it hasn’t made a dent in the company’s momentum either financially or in terms of visibility. Amazon doesn’t have the same depth of account control that Red Hat does, but its reach is so extensive that the last thing Amazon needs to spend money on is buying account control. Nor would Red Hat’s multi-cloud strategy hold much appeal for the largest and fastest growing cloud in market.
• Google: Of all of the non-IBM rumored potential acquirers of Red Hat, Google would have made the most sense. The cultures would have been a difficult fit at best, but the access to Red Hat accounts would have been an enormous shot in the arm for a cloud that has a reputation for great engineering but subpar outreach, visibility and enterprise access. That being said, it’s easy to imagine Google and IBM/Red Hat forging a tight partnership, as each needs what the other has.
• Microsoft: While Microsoft and Red Hat historically sat on opposite sides of an ideological divide, there has generally been some mutual respect – and even a bit of cross-pollination – between these two companies. Still, Red Hat to Microsoft was always a long shot, in part because they already have the account access that Red Hat brings with it and substantial expertise and product around Kubernetes, but also because it would be very interesting to see what regulatory authorities would make of the two largest commercial operating sytem providers consolidating. Some have argued that IBM/Red Hat is bad news for Microsoft, but any success IBM and Red Hat have pushing a multi-cloud agenda is ultimately a win for Microsoft.
• Oracle: Like Google, Oracle could have used Red Hat as an opportunity to differentiate and energize its cloud platform, but it would have had to pay for assets it didn’t require such as Red Hat’s customer base – many if not most of which are using an Oracle database somewhere. This would have been a truly difficult fit culturally as well, as it’s only in recent years that Oracle has made any overtures to developers whatsoever – and many from Red Hat have never forgiven the database giant for OEL.
• Pivotal: On the one hand, Red Hat stands to gain access to a huge bank of new IBM accounts into which it can sell OpenShift, backed when/if necessary by a wide portfolio of other cloud and database assets. On the other, Pivotal just became the most attractive means for any existing supplier to inorganically jumpstart a middleware, multi-cloud business backed by one of the most impressive enterprise process modernization offerings in market. There’s a reason PVTL has been trading a dollar or more higher per share since the news broke: without lifting a finger, it’s more valuable than it was last week by virtue of dwindling supply and a sharply growing demand for what it provides.
• VMware: The news is somewhat less welcome for the original Pivotal parent, VMware, in that a combined IBM and Red Hat represent a more legitimate threat to VMware’s stranglehold on on premise infrastructure than either one of them independently. That said, the company has done a good job of finessing the transition from virtual machines to containers, and is a fixture in the datacenter in a way that few vendors outside of Microsoft have ever been. VMware would have preferred a different outcome, almost certainly, but its situation is far from dire.

(Bonus) The Leadership

When the news of this transaction broke over the weekend, one of the first things that crossed my mind – before reading any of the details about IBM’s promises of independence for Red Hat – was what would become of the current Red Hat CEO Jim Whitehurst, who is generally well regarded for his tenure at Red Hat. The next thought was to wonder whether Whitehurst was, in fact, one of the assets being acquired. Since then many have publicly speculated that he’s ticketed for the IBM CEO role – with some even going so far as to promise that will occur within six months. That seems to be, at best, idle speculation.

It is curious, however, that the largest software acquisition in history comes at a time when IBM is at a crossroads, and the acquired entity is led by an executive of a similar age to other senior executives that IBM has promoted into the top role, and that said executive’s non-software background – being a former COO of Delta – lends him the kind of outsider’s perspective that has benefited IBM in the past, most notably with Lou Gerstner.

Only time will tell what IBM has in mind for Whitehurst, but assuming the transaction closes, he should be as closely watched as the product teams.

Disclosure: IBM and Red Hat are RedMonk customers, as are Amazon, The Cloud Foundry Foundation, Digital Ocean, GitHub, Google, Microsoft, Oracle, Pivotal, Salesforce (Force.com) and VMware. Cloudera/Hortonworks and MuleSoft are not RedMonk customers.