It's not "Open Source" (making code public and free to use and modify) that's broken. It's how people rely on it without any consideration about the sourcing of it.
It's not that it's free to pick and to use. It's that some/most people too often associate "it's free" to be equivalent to "I don't need to care about it, like, at all".
It's that some/most people don't understand that, whatever they take, they become dependent of, for the better and for the worse (insert Marie Kondo cue here).
The interesting thing here is that there's a full new line of work for Info/OpSec opening here: ensuring that your software supply chain is not only secured, but also properly funded and supported.
That's like... common sense in so many "old" industries.
Yes 'free' means 'the little people work on that'.
There's no real way to secure finegrained node.js or python etc deps, since you have no clue if the original author who signs his sources should be trusted, or was malicious from the start and just biding his time, let alone everyone who contributed to every package.
What would help is independent audits and where needed help with hardening like fuzzing and asan / valgrind / static analysis. Just an extra security-minded eye on patches in realtime would be a big help (and maybe would have found the logging bug at hand).
I hope you are answering the parent. Because rhis is exactly what I said. You as a user of any foreign library have to look through it. You can't trust code you didn't write. That is also one of the reasons why in the past so many parts where reinvented. Those guys where not stupid, but why on eaeth would you risk the security of your work just to not write the login process yourself? And then some smarty pants came and told you this is all unnecessary and it is "best practice" to just include some library, package or whatever it is called nowadays.
> It's how people rely on it without any consideration about the sourcing of it.
Exactly this. I think the problem is that OSS consumers often have a complex that they are entitled to "good software". But I doubt that the solution is to make it so that the producers are "entitled" to financial compensation. I can see situations where that backfires -- satisfying the producer's "entitlement" can exacerbate the consumer's sense of entitlement and just create an entitlement arms race, and stress out open source producers.
It absolutely is $0 free to pick and use. So that’s what people/companies will obviously do. Why should they pay more than $0 for something that is worth $0 in the market place?
It's common enough to see the phrases "'free' as in 'free beer'" puts it in contrast to "'free' as in 'free speech'" (which emphasises you can do what you want with the software).
Following in popularity from these is "'free' as in 'free puppy'"; which emphasises that you'd be taking on a burden of responsibility by using it. -- At the very least, if you're using it, it may have bugs.
Why? Because they not only pick something that helps them, they also pick the legacy that comes intrinsically with it.
If they want this legacy not to be a burden, they need to take appropriate steps: contribute to it, through the means of their choice: developer time, advocate time, money, structure, anything.
It's (a bit) like all industries sourcing from the environment (trees, vegetables, minerals, oil, gaz, etc.): it's all available for free, let's pick it.
Only, if you're not careful about the sustainability of it, and the consequences of sourcing these, it will backfire at you at some point. Badly.
Careful license choice and intentionally crippling things such that they are objectively useless unless you meet the exact needs that I have.
I've kind of given up on elemental-ircd and left it unmaintained and archived, but I would probably send a job application in to that place if said unicorn startup happened. A few people have tried to take over elemental in the past, but as a whole the IRC ecosystem is on a downturn so they don't last long. It's a complicated situation though. At some level I'd be shocked that they managed to turn that pile of shit into something usable!
it's a well written article and you got me agreeing with what you are saying. it's surprising to read comments here that start with "open source is not broken" but proceed to repeat everything you wrote in the article...
The title of the article is "Open Source is broken" and its subtitle is "Why I Don't Write Useful Software Unless You Pay Me"
And I disagree with both of these statements. Open source is not broken and I'll continue to write useful software, even if you don't pay me, because it's fun.
The actual problem is concisely present in the article:
> There is this culture of taking from open source without giving anything back.
The problem is not with open source, but with how capitalistic systems interface with open source - the same way the interface with any public good.
It's the capitalist culture that's broken; the capitalist culture of rent extraction and of short-term profit optimization.
And the solution is communism, of course. Duh. Isn't that the logical conclusion?
The problem is definitely not YOU. It's not like you could do anything about this situation yourself, say by making contributions to projects you'd like to support. No, it's those evil capitalist white men who use terrible phrases like 'welfare queen' to hurt the feelings of helpless black ghetto women, obviously. We need communism, and we need it now.
It would be interesting to get feedback from some of the more successfully funded projects and understand how they have things structured to handle these kinds of things.
I also know there are organizations like the Software Freedom Conservancy who helps to handle these kinds of things who I would highly recommend [1].
I used to donate to a lot of FOSS projects, most recently FOSSHOST. Both the project and myself were heavily attacked and accused of all sorts of things for doing so [2]. It has left a chilling effect on me and others I have spoken to. Most of the people who engaged in the online attack were not even developers, but simply "IRC Admins" of projects.
How does a company or individual support projects financially with this kind of social ecosystem?
Thanks for the thoughtful article. I've always viewed Free software and to some extent OSS as by programmers, for programmers, period. Contributing code back supports the other programmers who use it. If commercial businesses want to use the software then they are free to contribute back (monetarily to support programmers or with their own code) or not. There is a long history of volunteerism in maintaining the Internet via open standards and I see a lot of OS/Free software in the same way.
It doesn't make sense that businesses don't invest enough in the software they use (paid commercial software or otherwise). That is only to the detriment of the businesses that don't care to invest (their unique use-cases are not improved). It's not quite a tragedy of the commons because nothing prevents the people who do care (Google, MS, Amazon, FB, IBM, to name the large ones) from contributing their improvements back to the ecosystem, and they retain the full benefit of their work.
It is absolutely an unequal exchange of goods for labor for most businesses but the near+zero marginal cost of replicating software means that it's a negligible loss for the authors, if that. The solid benefit for most programmers and system administrators is that they get to use high-quality Free/OS software in the jobs where they do earn money. At least for me, business concerns are secondary; I want to use quality software with a good ecosystem rather than know for sure that my employer paid money for the software that I have to use.
I always think about paying for the open source software that I use and I try to be more dilligent in paying for it.
The problem for me is, that while calculating how much I theoretically should spend on the OS I use for example (gnome+fedora+linux kernel,etc), it would be actually cheaper to pay for a windows version+microsoft cloud/office suite or switch to the apple ecosystem.
Same applies for programming frameworks I use.
Doesn't that mean opensource is inherently impossible to use ethically as a private person?
So how do you decide on how to deep and how much one should pay?
If everyone paid 15$ (+-Netflix sub price in my country) to single favorite FOSS project they use, we'd be in a much better place. In case of libraries/frameworks - they should be founded by companies.
> This is why I am very careful about how I make "useful" software and release it to the world without any solid way for me to get paid for my efforts. I simply do not want to be in a situation where my software that I develop as a passion project on the side is holding people's companies together.
Isn't this the best position to be in if you want to get paid? "You've built your company on top of my project and now you need this bug fix/feature yesterday? My hourly rate is $$$"
No. It's really not. Every company that has previously obtained your work for free will be offended by having to pay for it. Worst case, you'll be attacked for rent-seeking. Best case, you'll be ignored but your work will used for someone else's profit
I agree with the author: it's time that value be compensated by real financial capital, not empty promises of status in some mythical open source community.
A thoughtful piece, and most supporting points are real and I think I agree with them. However, I don't think the conclusion "Open Source is broken" follows from the arguments.
The most concise counter-example I can come up with is: What would change if that XKCD picture had the critical log4j2 component replaced with closed-source "McA$$hat logj2+ ENTERPRISE" trialware+commercial $$$$ licensed product that was thanklessly maintained by severely underpaid hire-and-fire contractors in a 3rd world country? Nothing. Well, it'd be a lot worse because you couldn't fix it.
What's broken is larger umbrella projects and products, open-source and commercial, not understanding that they own and are responsible all the dependencies. All of them. Down to the very bottom of the stack. Whether they bought them or got them for free. Each and every dependency must be evaluated, and if it's appropriate, you could delegate the risks to a trustworthy sub(contractor) or project.
What if that project gets abandoned? What if "McA$$hat Inc." goes out of business? Or either just changes direction or quality suddenly? Will the security bugs be reported or covered up or remain undiscovered because nobody uses the thing?
I currently trust Linux. I trust the "big" distros. I trust a lot of larger, well maintained opensource projects. I'm very hesitant about things like node.js and others that have very fine grained and super-easy automatic dependency management and build systems the just pull whatever the latest thing is for hundreds or thousands of dependencies. I really don't trust most commercial software because it's always just as broken, but you can never see it nor fix it.
A lot of the article focuses on getting paid. I totally agree and the market will definitely correct when it becomes visibly critical. You can get paid to maintain opensource commercially and that's probably the best of both worlds. There's going to be a lot of people working for a lot of companies getting paid to fix or replace log4j2. There's going to be a lot of people paid to figure out how to get better control over that XKCD picture situation.
But Open Source isn't broken, it's the cure just working it's way along by making that picture visible.
I'm curious on your thoughts about the difference between publishing this post and publishing oss/foss code.
To me, it seems like this blog post is something you've shared freely with the world, with no expectation of getting direct financial compensation for it. You have an idea you want others to read and think about, so you wrote it down.
To me, this act of publishing and sharing your thoughts freely in the hopes others might find them interesting shares similarities to free software. You wrote something that you think others might find interesting or useful, and you want to share it. That statement applies equally well to FOSS and blog posts.
What do you see as the major difference? Is it that OSS rejects copyright, so the code can be used for profit, while your post can't freely appear in, say, a published for-profit book of opinions on OSS? Would you be opposed to this post being published by someone else and you not getting money for similar reasons that you blog about here?
Is the difference in expectations, that people expect support for software, while people expect nothing of blog posts? That a blog post is finished and may be thrown over the wall, comments ignored, typos uncorrected, and that feels "fine", while software thrown over the wall with issues ignored and no future changes planned feels "weird"?
Is there some bigger difference?
Is there a way to reduce this difference, to create an environment or structure where you would share code, just as you currently willingly share your thoughts and writings on this blog?
I actually do make a very small amount of money for my posts. I make about $120 per month on Patreon (I more accurately make $175-ish per month but I also donate back to the amount of about $55 per month to other projects) and this blog is frequently brought up in interviews, which means that it becomes an impetus for people to hire me. I'm not sure how to quantify that, but either way it offsets the costs of hosting the server, even though I have kind of a ridiculous level of overkill (Ryzen 5 3600, 64 GB of ram) for that server.
As for the time to write these posts, yeah I'm making nowhere near my market value for this kind of writing. I've considered adding ads to my blog, but I still feel kind of philosophically uncomfortable with "selling out" like that. My job really does make sure that all my needs are accounted for and I am blessed to be in a state where I have financial excess and can make additional private contributions to other projects.
At some level though my blog is really a sink for my anxiety. Just being able to put words out into the void and knowing that someone is gonna read them helps a lot when it comes to making things a lot less scary in the world. I really do just throw them over the wall when I'm done though lol. Sometimes I'll do a typo pass but most of the time I write well enough that my first pass turns out to be the last pass unless some critical problem is found. This doesn't happen often though.
I do occasionally make volumes out of my writing and sell them on Itch (https://withinstudios.itch.io/), but I have only ever made $250 on there in total; nowhere near enough to fund the creation of the media in question. I also don't advertise my Itch shop very well so that may be partially on me.
Mostly though the goal of this post was to make people think about the issue. I have succeeded.
What is broken is companies using open-source to build their products, expanding to billion dollars total revenue and not giving anything back in the long run.
This will - as shown in the latest example - come back to bite them.
It's the classic tragedy of the commons; everyone is willing to profit from the public good and nobody is willing to invest resources into it.
I agree. What's broken is liability of those companies relying on open source but not taking responsibility.
One way to hold them accountable is to apply regulatory pressure in case of security breaches, which has started to happen (albeit not nearly enough). Is there any other way I'm not seeing?
Another way would be to enforce open-source requirements for any public spending including/producing code. You want a city to buy your traffic control system? Open source the code first. You want a state to use your voting machines? Open source your code first. Any public money going should necessitate that software being released as open source.
Not only would this lower the risk of fatally flawed public software projects, maintenance of these systems in the long run would also not depend on just one company with an artificial monopoly anymore. This would also create a healthy ecosystem of paid open source developers.
I'm not sure. Wouldn't that mean forcing the companies to pay someone to take that liability but not necessarily providing any benefit to the original software developers---like whatever Red Hat Enterprise Linux is called today?
Why should companies pay more than $0 for something the creators ask $0 for? That doesn’t make sense at all. Do you pay more than the asking price for stuff you buy?
If you provide work/code for $0 then you yourself signal that your work is worth $0. So why should companies spend more than $0 on your work? If you truly think your work is worth more than $0 then put that in your licence for companies. It isn’t rocket science.
Human society has for thousands of years relied on unpaid voluntary labor. Be it taking care of the elderly, taking care of the sick and the poor, managing public spaces, organizing festivals, on and on and on. Human society is built on voluntary participation much more than on monetary incentives.
It's part of the capitalistic delusion that only what a price label has attached has worth; you are conflating "worthless" with "priceless".
Not at all. A lot of things have intrinsic value. Like the things you mention (taking care of the sick etc.) That is different from its market value (what people want to pay for it). The problem is that some OSS maintainers think they are the same, expecting the intrinsic value of their work to automatically convert into market value (them getting paid). That is not how it works.
Sorry, I don't know what you are referring to. Are you refuting any of my arguments? If so, please let me partake in your reasoning.
> The problem is that some OSS maintainers think they are the same, expecting the intrinsic value of their work to automatically convert into market value (them getting paid).
I don't think that this is what is currently happening, isn't it?
You don't hear the log4j maintainers complain that all these big companies leech of their work and they are owed. Many of these companies do make quite some nice profits and very seldom is the dollar that gets paid back voluntarily. And that's fine for pretty much every FOSS developer. Very seldom I hear about FOSS developers angry that companies use their product to make money. Usually these developers switch to different, commercial licenses.
Quite the contrary; it's these big tech companies that are in trouble. They are in trouble because they are liable. The log4j developers are not responsible for fixing these bugs. Why should they? FOSS licenses come with explicit denials of liability.
The big tech companies are in trouble because they saw something for free and saw that they would save the market value in expenses for a similar commercial product. But they forgot that they are also relying on voluntary labor that comes without responsibility by the authors. And now they are on the hook.
They should have recognized that by skimping on the dough and using FOSS software the same way they use commercial products they also took on unmitigated risk. And because they are so cheap, they didn't consider mitigating that risk by supporting the development of the software they so depend on.
If just one or two dozen companies had paid a measly few dollars every month to the developers of log4j, this could have all been avoided. But they were shortsighted and greedy, as capitalist companies have to be shortsighted and greedy. And now they have to own the mess they made.
Suites them right, I say. Though I doubt they will learn their lesson, don't you?
Someone should write a package that goes through your existing codebase to see which open source projects you make the most use of (however that is measured). Then a company could run it once a year, say around tax write off time, and build a list to donate to
I would have happily given to log4j, but I didn't know that they were in need. Someone has to make it easy to keep track of this because it's never going to be a priority for businesses
Or they could get a list of deps, and just get their engineers to occasionally keep tabs on a few random deps. Random would be almost as good as systematic if a few companies did it.
Check the security of the infrastructure (is it one guy?), check whether some the code is correct (either randomly or systematically, not just checking the first file you see), etc.
What's the incentive? Well, checking your dependencies is a way to upskill. You learn as much reading code (especially the code you are relying on) as you do writing code, and most of a programmer's job is learning.
An incremental way to get to this would be to standardize the format for payment info in package.json (or equivalent). Then you could build donation into yarn, pip, cargo, etc. Just run ‘yarn donate’ and choose the amount to spread over the packages you use.
This is a half-baked idea right now, but I think there’s something to it. A lot of the issues with open source stem from the friction of donating. Reducing that would incentivize people to work on libraries that are popular but neglected. It would also help devs capture some of the value they create.
Well, I agree but no solution in the horizon yet. Yes, the companies which profit from open source "should" fund the open source. But nothing forces (or even reminds) them to do so.
Why should they? The developers giving away their work for $0 are telling the world that their work is worth $0. So why should the companies pay more than $0 for it? That doesn’t make sense at all.
Sorry just saw this. But "worth" is not calculated by money every time, no? E.g. we're not paying for oxygen while breathing but I wouldn't consider "weather costs $0 so it is worthless". But (continuing from the same example) if the weather is being hard to breathe due to pollution, I seek some action to fix this situation. That was what I am trying to find out, how could one enforce some payment out from this system, but can't see any workaround yet.
Open source software is free to take is a practical measure as much as anything. It's because having the left-pad package surrounded by a paywall would suck, and would create all kinds of weird incentives to mess with both the software and the ecosystem. And we absolutely want an ecosystem where one person makes left-pad, and someone else builds on top of that and in the end you have React, or whatever, and that doesn't work if everything is an app store.
We (programmers) need to explain this to the money people somehow. No company I've worked for in my 10-year career would have been able to exist without open source. They would have had no product. If you're extracting significant value from this ecosystem, you should help fund it, even though there isn't a toll booth on the way in.
Yes it's in a bad state and unsustainable, especially with the recent (and welcome) focus on security these days. I wouldn't consider it broken however, that's implying an unrecoverable state. There do exist sponsored projects in the open source world which have been running successfully, though those are few and far between relative to the number of 'Nebraska' projects.
Those outliers aside, consider the alternatives. The first one I can think of is to put trust in closed source software, in many cases written by MAMAA. We have enough historical evidence to know that represents a nightmare scenario that we should actively be working to get away from.
That's why I agree, we should be trying to make the open source ecosystem sustainable. What I think we'll need, as a bunch of normal users, is a way to present these cases to our $workplaces, to get the funding or sponsorship in place. And an easy way for companies to do that, which slots in with their own practices.
Maybe UBI would be a good use case here. People could focus on their passion projects and wouldn’t need to worry about begging for money from the corporations that profit off of their labors and give nothing back.
If some guy in Nebraska maintains some library that is very useful and your company relies on it and does not pay him, you're asking to wind up relying on an unmaintained project eventually. If I maintained something extremely valuable and found out a core google product relied on it, I'd stop maintaining it.
Presumably their wish to cause google some inconvenience is greater than their wish for self-expression, and/or they have other means of expressing themselves so they don't care about any particular project.
I think the issue, which is so well depicted in that XKCD cartoon, is that transitive dependencies can make it nearly impossible to not depend on some low-level, unmaintained library.
It's not like tens of thousands of projects decide to pull in left-pad. But tens of thousands of projects do decide to use React, which (I'm guessing through its own gaggle of many dependency layers) happened to pull in left-pad.
Taking the option of "I'll just build everything myself" then is not really a viable process in today's world, where all of your competitors will be using tons of prebuilt stuff (unless, perhaps, you have the productivity of someone like Fabrice Bellard, but the reason he's so well known is because his abilities are so rare).
I think the real fix is that dependency management tools like NPM and Maven need to make it much easier to "override" dependency package names so that, if a critical issue is discovered, you are not at the mercy of the current maintainers of that package to quickly get a fix into production.
> Taking the option of "I'll just build everything myself" then is not really a viable process in today's world
I want it to be practical to build software which only depends on a small number of trusted individuals or organizations beyond the OS and compiler. C++ manages it better than newer languages with built in package managers, and dependencies rarely depend on transitive dependencies, though it comes at the cost of adding dependencies (especially transitive dependencies) being extremely difficult (I hear Meson subprojects help, and CMake has their own worse version I didn't try).
"I think the real fix is that dependency management tools like NPM and Maven need to make it much easier to "override" dependency package names so that, if a critical issue is discovered, you are not at the mercy of the current maintainers of that package to quickly get a fix into production."
I'm probably mistaken, but I thought in maven managedDependencies was exactly this. Please correct me if I'm wrong.
Maven/Gradle does exactly that. Provided the dependency you're replacing is compatible with the new one (same packages, same methods, etc), it's fully transparent. It's just that once again, the web world is running with awful tools that keep making the same mistakes that have been done years before them.
> Taking the option of "I'll just build everything myself" then is not really a viable process in today's world, where all of your competitors will be using tons of prebuilt stuff [...]
It obviously depends on the scope of things but I tend to see a future where this building everything yourself might be an advantage again. Because most of "this prebuilt stuff" adds layers of complexity because of generalizations you don't need and other abstractions.
In my experience this gets worse and worse every year. We software developers are already drowning in a flood of languages, frameworks and so on. How often do I see a framework Y built on top of library/framework X to abstract away something from X. Not only you have now both dependencies but at some point Y lacks a feature you need (which is provided by X). Now you have to pull up X and mix with Y and everything just got worse than just using X from the get go..
I more and more think we need some back to the root movement and also keep in mind to always choose the simplest solution.
> Taking the option of "I'll just build everything myself" then is not really a viable process in today's world, where all of your competitors will be using tons of prebuilt stuff (unless, perhaps, you have the productivity of someone like Fabrice Bellard, but the reason he's so well known is because his abilities are so rare).
Along with a sibling comment [1] that disagrees with you, I want to add that I am starting to do this myself.
I am close to 30, and I would not say I'm particularly productive. In fact, I would say that I am far below average on what most programmers call "productivity," by which they usually mean "amount of code written." I write code slowly. But I write good code.
My library of stuff is basically made to work on POSIX C and Win32 C, with no other dependencies, including the build system. It has resizable arrays, hashmaps, structured concurrency, trees, UTF-8 strings, string builders, filesystem handling, linked lists, a stack allocator (per-thread), stacks, a self-designed config language, and a pool allocator. Oh, and as mentioned, I'm well on the way to having a build system in there too, with a bootstrap process that depends on nothing more than either MSBuild, a Windows batch file, or a POSIX sh script, meaning that bootstrap itself has no other dependencies other than a minimal OS configuration.
A few months ago, I was writing a compiler in Python (with lark), thinking that I would write the compiler faster that way. Only recently did I try again with C, using my libraries. It turns out that I'm just as fast in C as in Python because I understand my entire stack.
Because of that, I think that my sibling comment is correct that the option of "I'll just build everything myself" is going to be viable for people with less productivity of Fabrice Bellard. In fact, maybe understanding his whole stack is what makes Fabrice Bellard as productive as he is.
I wouldn't worry about speed. As you progress through your career, you'll get very good, at writing very good code, very quickly.
These days (I'm 59), I can bang out a full-fat native Swift app in a few days, with excellent code (and operational) quality, great UX, high maintainability, accessibility, localizability, customizability, etc.
You say that as if you even know your full dependency chain. Reality doesn't quite work that way. No one knew their codebase even relied on leftpad until it broke millions of applications the world over when it got pulled.
Some projects have the benefit of notoriety (log4j falls in that category) but plenty of projects are just "plumbing" and the only thing you know is the name of the dependencies you have in your dependency list. I can guarantee you that except for security audits, no one knows their full dependency tree, and that they have a deeper dependency with itself a dependency on a utility that depends on a thing that no one's even heard of, and no one's looked at for years, and you would never have looked for. While also being one of the critical pieces that your software runs on top of, capable of bringing down your entire product even if _what it does_ is literally trivial.
Best case, it fails. Your product/server is now broken (hopefully, for only a short while). But worst case, it has a 0-day exploit. And now your entire company is at risk to the tune of "depending on how bad, you may have just gone out of business because you can't afford what is necessary to both legally and professionally deal with the fallout".
(Did your product/service have a database that comes with rather massive fines for leaking that data? Good luck, that might bankrupt you. Does your company have contracts that are void on significant service interruption? Good luck, you may have just lost all your big clients. Etc.)
> plenty of projects are just "plumbing" and the only thing you know is the name of the dependencies you have in your dependency list.
Maybe in the web world. .Net/Java/C/C++/etc projects have a well understood dependency chain, most of the time. Mostly because there is an actual stdlib and having dependencies upon dependencies upon dependencies is very rare. Projects I've worked on with over 150 dependencies (which is an awful lot for an Android project as it was) had a dependency tree that wasn't that deep (5 at most), and all of that was on standard, well known modules (androidx, etc.)
The shitshow that is JS dependency management is a self-inflincted wound. Knowing your dependency tree _is part of your job_ as a software engineer.
> You say that as if you even know your full dependency chain. Reality doesn't quite work that way. No one knew their codebase even relied on leftpad until it broke millions of applications the world over when it got pulled.
We're professionals - we in fact simply can do that with some elbow grease. Doesn't take a genius to understand how software is built.
My point is it's your collective job as a professional software dev shop to do so. It's a relatively fixed cost too - incrementally knowing your toolchain once you've done it the first time isn't that bad.
The only professionals who actually do this are in heavily regulated industries that require it, which are often criticized as being stuck with "ancient tech".
It seems there's currently two ways to tackle this issue: move fast and break things, or move slowly and don't break things.
This is what I was thinking: it seems like any security and reliability vulnerabilities from OSS are at least as bad, if not worse, in paid software or closed-source.
You can pay someone a lot to make a product and they can do a shitty job. You can have a company install a backdoor in a closed-source software for whatever reason. You can have a well-trusted organization with competent developers mess up a single line of code, creating a huge bug or exploit.
OSS actually gives you a benefit that you can see the code and technically discover any bugs or exploits (even though of course nobody will). There are plenty of open-source libraries where contributions are seriously reviewed for any accidental or intentional errors.
Serious hard-to-patch exploits are discovered in closed-source software every day. They might be harder to discover and easier to reveal without revealing how to trigger, because you can't directly see the source code. But this isn't a fundamental problem of OSS, it's something OSS users and maintainers need to look out for.
> This is what I was thinking: it seems like any security and reliability vulnerabilities from OSS are at least as bad, if not worse, in paid software or closed-source.
This is wrong: it's better in open source land. Closed source means you, the user have to wait for the vendor to ship a fix. With closed source, the answer sometimes is the version you are on is no longer maintained, and you must buy a new licenses to fix the vulnerability in your closed-source product. Other times, the answer is, sorry, we discontinued that product and will not be patching it.
With open source, you have options when a maintainer says the version is too old: fix yourself, use a patched fork, or migrate. Any way you go, the situation is substantially better than closed source.
> OSS actually gives you a benefit that you can see the code and technically discover any bugs or exploits (even though of course nobody will).
People can and do find and report bugs and exploits in OSS all the time. It's what makes open source work so well.
Open source isn't broken. The software will continue to get built regardless of funding levels, clearly. But when vulnerabilities like this are found, no one -- especially corporate users -- gets to complain. Any complainers should be immediately told to fund the software they use, or shut their entitled mouths.
Open source is fine. The culture of companies -- nearly all of them, including the one I work for -- that freeload off this work is what's broken. If you are equating this state of affairs with "open source", I think that does everyone involved a disservice.
I work on and release some things under open source licenses. I've been doing this on and off for nearly 20 years. None of it these days is as remotely as popular as something like log4j (the only popular thing I worked on for a while was Xfce, during the 00s). But that's the thing: I don't care (and kinda don't want) that kind of popularity. And if there's a critical bug in my stuff that lingers for a few weeks -- even if it's a security bug -- that's just life. If people want something with faster bug fixes or to-the-minute security responses, they submit patches, or they can pay me. Or, better yet, use an alternative that is already better supported, because I don't want to be paid for this stuff, and take on the burden of the added expectations.
An aside:
> Now let's turn our eyes to log4j2. This project is effectively in the standard library for Java users.
Is that really true? All my (professional and hobby) JVM projects use slf4j+logback. If I depend on anything that pulls in log4j (most of which pulls in v1, not the vulnerable v2), I exclude that and add the log4j-over-slf4j library, which replaces log4j with simple classes that delegate to slf4j.
I've never run into an issue with open source that couldn't be solved by throwing a trivial amount of money at it. Relicensing, bug fixes, feature requests.
> no one -- especially corporate users -- gets to complain
Do corporate users of open source really do all that much complaining without contributing? IME the people with the biggest complaint/contribution ratio in open source projects are individual devs (or trolls) who are not participating as a representative of any company.
In the case of core-js the issue isn't that "nobody is contributing", the issue is that there is one guy with commit authority and he's an asshole who reportedly spends most of his days rejecting PRs from people he doesn't like.
IBM, Oracle, Apple, Microsoft could submit all the PRs in the world and it won't do any good if he says "I don't like your coding style" or "this takes core-js in a direction I don't like."
But...and bear with me as I'm no JS guy and am unfamiliar with that library...how hard is it for the community to fork it and go on from there?
Literally every time I find an esoteric library on Github the first thing I do before forking it or adding it to my dependencies is immediately pull up the "network" tab to see if there's are active branch downstream I should follow.
Perhaps Github can do a better job of highlighting hidden downstream forks to direct people to find more updated and supported dependencies?
can't the governance structure of NPM remove and reassign the NPMish "ownership" and authoritative repo to a new fork in circumstances like the maintainer abandoning it, going to jail, being a dumbass or whatever? If NPM is the authority, it's their own rules that would allow/disallow it, right?
(note: I'm unfamiliar with this project, so seriously I'm asking if/why this is an issue)
Why does that make him an asshole? It's his project, he's free to do as he pleases with it. Even my very modest open source projects sometimes get people demanding I fix or change something. It's ridiculous. It's like there's this unspoken expectation that all available software rise to meet all needs.
> The culture of companies -- nearly all of them, including the one I work for -- that freeload off this work is what's broken.
Capitalism will always try to extract work at the lowest possible cost. If it’s possible to use your work without paying for it, companies will do it. They’ll fund work when funding the work can gain them influence or political dividends.
My two open-source projects, a font and pip-chill, are, respectively, a work of love and something that solves a problem for me. I enjoy working on them. In the past I have worked on other projects, but always to solve issues I had.
Yup, absolutely. I get why this is the case, but when things like this log4j vuln happen, and people at work start complaining the fix isn't released quickly enough, or in a particular way, all I can think is "you get what you pay for, and you were thrilled to pay zero, so here we are".
> The culture of companies -- nearly all of them, including the one I work for -- that freeload off this work is what's broken.
Absolutely. Originally, we had free as in freedom software. Then businesses did their best to redefine it as free as in free labor software. That's the entirety of the anti-GPL movement. The thing about the GPL is that you can dual-license your software for companies that don't like the GPL. It works marvelously as a way to monetize your open source work. Releasing under one of their preferred licenses guarantees there's no way to monetize your work beyond charity. That's what businesses want so many open source developers fall into the trap of donating their labor.
The companies are paying exactly what the price tag says it is worth: $0. What is so surprising about that? If you want companies to not “freeload” then change the price tag for companies.
For the record, that's exactly what I'm saying. Don't use a license that allows freeloading, because if you do, that's what you'll attract.
I disagree with "exactly what the price tag says it is worth: $0". That's not what the price tag says it's worth. They wouldn't be using it unless it was worth a lot more than $0.
I think you are confusing "marketplace value" (what they are willing to pay for it) and "intrinsic value" (your perception of what the "real" value is). Intrinsic value is in the eye of the beholder. Marketplace value is decided in the market place. I am only talking about marketplace value. Which is also what FOSS developers are complaining about. How the market doesn't put market $ value on their work.
I am saying no such thing. Read my comment again. What I am saying is that you get what you ask for. Ask for $0 and that is exactly what you get. So don't act all surprised and start throwing your toys around because the world doesn't work the way you want it to work.
I regret my use of the word "freeload" because of all the baggage it drags with it. I think companies are perfectly legally and ethically fine paying $0 for something that explicitly comes at no cost. But it's also rare that I see a company think about how critical a piece of open source is to their business, and realize that paying in some way (if possible) can be a good way to mitigate business risk. I think most companies don't really consider that risk in the first place.
I completely agree with you. Having worked for a few very large companies, I can tell you that any thinking beyond the crisis of the hour is very rare indeed.
> I simply do not want to be in a situation where my software that I develop as a passion project on the side is holding people's companies together.
People love to hate on Richard Stallman but he was really clear about the motivation for Free Software (which is not the same as Open Source but shares some tenets).
What companies do with the source is their thing. They get all of the benefits and all of the responsibilities. But the beautiful thing is that if that maintainer is dead or missing or no longer interested, you CAN fix it. Which is very difficult / nigh impossible for closed source.
Except you can't because hundreds of thousands of project have "log4j" in their dependency list not "wyldfire-fixed-log4j". If log4j broke and there was no maintainer, a fork would not fix things.
> hundreds of thousands of project have "log4j" in their dependency list
That's on them. They can migrate to wyldfire-fixed-log4j if they want, or to whatever other fork they want, or they can keep using the old busted shit. It's up to them, there's no problem here.
Sure you can fix it, change the "log4j" in your dependency list to "wyldfire-fixed-log4j". You can't do that with closed source (either because you care about legalities, or because you have no way of obtaining a compilable and readable source code).
Until all hundreds of thousands of projects have changed that, it'll take time.
That doesn't mention the fact you now also have to fork unmaintained projects relying on log4j to use the new version. If you're developing a major java projects, that's potentially thousands of dependencies you have to patch.
I'm not suggesting that closed source is the solution, I'm saying the current system is not sustainable and neither is just forking projects. Because which fork do you follow, and how do you make sure all your dependencies follow the fork you want and not an unmaintained fork?
Some package managers (eg yarn , cargo) have a solution for that and allow you to specify a local resolution override that will apply to all dependencies.
But again, that means EVERY single product, open source or not, will have to patch their deployment to use the fork instead of simply using the updated version of upstream. Permanently no less if it's unmaintained.
Meaning every single Java product would have to include that "if you want to use log4j, you have to include this patch line to use a fork, because of unmaintained dependencies".
That just ossifies log4j and fixes nothing. Patching dependencies in Cargo is not meant to permanently replace code, it's to be used while you're waiting for an upstream merge.
Correct, all those other people will have to manually find some fork or make their own, repeating the same work thousands of times and ossifying that some part of your java build system now permanently includes a section to patch log4j dependencies.
You can not force your dependencies to do what you want. You can only patch the problem for yourself and maintain that patch in the build system, or you can fork each dependency in the chain, maintain those and then your build system is cleaner.
Forking yourself is not scalable for fixing a 10/10CVE and I don't get how people think that somehow "fork it" is a viable solution across the entire industry.
This is not about forcing my dependencies to do anything, this is about caring about maintainers and maybe ensuring that the bedrock of our ecosystems aren't maintained by unpaid volunteers in their free time, exploiting the sweat on their backs for our amusement for free. Forking the project is just spitting on their efforts on top of that.
Entirely agree, we should find ways to reliably support upstream. But that is a different issue, and unfortunately it is one that the main beneficiaries are not willing to solve.
Forking solves the issue of an upstream dependency not willing to fix a bug.
Does it matter that other products don’t patch something that yours does? Like, sure, it’s unsatisfying from an ecosystem perspective, and one would hope for fixes to be incorporated upstream. But if they aren’t, who cares if other products are broken after you’ve patched the ones you’re responsible for?
It does because now I pull in a dependency that indirectly relies on log4j instead of my favorite fork of log4j and I end up having the same CVE in the project anyway. Yes this needs to work ecosystem wide, otherwise you have fixed nothing at all.
How would proprietary software make this better? You wouldn't even have anything to pull in!
Is your argument "having the source code and the legal rights to fix this bug even when nobody else wants to or even can fix it is not good enough because not everyone will use my fix"? Because good luck with proprietary software then!
My argument is not closed source. My argument is that "just fork it" does not magically fix all problems. Closed source makes this worse but "fork it" is no answer either.
I believe I made this very clear on my very first comment.
Right … open source doesn’t guarantee an absence of problems, only that, in the worst case, a user can repair a problem herself. As you note, that’s strictly preferable to closed source, where a problem with a dependency is not guaranteed to be fixable by the user. Isn’t that enough?
That is not sufficient no. As a user, I want to be able to support developers so they have the time to fix things that go wrong. That the log4j Maintainers are entirely unpaid for maintaining what amounts to the bedrock of the java ecosystem is a tragedy and that people continue to argue that this is how it should be are simply exploiting what amounts to slave labor.
> As a user, I want to be able to support developers so they have the time to fix things that go wrong.
As an individual user, you shouldn't be required to. It's not how or why the project started, anyway. Maybe big companies whose system depend on log4j could fund it, yes.
> what amounts to slave labor
That kind of hyperbole doesn't help the discussion. The situation is nothing at all like slave labor.
I have plenty of clues of what slave labor is and big companies exploiting the hard work of people working for free without paying them is definitely pretty damn close.
This is reddit tier derangedness, any one of the millions of people living under real slavery, where you get lined up to a wall and shot if you refuse to work would gladly switch places with anyone living under what you dream up to be "slavery".
I misunderstood you then. I agree with your statement. Open source doesn't solve all problems, just some. There are hard problems about dependency management and vulnerabilities that are not magically solved by something being open source, I agree.
The problem is, my dependencies also have dependencies. If the problematic dependency is any more than one degree of separation removed, you're back to square one.
How many excludes is Java going to ship is forking the problem of unmaintained libraries away becomes too much? When it reaches 5kb? 10kb? 100kb of excludes?
Strictly speaking in the Java space that's a perfectly reasonable assumption. It's a bit more work but you can just substitute the jar/modules for log4j following the build with the patched versions.
At the end of the day it is just a bunch of class files in jars/zips which makes patching a lot easier.
Hot patching a jar is not a scalable solution in the long term, especially if you're considering that in a larger project there may be multiple unmaintained projects that now need permanent hotpatching.
At least with gradle you can easily add some logic to the buildscript to substitute all instances of a specific dependency for a java library/application with a fork.
It's only a handful of lines of code and it is technically a bit hacky but it's really no worse than any of the other jank you are forced to do when building any moderate to complex gradle based java project.
And when another library is unmaintained and breaks, you add those few lines again. And again and again and again, until your gradle file is 90% hotpatching your dependencies.
Yep but that's just the breaks. Especially with ecosystems that have tall dependency trees.
Luckily those few lines can mostly be shared and you end up with a handful of lines and a map from old dep to new dep which makes it not too painful.
This whole issue is why I don't like these ecosystems but at the very least in the Java space dealing with this issue isn't too painful. I can't speak for the JS space but this is also a pretty trivial fix in the Rust space and it isn't too painful with C++ or C projects. Nix (mostly used for Haskell but it's a pretty solid universal package manager) has some pretty good tooling for modifying upstream dependencies. Spack (package manager specialised for HPC and embedded projects) has really good support for this as well.
My point being that people have run into these issues in the past a lot in certain spaces and as a result those spaces have come up with solutions for this problem a long time ago. It just so happens that for the most part the average dev doesn't see a lot of that because these issues get dealt with upstream or just aren't common in most industries. The embedded industry is particularly used to this considering how much of the kit from manufacturers is just outright wrong or broken 3 levels deep. The only reason I'm as well versed with this as I am is because I've been in the embedded space patching over broken HALs and I've bled my blood dealing with legacy enterprise applications that were initially written in Java 1.1 and haphazardly dragged along over the decades.
TLDR: This is an ugly fix but ultimately it's the best ugly fix to an ugly problem and every software ecosystem eventually gets to deal with it once they get old and crusty enough.
This isn't only about companies, people who develop open source software on their own are just as affected by log4j. Funding and resourcing can at least help people and maybe incentive handing the project to someone else.
And if you do that everytime an unmaintained project gets a 10 severity CVE, we'll have that at 200 lines in no time. Proabably petition whatever generates your Pom.xml to auto-include those lines.
Code doesn't just "break". It still works the same. If a vulnerability is discovered you either update the package or switch to a fork. Switching is not really that much extra work compared to updating. This issue has really nothing to do with open source except that you have the extra option of forking.
I argue that if your code gets assigned a 10/10 Severity CVE, then it broke, even if nothing changed. It just broke a while ago.
Switching one library is not much work. But if it becomes the standard approach then the first time you fire up your java project you either spent 30 minutes to put in all the exclusions to provide your favorite forks of dead projects or your pom.xml will already be 5KB large on generation just for those exclusions and patches.
Thats the problem. If you use say React then you are using it as is without any warranty implied. React is the equivalent of an aircraft in complexity when looking at its dependencies and then the browser stack itself on top!
React gives you a free copy of an aircraft and will probably maintain it for years. But maybe they rely on an altimeter developed by a poor person who decides they dont have time to work on it because they need to help their mum.
Well thats everyone elses problem now.
but the ease of download and use of React and other code libraries creates a sense of entitlement.
Yes if its broke and you need it fixed you have to pay someone now!
Off-topic but very important:
The widespread misuse of the word 'dependency' is very very icky, linguistically speaking. This word originally meant: 'in a state of being dependent'. Usage: "Ronny hated his dependency on the kindness of strangers.". But it's being used to refer to the 'dependent', as well as the 'dependee', which is very poor form:
I don't think that is any issue whatsoever, the software engineering world has largely agreed on the usage of the word dependency, doesn't really matter what linguists think. Language is consensus, not thesis papers.
The original meaning still works. In the software world, where abstractions abound, each dependee of yours can be said to add one 'state of being dependent' to your set of requirements. That's what it meant originally in this young field; when an author chooses to use a library instead of writing their own code, they're adding a requirement for the user ("Hey, you gotta have this thing already installed"). The software is in a state of being dependent on each of its dependees, individually. Each such state could be removed by replacing the library, and thus there'd exist one less 'dependency'.
----
Yes, this is mental gymnastics, another fine staple of this glorious field.
That doesn’t change the fact that open source users are the welfare queens of our times. As long as open source software exists, lazy degenerates with no skin in the game will feel entitled to keep demanding more and more. That’s why open source software needs to die.
I don't know if you're a troll, or if you really managed to stuff three different far-right rhetorical tropes into one sentence in order to declare the cooperative development of software as immoral, because megacorps can't force people to pay for something.
> What companies do with the source is their thing. They get all of the benefits and all of the responsibilities.
I know this very well and for some irrational reason it still makes me anxious to think about the many people relying on one of my free-time project that is used in classroom and medical settings. When there is a nasty bug found it's hard to shake the feeling of responsibility.
I have disabled the counting of downloads for this reason, I would rather not know just how many people rely on it and instead focus on improving it without pressure.
>> When there is a nasty bug found it's hard to shake the feeling of responsibility.
I know right? Someone just opened a github issue for a CVE in one of our dependencies. It's only relevant if you're opening a .DXF file from an untrusted source, so it doesn't seem terribly relevant but yet... And updating to a newer version would take effort, and we want to replace it with something else anyway which would take effort. None of that effort is where I want to spend my free time. But I do work on the software because I like it and really want it to continue being around and useful, and that isn't going to happen unless I (and others) make it happen.
similarly, free software (in RMS's sense) does not mean you cannot charge for it. however this has practical considerations which are still open problems
I get a little nervous when the responsibility of incentivizing FOSS is framed as a personal responsibility. Isn't there a deeper conversation to be had about how we allocate resources as a society to help build fundamental infrastructure instead of placing the blame on individual people or corporations on their lack of sponsorship or donation?
My apologies if this is flame-bait. I really don't know what the solution is. I certainly could admit that shaming people into contributing on an individual level is a valid tactic and that a good state to be in is to have individual and corporate sponsorship for a long tail of FOSS projects. I worry that focusing on the failings of individuals to fund projects takes attention away from other alternatives.
I really don't know what the alternative could be. UBI? A wide array of government grants for FOSS?
It's not flame-bait. We, as a society that values FOSS, should fund it, but not at the personal level of "I use this software so I'll pay for its license". FOSS licenses should state nothing about paying for the software. You should not feel bad because you are not paying FOSS at the individual level.
Taxes and allocation of funding at a societal level might indeed be the answer.
They benefit from FOSS as well, so maybe if we could do some adovacy. After all, I support paying taxes and funding stuff that doesn't directly benefit me.
> If log4j2 is responsible for your company's success, you have a moral obligation to donate to the person who creates this library thanklessly.
That's a big if, log4j is a logging library after all. This is an understandable position to hold for other types of dependencies (think react, database, UI components etc.) but the logging library is very far down in the ordered set of projects I'd donate to.
I will however leave a mark and donate to the top 3 dependencies I consider most important in my (non-java) side project.
Edited to add: If you offer your software at no charge, you shouldn't be surprised if people accept that offer. So I even disagree with the "moral obligation" bit. Doesn't mean that donating is a bad thing, however.
> If you offer your software at no charge, you shouldn't be surprised if people accept that offer. So I even disagree with the "moral obligation"
Sure, but don't complain then, if it doesn't work, or you get hacked using it. You get what you pay for. Nor should you be surprised if eventually, no one decides to "give you for free" something you value so little.
Open-source is only broken in the sense that we frequently conflate it with free as-in beer.
IMO, fewer things should be free in general, regardless of whether the source is open. Charging money limits the amount of low-value users and the problems that come with them, it rewards the those contributing their expertise, and it can be a replacement for junkvertising.
So I agree with the author, but perhaps not in the sense that open-source software needs to charge money. It depends on whether the software really necessitates pay and exactly whom should be paying. Charging all users a fee can be counterproductive, but only charging for commercial use by companies can be a way to go.
If I had a nickel for every time I've seen an article claiming "open source is broken", I'd have enough nickels to live on for some time.
The other side is that everything else is broken, too. How much should you really trust a package that you cannot audit and that is maintained by an unknown group of people with unknown skills who are also subject to the whims of quarterly earnings reports? Oh, and you'll never hear what their screw-ups were.
Can you really trust those average 3 engineers you work with to build any sort of complex piece of software more reliably just to get started with the project you're actually building?
I get the feeling that you misunderstand the gist of the article.
The gist of the article is not "I didn't know you were going to get rich off of my work (and I'm pissed off by that)". The premise is - in my reading -
"Don't point the finger at me for writing bad software in my own free time, when you didn't even consider contributing to it and don't try to shift the blame when you have to face the consequences of your own cheap behavior".
I see the author annoyed that companies don't want to to be their patron to just pay them to work on random things that they have fun working on
and attempting to leverage this issue to try to draw attention to this "injustice"
as someone with a full time software job: I wish I could only work on things that interest me...
rather than spending 80% of my time working on boring things and dealing with customers who set deadlines and expect to receive a specific product that they're paying for
I got the first interpretation, but I think yours is what we should be talking about. The responsibility for this bug is not on the maintainer, more so on the company for accepting it into their codebase without any vetting.
Open source users are the welfare queens of our times. As long as open source software exists, these lazy degenerates with no skin in the game will feel entitled to keep demanding more and more. Open source software needs to die.
I know what you want to say, but "welfare queens" is really a bad way to phrase it.
> The "welfare queen" stereotype is driven by the false and racist beliefs that places the blame of the circumstances of poor black single mothers as the result of their own individual issues, bringing forward racial tropes such as their promiscuity, lack of structure and morals, and avoidance of work. [0]
You seem to be unaware that there is a large and ever-expanding segment of 'society', in the US and UK at least, composed of people of all races and even social status (ghetto trash up to 'middle class' and beyond), both men and women, whose seeming sole objective in life is to have as many kids as possible and sign up for as many government checks as they can, so that they can 'live' exclusively off the backs of working people in society while contributing absolutely nothing of value themselves--not even to the actual welfare of their own children, who in the majority of cases 'grow up' to become equally unproductive leeches themselves, having learned by example from their own riffraff 'parents.'
In the UK, one such group are known as 'chavs.' It isn't a term of endearment.
Given the ignorance evident in your post, I wouldn't be at all surprised to receive a heated reply from you, calling me names and attempting to argue this inarguable fact, which is clear and obviously factual to anyone who has spent any time at all living out here in the real world aka 'flyover country.' Have you ever even been to jail?
Welfare queens come in all shapes, forms, and sizes these days. Some of the worst offenders are large corporations, though the largest by far are governments, of course.
The world is full of leeches who want something for nothing. Like for example these wealthy entities who in some cases make billions of dollars off the backs of open source developers, while the devs themselves may be on the brink of starvation, eating out of dumpsters and living in their car.
And of course, the Wikipedia propaganda is considered absolute truth, while my factual real world experience is 'flagged' by some SJW virtue signalling city slicker, who is angry at anyone who speaks truth.
You cannot argue with cold, hard truth obviously, or you would be doing so, instead of flipping your wig and downvoting/flagging my post.
Here, let me tell you more about these people you obviously know nothing about. I've met, interacted with them, spent months in jail with them. I know exactly who they are and what they are about.
They swap tips and stories and plots and schemes for signing up to as many welfare programs as possible. The more checks one has coming in, the higher one's social rank is within this system. EBT cards are used to buy certain items, like 24 packs of soft drinks being a major one, which are used as a sort of currency, exchanged at half price for hard cash, which is often taken straight to the drug dealer. Fact.
There is a pride among the group based on how much they can rip off from society vs. how little actual productive work they do, ideally none. 'Hustles' are the primary form of work, usually involving drug dealing.
Theft and robbery is another primary occupation of this crowd. They steal whatever isn't nailed down, and sell it on Craigslist. When confronted, they brag about it and show no shame or remorse whatsoever, like the one guy I went to school with for example whom I noticed doing this.
They spend their lives in and out of jail--and they are proud of this. They love going to jail. That's where all their buddies are. The only thing they like better is going to prison, because it's a lot better than jail, with much more to do, more hustles to run, and more criminal minds to link up with. Fact.
Having returned from jail/prison, they continue with the same life choices. Proudly.
They do things like steal large air conditioner units from schools and churches, or catalytic converters from cars, or copper wiring and plumbing from houses, and melt them down for scrap. To buy meth and heroin. Fact.
Every one of them thinks the world owes them something. The sense of entitlement is apparent in their every word and action. People with honor and dignity who prefer to do actual work are like an alien species to them, treated with scorn and contempt.
I've personally been ripped off, robbed, and screwed over in countless ways by this crowd. Matter of fact, my shop was robbed just the other day. They took several metal items that I desperately needed, like two radiators, one of which is for my generator. I'm not rich. I'm living hand to mouth, literally eating out of dumpsters to survive. They don't care. The only thing they care about in the world is themselves.
And is it any wonder they turmed out this way, when everybody in the entire country from President and Bankers and CEOs on down is exactly as selfish and uncaring? Who do you think molded them into such criminals?
Please, downvote and flag me some more, so you can prove how selfish and disconected from reality you are also, presumably isolated in your big city enclave in some coastal city. Out here in flyover country we have no such luxury.
This country is burning, and frankly, that's exactly what it deserves. Maybe when the destruction finally reaches your doorstep, you will finally get a clue.
‘Open Source’ has no implications about whether the writer gets paid or not, but I’ll set aside this semantic criticism.
There are many many FOSS projects where contributors get paid a great deal of money. Universities sponsor contributors. And most contributions to a project like say Kubernetes come from Google’s employees. Government agency grants. Et cetera. But if that’s not enough, tech giants throw a lot of money at places like the Linux Foundation to ensure that FOSS projects get maintained (and thus the maintainers get compensated).
The fact is that a little ‘buy me coffee’ link is simply an ineffective way to monetize a FOSS project. But FOSS is not broken. Some of the greatest things in computing today are FOSS.
Whatever I put out there is mostly to keep HR folks happy to check their bullet points, or done under straight GPL.
Valuable stuff, only with commercial contracts.
I also buy books from folks, or do occasional contributions to all ecosystems which are valuable to me.
Like myself they have bills to pay, however none of them (buying books or donations) is a sustainable business, if only a couple of people occasionally do it.
Somehow I think open source has legitimated piracy, in the sense that those that would pirate, now feel safe because license, and just go on their merry way and don't need to fear that the economic activities surprise audit would close down their shop.
You don’t owe anyone that uses your free software anything. If they rely on it and something is broken, they can fix it. That’s kinda the point of open source and it’s a good thing.
This is a point I've been pondering about recently, especially since the attacks against Free Software and RMS.
I've been convinced of the inherent good that openly available software is, both for users and developers, and for society at large. I want to continue contributing to the common goods. But I am also fully aware that Google, Facebook, Twitter, Instagram, Snapchat, Tiktok, and all other platforms exploiting users' privacy and controlling so much of our digital lives could rise to power that easily because they had a trove of open source software to build on, software for which there is no counterparts needed. That is what the MIT, Apache, BSD licenses and friends allow you to do.
That is why my opinion now is that if you want your work to be open, you should not make it open source "only" but fully Libre. Use a copyleft license. If other developers don't want to pay you in money, at least their production should become a common so that the entirety of society can benefit. Don't give FB more power to turn elections in the direction they want; make it so that someone else can _only_ build a platform where users, and as such people, remain those in power.
Open Source Software benefits those in power, and unfortunately it is not us who hold this position.
A good analysis of what open source enables - Facebook et al. were able to build their companies more easily using it.
But you forget to compare it to the alternative, where there is no significant open source or libre software available.
You can't run Linux, you have to trust Windows not to backdoor you. There is no Signal or Matrix or other encrypted messaging - or if there is, you have no way of verifying it. If you want to write a .txt file, you must pay for a close-source text editor. Or a very expensive compiler, if you're a programmer. Is the compiler backdooring your code? Maybe. You must find paid alternatives for all the free software you rely on, for work, or for your hobbies.
And who builds that paid software? Not a garage shop - they could never afford all the compilers and libraries and tools necessary. Only billion-dollar+ companies, engaging in incestuous cross-licensing, letting each-other use their tools, and crushing any upstarts.
If open source (or even copyleft) benefits those in power, closed source benefits them infinitely more.
Indeed Open Source also benefits Libre Software today. But do we really know what the ecosystem would be like today in a world where only Copyleft existed ?
Linux itself is GPL, so are some of the distributions. Hurd hasn't seen adoption, probably because the alternative is good enough.
Signal is still there, client and server. But maybe it wasn't needed because ejabberd, one of the biggest XMPP servers, was already there and powering all messenger platforms.
You're assuming that if developers didn't license under non-copyleft, they'd license under proprietary instead; there's no real reason to believe this. And as many examples have shown, many of the tools we use aren't actually made by billion-dollar companies but by single developers on their free time. The examples in the article show it, Werner Koch (the guy behind OpenPGP) has been asking for funding for years (decades ?). ssh, curl, ...
Anyway, that world is so different that we'll probably never know how it'll work, so here is the area where the optimism of people are visible and I myself believe Copyleft could have been a success.
Ah, sorry. I misunderstood you as talking about the problems of open source in general, but you were referring only to non-copyleft open source. In that case I think we agree.
Companies will use whatever is at their disposal to grow faster and more efficiently, this is the free market working as intended (and isn't a bad thing by itself: see free software companies like SourceHut benefiting as well).
I think the core of the problem lies in distribution. We've gotten so used to other people distributing our code for us (through the use of package managers and such) that we've made it hard to actually have a dialogue with our users. Many consumers of packages just know their dependencies by the npm package name, rather than actually seeing what the person has to say about the software, how they plan to maintain it and for how long, etc.
Even things like licenses are really just ignored at large, with there being a general mentality of "it's on Github therefore it's probably MIT". There was something I remember reading a bit ago about a Go project whose license was simply "you do not have permission to use for any reason ever" which was depended on by projects from big organizations such as AWS[0].
This is mostly just a rambling and I don't have any concrete way to solve this, but I think it should be taken into account when assessing whether the problem really lies in the individual license choices of developers, or whether this is some kind of effort by big market actors to keep open source solutions at a subpar level of quality in comparison to commercial offerings (for example: some of Microsoft's VsCode extensions only work on the proprietary version, not any open source forks[1]).
Open source is not "broken" - it's working exactly as designed, where anybody can obtain the software for no cost, and compensation for work done is voluntary.
If you want guaranteed compensation for your work, work for a company or require payment for your software. Releasing it as free software and then complaining when you don't get the donations you wanted is just being entitled.
Right, so your solution to avoid relying on an open source library for your company's success is to use an open source adapter to rely on another open source library. It seems to the unenlightened like you're still depending on an open source library for your success, you've just changed which one?
Shuffling the deck chairs around is one solution, I suppose. If all the deck chair makers get fed up, what then?
356 comments
[ 2.5 ms ] story [ 293 ms ] threadIt's not that it's free to pick and to use. It's that some/most people too often associate "it's free" to be equivalent to "I don't need to care about it, like, at all".
It's that some/most people don't understand that, whatever they take, they become dependent of, for the better and for the worse (insert Marie Kondo cue here).
The interesting thing here is that there's a full new line of work for Info/OpSec opening here: ensuring that your software supply chain is not only secured, but also properly funded and supported.
That's like... common sense in so many "old" industries.
There's no real way to secure finegrained node.js or python etc deps, since you have no clue if the original author who signs his sources should be trusted, or was malicious from the start and just biding his time, let alone everyone who contributed to every package.
What would help is independent audits and where needed help with hardening like fuzzing and asan / valgrind / static analysis. Just an extra security-minded eye on patches in realtime would be a big help (and maybe would have found the logging bug at hand).
You can keep dreaming otherwise and enjoy a steady stream of security problems from your leeching.
Exactly this. I think the problem is that OSS consumers often have a complex that they are entitled to "good software". But I doubt that the solution is to make it so that the producers are "entitled" to financial compensation. I can see situations where that backfires -- satisfying the producer's "entitlement" can exacerbate the consumer's sense of entitlement and just create an entitlement arms race, and stress out open source producers.
Following in popularity from these is "'free' as in 'free puppy'"; which emphasises that you'd be taking on a burden of responsibility by using it. -- At the very least, if you're using it, it may have bugs.
If they want this legacy not to be a burden, they need to take appropriate steps: contribute to it, through the means of their choice: developer time, advocate time, money, structure, anything.
It's (a bit) like all industries sourcing from the environment (trees, vegetables, minerals, oil, gaz, etc.): it's all available for free, let's pick it. Only, if you're not careful about the sustainability of it, and the consequences of sourcing these, it will backfire at you at some point. Badly.
What is? What's the "it" that "absolutely is $0 free to pick and use"?
A: The software, as-is (as-was) at the moment they downloaded it.
What does that "it" not include?
A: Any guarantee of support, bugfixes, maintenance or future development.
Those all cost extra, or one is free to go without.
That, as I seem to recall someone repeatedly pointing out here, is how the free market works. HTH!
How do you ensure that's not the case? Careful license choice, "you're on your own" wording or something else?
Like, if someone created a unicorn startup rivaling Slack using Elemental-IRCd, how would you react?
(I have massive respect for anyone maintaining an ircd, btw, having attempted to contribute to one a long time ago)
I've kind of given up on elemental-ircd and left it unmaintained and archived, but I would probably send a job application in to that place if said unicorn startup happened. A few people have tried to take over elemental in the past, but as a whole the IRC ecosystem is on a downturn so they don't last long. It's a complicated situation though. At some level I'd be shocked that they managed to turn that pile of shit into something usable!
it's a well written article and you got me agreeing with what you are saying. it's surprising to read comments here that start with "open source is not broken" but proceed to repeat everything you wrote in the article...
And I disagree with both of these statements. Open source is not broken and I'll continue to write useful software, even if you don't pay me, because it's fun.
The actual problem is concisely present in the article:
> There is this culture of taking from open source without giving anything back.
The problem is not with open source, but with how capitalistic systems interface with open source - the same way the interface with any public good. It's the capitalist culture that's broken; the capitalist culture of rent extraction and of short-term profit optimization.
The problem is definitely not YOU. It's not like you could do anything about this situation yourself, say by making contributions to projects you'd like to support. No, it's those evil capitalist white men who use terrible phrases like 'welfare queen' to hurt the feelings of helpless black ghetto women, obviously. We need communism, and we need it now.
I also know there are organizations like the Software Freedom Conservancy who helps to handle these kinds of things who I would highly recommend [1].
I used to donate to a lot of FOSS projects, most recently FOSSHOST. Both the project and myself were heavily attacked and accused of all sorts of things for doing so [2]. It has left a chilling effect on me and others I have spoken to. Most of the people who engaged in the online attack were not even developers, but simply "IRC Admins" of projects.
How does a company or individual support projects financially with this kind of social ecosystem?
[1] https://sfconservancy.org/projects/
[2] https://fosshost.org/news/freenode
It doesn't make sense that businesses don't invest enough in the software they use (paid commercial software or otherwise). That is only to the detriment of the businesses that don't care to invest (their unique use-cases are not improved). It's not quite a tragedy of the commons because nothing prevents the people who do care (Google, MS, Amazon, FB, IBM, to name the large ones) from contributing their improvements back to the ecosystem, and they retain the full benefit of their work.
It is absolutely an unequal exchange of goods for labor for most businesses but the near+zero marginal cost of replicating software means that it's a negligible loss for the authors, if that. The solid benefit for most programmers and system administrators is that they get to use high-quality Free/OS software in the jobs where they do earn money. At least for me, business concerns are secondary; I want to use quality software with a good ecosystem rather than know for sure that my employer paid money for the software that I have to use.
The problem for me is, that while calculating how much I theoretically should spend on the OS I use for example (gnome+fedora+linux kernel,etc), it would be actually cheaper to pay for a windows version+microsoft cloud/office suite or switch to the apple ecosystem.
Same applies for programming frameworks I use.
Doesn't that mean opensource is inherently impossible to use ethically as a private person?
So how do you decide on how to deep and how much one should pay?
Isn't this the best position to be in if you want to get paid? "You've built your company on top of my project and now you need this bug fix/feature yesterday? My hourly rate is $$$"
I agree with the author: it's time that value be compensated by real financial capital, not empty promises of status in some mythical open source community.
The most concise counter-example I can come up with is: What would change if that XKCD picture had the critical log4j2 component replaced with closed-source "McA$$hat logj2+ ENTERPRISE" trialware+commercial $$$$ licensed product that was thanklessly maintained by severely underpaid hire-and-fire contractors in a 3rd world country? Nothing. Well, it'd be a lot worse because you couldn't fix it.
What's broken is larger umbrella projects and products, open-source and commercial, not understanding that they own and are responsible all the dependencies. All of them. Down to the very bottom of the stack. Whether they bought them or got them for free. Each and every dependency must be evaluated, and if it's appropriate, you could delegate the risks to a trustworthy sub(contractor) or project.
What if that project gets abandoned? What if "McA$$hat Inc." goes out of business? Or either just changes direction or quality suddenly? Will the security bugs be reported or covered up or remain undiscovered because nobody uses the thing?
I currently trust Linux. I trust the "big" distros. I trust a lot of larger, well maintained opensource projects. I'm very hesitant about things like node.js and others that have very fine grained and super-easy automatic dependency management and build systems the just pull whatever the latest thing is for hundreds or thousands of dependencies. I really don't trust most commercial software because it's always just as broken, but you can never see it nor fix it.
A lot of the article focuses on getting paid. I totally agree and the market will definitely correct when it becomes visibly critical. You can get paid to maintain opensource commercially and that's probably the best of both worlds. There's going to be a lot of people working for a lot of companies getting paid to fix or replace log4j2. There's going to be a lot of people paid to figure out how to get better control over that XKCD picture situation.
But Open Source isn't broken, it's the cure just working it's way along by making that picture visible.
To me, it seems like this blog post is something you've shared freely with the world, with no expectation of getting direct financial compensation for it. You have an idea you want others to read and think about, so you wrote it down.
To me, this act of publishing and sharing your thoughts freely in the hopes others might find them interesting shares similarities to free software. You wrote something that you think others might find interesting or useful, and you want to share it. That statement applies equally well to FOSS and blog posts.
What do you see as the major difference? Is it that OSS rejects copyright, so the code can be used for profit, while your post can't freely appear in, say, a published for-profit book of opinions on OSS? Would you be opposed to this post being published by someone else and you not getting money for similar reasons that you blog about here?
Is the difference in expectations, that people expect support for software, while people expect nothing of blog posts? That a blog post is finished and may be thrown over the wall, comments ignored, typos uncorrected, and that feels "fine", while software thrown over the wall with issues ignored and no future changes planned feels "weird"?
Is there some bigger difference?
Is there a way to reduce this difference, to create an environment or structure where you would share code, just as you currently willingly share your thoughts and writings on this blog?
As for the time to write these posts, yeah I'm making nowhere near my market value for this kind of writing. I've considered adding ads to my blog, but I still feel kind of philosophically uncomfortable with "selling out" like that. My job really does make sure that all my needs are accounted for and I am blessed to be in a state where I have financial excess and can make additional private contributions to other projects.
At some level though my blog is really a sink for my anxiety. Just being able to put words out into the void and knowing that someone is gonna read them helps a lot when it comes to making things a lot less scary in the world. I really do just throw them over the wall when I'm done though lol. Sometimes I'll do a typo pass but most of the time I write well enough that my first pass turns out to be the last pass unless some critical problem is found. This doesn't happen often though.
I do occasionally make volumes out of my writing and sell them on Itch (https://withinstudios.itch.io/), but I have only ever made $250 on there in total; nowhere near enough to fund the creation of the media in question. I also don't advertise my Itch shop very well so that may be partially on me.
Mostly though the goal of this post was to make people think about the issue. I have succeeded.
What is broken is companies using open-source to build their products, expanding to billion dollars total revenue and not giving anything back in the long run.
This will - as shown in the latest example - come back to bite them.
It's the classic tragedy of the commons; everyone is willing to profit from the public good and nobody is willing to invest resources into it.
One way to hold them accountable is to apply regulatory pressure in case of security breaches, which has started to happen (albeit not nearly enough). Is there any other way I'm not seeing?
Not only would this lower the risk of fatally flawed public software projects, maintenance of these systems in the long run would also not depend on just one company with an artificial monopoly anymore. This would also create a healthy ecosystem of paid open source developers.
Just an idea.
It's part of the capitalistic delusion that only what a price label has attached has worth; you are conflating "worthless" with "priceless".
Sorry, I don't know what you are referring to. Are you refuting any of my arguments? If so, please let me partake in your reasoning.
> The problem is that some OSS maintainers think they are the same, expecting the intrinsic value of their work to automatically convert into market value (them getting paid).
I don't think that this is what is currently happening, isn't it?
You don't hear the log4j maintainers complain that all these big companies leech of their work and they are owed. Many of these companies do make quite some nice profits and very seldom is the dollar that gets paid back voluntarily. And that's fine for pretty much every FOSS developer. Very seldom I hear about FOSS developers angry that companies use their product to make money. Usually these developers switch to different, commercial licenses.
Quite the contrary; it's these big tech companies that are in trouble. They are in trouble because they are liable. The log4j developers are not responsible for fixing these bugs. Why should they? FOSS licenses come with explicit denials of liability.
The big tech companies are in trouble because they saw something for free and saw that they would save the market value in expenses for a similar commercial product. But they forgot that they are also relying on voluntary labor that comes without responsibility by the authors. And now they are on the hook.
They should have recognized that by skimping on the dough and using FOSS software the same way they use commercial products they also took on unmitigated risk. And because they are so cheap, they didn't consider mitigating that risk by supporting the development of the software they so depend on.
If just one or two dozen companies had paid a measly few dollars every month to the developers of log4j, this could have all been avoided. But they were shortsighted and greedy, as capitalist companies have to be shortsighted and greedy. And now they have to own the mess they made.
Suites them right, I say. Though I doubt they will learn their lesson, don't you?
I would have happily given to log4j, but I didn't know that they were in need. Someone has to make it easy to keep track of this because it's never going to be a priority for businesses
Are we really going to blame log4j2 authors who, for all we know, don't care if someone else is using their project?
Check the security of the infrastructure (is it one guy?), check whether some the code is correct (either randomly or systematically, not just checking the first file you see), etc.
What's the incentive? Well, checking your dependencies is a way to upskill. You learn as much reading code (especially the code you are relying on) as you do writing code, and most of a programmer's job is learning.
Would millions of dollars of donations over the last decade have caused log4j to not have the vulnerability?
This is a half-baked idea right now, but I think there’s something to it. A lot of the issues with open source stem from the friction of donating. Reducing that would incentivize people to work on libraries that are popular but neglected. It would also help devs capture some of the value they create.
We (programmers) need to explain this to the money people somehow. No company I've worked for in my 10-year career would have been able to exist without open source. They would have had no product. If you're extracting significant value from this ecosystem, you should help fund it, even though there isn't a toll booth on the way in.
Those outliers aside, consider the alternatives. The first one I can think of is to put trust in closed source software, in many cases written by MAMAA. We have enough historical evidence to know that represents a nightmare scenario that we should actively be working to get away from.
That's why I agree, we should be trying to make the open source ecosystem sustainable. What I think we'll need, as a bunch of normal users, is a way to present these cases to our $workplaces, to get the funding or sponsorship in place. And an easy way for companies to do that, which slots in with their own practices.
If some guy in Nebraska maintains some library that is very useful and your company relies on it and does not pay him, you're asking to wind up relying on an unmaintained project eventually. If I maintained something extremely valuable and found out a core google product relied on it, I'd stop maintaining it.
It's not like tens of thousands of projects decide to pull in left-pad. But tens of thousands of projects do decide to use React, which (I'm guessing through its own gaggle of many dependency layers) happened to pull in left-pad.
Taking the option of "I'll just build everything myself" then is not really a viable process in today's world, where all of your competitors will be using tons of prebuilt stuff (unless, perhaps, you have the productivity of someone like Fabrice Bellard, but the reason he's so well known is because his abilities are so rare).
I think the real fix is that dependency management tools like NPM and Maven need to make it much easier to "override" dependency package names so that, if a critical issue is discovered, you are not at the mercy of the current maintainers of that package to quickly get a fix into production.
I want it to be practical to build software which only depends on a small number of trusted individuals or organizations beyond the OS and compiler. C++ manages it better than newer languages with built in package managers, and dependencies rarely depend on transitive dependencies, though it comes at the cost of adding dependencies (especially transitive dependencies) being extremely difficult (I hear Meson subprojects help, and CMake has their own worse version I didn't try).
I'm probably mistaken, but I thought in maven managedDependencies was exactly this. Please correct me if I'm wrong.
It obviously depends on the scope of things but I tend to see a future where this building everything yourself might be an advantage again. Because most of "this prebuilt stuff" adds layers of complexity because of generalizations you don't need and other abstractions.
In my experience this gets worse and worse every year. We software developers are already drowning in a flood of languages, frameworks and so on. How often do I see a framework Y built on top of library/framework X to abstract away something from X. Not only you have now both dependencies but at some point Y lacks a feature you need (which is provided by X). Now you have to pull up X and mix with Y and everything just got worse than just using X from the get go..
I more and more think we need some back to the root movement and also keep in mind to always choose the simplest solution.
Along with a sibling comment [1] that disagrees with you, I want to add that I am starting to do this myself.
I am close to 30, and I would not say I'm particularly productive. In fact, I would say that I am far below average on what most programmers call "productivity," by which they usually mean "amount of code written." I write code slowly. But I write good code.
My library of stuff is basically made to work on POSIX C and Win32 C, with no other dependencies, including the build system. It has resizable arrays, hashmaps, structured concurrency, trees, UTF-8 strings, string builders, filesystem handling, linked lists, a stack allocator (per-thread), stacks, a self-designed config language, and a pool allocator. Oh, and as mentioned, I'm well on the way to having a build system in there too, with a bootstrap process that depends on nothing more than either MSBuild, a Windows batch file, or a POSIX sh script, meaning that bootstrap itself has no other dependencies other than a minimal OS configuration.
A few months ago, I was writing a compiler in Python (with lark), thinking that I would write the compiler faster that way. Only recently did I try again with C, using my libraries. It turns out that I'm just as fast in C as in Python because I understand my entire stack.
Because of that, I think that my sibling comment is correct that the option of "I'll just build everything myself" is going to be viable for people with less productivity of Fabrice Bellard. In fact, maybe understanding his whole stack is what makes Fabrice Bellard as productive as he is.
[1]: https://news.ycombinator.com/item?id=29524030
I like that. Your post today, made me curious.
I wouldn't worry about speed. As you progress through your career, you'll get very good, at writing very good code, very quickly.
These days (I'm 59), I can bang out a full-fat native Swift app in a few days, with excellent code (and operational) quality, great UX, high maintainability, accessibility, localizability, customizability, etc.
Some projects have the benefit of notoriety (log4j falls in that category) but plenty of projects are just "plumbing" and the only thing you know is the name of the dependencies you have in your dependency list. I can guarantee you that except for security audits, no one knows their full dependency tree, and that they have a deeper dependency with itself a dependency on a utility that depends on a thing that no one's even heard of, and no one's looked at for years, and you would never have looked for. While also being one of the critical pieces that your software runs on top of, capable of bringing down your entire product even if _what it does_ is literally trivial.
Best case, it fails. Your product/server is now broken (hopefully, for only a short while). But worst case, it has a 0-day exploit. And now your entire company is at risk to the tune of "depending on how bad, you may have just gone out of business because you can't afford what is necessary to both legally and professionally deal with the fallout".
(Did your product/service have a database that comes with rather massive fines for leaking that data? Good luck, that might bankrupt you. Does your company have contracts that are void on significant service interruption? Good luck, you may have just lost all your big clients. Etc.)
Maybe in the web world. .Net/Java/C/C++/etc projects have a well understood dependency chain, most of the time. Mostly because there is an actual stdlib and having dependencies upon dependencies upon dependencies is very rare. Projects I've worked on with over 150 dependencies (which is an awful lot for an Android project as it was) had a dependency tree that wasn't that deep (5 at most), and all of that was on standard, well known modules (androidx, etc.)
The shitshow that is JS dependency management is a self-inflincted wound. Knowing your dependency tree _is part of your job_ as a software engineer.
We're professionals - we in fact simply can do that with some elbow grease. Doesn't take a genius to understand how software is built.
It seems there's currently two ways to tackle this issue: move fast and break things, or move slowly and don't break things.
I'm saying it should be trivial to fork any dependency in your tree.
Every project I've ever worked on has met this - but I'm a Nix guy.
You can pay someone a lot to make a product and they can do a shitty job. You can have a company install a backdoor in a closed-source software for whatever reason. You can have a well-trusted organization with competent developers mess up a single line of code, creating a huge bug or exploit.
OSS actually gives you a benefit that you can see the code and technically discover any bugs or exploits (even though of course nobody will). There are plenty of open-source libraries where contributions are seriously reviewed for any accidental or intentional errors.
Serious hard-to-patch exploits are discovered in closed-source software every day. They might be harder to discover and easier to reveal without revealing how to trigger, because you can't directly see the source code. But this isn't a fundamental problem of OSS, it's something OSS users and maintainers need to look out for.
This is wrong: it's better in open source land. Closed source means you, the user have to wait for the vendor to ship a fix. With closed source, the answer sometimes is the version you are on is no longer maintained, and you must buy a new licenses to fix the vulnerability in your closed-source product. Other times, the answer is, sorry, we discontinued that product and will not be patching it.
With open source, you have options when a maintainer says the version is too old: fix yourself, use a patched fork, or migrate. Any way you go, the situation is substantially better than closed source.
> OSS actually gives you a benefit that you can see the code and technically discover any bugs or exploits (even though of course nobody will).
People can and do find and report bugs and exploits in OSS all the time. It's what makes open source work so well.
This is a pretty unlikely situation.
Someone already thought of all this and made Tidelift, btw.
Open source is fine. The culture of companies -- nearly all of them, including the one I work for -- that freeload off this work is what's broken. If you are equating this state of affairs with "open source", I think that does everyone involved a disservice.
I work on and release some things under open source licenses. I've been doing this on and off for nearly 20 years. None of it these days is as remotely as popular as something like log4j (the only popular thing I worked on for a while was Xfce, during the 00s). But that's the thing: I don't care (and kinda don't want) that kind of popularity. And if there's a critical bug in my stuff that lingers for a few weeks -- even if it's a security bug -- that's just life. If people want something with faster bug fixes or to-the-minute security responses, they submit patches, or they can pay me. Or, better yet, use an alternative that is already better supported, because I don't want to be paid for this stuff, and take on the burden of the added expectations.
An aside:
> Now let's turn our eyes to log4j2. This project is effectively in the standard library for Java users.
Is that really true? All my (professional and hobby) JVM projects use slf4j+logback. If I depend on anything that pulls in log4j (most of which pulls in v1, not the vulnerable v2), I exclude that and add the log4j-over-slf4j library, which replaces log4j with simple classes that delegate to slf4j.
Do corporate users of open source really do all that much complaining without contributing? IME the people with the biggest complaint/contribution ratio in open source projects are individual devs (or trolls) who are not participating as a representative of any company.
IBM, Oracle, Apple, Microsoft could submit all the PRs in the world and it won't do any good if he says "I don't like your coding style" or "this takes core-js in a direction I don't like."
Or he ends up in jail. I thought the author was joking about him going to jail for killing two pedestrians. They were not: https://www.theregister.com/2020/03/26/corejs_maintainer_jai...
Literally every time I find an esoteric library on Github the first thing I do before forking it or adding it to my dependencies is immediately pull up the "network" tab to see if there's are active branch downstream I should follow.
Perhaps Github can do a better job of highlighting hidden downstream forks to direct people to find more updated and supported dependencies?
(note: I'm unfamiliar with this project, so seriously I'm asking if/why this is an issue)
Capitalism will always try to extract work at the lowest possible cost. If it’s possible to use your work without paying for it, companies will do it. They’ll fund work when funding the work can gain them influence or political dividends.
My two open-source projects, a font and pip-chill, are, respectively, a work of love and something that solves a problem for me. I enjoy working on them. In the past I have worked on other projects, but always to solve issues I had.
Absolutely. Originally, we had free as in freedom software. Then businesses did their best to redefine it as free as in free labor software. That's the entirety of the anti-GPL movement. The thing about the GPL is that you can dual-license your software for companies that don't like the GPL. It works marvelously as a way to monetize your open source work. Releasing under one of their preferred licenses guarantees there's no way to monetize your work beyond charity. That's what businesses want so many open source developers fall into the trap of donating their labor.
I disagree with "exactly what the price tag says it is worth: $0". That's not what the price tag says it's worth. They wouldn't be using it unless it was worth a lot more than $0.
People love to hate on Richard Stallman but he was really clear about the motivation for Free Software (which is not the same as Open Source but shares some tenets).
What companies do with the source is their thing. They get all of the benefits and all of the responsibilities. But the beautiful thing is that if that maintainer is dead or missing or no longer interested, you CAN fix it. Which is very difficult / nigh impossible for closed source.
That's on them. They can migrate to wyldfire-fixed-log4j if they want, or to whatever other fork they want, or they can keep using the old busted shit. It's up to them, there's no problem here.
That doesn't mention the fact you now also have to fork unmaintained projects relying on log4j to use the new version. If you're developing a major java projects, that's potentially thousands of dependencies you have to patch.
I'm not suggesting that closed source is the solution, I'm saying the current system is not sustainable and neither is just forking projects. Because which fork do you follow, and how do you make sure all your dependencies follow the fork you want and not an unmaintained fork?
Meaning every single Java product would have to include that "if you want to use log4j, you have to include this patch line to use a fork, because of unmaintained dependencies".
That just ossifies log4j and fixes nothing. Patching dependencies in Cargo is not meant to permanently replace code, it's to be used while you're waiting for an upstream merge.
You can't force other people to use your fork.
There is nothing wrong with these options.
This is not about forcing my dependencies to do anything, this is about caring about maintainers and maybe ensuring that the bedrock of our ecosystems aren't maintained by unpaid volunteers in their free time, exploiting the sweat on their backs for our amusement for free. Forking the project is just spitting on their efforts on top of that.
Forking solves the issue of an upstream dependency not willing to fix a bug.
How would proprietary software make this better? You wouldn't even have anything to pull in!
Is your argument "having the source code and the legal rights to fix this bug even when nobody else wants to or even can fix it is not good enough because not everyone will use my fix"? Because good luck with proprietary software then!
I believe I made this very clear on my very first comment.
As an individual user, you shouldn't be required to. It's not how or why the project started, anyway. Maybe big companies whose system depend on log4j could fund it, yes.
> what amounts to slave labor
That kind of hyperbole doesn't help the discussion. The situation is nothing at all like slave labor.
In the Java world it’s much simpler with a few excludes in your POM. Especially for libraries that keep stable interfaces, such as a logging library.
At the end of the day it is just a bunch of class files in jars/zips which makes patching a lot easier.
It's only a handful of lines of code and it is technically a bit hacky but it's really no worse than any of the other jank you are forced to do when building any moderate to complex gradle based java project.
Luckily those few lines can mostly be shared and you end up with a handful of lines and a map from old dep to new dep which makes it not too painful.
This whole issue is why I don't like these ecosystems but at the very least in the Java space dealing with this issue isn't too painful. I can't speak for the JS space but this is also a pretty trivial fix in the Rust space and it isn't too painful with C++ or C projects. Nix (mostly used for Haskell but it's a pretty solid universal package manager) has some pretty good tooling for modifying upstream dependencies. Spack (package manager specialised for HPC and embedded projects) has really good support for this as well.
My point being that people have run into these issues in the past a lot in certain spaces and as a result those spaces have come up with solutions for this problem a long time ago. It just so happens that for the most part the average dev doesn't see a lot of that because these issues get dealt with upstream or just aren't common in most industries. The embedded industry is particularly used to this considering how much of the kit from manufacturers is just outright wrong or broken 3 levels deep. The only reason I'm as well versed with this as I am is because I've been in the embedded space patching over broken HALs and I've bled my blood dealing with legacy enterprise applications that were initially written in Java 1.1 and haphazardly dragged along over the decades.
TLDR: This is an ugly fix but ultimately it's the best ugly fix to an ugly problem and every software ecosystem eventually gets to deal with it once they get old and crusty enough.
Switching one library is not much work. But if it becomes the standard approach then the first time you fire up your java project you either spent 30 minutes to put in all the exclusions to provide your favorite forks of dead projects or your pom.xml will already be 5KB large on generation just for those exclusions and patches.
React gives you a free copy of an aircraft and will probably maintain it for years. But maybe they rely on an altimeter developed by a poor person who decides they dont have time to work on it because they need to help their mum.
Well thats everyone elses problem now.
but the ease of download and use of React and other code libraries creates a sense of entitlement.
Yes if its broke and you need it fixed you have to pay someone now!
Its still libre its just not gratis anymore
https://english.stackexchange.com/questions/25575/what-is-th...
https://wikidiff.com/dependee/dependent
----
Yes, this is mental gymnastics, another fine staple of this glorious field.
I know this very well and for some irrational reason it still makes me anxious to think about the many people relying on one of my free-time project that is used in classroom and medical settings. When there is a nasty bug found it's hard to shake the feeling of responsibility.
I have disabled the counting of downloads for this reason, I would rather not know just how many people rely on it and instead focus on improving it without pressure.
I know right? Someone just opened a github issue for a CVE in one of our dependencies. It's only relevant if you're opening a .DXF file from an untrusted source, so it doesn't seem terribly relevant but yet... And updating to a newer version would take effort, and we want to replace it with something else anyway which would take effort. None of that effort is where I want to spend my free time. But I do work on the software because I like it and really want it to continue being around and useful, and that isn't going to happen unless I (and others) make it happen.
Closed source does not mean that the customer has no access to it.
In case of my Sciter, for example, customers are getting access to SVN server with sources. Some of them are sending patches with fixes and features.
Sciter's [1] core customers are antivirus vendors - highly professional, dedicated and disciplined teams that know very well what they are doing.
It is not an open source but not a closed source either. Rather a professional club where members value each other time and efforts.
[1] https://sciter.com
I think RMS and the GPL would disagree with that statement.
My apologies if this is flame-bait. I really don't know what the solution is. I certainly could admit that shaming people into contributing on an individual level is a valid tactic and that a good state to be in is to have individual and corporate sponsorship for a long tail of FOSS projects. I worry that focusing on the failings of individuals to fund projects takes attention away from other alternatives.
I really don't know what the alternative could be. UBI? A wide array of government grants for FOSS?
Taxes and allocation of funding at a societal level might indeed be the answer.
That's a big if, log4j is a logging library after all. This is an understandable position to hold for other types of dependencies (think react, database, UI components etc.) but the logging library is very far down in the ordered set of projects I'd donate to.
I will however leave a mark and donate to the top 3 dependencies I consider most important in my (non-java) side project.
Edited to add: If you offer your software at no charge, you shouldn't be surprised if people accept that offer. So I even disagree with the "moral obligation" bit. Doesn't mean that donating is a bad thing, however.
Sure, but don't complain then, if it doesn't work, or you get hacked using it. You get what you pay for. Nor should you be surprised if eventually, no one decides to "give you for free" something you value so little.
IMO, fewer things should be free in general, regardless of whether the source is open. Charging money limits the amount of low-value users and the problems that come with them, it rewards the those contributing their expertise, and it can be a replacement for junkvertising.
So I agree with the author, but perhaps not in the sense that open-source software needs to charge money. It depends on whether the software really necessitates pay and exactly whom should be paying. Charging all users a fee can be counterproductive, but only charging for commercial use by companies can be a way to go.
Sadly many open-source evangelists are advocating for it because of the price tag not because it is free.
The other side is that everything else is broken, too. How much should you really trust a package that you cannot audit and that is maintained by an unknown group of people with unknown skills who are also subject to the whims of quarterly earnings reports? Oh, and you'll never hear what their screw-ups were.
That's anathema to Open Source. How do I know? Check "The Open Source Way" [1].
If you feel uncompensated, use a license that prevents commercial use.
[1] https://opensource.com/open-source-way
The gist of the article is not "I didn't know you were going to get rich off of my work (and I'm pissed off by that)". The premise is - in my reading -
"Don't point the finger at me for writing bad software in my own free time, when you didn't even consider contributing to it and don't try to shift the blame when you have to face the consequences of your own cheap behavior".
At least that's my interpretation.
I see the author annoyed that companies don't want to to be their patron to just pay them to work on random things that they have fun working on
and attempting to leverage this issue to try to draw attention to this "injustice"
as someone with a full time software job: I wish I could only work on things that interest me...
rather than spending 80% of my time working on boring things and dealing with customers who set deadlines and expect to receive a specific product that they're paying for
> The "welfare queen" stereotype is driven by the false and racist beliefs that places the blame of the circumstances of poor black single mothers as the result of their own individual issues, bringing forward racial tropes such as their promiscuity, lack of structure and morals, and avoidance of work. [0]
[0] https://en.wikipedia.org/wiki/Welfare_queen
In the UK, one such group are known as 'chavs.' It isn't a term of endearment.
Given the ignorance evident in your post, I wouldn't be at all surprised to receive a heated reply from you, calling me names and attempting to argue this inarguable fact, which is clear and obviously factual to anyone who has spent any time at all living out here in the real world aka 'flyover country.' Have you ever even been to jail?
Welfare queens come in all shapes, forms, and sizes these days. Some of the worst offenders are large corporations, though the largest by far are governments, of course.
The world is full of leeches who want something for nothing. Like for example these wealthy entities who in some cases make billions of dollars off the backs of open source developers, while the devs themselves may be on the brink of starvation, eating out of dumpsters and living in their car.
You cannot argue with cold, hard truth obviously, or you would be doing so, instead of flipping your wig and downvoting/flagging my post.
Here, let me tell you more about these people you obviously know nothing about. I've met, interacted with them, spent months in jail with them. I know exactly who they are and what they are about.
They swap tips and stories and plots and schemes for signing up to as many welfare programs as possible. The more checks one has coming in, the higher one's social rank is within this system. EBT cards are used to buy certain items, like 24 packs of soft drinks being a major one, which are used as a sort of currency, exchanged at half price for hard cash, which is often taken straight to the drug dealer. Fact.
There is a pride among the group based on how much they can rip off from society vs. how little actual productive work they do, ideally none. 'Hustles' are the primary form of work, usually involving drug dealing.
Theft and robbery is another primary occupation of this crowd. They steal whatever isn't nailed down, and sell it on Craigslist. When confronted, they brag about it and show no shame or remorse whatsoever, like the one guy I went to school with for example whom I noticed doing this.
They spend their lives in and out of jail--and they are proud of this. They love going to jail. That's where all their buddies are. The only thing they like better is going to prison, because it's a lot better than jail, with much more to do, more hustles to run, and more criminal minds to link up with. Fact.
Having returned from jail/prison, they continue with the same life choices. Proudly.
They do things like steal large air conditioner units from schools and churches, or catalytic converters from cars, or copper wiring and plumbing from houses, and melt them down for scrap. To buy meth and heroin. Fact.
Every one of them thinks the world owes them something. The sense of entitlement is apparent in their every word and action. People with honor and dignity who prefer to do actual work are like an alien species to them, treated with scorn and contempt.
I've personally been ripped off, robbed, and screwed over in countless ways by this crowd. Matter of fact, my shop was robbed just the other day. They took several metal items that I desperately needed, like two radiators, one of which is for my generator. I'm not rich. I'm living hand to mouth, literally eating out of dumpsters to survive. They don't care. The only thing they care about in the world is themselves.
And is it any wonder they turmed out this way, when everybody in the entire country from President and Bankers and CEOs on down is exactly as selfish and uncaring? Who do you think molded them into such criminals?
Please, downvote and flag me some more, so you can prove how selfish and disconected from reality you are also, presumably isolated in your big city enclave in some coastal city. Out here in flyover country we have no such luxury.
This country is burning, and frankly, that's exactly what it deserves. Maybe when the destruction finally reaches your doorstep, you will finally get a clue.
There are many many FOSS projects where contributors get paid a great deal of money. Universities sponsor contributors. And most contributions to a project like say Kubernetes come from Google’s employees. Government agency grants. Et cetera. But if that’s not enough, tech giants throw a lot of money at places like the Linux Foundation to ensure that FOSS projects get maintained (and thus the maintainers get compensated).
The fact is that a little ‘buy me coffee’ link is simply an ineffective way to monetize a FOSS project. But FOSS is not broken. Some of the greatest things in computing today are FOSS.
Valuable stuff, only with commercial contracts.
I also buy books from folks, or do occasional contributions to all ecosystems which are valuable to me.
Like myself they have bills to pay, however none of them (buying books or donations) is a sustainable business, if only a couple of people occasionally do it.
Somehow I think open source has legitimated piracy, in the sense that those that would pirate, now feel safe because license, and just go on their merry way and don't need to fear that the economic activities surprise audit would close down their shop.
Gitcoin could really help here.
Ordinary old-fashioned "fiat" coin would help at least as much.
I've been convinced of the inherent good that openly available software is, both for users and developers, and for society at large. I want to continue contributing to the common goods. But I am also fully aware that Google, Facebook, Twitter, Instagram, Snapchat, Tiktok, and all other platforms exploiting users' privacy and controlling so much of our digital lives could rise to power that easily because they had a trove of open source software to build on, software for which there is no counterparts needed. That is what the MIT, Apache, BSD licenses and friends allow you to do.
That is why my opinion now is that if you want your work to be open, you should not make it open source "only" but fully Libre. Use a copyleft license. If other developers don't want to pay you in money, at least their production should become a common so that the entirety of society can benefit. Don't give FB more power to turn elections in the direction they want; make it so that someone else can _only_ build a platform where users, and as such people, remain those in power.
Open Source Software benefits those in power, and unfortunately it is not us who hold this position.
But you forget to compare it to the alternative, where there is no significant open source or libre software available.
You can't run Linux, you have to trust Windows not to backdoor you. There is no Signal or Matrix or other encrypted messaging - or if there is, you have no way of verifying it. If you want to write a .txt file, you must pay for a close-source text editor. Or a very expensive compiler, if you're a programmer. Is the compiler backdooring your code? Maybe. You must find paid alternatives for all the free software you rely on, for work, or for your hobbies.
And who builds that paid software? Not a garage shop - they could never afford all the compilers and libraries and tools necessary. Only billion-dollar+ companies, engaging in incestuous cross-licensing, letting each-other use their tools, and crushing any upstarts.
If open source (or even copyleft) benefits those in power, closed source benefits them infinitely more.
Linux itself is GPL, so are some of the distributions. Hurd hasn't seen adoption, probably because the alternative is good enough. Signal is still there, client and server. But maybe it wasn't needed because ejabberd, one of the biggest XMPP servers, was already there and powering all messenger platforms.
You're assuming that if developers didn't license under non-copyleft, they'd license under proprietary instead; there's no real reason to believe this. And as many examples have shown, many of the tools we use aren't actually made by billion-dollar companies but by single developers on their free time. The examples in the article show it, Werner Koch (the guy behind OpenPGP) has been asking for funding for years (decades ?). ssh, curl, ...
Anyway, that world is so different that we'll probably never know how it'll work, so here is the area where the optimism of people are visible and I myself believe Copyleft could have been a success.
I think the core of the problem lies in distribution. We've gotten so used to other people distributing our code for us (through the use of package managers and such) that we've made it hard to actually have a dialogue with our users. Many consumers of packages just know their dependencies by the npm package name, rather than actually seeing what the person has to say about the software, how they plan to maintain it and for how long, etc.
Even things like licenses are really just ignored at large, with there being a general mentality of "it's on Github therefore it's probably MIT". There was something I remember reading a bit ago about a Go project whose license was simply "you do not have permission to use for any reason ever" which was depended on by projects from big organizations such as AWS[0].
This is mostly just a rambling and I don't have any concrete way to solve this, but I think it should be taken into account when assessing whether the problem really lies in the individual license choices of developers, or whether this is some kind of effort by big market actors to keep open source solutions at a subpar level of quality in comparison to commercial offerings (for example: some of Microsoft's VsCode extensions only work on the proprietary version, not any open source forks[1]).
[0]: https://fossa.com/blog/bouk-monkey-importance-knowing-your-d...
[1]: https://github.com/VSCodium/vscodium/issues/240
If you want guaranteed compensation for your work, work for a company or require payment for your software. Releasing it as free software and then complaining when you don't get the donations you wanted is just being entitled.
What they didn't get was support and maintenance. Newsflash: That wasn't included in the deal.
They want that, they can pay for it.
I doubt there are many companies that this is true for, if any
yes, log4j is good, but there's a dozen other logging libraries for Java that do 99% of what people will use log4j for
and the same is true for Alpine
so yes, it can be
eg. slf4j has adapters for logback/log4j/java.util.logging/commons-logging/...
you can also implement it yourself, I've done it several times in both directions, both:
they take at most a day to write, as the Logger and its factory are two well-specified small interfacesShuffling the deck chairs around is one solution, I suppose. If all the deck chair makers get fed up, what then?
we have our own logging libraries, but other pieces of software we integrate with depend on the log4j interface
so we have an adapter (that we wrote) that swaps out the log4j implementation for ours
if all the open source logging disappeared tomorrow we'd be absolutely fine
and everyone else would write a trivial adapter for Oracle's java.util.logging and they'd be absolutely fine too