From zero to hero: contributing to open source (2017)(miparnisariblog.wordpress.com)
miparnisariblog.wordpress.com
From zero to hero: contributing to open source (2017)
https://miparnisariblog.wordpress.com/2017/10/31/contributing-to-open-source/
22 comments
> about the NPM ecosystem
"NPM" should be mentioned in thread topic.
"NPM" should be mentioned in thread topic.
This is easily fixable by using tooling to help review. For example I have high hopes in the crev project: https://github.com/crev-dev/crev
As soon as you are no longer implicitly trusting all future versions of your dependencies, things become much more sane.
As soon as you are no longer implicitly trusting all future versions of your dependencies, things become much more sane.
> As soon as you are no longer implicitly trusting all future versions of your dependencies, things become much more sane.
I agree, I wish npm ci and fixed dependencies were the default, but they're not and people need to learn about them.
I agree, I wish npm ci and fixed dependencies were the default, but they're not and people need to learn about them.
Lock files are not enough, you can't review all the dependencies yourself every time you lock. A new tool is needed to deal with trust.
>Now I felt even more excited. I could push fixes and refactors without having to wait for someone to code review them.
Am I the only one feeling uneasy about this?
Am I the only one feeling uneasy about this?
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?
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?
From a security standpoint, how did NPM become a thing? Bar none, it feels like the most compromisable system short of SCADA.
A small Javascript standard library and more demand for packages with the use cases from running it server-side seem to be contributing factors.
For users of the NPM ecosystem this must be as exciting as this bus voyage: https://youtu.be/2WP5HfRt2Us
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.
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.
> Am I the only one feeling uneasy about this?
Why does this make you feel uneasy? Who's to say the original creator of the repo has any better intentions than the author of this article?
Why does this make you feel uneasy? Who's to say the original creator of the repo has any better intentions than the author of this article?
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.
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 am very permissive at giving commit but not release privileges.
I feel that’s the best value for removing blockers to contribution but still retaining some measure of control over security and quality.
I feel that’s the best value for removing blockers to contribution but still retaining some measure of control over security and quality.
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?
Hi, author here. The original author of the repo gave me permissions to push because he didn't have time to maintain it.
Does anybody know of a typescript open source project that's easy to get started on?
hutch120(1)
> 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.