Ask questionsMaintenance of the bundled package manager
On two occasions I’ve dedicated my time to try to improve the package manager that ships with Node, and both experiences have been poor:
In the first case, due to a hot issue not being referenced/closed by a PR that addressed it, and me not knowing of that PR, the time I dedicated ended up being spent in vain. This was a little bit my fault for assuming that the problem still needed fixing, since the issue was still open and there was no announcement from the maintainers there that it’d been fixed. Still, better communication on the maintainers’ part would have helped avoid that scenario too.
In the second case, the community has been yearning for years for a change to a confusing logging behavior when installing
fsevents on Linux. Four PRs in total have been submitted to address this issue:
8 months went by after I submitted my PR (the third one) before it was auto-closed, and another 9 months have gone by since another contributor has re-submitted my PR (the fourth one). In all that time and with much campaigning in the way of upvotes and comments (not to mention the hundreds from the addressed issue) we’ve been unable to attract sufficient attention from maintainers to get the patch reviewed and merged. This is a
+42 −29 patch with tests.
NPM’s CLI, accepting pull requests, appeared as if it would welcome my generous contribution dedicated to Node users’ greater good. Instead, my contribution has been met with much indifference, which I believe to be unwarranted.
The pattern I’ve noticed in both of my experiences has been a lack of concern by npm Inc to communicate with its community in the pursuit of addressing issues together. It’s very discouraging that I have the will to improve this vital component of Node’s ecosystem, but that my labor goes largely unrecognized by the component’s maintainer.
Seeing as the Node.js TSC “is responsible for … a number of projects depended upon by Node.js Core,” I expect this will be a fitting forum to consider the efficacy of npm Inc’s stewardship of the package manager included in Node installations.
Are my observations of neglect isolated, or is there a greater set of cases broad enough to warrant some upheaval? If so, a serious discussion about the management of npm/cli with npm Inc would be warranted. (Can process improvements be implemented for triaging PRs? Can community members be recruited and granted privilege to help?) If management could not be improved, then perhaps stewardship of the CLI ought to pass to Node.js itself. Let this be the beginning of a discussion that may lead to solutions such as these.
Answer questions othiym23
I have a couple brief responses to a few specific points you raise, and then I'll bow out of this discussion.
You seem defeated by the prospect of scaling an open source operation.
If npm Inc is mired in an impenetrable fog of bureaucracy or too strapped for cash to serve the community, then those are also problems that could potentially be solved by reallocation of community resources. (When I say “community resources,” I am not speaking euphemistically of the Node.js org; I am speaking more broadly, thinking of volunteers, and considering the possibility of corporate donations by those who depend on NPM.)
Consider the shading you gave this discussion, because there's a negativity and imputation of bad faith in what is quoted above that is not coming from what I wrote. If you go back and read what I said, I don't think you will find defeatism, nor a sense that the problem is one of bureaucracy.
I don't believe that the problems of managing a popular open source project are, in the end, problems of scale or the correct allocation of resources. The biggest problems are of maintaining consensus and pursuing the correct objectives. Maintaining an orientation is the hardest part of management, and this is especially true when you have a team composed of volunteers who may have very little common purpose aside from solving their own immediate problems or a broad sense of serving the community surrounding a project.
Each additional stakeholder added to a project brings with them their own goals and perspectives. Establishing and preserving consensus grows increasingly untenable as the number of participants grows, and in the absence of consensus, there must be some other means of coming to decisions if a project is to continue making progress. There will always be a core group of people who make the important decisions, and they will inevitably make decisions that displease other stakeholders. This is what it means to not have consensus, especially in the black and white world of OSS discourse, where "disagree and commit" is not really a thing.
I merely took a small sample of bad service from a big package
Your frustration is plain, so in return I will be equally blunt: npm owes you no service. npm's maintainers owe you nothing at all. You offered your contribution, and it was not taken up – any additional interpretation of what happened is simply interpretation, not a record based on actions. There is no contract or obligation, explicit or implied, governing what npm will do with community contributions, and while it would be friendly and helpful if you were given explicit feedback on why things played out the way they did, that is not something to which you, or any other participant in the community, are entitled.