I spent about five years as a Sales Engineer / Solutions Architect for one of Red Hat's channel partners.  This meant that, while I had no systems of my own to manage as part of my day job, I had to really understand all of their products in order to go stand in front of clients, listen to what projects they have on their radar, and map Red Hat product into those projects.  If there simply was no fit.. no harm, no foul, time to move on.  But, I used most of the products in my own projects, so I believed in them and know what they could do.

A Brief History of RHV

It's a tough task going to clients and convincing them to use a product that the vendor itself doesn't believe in, or market, or put major resources into.  Specifically I'm referring to Red Hat Virtualization... an enterprise virtualization product with the KVM (Kernel Virtual Machine) Hypervisor at is center.  KVM, like many of Red Hat's products, started life at a startup who saw the possibilities in KVM, and decided to throw its hat into the virtualization ring to compete against vmware.  The timeline was not way off,  vmware just had an extreme head start, more money, and a stable product. 

When Red Hat acquired Qumranet in 2008, Solid-ICE (the product which became RHEV) was a kludgey mutt of a product that actually required a windows machine to run the management plane.  As you might expect, Red Hat was anxious to get its new acquisition to market, so it rushed the process of onboarding the product, and went to market in 2010 with a very problematic product.  Even worse luck, people were excited for a vmware alternative, and many bought in... only to badly regret doing so.  At that point, the product was a mess.  Sadly, the damage was done.  Sales teams were badly snakebit on the product.  Management was badly snakebit on the product.  But the RHV BU and development team kept working on it and improving it.

By the time I started working to position RHEV with Clients, it was 2014 and RHV 3.3 was out, and it was light-years better than the product that went to market in 2010.  I earned my RHCVA certification against RHEV 3.3.  It still had the odd quirk in places, but generally speaking, RHEV was a solid competitor to vmware.  Price-wise it should not have even been a conversation - customers looking to save money could do the exact same things with RHV as with vmware, at 1/10 the price.  But even Red Hat was not really interested in talking to customers about RHEV.  Too many in the hierarchy remembered how bad things were in 2010, and simply weren't willing to take the chance.  They pointed to bad sales numbers as justification that it must not be a great product... but if your customer base doesn't know your product exists, it's unlikely they're going to beat down your door to buy it.

Toward the end of my five years as a channel partner, Red Hat started offering to give away RHV entitlements as part of their Virtual Datacenter bundles on 3 year deals, to give customers an opportunity to start using it while the customer's vmware ELA was in effect, with the intent to migrate off of vmware and onto RHV by the time the ELA was up.  Sadly, many sales teams were just using this SKU on deals where they sold the bundle, and very few, if any of them, renewed their subscriptions WITH RHV when the time came... often because they didn't even know they HAD RHV.

The messaging from management continued to get more dire, especially after Container Native Virtualization became a thing.  OpenShift had quickly become the darling of the company, partly because it is positioned as a frontronner in the kubernetes field, and many consider Kubernetes to be the future of IT.  Partly because openshift is expensive.  Either way,  with OpenShift taking center stage, and this new virtualization concept that could be bundled into OpenShift, management saw an opportunity to push out the product that had bitten them so badly 10 years earlier.

When Red Hat announced the forthcoming release of RHV 4.4, they indicated that it would be the last production release, and that they were essentially putting their eggs in the OpenShift Virtualization basket.  Except that OpenShift Virtualization was in its infancy, and was not even intended to be an Enterprise Virtualization solution.  In reality, RHV and OSV were complementary products, but Red Hat decided to finish out release 4.4 then essentially drop the product on the sidewalk.   4.4 is THE most stable release to date, and really closed the last few gaps that existed between RHV and vmware.  Yet Red Hat decided they were going to just... walk away from it.  The upstream community is alive and well, meaning oVirt is going to continue on, Red Hat just won't continue developing against it.

The Final Days of CloudForms

Going back to those days from 2014 on, Red Hat had a very clear strategy and mission.  They wanted to provide all of the building blocks that might be used to build a hybrid cloud solution, and/or develop apps to run in a hybrid cloud.  They had built a portfolio that filled all of the gaps in the tech stack.  You had:

• RHV for Virtualization Workloads
• RHOSP (OpenStack Platform) for Cloud Native workloads
• RHOCP (OpenShift Container Platform) and Atomic/CoreOS for DevOps and Microservices, designed to run atop whatever platform makes sense to you (baremetal/RHV/OpenStack/vmware/AWS, etc)
• RH CloudForms to provide a central management plane and self service portal to tie it all together and really provide the single pane of glass that companies wanted, for managing ALL of their hybrid cloud needs.
• RH Storage in two flavors to provide the data backend for all of the above
• The JBoss family of products to provide the various application features required for complex enterprise application development
• 3Scale to give you an API gateway to all of the above and whatever they need to talk to
• And RHEL underneath all of it

The best part about Red Hat's approach was that each of those products could be used independently and it would do exactly what you needed it to do.. there was none of the artificial drag that most vendors create, such that if you purchase product A, it will only do 10% of what it claims to do.. you have to purchase products Q, S and Y if you want the other 90%.  So customers who were leery of relying on one company for their entire technology stack, could easily and safely pick and choose where they were willing to depend on Red Hat.

In 2018 it was announced that IBM would Acquire Red Hat.  For those of us who drank the Red Hat Kool-Aid and who are Open Source true believers, this was both thrilling and horrifying.  It had the POTENTIAL to take Red Hat to the next level, inject new money into the development process to finally allow some of those troubled products to ride the wave into a new position of strength.  It also had the potential to destroy what many of us viewed as a true bastion of Open Source ... maybe not wholesomeness, but mindset, for sure.

I took a job with IBM in August of 2018, and the acquisition went through around the same time.  My team was tasked with building an on-prem private cloud, and largely due to the acquisition, the decision was made to utilize the Red Hat Tech stack.  Which is part of why they hired me, as I was well versed in most of the RH tech stack.  The decision to use CloudForms was mostly made when I started, but my fervor for the product and familiarity with it pushed the decision over.  So I probably have to assume a significant part of the blame for what happened to the product.

Prior to our efforts on the project, IBM paid very little attention to CloudForms as a product.  They didn't know much about it, and really hadn't spent any time loooking at it.  Numerous people within GTS looked at our decision and tried to take us to task for it, but we kept moving forward, and were able to demo an early version of our product.  Overnight the conversation changed.  People started asking us why we chose it.  We demonstrated all of the various features, and much whispering started among folks who hadn't realized just how useful and flexible and feature rich it was.  Then the worst possible thing happened.  IBM decided it wanted CloudForms.  Mere months away from our product going GA, IBM took CloudForms from Red Hat, transferred all developers to IBM, and forced Red Hat to push all existing customers to IBM for support.

This was bad for everyone involved.  IBM had not taken the time to build out any kind of build environment, nor did they have any infrastructure to support providing updates (the way Red Hat did, i.e. yum update).  At first it didn't really matter, because Red Hat was still providing updates for its last version of CloudForms.  IBM buried CloudForms in one of its many "CloudPaks".. bundles of products that clearly can't stand on their own, but likely add value to somebody when bundled.

Now, tying back to the title of this article... CloudForms too is an open source product.  Its upstream community is ManageIQ, whch, interestingly, is mostly comprised of IBMers who came over from Red Hat.  The fact that it's Open Source really raised my eyebrows when IBM 'took' the product... because it's not IP.  There's literally nothing stopping Red Hat from continuing to have its own ManageIQ based product.. nothing other than IBM dictating where they spend money.  Sadly, IBM still has no update mechanism for Infrastructure Management (their new name for CloudForms).  Although they did take the step of switching to CentOS under the hood in their templates, so you no longer get the benefits of having it live atop RHEL.  So you can't patch the application, and the application lives on a community supported operating system.

Tying it all Together

Back when Red Hat was an independent company, it had a clear vision of how their products fit into the enterprise ecosystem, and they ensured they had an answer for each component of the enterprise hybrid cloud technology stack.  Now, under IBM, they have no clear direction other than "We have OpenShift... oh.. and some other stuff too", and they've taken two amazing products with existing customer bases, and effectively dropped them off at lost and found.  *ANYBODY* could come along and pick up either project and they would have a salable, enterprise-grade product that competes extremely well against industry leading products... and that's without having added anything in the way of value, on day 1.  Heaven knows I've attempted to get at least one company to do exactly this, but so far I've not been successful.

The beauty of Open Source is that so long as a project continues to have active developers, it will live on even after the companies that built products around them die off.  It does also mean that you could be picking up a product at the same time that 10 other companies decide to pick it up and run with it.. like Kubernetes... but really, that's good for the product, too, because each of those entities will have to infuse their own ideas into it to stake out their unique claim to why their flavor is best.  

Red Hat exemplified the ugly side of the business behind Open Source... demonstrating that an Open Source project/product only has value as long as the people who control the money still believe in the project/product.  My hope is that both projects continue working to improve, and eventually show just how foolish those bean counters were.