4 ms·

Quoting the article: Around 60% of packages on npm have not been updated in a year or more. Despite the lack of maintenance these packages are still downloaded

by yoz 6y ago

Quoting the article: Around 60% of packages on npm have not been updated in a year or more. Despite the lack of maintenance these packages are still downloaded billions of times. This is a problem across many other languages/frameworks as well. Many popular packages have a single maintainer and the entry in the package manager index is accessible only by that maintainer. If that maintainer stops paying attention, the problems could be worse than the package just bitrotting, as we've seen from supply-chain attacks like event-stream[1]. There are volunteer orgs like Jazzband[2] which take group ownership of popular packages to ensure ongoing maintenance, but I've not seen many of those so far. [1] https://www.hillelwayne.com/post/stamping-on-eventstream/ https://www.hillelwayne.com/post/stamping-on-eventstream/ [2] https://jazzband.co/ https://jazzband.co/

jedberg 6y ago
Yeah, this is a big problem with pip. If you can't get the old maintainer to add you as a contributor, you can't update a package on pip. So now you have to fork it, come up with a new name, and then publish that instead. And then hope everyone who depended on the old package switches to your package. Reddit had this same problem with abandoned subreddits. They instituted a policy where you could apply to take over an abandoned subreddit, so if there had been no mod activity you could take over. Pip needs a process like that. They need a way to take over an inactive project. Safety would be a big concern, you don't want someone malicious taking over a popular but abandoned package and then hacking it. But safety the other way is important too. There is also the odd situation where you could end up owning the code and not the package on pip. When my company acquired another, we got all their code. We only realized later that we didn't get the credentials for pip. Luckily the old owner was kind enough to just give us the credentials, but we could have been stuck owning the code but not the pip package.
- pydry 6y ago
  There's now a PEP for that that seems to have had some work on it recently: https://github.com/pypa/warehouse/issues/1506 https://github.com/pypa/warehouse/issues/1506 (I got an email referencing it a couple days ago from an old project I asked to take over).
  - voltagex_ 6y ago
    That issue was last updated in July 2019, did discussion continue elsewhere?
- x1798DE 6y ago
  There is such a process, PEP 541: https://www.python.org/dev/peps/pep-0541/ https://www.python.org/dev/peps/pep-0541/ It was adopted in March 2018, and many projects / names have been claimed under this process. You can see a list of some of the projects claimed or in the process of being claimed here: https://github.com/pypa/pypi-support/issues?q=label%3A%22PEP+541%22+ https://github.com/pypa/pypi-support/issues?q=label%3A%22PEP...
  - Mattwmaster58 6y ago
    It's suprising what an email from PyPi admins can do. After many emails from different people and countless GitHub issues over the past year, the only thing that got a reply from the maintainer was an email from the PyPi admins.
deleted 6y ago
[deleted]
lostcolony 6y ago
Isn't there a bit of irony there though? Lack of maintenance could be abandonment, which is the implication...or it could be it's complete, and does what it needs to, and there hasn't been any reason to change it. It's especially ironic when talking positively about COBOL in the same post.
Cthulhu_ 6y ago
Honestly I don't know why a lot of open source is so centralized. I think Github can make a big difference there. I think open source projects should have redundancy in their owners. They should also have a bigger group of people that can decide (either independently or democratically / by consensus) on merging and making a release, which is already assuming that "master = release" hasn't been automated yet. And it should be easier or possible to take over a project, on both source code hosting sites like github and dependency publishing organizations like NPM. In theory anyone can take a library and fork it, but in practice the original library has a monopoly on the name still and will be installed by default for a long time. NPM could instate a deprecation warning on libraries that haven't seen a release or any activity in a year. Mind you, a lot of libraries will be 'done', but those could be marked as such. If anything, the people responsible for the library should be pinged every once in a while and indicate that they are still responsible for the library, and will be able to act in case of e.g. a security vulnerability.

by yoz 6y ago

jedberg 6y ago

Yeah, this is a big problem with pip. If you can't get the old maintainer to add you as a contributor, you can't update a package on pip. So now you have to fork it, come up with a new name, and then publish that instead. And then hope everyone who depended on the old package switches to your package. Reddit had this same problem with abandoned subreddits. They instituted a policy where you could apply to take over an abandoned subreddit, so if there had been no mod activity you could take over. Pip needs a process like that. They need a way to take over an inactive project. Safety would be a big concern, you don't want someone malicious taking over a popular but abandoned package and then hacking it. But safety the other way is important too. There is also the odd situation where you could end up owning the code and not the package on pip. When my company acquired another, we got all their code. We only realized later that we didn't get the credentials for pip. Luckily the old owner was kind enough to just give us the credentials, but we could have been stuck owning the code but not the pip package.

pydry 6y ago
There's now a PEP for that that seems to have had some work on it recently: https://github.com/pypa/warehouse/issues/1506 https://github.com/pypa/warehouse/issues/1506 (I got an email referencing it a couple days ago from an old project I asked to take over).
- voltagex_ 6y ago
  That issue was last updated in July 2019, did discussion continue elsewhere?
x1798DE 6y ago
There is such a process, PEP 541: https://www.python.org/dev/peps/pep-0541/ https://www.python.org/dev/peps/pep-0541/ It was adopted in March 2018, and many projects / names have been claimed under this process. You can see a list of some of the projects claimed or in the process of being claimed here: https://github.com/pypa/pypi-support/issues?q=label%3A%22PEP+541%22+ https://github.com/pypa/pypi-support/issues?q=label%3A%22PEP...
- Mattwmaster58 6y ago
  It's suprising what an email from PyPi admins can do. After many emails from different people and countless GitHub issues over the past year, the only thing that got a reply from the maintainer was an email from the PyPi admins.

deleted 6y ago

[deleted]

lostcolony 6y ago

Isn't there a bit of irony there though? Lack of maintenance could be abandonment, which is the implication...or it could be it's complete, and does what it needs to, and there hasn't been any reason to change it. It's especially ironic when talking positively about COBOL in the same post.

Cthulhu_ 6y ago

Honestly I don't know why a lot of open source is so centralized. I think Github can make a big difference there. I think open source projects should have redundancy in their owners. They should also have a bigger group of people that can decide (either independently or democratically / by consensus) on merging and making a release, which is already assuming that "master = release" hasn't been automated yet. And it should be easier or possible to take over a project, on both source code hosting sites like github and dependency publishing organizations like NPM. In theory anyone can take a library and fork it, but in practice the original library has a monopoly on the name still and will be installed by default for a long time. NPM could instate a deprecation warning on libraries that haven't seen a release or any activity in a year. Mind you, a lot of libraries will be 'done', but those could be marked as such. If anything, the people responsible for the library should be pinged every once in a while and indicate that they are still responsible for the library, and will be able to act in case of e.g. a security vulnerability.