For clarity, I refer to the various parties as follows:
Owner: the person/company who currently owns the software/package/etc., and wants to leave the industry
Clients: the people /companies who use the software/package, whether they actually pay for it or not
3rd Party: a person/company who handles programming/support, but doesn’t purchase the package (i.e., a contractor)
Purchaser: a person/company who purchases assets from the Owner.
- A) The Code Outlives the Developer
I don’t like even really listing this as a “strategy”, but it is the default way out of the business if we don’t pick other ones, and I have seen this happen quite a few times. It’s sadly probably the most frequent option. Just this summer I had to take on a new client and try to help them out of a pickle because their package’s owner passed away unexpectedly.
- B) Sell the business/client list/source code to another PL/B developer
This is the one that owners seem to like the best, because it lets them “cash out” in exchange for selling their lifelong sweat equity. If you can find someone willing to buy everything outright, then definitely go for it. However, from the other side of the desk, as the one making the purchase, I’ll tell you that this option is a really big hassle – especially once the deal gets big enough to need to get lawyers and a bank or other investor involved. The due diligence that has to be done to make a good deal is really time consuming, and it comes with quite a bit of risk for the purchaser. That’s the reason that I don’t ever do deals like this. But like I said, if you can get someone who wants to pay the asking price, it’s a great option from the owner’s side of things.
- C) Contract out the Development/Helpdesk side of the business
I have seen this option used when owners may not be ready to retire fully, but are burned out on dealing with the day-to-day support and upkeep of a system. The owner will hire a third-party developer to do the dirty work of maintaining code, troubleshooting errors, etc. But the owner will keep all the rights to the software, keep the client list private, and continue sending bills to the clients. The owner will pay the third-party developers out of their gross receipts from the clients, and keep the difference. This isn’t quite passive income, but it’s pretty close. It also allows the owner to either pass on their business to a relative when they retire, or the owner can convince the third-party dev to become the Purchaser. For the third party, it’s a more attractive deal because they don’t have to pay up front to purchase a package, they don’t know all the ins and outs of. The clients also get to keep working with the Owner, just as they’ve always done. The outsourcing is usually done behind the scenes.
- D) Sell the source code to the client(s) and let them maintain or contract out
This plan works best when there are just a couple of clients, and their operation is large enough to finance having a developer on-call to support them. The reason this option is used is because selling a business (option B) is a real pain, and the clients generally don’t want to be in the software business. They just want to have their package maintained, or at least know that they have the option to modify it in the future if they need. The problem here is trying to find the value of the software package which meets both the owner’s expectation and the client(s) cash flow.
- E) Release the code as open source, let the clients maintain or contract out
This is almost exactly the same as D, but instead of selling the package, the owner just releases it under an open-source license. This means anyone can use or maintain the software without having to pay any royalties on it. I’ve usually seen this done when there’s not enough income generated by a package to justify going through all the legal hurdles to sell it. Also, this is sometimes done with packages used by small non-profits.
- F) Assign rights to one or more other developers
This option is a hybrid arrangement. The owner will assign the rights to develop/maintain the source code to one or more third parties, in exchange for a percentage of any income they make from the source code. In exchange, the owner agrees to provide knowledge as required to help the third party solve problems and support the customer base. The upside for the owner is that they really just need to provide the source, the client list, and be available to talk shop with the third-party if there’s a question. In exchange, they take a percentage of all the income that the third-parties earn from the source (even new clients that the third party found by themselves). For the third-party, they get new clients without having to do any marketing, and all they have to do in exchange is to pay a commission fee to the original owner. And the clients get a long-term transition plan and they know that there’s more than one person who can support their products. This is the option that I prefer and usually try to steer owners toward.