Adjusting to a more open world: Understanding and overcoming resistance to open technologies

Print Friendly

Podcast of this blog entry

I spend a fair amount of time trying to discern, understand, and analyze the strategies of opponents of open standards and open source. I won’t claim that I do this in any completely comprehensive manner for the industry, but I find it to be a useful exercise. There are a few key targets of my inquiries and you can probably guess who some of them are.

One of the first determinations I try to make is whether, in fact, there is any strategy or whether the actions are merely tactical or even something less. The old “we always were in complete control, let’s stay that way” also comes into play. Some companies are getting more systematic about making “open” a part of their business considerations but we as an industry still have a long way to go.

In fairness, it’s clear that some of these folks have well thought out plans, though it may take a while for them to get firmly in execution mode. Conversely, I could also point out sub-optimal strategies or planning by proponents of open source and open standards.

IBM itself has learned many lessons through the years about what openness can do to and for our business. We’re still getting educated and others are quick to point out what they perceive to be our errors and shortcomings.

I want to talk about how people who start out thinking that openness is a bad idea might come to deal with open standards and open source in a more positive way. I’m not going to be terribly original here because when I started thinking about this, what came to mind is what some people call the “Five Stages of Grief.”

Before I dive into that, I want to make clear that personal traumatic events are far more important than the happenings in the IT industry, so I in no way want to equate how someone deals with a personal loss with a change of corporate strategy. I’m just going to use this as a handy framework for looking at change and resistance to it.

The five stages are

  1. Denial
  2. Anger
  3. Bargaining
  4. Depression
  5. Acceptance

Beyond these and starting at #5 are the following four phases

  1. Accept the reality of the loss
  2. Experience the pain of the loss
  3. Adjust to the new environment without the lost object
  4. Reinvest in the new reality

My reference for these stages and phases is Beware the 5 Stages of “Grief” by the TLC Group, Dallas, Texas.

What exactly is the loss that we’re talking about? Here are some possibilities in the software area:

  • Loss of control over a protocol, programming interface, or data/message/document format to a standards organization
  • Loss of primary or personal control over a programming language definition to a consortium or a national standards group
  • Loss of control over an architecture
  • Loss of customer mindshare to more open alternatives
  • Loss of marketshare of proprietary software, including operating systems, middleware, and applications

Before you jump to any conclusions such as “oh, he’s talking about company Y there,” let me note that I can probably give you at least three or four examples for each. With a little help, the numbers would get much bigger than that.

These stages and phases need not be carried out in public. Sometimes they are buried in internal task forces, investment review meetings, or even corporate board meetings. There are certainly leaders who will enthusiastically carry out the necessary work to transform to a more open company. I’m not talking about them!

Consider a hypothetical situation where a new CEO comes in and tells an owning VP that a software product will be open sourced. This person may agree completely and get on with it, but let’s look at what might happen if they don’t. For simplicity of pronouns, I’ll assume the CEO is female and the VP is male.

In the Denial stage, the VP may think the CEO isn’t serious and so therefore tries to ignore the directive. He might not think that the company will not ever open source the code, that it’s just a passing notion or fad. The VP might discount customer input that says that it is time to shift business models (“what does the customer know?”). He might not accept that the market conditions are right to open source the code. This is tricky, because the VP might be right.

Perhaps there is no external community to participate in the effort. Maybe the company has a strong income stream from the product and few competitors, but no alternative revenue source if product licensing goes away. The CEO might be making an ideological decision rather than a market-based one.

Assuming that the CEO in our example is well informed, practical and a good strategist, this may boil down to a difference in business opinion. However, I’m going to assume we’re looking at a situation where opening up is very likely the right thing to do but the decision is being fought by the VP who can’t or won’t deal with it.

In the Anger phase, our VP lashes out at peers and loved ones about what a stupid decision was made and how could he possibly be working for such an insane person. He might say “This is a software company. We write software and people pay us for it. How are we going to make money? I didn’t get to this point in my career and build all my customer relationships to have to deal with giving stuff away for free.” The VP might leave at this point.

The anger might also come about because of some perceived loss of status or potential income. “Does this mean I no longer have P&L responsibility?” or “If we shift to a services model what happens to my bonus based on sales?”.

These are not points to be trivialized and must be part of the larger planning exercise. So our CEO has to do more that just say “Open source product X.” She has to say

  • “Get back to me in 30 days with the plan for how we will open source X including all necessary reorganizations, resource adjustments, and changes to compensation models.
  • “Include a fact-based revenue projection together with a competitive analysis.”
  • “Make sure there’s a fully fleshed out discussion of potential open source licenses we might use, with input from legal.
  • “List the top candidates who might participate in the community, in priority order, with likelihood of participation.”
  • “This will require a different kind of communication and marketing program than we’ve done before. Get with the agency and the VP of Marketing to sketch out how we might do those and how it should and should not affect our corporate image.”
  • “I want to see all the milestones and major tasks to make this a success and I want to see who, by name, is going to make them happen.”

The CEO then has to make sure that Denial is not unduly influencing the plan that is presented. In the Bargaining stage, the VP may go back to the CEO and say something like

  • “You know, the time really isn’t right to do this. How about we give it 12 months more thought?”
  • “Your predecessor considered this but decided not to do it. Let me tell you why.”
  • “I think Larry’s product is much more amenable to being open sourced. How about we do that one first and then see if it still makes sense to do mine?”

Once again, we could have an honest debate going on about the business merits of the decision. That should all be included in the plan and backed up by defendable numbers and observations. The plan should always include an “Option 0: What happens if we don’t change the current business model?”. If the bargaining is really just stalling because the VP doesn’t want to carry out the plan, then we’re into our “dealing with loss” scenario.

Depression may set in when the VP realizes the open sourcing is going to happen even though he doesn’t agree with it. This is change and, though it is a cliche, change is hard. As in the Anger stage, the VP might leave the company because he fundamentally feels that the direction is at odds with his personal view of the business and his role in it.

I hasten to add that situations other than open sourcing software can lead to this result as well! The CEO could realize at this point that the VP is not going to be the right person to have the responsibility to execute this important business transition. There might be some other role in the company that is more suitable or perhaps something more extreme is in order.

With Acceptance we turn the corner, and the VP buys into the program. He should make a personal commitment to the CEO to do everything necessary to exceed the expectations for success. For example, instead of bringing in five other companies, organizations, or individuals, he should commit to ten or fifteen. Note, though, that in his exuberance he should only do what makes business sense and is consistent with the developed plan.

Getting back to that plan, dealing with the three final phases after acceptance should be part of the strategy that the VP created. Experiencing the pain of the loss means that the revenue structure has changed, sales people are adjusting (or not), support calls or service engagements might be increasing with the need to bring in more people, and financial results need to be explained to analysts.

While I used the word “pain” here, and there is certainly no guarantee of success, as a thought exercise you should think through what these mean in a positive sense. Presumably everything was done to transition part or all of the company to something different yet better able to meet customer needs. This will be hard work, and with hard work comes at least a few aches and pains. I assume that if the decision wasn’t made to open up, then the CEO, the VP, and the company would be feeling other forms of pain.

When they adjust to the new environment, they are treating their open source business model as the new norm. There will be things they did not anticipate and some course corrections that need to be made. Most business people deal with such things on a daily basis, though this might be tougher since it is something new to them.

Moving to open source will almost certainly change the company’s partner relationships (“Resell what?”). They will also have new partners in the community developing the now open and shared software. The company must use these new relationships to help them with their adjustment. They must use their network to talk to others who have been through what they are going through.

Our hypothetical company will also have a different relationship with their customers. The CEO, VP and other staff must work very closely with existing customers so that their expectations are met if not exceeded. The business around this software will fail if the customers are treated the same way they were when they licensed the software. More than anyone else, the customers need to adjust to the new model if the company is going to be successful.

If the company has venture capital, the investors bought into this new strategy very early in the process. They very probably brought in the CEO to make the necessary business changes. The VCs should be used now to help work through the additional required adjustments.

Reinvesting in the new reality might mean doing all the above again with other parts of the company’s portfolio. It could also mean joining other open source efforts or using the code in those efforts to enlarge the breadth of the business.

In this extended example, I focused on open sourcing software but it’s instructive to work through the other cases. What would it mean for your company to give up proprietary control over a data format and turn it into an open standard? For the sake of argument, here I mean a real community developed and maintained standard and not a pseudo-open effort where you are still controlling things.

What does denial sound like inside your company when such a proposal is made? What does denial sound like when there are public discussions about whether you should open up a protocol? Can you point to public displays of anger that preceded the eventual opening of a specification or a technology? Do you know of an executive job change that now, in retrospect, fits into the pattern above?

Though I expressed the example above in terms of one reluctant individual, some of these stages might be illustrated publicly in a consistent way by the senior leadership of a company. That is, it might appear that the company itself is angry or in denial about what seems to others to be a fairly obvious thing to do. You may even see this in the blogs of less senior employees who are adhering to some internally developed story or rationale.

In defense of the company, the outsiders with these strong opinions are not privy to all internal business and technical considerations. What might appear to be anger may just be frustration with others who are not informed enough to understand the path the company is taking. Perhaps an acquisition is pending or significant effort is being made to open source something else.

Then again, the company might just be wrong. What might appear as an official position may just be the opinion of someone who does not have the informed consent of senior leadership. In the IT business, these things usually become clearer over time, particularly years later when former employees describe what the real story was.

Not all transitions proceed along the path I described but some certainly do. This discussion may help you recognize some signs of what is really occurring. This is certainly important within your own organization but it may prove even more useful when you pick up clues about what’s happening elsewhere in the industry, particularly with your competitors.

Listen to the tone of how they speak at conferences and how they phrase things to the press, especially when they wander off their list of talking points. Are they defensive or are they asserting things which are simply counter to what is commonly known?

I think that the better you can manage your transformation to a company based on more open principles, the greater is your chance of becoming a stronger and potentially more innovative organization. The better you understand how your competitors are or are not managing their transformations, the greater is your chance of giving yourself an opportunity to predict, adjust and grow.


One Comment

  1. Fascinating stuff, thanks for a great blog. I can’t stop wonderinh what prompted this blog Bob. It sounds like an authentic voice so I am guessing you’re talking about a conversation inside IBM.

    Is IBM thinking of OpenSourcing Notes or something? Maybe Tivoli or DB2.

    I’d love it if IBM offered the proprietary Notes nsf format as an open specification like ODF. I have so much data locked in that format.

    Keep up the good fight inside IBM Bob

Comments are closed