Needed: New maintainership of node-pre-gyp

[springmeyer]

I'm stepping down from maintaining node-pre-gyp. For the next month and a half (until the end of June) I can be available to a) facilitate moving maintainer-ship to someone else and b) be available to answer any questions on the transition from that new maintainer or the wider community (on this ticket).

However I will no longer be reviewing PRs, making releases, or responding to bug reports.

As far as a new maintainer, that maintainer could be:

• A single person or group/team
• Inside or outside of Mapbox
• Could be given access to this repo or (ideally in my opinion) could take ownership of this module under a new organization
• Either someone who has a vision for what good long-term maintenance looks like or someone who has a vision for how to potentially sunset/deprecate node-pre-gyp without causing undue turbulence for the node.js community

In my mind, all are good options and I will consider any proposals and try to decide promptly (by the end of June) to find a good solution that ensures a) node-pre-gyp is well maintained going forward for the benefit of the entire node.js community and b) also satisfies Mapbox needs.

So, please comment on this ticket if you or your org are interested. Or reach out to me to discuss by emailing me at dane@mapbox.com.

Thanks!

---

For those curious for extra context and history, here is a quick summary.

Since 2013 I (@springmeyer) have been the primary maintainer of node-pre-gyp. Over this time I've tended to be the single point of contact both for internal Mapbox customers of node-pre-gyp as well as for the wider node.js community (fielding requests from companies using node-pre-gyp for mission critical modules as well as tending to the public github issue queue).

I've recruited help from various Mapbox colleagues over the years (thank you especially @mapsam, and @wilhelmberg) and from countless generous open source contributors (like @Mithgol, @murgatroid99, @brianreavis, @jschlight, and @bmacnaughton). I'm especially grateful to these external folks for helping to keep things chugging during times when I've been in management roles without any time for coding.

Recently I've been away on parental leave and coming back I can see how important it is to find a new maintainer for this module.

The main reasons are:

• I no longer have the time or ability to prioritize node-pre-gyp maintenance at the level the node.js community needs (for example, look at all the great work from https://github.com/mapbox/node-pre-gyp/pulls/ronilan that needs attention)
• Mapbox internal needs have shifted towards needing better support for private C++ addons, which node-pre-gyp does not yet support, and therefore it seems to me that someone needs to lead the effort to address this (either by adding robust private module support to node-pre-gyp or moving off node-pre-gyp internally at Mapbox).
• CI systems and testing for the project need special love and attention. A great step forward would be to move node-pre-gyp CI to use github actions. But Mapbox's github org does not permit github actions, so short of Mapbox changing their policy (not something I have time to address) the only way I can see to get github actions unblocked would be to move node-pre-gyp outside the Mapbox org.

The quick timeline of node-pre-gyp is that:

• In ~2011 Mapbox started using node.js during the Node.js 0.1.x series for all our services
• Soon after we started porting over various C++ modules which we'd been using via Python to node.js (mapnik) and writing others from scratch (node-sqlite3, node-srs, node-zipfile, etc)
• Also in 2011 we launched the TileMill project (https://tilemill-project.github.io/tilemill/) which featured many node C++ addons compiled into it in a way that was portable across OS X, Linux, and Windows such that users could download a desktop app and have it work without any additional configuration or knowledge that node.js was involved.
• In 2012 we started work on cloud based mapping systems, and found ways to distribute those same Node C++ addons powering the TileMill desktop app to various linux distros (ubuntu, RHEL, solaris) on AWS.
  • Since we wanted complete control over dependencies for Mapnik (like libjpeg, boost, libpng, etc) and we wanted a system that would work across any linux version and macs we chose not to use standard linux package managers (apt, rpm, homebrew, etc) to handle binary deployment
  • Because several of our key (at the time) node modules (like node-mapnik and node-gdal) included binaries over 1-200 MB in size (per platform) we knew that a system that stored the binaries inside the package published to https://npmjs.com/ would not scale well (instead it would be more scalable to have a system to store the binaries separately, per platform)
  • So we leveraged platform agnostic static linking method to create binaries and archived them on s3. We therefore needed a node.js mechanism to reliably download the statically linked C++ binaries from s3 during npm install (this became node-pre-gyp).
• Also in 2012 @ErisDS from the https://github.com/TryGhost reached out about how to make node-sqlite3 easier to install for windows users
• So in 2013 I launched node-pre-gyp publicly such that the internal tool that helped us scale our AWS cloud deployments could also be used to handle binary deployment for windows users of node-sqlite3
• At the time (and for many years after) I hoped that node-pre-gyp would become nothing more than the "art of the possible" and would inspire the Node.js community to find a solution inside of node core that would avoid anyone needing node-pre-gyp.
• Instead what happened is very widespread adoption of node-pre-gyp and over time also additional projects like https://github.com/prebuild/prebuild.
• When prebuildify was launched I hoped that Mapbox could move our modules to it and deprecate node-pre-gyp. But two things caused friction: a) prebuildify tooling works by storing the binaries inside the npm package which works for most use-cases but not for the Mapbox use-cases that involve really large binaries for many different platforms (https://github.com/prebuild/prebuild-install#note) and b) by the time prebuildify was created I was working on totally different things at Mapbox than node.js c++ addon development so I never found time to address a) with any creative solutions.
• So, to this day node-pre-gyp only supports storing binaries on s3 (which was all Mapbox needed in ~2013) and does not support a) private modules, b) posting to github releases (like the third-party https://github.com/bchr02/node-pre-gyp-github allows), or c) allowing binaries inside of the npm package. All of these things seem quite reasonable to support to me, but are not something I will be able to help with. Hence this issue. Thanks for reading all the way to here :)

/cc @flippmoke @aswamina @danpat @yhahn @mapbox/security-and-compliance

[springmeyer]

In my mind, all are good options and I will consider any proposals and try to decide promptly (by the end of June) to find a good solution that ensures a) node-pre-gyp is well maintained going forward for the benefit of the entire node.js community and b) also satisfies Mapbox needs.

So, please comment on this ticket if you or your org are interested. Or reach out to me to discuss by emailing me at dane@mapbox.com.

Following up here that I did not receive any comments or questions of interest. Also dane@mapbox.com is no longer a valid email as I am no longer an employee at Mapbox and therefore I no longer have maintenance access to this repo. Therefore the time has passed that I would have been able to easily and formally pass on responsibility to others. If anyone finds this issue in the future, and has an interest in taking on maintenance responsibility, I recommend just commenting on this issue (instead of contacting me directly as I previously stated).

[ronilan]

If there is interest from corporate users of the package for more active maintenance and/or tacking some of the more prominent open issues, I may be able to put time/work on this starting spring. Feel free to reach out if relevant.

[fcanela]

Can this unmaintained status be announced in the README.md?

That may help to find new maintainers and quickly understand that the recent issues can not be resolved meanwhile.