If you come across such a Zombie, please ask for it to be added to the Code Shelter (https://www.codeshelter.co/) so projects can be resurrected later. Also, I would encourage you to join yourself, since we always need more maintainers. There's no work requirement, you can simply maintain projects if and when one excites you.
The opening example is not actually of FOSS zombies... because _you_ are someone who knows the project and is interested in pushing it forward (and conceivably, might maintain it).
Real FOSS zombies have _users_ depending on them, and expecting to see maintenance or updates, but nobody to carry those tasks out. The linked-to article is more about "Zombie project steering". IMHO.
I'm not sure some of the users actually knows the state of the FOSS project. I would bet there are more than a few businesses that have software they paid for that has some code from these projects.
In general, I would agree, but you are one OS upgrade from failure (see Mac OS Catalina). I would imagine some testing will surface that the company needs to act.
> It's important to distinguish between a "FOSS zombie" and a project which is simply done. If that's the case, you'll find out easily by reading the documentation.
Yes, it's often the time to fork and take over. But it's a big project in itself, not everyone wants to be the new developer-in-chief.
Sometimes, a project can stay at the borderline of death and alive - there still can be minimum maintenance by a not-so-active developer, major distributions still have packages for it, etc. I recently sent a patch to a project - it took 11 months, but it was eventually merged when a developer with commit access finally noticed it. There was no motivation for me to fork it since all I wanted to merge was a simple fix, I was not planning to take over the project.
> It's important to distinguish between a "FOSS zombie" and a project which is simply done. If that's the case, you'll find out easily by reading the documentation.
I'm glad they mentioned that. Package managers and developers routinely neglect this possibility.
This! One of my pet peeves is when someone recommends a software and then someone else looks at its GitHub commits or last release date and claims that the project is unmaintained because there has been no activity in it for a while.
Some projects do not need any maintenance. They work as is. Lack of activity does not imply bad software.
I'm not sure I get the drama. The beauty of FOSS is that nothing usually stops you from just forking the project and continuing to maintain it the way you see fit. If the original project is dead in the water, people looking for new releases or fixes will find you very soon and will be grateful. Just leave some links in the comments to the issues that you fixed in your fork and people will find it.
I've done this several times and never really bothered to get an "official" redirection from the original project. In most of the cases, Google just picked it up and eventually prioritized my maintained fork over the original zombie, as people posted more and more links to it. A couple of times the original author noticed and shared a quick update of "hey, this dude is maintaining the project now, kudos to him, go to his site for the latest build".
18 comments
[ 3.1 ms ] story [ 42.5 ms ] threadReal FOSS zombies have _users_ depending on them, and expecting to see maintenance or updates, but nobody to carry those tasks out. The linked-to article is more about "Zombie project steering". IMHO.
> It's important to distinguish between a "FOSS zombie" and a project which is simply done. If that's the case, you'll find out easily by reading the documentation.
Isn't this around the time that you make a fork of the zombie?
Sometimes, a project can stay at the borderline of death and alive - there still can be minimum maintenance by a not-so-active developer, major distributions still have packages for it, etc. I recently sent a patch to a project - it took 11 months, but it was eventually merged when a developer with commit access finally noticed it. There was no motivation for me to fork it since all I wanted to merge was a simple fix, I was not planning to take over the project.
OpenOffice is a perfect example of such a project.
I'm glad they mentioned that. Package managers and developers routinely neglect this possibility.
Some projects do not need any maintenance. They work as is. Lack of activity does not imply bad software.
I've done this several times and never really bothered to get an "official" redirection from the original project. In most of the cases, Google just picked it up and eventually prioritized my maintained fork over the original zombie, as people posted more and more links to it. A couple of times the original author noticed and shared a quick update of "hey, this dude is maintaining the project now, kudos to him, go to his site for the latest build".