“Open Source is free software, why should I pay for support?”, “There’s no real difference between the community and enterprise open source versions.”, and “My developers are very technical and know what they’re doing, we’re fine operating on the community version.”
These are very common responses I hear in conversations with customers and prospects. We’re contacted at least 3 times a week from companies who have run into a dead-end trying to locate and correct software defects that are causing disruptions in their business.
Most of these organizations have designed and implemented their business software solutions using one or more community open source products. By the time that we get called, a company is experiencing some major failure that is preventing them from normal business operations. The problem has finally caused enough discontent and pain that they look to others to assist with fixing their problem.
How did they get to this point? It’s very simple, ask your customer “What business are you in?”.
When I ask this question, they tell me the real business they operate such as banking, insurance, logistics, and retail. Very rarely does someone answer innovative technology or software product development. So why then are so many businesses entrusting their operational stability and business agility to open source projects that are supported by a community of developers when there are open source projects that have organizations who provide enterprise product versions with service level agreements (SLAs)? Who led them down this path?
Grandma’s Chicken Noodle Soup – It’s in there.
When we show up at a customer, almost always, no one can fully tell us what their server deployment architecture is, how it is built and deployed, and what versions of software products they are running. It’s almost like they want us to come in and taste their soup, determine what ingredients are being used, and then alter the recipe so that it tastes wonderful.
Everyone in Information Technology (IT) believes himself or herself to be smart and capable. Business executives tend to trust their IT departments, but rarely get involved with the software decisions because it’s a “technical”, not a “business” decision. I disagree.
The solutions architecture and its software components are very much a business decision and should be evaluated for their ability to provide sustained operations and Continuity of Operations Plan (COOP). Selecting open source community software when there are supported, Enterprise Open Source versions available is introducing operational risk and uncertainty. This is due to relying on a community of peers for defect correction while there are organizations that provide commercial support. What’s the opportunity cost of community open source operating in the enterprise?
It is a cost that may vary from organization to organization, but can yield the same outcome; business disruption. While the actual cost varies, lost profits and customer dissatisfaction are pains that can be experienced by anyone.
Business and IT Agility – Purpose-Based Alignment Model (Nickolaisen)
I will summarize Nickolaisen’s Purpose-Based Alignment model, which focuses on aligning an organization’s resources on processes, products, and projects that meet the demands of their business while reducing resource expenditures that do not provide differentiation.
I suggest that you download and read this paper (see “Mission-Critical Market-Differentiation strategic model" at http://aamngt.com/resources.htm). It is a short read, but provides an approach that you can share with your customers to educate them on the importance of simplifying and streamlining their operational processes while not over/under engineering their IT systems. He separates items into two major categories; mission critical and market differentiating.
Mission critical reflects the activities and processes that are essential for normal operations. Market differentiating is akin to gaining market share and market penetration. I will focus on the mission critical aspect of the model because that’s when my firm is usually called in, when it’s mission critical. Somehow organizations never think that having a support agreement vs. getting support from the community is mission critical until operations stop.
One of the activities that Nickolaisen describes is the need for Parity, which he defines as the goal “to achieve and maintain parity with the market”. Over designing, over complicating, and developing custom behavior for common processes and operational procedures decreases business agility and breaks parity. Instead, organizations should establish standards that are neutral of proprietary technologies and practices, and interface to other systems in a secure, standard, and compliant manner.
360 degrees of pain.
While my firm could come in and decipher what the problems are, provide corrections, and get operations running again in a community open source platform, it is a vicious circle. Customers that run into this problem want us to work within their existing framework and to not take a pragmatic and systematic approach at solving the problem. They believe that it’s cheaper for them to “just fix” what’s broken and not “solve the problem”. We tend to shy away from these engagements because no one is happy in the end. Even if we “fix the issue” for them, we have only solved one problem. We are leaving the customer in the same situation we found them, which is “waiting for the next failure to occur”.
Our recommendation to customers is that they first secure a software support agreement. This provides us a foundation upon which we can be successful. It also establishes a baseline to measure behavior and performance that can be repeated. It is the “recipe” for success for both us and the customer. Paying my firm to “get it to work” is throwing money away.
When we have support agreements, the business achieves parity, when the defects are corrected. Support agreements eliminate variation for everyday and common IT tasks that simplifies issue resolution. It focuses organizations on creating simple and effective solution architectures that power business, by removing complexity introduced by non-differentiating tasks.
Have a business vs. a technical conversation.
I challenge you to have the difficult conversation with your customers about the business impact associated with community open source products. Sell them on the value of sustained operations and business agility. The ability to work from a solid foundation from which to solve the problem vs. wondering if the fix will hold.
We’ve found that the amount of money that a support agreement costs can be negligible compared to the loss of consumer confidence and profits. The true value of a support agreement only becomes apparent during a time of crisis. I tell my customers that they are wasting the money on my services without fully correcting the problem and that they will be dissatisfied over time. It is only a matter of time before we are talking again about the same problem.
I recommend that organizations should take time to evaluate the impact of downtime and lost profits compared to keeping things simple and in parity. Some of my personal recommendations for businesses running community open source projects are to:
- Establish a software and server architecture that provides a foundation to support, sustain, and enhance business operations,
- Develop applications using industry standards and best practices,
- Avoid custom-built software architectures and product development unless critical for competitive differentiation, and
- Leverage open source software products that have third-party support agreements replete with Service Level Agreements (SLA).
Please share your comments - if you would like to schedule some time to talk please contact us.
