How to throw a tarball over the wall

It costs a lot of money to open source a mature piece of commercial software, even if all you are doing is "throwing a tarball over the wall." That's why companies abandoning software they no longer care about so rarely make it open source, and those abandoning open source projects rarely move them to new homes that benefit others.

If all you have thought about is the eventual outcome, you may be surprised how expensive it is to get there.

Costs include

• Legal clearance. Having the right to use the software is not the same as giving everyone in the world an unrestricted right to use it and create derivatives. Checking every line of code to make sure you have the rights necessary to release under an OSI-approved license is a big task requiring high-value employees on the "liberation team." That includes both developers and lawyers.
• Repackaging. To pass it to others, a self-contained package containing all necessary source code, build scripts, and non-public source and tool dependencies has to be created since it is quite unlikely to exist internally. Again, the liberation team will need your best developers.
• Preserving provenance. Just because you have confidence that you have the rights to the code, that doesn't mean anyone else will. The version control system probably contains much of the information that gives confidence about who wrote which code, so the repackaging needs to also include a way to migrate the commit information.
• Code cleaning. The file headers will hopefully include origin information, but the liberation team had better check. They also need to check the comments for libel and profanities, not to mention trade secrets (especially those from third parties) and other IP issues.

For a sustainable project, all of the above plus

• Compliance with host governance. It is a fantastic idea to move your project to a host like Apache, Conservancy, Public Software, and so on, but doing so requires preparatory work. As a minimum, you will need to negotiate with the new host organization, and they may well need you to satisfy their process requirements. This includes paperwork obviously, but the code may need conforming copyright statements and more. That's more work for your liberation team.
• Migration of rights. Your code has an existing community that will need to migrate to your new host. That includes your staff—they are community too! They will need commit rights, governance rights, social media rights, and more. Your liberation team will need your community manager, obviously, but may also need HR input.
• Endowment. Keeping your project alive will take money. It's all been coming from you up to this point, but if you simply walk away before the financial burden has been accepted by the new community and hosts there may be a problem. You should consider making an endowment to your new host to pay for their migration costs plus the cost of hosting the community for at least a year.
• Marketing. Explaining the move you are making, the reasons why you are making it, and the benefits for you and the community is important. If you don't do it, there are plenty of trolls around who will do it for you. Creating a news blog post and an FAQ—the minimum effort necessary—really does take someone experienced, and you'll want to add such a person to your liberation team.

Motivations to liberate your software

There has to be some commercial reason that makes the time, effort, and expense worth incurring.

• Market strategy. An increasing number of companies are choosing to create substantial, openly-governed open source communities around software that contributes to their business. An open multi-stakeholder co-developer community is an excellent vehicle for innovation at the lowest cost to all involved. As long as your market strategy doesn't require creating artificial scarcity.
• Contract with a third party. While the owner of the code may no longer be interested, there may be one or more parties to which they owe a contractual responsibility. Rather than breaching that contract, or buying it out, a move to open source may be better.
• Larger dependent ecosystem. You may have no further use for the code itself, but you may well have other parts of your business which depend on it. If they are willing to collectively fund development, you might consider an "inner source" strategy, which will save you many of the costs above. But the best way to proceed may well be to open the code so your teams and those in other companies can fund the code.
• Internal politics. From the outside, corporations look monolithic. From the inside, it becomes clear they are a microcosm of the market in which they exist. As a result, they have political machinations that may be addressed by open source.

None of this is to say a move to open source guarantees the success of a project. A "Field of Dreams" strategy only works in the movies, after all. But while it may be tempting to look at a failed corporate liberation and describe it as "abandonware," chances are it was intended as nothing of the kind.

Read the full post at Meshed Insights.