13 ms·

Especially given that Dominic maintains hundreds of packages[1]. He's a good guy and a great developer, and he's always been supportive of others who want to h

Especially given that Dominic maintains hundreds of packages[1]. He's a good guy and a great developer, and he's always been supportive of others who want to help out. When working on Scuttlebutt[2] I got some flak for a change I made and he said this[3]: > I argued against this before, but @christianbundy wanted to do it, so I figured okay do it then. Maybe it is annoying for everyone (in which case christian probably learns for experience) or maybe it turns out to be a good idea! in which case we all do. Either way, shooting down* something someone wants to do (that doesn't have a strong measurable reason) leads to a permission based / authority driven culture. And that isn't what I want. This may make ssb less stable... but I'd rather have less stability but more people who feel like they can work on it / are committed to it. >* "shooting down" is not the same as negotiating a better solution that addresses everyone's needs. I think that's a good thing, plus being good at negotiating is a very good skill. [1]: https://www.npmjs.com/~dominictarr https://www.npmjs.com/~dominictarr [2]: https://scuttlebutt.nz https://scuttlebutt.nz [3]: http://viewer.scuttlebot.io/%25%2B2WIaJ%2BoRVURoTAke9YWuJzp%2FSU%2BhnQtj2lNZ8sAXto%3D.sha256 http://viewer.scuttlebot.io/%25%2B2WIaJ%2BoRVURoTAke9YWuJzp%...

chippy 8y ago
> maintains hundreds of packages Might be worth looking over some of these to see if he has also given access of them to some dodgy people. As most of them appear to be as old as event-stream and are also probably as unused by him. And if we are concerned, we should, he would advise, simply make a fork and write an email to npm to warn them. But hes a good guy, so don't blame him if you find that he's done this before in the other 422 packages. Edits: I mean I do understand having software that's old and unmaintained, and it's fine and easy to hand off control to others - we developers are generally trusting of other developers. I wonder if he has also trusted others in this way before and that he has been exploited before without anyone knowing.
- gregknicholson 8y ago
  > And if we are concerned, we should, he would advise, simply make a fork and write an email to npm to warn them. Well... yeah. If you don't trust him, don't trust him. If you don't trust NPM's vetting, don't trust NPM's vetting.
  - mattdeboard 8y ago
    npm does vetting?
    - cmorgan31 8y ago
      NPM increased their efforts with regards to auditing. They realized it was a prominent attack vector and without them taking responsibility for some level of the problem they would be throwing their reputation down the drain. It isn't perfect, but it's a step to improving the situation.
      - mattdeboard 8y ago
        Sweet! There are so many brilliant & creative people in the Node community. I'm positive there are some innovative ways to approach this problem.
programmarchy 8y ago
Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Dominic's other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. For a successful counter-example, one can look at the well-structured, hierarchical organization behind Linux. Lieutenants gain authority based on the merit of their contributions, and are responsible for reviewing the work of other developers. Authority works, has worked for thousands of years, and will continue to work for thousands more.
- lsc 8y ago
  > Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Maybe, but the sort of people who are not jerks (i.e. who don't get too much pleasure out of having power) who are willing to lead for free are... very rare. Fundamentally, non-commercial open-source needs to evolve organizational methods that require less leadership, just because there aren't a lot of good leaders willing to work for free.
- codetrotter 8y ago
  > other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. Define failure. I don’t know Dominic and I haven’t looked into the Scuttlebutt project beyond being aware of its existence and what it is, but... He talks about creating a community where anyone is welcome to contribute. It is perfectly fine for an open source project to have the development process and the community as its raison d'être. Just because a project doesn’t outcompete every single alternative doesn’t mean it’s failed. Just because a project isn’t even used by more than a handful of people doesn’t mean it’s failed. It all depends on what the goal of the project was in the first place, and what the goal of the contributors are.
  - skore 8y ago
    > He talks about creating a community where anyone is welcome to contribute. Yes and in this case, that was exactly the problem. > It is perfectly fine for an open source project to have the development process and the community as its raison d'être. Conway's law is not an instruction manual.
meowface 8y ago
Handing over a popular software project to a random stranger you've never spoken to who asks to take it over is just irresponsible. Nothing is preventing that stranger from adding malicious code and potentially compromising millions of devices, which is exactly what happened.
- trickstra 8y ago
  exactly, transferring a package to an unknown person is not only giving them access to the code but also to all the people who already trust that code
  - AnaniasAnanas 8y ago
    To be honest that kind of your fault for trusting that code. Heck, the commits were not even signed as far as I know, had they been signed the change of "ownership" would have been clear.
    - meowface 8y ago
      Makes no difference if they were signed or not. He handed over the NPM package, not the GitHub repo. NPM doesn't show commit history or authors and has no connection to GitHub; you can easily have a GitHub repo for your NPM package with benign code in the GH repo and completely different, malicious code in the package.
      - AnaniasAnanas 8y ago
        > not the GitHub repo He did that too actually. > you can easily have a GitHub repo for your NPM package with benign code in the GH repo and completely different, malicious code in the package This is one of the biggest issues that NPM has, along with not enforcing packages to be signed. If the package was signed this would not be an issue as people would see that the signer changed.
- kurtisc 8y ago
  Dominic is the same kind of random stranger to most of the people whose codebases he's in.
gkya 8y ago
> Especially given that Dominic maintains hundreds of packages > maintains hundreds of packages > hundreds How can a single human reasonably and responsably do this? This number alone demonstrates how sloppy and inept the Node.js community's practices are.
- joshmanders 8y ago
  Node people highly follow the single responsibility principle that is prevalent in Linux. By your logic, Linux is sloppy and inept too.
  - faho 8y ago
    It's not. Not to that degree. Unix frequently espouses "do one thing", but how much "one thing" is is always open to interpretation. And it's never been quite as small as e.g. left-pad. It's more something like `printf` or `cat`, which do "print a formatted string" and "concatenate files" as their "one thing", respectively. Let me reiterate: The problem isn't "single responsibility", the problem is "single responsibility for half a thing". The pieces are just too tiny, which leads to an explosion of packages, which leads to packages being badly maintained.
    - gkya 8y ago
      Add to that the fact that while the Unix way works well for connecting certain types of programs through pipelines and/or shell scripts, those programs themselves are written usually in C or Perl, Python &c, which are languages that have big standard libraries. It might be reasonable to assume that while programs that conform to Unix philosophy may constitute useful building blocks for end user or sysadmin tasks, more complex programs, even those "building blocks" themselves are better off with languages that provide them with a rather large, well-though-out toolset that's built as an integrated whole, i.e. a standart library.
    - AgentME 8y ago
      `cat` without any options support is possibly simpler than left-pad. I think the big difference is that very few people set their systems to trust and receive updates of `cat` directly from the developers of `cat` (and same for all the other standard tiny utilities). Instead, they rely on a Linux distribution to vet the developers' code and to regularly pull in updates. Maybe there's room for a similar model of distributions vetting code in the npm ecosystem.

chippy 8y ago

> maintains hundreds of packages Might be worth looking over some of these to see if he has also given access of them to some dodgy people. As most of them appear to be as old as event-stream and are also probably as unused by him. And if we are concerned, we should, he would advise, simply make a fork and write an email to npm to warn them. But hes a good guy, so don't blame him if you find that he's done this before in the other 422 packages. Edits: I mean I do understand having software that's old and unmaintained, and it's fine and easy to hand off control to others - we developers are generally trusting of other developers. I wonder if he has also trusted others in this way before and that he has been exploited before without anyone knowing.

gregknicholson 8y ago
> And if we are concerned, we should, he would advise, simply make a fork and write an email to npm to warn them. Well... yeah. If you don't trust him, don't trust him. If you don't trust NPM's vetting, don't trust NPM's vetting.
- mattdeboard 8y ago
  npm does vetting?
  - cmorgan31 8y ago
    NPM increased their efforts with regards to auditing. They realized it was a prominent attack vector and without them taking responsibility for some level of the problem they would be throwing their reputation down the drain. It isn't perfect, but it's a step to improving the situation.
    - mattdeboard 8y ago
      Sweet! There are so many brilliant & creative people in the Node community. I'm positive there are some innovative ways to approach this problem.

programmarchy 8y ago

Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Dominic's other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. For a successful counter-example, one can look at the well-structured, hierarchical organization behind Linux. Lieutenants gain authority based on the merit of their contributions, and are responsible for reviewing the work of other developers. Authority works, has worked for thousands of years, and will continue to work for thousands more.

lsc 8y ago
> Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Maybe, but the sort of people who are not jerks (i.e. who don't get too much pleasure out of having power) who are willing to lead for free are... very rare. Fundamentally, non-commercial open-source needs to evolve organizational methods that require less leadership, just because there aren't a lot of good leaders willing to work for free.
codetrotter 8y ago
> other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. Define failure. I don’t know Dominic and I haven’t looked into the Scuttlebutt project beyond being aware of its existence and what it is, but... He talks about creating a community where anyone is welcome to contribute. It is perfectly fine for an open source project to have the development process and the community as its raison d'être. Just because a project doesn’t outcompete every single alternative doesn’t mean it’s failed. Just because a project isn’t even used by more than a handful of people doesn’t mean it’s failed. It all depends on what the goal of the project was in the first place, and what the goal of the contributors are.
- skore 8y ago
  > He talks about creating a community where anyone is welcome to contribute. Yes and in this case, that was exactly the problem. > It is perfectly fine for an open source project to have the development process and the community as its raison d'être. Conway's law is not an instruction manual.

meowface 8y ago

Handing over a popular software project to a random stranger you've never spoken to who asks to take it over is just irresponsible. Nothing is preventing that stranger from adding malicious code and potentially compromising millions of devices, which is exactly what happened.

trickstra 8y ago
exactly, transferring a package to an unknown person is not only giving them access to the code but also to all the people who already trust that code
- AnaniasAnanas 8y ago
  To be honest that kind of your fault for trusting that code. Heck, the commits were not even signed as far as I know, had they been signed the change of "ownership" would have been clear.
  - meowface 8y ago
    Makes no difference if they were signed or not. He handed over the NPM package, not the GitHub repo. NPM doesn't show commit history or authors and has no connection to GitHub; you can easily have a GitHub repo for your NPM package with benign code in the GH repo and completely different, malicious code in the package.
    - AnaniasAnanas 8y ago
      > not the GitHub repo He did that too actually. > you can easily have a GitHub repo for your NPM package with benign code in the GH repo and completely different, malicious code in the package This is one of the biggest issues that NPM has, along with not enforcing packages to be signed. If the package was signed this would not be an issue as people would see that the signer changed.
kurtisc 8y ago
Dominic is the same kind of random stranger to most of the people whose codebases he's in.

gkya 8y ago

> Especially given that Dominic maintains hundreds of packages > maintains hundreds of packages > hundreds How can a single human reasonably and responsably do this? This number alone demonstrates how sloppy and inept the Node.js community's practices are.

joshmanders 8y ago
Node people highly follow the single responsibility principle that is prevalent in Linux. By your logic, Linux is sloppy and inept too.
- faho 8y ago
  It's not. Not to that degree. Unix frequently espouses "do one thing", but how much "one thing" is is always open to interpretation. And it's never been quite as small as e.g. left-pad. It's more something like `printf` or `cat`, which do "print a formatted string" and "concatenate files" as their "one thing", respectively. Let me reiterate: The problem isn't "single responsibility", the problem is "single responsibility for half a thing". The pieces are just too tiny, which leads to an explosion of packages, which leads to packages being badly maintained.
  - gkya 8y ago
    Add to that the fact that while the Unix way works well for connecting certain types of programs through pipelines and/or shell scripts, those programs themselves are written usually in C or Perl, Python &c, which are languages that have big standard libraries. It might be reasonable to assume that while programs that conform to Unix philosophy may constitute useful building blocks for end user or sysadmin tasks, more complex programs, even those "building blocks" themselves are better off with languages that provide them with a rather large, well-though-out toolset that's built as an integrated whole, i.e. a standart library.
  - AgentME 8y ago
    `cat` without any options support is possibly simpler than left-pad. I think the big difference is that very few people set their systems to trust and receive updates of `cat` directly from the developers of `cat` (and same for all the other standard tiny utilities). Instead, they rely on a Linux distribution to vet the developers' code and to regularly pull in updates. Maybe there's room for a similar model of distributions vetting code in the npm ecosystem.