In-Depth

Taking in Orphanware: Please, Sir, May I Have Some More?

Taking in orphanware can be frustrating, but there are steps you can take for its proper care and feeding.

• By Lafe Low
• 06/01/2007

That low-cost choice proved more expensive than Francis could have ever imagined.

"[The vendor] never finished the product, went to the wire financially and was bought by another financial services provider that promptly pulled the plug to stem the hemorrhaging of cash," Francis says. And just like that, Francis had become the proud owner of orphanware. Fortunately for Francis, now the IT manager for global financial services firm Demica Ltd., his story didn't end there.

The ingenuity and entrepreneurial spirit of many technology companies breeds innovation and unique solutions to complex problems. It does not, however, breed stability. That's especially true for some of the smaller companies. If you've ever purchased a piece of software only to have the vendor go under or be acquired by a larger company shortly thereafter, you can empathize with the inconvenience, expense and exposure of being orphaned.

Most IT administrators maintain a respectful level of vigilance when selecting, deploying and relying on any piece of software or hardware, especially for mission-critical functions. Some even eschew smaller companies or start-ups, opting instead for established companies with lengthy track records.

"The big dogs eat the little dogs," says an IT manager with a medical firm who prefers to remain anonymous, "so we try to use the big dogs whenever possible." But when a specialized utility or application with unique features is needed, administrators don't always have the luxury of relying on proven vendors.

Analysts agree that instances of orphanware are more common when smaller vendors are involved. "Orphanware is less prevalent in core business applications," says Ray Wang, senior analyst for market researcher Forrester Research Inc. Smaller vendors getting gobbled up by larger vendors, Wang finds, is the situation that most commonly leads to products being orphans.

Ironically, Wang also sees a strong likelihood of orphanware resulting from systems integrators developing customized applications for large platform deployments. "Systems integrators continue to add code on top of existing base products," he says. "Many of those integrators are small shops. Some may go under or be acquired."

The open source arena is another place where orphanware has become a common occurrence. "In custom development and the open source side, it's more prevalent. I don't think it's become a disaster or a tragedy, but it's more prevalent," Wang believes. He cites the nature of highly specialized applications and people moving on to other positions with other companies as the primary reasons for open source orphans.

Plan Ahead
So how can you protect yourself? David Reitz, systems administrator for the Coors Brewing Company in Golden, Colo., has become the caretaker of orphan technology several times. His first step is to batten down the hatches and try to minimize the impact by putting together a sensible migration plan. "The short-term plan deals with assessing the impact, freezing the environment and looking at other people to support it, including former employees [of the defunct company]. The longer term plan deals with moving away from the product," he says.

While it's important to have a plan of action in the immediate event of being orphaned, it's equally essential to negotiate up front what will happen in the event of a company's demise or sale to another firm. "Terms in the contract should include software escrow and code ownership if the company fails," Reitz advises. "We have used a software escrow account and obtained the source code. It was a little out of date, but it helped a lot," he says.

Planning ahead ultimately worked out well for Francis. Fortunately, he had organized a user group as his firm was purchasing the yet-to-be-finished software. He realized there's safety in numbers to a certain extent, and that there's some leverage available to help those left short by a vendor's dissolution. His user group had seen that the end was coming and negotiated with the new owners to receive the code that had been placed in escrow during the sale. "The new owners gave us the code under the contractual understanding that we could maintain and develop the system for our own businesses, but not exploit it commercially," he says.

That type of arrangement is fairly typical when placing source code in escrow to provide to customers when a company goes out of business. Customers can typically receive the code to maintain and update the product for their own use, but not use it to realize a profit. Vendors will also update source code in escrow from time to time. This is yet another legal point that IT managers should clarify during their negotiations.

A software escrow account should be established any time there's a change in control within the company or any financial viability issues, says Wang. "Not only the software in escrow, but also the support contracts, training materials, installation guides and platform certification specs," he says. "Make sure the documentation is there. Make sure the knowledge transfer is in place."

If you haven't established these types of guidelines and an escrow account for the source code up front, be certain to act on it at the first indication that a company may be going down. "You have to do this before the bankruptcy process starts, if possible," says Reitz.

Having a backup plan like this can help, but it's no guarantee that you won't be left high and dry. "Sometimes you get lucky and sometimes you eat it," says one anonymous IT manager. "I had one product that was bought out by Macromedia a month after release and never had its bugs fixed. Another case was when a blade vendor almost had 125 grand of my money. I called them to clarify part numbers and the phone was disconnected." Doing a lot of research prior to signing a check and having more than one option is the best course of action, he says.

Plan B
No matter how much preparation and planning you do, you may still find yourself pursuing your Plan B. Randall Stevens goes into any negotiation with a backup plan already in mind. As a software engineer and independent consultant, he tries to line up a vendor with a similar replacement product, but even that doesn't always work out. "If none is available, we'll reverse-engineer the functionality," he says.

Another IT manager, who preferred to remain anonymous, rebuilds his systems every five years. Consequently, he always has his eye on an alternative approach. "We've found a different vendor, found a way to do without the product, or built our own," he says. "You always have a Plan B at the ready."

Lining up an alternative solution is often an effective strategy. "Once a buyout happens," says John Pitton, systems administrator for Discorp, "we go into reactive mode and search for a similar or better solution." Pitton has experienced both situations where products were dropped right away and where they were maintained for a while following a sale. Most of the time, the buyout company will renegotiate with customers to continue support and upgrades.

Occasionally, the new company will sideline a product or phase it out. Even when a product is phased out, though, there's usually enough time to select and install a replacement. Pitton has found this is most often the case with smaller companies purveying the latest technology. Researching available options among competitors to that technology is vital.

"Research first what viable options are available from other similar software manufacturers," Pitton says. "Bleeding-edge software isn't for everyone. However, if you're going to take the leap of faith in software that no one else is manufacturing, be prepared to self-support," he adds.

Start Me Up
The experience of buying from a start-up company is similar to that of buying from a smaller or specialized vendor. Many of the risks are the same, as are many of the precautions you should take. In either case, once again, research and contingency plans are essential.

First, make sure a start-up is on sound financial footing. This can sometimes be problematic, but most should be willing to give you a good indication of their financials. Even if you're dealing with a smaller, privately funded company that's reluctant to divulge details, market research reports can give you a good feel for how the company fits into the context of its market.

While he focuses on major players for his company's critical business applications, Deon Pretorious, the lead developer for Geckotek in South Africa, has shopped around at start-ups for some unique solutions. "I'm not averse to purchasing non-critical software from start-up companies," he says. "I usually take the precaution of testing the software on a trial basis in order to satisfy myself that it can perform the necessary functions and is bug-free."

The specific focus of some start-up software developers puts the company, and therefore its customers, in a unique situation. The prospective competitive advantages can overshadow the potential risks. "In certain cases, niche software is provided by start-up vendors that's not available elsewhere. This makes it a viable proposition," says Pretorious.

Francis says he no longer relies on start-ups for line-of-business applications, but still considers them for utilities and second-tier functions. "The risk to the business is too great. An exception would be if I knew a start-up's people well and was convinced they understood my business and its requirements," he says, or if he was considering software that provided "non-essential functionality that couldn't compromise the business core operations by its absence."

Learning From Experience
While experience may be a harsh teacher, most IT professionals left high and dry by orphanware have adjusted their tactics to better manage the situation should it happen again.

Sometimes, when you negotiate ownership of source code in escrow, you may get more than you bargained for. "We've been in the position where we were offered the entire company's assets," says Coors' Reitz. "Our maintenance contract exceeded the value of the company's stock, so we turned them down, but referred them to other software companies," he says.

To maintain the value of his software investment, Reitz has also found those who did the initial work are often available to keep it going. He sometimes runs ads in local papers where a company was based and contracts with the former employees to do work and support.

Francis' user group members had a similar experience. They employed a developer who had originally worked on the product to finish it off and provide maintenance. Several of the members continued using the product for years, although Francis says he replaced it with an established product after a couple of years. Still, he and his user group members were able to preserve much of the value of their initial investments.

Dealing directly with the original developers is the best response to orphanware, says Wang. "Reach out to existing employees and bring them on board," he says. "The key ones to know are heads of development and release-patch engineers."

The rewards of dealing with smaller, intensely specialized vendors or start-up software companies can outweigh the risks, but you have to go in with eyes wide open and a ready backup plan. You can stick with the big dogs, or you can isolate products you buy from potentially questionable vendors, but you had better be ready for anything. Companies will come and go, and you don't want to get caught in the vacuum they leave behind.