Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Author here.

The difference is that FOSS is not a business model. It is far closer to infrastructure, which is usually supported by other means than business models. Things like community structures for common goods (regularly called government but not always).

There is a different problem here, which I have chosen to not talk about here, but that is the problem of funding profitable software products. We simply... do not do that. We do not have the tools for that. But that is a different rant.



> The difference is that FOSS is not a business model

FOSS can be part of a business model, but only if there are contracting parties who agree on the mutual obligations. If someone simply develops open source software and this is used by arbitrary people, essential prerequisites are missing for a contract to come into being. Instead, there are no obligations to the developer.


"FOSS is infrastructure" and "FOSS maintainers are not suppliers" seem pretty at odds. It can't be both "infrastructure" and akin to a couch you dump in the trash (as in the example in your comment below).


FOSS as infrastructure doesn't mean every piece of FOSS is. And infrastructure can be incidental. While we're using analogies tortured beyond all meaning, a goat path in the forest is infrastructure if I ride my bicycle on it to get somewhere, but the goat herder was just herding their goats. If you want to rely on something (code, forest path, whatever), you should probably take steps to ensure the longevity and security of that thing, especially if you depend on it to make money. If I really need my goat/bicycle path, I could do path maintenance on it or try to get the government to do it, but complaining that I'm late for work because the goat herder didn't clear a fallen tree that their goats can jump over but I can't bike around is both foolish and obnoxious.


I'm more concerned about the goat herder intentionally dropping a tree on the path because he's having a bad day and wants it to be your problem too.

Perhaps it's a distinction without a difference. But if it happens a lot, you'd stop using that path.


the road in front of your door are not a business model ;)


I am curious… what percentage of FOSS work for the most critical systems is done by people working for free verse people on a company payroll? I feel like most big FOSS projects have corporate sponsors.


Most big FOSS projects do have corporate sponsors, but what about their dependencies? And the dependencies of the dependencies? Eventually you end up with a situation like what you have with OpenSSL or NTP, where an obscure but important component is owned by someone who has a day job and can't properly look after it.


Nearly none for the really critical components. Even the one with sponsors do not make that much.

Typical example. Last year was the first time the curl project could pay for their website hosting vs the author paying it from his own pocket.

Curl.


Agreed. What I'm thinking of specifically is the leftpad attack vector, where a trusted actor suddenly went malicious and broke the software many people were lying upon who didn't realize they were relying upon it (and weren't really in a position to be aware of the issues the author had encountered).

If that happens too much, corporations re-evaluate rush and costs and start developing things in isolation and in-house. But I expect leftpad will be a rare event.


I would note that the trusted actor did not went malicious. He did exactly what he was entitled to.

If we follow the rules, the people that went malicious are all the trusted users and package repository that broke his intent. He was totally in the limits of his rights and the social contract of the licencing for FOSS.

The fact we present these maintainers as "going malicious" is exactly what i am ranting against in this post.


If those are the rules, then the risk is too high for corporations to trust strangers, they shall have to stop using FOSS, the ecosystem collapses (because nobody can build on an untrustable system), and the FOSS experiment fails (in the sense we're back in the bad old days of closed software and while people can develop with FOSS, no same user would trust it for use). If my company has to be responsible for every line of code, we may as well own them.

I'd argue that he very much did break the social contract. Not the letter of the actual contract, but it's generally assumed FOSS developers aren't in it to screw consumers of their offerings actively. That's the social contract that's the lifeblood of the movement, and if it breaks in the general case, the movement dies.

(There's a lot of things people can do that they're perfectly entitled to that would destroy ecosystems because they shatter expectations. Linus could sneak a very clever backdoor into Linux [hypothetically, perhaps not without collusion with multiple actors and a lot of prep work], and he wouldn't break the license but he would severely injure the project's reputation).


> If those are the rules, then the risk is too high for corporations to trust strangers, they shall have to stop using FOSS, the ecosystem collapses (because nobody can build on an untrustable system), and the FOSS experiment fails (in the sense we're back in the bad old days of closed software and while people can develop with FOSS, no same user would trust it for use).

Well, yes.

There must always be someone you can drag onto the carpet (i.e., sue if it fails or goes rogue). Proprietary software gave you that, at least at the enterprise level. When Microsoft, IBM, et al. sold you software they were staking their professional reputation on that software and the associated support.

So yes, let's go back to proprietary -- when developers got paid and businesses got some assurance from the vendor that their stack wouldn't go rogue on them.


> If my company has to be responsible for every line of code, we may as well own them.

Good luck with that… your company has the skills to reimplement node?

> but it's generally assumed FOSS developers aren't in it to screw consumers of their offerings actively

It's generally assumed they are in it to get screwed actively… but often that isn't the case.

> Linus could sneak a very clever backdoor into Linux

You are aware of a difference between writing a malware and deleting a project you own right?


> You are aware of a difference between writing a malware and deleting a project you own right?

You are quite correct; the npm ecosystem may be a special cade since it has been built on a huge amount of trust-assumption, and the real issue there was that trust model, not FOSS in general. Still, in that ecosystem, unpublishing a module unilaterally that so many systems relied upon was, at besst, negligent (morally not legally), showing a disregard for the concerns of those outside the fight with npm operators. In that context, the unpublish was more malicious than an adherence to the old "user beware" rule. Indeed, it would be hard for Linus to unpublish Linux, given the distributed nature of its hosting; unpublishing leftpad looks more like taking advantage of a mis-design in npm's package model to screw over thousands of third-parties.


The negligent part is relying on npm. If you want reliability then pay for it. Corporations crying about morality is just a smokescreen for them to avoid paying.


Most users of npm aren't corporations. They are individual developers or small operations taking advantage of a very clever ecosystem for distributed package management.

The leftpad stunt hurt everyone in that ecosystem. It was dropping a stink bomb at a party because the host had offended him, but everyone in the room got to suffer the consequences.


This software is provided 'as is'.

Noone built it as trust-assumption

We all chose to trust because it allows us to look at ourselves in the mirror every morning and forget the free work we are exploiting. The problem is us. Not npm.


We chose to trust because it lets us all do more cool and useful things faster. All of us.

That's good! It's also necessary to operate at this scale, where any of us (not just corporations, but every hacker using a package manager) can operate with some minimum level of expectation that while packages might break from time to time, the breakage isn't malicious and everyone's incentives are aligned to minimize it and correct issues as quickly as found. Imagine what the ecosystem would look like if we couldn't make that assumption? The legal warranty allows for, say, Debian to start sneaking keyboard harvesters into the binary blobs that they publish alongside the source... What would happen to Debian users if they did? What would happen to the entire GNU/Linux desktop ecosystem if every package manager chose to do that?

If that trust were to break at scale (i.e. if stunts like leftpad's removal breaking everyone became common, or FOSS developers were to begin doing even more malicious things that the "as-is" legal providing technically allows)... We'd all do fewer cool and useful things, and companies with money would do more of them out of sight.

I don't think that's an improvement over what we have now.

So yes, the buck has always stopped with the last mile developer putting other people's software together into a solution. That is a necessary requirement to have an open source ecosystem at all in a legal environment that demands that blame be assignable somewhere. But if we all start acting like that legal constraint is the only behavioral constraint that matters, we don't actually get to have an open source ecosystem.


> We chose to trust because it lets us all do more cool and useful things faster. All of us.

Which is why I only use licenses from FSF: I want cool stuff I can use… I don't want my cool stuff to be used in cool stuff I can't use, or is used against me.

Anyway not inserting malware is not the same as "this is no longer maintained so I remove it to not be bugged about issues"


It kind of did, as proven by subscriptions, SaaS and digital stores as means to be paid.

Which only works for products, not component libraries.


And yet that is the rules of the contract.

This software is provided 'as is'


he just deleted his package, where he screw them?


Because the npm ecosystem pulls package dependencies automatically, deleting leftpad kicked a necessary brick out of the foundation of some hundred (thousand?) libraries, breaking all of them.

You could consider this a weakness in npm's design... Most package managers don't have the decentralization of authority that npm does. But if it is weakness in the design, it's a weakness that the leftpad author chose to exploit.


I don't know know, company told him fuck off, he deleted his package but more them company required.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: