How should we deal with unmaintained and deprecated packages?


#1

There is this package (language-julia) which is not maintained (for over a year), and the author is not working on any PRs. I wrote a replacement (tpoisot/language-julia) which fixes a few bugs, implement new things, etc.

Since all packages describing languages seem to be named language-foobar, I thought I’d make mine the replacement one (since it’s being worked on, and all). But there seem to be no mechanism to deprecate a package, and/or suggest a replacement.

Any ideas about how I can proceed?


#2

If the original author cannot be contacted or doesn’t respond there’s not much you can do. You need their cooperation to add you as a collaborator, or to transfer ownership.
But eventually deprecated packages will drop off the charts. The eco system will correct itself. You can name your package language-foobar-new or -next or something to indicate it’s an improved fork.


#3

I agree – in this case, the original author unpublished it. But this might be something that happens, and perhaps there is the potential to develop a system to deal with it? As in, reporting packages that are out of date and unmaintained, and letting people vote on replacements?


#4

The old package may be working perfectly well for the original author though. I kind of view this like someone who owns a patch of land. Sure, you might want them to plant some nice flowers to make the neighborhood look nicer, but you don’t have the right to take their land away if they don’t.

This is the way open source works. If something is left unmaintained or the original author doesn’t agree with the direction you think the product should go in, you’re perfectly within your rights to make a new fork of the project. But don’t expect to give it the same name. (See Node.js vs IO.js or the entire history of Linux distributions and many, many other projects for examples.)


#5

Package authors need the ability to mark a package obsolete or un maintained. Currently I have to check the github readme and commit history to check if the package is being developed.

The version release date next to the version would be helpful too.

Unmaintained packages are more likely to die off, even if they currently work.


#6

It is good etiquette to add something like “Not Maintained” in big letters to the top of the readme on these projects. I’ve seen several like this. Then you would see it right on the atom.io page.

Edit: Also put it at the beginning of the description like “[not maintained]”