Are You Being Held Hostage?

In keeping up with the times, I want to talk today about terrorists.  The scum of the earth.

Maybe you don’t think these particular guys are the caliber of Al-Qeada or other groups, but these folks can definitely strike terror into the hearts of company management who have this particular act of terrorism inflicted upon them.

I am talking specifically about software terrorism.  People who literally hold a company’s software hostage demanding some form of compensation, recognition or fulfillment of some other demand.  It usually involves major sums of money. Think extortion.  Think suicide bomber (because the second they execute their plan, it’s guaranteed to blow up in their face.  The loss of a client is certain.)   I think these people are scum because instead of structuring a relationship based upon the value/service they provide, they base it upon the necessity of doing business only with them because they are the only people who have the source code.  This means, company owners and management are going to get screwed… Royally.  It’s a monopoly of one.

Since the beginning of the year, I have been engaged by at least a half a dozen companies who are scared out of their wits.  Why?  Because they don’t have the software source code to their custom systems available to them.  They have lost control (or didn’t have it in the first place) of one of their most important business assets. This occurs especially in situations where custom software was developed at great expense and time.

Which brings me to an interesting point:  Until it is pointed out to them, sometimes they are usually unaware of their predicament.  They don’t even know the importance and value of making darn sure the software source code is safe and protected.

There are usually a variety of factors at play besides money, including the reluctance to call in the lawyers for fear of further ticking off the developer(s) or having the developers potentially sabotage the source code, modifying it in such a way as to render the source code useless once it is within their possession.

Sometimes when they call me, I can hear the desperation in their voices.  It’s one of the most difficult situations to consult about, because of the sensitivity of the matter and the importance to the company’s future.  In addition, inappropriate handling can be a CLM (Career Limiting Move).

In this age of off-the-shelf software and software via ASPs, management is sometimes unaware of the custom software dynamics.  When structuring software development projects with external resources such as consultants, keep these strategies in mind:

·        You want the source code, especially if its custom code, in your possession, on site and available for inspection.  Period. No excuses. Preferably online on your system, not a backup tape or CD or in escrow.

·        You want to purchase the appropriate licenses for all the specific software tools which were used during its development.  Remember that the source code is dependent upon specific version levels of these tools.  You want to replicate the development environment precisely and have it kept up-to-date by the developer during the development and support process.

·        Occasionally, you want to confirm that you have what you think you have.  Try to force a rebuild of the executable programs.  You may have to pay for it, but consider it an insurance cost.

·        Have a backup developer or other resource who is familiar with the code base and design of the system.  The old “What if you get hit by a truck?” strategy.

·        You want to be clear about the legal ownership of the software.  Do you only have a license to it?  Do you really own it?  Like are you able to legally resell it without further involvement of the developer?  Check your agreement, check with your lawyer (one who is conversant with software issues).  In a word: Homework.

·        In essence, complete control is the best case scenario.  In the event that there is a disaster, or you fall out of love with the developer, you have your asset and the infrastucture working and in your possession.  Minor interruption.  What’s more you escape having to work with a hostile consultant.

·        Note: Occasionally, I’ve seen a company’s IT department or person hold the company’s information and processes hostage.  I know this sounds weird, but there are people within IT departments who have enormous job security and covet/protect what they know from anyone within their organization knowing what they do or how they do it.  This scenario is just as intimidating to management as the source code issue, because these folks usually have substantial business acumen along with their technical expertise.  You must watch out that these people are not on the critical path to your success.  They must have a back up for the same reasons as the above.

Now what should you do, if your software source code is already held hostage?  That’s a hard one to answer.  There is no generic reply that I can think of.  It depends primarily upon: 1) Your relationship (legal and personal) with your developer(s), 2) The agreement you have in writing, 3) The company, 4) The amount of money at stake, and 5) The strategic value of the software.

I hope I’ve been of some help.  If you have additional questions regarding this sensitive subject, feel free to email me at rick.duris@btgi.com.  See you next month...

For additional information please call 847/251-3327