What is orphanware?

A working definition

Orphanware is software that a business still relies on after every normal support path has closed. The source code, meaning the human readable text that developers compile into a program, is lost. The vendor or developer who could maintain the program is gone, retired, unreachable, or no longer offering the product. What remains is the compiled program itself, the data it holds, and the people who use it every day without any way to change how it behaves.

The word is also used in the software escrow industry, where it can describe source code that a vendor deposited with an escrow agent and then abandoned, or a deposit that was released because the vendor failed. That usage is about custody of code on paper. Our usage is simpler and more practical: a program is orphaned when, in practice, nobody can maintain it anymore, whatever the paperwork says. A system can be fully licensed, fully paid for, and completely orphaned at the same time.

How software becomes orphaned

Software rarely becomes orphaned in a single event. It happens gradually, while the program keeps working and nobody sees a reason to intervene. The common paths are these:

• The vendor goes out of business, is acquired, or discontinues the product line, and support ends with it.
• The original developer retires, changes careers, or dies, and the knowledge of the system leaves with that one person.
• The source code is lost: stored on a drive that failed, on media nobody can read anymore, or on the workstation of an employee who left years ago.
• The program was custom built under a contract that never delivered the source, so the business owns the use of the software but never held the code.
• The platform underneath it ages out, and the program becomes tied to an operating system or machine that is itself unsupported.

In most cases several of these happen together. By the time the problem is visible, the program has usually been orphaned for years. It just had not broken yet.

Orphanware is not abandonware

Abandonware is a term from the hobbyist and gaming world. It describes old software that a publisher no longer sells or supports, which people download for nostalgia, preservation, or curiosity. Nobody is depending on it to run payroll. If a piece of abandonware stops working on a modern machine, the loss is a disappointment.

Orphanware, as the term is used here, is a production system. It posts invoices, runs a machine, keeps records that a business is legally required to keep, or holds the only copy of years of operational data. The stakes are different, so the remedy is different. Abandonware is preserved so it can be run again for interest. Orphanware needs to be understood, documented, and made maintainable, because a business is exposed every day that it is not. Confusing the two leads owners to underestimate the problem: this is not an old program that would be nice to keep, it is an unsupported dependency at the center of an operation.

The risks of running it

An orphaned program cannot be patched, so a security problem or a defect stays in place permanently. It cannot be changed, so a new tax rule, a new report format, or a new customer requirement has to be worked around by hand. It cannot easily be moved, because it is usually bound to aging hardware and an aging operating system, and the one working installation becomes a single point of failure.

The deepest risk is where the knowledge sits. With the source gone and the developer gone, the only complete record of what the program does, which rules it applies, and how its files are structured is the binary itself. Every year, the people who remember why the business uses it the way it does also move on. The program does not get worse with time. The ability to recover from its failure does.

What can be done about it

There are four realistic options, and they are not mutually exclusive:

• Run and maintain the environment. Keep the program as it is, protect the machine it runs on, keep backups and spare hardware, and document the workflows around it. This buys time, and for some systems it is enough.
• Recover the source. Rebuild readable source code from the compiled program, verify the rebuild against the original, and return to having a system that can be fixed and changed.
• Reimplement from behavior. Write a new program that does what the old one does, using the old program and its outputs as the specification. This costs more, and it only works well if the behavior is documented first.
• Migrate the data out. Extract the records into a modern system and retire the program. This is the right answer when the data matters more than the program that holds it.

Recovery is the option to choose when the behavior of the program itself is the asset: the calculations, the formats, the machine specific logic, the accumulated rules that nobody wrote down anywhere else. In that case, replacing the program means losing the rules, and recovering the source is how the rules are kept.

When recovery makes sense

Recovery makes sense when the business still needs the program to change, not just to keep running, and when the binary is in a condition that makes reconstruction realistic. Not every binary qualifies, and an honest assessment comes before any commitment. That assessment is the Recon Report: for $45, it documents what the program does and gives a plain verdict on whether recovery is realistic and what a full recovery would take. If the verdict is no, you have still bought the documentation, and you can plan a migration with your eyes open.