GitHub's npm gave away a package name while it was in use, causing rethink Last December, GitHub recognized that it hadn't revisited the dispute policy for npm packages since acquiring NPM in March, 2020, and in February this year, it suspended transfers of abandoned packages until it could come up with a system that's fair, consistent, and enforceable. The Microsoft-owned company did so because …
I can't speak for the general situation, but in this specific case I have to say I think the owner of the original Bebop package (Kelling) was at fault, for not ensuring that the correct email address was on file for his package. I don't think it's asking too much, if you're publishing a package to a public resource, for the onus to be on you to keep the correct email address.
Yes, I feel bad for him that he lost control of the package name, but some of the blame does lie with him. In the circumstances I think Github and the new Bebop owner handled it well.
I'm not so sure it's entirely on the dev. Surely part of the check before releasing the name should have included checking simple things, perhaps like "whether the bloody thing had been updated in the past year". I recognise that there are statements about "fixing the process" but really, given there was evidence of continuous use, it should be more like the ICANN result where the original owner gets it back.
Or they could just, you know, have noticed that other packages depend on it which should make fundamentally changing that package to a product that does something totally different a non-starter.
Not to mention npm tracks download traffic.
What if the dev were dead and gone but others still used the package? Should they see all their systems break because the package owner isn't around anymore?
How did the wrong email address get listed in the first place? You know, like everybody else does when you set up an account - send a message to the address in question to verify it's a real address and that it belongs to the requestor?
if package namespace maintenance is such a clusterf**k then they should adopt maintenance methods somewhat similar to domain names because that's the very reason they were developed: we need yearly "renewals" - even if it's free they should make them validate each name via email validation links every year.
If one of the yearly validations is not completed even after an entire year passed then the name should become inactive and not usable by anyone, but not released - it should remain in quarantine for yet another year - only the original owner should be able to 'revive' it from quarantine during this time.
Only after these 2 years (1 waiting for re-validation and 1 quarantine) they should release the name for reuse.
yes, but even with hierarchies the basic original questions still remain: is the email point of contact for the hierarchy management still valid? When was the last validation done?
Thus the need for periodic email revalidations still remains, even if names are not deactivated/reused, it's useful to know that someone is actively managing things and that that hierarchy is not just running on inertia without any management.
No, with hierarchies, most of the original problem goes away - no-one else is going to want to use the same name for a different product. The only issue that remains is that of a sole developer dying, which isn't a massive issue if you can fork, and just rename the upper levels of the name.
That's just a convention in the naming of packages, and Maven groupIds (which is how most developers manage package dependencies in a Java project these days, and what I think the article author was probably partially referencing).
You can eschew that entirely, and it's not a problem. But most dependencies are now following the format.
Sometimes the groupId changes - the common examples being when Apache takes over a popular bit of software and the groupId becomes org.apache.{project}, but the package names in the software will remain the same for longer for compatibility reasons.
It's not perfect. There's no API/incompatibility versioning mechanism (to manage incompatible changes in a bit of software between release versions) beyond sticking that in the artifact name *and* package names (to prevent collisions, even flipping hibernate gets this wrong and they knew they were making incompatible changes with v6.x!).
Public package repositories and the "ecosystems" that have grown around them are toxic. The namespace problem is only one small part of that. Fixing it won't help much.
Some of the older public repositories, such as CPAN, are not quite as much of a mess because they began with better governance and evolved a measure of community oversight, and because they're not so popular with the kids and therefore don't attract quite so many trivial submissions. But on the whole it's a concept which can't be fixed in its current form.
Building applications with a vast and largely hidden array of direct and transitive dependencies of unknown provenance and quality is never going to work well.
That's a good point. If the package name management system is changed to ensure that only the owner of the name can relinquish it, then if said owner is no longer alive, there will be no one to relinquish it.
Stalemate.
So there will either have to be a process to take ownership by the package management authority, or the package owner should be prompted to nominate a "secondary" owner (and not himself with another email address) in case of non-response under 90 days or something like that.
In any case, it is not an easy situation to resolve.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
