The terror of open source. M.A.Newhall

What is it that compels professional IT managers of other people to flee Linux and the like? The big software companies of the world seem to lull them into a trance. The accepted answer is as an astute colleague of mine once suggested, that Microsoft, for instance, offers managers of all stripes the opportunity to play golf. I do think this was the promise, but one that now falls short.

When open source started, knowledge of both it's products and it's process were scarce. This has changed. While the same managers wallow in the mire of sales calls, budget meetings, and half baked performance reviews the landscape has completely changed around them. Their customers, at least enough of them, now know that anything is possible. Some of them in turn now know, from experience that discovery, innovation, and occasionally gross profits now occur from lessons learned at the periphery, not the mean.

No I'm not going to bore you with another diatribe about the stratospheric disruptive technology that will obsolete entire fields with a single release. Not going to say that this isn't important, but instead that this is not important to the golf wishers. They were never players in this field. If they had skill in the old ways then the old ways were still needed in the new job. While uncomfortable and a little scary , if was very possible to jump from the sinking ship to the newly sailing one. This is manageable problem for our hero golfers. Managing programmers, engineers or admins, may change technologies, but until now it has always been the same problems of workflows and budgets.

Another problem is the service model of software companies. Software has almost completely become a service and this just exacerbates and amplifies the problem. Service is an awkward but presentable change in budget from a one time cost structure with a possible ongoing maintenance cost, to a flat out series subscription. It's awkward knowing exactly what services you are getting. But a savy negotiator can too surmount this hurtle. This can become a major conquest for a golf wisher, and while a risk is a manageable one with real skill.

New tech cuts down whole fields, and the software service agreements are slippery snakes, but this can't kill a manager dead. Not if he (or she) has some skill and tries to say on top.

The terror of unsatisfied customer.

Unsatisfied customers are terrifying. A happy customer, if you are lucky will make a good note of their happiness someplace. An angry one will tear into the flesh of your reputation at least until they smell blood!

Until very lately the day to day life of management is very much about the damage control model of customer service. It goes something like this. The customer makes a request. The technicians compare this to their previous work to determine feasibility and either rubber stamp it or present a list of problems either to the manager, the sales team or to the customer themselves.

If the customer is considered a 'good one' by all if they want some service that is just like some service someone else has wanted. Nobody has to think. Nobody has to change. Techs follow docs or run scripts, managers play golf and all is well.

If the customer wants something new that's when if gets weird. Managers, techs, and sales people meet. Of course everybody feels they contributed to the managers decision in some small way post meeting. Techs describe time and materials, sales people asses total costs, and managers oversee the purveyance to the customer, and it's execution once launched. At least this is the dialogue they use to interact with each other.

It's a lie.

What's really happening is the customer makes a new request. Sales tells the manager to handle it. The manager tells the techs to come up with a cost model, and the techs ask the software vendor if they support it. The software vendor sends an absurd price to the tech, then the manager, then the sales team and finally the customer gets the bad news. Sure we can do that, but here is absurd cost. The customer changes his plan.

A variant on the above is much easier to understand and far more common. The vendor just says no.

The lie if you missed it is that the tech is actually saying no the customer. If you think about it this is a fairly absurd notion. Everyone knows the nerd behind the keyboard is NOT the strongest personality in the room. To the contrary, he is often the weakest. The most humble. The least audacious.

Now of course the tech was always the best qualified at the company to say no, as he understands the technology best. But something has gone strange with open source techs. Something that has completely been missed by their attendant managers. In open source the tech IS the software company. A sufficiently skilled tech can always say yes. There is no request he can not honor. The source is there so it CAN be done. Every single time. So now it is on the tech to say no, or in place of the sales team of the vendor attach the very high cost.

Of course for the tech to be able to properly attach an accurate high cost, he has to learn not only the sales team's job, but the managers job as well. Sometimes the result is a frustrated tech ready to quit and a befuddled manager clueless to the previous lies. Neither has the skill to assess why the other is failing. The tech, and the manager are in danger.

Sometimes the tech may have the menagerie of skills to learn the sales team and the managers jobs. They become the manager. This is a better outcome for the company, but not for the boss. He is out of a job. If it's his company he could be out of a company. Probably for good.

Attacking the victim.

The customer is changing here too. Most customers know both that things are changing faster than ever and that change can leave them behind. In the case of some Internet security flaws, it can kill their projects dead by destroying their data.

They don't know that they can't accept proprietary closed source software's restrictions on their business model, but they see that when people and companies limit themselves, they fall behind. It doesn't really matter that they don't know why some companies say yes and others say no. The culture has changed. They just know that the company that says no too often, it will lead them to obsolescence.

On the defensive.

The wishful golfer seems to have only one path. Attack open source. Talk about who 'supports' it and indicate that the service model is slipperiest of them all. This is the death rattle. They recognize that an important change has happened, but not what it is. The blindness originates from a culture that has viewed IT management as roughly the same for at least 30 years. When you want to say no, you let the software vendor do it for you.

The most distinct feature of closed source software, the tendency to make difficult or impossible unusual use cases, is so managers have a way to say 'no.' It is said that when someone responsible has to make a decision they don't want to answer for, they form a committee. So too have managers hidden behind the common used cases, supported models, and lifecycle paths of proprietary software vendors. The vendor is the unassailable bad guy, and they can play golf.

Sinking ship.

The landscape has permanently changed. Twenty years of production ready open source has permeated the culture of customers. They do not know why, but they know they must customize. Not just a little, but a little more than their competitors. It is terrorizing managers who can't grasp why their open source technicians hate them, and their customers are ready to flee at the first opportunity.

It's time to let the closed source model drift away. The number one and possibly only skill you need to do that is learning how to say no to your customer. This is the price of working with open source. The very fact that you never need to say no, is why you need to learn restraint. Often for the first time.

Some tactics for polite refusal.

Since the shift toward customization is cultural not technological, you will be getting increasingly insane requests for technologically impossible feats. Let me clarify, not impossible, never impossible, but way too rich for you or your customers blood.

Scour the distributions. - A variation on the closed source model of refusal. The more distributions you learn about the more likely you are to make the case that only some or even none of the distributions will support or be compatible with the customers request. Their differences are your trade now. If they all say no, now so can you. TIP: Try chatting up the differences between two distributions with your technicians. They will be happy to oblige you and this will accelerate your learning.

Educate for free. - Offer a general education for free or cheap to your customers. Depending on exactly what your product is you may even be able to require that your customers take your course. They may decide their problem is 'easy' and solve it for you. Even better, they just may realize just how complicated their request really is and relax their requirements.

Hire and grow. – So you've been patting yourself on the back. Saving millions a year of expensive software service agreements? Guess what, you're not the only one. Now you once again need to spend that kind of money, but now on the technicians to make the magic happen in house for your customers. Even if you don't hire every last dollar away, having a good growth plan on the table gives you a new way to say no. Send your customers a profitable quote. If they are crazy enough to say yes, everybody wins.

Refer them elsewhere. - Again the change is now cultural among users including customers. Waves of paranoia inducing Internet based attacks and oscillating Internet technologies have drilled home the importance of customization in the survivors. You may not be able to accommodate them, and they just may not yield. The best thing for everyone involved is to actually give a customer up. Think about it. The software vendors did it for you, all the time, but that jig is up. You can't pass the buck and be adaptive. It's now on you.

A better plan than early retirement.

With the recent cultural shift you are certainly facing obsolescence and if your customers are not captives, 'restructuring' It's stupid and avoidable. Really, you need one skill to survive a switch to open source. An adaptive ability to say 'no.' You can no longer rely on a billion dollar company with an epic legal team to do it for you. The sooner you recognise this, the more likely you are to survive.