Hacker News Reader

Comment by toastercat | Hacker News Reader

The impression I get from the companies I've worked at is to not trust packages that are mostly maintained by one person. Ironically, those packages are usually the ones that don't have outrageously large dependency trees and can usually be audited by a developer on a weekend, and the more "trustworthy" larger packages with hundreds of maintainers typically have monstrous dependency trees.

Not saying 1-man tools are inherently better, but in my experience, these tools seems to have a tighter focus and less chances of scope/dependency creep.

View on HN

Node has a peculiar place in the pantheon for me where there are a few well known individuals who are maintaining a mountain of code that is still mostly theirs even with external contributions coming in.

TJ in particular, before he fucked off, and Sindre Sorhus, who has a little kingdom of tools in the Unix philosophy but more useful than leftpad.

I probably use code from others but those are the only two I am keenly aware of.

When I find an issue with one of the little packages Sorhus publishes, I often need to traverse 3-5 different GitHub repos to understand how the code works. Many times I find it better to copy paste the “base” code into my repo once I find it than continue to use the web of NPM packages.

lukeed is another one I think; I've depended on his packages for years, and have yet to be burnt by one.

I've not heard of him but it looks like I use a few libraries that use his stuff.

>can usually be audited by a developer on a weekend

why are devs expected to do this on a weekend and not just as part of the work week? are we coming from the perspective of the dev working on a side project?

I said "weekend" to communicate a short amount of time; apologies, I don't think anyone should be doing unpaid labor.

I knew what you meant ;)

The big problem with one-person packages isn't so much security as it is support. I have been burned more than once by old applications where key features rely on random packages with one maintainer who disappeared years ago. At least with a group, you have options to keep things moving without having to fork the library yourself.

(Of course the root cause here is arguably too much reliance on third-party dependencies, but searchable dropdowns are _such_ a pain to make on your own, and it's so tempting...)

The Sangria GraphQL library in Scala ran into a version of this. The libraries were primarily maintained by one person, who wrote the vast majority of the code and was the only person with write privileges in the main repos. Sadly, he passed away unexpectedly, and it took months (maybe a year or so) before his colleagues and other contributors were able to get access to the GitHub org.

Well, for what is worth, we have a lot of dependencies maintained by Microsoft of all companies, with lots of production-breaking bugs and they're not too interested in fixing or letting us fix. Even getting fully-functional PRs (with good test coverage and community support) looked at takes a lot of work and time, let alone getting fixes after reporting issues.

One of those packages is a JS package that is hosted by them, so we can't even fork it and host ourselves.

On the other hand, with simple packages that get abandoned, we just fork, publish ourselves with another name or namespaced, and it's solved.

Solo maintainer vs. organization is definitely an imperfect heuristic for long-term support. But it's a decent approximation for dependencies that are low ROI but potentially high impact if they break, like a UI widget that gets used everywhere in your app.

It's the problem with any third-party dependency (ask anyone who's used certain Google products). But then if you build everything in-house, a) it's expensive, and b) you end up with homegrown frameworks written by somebody who left the company five years ago and now everyone is afraid to touch it.

The laws of software thermodynamics come for all of us. Eventually, old systems decay, and you need to roll up your sleeves and do the work to keep them going.

> But it's a decent approximation for dependencies that are low ROI but potentially high impact if they break, like a UI widget that gets used everywhere in your app.

Not really, it's not decent at all. What is a great approximation, however, is the heuristic presented by the grandparent poster: projects that are easy to audit, easy to fork (if necessary) and don't have outrageously large dependency trees. Everything else is a liability.

It's really context dependent.

1-person tools make it easier to audit the person involved, and like you said in general I also find that those tools tend to be smaller and have fewer dependencies, which makes a big difference for security. Limited scope is good when looking at packages/dependencies, and side-projects are kind of required to have limited scope just by virtue of not having a ton of resources.

However, 1-person tools also have less accountability and less bandwidth to respond to emergencies, and (particularly if there aren't a lot of eyes on them), you need to evaluate whether the developer is qualified to build the package -- ie, are they likely to inadvertently introduce a security vulnerability or abandon the package if it needs security updates? People (myself included) have an instinctive bias to assume that 3rd-party code is written by people who know what they're doing. Part of the evaluation process needs to be asking, "does this person actually have the skill to do what they're trying to do?"

I also try to look at how documented the project is -- in an emergency, could I fork the project myself? If a project is being run by only 1 person, then it's more likely that the codebase isn't massive and that it wouldn't require a full team to update. But it's also less likely to be well-documented or extensively tested. Again, balancing act.

I'm not sure there's a single correct answer, I think it depends a lot on the project and on what kinds of packages you're looking at.

Unfortunately, as recent incidents have shown, these many party, otherwise reliable, projects often have dependency chains that have these one person that can have a breakdown projects as dependencies.

Would I ever include left-pad as a direct dependency? No. But as we found out, the person who provided a library that was used by react-dom might.

> The impression I get from the companies I've worked at is to not trust packages that are mostly maintained by one person.

That is hardly the point. Regardless of what you think of the solution presented, the author is utterly right in saying any solution has to involve not trusting any packages at all. How many people wrote the package is irrelevant.

Reply on news.ycombinator.com