Reply to post: The blessing and curse of centralized software module sites

NPM apologizes for ham-fisted handling of recent staff layoffs

chilinux
Facepalm

The blessing and curse of centralized software module sites

It seems like several modern languages never learn the lessons that two decades of Perl's CPAN should have taught.

The history that seems often repeated goes something like this:

(1) Someone comes up with a clever new programming language and runtime

(2) The primary APIs and modules are created for the language that are provided standard

(3) People start extending the language with modules that aren't accepted for inclusion in the standard

(4) Someone eventually suggests it should make things easier if there was a centralized site for all these additional modules

(5) Someone creates a solution that seems to scratch that itch

(6) Everything seems to be working great for 1-2 years, long enough for the solution to become established

(7) Issues come up that make it clear the full lifecycle of a module was not covered in the original governance model

(8) The central authority comes up with quick fixes to appease the masses and keep them hooked on the established central model

(9) Eventually the lifecycle governance breakage results in a mass of modules of which the majority are no longer maintained, no provision exists for establishing a new maintainer, code that breaks due to updates in the language/API and code which never really work as described.

NPM seems to be in stage 8 of the CPAN history. Also, much like CPAN, NPM is both the name of the tool and the name of the site/service that the tool defaults to. And much like CPAN, the tool is not designed to make it easy to have multiple competing public sources. Instead, the tool encourages everyone to put all their faith in the tool/site authors/maintainers.

Sometime check the documentation for what is involved in trying to create a secondary public NPM using npm-registery and get others to add the registery to the npm configuration. For Python and GoLang, the ability to have multiple sites publishing modules under difference governance rules is clearly a design goal of the tools that come with those languages. That level of flexibility doesn't seem to really be intended as part of NPM.

I really thought the drama of Kik leveraging NPM to bully the author of left-pad should have been a wake up call that governance of NPM was more self serving than in the interest of the community. The Isaac Schlueter post on how to apologize makes it clear that transparency is a requirement. The first two steps in the apology must contain "clear explanations" and the final step of the apology is to explain what will be done "to make sure [it] never happens again." That level of transparency in an apology seems critically important when the installer tool encourages users to trust a single source of governance of the public modules. Yet, NPM fails to provide that level of transparency all. It replaces clear explanations with excuses and deflection. Lastly, after screwing up to have an action plan of '[working] hard to uphold our values every day" seems to speak volumes of how little their values really count for anything. This statement neither provides a clear explanation how the NPM values allowed the problem to take place or provide clear direction on how it will never happen again.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER

Biting the hand that feeds IT © 1998–2021