> So, the question is: how can we avoid these zombies, both from a user and also from a ‘producer’ perspective?<p>No, the question we should ask first is why being a zombie is bad (especially compared to <i>not existing</i> at all, ie. not being open sourced). I don't see it answered in the article. I don't see it asked in the article. It's simply assumed.<p>There are many different kinds of zombies. Most of them are essentially immortal unless shot in the head. They may move rather slowly, but they have great strength. They may become blind, but they often get a great sense of hearing. They tend to rot if left alone but can last very, very long if preserved properly. There are instances of zombies who continue to be conscious after zombification and who continue to do what they did before (think Mr. Slant from T. Pratchett books). They are unlikely to change their ways, but sometimes it's a good thing. There are zombies who retain their emotions (see Sankarea manga). And so on.<p>It's equally true for open source projects. Even if abandoned (for some definition of abandonment) for the same amount of time, two different projects may become two very different kinds of zombies. LiveScript, for example, is a zombie if you look at its mailing list, but is one of the most productive (for me, of course) compile-to-JS languages out there. StumpWM (a Common Lisp WM) is also nearly dead, yet it's still the best WM if you want a WM that's hackable.<p>On the other hand, there are projects which we'd really like to see dead, yet they refuse to die or even zombify. Projects which suck a massive amount of resources into their life support systems without any visible improvements.<p>> and if you find one in the wild: run!<p>Or you could just take a nice pump-action shotgun (ie. ability to read and write the code) with you and have a good time.<p>In short: this article is shallow. It reads like a generic advice written only to write something, without any deeper insight. And the author seems to know very little about zombies...