updating is a systemic issue, not a per-project matter
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.
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.
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.
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.
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.
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.
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...
At this point I have a feeling "perfect" software only exists in hardware like consoles where updates just stop one day.
I might be wrong but npm etc feels like a very large attack surface.
That's an understatement if there ever was one.
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.
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.
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.
(The whole first name thing in software circles kind of irritates me.)
There's very few folks in software that can be recognized uniquely, by their first name, but he's one.
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.
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 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...
Name an ideology where this doesn't happen.
They don't exist.
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.
> 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?
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.
> 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.
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.
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.
https://scarff.id.au/blog/2023/state-actors-can-add-a-backdo...
The title of the register article is completely disgusting
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.
Am I missing something or was it not, in fact, an important data point at the end?
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.
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.
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 are the ones responsible in the end for the state of the repo while contributors suggest changes.
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.
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.
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.
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.
Is the project taken over by another, single developer? Is it replaced by a similar project? Does it just go away?
And that's why I don't run Netflix.
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.
If there is a major change (e.g., Python 3, React Native new arch), they are replaced/forked.
- 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.
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.
* 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.
Which one is that?
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.
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.
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.
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.
speakingmoistly•14h 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.
sorrythanks•7h ago
> So now, let’s look at the number of maintainers for projects with over 1 million downloads this month.
speakingmoistly•5h ago
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.
thisoneworks•4h ago
socalgal2•4h ago
EdiX•49m 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 under 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.