13 votes

What happens when the maintainer of a JavaScript library downloaded 26 million times a week goes to prison

6 comments

  1. Akir
    Link
    As much as it seems to have gotten a bad rap lately, problems like these are why I think that JavaScript needs its own version of a standard library. IMHO when it comes to these mega-popular...

    As much as it seems to have gotten a bad rap lately, problems like these are why I think that JavaScript needs its own version of a standard library. IMHO when it comes to these mega-popular packages, the npm model of software development takes the efforts that would normally be taken care of by the most involved people and makes it so that every developer has to constantly evaluate the quality and usability of each module. Perhaps I am a bit too old fashioned, but it terrifies me that usage statistics have replaced code review as a method of determining the quality of a software package.

    5 votes
  2. [5]
    ThatFanficGuy
    Link
    That's a hell of a story. You can see Denis mention "stupid law" in regards to how Russia has apparently mistreated him... after he killed a person with his bike. I saw this quoted in one of the...

    That's a hell of a story.

    You can see Denis mention "stupid law" in regards to how Russia has apparently mistreated him... after he killed a person with his bike. I saw this quoted in one of the earlier posts in the GitHub thread regarding the fate of the project, but I'm tired, so pardon me for not going out to look for it now.

    I feel like this is something GitHub might consider pulling a "special circumstances" for. Like the article says, it's not a library in urgent need of fixing – but if suddenly disappears like left-pad did, lots of projects are going to break suddenly and for a lot of people.

    2 votes
    1. entangledamplitude
      Link Parent
      I don’t see why Github needs to do anything. I feel that anything they do can only set complicated precedents. The answer is simple. It’s an open source repository with a stated license. Fork it,...

      I don’t see why Github needs to do anything. I feel that anything they do can only set complicated precedents.

      The answer is simple. It’s an open source repository with a stated license. Fork it, and do what you want. Those who want to switch to the new one can do so. At most, a community decision could be made at the NPM level. I don’t think GitHub has any role to play in this matter — it would only be unnecessary interference.

      3 votes
    2. [3]
      reese
      (edited )
      Link Parent
      It won't suddenly disappear like left-pad did, because NPM tightened the restrictions around unpublishing packages. There are options. There's already another contributor with write access to...

      It won't suddenly disappear like left-pad did, because NPM tightened the restrictions around unpublishing packages.

      There are options.

      There's already another contributor with write access to core-js, this user is merging pull requests at least. In the long-term, you're right, "special circumstances" is the way to go. GitHub recommends moving popular projects into organizations with multiple trusted contributors, as noted in the article, but they may have to do that themselves in this case. They already follow hand-off procedures when people die. As long as the existing MIT license is preserved in a core-js move, I don't see a problem. If/when the original creator's out of prison, he can work with GitHub or the replacement maintainer(s) to get permissions back, PoLP.

      NPM could also just point to a fork of core-js of the same name for subsequent releases as long as it's from a trusted source.

      It's weird and unprecedented, but the silver lining is that these waters will be charted. And I get that just because some user can merge pull requests that doesn't mean they're trustworthy or competent, but, honestly, this is an open problem. You can have thousands of users and millions of downloads over years of dedicated maintenance, and despite all that there's only one other person who can be trusted enough to merge pull requests? This seems like a developer culture problem.

      Most of us enter the workforce without having contributed jack shit for open source or free software, so there's this pervasive, unaddressed entitlement that maintainers are faceless free labor, because the majority of developers don't have the perspective one gains by being on the other side of the conversation. Most developers just use other developers' code, so they demand instead of ask. And it's okay to ask if you're not comfortable with a given framework or programming language, btw, but we need to collectively require more source control-based collaboration in college and early-career so there are more prospective candidates to take the helm.

      Edit: I don't know if this is a thing, but maybe all of us maintainers should start formalizing around stale maintainer procedures or something, at the very least documentation akin to the code of conduct and license we're encouraged to include in our codebases. "If the maintainer(s) are unresponsive for x amount of time, you have the right to such and such."

      2 votes
      1. [2]
        ThatFanficGuy
        Link Parent
        This sounds like a good idea in principle. Kinks to work out as always with new things, but sounds like a sane and reasonable thing to do. My question is: how do you fascilitate that on an "owner"...

        "If the maintainer(s) are unresponsive for x amount of time, you have the right to such and such."

        This sounds like a good idea in principle. Kinks to work out as always with new things, but sounds like a sane and reasonable thing to do.

        My question is: how do you fascilitate that on an "owner" level? How do you transfer rights? How do you indicate that the transfer was legit (and not just someone taking advantage of confusion)?

        This is not for you alone to decide, of course. We're talking about open source: the community must be able to chime in.

        1 vote
        1. reese
          Link Parent
          Eventually technical standards would wholly replace docs like that once sensible, popular patterns emerged. The docs would just push the issue and drive the conversation you're wanting. One...

          Eventually technical standards would wholly replace docs like that once sensible, popular patterns emerged. The docs would just push the issue and drive the conversation you're wanting. One immediate observation is that the likes of GitHub and GitLab should probably start requiring backup maintainers for sufficiently popular projects that lack them (they can flag projects lacking backups, warning users). How do you measure popularity? Stars, downloads, clones, clicks, etc. Depending on the detected language, they could potentially try querying popular artifact repository public APIs as well for additional stats to make some kind of determination (that's easier for GitHub since they've spun up their own artifact solutions). That's on them more, not the maintainers.