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 developers concerned about the fate of his code library.

Core-js is "a modular standard library for JavaScript," meaning it provides a load of functions to perform common, useful operations. Often used for "polyfills" – implementing modern browser features in older, less capable browsers – it gets downloaded more than 26 million times every week via the npm registry, and is widely used by major companies including Apple. Now its future is uncertain.

Pushkarev, known as zloirock on GitHub, mentioned the possibility he may end up incarcerated in a thread last May discussing the addition of post-install ads to generate revenue for a project that so many use and so few pay for. He anticipated he may need to pay for legal or medical expenses related to his motorcycle accident.

In that thread, developer Nathan Dobrowolski asked, "If you are in prison, who will maintain [core-js] then?"

Pushkarev offered no answer. Since his conviction last October, the need to resolve that question has become more than theoretical.

A discussion thread started in February asked whether core-js can survive in the absence of Pushkarev, who has been the primary maintainer of the project. To date, only Pushkarev has issued official releases, the last of which arrived on January 13, 2020.

At least one other project contributor, an individual associated with GitHub account slowcheetah, has "collaborator" status – basically, write permission – and claims to be able to issue updates. But it's not clear whether this person's stewardship will be sufficient to sustain faith in the project.

Another JavaScript cryptographic library known as jsrsasign faces a similar challenge: its maintainer, Kenji Urushima, hasn't been active since April 2018. Programmers who use the software have expressed concern about the lack of communication and an unaddressed vulnerability, noting that 350 npm projects depend on the library, including some by Microsoft and Mozilla, among others.

The situation facing core-js and jsrsasign underscores the many challenges facing popular open-source projects, particularly those that have seen usage grow without changes in governance. 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 core-js went dormant, it probably wouldn't cause as much trouble as the left-pad incident of 2016. Nothing would suddenly break and developers would have time to revise dependent code. Nonetheless, a transition plan may have helped.

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. "In a preferred situation, we want to make sure that we’re proactively mitigating issues in advance," he said.

"We encourage maintainers to move popular projects from their personal account into an organization. In addition to gaining access to advanced community management features, adding at least one other maintainer as a co-owner further ensures the project can continue, even if one maintainer is unavailable."

He added maintainers can signal that they intend to step away from projects by setting their GitHub status to "away," to let contributors know they will not be responsive during this period.

Balter said GitHub has processes for transferring account ownership in the event of illness that apply to relatives, collaborators, coworkers, and business partners. Forking dormant repos is also an option, he said, noting that GitHub can potentially re-position a fork if it takes over as the canonical source of the project. ®