I feel like there's a lot of misunderstanding of this issue in the software community, because primarily, supply chain risk isn't a software or engineering issue. It's a governance issue.
Someone doesn't have to be a bad actor for a project to have supply chain risk. Nor do all who evaluate supply chain risk have the same security posture and evaluate risks the same as others might. The DoD likely has a very different set of risks they evaluate against for their security posture than you do.
Most supply chain risks are not an indictment of somebody's code or somebody's character. A lot of one person projects are risky just because they're only one person. Having a bus factor of one is a supply chain risk in and of itself.
And while most people don't prepare for war while choosing their packages, it's not unreasonable for a military to do so. During a war, the ability for people to govern themselves and their own projects often changes dramatically, even in democratic countries. It is entirely routine for countries to require cooperation by the force of law in war time, even the US can and has forced private companies to cooperate with war efforts. This is probably not in the security posture calculation for most of us. But it is for some.
> And while most people don't prepare for war while choosing their packages, it's not unreasonable for a military to do so. During a war, the ability for people to govern themselves and their own projects often changes dramatically, even in democratic countries. It is entirely routine for countries to require cooperation by the force of law in war time, even the US can and has forced private companies to cooperate with war efforts. This is probably not in the security posture calculation for most of us. But it is for some.
Reading this I'm really hoping the DOD maintains mirrors of GitHub projects that are vital to them.
Still, we had a lot of security issues of people injecting themselves into these one-man projects.
It is ridiculous to force these people to do anything because you were to lazy to build the foundations of your infrastructure yourself, especially if you care about self-reliance.
Huh? The DoD would not have used the package if they hadn't read every line, locked it down for updates, and were ready to patch it themselves if needed. Can you really imagine in a war they'd be like "damn, if only there were a second person we also don't trust at all to do this work for us cause otherwise we'd just be SOL"
> So while NPM has over 4 million single person projects, they have about 900,000 maintainers for those 4 million single person projects. This will be an important data point at the end.
Am I missing something or was it not, in fact, an important data point at the end?
I didn't see it explicitly stated, but I think it supports the "overworked" part of this statement:
> Open source, the thing that drives the world, the thing Harvard says has an economic value of 8.8 trillion dollars (also a big number). Most of it is one person. And I can promise you not one of those single person projects have the proper amount of resources they need. If you want to talk about possible risks to your supply chain, a single maintainer that’s grossly underpaid and overworked. That’s the risk. The country they are from is irrelevant.
Has anyone seen any stats on what happens to a single maintainer project when said person is hit by a bus (or meets some other demise)? With that many data points, there should be enough of them by now to study it.
Is the project taken over by another, single developer? Is it replaced by a similar project? Does it just go away?
It depends. More common than getting hit by a bus is that the maintainer loses interest, or doesn't have the time to put into it anymore. When that happens I've seen all of the following happen:
* Someone forks the project, and eventually the fork replaces the original
* Another, possibly new, project that fills the same niche becomes more popular, and eventually replaces most usages of the first project.
* The original maintainer hands off maintenance to someone else.
* People keep using it, even though it is no longer maintained, and maybe make their own forks to fix issues they have, but none of the forks really catch on
One of the strengths of OSS is that if the developer disappears, or goes rogue, or changes the license terms, someone can fork the project and keep it going. With proprietary software, if the company (or individual) who makes it disappears, or decides to discontinue it, or change the terms to something unacceptable, you are just out of luck. Hopefully, you can find a competing product that meets your needs.
I would love to see a diligently researched episodic series, every episode covering the transition of a popular open-source library/tool/app/site from one maintainer to the next.
I bought ASIO Link Pro (software) something like 10 years ago to help route virtual audio devices on my system. The author sadly died and eventually the license key server went offline rendering it unable to start. His nephew looked into it and eventually made the tool free after a year or 2.
I stopped using it after the license server went offline because I still had to record videos. I ended up solving my problem with hardware, but that tool was extremely helpful when I used it for years. It was around $40 at the time. It's one of the few pieces of software I've purchased and felt really happy about it.
Closest example I could think of would be Hans Reiser/Reiserfs. It's a more sordid story than just getting hit by a bus, though. Ultimately the project just died.
I don't know about any broader statistics, but in my personal experience, I see all three of those. I think it's mostly a function of how large the user base is, how complicated the code base is, and whether or not there are any substitutes.
I think this is one thing that people fail to consider: if the code is open source, though it may take time to understand, worst case scenario you can just fork it.
- Hans Reiser, maintainer of ReiserFS. I think very few people use ReiserFS these days.
- Ian Murdock, creator of the Debian distribution. Debian lives on, but the project was also set up specifically to distribute maintenance.
- Jim Weirich, creator of the Rake build tool. I'm not a Rubyist so I don't know how it was affected, but I assume it's such a big part of Ruby other people took over.
- Peter Hintjens, co-creator of ZeroMQ. From what I understand, Hintjens was never the main developer but an active promoter. The project lives on as far as I know.
- Terry Davis, creator of TempleOS. I think development on TempleOS stopped.
The DOD is one of the world's largest organizations. There are people there who do things like publish newsletters and put up webpages for people like boy scouts to arrange tour bases. It is totally fine to use Node for things like that.
Those systems are not connected to the systems that fire missiles. If the sign up page for the 4th of July fireworks announcement gets vandalized, it isn't really an issue.
The DoD is very efficient at finding something they are getting for free and convincing everyone it's in their best interest to pay a team of contractors for it.
I've heard good things about work done by this guy Linus. I'm pretty sure that I've used his work.
I think he comes from a country that borders Russia, so should we be worried?
I've done OSS for decades; mostly by myself, but sometimes, in teams of volunteers.
If anyone has any experience, working in teams of volunteers, it can be ... challenging.
It can definitely work, but not as often as you'd think. If it works, there's usually some "BDFL," or a common goal that has everyone on the same beam. In my case, it was usually the latter.
Not only that, but Linus's parents were politically active communists and young Linus was a pioneer (like a boy scout but for communists). His father also lived in Moscow for several years on two separate occasions.
After reading. For a person that calls out how people are not smart the author takes quite of mental shortcuts to make his point work.
NPM downloads are not equal to amount of projects as people plug in their CI/CD to download package on each build.
Then assuming just by sheer number that there must be something critical in the set or at least super important. Without putting effort to track at least one in some way.
That’s at least lazy especially if you call people „smart”. Then throw up some numbers thinking you’re the smart one.
Too bad the notion of completed/finished/done software is very weak. In theory, there it nothing wrong with an OSS project made by one person.
I would like to see the LOC these one-person projects with >1M downloads have. I suspect most of these are a simple Node/browser/OS API single-file wrappers that are simple to get right and treat it as complete.
At the same time such projects are easy to verify upon adding as dependency. Lately, I've just copy-pasted relevant parts of a library to my project because adding it as a dependency has a cost. I doubt this is a common practice though, especially in NPM land.
> Too bad the notion of completed/finished/done software is very weak.
FWLIW, this simple definition suffices for me: software is complete insofar as it requires no changes to do what its maintainers would like to do with it at the current point in time.
"Complete" software frequently changes to "incomplete" as the desires of the maintainer(s) change(s), and may just as quickly revert to "complete" as changes are made.
This definition does not consider the desires of non-maintainers because there's _always_ at least one such person who wants a given pieces of software to do their one weird thing (which the maintainer(s) will not ever add).
I think it can go both ways... I've definitely copied code into a project more than once. I've also directly written the following line of code into a lot of places, just because of import overhead and convenience when needed.
const sleep = (ms) => new Promise(r => setTimeout(r, ms));
I also with push for just straight SVG with JSX instead of the massive charting libraries everyone seems to bring in... similar when I seem moment.js ... I don't know why more people don't generate/refer to the resource usage outputs. If anything comes close to the base React or MUI libraries, it gets yanked if at all possible. Or at LEAST load it async and only where necessary.
I wonder. A lot of single person GitHub projects are just people’s “hello world” or other personal experiments. Single file webserver written without “if statements” or other absurdity.
It's interesting to see the periodic rediscovery of "capitalism + technology relies on unpaid, voluntary labour", or as the author puts it, "Open source, the thing that drives the world, the thing Harvard says has an economic value of 8.8 trillion dollars".
The one flaw that I see in the author's analysis though is that they don't seem to account for whether the packages accounted for by their source have dependents or monthly downloads. There's *a lot* of dead code out there. When excluding abandoned packages, I bet the picture is still grim, but it might be less so.
> capitalism + technology relies on unpaid, voluntary labour
You are falling into the breadtube trap of faulting capitalism for a societal issue that has nothing to do with it. Did capitalism force people to have productive hobbies? Would you prefer a system, other than capitalism, that prevented people from having productive hobbies?
Often times this error relies on the assumption that capitalism is what's preventing us from having an "idealized" version of communism that I've heard aptly described as Gay Luxury Space Communism, where anyone can do anything they want and society just magically pays for it. The problem is that GLSC isn't real, we'd need ~infinite resources to do it.
I personally blame this problem on charities. This is the type of problem that charities and foundations should solve but there is no safeguard for charity money actually going to the charity's cause of action, instead the moment you create any kind of non profit it transforms into Non Profit (inc) and all the money it received goes to (1) professional non-profit people for the job of raising money and redistributing it, (2) shuffled to other non-profits, (3) thinly disguised political activism.
You can frame the "unpaid voluntary labor" as "creative work" and it would start making a whole lot of sense. "Creative work thrives despite being unpaid in capitalist society."
that and, i would argue that npm in particular is filled with lots of small projects and only very few large ones simply by the nature of the ecosystem. it is the wrong place to look. something better would probably be to eg count the contributors on github, or, on npm, analyze project dependencies and distinguish projects that are directly downloaded vs those that are loaded as a dependency. arguably, dependencies can be replaced by the developers of the project using it, so a developer of a dependency disappearing is less dramatic than if you use that project directly.
technically speaking, if you have a large project with many contributors, every contributor is often still only responsible for one small part of the project. linux kernel drivers and subsystems most have their dedicated developers. and very few of them each.
Reminds me of what was it... Heartbleed? Then everyone realized its a library mostly maintained by one underfunded developer? Critical piece of software, underfunded.
Most the stuff on github is something one person wrote, stuck on there, and nobody uses. Then there's a bunch of things that are one person, but some small number of people use or have used it. Most big OSS programs have more than one person behind them. The vulnerable things tend to be dependencies of larger projects - small, but useful enough to get used in larger things.
Just FYI: I got a modal in Chrome asking "Did you mean opensource.google? Attackers sometimes mimic sites by making hard-to-see changes to the web address."
I'm sure there's nothing you can do about it, but thought you might want to know.
They stopped before looking at the number of commits by person in the projects with multiple maintainers. I would guess that makes the picture even bleaker.
The visualisations could be improved by binning number of maintainer 1 / 2-10 / 11-n or by plotting cumulative distribution (ie. x% of projects have less than y contributors)
Even that would be mis-representative... I know of many packages with contributions from hundreds of people, but the bulk of the work was still 1 or 2 primary maintainers based on commits.
I can see how the article seemed like an advertisement for Hunted Labs. I have talked to them and it’s a good product especially if you care about where you are getting your software from as part of a supply chain analysis.
The title of the register article is completely disgusting
> Putin on the code: DoD reportedly relies on utility written by Russian dev
then in the article:
> Hunted Labs told us that it didn't speak to Malinochkin prior to publication of its report today, and that it found no ties between him and any threat actor.
Yeah, it is pretty amazing but not surprising. The Register has taken to a certain kind of sensationalism as of late.
I found this interesting:
> "Every piece of code written by Russians isn't automatically suspect, but popular packages with no external oversight are ripe for the taking by state or state-backed actors looking to further their aims," Smith told us in an email. "As a whole, the open source community should be paying more attention to this risk and mitigating it."
Uh, I guess? The nature of open source is supposed to be that the dev provides the effort and the code, and that's where the guarantee stops. It is up to the people who uses it to implement and ensure security. People treat OSS like it is a business product that must have drop-in replacement ready at all times.
The modern nature of development is perhaps my biggest gripe as a professional. There is little care given. Projects begin with importing dozens of other packages and libraries that we never look at, let alone fully understand. And it is normalized.
"Open source, the thing that drives the world, the thing Harvard says has an economic value of 8.8 trillion dollars (also a big number)."
Yeah, but the maintainer almost never sees anything from it. And most of the people cannot monetize oss based projects, because they don't have the expertise for it.
OSS is the biggest farce ever. Same when people say patents are evil. Ridiculous. A handful of people spoon fed this universal bullshite to people and they believed it.
Remember people that proper governments plan tens of years ahead. In this context, OSS was first, so AI systems would have ample source code to be trained on.
the west or those with largely liberal viewpoints who think in black and white vs seeing the world as grey are gonna cost the west a lot.
we already saw this - with 'cancel' mafia.
because russia or i.e putin invaded ukraine doesn't mean the whole russia is bad. or you shouldn't interact with russia at all. no one stopped interacting with usa after they invaded iraq.
just because russia doesn't give a shit about lgbtq rights doesn't mean russia is a bad country. likewise just because china runs an explicit authoritarian system - it doesn't mean its a country - china bad.
trump and his idiotic gvt kinda recognize this - but they're also doing it the wrong way.
anyways - trade with enemies / friends alike as long as they're benefits to be realized.
Another case of power law distribution being all around us. I wonder how many commits of the 1M+ downloads projects maintained by more than one person, were done by just one person?
kube-system|6 months ago
Someone doesn't have to be a bad actor for a project to have supply chain risk. Nor do all who evaluate supply chain risk have the same security posture and evaluate risks the same as others might. The DoD likely has a very different set of risks they evaluate against for their security posture than you do.
Most supply chain risks are not an indictment of somebody's code or somebody's character. A lot of one person projects are risky just because they're only one person. Having a bus factor of one is a supply chain risk in and of itself.
And while most people don't prepare for war while choosing their packages, it's not unreasonable for a military to do so. During a war, the ability for people to govern themselves and their own projects often changes dramatically, even in democratic countries. It is entirely routine for countries to require cooperation by the force of law in war time, even the US can and has forced private companies to cooperate with war efforts. This is probably not in the security posture calculation for most of us. But it is for some.
const_cast|6 months ago
ozim|6 months ago
giancarlostoro|6 months ago
Reading this I'm really hoping the DOD maintains mirrors of GitHub projects that are vital to them.
raxxorraxor|6 months ago
It is ridiculous to force these people to do anything because you were to lazy to build the foundations of your infrastructure yourself, especially if you care about self-reliance.
conartist6|6 months ago
aniviacat|6 months ago
Am I missing something or was it not, in fact, an important data point at the end?
gamerdonkey|6 months ago
> Open source, the thing that drives the world, the thing Harvard says has an economic value of 8.8 trillion dollars (also a big number). Most of it is one person. And I can promise you not one of those single person projects have the proper amount of resources they need. If you want to talk about possible risks to your supply chain, a single maintainer that’s grossly underpaid and overworked. That’s the risk. The country they are from is irrelevant.
didgetmaster|6 months ago
Is the project taken over by another, single developer? Is it replaced by a similar project? Does it just go away?
thayne|6 months ago
* Someone forks the project, and eventually the fork replaces the original
* Another, possibly new, project that fills the same niche becomes more popular, and eventually replaces most usages of the first project.
* The original maintainer hands off maintenance to someone else.
* People keep using it, even though it is no longer maintained, and maybe make their own forks to fix issues they have, but none of the forks really catch on
One of the strengths of OSS is that if the developer disappears, or goes rogue, or changes the license terms, someone can fork the project and keep it going. With proprietary software, if the company (or individual) who makes it disappears, or decides to discontinue it, or change the terms to something unacceptable, you are just out of luck. Hopefully, you can find a competing product that meets your needs.
gausswho|6 months ago
And that's why I don't run Netflix.
nickjj|6 months ago
I bought ASIO Link Pro (software) something like 10 years ago to help route virtual audio devices on my system. The author sadly died and eventually the license key server went offline rendering it unable to start. His nephew looked into it and eventually made the tool free after a year or 2.
I stopped using it after the license server went offline because I still had to record videos. I ended up solving my problem with hardware, but that tool was extremely helpful when I used it for years. It was around $40 at the time. It's one of the few pieces of software I've purchased and felt really happy about it.
ashleyn|6 months ago
kube-system|6 months ago
rglover|6 months ago
kqr|6 months ago
- Hans Reiser, maintainer of ReiserFS. I think very few people use ReiserFS these days.
- Ian Murdock, creator of the Debian distribution. Debian lives on, but the project was also set up specifically to distribute maintenance.
- Jim Weirich, creator of the Rake build tool. I'm not a Rubyist so I don't know how it was affected, but I assume it's such a big part of Ruby other people took over.
- Peter Hintjens, co-creator of ZeroMQ. From what I understand, Hintjens was never the main developer but an active promoter. The project lives on as far as I know.
- Terry Davis, creator of TempleOS. I think development on TempleOS stopped.
popalchemist|6 months ago
jampa|6 months ago
If there is a major change (e.g., Python 3, React Native new arch), they are replaced/forked.
qn9n|6 months ago
blueflow|6 months ago
ysofunny|6 months ago
updating is a systemic issue, not a per-project matter
gsliepen|6 months ago
joshdavham|6 months ago
[0] https://github.com/11ty/eleventy/graphs/contributors
andersmurphy|6 months ago
I might be wrong but npm etc feels like a very large attack surface.
dghlsakjg|6 months ago
The DOD is one of the world's largest organizations. There are people there who do things like publish newsletters and put up webpages for people like boy scouts to arrange tour bases. It is totally fine to use Node for things like that.
Those systems are not connected to the systems that fire missiles. If the sign up page for the 4th of July fireworks announcement gets vandalized, it isn't really an issue.
lantry|6 months ago
unknown|6 months ago
[deleted]
hermannj314|6 months ago
kube-system|6 months ago
ChrisMarshallNY|6 months ago
I think he comes from a country that borders Russia, so should we be worried?
I've done OSS for decades; mostly by myself, but sometimes, in teams of volunteers.
If anyone has any experience, working in teams of volunteers, it can be ... challenging.
It can definitely work, but not as often as you'd think. If it works, there's usually some "BDFL," or a common goal that has everyone on the same beam. In my case, it was usually the latter.
tarvaina|6 months ago
Not only that, but Linus's parents were politically active communists and young Linus was a pioneer (like a boy scout but for communists). His father also lived in Moscow for several years on two separate occasions.
moktonar|6 months ago
kube-system|6 months ago
unknown|6 months ago
[deleted]
andai|6 months ago
Which one is that?
ozim|6 months ago
NPM downloads are not equal to amount of projects as people plug in their CI/CD to download package on each build.
Then assuming just by sheer number that there must be something critical in the set or at least super important. Without putting effort to track at least one in some way.
That’s at least lazy especially if you call people „smart”. Then throw up some numbers thinking you’re the smart one.
ivanjermakov|6 months ago
I would like to see the LOC these one-person projects with >1M downloads have. I suspect most of these are a simple Node/browser/OS API single-file wrappers that are simple to get right and treat it as complete.
At the same time such projects are easy to verify upon adding as dependency. Lately, I've just copy-pasted relevant parts of a library to my project because adding it as a dependency has a cost. I doubt this is a common practice though, especially in NPM land.
sgbeal|6 months ago
FWLIW, this simple definition suffices for me: software is complete insofar as it requires no changes to do what its maintainers would like to do with it at the current point in time.
"Complete" software frequently changes to "incomplete" as the desires of the maintainer(s) change(s), and may just as quickly revert to "complete" as changes are made.
This definition does not consider the desires of non-maintainers because there's _always_ at least one such person who wants a given pieces of software to do their one weird thing (which the maintainer(s) will not ever add).
tracker1|6 months ago
BirAdam|6 months ago
BobbyTables2|6 months ago
Not sure about NPM but a lot of PyPI projects are likely similar. Just now I hit “browse projects” and got this: https://pypi.org/project/helloworld-eduardo/
Nobody even extremely drunk would even think of using that stuff in a product…
speakingmoistly|6 months ago
It's interesting to see the periodic rediscovery of "capitalism + technology relies on unpaid, voluntary labour", or as the author puts it, "Open source, the thing that drives the world, the thing Harvard says has an economic value of 8.8 trillion dollars".
The one flaw that I see in the author's analysis though is that they don't seem to account for whether the packages accounted for by their source have dependents or monthly downloads. There's *a lot* of dead code out there. When excluding abandoned packages, I bet the picture is still grim, but it might be less so.
EdiX|6 months ago
You are falling into the breadtube trap of faulting capitalism for a societal issue that has nothing to do with it. Did capitalism force people to have productive hobbies? Would you prefer a system, other than capitalism, that prevented people from having productive hobbies?
Often times this error relies on the assumption that capitalism is what's preventing us from having an "idealized" version of communism that I've heard aptly described as Gay Luxury Space Communism, where anyone can do anything they want and society just magically pays for it. The problem is that GLSC isn't real, we'd need ~infinite resources to do it.
I personally blame this problem on charities. This is the type of problem that charities and foundations should solve but there is no safeguard for charity money actually going to the charity's cause of action, instead the moment you create any kind of non profit it transforms into Non Profit (inc) and all the money it received goes to (1) professional non-profit people for the job of raising money and redistributing it, (2) shuffled to other non-profits, (3) thinly disguised political activism.
sorrythanks|6 months ago
> So now, let’s look at the number of maintainers for projects with over 1 million downloads this month.
thisoneworks|6 months ago
socalgal2|6 months ago
vitonsky|6 months ago
It looks they consider as maintainer only those people who listed on package.json, not a real number of contributors on github or anything.
So all conclusions in this post is based on wrong assumption and incorrect data interpretation. That's all you need to know about it.
I think you could list random people on github in your package.json to looks cool in eyes of stats cultists.
em-bee|6 months ago
technically speaking, if you have a large project with many contributors, every contributor is often still only responsible for one small part of the project. linux kernel drivers and subsystems most have their dedicated developers. and very few of them each.
msgodel|6 months ago
Maintainers are the ones responsible in the end for the state of the repo while contributors suggest changes.
giancarlostoro|6 months ago
phkahler|6 months ago
unknown|6 months ago
[deleted]
johneth|6 months ago
I'm sure there's nothing you can do about it, but thought you might want to know.
voidmain|6 months ago
mathisd|6 months ago
tracker1|6 months ago
andai|6 months ago
mikeytown2|6 months ago
firesteelrain|6 months ago
pabs3|6 months ago
> "This serves as another powerful reminder that knowing who writes your code is just as critical as understanding what the code does"
If who wrote some code matters to you, then your supply chain management is simply insufficient.
poulpy123|6 months ago
> Putin on the code: DoD reportedly relies on utility written by Russian dev
then in the article:
> Hunted Labs told us that it didn't speak to Malinochkin prior to publication of its report today, and that it found no ties between him and any threat actor.
shark1|6 months ago
actionfromafar|6 months ago
aurareturn|6 months ago
weirdpickles|6 months ago
I found this interesting:
> "Every piece of code written by Russians isn't automatically suspect, but popular packages with no external oversight are ripe for the taking by state or state-backed actors looking to further their aims," Smith told us in an email. "As a whole, the open source community should be paying more attention to this risk and mitigating it."
Uh, I guess? The nature of open source is supposed to be that the dev provides the effort and the code, and that's where the guarantee stops. It is up to the people who uses it to implement and ensure security. People treat OSS like it is a business product that must have drop-in replacement ready at all times.
The modern nature of development is perhaps my biggest gripe as a professional. There is little care given. Projects begin with importing dozens of other packages and libraries that we never look at, let alone fully understand. And it is normalized.
lofaszvanitt|6 months ago
Yeah, but the maintainer almost never sees anything from it. And most of the people cannot monetize oss based projects, because they don't have the expertise for it.
OSS is the biggest farce ever. Same when people say patents are evil. Ridiculous. A handful of people spoon fed this universal bullshite to people and they believed it.
Remember people that proper governments plan tens of years ahead. In this context, OSS was first, so AI systems would have ample source code to be trained on.
dzonga|6 months ago
we already saw this - with 'cancel' mafia.
because russia or i.e putin invaded ukraine doesn't mean the whole russia is bad. or you shouldn't interact with russia at all. no one stopped interacting with usa after they invaded iraq.
just because russia doesn't give a shit about lgbtq rights doesn't mean russia is a bad country. likewise just because china runs an explicit authoritarian system - it doesn't mean its a country - china bad.
trump and his idiotic gvt kinda recognize this - but they're also doing it the wrong way.
anyways - trade with enemies / friends alike as long as they're benefits to be realized.
lern_too_spel|6 months ago
axelpacheco|6 months ago
unit149|6 months ago
[deleted]
StellaMary|6 months ago
[deleted]