It’s Like Building a Swimming Pool – InApps 2022

Open source software offers many compelling arguments for the consumer: You get access to the latest thinking in solutions with considerable industry and private contribution to making that software interesting. It’s no wonder so many developers and IT organizations jump on to these free offerings. But when is free, not free?

Among the many promises of OpenStack was that it would replace what was perceived to be the high price and lock in of VMware’s vSphere. The problem with OpenStack is that it rarely fulfilled its promise. It’s too complex and there’s too much splintering in the community from a distro standpoint.  While there are some successful projects with OpenStack, for the most part it came from the “not free” variety where you paid someone for the implementation of their specific distro (Cloudscaling, Mirantis, Red Hat).

However, for even those projects you might struggle to find a project owner who thinks it was easy or free. In some companies where an implementation was considered successful after year long projects, they are now seeing OpenStack as legacy. There’s no way I can say that in any or all the OpenStack projects that VMware would have solved their needs but in many cases, it would have. I’m not a VMware hype guy. In fact, I’m just as often heard talking about their grip on license costs and the perceived lock in. However, getting work done for the business is what IT and engineering is paid to do. We’re not paid to try the next “hot” thing.

A Swimming Pool vs. Open Source Software

Ride along with me for a moment; a cohabitating couple is driving home from work and one says to the other “We got an extra $70,000 in our combined bonuses this year, what do you say we put that money into a pool?”

They consider the idea for a minute and says “I think that’s a great idea, but I have a few questions.”

Spouse 1: “Yes.”

Spouse 2: “What kind of fence and gate do you want to buy for around the house and pool (compliance and or security issues)?

Do you think you’ll be cleaning the pool or would we hire a service (operational support)?

How about the trees we love so much, would we cut those down, you know what kind of mess they would make (changes that risk dirtying up the code base)?”

At this point, the first one says, “when you put it that way maybe a pool isn’t such a good idea after all.”

The point is, whether it’s a “free” puppy or a new pool, there are a ton of considerations to make when you consider “owning” the pool versus just “getting” one. If you’re going to take on a large multi-functional (i.e., is more than a developer tool, backup agent or OS) then you really need to consider the ramifications of ownership.

When I Think of Ownership in IT

To me ownership is the full environmental view of how something I’m doing fits into our (my company not just ops/dev or IT) world. In the case of a complex solution like OpenStack or Kubernetes the ownership question takes on some very serious meaning.

Examples of considerations:

• How did the solution enter into Engineering or IT? Was it introduced with purpose or was it downloaded and allowed to creep in like crab grass in the yard?
• Who should drive the decision around a tool with cross functional and business impacting capabilities? Is it a developer decision (because they downloaded it and it’s the latest cool thing) or is it a strategic decision because of the long-term ramifications of work that isn’t done while this new solution is being absorbed?
• Where does the rest of the organization fit in? Do the edges of the new OSS solution touch network security, storage, compliance, governance, audit, reporting, capacity planning, etc., etc.? Would a more complete solution allow for greater integration?
• Who owns keeping track of the growth, change or on-going market acceptance of the OSS solution? Is there a “pull up red leader” moment planned in the lifecycle?
• What type of company are we? Do we need to spend time on the company’s products and services or on building custom infrastructure solutions?
• Do we have the staffing needed to build out and maintain a large complex OSS environment? If we get the right staff do we believe we can keep them.

I’m not saying there isn’t a place for OSS, there obviously is. What I am saying is that hype and/or what’s new and cool or perceived to be free are not the “why” for defining a need. What I am saying is that you need to be very careful about allowing change to happen to you instead of happening because of you. In other words, the developer or engineer that introduced the tool or solution might have all the best intentions, but what’s your real option if when you’ve heard about it all your developers have already decided it’s the bee’s knees.

Time to Value

If you’ve decided (consciously) to begin a new project there is always an assumption of value attributed to that project. The value could be money saved, sustainability improvements or higher revenue, regardless, every minute you waste after identifying the project need is lost opportunity. Time to value for your ability to deliver is more than the cost of the project, its opportunity cost.

If your business is literally run by a giant largely uniform compute environment (LinkedIn, Paypal, Facebook, etc.) then building custom infrastructure or application management solutions to eke out even one percent in operational or performance benefit can make sense. The clear majority of companies don’t have a single application environment and they likely aren’t deploying thousands of physical nodes every week. So, for the rest of us, thinking time to value is often more important than perfect.

Apcera is a sponsor of InApps.

Feature image via Pixabay.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Mirantis.