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.
Several years ago, Jacques Francis was charged with finding a highly specialized
business process automation tool. His firm, a small London-based insurance broker,
made as its final choice a work in progress that was being offered to the company
and other small brokers at a price well below that of what more established
players could offer.
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
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
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.
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,"
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,
You can take
several steps up front that will give you a modicum of protection
in the event that your software vendor is acquired or goes
- Formulate a step-by-step backup plan.
- Negotiate ownership of source code in escrow.
- Check financial stability of the company.
- Test software if possible.
- Consider alternative solutions.
When It Happens
You need to act immediately if a software package you're using
suddenly becomes orphanware. Here's what to do:
- Act on your step-by-step backup plan.
- Lockdown and assess the situation to limit exposure.
- Consider employing or contracting with former employees
of defunct vendors who worked on your product.
- Aggressively look for alternatives.
- Begin a phase-out plan.
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.
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
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
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.