FLOSS developer intentionally corrupts his libraries and has multiple depending applications print out garbage, stating that "I am no longer going to support Fortune 500s [...] with my free work."


#FLOSS #labor

@fcr If you don't want to support fortune 500s with your free work, don't publish your work under the MIT license

I can't fathom people in this thread are siding with him. This is a breach of trust in the open source world. The updates were purposefully malicious.

He was allegedly also making a bomb and set his house on fire:


@Gargron @fcr yeah, I am not siding with the developer. His actions were shitty.

I am underlining the fact that:
1. Microsoft GitHub will block your account if it doesn't like the changes you make to your own code;
2. AGPL is a way better choice of license if one doesn't want to support Big Tech.

@rysiek @fcr Regardless of if it's your code or not, if you upload malware into a widely used software package you deserve to have your account blocked.

@Gargron @fcr I do not see them as *malicious*. these were not cryptominers, no data stealing code, it just rendered the libraries unusable.

"Mischievous" is the word used in the original story, and I think that's a way more accurate description.

@rysiek @fcr It didn't just make the library output the wrong value, it introduced an infinite loop, which in my view constitutes a denial of service attack.

@Gargron @fcr I can see why you feel that way. Personally, to me it does not cross the "malicious" line -- partly because this is something that should be trivially caught in any pre-deployment testing.

We can agree that this is not an acceptable behavior for a FLOSS developer, and it is in fact irresponsible.

That said, I do think focusing on the developer's (shitty) action is less useful than focusing on the bigger problem of open-source software developers doing free work for Big Tech.

@rysiek @Gargron @fcr, the problem isn't even big tech using the free work of others, the average JS developers don't even realize that the ecosystem is fragile, not even the managers of Big Tech projects:


They brush over these issues as if they were a "misunderstanding" on the part of people reporting them.

I'm afraid that the Unix philosophy doesn't really work these days. You can't trust hundreds of developers and their code for the most basic JS project.

@walter @rysiek @Gargron @fcr NPM has little to do with Unix philosophy. Unix/Linux is maintained in distributions where the quality of the toolset is taken care by the core teams. See projects like Gnome or KDE. Nothing like this in NPM which resembles more a laissez-faire market.

True, but you do have big ecosystems that looks like de facto distributions. A default Angular project comes with 25+988 dependencies, where you get the basics, like: "zypper install-pattern foobar-desktop foobar-devel". With that you install many projects that "do one thing and do it well", including the "colors" package.

And this doesn't count projects that embed (i.e. statically link) their dependencies. And yes, strict versions are a thing and[...]

cc: @rysiek @Gargron @fcr

[...] it's not a perfect analogy, but on NPM you just get more flexibility. They don't lock you into their "repos", think DEB/RPM repos, not CVS repos. Thus, you get to have code from all other "repos", think of PackageKit+Alien, but for Angular and React "repos".

If one really wants, the per-distro repo approach can be achieved here; and things don't even have to change much. Then you're on your own if you want to "zypper addrepo" or add a new PPA.

cc: @rysiek @Gargron @fcr

@walter @movonw @Gargron @fcr this has nothing to do with distributions. In Debian or Fedora, or Arch, or any other Linux distro, the *packagers* are responsible for quality of the packages that are published in the distribution-specific repository.

In your example the Angular people just pull random crap from Teh Intertubes and hope for the best.

It's not even comparing apples to oranges, it's comparing apples to the number three. 🤷‍♀️

yes, it has nothing to do with distros, but there could have been a resemblance.

It's wishful thinking on my part, but even NPM has the notion of registries, so it's not a long way from here to adding to packagers to the mix. The problem is that there doesn't seem to be much demand for this, and then there's npm Inc. in the mix.

deno.land is changing things, but they went with "install from src" + bigger StdLib. So... no packagers yet.

@movonw @Gargron @fcr

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!