Do you use any software that is important to your operations?  I’m sure you do.  What if that software were suddenly discontinued or the software provider ceased to exist?  How would it affect your business, what options do you have, what could you have done to prepare for such an occurrence? 

The LabMan was acutely reminded of this recently when Microsoft announced that their personal financial management product, MS Money, would no longer be sold after June 30th, and support for all the on-line electronic banking and brokerage services would end one year later.  The LabMan has 12 years of financial information embedded in MS Money, so this came as quite a shock.  After all, Microsoft is not a fly-by-night company!  So, I will have to cope and make a transition, just as you would if you experienced this same scenario with some essential piece of scientific or laboratory software. 

Lest you think this is a rare occurrence, read the lamet from this user of the recently defunct BioTrue Collaborative Data Management Software (which was focused on confocal microscopy, flow cytometry, and office documents). 

So, how can you protect yourself from such eventualities?  Let’s tick through a few common approaches:

·        Firstly, if the software is really important to your operation, do a full financial analysis on the software-providing company before you buy.  This can place a major burden on a small vendor who has little time to spare, so don’t expect to ask for a discount after running them through the ringer.  The bottom line is that if your potential purchase is key to their company survival, then as Monty Python says, “run away”.  However, Microsoft certainly would have passed this muster, so it only speaks to the potential survival of the company, not any particular product.

·        If a technology provider offers multiple products, try to determine how close to their “core” business the product you are interested in lies.  Products further from the “core” have more chance of being dropped during lean times.  In the case of MS Money, it’s not Windows nor Office, so one could have considered it at risk, even though it’s been around about 15 years. 

·        Choose software that adheres to industry standard data formats or has an open architecture.  This will increase the potential for porting that data to other, competitive software and also increases the chance that 3rd party developers are knowledgeable about the inner workings of the software.  In the case of MS Money, the standard data export format, qif, is pretty widely used.  One can also export to Excel.  But in either case, not all of the more complex records seem to export perfectly. 

·        Look for software providers that have a strong history of making their new releases backwards compatible.  This will make it less likely that a new version of a product will leave your existing product totally obsolete w/o any future upgrade path or support.  Of course, Microsoft passed that grade well. 

·        Stay in touch with competitive products – for several reasons.  Firstly, you might have to make an emergency migration.  Keep yourself educated about the technical possibility of such a migration, and keep in touch with the technical features of that product.  Secondly, if you see a competitive product really running away with market share, that might be a danger signal for the product you’re using.   In the case of MS Money, the obvious competitor is Quicken (which I used years ago).  They’ve always held roughly similar market shares, but apparently that share became increasingly unattractive to Microsoft, while it still appears to be appealing to the maker of Quicken, Intuit.  Migration of data between the two has always been somewhat possible, but not nearly 100% clean.  However, immediately after the MS Money announcement Inuit issued a press release promising a seamless transition add-on to their next revision due this fall.

·        Finally, there is the often quoted practice of asking your software provider to put their source code in escrow, accessible to you via legal agreement only if the company goes defunct.  I’ve recommended this to people, but in reality I’m not sure how much of a true safety net it provides.  Does your company really have the resources to dig into unknown source code and tinker with a complex product?  For small products, perhaps, but certainly not for something on the scale of a LIMS or Collaborative Data System.  This option might be more viable if there were lots of 3rd party developers already in the marketplace who had done custom software development on this product all along.  They, together with the source code, could possibly help you to bridge to something new.  It’s unlikely that you'll continue to use the defunct product indefinitely, however. 

In the end, there is no way to be 100% totally safe, unless of course you write all your own software.  But even then you’re not safe. If you had written lots of critical software using Microsoft Visual Basic over the years, you’d have been up the creek when MS dropped that product. 

Make the best educated choice you can.  Realize that while the mainstream tends to be safer, they're also not 100% safe.  Give thought to your “plan B” options.  Keep in regular contact with those in places to hear about pending developments.  Live the Boy Scout motto: Be Prepared! 

Until Next Time,

Domo Arigato, Mr. Roboto!