IBM finalized its $34 billion acquisition of Red Hat last week, one of the largest technology deals in history. A lot is on the line for IBM and for CEO Ginny, who some have said is staking her legacy on the deal. The companies themselves believe that, combined, they are “the leading hybrid cloud provider.”

The reality is that much of their software platform revenues come from traditional infrastructure business, not public cloud. IBM’s cloud business did grow in its most recent quarter, but only by 5%, which isn’t much compared to Microsoft’s 41% cloud revenue growth in its most recent quarter. And based on Red Hat’s last stand-alone quarter, its Application Development-related and other emerging technology subscription revenue accounted for a little over 24% of total revenue, with the public cloud related revenue being a subset of that number. Even with the addition of Red Hat, IBM clearly has some catching up to do when it comes to cloud.

One factor that will be critical to the success of this transition is IBM/Red Hat’s ability to win the hearts and minds of developers, who are critical decision makers in any enterprise’s journey to cloud. The rise of the developer hit tipping point more than five years ago – hand in hand with the success of cloud computing. Developers should be concerned that IBM could try to take them back in time to the pre-DevOps, pre-cloud dark ages where complicated technology and top-down selling of monolithic platforms to CxO’s reigned supreme. How and why could this happen?

Profiting from complexity

Enterprises now live in a cloud-first world that values simplicity and agility. But IBM is known for embracing complexity and monolithic platforms as a means to sell more consulting services. The services-heavy business model is key to its financial performance. Global Technology Services (which includes infrastructure and cloud services as well as technology support) is IBM’s biggest business unit. It generated $6.84 billion in revenue in its most recent quarter but came in under consensus estimate and added to Wall Street’s disappointment.

Now, with the Red Hat business, IBM has an opportunity to bring back its 1990s IT services strategy. Developers targeting cloud have happily moved on from big integrated services plays where companies like IBM prescribe monolithic full-stack platforms. They will not tolerate this sort of regression. And yet IBM will need to court them in order to fuel its cloud turnaround.

Enabling cloud choice, more or less

IBM may want to look deeper at what it just bought in Red Hat OpenShift. The OpenShift team has done a great job building an enterprise container platform that is second only to Docker’s platform. There’s lots for developers to like with OpenShift, including its ability to run on all the major clouds. But OpenShift is dependent on Red Hat Enterprise Linux (RHEL) CoreOS for its Kubernetes capabilities. This tight coupling of OpenShift with Red Hat’s operating system effectively means it is competing head-to-head with the container services from Amazon (ECS/EKS), Azure (AKS), and Google (GKE) rather than enabling the rich value of OpenShift to ride atop any of these cloud container services.

Additionally, IDC has found that when it comes to developers, “88% use containers with multiple operating systems (4.1 OSs on average), and 51% of container deployers have both Windows and Linux containers.” Red Hat has positioned itself as a leader in cloud, however a majority of workloads running in the cloud are not on the Red Hat Enterprise Linux operating system. This full stack approach from IBM (and now Red Hat) with diminished choice is a two-decade step backwards for today’s developers who are closer than ever to being able to develop and deploy modern applications anywhere they choose. Forcing OpenShift users to use Red Hat’s Linux stack is a strategy to protect revenue.

IBM/Red Hat appears to want to prescribe a monolithic stack of Red Hat products from top to bottom, all the way down to the operating system. Its leadership recently said, “This is the problem that we’re aiming to solve — providing a single, common operating environment across the hybrid and multicloud world.” But any solution that results in less choice, not more, is a regression that will leave a bad taste in the mouth of today’s developer.

Give developers what they want

IBM’s track record shows that as a platform company, it has “failed to make the transition to cloud computing … meanwhile the cloud continues to relentlessly devour IBM’s business,” as consultant Charles Fitzgerald recently put it. Just how quickly is cloud devouring its traditional on-premises market? 451 Research found that workloads targeting “on-prem traditional resources” are projected to drop from 40% today to just 19% in 2021. It also found that “workloads primarily executed in hosted/cloud environments” will grow from 36% today to 57% in 2021. This is a tectonic shift for IBM/Red Hat to navigate in their quest to be a credible cloud market contender. They will need the developer community on their side if they are to succeed.

But developers have already spoken, and they not only need but demand simplicity and choice. The success of public clouds like AWS, Azure, and GCP and the popularity of “Dockernetes” (Docker + Kubernetes) are examples of the power of developer-led adoption. A dated playbook of boxing in and trying to control developers through a Big Blue (and now Red) stack could ultimately harm IBM’s chances of achieving cloud relevancy.

Shaun Connolly is a strategist and advisor for young tech companies at AccelG2M. He has 25+ years as a software executive, business strategist, and product development professional with expertise in big data, cloud, devops, and open source. He previously held key product strategy roles at Hortonworks, SpringSource/VMware, JBoss/Red Hat, and Bluestone/HP. Follow Shaun @shaunconnolly.  

[VentureBeat regularly publishes guest posts from experts who can provide unique and useful perspectives to our readers on news, trends, emerging technologies, and other areas of interest related to tech innovation.]