I'll preface this by saying that I have nothing against the author, I'm just trying to make a point about the NPM ecosystem and chain supply attacks .
> The problems seemed easily solvable and would require some moderate amount of work.
> When that got merged, suprise! I was made a project contributor.
> Now I felt even more excited. I could push fixes and refactors without having to wait for someone to code review them.
Think about this, and then think about your dependencies. How easy it is to pay a few people full time to contribute to the edges of the NPM ecosystem (deep dependencies, forgotten dependencies) to then slowly take control over some packages? Every result that's shown with "npm fund" is a potential target. Famously, Express was sold to a company (though this wasn't for chain supply attacks, but for clout I think?).
Of course that's also the good part of open source NPM-style: in some places there isn't much red tape. But I'm wondering if companies should rely on processes like that. That seem dangerous.
Yes and no. Open source is built on trust, something we're starting to feel the backsides of today, where npm modules sometimes gets compromised, but people also get shared responsibility over shared resources like reusable libraries.
I'm torn if it's good or bad really. I feel like our tools should do more to protect us, but until we get there, maybe we do need to be more careful with who we're giving our trust to?
There is a lot of unmaintained code out there. When somebody steps up and starts doing meaningful work to fix that, stepping out of the way and letting them do their thing is a very appropriate way to get the changes out to users.
Ultimately open source is based on trust. Code reviews are nice if you can get them but github is full of projects with pull requests that aren't getting reviewed. That's frustrating for contributors and users.
I tend to feel bad when somebody submits a pull request to one of my projects and I don't have time to properly review it. It happens sometimes. But I tend to bias towards merging the work unless I see something really wrong with such pull requests in which case, I'll inform the contributor. Ultimately, OSS should be a meritocracy. People doing the work gain power and trust. Nothing wrong with that.
It shows that the author is unconcerned about code quality in someone else's project.
But you are right that the original project had the same problem of lack of review. This is a big problem in sole author open source; such projects tend to be poorly documented, have a lot of nasty code that is error prone and hard to maintain and continued fixes to. I know this from bugfix commits I've made to various project.
I'm not arguing to have code reviews for every commit (or PR). If there's no review with each incremental change, is it still feasible to review at release time?
> The problems seemed easily solvable and would require some moderate amount of work.
> When that got merged, suprise! I was made a project contributor.
> Now I felt even more excited. I could push fixes and refactors without having to wait for someone to code review them.
Think about this, and then think about your dependencies. How easy it is to pay a few people full time to contribute to the edges of the NPM ecosystem (deep dependencies, forgotten dependencies) to then slowly take control over some packages? Every result that's shown with "npm fund" is a potential target. Famously, Express was sold to a company (though this wasn't for chain supply attacks, but for clout I think?).
Of course that's also the good part of open source NPM-style: in some places there isn't much red tape. But I'm wondering if companies should rely on processes like that. That seem dangerous.