For someone who has been a strong supporter of FOSS for a very long time, watching what has been happening to the various FOSS communities over the past half decade or so is kind of depressing (with some exceptions, of course).
Let us consider one of the latest episodes in the saga of the industry that has no idea what it is doing as a whole:
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn’t create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I’ve since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I’ve written way better modules than this, the internet just hasn’t fully caught up.
– @dominictarr, in statement on event-stream compromise
TL;DR: Tarr is no longer maintaining a node.js package that everyone and their dog uses. No legitimate users step up to maintain said package, even though they depend on it. Tarr hands over said package to a “helpful” stranger, who immediately decides to monetize it via cryptocurrency pilfering. Internet polarization ensues.
Boy, that must have been a good day for this “helpful” person. Not so much for Tarr, though, who got the crap end of the Internet for handing over the package without properly vetting the stranger. How Tarr would have been able to do so in a way that is 100% safe is not clear to me at this stage, but lets roll for a bit with the assumption that a small amount of extra care on Tarr’s part could have avoided this mess.
This would mean that the original author of any FOSS package or application, by publishing it, would have to accept as fact that any misuse of said software would forever be their responsibility, or at least until that responsibility is, diligently and ceremoniously, transferred to someone else, hot potato style.
You know, like we do in the corporate world.
This line of reasoning quickly leads us to a dead end where there is no possible positive cost-benefit analysis on the matter of ownership of a part, however small, of the FOSS ecosystem.
Here’s a thought experiment: suppose it was Tarr himself who decided to add a new crypto miner “feature” to his own package. Hell, it’s just one of the many ways of monetizing FOSS, after all. Though I will concede that it would not look good in his rap sheet, the most interesting thing about this possibility is that it is entirely legal. It is also possible that, if done correctly, no one would have noticed for a long time.
So what does this mean? It means that at any point in time any one FOSS
maintainer may entirely replace their code with anything they fancy, be it
crypto miners or console.log("ur mom, lol"), make it unavailable permanently
or only on Tuesdays and full moons, and also, as with any property, transfer it
to anyone, without asking for your opinion.
You on the other hand, the avid FOSS user, bestowed with the powers of binary copying and the four essential freedoms of the GPL, get to say “yeah, maybe not today”, and pull out your own, well behaved copy of the offended/offending software, make the modifications you need, and proceed from there, optionally publishing your own modified version of the codebase in question.
But no one has time for that, right? We got some hip new webapps to ship. No time to read all the code for the 40k dependencies they have, when we don’t even have time to write unit tests. FOSS maintainers should be held to higher standards so that we can better trust them! How dare they pull the carpet on us like that?!
Here’s the thing:
It was about not needing to trust them to begin with.
Code is the only thing you can trust when you want to know what the software is doing, when the company goes belly up, or when your system isn’t the same system that the original authors were developing on.
Code is the only thing you can trust, and by not reading it, you’ve forfeited the most important benefit provided by this ecosystem: the choice of not having to trust the authors regarding behavior or continuity.
You want to download thousands of lines of useful, but random, code from the internet, for free, run it in a production web server, or worse, your user’s machine, trust it with your paying users’ data and reap that sweet dough. We all do. But then you can’t be bothered to check the license, understand the software you are running and still want to blame the people who make your business a possibility when mistakes happen, while giving them nothing for it? This is both incompetence and entitlement.
Plus how is this any different from using proprietary software? If you’re not going to take full advantage of FOSS, maybe you’re better off spending your money on support contracts anyway. At least then, you are entitled to complain until you’re blue in the mouth. Maybe you can even take someone to court!
Your system is your responsibility and you owe your users that, especially when they pay. This responsibility does not change when you choose to take someone’s code so that you don’t have to write it yourself, especially since you didn’t pay for that. This is not to say that the FOSS ecosystem doesn’t benefit from a high degree of trust (it does), however it can, and did, function without this new concept of trust by proxy, because we used to do it the hard way: trust by check-modify-then-compile.
I may be wrong, but in the millions of downloads of event-stream and it’s 1.5k dependent packages, there should be at least 5 companies involved which, had they spared 1 dev-hour per week each, should be more than enough to keep event-stream kosher.
Here’s the part that’s a bit depressing, at least for me.
We may have reached a stage where FOSS doesn’t represent everything it used to anymore, simply because there is too much of it. Too many lines of code, too many competing solutions, too fast a rate of change. We want to keep those security updates coming in straight from upstream, but how are we going to do audits every week on our current constraints?
The fact that some of the focus is being shifted to trust is no surprise in this kind of environment. A FOSS ecosystem benefits tremendously from having a solid trust base because it allows for more distributed work to happen.
But it isn’t really trust. As it currently stands, it’s actually hope and wishful thinking.
I use many Linux distros here in this haus. Of course I can’t audit the entire kernel alone, much less all the code, patches and build scripts for all the packages for all these distributions. What I do is I audit the parts that I’m more interested in, and I hope that 1) the distro maintainers aren’t malevolent, 2) that if they are, some one else will study the parts I haven’t seen and 3) that someone else is also interested in the same parts I am, so that they might catch things that slipped through my eye-comb.
This paints a bleak picture of the future in the case where the growth of the number of lines of code or number of patches per time period far outpaces the growth of the number of developers and maintainers.
So how do we avoid this?
We must make software simpler. Much much simpler. And companies who base their service offering on open source software must become more involved in keeping this ecosystem alive in whichever capacity they can.
Here is another thought experiment: is it possible for a new (but experienced) developer to understand 80% of the part of the codebase they’ll be responsible for within their first 2 weeks (80 hours)?
If not, this person is overworked from day 1, because they will be, by definition, unable to transfer their responsibilities within the standard North-American notice period. If they are fired or leave, no amount of jiggling can prepare a replacement within the notice period, as guaranteed by fourth grade arithmetic. As a consequence, no smooth transition can occur, and some domain knowledge will inevitably be lost.
You may want to adjust the above figures to your particular jurisdiction, but the basic premise remains intact. In no other industry is it considered normal for people to work with, let alone develop on, things they don’t understand at least to a certain degree of confidence.
Software must be made understandable. The essence of FOSS for me can be reduced to one fundamental computing right: the right to refuse to run, on my machines, code that I do not have the option to understand. That is it.
Sure, there are cybersecurity benefits, and economical benefits, and some others I can’t recall right now. But when you try to argue with me that it is normal for my government’s online tax submission system to require Adobe Flash and the delivery of that overprivileged opaque blob to my browser, that’s when you get the “public money, public source code” response, liberally drizzled with the “holy fuck, how do you breathe” stare.
I’m not fundamentally opposed to closed source software, so as long as it runs on someone else’s computer.
However, as we’ve seen, having the source code is not enough to guarantee understandability. It is therefore imperative that the software industry also calms down a bit with this churning out of features, and more emphasis is given to stability, cybersecurity, user privacy, and the understanding of one’s own systems which underpins all of these. Because that’s the bare minimum that any responsible entity can do, especially when they happily take money from the masses for their “service”.
And if said service is based on FOSS from individual contributors, consider supporting them. After all, they are supporting you. They don’t get to complain when you don’t support them, but you don’t get to complain when things go wrong either.