Open-source development: the dangers 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 to explain open source. I’ve been saying “free as a puppy” for years and coined “free as a pup” to illustrate the burden on individual maintainers who find themselves forced to deliver unpaid but timely fixes to giant corporations using their project. Recent vulnerabilities in Log4j show that we have learned relatively little as an industry from Heartbleed about this issue.

But having recently purchased a new mattress, I found myself pondering “free as a mattress,” which I find a particularly pungent metaphor for open source. I always thought of it in terms of checking 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 from unknown provenance may be exactly what you need, or it may contain bugs that you only discover exist after bringing it back to home and integrated into your infrastructure.

But the mattress is also a responsible disposal by the owner of the mattress (or the creator of the open-source project). When commercial software vendors discontinue older apps or operating systems, there are sometimes calls to open them instead. It’s very different from what you might call an “open-source exhaust” project; something you develop because you need it for your business, but isn’t so critical to business value that you need to keep it. There are many valuable “open source” projects where the original coding team can open it up and benefit other people contributing to it as they continue to use and develop it.

With an obsolete project that you’re not going to use anymore, even if the code isn’t cluttered with patents, trademarks, or licenses from other code owners, open source as abandonware may not be particularly effective. There’s probably a reason the original vendor no longer finds it worth maintaining and without a community willing to invest in the code base, just making it free might not be really useful.

Open Live Writer is a rare counterexample; the last commercial version was released in 2012, but in 2015 it was still so widely used that it was worth a group of fans within Microsoft working to update the code base and ensure that be open source. Even so, there has been relatively little development on the project recently, though services like Google Blogger have changed to make it harder to post.

You get a fly dump fine and you probably have to pay your town hall to remove an old mattress: getting rid of an old app will reduce your technical debt, but you’ll still have to devote time and resources to untangle it from your other systems (and take any private information or embarrassing swearing from the code comments). Whether it’s a mattress or a codebase, deciding to throw it away or give it away has to be a responsible decision.

Will it be useful to anyone? Is it safe enough for them to use? Will it last them long enough to make it worth it to pick it up and install it? Despite its age, my old mattress is still quite comfortable and supportive. I’m just sick of putting the separate memory foam topper back on 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’ve been working on for several years – but aren’t as invested in anymore – in good enough shape to be open if you no longer plan to be involved in it, or if the technology has changed so much that your project is no longer the best way to approach the problem?

My old mattress probably doesn’t have a second act. At least with open source, if it gives them enough head start to be useful, someone might fork off a project and pick it up – but just because it’s free doesn’t mean it’s good value .

Previous Global Immersion Circulator Market 2021 Innovative Strategy by 2027
Next How distance learning can help close the digital skills gap