Comment by jhardy54 | Hacker News Reader

Comment by jhardy54 | Hacker News Reader

Parent Full thread

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 [2]: https://scuttlebutt.nz [3]: http://viewer.scuttlebot.io/%25%2B2WIaJ%2BoRVURoTAke9YWuJzp%...

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.

> 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.

> 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.

> 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.

The problem was that too few people contributed. A contribution to an open source project doesn't have to be a pull request. Glancing over the code you're pulling down rather than assuming the maintainer is infallible counts just fine. Very, very few people do that in the JS ecosystem though.

When a package gets 2m downloads a day and it still takes 2 and a half months to find a problem, a huge number of developers have failed to do their part.

A security hole and backdoor is always a failure in a software product. Having someone else control your system is just about the worst you can get. It has nothing to do with relative definitions because it always degrades every other objective the project could or does have. If a model of leadership leads naturally and often to security holes, it is time to reconsider the model. If it is a common library, then it is even worse. Open source that is used widely is _even_ more important to protect because the impact can be so much greater.

I don’t know, if I write open source software, the only definition of success I use is whether or not I had any fun writing it.

Anything else is gravy.

Lots of projects, including windows and linux have had security holes that allow remote control of your system. Security flaw does not mean failure, its always about weighing the cost of security flaws against the utility the software provides. Even a completely compromised system can provide utility to many users.

This sounds like "if it's not perfect, it's a failure."

I'm actually not aware of a single piece of software that didn't at some point have a production security vulnerability.

Facebook failed.

Google failed.

Amazon failed.

Linux has a giant user base, a giant installation base, and a giant pool of talented devs willing to take on unpaid work.

If this is an indictment of anything, it's an indictment of the entire NPM ecosystem -- it's been the wild wild west for years; haphazardly using whatever NPM install gives you is baked into the culture.

Sure, Dominic is an active participant in that culture but it seems to me that it is impossible to have a largely unmoderated volunteer system with as many packages are actively used without things like this happening.

Keep in mind, this is a case where the system worked, more or less -- an observant user caught the issue, and made a public issue of it. Who knows how many packages have slipped by like this?

> Linux has a giant user base, a giant installation base, and a giant pool of talented devs willing to take on unpaid work.

And also important: It even has a giant number of paid maintainers, for who this is their main job.

For those the incentive to continuously maintain things is different than for someone who gets nothing expect more work out of it.

> Linux has a giant user base, a giant installation base, and a giant pool of talented devs willing to take on unpaid work.

Linux didn't always have a giant user base, and it wouldn't have gotten there without strong leadership having a sense of pride and responsibility.

I'm curious if anyone knows how it really has developed. Has anyone documented the history? Do I understand correctly that right now it's a hierarchy with Linus at the top and levels of "Lieutenants" managing increasingly more detailed levels of subsystems. How was development organized before? Are the developers that are paid mostly on the top or the bottom of the hierarchy? Are the proportions of paid developers very distributed among different companies or does a major portion of them belong to one company?

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things)."

I would rather see it as if contributors gain _trust_ based on their contributions, which is not necessarily the same as authority.

If a contributor's end goal is to publish a backdoor, then making them wait 0 or 100 commits to the project before trusting them doesn't change the end result.

In fact, if you had the energy to do the attack at all here (which took some work), having to fake trustworthiness doesn't require much more effort. Just look like a super enthusiastic contributor, put work into the readme, bike-shed over some issues every month, and bam.

> Lieutenants gain authority based on the merit of their contributions

Meritocracy is an outdated discriminatory practice.

https://postmeritocracy.org/

https://www.theguardian.com/commentisfree/2017/mar/20/merito...

To be clear, you're arguing that people should be judged on their identity and background rather than the merit of their contributions?

You are feeding a troll. Please don't.

Skimming those links, I think the position is that people are already being judged on their identities before they're judged on the merit of their contributions, not that they should be.

The extent and congruence of the findings regarding, e.g., blinded vs non-blinded resumes alone should put the lie to the idea that a true "meritocracy" is something humans can actually meaningfully do at this point.

That's a contrived "no true Scotsman" right there. Also quite a few people argued that democracy should be replaced by dictatorship on similar grounds: "look at America, it's clear that democracy is shit".

Imperfect realization doesn't mean the ideal is invalid (except when that imperfection is inherent to the ideal). You can argue for more equal, more meritocratic community; tearing it down because it's not already perfect is disingenuous and destructive.

> Meritocracy is an outdated discriminatory practice.

Of course merit is judged subjectively (like anything else), but what exactly is the alternative?

In particular, I don't find anything actionable in that manifesto in regards to decision making.

Is there a showcase of open-source projects managed/developed according to this post-meritocratic system?

> that doesn't have a strong measurable reason

I think that's the key here - organization/hierarchy is important as a project scales up, but he didn't want to stifle a new contribution without good reason.

But in the absence of a trusted, well-structured organization, authority rests on the shoulders of those using the library as a dependency.

Scuttlebutt already works, people use it and are building on it.

What happened is that Dominic gave ownership to the only person who wanted it: "he emailed me and said he wanted to maintain the module, so I gave it to him. I don't get any thing from maintaining this module, and I don't even use it anymore, and havn't for years." At every single point, there was authority and responsibility. It is just that authority turned out to be bad actor.

It was situation where former authority was not interested in being authority anymore, since former authority gained nothing from it and had other work.

> 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.

> 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.

npm does vetting?

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.

Sweet! There are so many brilliant & creative people in the Node community. I'm positive there are some innovative ways to approach this problem.

> 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.

Node people highly follow the single responsibility principle that is prevalent in Linux. By your logic, Linux is sloppy and inept too.

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.

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.

`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.

Do you really think cat is as simple as left-pad?

https://github.com/freebsd/freebsd/blob/master/bin/cat/cat.c

Also, cat is kind of an important primitive for building a functional system that uses files as one of its core abstractions. It makes total sense that it would (a) exist and (b) be well maintained by an authoritative and reliable source.

Left pad it is not.

> `cat` without any options

Interestingly, the `raw_cat()` function is 37 lines long.

https://github.com/freebsd/freebsd/blob/e511976db9f51bae1a59...

UNIX `cat`, unchanged from V2 through V6 until it was rewritten in V7, was 44 instructions.

The core utilities are provided as a suite. The cat utility is one of a hundred others, all packaged together. Even without distributions, you'd only need to vet one organization for those basic utilities.

I don't follow your comparison. What parts of the Linux ecosystem have a single person maintaining a large multitude of packages?

Looking at the kernel itself you see a hierarchy where people are only responsible for small segments of the kernel.

Looking at a standard distro like Debian, which makes this easily available at https://www.debian.org/devel/people you'll see that most individuals are only responsible for a handfull of packages, with the bulk having a team responsible for them.

I think with "single responsibility" he means the packages. So instead of complex packages that are hard to maintain they have lots of smaller packages that are easier to maintain. So a single person can maintain several packages.

Not saying that I think maintaining hundreds sounds like a good idea, just trying to point out the misunderstanding :) .

NPM packages are frequently tiny, single-purpose functions. The infamous left-pad module is only 47 lines of code. https://github.com/stevemao/left-pad/blob/master/index.js

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.

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

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.

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.

> 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.

Dominic is the same kind of random stranger to most of the people whose codebases he's in.

Sure but he earned the trust of the community by building everything he did. It took times and effort, unlike that other strangers, which does give more credence to what he does.

Sadly he didn't deserved that trust.

Explain how you would be able to evaluate the trustworthiness of a person asking to transfer ownership to.

If you can't evaluate the trustworthiness who you're handing the package over to, just don't hand it over. Mark it as deprecated and call it a day. This is Open Source 101.

GitHub has a Read Only option, and package managers of most languages have a way to convey that the project is abandoned or provided security fixes only.

You don't have to feel guilty to abandon the projects. Most us do it, every day.

At the very least, a few years of regularly contributing to Node projects on GitHub. The account he handed it over to has essentially zero history: https://github.com/right9ctrl. The one repo they have is just a copy of https://github.com/barrysteyn/node-scrypt.

I'm not against handing over projects, but some vetting has to be done.

Actually, it's not as hard as you make it sound:

1. - don't transfer - mark your repo Abandoned, tell people to use that other person's fork if you have to 2. - does that person have any other online presence? Long running? 3. - does he also put his face in front of the crowd? Talk at conferences?

This creates accountability - someone like that wouldn't pull out the same kind of injection, because he could be caught for that and his "brand" would be destroyed.

This is a reasonable response. I'm not sure why you're down voted but I gave you a up vote.

Have you ever created a package that people started to use, which you then had to maintain for purposes that didn't do anything for you and then no longer even need the package? Pretty much any rando offering to take over maintenance is going to be welcome to it compared to the dozens of requests and insults offered as bug reports.

Yes, I am in this situation right now, actually. I have a project with around 700 stars on GitHub with over a million downloads per month (according to PyPI) which I no longer have the time, interest, or willpower to continue maintaining.

I placed an open call to find a new maintainer months ago, and have received many requests. Every single request I've received has been roughly as shady as the request sent to event-stream. I've declined them all due to their shadiness. I know exactly what could happen (this situation right here) if I give it to the wrong person.

This is good maintainership right here!

For outsiders, it looks like the maintainer is greedy to keep the project to themselves. The bug reports pile up, and dozens of people are offerring to maintain. And then insults start to come up, because it looks like you don't want to hand it over.

If you want to take over a project, you just earn the trust if the current maintainer, be it patches for existing PRs, finding security vuons, etc over the time. Linux has gotten this right.

Thank you. Exactly.

Reply on news.ycombinator.com