back to article NPM apologizes for ham-fisted handling of recent staff layoffs

JavaScript library manager NPM on Wednesday apologized for its handling of a contentious round of recent layoffs. The company statement, which comes a week after product manager Rebecca Turner resigned in protest, is co-signed by chief executive officer Bryan Bogensberger, chief product officer Isaac Schlueter and chief data …

  1. Pascal Monett Silver badge

    So, to summarize

    Sharks smelled a good opportunity and went in for the kill, not understanding that they weren't dealing with regular, private-owned companies. They behaved as sharks do, and now they are going to learn that they were not in the right ocean.

    Couldn't happen to nicer people, by the looks of it. I hope they do get competition, that'll teach them a lesson on walking the talk.

  2. Anonymous Coward
    Anonymous Coward

    oh please please

    I just pray I will make it to retirement without having to touch this NPM garbage. Having my nightly build grab random sh1t off the internet is some Winston Smith at end of 1984 level of surrender.

    1. adnim

      Re: oh please please

      if ya can'y build ya own code libraries...

    2. This post has been deleted by its author

  3. Notas Badoff

    How to ruin your reputation

    Thank you for including reference to that blog posting. Having read that posting a couple weeks ago, I today read carefully the non-apology from NPM, Inc. And at the end was Isaac's signature. That's a mark he'll not live down.

    1. Anonymous Coward
      Anonymous Coward

      Re: How to ruin your reputation

      I just read the 'How to Apologize' blog post for the first time - I thought it was so good that I made a copy of it.

      Since Schlueter co-signed the 'apology', and I assume must have at least read it, he will have known how it would be perceived in light of his own publicised standards.

      Which leads to the conclusion that they're really saying "Screw the lot of you".

  4. 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.

    1. ibmalone

      Re: The blessing and curse of centralized software module sites

      I think CPAN is in a stage 10 now though, there are things there that you'd never touch because they have one release 5 years ago, and then there are the long-standing and actively maintained modules like XML::SAX which have been going since the mid 2000s and a curation effort to make sure people can discover the worthwhile parts. (It also has a fundamentally different model in how things deploy which means things like the left-pad fiasco are much less likely.)

    2. Korev Silver badge

      Re: The blessing and curse of centralized software module sites

      It reminds me of when I reported a broken port in Macports* caused it trying to download from a site that was no longer updated; I had the bug report rejected as it was the originator of the software's problem to fix. It would have been a one line fix to have put a functioning URL in....

      *Having one broken port will prevent updates completing fully as it's one big dependency tree

    3. myhandler

      Re: The blessing and curse of centralized software module sites

      All you needed to say was " left-pad should have been a wake up call..."

  5. Anonymous Coward
    Anonymous Coward

    wtf

    why are people still using this shit, 2 years after it became obvious it is a fucking stupid idea NPM needs to fucking die.

    (and the brain dead web devs using all these external fucking libs, need to stop being fucking lazy twats).

    1. CederTree

      Re: wtf

      It's not laziness, it's pragmatism that makes me stand on the shoulders of others rather than spend my time reinventing wheels.

      1. Anonymous Coward
        Anonymous Coward

        Re: wtf

        Gluing black box frameworks and libraries together = web developer these days. Node.js because threading is hard and complicated.

  6. Ben Burch

    Crocodile tears don't erase what you have been doing to people. At one time I thought I wanted to work for you. Glad I dodged that bullet.

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

Other stories you might like