Open-source development: The perils and responsibilities of creating your own projects
There are several riffs on the original 'free as in speech, not free as in beer' distinction as a way of explaining open source. I've been saying 'free as in puppy' for years and I coined 'free as in night off' to illustrate the burden on individual maintainers who find themselves on the hook for providing unpaid but timely fixes to giant companies using their project. The recent vulnerabilities in Log4j show that we've learned relatively little as an industry from Heartbleed about that issue.
But having recently bought a new mattress, I found myself musing on 'free as in mattress', which I find a particularly pungent metaphor for open source. I've always thought about it in terms of vetting the projects, libraries and dependencies you use in your code. Like a mattress you find on the side of the road, an open-source project with unknown provenance might be just what you need, or it might have some bugs that you don't find out about until after you've brought it home and made it part of your infrastructure.
But the mattress is also about responsible disposal by the owner of the mattress (or the creator of the open-source project). When commercial software vendors sunset older applications or operating systems, there are sometimes calls to open source them instead. That's very different from a project that you could describe as 'open-source exhaust'; something you develop because you need it for your company but that isn't so core to business value that you need to keep it propriety. There's a lot of valuable 'opened source' projects where the original coding team can open source it and get the benefit of other people contributing to it because they continue to use and develop it.
With a sunsetted project that you're not going to use anymore, even if the code isn't encumbered by patents, trademarks or licences to other code owners, open sourcing it as abandonware may not be particularly successful. There's probably a reason the original vendor doesn't find it worth maintaining any more and without a community prepared to invest in the codebase, just making it free might not actually be helpful.
Open Live Writer is a rare counter example; the last commercial version came out in 2012 but by 2015 it was still so widely used that it was worth a group of fans inside Microsoft working to update the codebase and arrange for it to be open sourced. Even so, there's been relatively little development on the project recently even though services like Google Blogger have changed to make it harder to publish to.
You get fined for fly tipping and you probably have to pay your local council to take an old mattress away: getting rid of a legacy application will reduce your technical debt, but you still have to spend time and resources disentangling it from your other systems (and taking any private information or embarrassing swearing out of the code comments). Whether it's a mattress or a codebase, deciding whether to throw it away or give it away needs to be a responsible decision.
Will it be useful to someone? Is it safe enough for them to use? Will it last them long enough to be worth them collecting and installing it? Despite its age, my old mattress is still pretty comfortable and supportive. I just got fed up of tugging the separate memory foam mattress topper back into place every few days – but there's a coffee stain and a small tear on one side. If I couldn't sell it, is it a good idea to give it away? Is the project you worked on for several years – but are no longer so invested in – in good enough condition to open source if you're not planning to be involved in it any more, or if technology has changed so much that your project is no longer the best way of approaching the problem?
My old mattress probably doesn't have a second act. At least with open source, if it gives them enough of a head start to be useful, someone could fork a project and take it over – but just because it's free doesn't mean it's good value.