Open Source is one person(opensourcesecurity.io)
opensourcesecurity.io
Open Source is one person
https://opensourcesecurity.io/2025/08-oss-one-person/
183 comments
Guys say it with me: vendor your packages! VENDER YOUR PACKAGES!
How about: commit your dependency lockfiles, make sure they use content-addressing cryptographic checksums like Cargo.lock does.
This is also needed for both reproducible builds and SBOMs.
If you commit the actual source code you're making things worse, because it makes coordinated source code review efforts a lot harder. Also patch management with actual vendored source code is terrible.
This is also needed for both reproducible builds and SBOMs.
If you commit the actual source code you're making things worse, because it makes coordinated source code review efforts a lot harder. Also patch management with actual vendored source code is terrible.
And mirror your dependencies.
Yet still hype leads people to believe in single proprietor billion dollar software companies are just around the corner.
> 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.
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.
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"
It mostly doesn't work like that even for closed source in DoD. They have to weigh the risk against the very high cost of mitigating the risk. Their resources are large but not infinite.
Even if they trust the developer they may not trust their process. There are many cases of trusted developers having their development environments compromised such that bad actors were able to insert modifications into source trees, in commits signed by the developer. Most code is not developed in anything remotely resembling a high security context.
Even if they trust the developer they may not trust their process. There are many cases of trusted developers having their development environments compromised such that bad actors were able to insert modifications into source trees, in commits signed by the developer. Most code is not developed in anything remotely resembling a high security context.
I don't know where you're working, maybe you work in some secret lab where everything is air-gapped and not even the pigeons are allowed within a mile of the facility. In which case, what the hell are you doing commenting on a public message board?
That is absolutely not how DoD works. The vast majority of code is contracted out. Nobody from DoD side is reading any of the code. It's all a series of affidavits and audits for configuration management process. Vendors assert everything's cool. Failed audits lead to fines or revocation of access. And the audits check up on documentation and config. They don't dig into code.
At no point in time is anyone, anywhere, in this process reading every single line of code. Not even A single line of code. I doubt they even read the Software Bill of Materials we're supposed to generate, because I've never heard any feedback on any of it.
That is absolutely not how DoD works. The vast majority of code is contracted out. Nobody from DoD side is reading any of the code. It's all a series of affidavits and audits for configuration management process. Vendors assert everything's cool. Failed audits lead to fines or revocation of access. And the audits check up on documentation and config. They don't dig into code.
At no point in time is anyone, anywhere, in this process reading every single line of code. Not even A single line of code. I doubt they even read the Software Bill of Materials we're supposed to generate, because I've never heard any feedback on any of it.
Doesn't change the fact that they can just fork it if it ever matters though...
By the time you know it matters, it's too late. And if it's not too late, you don't have enough data to know which of the thousands of packages you depend on should be forked and which shouldn't.
You're missing the point of a supply chain risk assessment. Yes, you can fork a project to maintain it yourself. But, for an organization to do this, they need to allocate resources, e.g. time and money. This is part of the risk you are assessing for in a supply chain risk assessment.
The risk quintuples with no lock files. And the number of maintainers is often not as important as the number of other users who are also putting eyes on the code
Just forking the code doesn't get you very far. Few of those products have what we would call reproducible builds so good luck trying to create a working release image if you don't have access to the contractor's infrastructure and tooling.
Damn, what country is this in? Maybe the US could learn a thing or two from this level of attention to detail.
I'm only really describing the due diligence I do to keep people safe who might rely on my OSS work. I didn't realize I was so far ahead of the defense industry...
I think you're seriously overestimating the amount of work the DoD will use... It really depends on what you are working on and where it will be used. I've worked on govt adjacent, military and banking projects... The most locked down in terms of packages I can use have been banks. In one case, a lawyer had to review (mostly licensing) every package that got added in to the local npm mirror for allowed internal use.. and another review for every version bump. Then of course, the (one) guy retires and there's no reviews for a month (so much for the launch date).
I've also been in a sealed environment, where I literally had to hand copy jQuery from an internet connected computer on one side of the room to an internal dev computer on the other side of the room... no disks, usb drives, etc allowed. That was a few days of "fun."
I've also been in a sealed environment, where I literally had to hand copy jQuery from an internet connected computer on one side of the room to an internal dev computer on the other side of the room... no disks, usb drives, etc allowed. That was a few days of "fun."
> 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?
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.
> 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?
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.
* 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.
Definitely seen this a lot in the JS/NPM ecosystem... You go searching for a module that does $thing... you find about 10, you sort and look at say the 3 most recently published an the 3-5 most downloaded/popular... is the repo open (github, usually), are there a lot of old issues left lingering with an old last publish date? Might take a passive look at the codebase to see if I can grok it and fix any issues I find if needed.
Choose what I feel is the best option. Trying to avoid dead packages, but not afraid to deal with older packages if they aren't just stale, but functionally complete. The shift towards ES import statements and TypeScript defs has also influenced my selection process.
I've seen plenty of cases where either a fork or new option effectively takes over. A lot of people are leaning towards Zod over Yue or Hono over Express. There's instances where the dev goes off the rails like with Faker and the community comes together to fork a solution.
All of the above examples definitely happen in practice. I'm guessing many packages all over the place have replaced various dependencies over the years.
Choose what I feel is the best option. Trying to avoid dead packages, but not afraid to deal with older packages if they aren't just stale, but functionally complete. The shift towards ES import statements and TypeScript defs has also influenced my selection process.
I've seen plenty of cases where either a fork or new option effectively takes over. A lot of people are leaning towards Zod over Yue or Hono over Express. There's instances where the dev goes off the rails like with Faker and the community comes together to fork a solution.
All of the above examples definitely happen in practice. I'm guessing many packages all over the place have replaced various dependencies over the years.
This is theory
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.
And that's why I don't run Netflix.
And that's why I don't run Netflix.
I think this is in the realm of a YouTube series. I mean, what's stopping you from doing it?
Other than it being a lot of work?
Any maintainer pairs want to reach out? I'll give it a shot.
You should pitch this to David Gelb / whoever is responsible for Chef’s Table on Netflix
No, but I would happily pirate that.
Here is one data point.
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.
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.
Not sure if you know or not, or if it matters anymore, but someone eventually made a fix for this.
https://github.com/DirkoAudio/ASIOLinkProFIX
I've been using it for over a year on Windows 10 and it works great.
https://github.com/DirkoAudio/ASIOLinkProFIX
I've been using it for over a year on Windows 10 and it works great.
I suspect this is the case for the majority of open source software. I have a handful of tiny projects. I don't think anyone will keep them alive after I die. But I guess we should make a distinction based on popularity or something. My top four projects have only 675, 363, 122, and 96 stars.
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 think this is a good example though as the "sordid" part also made the project toxic for anything that might have otherwise chosen to take it on.
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.
The ones that come to mind are
- 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.
- 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.
IMO, it has a lot to do with usage and the availability of alternatives. With ReiserFS, there were a lot of alternatives, both available at the time or announced shortly. While ReiserFS pioneered a lot of ideas, many of them showed up in alternatives fairly quickly. TempleOS is had a pretty limited user base.
I’ve seen many projects in the Clojure ecosystem get picked up and maintained by other folks. The key was always that the projects had an established user base of some notable size and something distinctive about them that made switching to other alternatives less desirable than continuing to push forward with a new and possibly more mundane maintainer and feature schedule. I’ve also seen a lot of “abandonware.”
So, it’s a bit of a mixed bag.
I’ve seen many projects in the Clojure ecosystem get picked up and maintained by other folks. The key was always that the projects had an established user base of some notable size and something distinctive about them that made switching to other alternatives less desirable than continuing to push forward with a new and possibly more mundane maintainer and feature schedule. I’ve also seen a lot of “abandonware.”
So, it’s a bit of a mixed bag.
Reiserfs died because alternatives, like ext3/ext4 and btrfs, became readily available.
TempleOS has a fork called ZealOS. Terry Davis really was the "Wesley Willis of programming", and he had friends and fans worldwide, some of whom have taken up TempleOS development under the ZealOS banner.
TempleOS has a fork called ZealOS. Terry Davis really was the "Wesley Willis of programming", and he had friends and fans worldwide, some of whom have taken up TempleOS development under the ZealOS banner.
If it's open-source, and the original breaks for any reason, it's typically forked and continues life. See: Redis (recently).
Unless something changes in the underlying infrastructure, most packages don't need active maintenance after achieving their objective.
If there is a major change (e.g., Python 3, React Native new arch), they are replaced/forked.
If there is a major change (e.g., Python 3, React Native new arch), they are replaced/forked.
When Bram passed away Vim was passed on to the core maintainers there.
If they had done an activity check they would have seen that half of all projects have zero maintainers.
software once "perfected" (working well enough long enough) needs NO maintenance. No cleaning. No calibrating/tunning.
updating is a systemic issue, not a per-project matter
updating is a systemic issue, not a per-project matter
Definitely varies with language/runtime/library choice. I have no problem using a clojure library that hasn’t been touched in 5 years. But back when I had a gatsby site (static site generator for react) I would end up in the dependency hell after literally a month of not touching it
Under a microscope, maybe.
But if you had a "perfect" piece of software that used Log4j in 2020, it wouldn't have been perfect for long.
Unfortunately, there's a lot of reasons that software needs maintenance, even if it was thought to be perfect when it was originally written.
Hardware changes. The software landscape changes. Dependencies are deprecated, or are found to have their own problems. Vulnerabilities are discovered. Vulnerabilities are found that aren't even the fault of your software, maybe they are a flaw in the hardware your software runs on, and the only way to fix it is via a software mitigation. These are all real things that happen to otherwise perfect software.
But if you had a "perfect" piece of software that used Log4j in 2020, it wouldn't have been perfect for long.
Unfortunately, there's a lot of reasons that software needs maintenance, even if it was thought to be perfect when it was originally written.
Hardware changes. The software landscape changes. Dependencies are deprecated, or are found to have their own problems. Vulnerabilities are discovered. Vulnerabilities are found that aren't even the fault of your software, maybe they are a flaw in the hardware your software runs on, and the only way to fix it is via a software mitigation. These are all real things that happen to otherwise perfect software.
Ironically if you didn’t upgrade from 1.x you didn’t get the new features or the bug you’re referring to
2.x had been out for about six years by the time the vulnerability was discovered.
And 1.x was and has been logging for a decade or more before that which is why I thought it relevant to the ‘no need to upgrade’ discussion
The world didn't stop building new software for that 6 year period, is my point. One would have picked the latest version to build something during that time period.
[deleted]
Plenty of Clojure projects are "done" (the only community I'm aware of that actually believes in this) that presumably specified the vulnerable log4j versions. In reality, it's not an issue, because you can deal with it in your own deps.edn/project.clj/maven.xml, by excluding the dependency, or overriding it with a newer one.
> In reality, it's not an issue, because you can deal with it in your own deps.edn/project.clj/maven.xml, by excluding the dependency, or overriding it with a newer one.
This is maintenance. Maintenance is not an issue if you deal with it, if you don't deal with it, then it is an issue.
This is maintenance. Maintenance is not an issue if you deal with it, if you don't deal with it, then it is an issue.
That is a hysterically wrong statement.
It is true of Solitaire, Minesweeper, Calculator, and Notepad, and probably about the same number of programs on other OSes. (Notepad has recently had an important expansion of functionality, but it didn't NEED that change.)
It's also true of some dinosaurs I have on my system, that copy DVDs and so forth.
It's not true of most other applications, nor can it be true, unless the app works in a sealed, unchanging environment.
Even then... Voyager 2 recently required a software upgrade, IIRC.
It is true of Solitaire, Minesweeper, Calculator, and Notepad, and probably about the same number of programs on other OSes. (Notepad has recently had an important expansion of functionality, but it didn't NEED that change.)
It's also true of some dinosaurs I have on my system, that copy DVDs and so forth.
It's not true of most other applications, nor can it be true, unless the app works in a sealed, unchanging environment.
Even then... Voyager 2 recently required a software upgrade, IIRC.
The point is everything require maintenance, the degree at which it does require it depends on how dependent you are on it and how resilient the system itself is.
You are but going to fundamentally be in distress if solitaire and minesweeper is not running, if your monitoring SW for some important infrastructure starts to exhibit some issues, you might want to take a look or two...
You are but going to fundamentally be in distress if solitaire and minesweeper is not running, if your monitoring SW for some important infrastructure starts to exhibit some issues, you might want to take a look or two...
You don't think Notepad needed AI, a subscription model, and interstitial ads?
You'd think so, but you make something then it doesn't work on a new version of windows, or it doesn't work on a new version of python because one of your dependencies isn't available for that version of python, or it doesn't work on linux if it doesn't have a specific version of packages, or it doesn't work on the browser because they're ditching manifest v2, or it doesn't work on android because you need to provide more personal information or your app will be unpublished.
At this point I have a feeling "perfect" software only exists in hardware like consoles where updates just stop one day.
At this point I have a feeling "perfect" software only exists in hardware like consoles where updates just stop one day.
Nicely said, but the reality is that no software is "perfected", just abandoned.
Hell, even sysvinit had some big updates recently.
Hell, even sysvinit had some big updates recently.
qmail, djbdns, grep, awk, sed, TeX, SQLite, zlib, curl
runit. Every other year someone forks it because they think its abandoned, make some commits for some weeks, and then find nothing else to change and start to look abandoned themselves.
qmail
Also many common lisp packages, 15-20 years old and work perfectly fine.
Also many common lisp packages, 15-20 years old and work perfectly fine.
Maybe we need a Linux distro based on "inactive" software and look how reliably it performs.
I was once forced to use older (but not deprecated) LTS Ubuntu and I hated it. New software come out and you're gonna want to use them (often forced to use them), and they of course use newer dependencies. I had to do the distribution maintainer job and package a bunch of software myself.
What sort of work do you do?
I only use LTS distributions, and this is not a problem I have encountered, so I wonder what accounts for the difference in our experiences.
I only use LTS distributions, and this is not a problem I have encountered, so I wonder what accounts for the difference in our experiences.
I think this depends on how they are used.
If you are leaning on the package manager for managing things like Python, then they are really annoying.
If you are just skipping that and using something like UV, then you won’t care that LTS only has python 3.9 or similar.
If you are trying to use them interactively, then they can be annoying because everything new isn’t available. If you are using them as a server for running pre-packaged code, then they are fine.
If you are leaning on the package manager for managing things like Python, then they are really annoying.
If you are just skipping that and using something like UV, then you won’t care that LTS only has python 3.9 or similar.
If you are trying to use them interactively, then they can be annoying because everything new isn’t available. If you are using them as a server for running pre-packaged code, then they are fine.
s/inactive/stable/
Well, when you talk about a distribution there's a different issue.
The entire Linux ecosystem is constantly shifting with each package releasing new versions, and therefore everything else must be updated to accommodate the changes in the dependency tree.
You could get away with some stuff being only stable versions, but things like mesa, x11, chrome, etc... would still be constantly changing as would their dependency trees.
Well, when you talk about a distribution there's a different issue.
The entire Linux ecosystem is constantly shifting with each package releasing new versions, and therefore everything else must be updated to accommodate the changes in the dependency tree.
You could get away with some stuff being only stable versions, but things like mesa, x11, chrome, etc... would still be constantly changing as would their dependency trees.
Can you provide an example?
A perfected software that had existed >5 years with zero updates, tweaks, ports, or fixes?
A perfected software that had existed >5 years with zero updates, tweaks, ports, or fixes?
LOL. As soon as Python 3.8 is deprecated/replaced by Python 3.9+ in most systems, python packages that depend on old APIs become useless until updated. Any half decent software engineer understands this.
And even in projects that are maintained by more than one person, it's usually just a single person responsible for most of the commits.
This is the exact reason I decided to avoid 11ty for my personal website and instead went with Jekyll [0].
[0] https://github.com/11ty/eleventy/graphs/contributors
[0] https://github.com/11ty/eleventy/graphs/contributors
I find it more concerning that the DoD uses node.
I might be wrong but npm etc feels like a very large attack surface.
I might be wrong but npm etc feels like a very large attack surface.
Why?
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 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 a huge organization, so I'd guess they use almost everything.
> The DoD is a huge organization
That's an understatement if there ever was one.
https://en.wikipedia.org/wiki/List_of_largest_employers
That's an understatement if there ever was one.
https://en.wikipedia.org/wiki/List_of_largest_employers
Woah that’s insane, I didn’t realize it was THAT big. And that’s not even counting the zillions of contractors and consultants. I live in the DC area and I know a ton of people who work for places that contract for the DOD, and only like 2 people who actually work there
That is including all us military personnel, which puts it into perspective a bit.
I think I'm even more amazed that Walmart has almost as many employees as the DoD.
There's a reason it's the largest budget item outside entitlements. There's a lot of money flowing into DoD (and Military Industrial Complex vendors).
[deleted]
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.
The city of Troy kind of got fucked that one time by free shit.
Come on, tell me you don't want a pony!
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.
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.
(Off topic.)
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.
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.
> Linus was a pioneer
Being a Young Pioneer or joining the Komsomol was not officially mandatory, but it functioned as a gatekeeper for any kind of advancement. Party membership operated the same way.
So, by themselves, they don't tell you whether the person in question is a communist.
Being a Young Pioneer or joining the Komsomol was not officially mandatory, but it functioned as a gatekeeper for any kind of advancement. Party membership operated the same way.
So, by themselves, they don't tell you whether the person in question is a communist.
Not in Finland which has never been a communist country. His parents were just political activists who forced young Linus to participate in that as well. Linus has said that the experience made him very apolitical person.
Ah, whoops! I mistook Linus as the name of the Russian developer in question, whose name is actually Denis.
(The whole first name thing in software circles kind of irritates me.)
(The whole first name thing in software circles kind of irritates me.)
Well, my use of his first name was kind of a joke. I apologize for the confusion.
There's very few folks in software that can be recognized uniquely, by their first name, but he's one.
There's very few folks in software that can be recognized uniquely, by their first name, but he's one.
I don't think Russia (or China, either) has been truly communist, in a long time.
Not sure there are any real communist nations left. It's one of those ideologies that looks good on paper, but falls apart, as soon as humans get added to the soup.
Idealists never seem to account for base human nature.
Not sure there are any real communist nations left. It's one of those ideologies that looks good on paper, but falls apart, as soon as humans get added to the soup.
Idealists never seem to account for base human nature.
>> It's one of those ideologies that looks good on paper, but falls apart, as soon as humans get added...
Name an ideology where this doesn't happen.
Name an ideology where this doesn't happen.
Constitutional democracies with a free market have had a long run so far. We shall see if they last.
Curious how we're defining "democracy" and "free market" with this one. I wonder how countries with a pure democracy and an actually free market compare to the republic and regulated market we have in the US.
The US is a constitutional democracy with a free market and I consider it successful.
The definitions of these words can be the predominant use of these words in the English language. But if you want "constitutional democracy" here use this: https://civiced.org/lesson-plans/constitutional-democracy
And for free market here, use this: https://www.investopedia.com/terms/f/freemarket.asp
People frequently misunderstand "constitutional democracy" as being substantially different from "republic" but that's usually an ESL error that can be fixed quickly.
The definitions of these words can be the predominant use of these words in the English language. But if you want "constitutional democracy" here use this: https://civiced.org/lesson-plans/constitutional-democracy
And for free market here, use this: https://www.investopedia.com/terms/f/freemarket.asp
People frequently misunderstand "constitutional democracy" as being substantially different from "republic" but that's usually an ESL error that can be fixed quickly.
The vast majority of markets in the US are hardly free. Every single large company in the US is heavily government subsidized, market protectionism is rife, and regulatory capture and artificial moat-building is the norm. I think it's quite a stretch to day we have a free market. Maybe a 'free-er' market.
So be it. s/free/free-er/g in comments above if that will lead to convergence.
> The US is a constitutional democracy with a free market and I consider it successful.
Out of all the definitions you gave, I feel you left out the most important. How exactly are you defining “successful”? Considering the current state of the US, that one seems really important.
Out of all the definitions you gave, I feel you left out the most important. How exactly are you defining “successful”? Considering the current state of the US, that one seems really important.
> The free market is an economic system based on supply and demand with little or no government control.
Given the amount of government subsidy and regulation that exists in our markets I assume this, too, is a simply ESL error that can be fixed quickly?
Given the amount of government subsidy and regulation that exists in our markets I assume this, too, is a simply ESL error that can be fixed quickly?
>I wonder how countries with a pure democracy and an actually free market compare to the republic and regulated market we have in the US.
They don't exist.
They don't exist.
Yeah, someone should make one of those. Would be interesting to see how they compare to the current 'free market' 'democracies'.
It'll wind up mired into something close to what we have now before long. "There atta be a law" and "Think of the children"... That said, I'm fairly pragmatic about it... I don't think you can have free markets with nations that heavily manipulate their markets, or significantly different quality of life goals or regulation.
That said, I much prefer the free-er market systems and a constitutional republic over what the Quasi-Mauists seem to be pushing for.
That said, I much prefer the free-er market systems and a constitutional republic over what the Quasi-Mauists seem to be pushing for.
True, dat…
> Not sure there are any real communist nations left. It's one of those ideologies that looks good on paper, but falls apart, as soon as humans get added to the soup.
> Idealists never seem to account for base human nature.
Are the implicit “in practice” (cf on paper) and “base human nature” weird synonyms for America invading or doing a coup?
> Idealists never seem to account for base human nature.
Are the implicit “in practice” (cf on paper) and “base human nature” weird synonyms for America invading or doing a coup?
Doesn't stop idealists from pushing their new, "real" version of it... or "Rules for radicals" and Maoist inspired updates to Communism along the way.
Don't forget about North Korea.
China is still pretty communist, even if you define it purely economically rather than by all the other traits too (e.g. heavy censorship). The list of largest employers in the world has a lot of state owned Chinese firms.
China is still pretty communist, even if you define it purely economically rather than by all the other traits too (e.g. heavy censorship). The list of largest employers in the world has a lot of state owned Chinese firms.
Your parent comment labeled themselves off-topic but I'd say they were still pretty on it, but you're like way too off-topic. The point isn't whether some country or some people are real communists or not, but that an individual shouldn't be harassed for maintaining open source software and can somehow be linked to some rival of the West.
Fair point.
But, to be fair, the note about not taking human nature into account, applies everywhere.
I think that we've all seen very smart people fail to account for human nature, and things go badly.
Open source/free work is very human, and I have found it important to keep human nature in mind, as I work.
But, to be fair, the note about not taking human nature into account, applies everywhere.
I think that we've all seen very smart people fail to account for human nature, and things go badly.
Open source/free work is very human, and I have found it important to keep human nature in mind, as I work.
I agree that ignoring human nature is a bad move. In fact, a recipe for disaster for many reasons. Repress or disrespect it, and it will come back roaring with a vengeance.
I also agree that empirically, communism is always a disaster.
But I would also say that communism doesn't even look good on paper. It looks terrifying! To naive and frankly clueless young minds with no appreciation of human nature, human society, and so on, a superficial acquaintance with the subject matter might seem nice, as it might play on tropes and juvenile grievances, envies, and sentiments. But an honest look at it by an intellectually properly formed and informed mind will inspire horror. It is a dehumanizing ideology.
Now, that doesn't mean our hyperindividualist, capitalistic, and liberal consumerist societies don't have their share of poison. They do, and again, to a good degree because they misconstrue human nature. But communism or even socialism are no solution to these ills.
(JPII's "Centesimus Annus"[0], among more academic works by him and others, addresses some of this. People often pay attention to his anti-socialist, anti-communist legacy, but remain unaware of his critical stance toward capitalism and liberalism.)
[0] https://www.vatican.va/content/john-paul-ii/en/encyclicals/d...
I also agree that empirically, communism is always a disaster.
But I would also say that communism doesn't even look good on paper. It looks terrifying! To naive and frankly clueless young minds with no appreciation of human nature, human society, and so on, a superficial acquaintance with the subject matter might seem nice, as it might play on tropes and juvenile grievances, envies, and sentiments. But an honest look at it by an intellectually properly formed and informed mind will inspire horror. It is a dehumanizing ideology.
Now, that doesn't mean our hyperindividualist, capitalistic, and liberal consumerist societies don't have their share of poison. They do, and again, to a good degree because they misconstrue human nature. But communism or even socialism are no solution to these ills.
(JPII's "Centesimus Annus"[0], among more academic works by him and others, addresses some of this. People often pay attention to his anti-socialist, anti-communist legacy, but remain unaware of his critical stance toward capitalism and liberalism.)
[0] https://www.vatican.va/content/john-paul-ii/en/encyclicals/d...
> But I would also say that communism doesn't even look good on paper. It looks terrifying! To naive and frankly clueless young minds with no appreciation of human nature, human society, and so on, a superficial acquaintance with the subject matter might seem nice, as it might play on tropes and juvenile grievances, envies, and sentiments. But an honest look at it by an intellectually properly formed and informed mind will inspire horror. It is a dehumanizing ideology.
Notice the abundance of adjectives and complete lack of argumentation.
Notice the abundance of adjectives and complete lack of argumentation.
If you're too lazy to read the linked encyclical, just say so. Don't hide behind vacuous moralizing.
If you’re too lazy to make your own argument, just-- well you already said so.
[deleted]
Curious, because just recently he expelled Russian maintainers from the Linux project, just because
Just because? I don't think so. I remember the reasoning being provided.
Yes but it’s essentially just because they are Russian, which again, is curious
Linux is a well supported project with a lot of maintainers and support, it isn't a one-man project by Linus.
Not anymore, but that was not always the case. He just has an extremely strong will, and a force of personality, that was able to shepherd the project through its nascent challenges.
I have founded fairly important projects (nowhere near on the scale of his work, though), but I don't have the force of personality he does, so tossing the keys to a new team, and walking away, is what worked for me.
I have founded fairly important projects (nowhere near on the scale of his work, though), but I don't have the force of personality he does, so tossing the keys to a new team, and walking away, is what worked for me.
Of course, and likewise it wasn't always the case that Linux was a well trusted operating system with a robust supply chain. It took a lot of time, people, and investment to prove that out. The organizations who cared about their technology supply chain, didn't adopt it until that was the case. These are some of the forces that built companies like Red Hat.
I feel like you’ve missed the sarcasm here and zeroed in on correcting PC. Good old HN
[deleted]
>It’s not until I change downloads to 1 billion downloads that we see 1 package maintained by 1 person, and 9 packages maintained by more than 1.
Which one is that?
Which one is that?
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.
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.
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).
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));
This reminds me of the observation that adding people to a project doesn't necessarily increase productivity that much...
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.
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…
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…
[Relevant xkcd.](https://xkcd.com/2347/)
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.
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 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.
I wish I could +1 this many times over. Mozilla and Wikipedia are two great examples of this... so much of the expenses are diverted to busy work and so much less to the added value to society.
It is funny how you recognize the "breadtube trap", yet you are so invested in the "no alternative" ideology.
Maybe it would help if you articulated it even a little bit.
half way down the page:
> So now, let’s look at the number of maintainers for projects with over 1 million downloads this month.
> So now, let’s look at the number of maintainers for projects with over 1 million downloads this month.
Fair point, I glossed over that part a bit fast.
It does go in the direction I thought it would though. I'd be curious to see (or to take) a look a little deeper at what those thousand of packages are.
It does go in the direction I thought it would though. I'd be curious to see (or to take) a look a little deeper at what those thousand of packages are.
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."
I’d state that as capitalism + technology provides enough surplus money and time that people can work on hobbies
Huh, I just checked stats on ecosyste.ms
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.
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.
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.
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.
leftpad was a minuscule project that could have been created by anyone. Yet its deletion caused chaos. There are certainly load bearing projects of moderate complexity that are still single person efforts.
right, but the problem here was the deletion of the module, not the disappearance of the maintainer. in the later case the module would have remained, and if it would stop to work because of some incompatibility in a future js, people would replace it
You could also imagine leftpad was using some security compromised library (eg log4j). If the project is of moderate complexity and there is nobody behind the wheel to maintain it, what happens to the ecosystem?
basically, my rule of thumb is that i have to be prepared to take over and maintain any dependency that i use. it's all part of my code. if i am not prepared to do that then i better avoid pulling in the dependency in the first place.
the leftpad example, as it happened, was not a maintainer issue. had the maintainer just stopped working on it, replacing leftpad would have been a no brainer for anyone taking their project seriously. deleting leftpad was deliberate sabotage by the maintainer, even if he may not have predicted the consequences.
i dare say that the leftpad incident would not have affected me because i never deploy live depending on remote resources. everything needed to deploy is cached, and the only time leftpad disappearance would have affected me is when setting up a new project, at which point the failure to build would be an oops, there is a bug, we need to fix it kind of situation.
i don't rely on others such that if they don't do their work my house would come crashing down. if that happens, then that's on me. i rely on things that have been proven to be stable. a maintainer disappearing does not affect the current stability of any of my systems. it only affects future upgrades, and i can deal with those.
even security issues don't necessarily depend on the maintainer such that only the maintainer could fix them. that's the whole point of FOSS, that anyone can fix issues if necessary. in the worst case someone out there would work on a patch to fix the log4j issue, or, remove it as a dependency. if the issue is critical enough for me, then that someone might even be myself.
the leftpad example, as it happened, was not a maintainer issue. had the maintainer just stopped working on it, replacing leftpad would have been a no brainer for anyone taking their project seriously. deleting leftpad was deliberate sabotage by the maintainer, even if he may not have predicted the consequences.
i dare say that the leftpad incident would not have affected me because i never deploy live depending on remote resources. everything needed to deploy is cached, and the only time leftpad disappearance would have affected me is when setting up a new project, at which point the failure to build would be an oops, there is a bug, we need to fix it kind of situation.
i don't rely on others such that if they don't do their work my house would come crashing down. if that happens, then that's on me. i rely on things that have been proven to be stable. a maintainer disappearing does not affect the current stability of any of my systems. it only affects future upgrades, and i can deal with those.
even security issues don't necessarily depend on the maintainer such that only the maintainer could fix them. that's the whole point of FOSS, that anyone can fix issues if necessary. in the worst case someone out there would work on a patch to fix the log4j issue, or, remove it as a dependency. if the issue is critical enough for me, then that someone might even be myself.
Maintainers and contributors have overlapping but subtly different responsibilities AFAIK.
Maintainers are the ones responsible in the end for the state of the repo while contributors suggest changes.
Maintainers are the ones responsible in the end for the state of the repo while contributors suggest changes.
I have couple open source NPM packages I develop together with other developers. In some of this packages I have less than 50% contributions in code. But I listed as contributor on NPM, just because I found this packages and did not update contributors list a long time.
So definitions does not matter when stats that author refers, does not include a developers who own over 50% code in repo, but includes me as contributor.
That's widely known problem of programmers to believe that world is perfect and all data are always actual. Actually it won't.
So definitions does not matter when stats that author refers, does not include a developers who own over 50% code in repo, but includes me as contributor.
That's widely known problem of programmers to believe that world is perfect and all data are always actual. Actually it won't.
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.
[deleted]
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.
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.
Open Source is just a guy, and The Internet is just his computer.
Drupal isn't one person last time I checked; but yes this is correct for almost all projects
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.
It seemed like an advertisement for the incompetence of Hunted Labs to me, from them:
> "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.
> "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.
> If who wrote some code matters to you, then your supply chain management is simply insufficient.
I am not following. Source country is absolutely a thing when certain industries look at open source. That’s what Hunted Labs does
I am not following. Source country is absolutely a thing when certain industries look at open source. That’s what Hunted Labs does
Its completely irrelevant if you are doing things properly.
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.
> 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, the subtle way to plant an idea. It's a crime again to a person have "certain nationalities".
The real concern isn't the nationality per se, it's the vulnerability to blackmail by the state that has jurisdiction over you. It's not a matter of personal responsibility, but nevertheless it has to be accounted for.
For example, I am an American citizen, but I have extended family in Russia, and I would fully expect a place like DoD to be wary of that solely on the basis that it makes me susceptible to blackmail by Russian govt agencies by threatening my family.
For example, I am an American citizen, but I have extended family in Russia, and I would fully expect a place like DoD to be wary of that solely on the basis that it makes me susceptible to blackmail by Russian govt agencies by threatening my family.
Yes, I know. My point is that writers could easily do it better.
Aren't Russian developers on average more susceptible to the "wrench attack" though?
Not necessarily, Australia has a law allowing the government to compel software devs to add backdoors and gag them to prevent people hearing about the backdoors.
https://scarff.id.au/blog/2023/state-actors-can-add-a-backdo...
https://scarff.id.au/blog/2023/state-actors-can-add-a-backdo...
While Russia doesn't need laws for that. You just get arrested for something else (e.g. planted drugs) and then tortured in detention.
Many of them don't live in Russia.
Some of the best engineers that I've worked with (in the US and Europe) are Russian. I've also been quite impressed with other former Iron Curtain developers. A lot of Chinese folks I've worked with have been good.
I know that some nations are known for threatening the relatives of expats, to get them to work on their behalf. Not very nice.
But state-sponsored Russian (or other nations, as well) is definitely something to be concerned about. I suspect a number of folks are concerned about the influence of American programmers. The CIA is known for using fairly innocuous employees of NPOs. My father was one.
Some of the best engineers that I've worked with (in the US and Europe) are Russian. I've also been quite impressed with other former Iron Curtain developers. A lot of Chinese folks I've worked with have been good.
I know that some nations are known for threatening the relatives of expats, to get them to work on their behalf. Not very nice.
But state-sponsored Russian (or other nations, as well) is definitely something to be concerned about. I suspect a number of folks are concerned about the influence of American programmers. The CIA is known for using fairly innocuous employees of NPOs. My father was one.
> Many of them don't live in Russia.
Well Malinochkin does. His GitHub profile says he is located in a suburb 30 minutes from the Kremlin.
Of course, there's a lot of smart software engineers in major cities all around the world.
Well Malinochkin does. His GitHub profile says he is located in a suburb 30 minutes from the Kremlin.
Of course, there's a lot of smart software engineers in major cities all around the world.
The FSB is looking for people they can recruit, even here, on HackerNews, too. Look at the HN news history. You will find stories about Russian history or culture. In comments, some people are expressing their fascination with Russia or its culture. This is how FSB identifies potential sympathizers, who are
easy to recruit. Most likely, some of those, who expressed their sympathy under such news articles a year or two ago, are already recruited by FSB.
they would probably still fake their identity to hide their tracks.
The title of the register article is completely disgusting
They're also from Great Britain which seems to have the most irrational hatred for everything Russian.
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.
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.
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.
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.
You are not familiar with how Putin thinks. https://en.wikipedia.org/wiki/Foundations_of_Geopolitics
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?
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.