back to article What happens when the maintainer of a JS library downloaded 26m times a week goes to prison for killing someone with a motorbike? Core-js just found out

In November 2019, Denis Pushkarev, maintainer of the popular core-js library, lost an appeal to overturn an 18-month prison sentence imposed for driving his motorcycle into two pedestrians, killing one of them. As a result, he's expected to be unavailable to update core-js, a situation that has project contributors and other …

  1. Anonymous Coward
    Anonymous Coward

    No updates for 18 months? MONTHS?????

    I don't know if JavaScript developers will be able cope with not needing to reinvent and rewrite fundamental aspects of their entire application stack for a whole 18 months!

    1. Dan 55 Silver badge
      Thumb Up

      Re: No updates for 18 months? MONTHS?????

      Oh, so that's why they never take local copies of libraries hosted on other websites and host it on their own.

    2. Anonymous Coward
      Anonymous Coward

      Re: No updates for 18 months? MONTHS?????

      There's updates and changes to the most fundamental part of our application stack - the end-users' browser - every few weeks, whether we like it or not. An 18 month pause on everything would be a fucking blessing.

      1. rcxb Bronze badge

        Re: No updates for 18 months? MONTHS?????

        You can blame yourself for depending on so many undocumented behaviours, edge cases, etc. I bet most Reg readers hate those javascript-heavy sites which depend on pixel-perfect page layout to work at all. My browser is not your graphical toolkit. I'm looking for information, not ever-changing interface paradigms to keep re-learning.

        1. Anonymous Coward
          Anonymous Coward

          Re: No updates for 18 months? MONTHS?????

          Well then, I wish you were the one giving me requirements and paying my bills...

          1. Anonymous Coward
            Anonymous Coward

            @AC - Re: No updates for 18 months? MONTHS?????

            If your work does not make you enough money to pay your bills, you have two options: move to another field of activity or use extortion. Constantly adding unnecessary bells and whistles just to keep a steady income for the developer is what I call a "soft" form of extortion. It's like your grocery charging you double for a bag of potatoes just because they worked hard to get a unique, engaging color for the plastic wrap.

            1. Anonymous Coward
              Anonymous Coward

              Re: @AC - No updates for 18 months? MONTHS?????

              You misunderstand me. I'm paid quite well to implement lists of changes and features requested by clients - I don't suddenly suggest "unnecessary bells and whistles" to add, believe me our clients are more than capable of suggesting their own. We're usually in the position of trying to tone down what they ask for.

              I'd like nothing more than for new frameworks to stop appearing every five minutes, and browser manufacturers to slow down the updates - despite annoyances like that though, I quite enjoy my field of work.

      2. Michael Wojcik Silver badge

        Re: No updates for 18 months? MONTHS?????

        There's updates and changes to the most fundamental part of our application stack - the end-users' browser - every few weeks, whether we like it or not

        Ah, if only there were published standards for HTML, CSS, and ECMAScript so you didn't have to worry about all those updates.

        For that matter, some have speculated that it's possible to build perfectly usable websites and web apps without using the latest idiot-bait built into browsers, Obviously that's lunacy, but it makes you think, no? Well, probably no, if you're a typical web developer.

        1. sabroni Silver badge
          Facepalm

          Re: Well, probably no, if you're a typical web developer.

          What's with all the bigots on this site?

    3. ecofeco Silver badge

      Re: No updates for 18 months? MONTHS?????

      Not enough upvotes.

  2. Benson's Cycle

    Zloirock

    It's a transliteration of the Russian for "evil fate". It may just be nominative determinism at work, but I myself would hesitate to use any code from someone who chose that as a user name.

    1. IGotOut
      Coat

      Re: Zloirock

      but you're happy to have a GIMP fiddle with your artwork?

      1. Kevin Johnston

        Re: Zloirock

        I wasn't sure what you meant by that so tried searching the web for clues and now apparently I have to have a video conference with HR

        1. Martin Summers Silver badge

          Re: Zloirock

          Make sure you've got trousers on!

          1. Kane Silver badge
            Childcatcher

            Re: Zloirock

            "Make sure you've got trousers on!"

            Not on the head! We've spoken about this before...

            1. Nunyabiznes Silver badge

              Re: Zloirock

              Make sure your second monitor is not displaying your porn preference of the day.

              1. Paul Crawford Silver badge

                Re: Zloirock

                Tsk, the second monitor is for displaying your porn preference of yesterday!

              2. Anonymous Coward
                Anonymous Coward

                Re: Zloirock

                Make sure your second monitor is not displaying your porn preference of the day.

                Mmmmmmm... Negitoro. (no, not the sushi, you pervert).

            2. TheRealRoland

              Re: Zloirock

              Wibble?

        2. ElectricPics

          Re: Zloirock

          Thanks for the belly laugh!

        3. Sorry that handle is already taken. Silver badge

          Re: Zloirock

          I wanted to upvote this, but you're at 69 right now so I can't. Fnar.

      2. Anonymous Coward
        Anonymous Coward

        @IGotOut - Re: Zloirock

        GIMP doesn't sound offensive to me and I think all this is overblown.

        In my native language the word foot sounds exactly like the famous f3$%k English word, students were always giggling during their English classes in school. Oh and the word do (like in I do) sounds exactly like the f3$%k word so I must be careful when speaking with others of my kin when English people are in hearing range. So, should these word be excised from respective languages ?

        Oh and if someone is unable to make the distinction between GIMP the software and gimp as insult, that person has a serious problem understanding context and should be helped to grow up or else we will be forced to find alternative names for birds like woodpecker and cock just because of some sensitive ears.

  3. chivo243 Silver badge
    Terminator

    New meaning UTB

    He's only under the bus "for 18 months" !! I'll be back!

    closest icon to terminator

    1. ComputerSays_noAbsolutelyNo
      Stop

      Re: New meaning UTB

      Also: the bus-factor in action

  4. James Ashton

    Like ReiserFS

    Hans Reiser went down for actual murder but still ReiserFS struggled on for quite a while. It’s still not quite dead.

    1. Christopher Michaelis

      Re: Like ReiserFS

      People do call it MurderFS though.

      1. Joe W Silver badge

        Re: Like ReiserFS

        Not here. We used to call it "Reißwolf FS" (shredder FS) due to the problems with file integrity in the not-quite-early naughties. Forgot what the actual issue was.

  5. Captain Zippy
    Linux

    Fork and adapt

    It’s open source, right?

    Download, rename, keep attributions and move on.

    1. overunder Silver badge

      Re: Fork and adapt

      Actually, that is exactly what will happen and there will soon be 100 "new" NPMs "based on" it. Or, NPM will maintain it themsleves like the holy grail and pretend it's SOOoo important just to make it seem as if NPM itself is SOOOOOoooo important (they've proven many times that there is always room for self grandeur).

  6. Irongut

    > One of the coders participating in the discussion asked how it is that such a widely used project can be in the hands of a single individual rather than a foundation.

    Because morons like you keep using packages like this. You should have checked things like that before including it in your project.

    1. LucreLout Silver badge

      <iBecause morons like you keep using packages like this. You should have checked things like that before including it in your project.</i>

      Most of the js devs I work with have not the first clue how to follow their dependency graph - they literally don't know, beyond the top level include, what code they're running.

      The only conclusion I can come to is that they aren't capable of understanding why that is a problem, so they simply avoid thinking about it.

      1. Julz Silver badge

        Have an up vote. I really wish this wasn't true, but...

        1. Michael Hoffmann
          Meh

          PyPi

          So true for many other languages as well.

          "pip install ..." one package - and your screen fills with pages full of dependency downloads.

          I've started putting all those into requirements.txt just for my own sanity, version locked inside a virtualenv or container.

          And hope like hell those version dependencies remain available. Apart from forking every single one of them, I'm not sure what you *can* do. Rewrite the lot? :-|

          1. Tom 7 Silver badge

            Re: PyPi

            I do wonder whether someone could add an extension to ccmake or whatever to actually make a requirements.sh to install all the shit you need rather than repeatedly running it to the next fail. Or have I not read the man page closely enough!

      2. Hans 1 Silver badge

        The same can be said about Powershell modules, though.

        The other day I updated Powershell and one of the modules no longer worked so i looked closer and found it was related to another module I am dead sure I never installed or saw getting installed that is used by one of the dependencies of the module I installed,

    2. Anonymous Coward
      Anonymous Coward

      > One of the coders participating in the discussion asked how it is that

      > such a widely used project can be in the hands of a single individual

      > rather than a foundation

      If you’re working in some hideously inefficient corporate borg environment where every line of code is the result of endless meetings and moving goalposts and eventually trying to extract some tiny hint of value from a huge steaming pile, all overseen by layer upon layer of management and bureaucracy, then you might indeed wonder how something like this could have been produced by one (smart?) person in their spare time.

      If every chunk of free software had some sort of “foundation” to supervise it, productivity would plummet.

      1. Carlie J. Coats, Jr.

        It's my experience (over the course of more than 1e6 lines of production environmental modeling code) tht *every* project I've handed off has subsequently been royally screwed up by the bureaucratic coders.

        That's why I stay "gatekeeper" over what is left. FWIW

      2. vogon00

        @ac:

        You say : 'If every chunk of free software had some sort of “foundation” to supervise it, productivity would plummet.'.

        I say/FTFY : If every chunk of free software had some sort of supervision it, quality would improve.

        IMO, the bottom line is either PAY ATTENTION TO AND UNDERSTAND YOUR DEPENDENCIES (Shouting is intentional!) and update your code when necessary, or 'snapshot'; things at your release time and include all deps in *your* release as absolutes.*

        Understanding dependencies involves both your code, and and how it is used by 3rd/4th/5th/Nth parties..

        I get soooo fucked-off with code/systems/applications that suddenly fail due to someone changing one or two lines in a dependency that the author didn't know they had.

        Is it just me. or do people no longer know or care what they are doing? Why write a package/system with *your* name on it when it can be crippled by someone else, by design or accident?

        Learn what dependencies means in your context, and take the necessary steps...

        *The software equivalent of nuking the site from orbit - it;s the only way to be sure :-) Old quote I know, but stop being age-ist, you!

    3. Ken Hagan Gold badge

      "Because morons like you keep using packages like this."

      Careful now. You don't know that the person asking the question is a user. In fact, if they are a user then they surely know why they use it themselves and it is a simple matter to assume that others are making a similar judgement. More likely then, that the person posing the question is (like you, I assume) not using this kind of code and merely bewildered that others are.

      OR ...the economics favour "shoddy code now" over "decent code later" and packages like this facilitate the former whereas coders like you, dear Irongut, favour the latter. Perhaps the Invisible Hand of the Meerkat needs to deliver a hearty slap.

      OR ... the world is full of morons. Yeah. Maybe that.

      1. A.P. Veening Silver badge

        There is something in all of the arguments, so glad you used "OR" and not "XOR".

    4. eldakka Silver badge

      Because morons like you keep using packages like this. You should have checked things like that before including it in your project.

      I think the issue is worse than that.

      Someone like this person will sit back and expect somebody else to form/organise/fund such a foundation.

      In the Open Source world, the answer to a question like (paraphrased) "why isn't this in the hands of a foundation?" is "Because you [the questioner] haven't done that yet".

      If this person believes this product is important enough to warrant such a thing, then why haven't they done the hard yards of getting such a foundation formed?

  7. Lorribot

    It Open Source so no worries

    As more people use open source and more applications and websites get dependant on what were obscure libraries, the whole single point of failure thing will become more apparent and more likely to break stuff or expose things to a security breach.

    Take a look at NTP for a disaster waiting to happen.

    You need to have a more formal set up once stuff becomes very important to a lot of people having one block in his shed in the garden as sole maintainer is a bit of a joke.

    I would imagine insurance companies may start asking what libraries are in place and what support agreements there for code maintenance.

    1. Anonymous Coward
      Anonymous Coward

      @Lorribot - Re: It Open Source so no worries

      And who is to decide when some stuff becomes very important and on what criteria ?

    2. bombastic bob Silver badge
      Meh

      Re: It Open Source so no worries

      "I would imagine insurance companies may start asking what libraries are in place and what support agreements there for code maintenance."

      I'd say "Nunya Business" and shop elsewhere...

      Also, if a software shop is PRUDENT, they will HOST LIBS THEMSELVES and merge FULLY TESTED changes when necessary... and ONLY when necessary!

      Too many cases where this JS "cloud sourced" "forced update" library HOUSE OF CARDS has bitten people in the ASS.

      1. Nunyabiznes Silver badge

        Re: It Open Source so no worries

        You rang?

      2. Alan Brown Silver badge

        Re: It Open Source so no worries

        >> "I would imagine insurance companies may start asking what libraries are in place and what support agreements there for code maintenance."

        > I'd say "Nunya Business" and shop elsewhere...

        You're as much a part of the problem as anyone else. Once someone writes something that gets popular, everyone using it demands instant attention to their problem but nobody wants to pay for it.

        It would be nice to actually be tossed a bone now and then, especially when you hear your work saved a company a hundred million dollars plus (and being told is all you get....)

        1. Peter2 Silver badge

          Re: It Open Source so no worries

          Once someone writes something that gets popular, everyone using it demands instant attention to their problem but nobody wants to pay for it.

          It would be nice to actually be tossed a bone now and then, especially when you hear your work saved a company a hundred million dollars plus (and being told is all you get....)

          Exactly. The problem is quite simple; somebody needs to pay for the programmers work, or when the programmer decides that they want to something better paid (like stacking shelves in a supermarket) then nobody gets to make use of the results of their work.

          This problem has come up several times now, and it appears that it going to continue happening until there is a massive disaster so monumental that nobody can ignore the problem any longer. This is nowhere serious enough.

          1. Anonymous Coward
            Anonymous Coward

            Re: It Open Source so no worries

            >This problem has come up several times now, and it appears that it going to continue happening until there is a massive disaster so monumental that nobody can ignore the problem any longer. This is nowhere serious enough.

            No problem will ever be serious enough. Whether it be the Coronavirus, Environmental Disaster or shitty Javascript code failing. Decision makers are no better than junkies at this point.

    3. Alan Brown Silver badge

      Re: It Open Source so no worries

      "Take a look at NTP for a disaster waiting to happen."

      No need, that's _why_ Chrony exists.

  8. Mage Silver badge
    Coat

    Shirley!

    I thought part of the idea of open source is that it's not just available, but unencumbered, thus anyone can take it over (fork if there are no write/update permissions on the "server" where it's offered)?

    Or am I missing something?

    1. Steve Graham

      Re: Shirley!

      I guess that nobody wants to commit to the learning curve. It's likely that most users of the package don't have the skills to maintain it.

      1. Mike 137 Silver badge

        "I guess that nobody wants to commit to the learning curve."

        Not surprising the learning curve is daunting, seeing how truly abysmal most open source documentation is. Beyond the "how to" for users, it mostly consists of some paraphrase for "reverse engineer it, sucker".

        "RTFM" would be a valid suggestion if "WTFM" were the norm, all the more where applications and libraries are subject to "continuous development".

        1. bombastic bob Silver badge
          Trollface

          "continuous development"

          A sign that INEPT "DEVELOPERS" can't get it right the FIRST time...

          1. doublelayer Silver badge

            Re: "continuous development"

            In some cases, sure. In many cases though, that's not the reason. Plenty of well-regarded projects are run that way. Linux, for example. A lot of the updates fix bugs and add features and we're usually quite happy about it. They have only three choices. They could do what they currently do, they could do a lot more testing on everything, holding back updates, or they could stop development entirely and focus all their time on a single-release perfect OS that would never need updates (I.E. the perfect example of vaporware). I think many would agree that their current approach is optimal. Continuous development, as you put it, is only a problem if it's used to disguise frequent bug releases, but you can release buggy code quite easily without needing any specific development strategy, and proof of that is available everywhere.

          2. Jens Goerke

            Re: "continuous development"

            Java - I'll have a look at it when they're done with the final version.

            1. A.P. Veening Silver badge

              Re: "continuous development"

              Java - I'll have a look at it when they're done with the final version.

              I am not quite that patient, I'll have a look when they have a stable version that lasts more than one year.

        2. eldakka Silver badge

          Re: "I guess that nobody wants to commit to the learning curve."

          Beyond the "how to" for users, it mostly consists of some paraphrase for "reverse engineer it, sucker".

          When software is Open Source and free (as opposed to commercially supported Open Source software), is it really fair to expect the author/maintainer to produce the reams of documentation - that often take longer than the actual coding/testing work itself - necessary that you are implying?

          I, personally, don't think it is.

          The user of such software needs to do their own due-diligence as to what services are provided by the maintainer (support, documentation) and decide based on their own needs whether to use that product as is.

          Running up a website so my family can download my holiday snaps, no problem, don't care, if it breaks so what?

          Defence department having it as a dependency in their logistics support system expected to be used for the next 20-40 years? Do your due diligence and move on to another package (possibly developing your own) that provides the support you need.

          1. Michael Wojcik Silver badge

            Re: "I guess that nobody wants to commit to the learning curve."

            When software is Open Source and free (as opposed to commercially supported Open Source software), is it really fair to expect the author/maintainer to produce the reams of documentation - that often take longer than the actual coding/testing work itself - necessary that you are implying?

            I agree. It's not fair to expect much of anything of open-source software, beyond what's claimed by documents with some legal standing, such as licenses.

            However, a wise developer might examine an open-source package to see if the source was developed using decently-written, maintainable code before adopting it. Or make the commitment to understand the code anyway (which was my position with OpenSSL back in the 0.9.8 days - the code was pretty awful, so I spent some time learning it).

            The Javascript open-source ecosystem is toxic, with a vast array of poorly-written, poorly-maintained packages being used willy-nilly by developers who aren't interested in making the slightest effort to understand them, often for trivial things (need I mention left-pad?), and dependency graphs that surpasseth all understanding. But the situation is similarly bad in many parts of the open-source world. There are relatively few C programmers who are capable of writing decent C, for example, but there's a lot of open-source C. There are relatively few C++ programmers willing to write maintainable C++. Languages like Python also suffer from dependency disease.

      2. Alan Brown Silver badge

        Re: Shirley!

        "I guess that nobody wants to commit to the learning curve."

        It's not _just_ the learning curve, believe me.

        Burnout is a very serious problem on popular projects.

    2. S_W

      Re: Shirley!

      Just because someone can doesn't mean that someone will.

      Or that you won't get a bunch of people all making their own subtly different forks.

      1. bombastic bob Silver badge
        Devil

        Re: Shirley!

        "a bunch of people all making their own subtly different forks."

        Why is that a BAD thing... if they each maintain their own fork?

        1. Hans 1 Silver badge

          Re: Shirley!

          Exactly! Choice is good. Survival of the fittest in software is good.

          1. Michael Wojcik Silver badge

            Re: Shirley!

            Survival of the fittest in software is good.

            Perhaps it would be. We don't know, because it doesn't happen.

          2. sabroni Silver badge
            Facepalm

            Re: choice is good

            https://m.youtube.com/watch?v=6T2zUEiVQU4

            A choice between 100 shit sandwiches? Fantastic!

        2. Alan Brown Silver badge

          Re: Shirley!

          "Why is that a BAD thing... if they each maintain their own fork?"

          What actually happens in such cases is the best parts of the forks invariably merge.

          Even if the authors of the forks violently disagree with each other - in that case someone else will do the merge

    3. Jason Bloomberg Silver badge

      Re: Shirley!

      Open source means people can potentially take it, keep it going, add to to it, fix bugs, if they had to.

      With closed source there's no possibility of that without reinvention.

      One-Nil for open source there. But whether anyone or any group can keep a particular open source project going is another issue. Foundation and group-backed projects should have more people who understand it already on-board and not unduly miss any individual who disappears. That's not the case for a one man show.

      1. Stuart Castle Silver badge

        Re: Shirley!

        "Open source means people can potentially take it, keep it going, add to to it, fix bugs, if they had to.

        With closed source there's no possibility of that without reinvention"

        Can, doesn't necessarily mean anyone does. Look at what happened with Open SSL. Anyone of the users *could* have maintained it, but only 2 were.

        The same applies with Closed source though. If there is a profit in it for them, or they are providing a service contract, the company running the project will just assign a new lead developer if the current one is unavailable for any reason.

        1. Michael Wojcik Silver badge

          Re: Shirley!

          [Any] of the users *could* have maintained it, but only 2 were.

          To be fair, during the Bad Old Days, the OpenSSL project was not taking patches from developers in the US and some other countries, due to legal concerns.

          Also, some users - typically participants on the openssl-dev and openssl-users lists - did provide feedback and suggestions, sometimes including example code that looked a lot like a patch if someone wanted to incorporate it.

          And it's not true there were only two contributors even then. The heartbeat implementation that led to Heartbleed was an outside contribution from Seggelmann, for example.

          What's more important with OpenSSL is that any of its many, many large corporate users could have contributed funding, but very few did. Nor did many individuals.

    4. HildyJ Silver badge

      Re: Shirley!

      You missed the fear of big business among the open source community.

      When Microsoft took over GitHub it lost developers. If they took over this project I suspect the reaction would be fear rather than relief.

      1. Alan Brown Silver badge

        Re: Shirley!

        "You missed the fear of big business among the open source community."

        It's not a "fear", it's experience of companies claiming ownership of the work, asserting copyright and taking the source code closed in order to monetise it.

        Fighting that kind of thing is expensive and longwinded to deal with - very much about who has deeper pockets.

    5. doublelayer Silver badge

      Re: Shirley!

      You're correct. There are a few ways that could be harder than it sounds, though.

      1. The package is easy to use, but hard to modify. Since people haven't been writing it, there are no maintainers who can immediately take charge of important updates, and you're counting on someone eventually learning the internals.

      2. Because nobody was clearly next in line, ten people made forks and people didn't notice until there were now ten incompatible versions. You can either keep that and see if the one you chose dies early or you can attempt to organize the painful and almost fruitless but ultimately a little useful effort to merge those people into a group effort.

      3. Because everyone just picked up the internals, there may be bugs the original developer would know about but which the new people don't, which could become a bigger problem later.

      Open source is great, but it fixes none of the problems of making source easily modifiable without breaking things. I'm sure we've all been in a project where someone with no experience in the codebase is preparing to make a change to something important in it. Often, it ends fine because they studied up and did what was necessary. But when that doesn't happen, it's not a very fun experience. Open source increases the number of people like this, but at least it prevents the risk that someone leaves and nobody knows where the source is or how it works so the entire system stagnates.

  9. chuBb. Bronze badge
    Devil

    Simple solution

    Given github just bought NPM, fork it, and change the NPM registrys entry to point to the forked copy, boom problem solved.

    I dub this method the Soap Drop tyvm

    1. Roland6 Silver badge

      Re: Simple solution

      Escrow isn't new or rocket science. Github (and other open-source repositories) simply need to amend their standard terms of service for projects to include an escrow clause, allowing them once certain conditions have been satisfied to transfer the ownership of a project in the absence of the project's designated lead maintainer...

      1. eldakka Silver badge

        Re: Simple solution

        to transfer the ownership of a project

        I don't think that'd fly, that's a copyright grab (Open Source software is not the same as Public Domain software), potentially breaking copyright laws.

        Especially when there is a much simpler possibility already in place, fork it and move on with that fork being the recommended version.

      2. chuBb. Bronze badge

        Re: Simple solution

        As stated above you don't touch the original project copyright (wrong and left) issues.

        But a fork on the other hand now that's a different kettle of fish while you may not (or you may depends on the license) change the license, you can certainly own your fork and more to the point here the real issue isn't the project but the destination the packages entry in Npm points too, change that to a maintained fork and the problem goes.

        Just have to hope that some bright spark doesn't decide the w3c should be involved, which would make a super tanker look nimble in terms of decision making

        1. Roland6 Silver badge

          Re: Simple solution

          There is no copyright issue - the escrow contractual clause handles that; which the project leader will have signed up to on creating their project on GitHub et al.

          The issue which the clause needs to resolve, is as you note, is the maintenance of the dependency network so that core-js(2020) can simply take over from legacy core-js(Denis Pushkarev) and users don't see any change.

          Given the age of many open source projects, and their leaders, I expect we will be seeing this handover problem occurring regularly in the coming decade.

  10. Pascal Monett Silver badge

    I cannot bring myself to feel sorry for the guy

    The one going to jail, of course. I do feel sorry for the person who was just walking around, minding their own business, and found themselves before the pearly gates.

    Accidents do happen, of course, and I understand that this was not a case of cold-blooded murder or a joyride that ended badly. But still, someone died. A price must be paid.

    And, when he gets out in 18 months, he can remember that the other person is not getting out of their grave.

    Sadness all around.

    1. dono

      Re: I cannot bring myself to feel sorry for the guy

      I wonder if you really understand the notion of an "accident" and that jail etc are deterrents for crime, not something you just pay.

      This article doesn't make any attempt at giving details where you could know if there was justice done here or not, so I think your comment about feeling sorry for him isn't based on any evidence at all. The only conclusion I can draw therefore, is that you think jail would deter someone from having accidents.

      How can you prevent yourself from having accidents without stopping your life completely ? I really don't get the logic here unless you know something that's given outside of the scope of the article.

      I'm really sad that people think this is justice.

  11. Brewster's Angle Grinder Silver badge

    *cough* electron *cough*

    I've just installed electron to start evaluating it. And this was spewed to the console:

    Thank you for using core-js ( https://github.com/zloirock/core-js ) for polyfilling JavaScript standard library!

    The project needs your help! Please consider supporting of core-js on Open Collective or Patreon:

    > https://opencollective.com/core-js

    > https://www.patreon.com/zloirock

    Also, the author of core-js ( https://github.com/zloirock ) is looking for a good job -)

    The author is available to start any employment opportunities in eighteen months...

  12. Claverhouse Silver badge
    Pirate

    Wouldn't it be the same if he had died in the crash ?

    1. Michael Wojcik Silver badge

      Yes, this is just another variant of the Bus Factor problem.

      Of course this can equally be an issue with proprietary software or other forms of industrial knowledge. At my job, we've been working on breaking developer silos for years, giving projects on various components to different developers to spread the expertise around. It can be done but it takes effort.

  13. bombastic bob Silver badge
    Mushroom

    JS lib house of cards - you ARE the weakest link!

    You ARE the weakest link - G'BYE!

    This "constant update" JS library model was the *WEAKEST* it could have possibly been, from authors "pulling their schtuff" out of anger [causing disruptions in service EVERYWHERE] to "unmaintainable" source trees due to death, illness, incapacitation, or prison...

    "Back in the day" I chose to ALWAYS static link libraries to PREVENT the "DLL Hell" in Windows. And in POSIX systems, if I don't build from source [or have a package available in the distro], I'll want to do the SAME THING for _MY_ stuff. Reason: A midnight phone call due to "some third party dweeb" screwing up or NOT being able to make swift updates [in the cases of a 'cloud update' model which I won't do anyway] won't happen to ME because some *IDIOT* "developer" was... THE WEAKEST LINK.

    At least with other OSS projects, particularly those that have been abandoned or become unmaintainable (particularly on github, sourceforge, etc.) it is possible to fork it under a different name (or maybe the same name, with a different dev controlling the source tree). In some cases (like TigerVNC) it was done because the author of the source project (tightvnc in this case) chose to no longer support X11 properly. So over a short period of time, you could still use the old libs, but if you wanted updates, you had to switch to the newer package [no real problem except getting the word out].

    But this "forced update" model used by JS libs is JUST! PLAIN! WRONG!. Weakest link indeed...

    1. eldakka Silver badge
      Boffin

      Re: JS lib house of cards - you ARE the weakest link!

      "Back in the day" I chose to ALWAYS static link libraries to PREVENT the "DLL Hell" in Windows. And in POSIX systems, if I don't build from source [or have a package available in the distro], I'll want to do the SAME THING for _MY_ stuff. Reason: A midnight phone call due to "some third party dweeb" screwing up or NOT being able to make swift updates [in the cases of a 'cloud update' model which I won't do anyway] won't happen to ME because some *IDIOT* "developer" was... THE WEAKEST LINK.

      While that certainly has advantages, it also has significant downsides to.

      Say, for example, you use an OpenSSL library in your code. And a critical bug is found in OpenSSL (e.g. heartbleed).

      In the normal course of events, system admins would download the OpenSSL patch and distribute that to their servers, so any application using the system provided OpenSSL library is now patched.

      However, for your app, you need to download the patch, recompile your app with the patch, and then distribute this new binary to whatever servers (or customers, but I do note you said for 'your' apps, so assuming you aren't talking about an app you distribute to third parties ;) ) are using your app.

      Now, this may be fine for a home project, where your app is the only non-system application running. But if everyone does this, and on a server is a dozen different apps, then the system admins, in addition to applying the OpenSSL patch to the system for those system apps that use it, then have to go out to all the various vendors of those dozen apps and obtain the application-specific patches for each of those apps from each of those vendors, and then go and apply those patches to each of those apps, to fix a single bug in a single - now statically linked - OpenSSL library.

      So rather than applying 1 patch across a couple servers, or dozens, or even thousands in a large organisation, they now have to apply dozens, hundreds, thousands of different patches across different random selections of servers (some servers have app A, others have B, some have A+B+C, some have B+Z, etc. all of which may need to be patched).

      Also, statically linking a library means increased memory use. Every application that has that library inside the app, statically linked, will be running a full copy of that library in memory, having the same code duplicated and stored in memory for each of the apps, 10 apps with statically linked 10MB fred.so? 100MB of memory in use just for the instructions of that library since there are 10 full copies of it in memory.

      When a shared library (Windows DLL, POSIX .so, etc.) is dynamically linked then the library is loaded into memory once and each app that needs the services of that library share (hence the term, shared library) that same, single instruction set in memory. So the same 10 apps using the 10MB fred.so, but now dynamically linked, that's only 10MB of RAM used for the single copy of that library in memory. Sure, they may need to spawn off a process/thread with it's own stack, instruction pointers and so on, but they don't need their own copy of the code itself in memory.

      And 10MB vs 100MB might not sound that bad in typically systems that have 8GB+ just for desktops, let alone servers in the 10's to 100's of GB. But that is just for that one library. Even simple apps (e.g. say a notepad) may have a half dozen libraries linked to it, complex apps could have scores of libraries linked in. Dynamic vs static can save many GBs of RAM in a modern system running dozens of background services all with their dynamically linked libraries instead of statically linked.

      1. Sam Liddicott

        Re: JS lib house of cards - you ARE the weakest link!

        I remember this being a problem for Microsoft just over 20 years ago with an exploitable libtiff having been statically linked into their apps.

      2. bombastic bob Silver badge
        Stop

        Re: JS lib house of cards - you ARE the weakest link!

        fortunately, the number of 'heartbleed like' cases in the world of software support has ALREADY gone BELOW the number of NodeJS issues *caused* by this "cloudy fragile opposite model" of deploying libraries...

        Some DLL Hell issues back in the day were actually CAUSED by Microsoft! One case, ODBC using the MFC DLLs _BROKE_ with Win '95 OSR2 and NT 4, and would have also been broken in Win '98 when it released. The cause: they change the ABI so that it was INCOMPATIBLE with earlier versions of their C++ compiler, when they'd been RECOMMENDING to people to "use the shared libraries" (and you STILL find that as the DEFAULT when you create a new project - you have to EXPLICITLY GET RID OF IT - that and ".Not" bindings, which are _WORSE_)

        I fixed the problem by creating my OWN versions of their DLLs [which were required due to me mistakenly following ANOTHER one of their recommendations, too late to change it] with different names, defeating the whole purppse of having shared libs in the FIRST place, and ALSO teaching me a VALUABLE LESSON about their SERIOUS disadvantages!

        (at the 1997 PDC I bent the ear of more than one engineer over the details of this specific issue, even one very senior guy that looked a lot like Nadella from what I can remember... not sure if he even worked for MS in 1997 but who knows, could've been him)

        The point, in any case, is that I'd MUCH rather deploy a fix to my application for those RARE cases where something like 'hearbleed' has been found, than to take a chance that SOME FRAGILE COMPONENT was "updated" and CAUSED something WORSE.

        So far the "something worse" has more than proven that static linking is better from a customer support perspective. But it DOES mean you have to be able to rapidly respond.

        And the alternative would be to make it open source so that end-users COULD recompile on their end with the new libs. (the package maintainers on Linux distros and things like FreeBSD typically do that on our behalf).

        (I guess it's worth mentioning that applications shipped as BINARIES would be statically linked - those shipped as source, or compiled by package maintainers for various OS distros, could still dynamically link if that makes sense - but another advantage of static link is IMPROVED LOAD TIMES, and so I'm inclined to do that by default even when built from source)

        1. StargateSg7 Bronze badge

          Re: JS lib house of cards - you ARE the weakest link!

          P.S. The text formatter in the Register comments section is UTTER BOLLOCKS !!!

          It c'an't even indent properly to show how source code SHOULD LOOK when properly formatted and indented! DO I HAVE TO WRITE ONE FOR YOU???

          Get on with it REGISTER coders! Make a proper comments section with decent text formatting!

    2. StargateSg7 Bronze badge

      Re: JS lib house of cards - you ARE the weakest link!

      Source code be it public or proprietary MUST be properly coded IN THE FIRST PLACE !!!

      I'm used to an environment where EVERYTHING is considered CRITICAL SYSTEMS CODE usually used in aerospace, weapons and nuclear systems where MILLIONS of people can DIE if it doesn't work or it doesn't error trap properly! We have been FORCED to write proper code for DECADES

      now, so it has become second nature.

      The basic gist of the matter is MOST CODERS SUCK --- When YOU can write easy-to-understand and WELL-COMMENTED code then GitHub will become usable by the average person:

      Copy to a word processor and change the font to Courier New 12 point bold and see

      what MY PROPERLY COMMENTED CODE looks like:

      Type

      // Set generic globally-available integer data types that can be 8, 16, 32, 64 or 128-bits

      // in size that DO NOT NEED to be of an application-or-hardware-dependent bit-width.

      Signed_Integer_Type = Signed_64_Bit_Integer;

      Runtime_Identifier_Type = Signed_Integer_Type

      {

      *******

      Set Basic Record/Object Identification and Owner Identification

      Numbers that are unique to the Local-machine and/or local LAN.

      *******

      }

      Procedure Record_Header_Type.Set_Identification_Numbers(

      New_Identification_Number,

      New_SubIdentification_Number,

      New_Owner_Identification_Number : Runtime_Identifier_Type );

      Var

      Saved_Line_Number_For_Code_Failure : Signed_Integer_Type;

      Begin

      Try

      {

      These are basic low-level integer-based identifiers for internal programmer use.

      These allow applications to identify specific records and the objects they contain

      using a singular major identification number and a minor identification number.

      There are allowed to be duplicates of the major identification numbers within

      an application but for true differentiation, use the minor more-granular

      identification number. The Owner identification number lets applications,

      systems and upper-level container object/items determine to whom or what

      they belong to and/or are directly controlled by.

      The line number definitions allow the internal always-on, realtime debugger

      to save a specific local-procedure code location so that the system can fail

      gracefully when ID numbers are NOT able to be defined at runtime.

      This allows us to find WHICH record property handler is causing

      the problem.

      }

      Saved_Line_Number_For_Code_Failure = LINE_1;

      Identification_Number := New_Identification_Number;

      Saved_Line_Number_For_Code_Failure = LINE_2;

      SubIdentification_Number := New_SubIdentification_Number;

      Saved_Line_Number_For_Code_Failure = LINE_3;

      Owner_Identification_Number := New_Owner_Identification_Number;

      Except

      // Upon any low-level error or runtime exception, do nothing else after the

      // save error information handler, and immediately exit this Record Field Handler Method.

      Set_Global_Error(

      ERROR_IS_UNABLE_TO_SAVE_ID_NUMBERS,

      'FAILED RECORD METHOD: Set_Identification_Numbers()',

      Saved_Line_Number_For_Code_Failure,

      Get_Current_Time_and_Date_As_String,

      SAVE_TO_LOCAL_LOG_FILE + SEND_ERROR_TO_SERVER )

      End;

      End;

      THIS is how EVERY SINGLE FUNCTION AND PROCEDURE should be written in a properly coded CRITICAL SYSTEMS STYLE of coding!

      d

  14. Drew Scriver Bronze badge

    This is a common issue with open source and consulting firms

    I've successfully challenged our in-house developers on these kinds of dependencies quite a few times. Generally, management will listen since they'll be on the hook if the maintainer goes to the slammer, gets sick, or perishes after they've been notified. Legal tends to be interested also.

    Now, if a consulting firm introduces a similar dependency the old adage "Thou shalt never question a consultant" (especially not the ones that are labeled "high-powered" by management) is in full force and all bets are off.

    1. Anonymous Coward
      Anonymous Coward

      Re: This is a common issue with open source and consulting firms

      I've worked with a high powered consultant, back in the days when BS5750 was hot shit.

      BS indeed. I swear he was just making up stuff and peppering it with buzzwords to make it sound important.

      I don't understand, also, why management gives basically root level access to the company to an outsider. The person in question not only made suggestions of how to "streamline" the operation, but also which members of staff were ineffective (and should thus be laid off). Accordingly, the first set of names were the technical people that saw right through the bullshit. It got messy. Consultant got paid and left. As did a lot of the capable employees. And the company? A mere hiccup in history.

      Don't trust anybody calling themselves a consultant that isn't a doctor. And if you work for a company that brings in consultants, don't trust management either. They'll screw you over in a heartbeat if this overpaid outsider says so.

      Anonymous as it was a tech place, somebody here might be "hey, I remember that". If you do, just know that I was very against what was happening because the guy was a clueless dickhead. Why was I there? I was the PFY that translated the technical reports into simple English (imagine explaining code verification (and why it is important) to somebody like, oh I dunno, Trump...). Got paid peanuts. Hated it, hated him. I only hung around long enough to see how badly management would fuck their own company on the "advice" of a complete moron. I did tick the anon box, right? ;-)

    2. Version 1.0 Silver badge

      Re: This is a common issue with open source and consulting firms

      In general, releasing or maintaining open source generates zero income so there's no backup plan when something like this happens. Before open source came along programmers wrote, supported, and documented the whole damn thing - then open source appeared and programmers found their life a little easier, they moved on to new jobs and were replaced by less skilled people who didn't need to understand everything, they just needed to be able to compile it.

      It's like calling yourself a "baker" when all you do is pour a box of mix into a bread machine.

      1. heyrick Silver badge

        Re: This is a common issue with open source and consulting firms

        "It's like calling yourself a "baker" when all you do is pour a box of mix into a bread machine."

        Bakers make bread. I've yet to put anything into a bread maker (three different ones, and different mixes too) that didn't come out resembling a brick. The insides were quite nice when drowned in butter and eaten while still warm, but "bread" it wasn't.

        1. eldakka Silver badge

          Re: This is a common issue with open source and consulting firms

          The insides were quite nice when drowned in butter and eaten while still warm, but "bread" it wasn't.

          Everything is better with enough butter. Short-crust pastry used in meat pies, sausage rolls etc. is 50% butter ...

      2. Hans 1 Silver badge
        Coat

        Re: This is a common issue with open source and consulting firms

        You have this with proprietary software as well, even from reputable companies, e.g. Microsoft or Apple, puff, they decide to abandon this platform, piece of software, or whatever. They put it in money-grabbing maintenance mode and there you are ... the main differences ?

        With proprietary software you paid through your nose for the pleasure.

        With open source you can always fork it.

  15. Sleep deprived
    Happy

    Working from the prison library computer?

    But he may have to buy his cellmates' computer time with his Kickstarter gains.

  16. bazza Silver badge

    In an email to The Register, Ben Balter, senior product manager for community and safety at GitHub, said the company is continuing to think through repo ownership transfers in cases where project maintainers are unresponsive.

    Sounds tricky. It would amount to an in-place fork, and change the ownership status of someone’s account.

    There’s also the issue of who owns the diffs, the project history. Even if the code is open source (and therefore forkable), and individual submitted diffs are themselves open source, the combination of all those diffs (the project commit log) is in itself a “work”, probably. Transferring ownership of that work to someone else is probably alarmingly close to pinching someone else’s copyright. Everything is copyrighted by default, even if there’s no copyright mark in it!

    1. Richard 12 Silver badge

      That's what contributor agreements are for

      However, I've not seen those on very many projects.

      It's arguable that contributing to an open-source project is implicitly giving the project a non-exclusive perpetual license to use everything about your commit, but IANAL.

    2. eldakka Silver badge

      Sounds tricky. It would amount to an in-place fork, and change the ownership status of someone’s account.

      It would also be legally dubious, at best. Open Source software still has copyright, transferring the ownership of a repo like that could be viewed as stealing someones copyright (not in the traditional 'piracy' of copying someone else's work, but you are now claiming the work is yours).

      The best option is to fork it, which is legally permissible under Open Source licenses, and then remommend/flag/update dependency lists to use the fork.

  17. prinox
    FAIL

    Maybe it's time to go back to the basics?

    The proliferation of Javascript means that today an average website contains about 1% real content, and 99% junk, of which 99% isn't used..

  18. www.rzr.online.fr
    Linux

    GitAbandonWare Community

    Hi,

    May I share a link to a best effort community to collectively maintain opensource software:

    https://abandonware.github.io/

    More to come track "#GitAbandonWare" on social media:

    https://twitter.com/RzrFreeFr/status/1243210045061464070

    I am about to publish a webinar video, you can also contact me at:

    https://github.com/abandonware/abandonware.github.io/issues/9

    Regards

  19. Dave Bell

    I am a little surprised that nobody seems to have mentioned the current pandemic as, at least, an immediate threat. Any of us could be in ICU within a few days, dead within a week.

    Could this apparent apathy kill OpenSource as a tool? Who would trust it ever again?

    1. Roland6 Silver badge

      >Could this apparent apathy kill OpenSource as a tool?

      It depends on whether project overseer's fully appreciate the change in their status and thus role once they make an open source project's on-going development open to community contributions.

      A conscientious overseer would put in place continuity plans and thus try to ensure the survival of their project(s). However, I suspect that currently many, whilst wanting to ensure project continuity, are uncertain about the bests ways of achieving this.

      I think that GitHub and others have a role to play and probably need to develop and promote the services they can offer - users with project overseer responsibilities, in this area. In view of CoViD19, I suggest they need to get something up and running within a week or so. Looking at Abandonware's adoption process, a process that utilises the consent of a project's supervisor is trivial.

      So a well orchestrated response and some good marketing, CoViD19 might actually benefit some open source projects. Certainly it would beat negotiating your own escrow arrangements with each and every supplier of proprietary code.

  20. Anonymous Coward
    Anonymous Coward

    Rough Justice

    He ran into a couple of drunks passed out in a crosswalk in the dark. And for that 18 months in a Russian prison, wow.

    1. Anonymous Coward
      Anonymous Coward

      Re: Rough Justice

      Other than the US-Russia difference, that's a difference between driving a manually controlled car and a Telsa/Uber self-driving car, where no one goes to jail or gets fined...

  21. rskurat

    "In a preferred situation, we want to make sure that we’re proactively mitigating issues in advance"

    Is that even English?

  22. ChadF

    Bus factor

    I guess this is a whole new twist on the "bus factor" (https://en.wikipedia.org/wiki/Bus_factor) when a key part of a project is only one developer deep. Only now it also applies if you're the one doing the hitting and not just the victim.

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

Biting the hand that feeds IT © 1998–2020