Beware of Open Source Software Zombies

TL;DR — When putting source code into the open, reserve some time & energy to build a community around it, otherwise: zombie.

As a user of and as someone who contributes to Open Source Software (OSS), I increasingly see a troublesome pattern: source code that is openly available but really is a walking dead, a zombie. So, the question is: how can we avoid these zombies, both from a user and also from a ‘producer’ perspective?

No matter if you are an established commercial entity that donates one of its crown jewels to the Apache Software Foundation, if you’re a startup that pivots and while you’re at it (or later) open source some of your code base, or if you as an individual trying to increase your chances to land your dream job through creating an interesting OSS portfolio.

Chances are you create an OSS zombie. Something that is in the open, people can use (if they would only be aware of it) but in fact the bit rot has already started.

Typical symptoms of an OSS zombie include but are not limited to: low participation (mailing list, issue tracker, etc.), no updates or changes in the code itself, single committer, doesn’t show up when googling.

Bottom line is: Github is littered with OSS zombies. As a tiny data point I can offer my own list of Github repos.

Why is that so? Because we focus on writing the code — and maybe the documentation — but we forget about the people, the ones who are using it and likely contribute something back, in form of bug reports, fixes or cool applications.

So, next time you embark on creating an OSS project, consider the following steps to avoid a zombie:

• Create an exciting video walkthrough of your software to attract people and use tools like asciinema to make it easier for folks to follow along — and hopefully they help spread the word.
• Launch a competition or organize a hackathon to bring your users (virtually) together and exchange thoughts or code.
• Hang out. A lot. Create a Slack community, hold monthly Google hangouts or create a dedicated IRC channel, whatever. But (virtually) be with your users and potential tommorrow’s contributors.
• If you’re an organization (and can afford it): assign a person to the task, full-time, to support and grow the community.

Just like zombies are missing their brains, OSS zombies are missing humans that use and contribute to them. Don’t create OSS zombies and if you find one in the wild: run!

UPDATE: Thanks for the overwhelming number of eyeballs here (2k+ views in 12h), the recommendations and your feedback!

I wanted to clarify one point, though, something I should have made much clearer: I’m not suggesting that everyone who releases OSS must build a community. I’m suggesting that if your OSS project has reached a certain stage in the lifecycle (read: dead) then please clearly flag it so — the ASF with its attic is actually a good example.

Boils down to expectation management, I suppose.