Everyone involved has their own incentives, and gets to make their own decisions about when and where to invest their time and money.
Some devs are in it for the passion, some for the experience, some for the challenge, some for the learning, some so their work will live on when they change employers.
Startups get to use well-tested community supported libraries and don't have to build everything from scratch. Big companies get tech branding cred and can attract better talent, etc, etc.
And yes, maintainers sometimes get burnt out, consumers sometimes act inappropriately entitled, massively profitable enterprises often give back relatively little in return.
But that's all part of the deal going in, and everyone is fully aware of all the trade-offs straight from the onset.
What's so beautiful is that there are so many options whenever conditions change for any party. A maintainer goes to jail for vehicular manslaughter and a bugs needs fixing, no problem. Stand up a fork and the project continues on. A company's new leadership takes its own source project in a questionable direction and consumers are upset, no problem. Community forks and the project lives on.
And the result is we have this thriving, organic, creative, productive ecosystem which benefits us all in the end.
I mostly agree with your argument. But, if we just de facto accept everything for how it has been in the past. Then we stop making things better, for everybody involved.
Is Open-Source thriving? yes. Can we make fix the places where it's broken? Also, Yes.
> Can we make fix the places where it's broken? Also, Yes.
Two problems:
1. How is it broken? As I and others in this thread attest to, the thing that makes open source so powerful is, in fact, the lack of legal and moral obligation to do anything in exchange for the right to use the software. Not having obligations is a two-way street. Same for donations; donations do not give you any additional assurances.
2. If it is truly broken, then what is the solution? Nobody has really offered any solution, that I can see. If the solution is that everyone rushes to support a project the moment it hits the news, that's not sustainable. It's good that log4j and its maintainer(s) will get more attention and hopefully funding as a result of this snafu, but it's not a sustainable solution to a problem.
(As a clarification, I am not implying that the answer is "it's not broken." I certainly do agree that open source is underfunded, though I think this is more of a procedural issue than anything.)
I feel like a lot of this isn't that individuals are the ones who should be forking over money, but rather corporations who are making tens of millions or billions who rely on this stuff as a core to their stack, but do nothing to support the ecosystem monetarily.
Any large tech company probably uses thousands or tens of thousands of open source components (because the licenses are well understood). Sone even support the projects officially, or unofficially by paying salaries to developers who contribute in their free time.
I like licenses that bind all users equally: whether you're a lone developer, a charity, or developing nukes. If you do not like a certain class of use using your software, then choose a license that matches your philosophy. One shouldn't piggyback on common licenses for popularity and then complain about users keeping to the terms if the license.
"everyone rushes to support a project the moment it hits the news, that's not sustainable."
This is exactly how a lot of things function, especially in government and disasters. So apparently it is sustainable. It's just not ideal, but this element is always going to be a part of human nature as our collective consciousness can only focus on fixing a few things at a time.
If you give your work away for $0 then the world will expect to pay $0 for it. That’s it. It isn’t rocket science. If you value your work make companies pay for it.
Absolutely. However in reality if you give away your work for $0 then people value your work at $0 which means that they expect you to fix problems for $0. The problem is the maintainers giving away their work for $0. OSS is not about free (as in $0) it is about Open Source.
> OSS is not about free (as in $0) it is about Open Source.
FOSS has an 'F', which stands for "Free" in the sense that anyone can fork, modify, build and distribute the software. Without the 'F', you have code that is only open-source in the sense that you are allowed to read it. If you include the 'F', you have software that anyone can distribute, either for money or for $0. The market price is going to converge on $0.
Plainly some devs are willing to work for nothing, whether out of passion, for the props, or because the software is important to them. So the market price of any software that isn't ringed with patent and copyright fences is going to tend towards $0.
I favour a Universal Basic Income. Many people will leech; but many users of free software are leeching now. I believe people do productive work because they want to, not because they're paid mega-salaries. In fact, that's the only plausible explanation for free software. So make taxpayers finance a UBI. Admin costs are tiny (no eligibility checks, you just pay everyone). You can also get rid of most Social Security infrastructure.
I think UBI is unpopular mainly because people hate the idea that the taxes on their income from work will be paid-out to people who don't care to work. That's understandable, but is it reasonable? Do they also complain about the number of people who are paid out of tax revenue just to check claimants' eligibility for SS support? I haven't heard that complaint.
if this were true then FOSS would never have reached the popularity that it does now. FOSS users give a lot of valuable feedback that makes software better, and they don't generally expect their problems fixed for free.
that mainly comes from greedy corporations that exploit free resources for their own gain.
i give away my software for free to give back to the community that gives me tons of other free software and to get feedback and patches. if i were to sell it, that would just not happen because we would all compete on price.
and because i can't tell the difference between individual FOSS users and large corporations when the software gets downloaded i can't force corporations to pay. nor can i make a license that forces payment from a select group because that would not longer be FOSS.
Honest question: How do you know that FOSS is popular because it is great and not because it cost $0? If FOSS cost the same as the equivalent commercial software would people pick it? I personally don't think so. There is a lot of really buggy crappy FOSS (and commercial) code out there. I don't think one is inherently better than another. It depends on the quality of the team building it.
the key advantage of FOSS is not code quality or price but access to the source and the right to resell it.
code quality on average should be on par with closed source software, if not a little bit better because developers know that their code will be public.
if FOSS would cost the same, source access would still be a factor, whereas code quality would not really matter because it can't be inspected for closed source anyways.
the downside would be a smaller pool of FOSS developers since less people would be able to afford to pay. but actually not that much. if a linux distribution cost the equivalent of a windows license, most people would still be able to afford it. the challenge is rather all the additional applications.
for a more realistic comparison look at freeware. it costs the same as FOSS but the only really popular freeware out there was the netscape browser and what, winrar? (there are probably others, but i am not a windows user so i am not familiar with the ecosystem). but if cost was the factor, then freeware should be just as popular.
FOSS is popular because it endures. i personally use several FOSS applications where the principal developers had left the project and others took over. any equivalent commercial of freeware application would be dead by now and i'd have to switch to something else.
I think of open source as a force of nature, sure you can create incentives in your own proximity, and if you are FAANG the radius can be huge, but finite. The fundamental failure here is not related to open source but in how software is integrated and isolated. We need more robust typing in the integration and capabilities to define the isolation.
Capabilities alone might have eliminated this whole class of failure to escalate, but not eliminate the initial injection failure. Pretty sure that could have been demonstrated on wasmcloud.dev
> No one is entitled to money. There's nothing broken about that. If you want to make money it would be a good idea to make a business plan.
This attitude totally ignores how hard it is to actually run a software tooling business and collect when you have a free/community offering.
Take the Obsidian note app, for example. It's technically free until you start using it for revenue-generating, work-related activity per their license, but how do they go about enforcing that? If they were to dig through customer data to see who is violating the agreement, they'd get roasted on Twitter in an instant and risk losing their user base. Should they hire attorneys to investigate and shake down violators for the $25/mo fee plus damages? Again, major risk of losing the customer base.
Software devs have to represent a significant, if not majority share of the user base of Obsidian, and I'd bet a year of my salary that most of them aren't paying for it when they're using it for work. Committing to a business plan is an important step, but software's value is directly correlated with it's use, and more widely used software is inherently more valuable, but achieving that kind of growth without giving it away free is a major challenge.
It kinda feels like tipping in the restaurant industry, where folks argue that it's to ensure proper service, when in reality it's often just a way for the restaurant owner to not have to pay minimum wage by offloading that portion of a workers wages onto the customer, who often just doesn't give a tip.
Selling software is hard. No one is guaranteed to be successful at it. Obsidian decided to go the free-for-personal-use route presumably because they thought it was the best route for them. They didn't get nothing for that: they got early growth of the user base, beta testers, community built plugins and themes, voluntary user-to-user support, and free advertising.
I'm not sure what the alternative is here. Is it forbidding free software?
People pay $ all the time for things they value. If people choose not to pay $ for work you do then accept that they don’t find it valuable enough to spend $ on.
Or just use the honor system in combination with a liability standpoint.
They might loose out on smaller companies that abuse it, but teams and people in larger companies that use it will pay.
If I want to use something, I can pay for it and submit it to get reimbursed or if it's a bigger purchase, I use a company card. I don't have to worry about putting the company in liability and that's something that's understood by many.
Another example, how does Jetbrain make sure that the people paying for their software via personal licenses aren't getting money for it from their companies?
> Another example, how does Jetbrain make sure that the people paying for their software via personal licenses aren't getting money for it from their companies?
This is a great example, perhaps companies like Jetbrains just assume that a certain percentage of their user base uses their product out of license and they just deal with it, which undermines the original argument. Software inherently wants to be free, but we as a community agree upon the proper way to compensate those make OSS because we're taught that the exchange of money for goods should always happen upfront and there is no other way to conceptualize alternatives, which I disagree with.
> This is a great example, perhaps companies like Jetbrains just assume that a certain percentage of their user base uses their product out of license and they just deal with it
Of course. The same thing that happens with piracy.
How much of Adobe, MS and software from other big companies is pirated every year? I've also heard the argument that if they went strict and went against all of them, no one will be familiar with their products and would levitate to something else.
When I was in uni, the majority of people with Adobe programs on their laptops just had it pirated. Now, when they go into industry, if they need to manipulate an image and all they know is Photoshop, guess what they'll ask for?
Same thing here IMO. Jetbrains makes some of their products free with some functionality removed. When the people go into their jobs and if they need that, they'll spend the money.
Same with Obsidian. If you use it and find it useful, when you go to work, you'll make the business case that it could be useful to do the work in an efficient matter. That will also sell others into using it.
I'm not sure that many people are using Obsidian for work, specifically because Obsidian does not have collaboration or any kind of "team" concept. It truly is a knowledge-for-one app.
Obsidian is largely associated with the "Zettlekasten" philosophy, which is inherently individualistic and doesn't ever encourage collaborative use since the entire idea is based around a personal knowledge base, not a community knowledge base.
I also wonder about the futility of the statement that someone could cause millions of dollars of damages when those companies elected to depend and build upon truly free software.
Right, if this is a huge problem for these big companies they only have themselves to blame, they decided to use software from a guy who writes it in his spare time.
But what is broken is the disconnect between providing value and being able to earn a living from that value. More often than not, any "business plan" involves providing a worse product, because the product must be compromised to enable the business plan.
SaaS for things that could be run locally is a perfect example. Or algorithmic feeds optimized for engagement in social media. Or the advertising panopticon. Or coffee filter DRM. Or smart TV spying. Or ads in the Windows start menu. Or..
> But that's all part of the deal going in, and everyone is fully aware of all the trade-offs straight from the onset.
I think part of the problem here, in all honesty, is that some people just _are not_ aware of the trade-offs upfront. They learn these after getting started, and it bites them in the butt one way or another.
I was going to say this. Most are just looking for some experience outside school/work and next thing you know they are the only one maintaining something big companies rely on.
I think most people, at least certainly myself, do not disagree that open source infrastructure projects are often underappreciated and underfunded. However, there's a dramatic difference between the way that ESR's LBIP initiative frames the problem vs this article (not to single anyone out - this article expresses a commonly held belief among plenty of influential and intelligent people, and no doubt the person who wrote the article is one.)
To me, the money quote is here:
> If log4j2 is responsible for your company's success, you have a moral obligation to donate to the person who creates this library thanklessly.
I don't agree. I think that it is tragic if nobody does, but I draw the line at "moral obligation." Furthermore, the article doesn't really provide any sustainable solution, it just expresses that it's broken and says people should pay for it. Initiatives like ESR's LBIP proves that there are some attempts to get more funding in, but the problem is manyfold, and simply put: I don't think trying to create a new norm that there is a moral obligation to pay your dependencies is really a good idea, nor do I think it solves the problems that lead to this situation. I think that discovery and awareness of load-bearing dependencies is an even greater problem, and that plenty of entities that relied heavily on log4j had honestly not even realized it until now.
I'll repeat myself: It's good that log4j will now see additional attention and funding, if only temporarily, but it's still not fixing the sustainability problem if we only ever fund things when they become newsworthy snafus.
Maybe moral obligation is the wrong phrasing. But if you are major company with investors, perhaps a fiduciary responsibility to your shareholders and customers to fund the software?
The correct model likely looks something like a foundation to support core infrastructure projects in the open-source ecosystem. This foundation is then funded by companies most dependent on that infrastructure.
Yeah, except by creating such an obligation, you are essentially throwing out the core concept of something being open source or free software. That's not solving the problem, that's more like giving up on it.
Not at all. I don't think you understand OSS. OSS is about Open Software. Not about free (as in $0) software. The only way to make OSS sustainable is to make companies payforit.
With all due respect, I don’t think you do. Open source is about rights, and creating a secondary unwritten set of rules about obligations that are extralegal is just a more advanced way of circumventing them. Please read the DFSG, or OSI definition of open source, or the FSF definition of free software for what I mean. All of them are explicit that you can not discriminate on endeavor (explicitly including commercial) or the licensee. That’s not accidental.
OK. So let’s say I want to participate in open source. I release an open source project on the internet. The way I see it, here are my options:
1. I can release it freely, on a project forge like GitHub, and thus nobody has any obligation to pay for it. I can use dual licensing schemes and/or offer commercial support, or solicit donations, but by and large everyone from your average Joe to the fortune 100 are treated the same, because that’s part of the definition of open source and free software, and indeed, part of the draw.
2. I can release it at a cost, but still provide it under an open source license, but because it’s open source, someone can simply release the source code when they pay for it. In practice this actually has worked out this way; take a look at how this has been attempted with the Patron model for emulation software, for example.
3. Do #1 but ask politely (or impolitely) for big companies (how big?) to pay back when they take advantage of open source software. Create a culture wherein using open source projects implies obligations that may not be written out explicitly. This is a commonly expressed viewpoint when people talk about the problem of compensating open source maintainers, and it’s where the “extralegal” part comes in, wherein there are social expectations that contradict the license.
Selling software under a license that doesn’t allow redistribution would obviously fail almost any open source or free software definition, so I’m struggling to think of another potential interpretation here.
Great comment! My message is to the group of OSS maintainers that pick option 3 and then throws a tantrum when it doesn't work. My message is: Option 3 does not work and will never work. Accept it and pick another option.
Apparently, we’re on the same page. However, I think we can still do better than this. While some more organized projects will successfully find a model that helps them meet their goals, initiatives that try to help individuals externally could also (and obviously do) contribute to the solution.
It’s basically the same level of expectations on both sides: nobody is expected or obligated to do anything; they do so because they want to, or because they believe it is a mutually beneficial decision. It’s kind of like the comparison of engineer salary vs open source donations. Yeah, on one hand, open source donations are not likely to pay you enough to live in most cases. On the other hand, it’s money given to you under essentially no obligations. The same reason you can’t really complain much about the support you get from open source maintainers; there was never really any obligations.
But, I believe that open source has proven itself enough to have earned more donations and funding, and that there’s plenty more funding that could be making its way to open source if we could resolve issues with routing it there.
I dont disagree with you but I think that is a very old school of thoughts on OSS. And may be no longer accepted as such.
In the past ~5 years, most ( at least those who have been most vocal ) voices have suggested Open Source is not just about your source code being open / available, but it also means the community around it. And how everyone helps and contribute.
And these kind of thoughts has some sort of correlation with certain political ideology.
The problem runs deeper. To get companies to pay you, in particular enterprises, you have to participate in their high-touch/low value purchasing behavior. And that means you need large pockets which in turn means high prices. High prices means high expectations. Much of those $$$ go into marketing and sales, not product. Which is one reason most enterprise software sucks.
That's the opposite of what OSS devs want to do: solve problems and provide efficient solutions. Its also the opposite of what users of OSS want: easy to acquire solutions to their problems (nobody except purchase officers and lawyers actually want high-touch/low-value procurement. Everybody knows its a waste of time & money.)
Unfortunately most companies are not interested in buying solutions, but risk reduction (which they never actually get because all software comes with limited-to-the-max liability & warranty, just like OSS).
Therefore we have to change not the OSS model, but its reputation.
Licenses should say something like "free to use unless it generates commercial value. When it does you need to pay $ or risk your reputation". Sort of what the GPL does but without the virality.
I'm working on a solution quite similar to the one you've outlined. OpenFare implements payment plans in code. That means simple setups and programmatic management of payment obligations across software dependencies.
> Some devs are in it for the passion, some for the experience, some for the challenge, some for the learning, some so their work will live on when they change employers.
Sure, but what about people who could write code, help with docs, testing etc., but can't because of the current financial disincentives to do that?
With these current circumstances, i cannot be in my right mind and decide to meaningfully commit to open source, apart from small bug fixes or something, unless i want to miss out on spending time with family or anything else over the evenings and weekends, because my day job takes up the rest of my time.
Sure, you can talk about that particular salary number (though it's similar for many people in Eastern Europe, India and many other places), or talk about how i should try to convince my management to allow me to contribute to open source (which is a non starter in many circumstances), but at the end of the day it'd be like quitting my job because i want to develop a video game or something without having a clear plan on how to make money and just vague hopes and dreams instead (which i've seen often as well). For example, i'd have to give up freelancing to do that, which would just further hurt my finances.
Open source isn't a financially responsible choice for many non-privileged folks out there (e.g. company doesn't invest in it, don't have savings to avoid having to live paycheck to paycheck). Just look at this comment in the other thread: https://news.ycombinator.com/item?id=29525272
> The default is that no one will use your thing, no one will contribute, no one will fund you, etc.
In my eyes, doing meaningful work is logically supposed to be followed by not being punished for it, such as not having to starve or be homeless (maybe the "just world" fallacy on my part). No one should be able to praise the open source devs for their work and then just turn around in that same sentence and shun them for wanting to be supported financially for doing that, or claim that these incentives are not valid in some way.
I think this argument massively ignores the underlying message of this blogpost: addressing that the human beings that make and use software aren't always treated as, well, human beings.
> A maintainer goes to jail for vehicular manslaughter and a bugs needs fixing, no problem
The author didn't seem to hint that open bugs in core-js or its usefulness to its community of users are / is problematic. They hinted that maintainers are people with real life problems, whether that's struggling to make a livelihood, or facing imprisonment and ignoring that social/economic context is problematic.
Stating "well, let's just fork their code and off we go" basically ignores the person behind the code entirely. It reduces the value of a person to their ability to spend time and effort on maintaining code. And that's just a morally very questionable way of approaching other people. That kind of behavior just doesn't foster any mutual trust or respect which are the basic requirements for open source to thrive to begin with.
> But that's all part of the deal going in, and everyone is fully aware of all the trade-offs straight from the onset.
No, absolutely not. That's not how the original instigators of the Open Source movement envisioned this.
Yes, open source licensing allows forking, but that's not something you'd do, for instance, because a maintainer fails to respond to your issues on GitHub.
Eric S. Raymond can be quoted from his seminal essay "Homesteading the noosphere":
> The three taboos we observed above make perfect sense under this analysis. One's reputation can suffer unfairly if someone else misappropriates or mangles one's work; these taboos (and related customs) attempt to prevent this from happening. (Or, to put it more pragmatically, hackers generally refrain from forking or rogue-patching others' projects in order to be able to deny legitimacy to the same behavior practiced against themselves.)
> Forking projects is bad because it exposes pre-fork contributors to a reputation risk they can only control by being active in both child projects simultaneously after the fork. (This would generally be too confusing or difficult to be practical.)
> Distributing rogue patches (or, much worse, rogue binaries) exposes the owners to an unfair reputation risk. Even if the official code is perfect, the owners will catch flak from bugs in the patches (but see [RP]).
> Surreptitiously filing someone's name off a project is, in cultural context, one of the ultimate crimes. Doing this steals the victim's gift to be presented as the thief's own.
In the past, I kept a handful of tiny open source libraries in PHP on Packagist. Someone forked one of those without notifying me and started directly competing with mine. I can't express how off putting that experience was at the time. It has made me quite apprehensive of pro-actively sharing code I write in my spare time under an open source license.
Because someone falls on hard times or isn't available for a while, that doesn't justify taking their work and presenting it as your own under the guise of "having a thriving, organic, creative, productive ecosystem."
ESR doesn't get to decide how it works; the revealed preferences of the participants do. And those revealed preferences are that everyone pretty much does what they want, and nobody owes anybody anything. And it seems to have clearly created a vibrant ecosystem.
If you're in it for money or the fame, you're going to end up very unhappy. If you prioritize OSS work above addressing your real life problems, you're going to end up unhappy. If you invest your ego into the success of the project, you'll probably end up unhappy Those aren't broken properties of the system; they're the consequences of transparently poor decisions by participants. Those people would be better served by simply not doing OSS instead of trying to convince everyone else to fund their coding adventures.
I am the sole maintainer of a project with almost 12k stars on GH and 2M weekly downloads from NPM. It would be a massive amount of work if I let it be. The entitlement and indifference of users would eat me alive if it were a real workplace. And the pay would be hilariously bad if I expected income from it. But none of those predicates are true.
No one asked me to make it, no one pays me for it, and no one controls what I spend my time on. Those mutual obligations are properties of jobs, exactly what I don't want out my hobby work. When I don't want to work on it, I just don't. When a bunch of people want a feature I have no wish to add, I don't add it and they're free to fork. When I write or merge a bug, I lose no sleep over it. When people "threaten" to use a "competing" library, I laugh: who cares? Building it is fun for me and it's apparently useful to others. What's the problem?
Since all that seems to work pretty well, the right answer is to keep doing it. Sure, you'll end up with occasional log4j RCEs, but it's not like anyone is going to look at that and say, "I guess I won't use OSS". It was always caveat emptor.
You're addressing maintainers who somehow arrive at open source with expectations which set them up for failure and disappointment. I can agree with you there.
In the past, I've made comments that open source isn't a business model. It's a licensing model which governs intellectual property.
My comment, however, isn't addressing maintainers. It's addressing their audience and their behavior: anyone who uses and leverages open source code without consideration of the labor that goes into it, which is a big difference.
ESR is absolutely right when he points out that anyone who shares creative work also shows themselves vulnerable when it comes to reputation, good name and public perception. Sure, you could use the argument that "open source doesn't make any promises regarding support". But that still doesn't excuse the entitlement and indifference.
If you can happily ignore it, that's great for you. Calling it out for what it is, however, isn't any less valid a way of responding. Even when it's just a hobby project and you don't get paid.
Every so often, there's a case where a small open source project with limited maintenance ends up being leveraged by entire industries with interests worth billions. When things fall apart, media outlets and pundits will report about the failings of that small project and how it affects big interests, but they won't point out the elephant in the room: how these projects are maintained by a skeleton crew working in their spare time.
Sure, none of this is going to awaken people's minds to be more apprehensive or more empathic to the challenges of maintaining a popular OSS project. The value proposition of being able to leverage free labor is simply too attractive.
Meanwhile though, the log4j maintainers are now stuck being perceived as not having done enough to avoid these kinds of bugs. Whether that's trough investing "enough" time, making the "right" calls (whatever those are) or finding "appropriate sources of funding" for themselves. Thousands of engineers are scrambling to roll out fixes upstream. And millions of end users merely learn how "a software bug almost breaks the Internet and Minecraft."
Ultimately, nobody gains from these disasters as a result of a lack of assuming shared responsibility for a common good.
> Yes, open source licensing allows forking, but that's not something you'd do, for instance, because a maintainer fails to respond to your issues on GitHub.
Huh? Not getting satisfaction, however you want to define that, from upstream is the main reason forking occurs.
Yes, forking occurs. But before you, you would reach out, ask permission, offer a solution and try to come to a compromise with the original authors.
Downright forking while ignoring the original authors and then putting it out there as an independent alternative to theirs? Well, that's just entitled behavior.
The "fork" button on GitHub exist primarily to make it easier for contributors to create pull requests and contribute back to the original project. It's not meant to wholesale copy projects and run them as if they were your own.
The specific case was "maintainer fails to respond", which implies that one was reaching out. It doesn't really matter why they don't respond, perhaps the maintainer died, or they are burned out, or maybe they just don't like you.
> Downright forking while ignoring the original authors and then putting it out there as an independent alternative to theirs? Well, that's just entitled behavior.
Entitled by the very license the maintainer attached to the software. But if you meant "entitled behavior" as some kind of indicator of privilege, well, everyone has that entitlement per the license, so I'm not sure if that really counts as being entitled.
If you give away your work for $0 then people/companies will value your work accordingly and pay no more than what is asked. What is so surprising about that? Do you pay more than what is asked for when spending $ yourself?
How many companies paid $0 for log4j2, and then got upset and bashed the authors of it when this bug happened for the cost it caused to their business?
People pay nothing for the software, but will expect paid quality support.
They get upset and expect things to be fixed for $0 because thatisthevaluethattheOSSmaintainerputonhisownwork. So why is that surprising? It's how a market place works.
The maintainer never put a $0 _value_ on their work, but a $0 _public price_ of it "as is, without warranty of any kind, ...".
It's some (corporate) users and markets that understand this (wrongly) as a $0 value. It's their own evaluation that's failing in the long term.
Mentioned that in an other comment, but this is akin to mining companies that extract value from natural resources at $0 price (because the resource is just there to pick up).
When the resource is depleted (even excluding other externalities like pollution deriving from the extraction itself), no one can reasonably expect that it would cost $0 to regenerate/reproduce the resource or repair the scarcity.
... which is why countries are putting fishing quotas and carbon markets in place to make sure that doesn't happen. In other words, countries put a market value on things that otherwise wouldn't have it. OSS maintainers needs to do the same. That's my point.
> They get upset and expect things to be fixed for $0 because that is the value that the OSS maintainer put on his own work. So why is that surprising? It's how a market place works.
The "work" you're talking about is the development of the software. The post you replied to was talking about support:
>> People pay nothing for the software, but will expect paid quality support. [Emphasis added -- CRC]
Valuing what's there to freely download at this instant in time is one thing; bugfixes on top of that are support, which is a different thing.
If you get something for free, you don't have to pay for it; if you want something more on top of that, you may have to pay for it. That's how a market works.
Just out of curiosity - I wouldn't use vehicular manslaughter as a point of comparison for open source projects? Is there a reference I'm missing with that part of the comment?
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.
> 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 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.
> 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.
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.
> 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".
> 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.
> 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
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.
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?
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.
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.
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.
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.
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:
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.
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.
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!
> 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.
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.
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.
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 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?
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.
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.
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.
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.
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.
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, 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.
> 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.
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.
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]).
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
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.
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.
Fully agreed. I'm not entirely sure if authors like the one from TFA fully embrace or understand the distinction between Open Source and Free Software (I suspect they are conflating the two, but happy to be proven wrong), but if they do, they are actually doing good work and showing why Free Software is philosophically sounder.
Don’t you see that one big issue, that I never see addressed in this kind of discussion, is the enormous tension between true observation 1 :
> Consider something as basic as running an SSH server on the Linux kernel. In the mix you would have at least 10 vendors (assuming a minimal Alpine Linux system in its default configuration), which means that there are at least 10 separate organizations that still have bills to pay with actual money dollars regardless of the number of users of the software they are giving away for free.
And your judgment 2 ? :
> If log4j2 is responsible for your company's success, you have a moral obligation to donate to the person who creates this library thanklessly.
Let’s say that you convince me of 2. I have 603 packages on my production server, with no obvious way to know how much distinct maintainers this is, or how they accept funding. One node application on it developed by my company has 991 dependencies, 129 of those "are looking for funding", according to npm.
How do I even start to fulfill that responsibility in a fair way ? Just picking the 5 (or, hell, even 10) most "visible" or "obvious" projects would be a significant burden, and I don’t see how prioritizing by visibility is fair or fixes anything about "that obscure but important library maintained by that guy in nebraska".
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.
What I see as broken is the expectation that dev tools and the entire dev stack should be provided for free. It manifests as only using "open source" tools and everything in this blog post applies.
As a developer I both expect tools and libraries to be free and have been burned by this as someone working on developer tools and as an open source maintainer on my personal projects.
The frustrating part to me is that this doesn't apply to apps, saas apps, services, or a lot of AI/ML related things. Most developers expect to make money off those things while at the same time demanding everything they used to build it be free because it's just code and they love open source. It feels unfair, and in that way I agree, open source is broken, or at least unsustainable for small projects long term.
This is a good article, and 99% of this article I agree with. I'm going to quibble at something very small, not because I think the author is guilty or anything or because they're doing something wrong, but because this is a general pattern I've been seeing over and over again in multiple takes from multiple people: it feels weird to me to have a criticism of corporate behavior where corporations don't know how to ensure the continued success of the commons they build on, and to title this that "Open Source" is broken.
If a bunch of hunters go out and shoot all the ducks to extinction, you don't title an article that ducks have failed as a species, you say that duck hunting is a problem. And I've seen a few different articles now talk about how Open Source devs need to get better about setting up contracts and finding sponsors, or saying that this reveals a fundamental problem with Open Source, and I just don't get why we're laying this at their feet.
The big companies who's stuff broke because of Log4j have both a giant legal department with infinitely more resources than any single developer available to them to figure out how to kick money to these projects. And this is something that article touches on, which it describes completely accurately: there are developers who build this stuff that do not want it to be a professional thing, and they should still be compensated. There are developers who don't want compensation in the form of money, they want additional development resources or dedicated people helping them triage bugs, and that's a legitimate need that companies could start learning to provide. Volunteer developers should not need to learn how to set up an LLC or a nonprofit to get some compensation for their work if their work is important; the idea that compensation is dependent on a very specific model of professionalism and that it's incompatible with people doing something as a hobby is just wrong. The author does a good job of pointing this out that Open Source funding often looks different from commercial funding. A quote even admits:
> Okay, part of this may also be an ADHD thing and not really being able to stick to projects longer term.
But the thing is, that's OK. Like, you should be able to be in that position and to jump around between projects and if a company really cares about it it's still their job to give you money or to invest resources and maintainers into the project to make your life easier. This should not be conditional on you turning your work into a full-time job with years of commitment. But even as I praise the article for that phrasing, and even though I suspect this is something a lot of people agree with, I'm still frustrated that we don't get a bunch of articles that say "corporate financing is broken and unsustainable" or "our culture about funding and who/what deserves money is broken." We get articles that say that "Open Source" is broken.
I know that I'm kind of just quibbling over something small, and I know this is if anything the wrong article to even post this rant under. I don't want to make needless conflict over something where the author is mostly just right and in many cases saying the same things I'm saying. But I do kind of think this phrasing is important. My objection is I think the phrasing here implies to people (unintentionally) a kind of unconscious bias that this is Open Source's problem to solve. But the commercial companies broke and went into panic mode because they weren't willing to invest into the infrastructure that they rely on. That is their problem to solve, they are the ones on fire. They have the resources and they are capable of learning how to give money directly to developers. Maybe it's a cultural problem that they need to work on that's just ingrained in business heads; I somehow doubt we're going to get a bunch of corporate think-posts on LinkedIn about that framing though. Companies should be expected to occasionally evolve themselves instead of having everybody constantly hold their hands and console them that we understand that large direct donations and regular investments are just ever so scary and difficult to do and that this is a systemic problem with the community, not a direct problem with their individual behavior as an individual company.
Funding for Open Source is a serious problem, but I'm kind of tired of seeing article titles and phrasing implicitly suggesting (again, I think completely unintentionally in this case) that it's the Open Source community's problem to solve. You all use our stuff! This is your problem, your stuff broke because projects were underfunded. Why is it our job to make our funding methods more comfortable to you? The company's stuff breaking because their lawyers are irrationally scared of straight no-strings-attached donations is their problem. Let commons be commons, get over the short-sighted thinking that says companies can't possibly invest into making their products not fall over and catch on fire randomly unless they get something exclusive out of that investment. Or if they're incapable of doing that, stop giving them sympathy and treating their irresponsibility like it's everybody else's job to solve. They'll learn to fund Open Source, or their stuff will break in embarrassing public ways that make them look bad, and maybe after a while they'll start learning some heckin lessons from that.
This is something that (outside of the title) the article does a good job of reinforcing: build the software you want to build, and don't let leaches pretend that gives you an extra obligation to them. Particularly don't let leaches argue that your inability to keep leaches away is your fault. Honestly, the Log4j maintainers would have been completely justified in saying, "hey, yeah, we see this critical vulnerability, but it's the weekend, we'll get to it on Monday."
As someone who's pointed 10's if not hundreds of thousands of dollars to open source projects, blaming lawyers is unfortunately not the solution either.
Companies have budgeting and legal solutions laid out, its pretty much a first year problem. Engineering and IT want money to go to those developers. The issue is finding and getting money to these developers in accordance to tax code, jurisdiction/etc, its basically a regulation issue. On top of that, many developers don't want to deal with the tax hassle of getting paid for a $50-200 solution because it opens them up to ID theft and a whole morass of problems.
For the moment the most effective use of my dollars has been to donate to foundations and tag my donation with a "hey, can you use this for $XYZ", and that works. The FreeBSD foundation does a great job of this and thats why I donate money to them every year.
If there was something like this that encompassed more developers, I'd be really keen to see that as well.
So on some level, I agree, and in particular I think that having these meta-organizations and middleperson organizations that essentially act as money-pits and then put in more of the hard work to distribute funds or support -- that's a great idea, and I'd love to see more stuff like that.
And I am grateful for companies that are putting the work in to try and solve these problems, we need more of that, so thanks for the work you have done and thanks for your thoughts on the problems.
I still have a couple of specific, narrow objections overall:
----
> Companies have budgeting and legal solutions laid out, its pretty much a first year problem.
> The issue is finding and getting money to these developers in accordance to tax code, jurisdiction/etc, its basically a regulation issue.
Who's more equipped to solve those problems, companies or unfunded developers building stuff in their spare time? Who has more lobbying resources to change tax laws, Microsoft or Open Source developers? Saying that this is a corporate/business problem is not necessarily the same as saying it's an easy problem, it's just saying that the stuff you you bring up above are company issues, not problems with Open Source. Open Source isn't broken, companies are broken in that they struggle to interact with or support the ecosystem in productive ways.
It's a business problem that budgeting is so rigid that companies can't on-the-fly budget (or never thought to budget in the first place) resources to maintaining infrastructure that they rely on. It's a business problem that businesses don't understand their supply chain well enough to know what they're relying on or how to get in contact with or support the projects that they're relying on to remain stable and secure. These are complicated problems to solve, but let's be clear about where they lie.
Yes, there are tax complications, there are regulations. These are also problems that companies are more equipped to solve than developers are; companies have legal departments that can help navigate taxes, and individual developers do not. It's a business problem that companies don't have mechanisms/infrastructure to distribute support to things they rely on without falling into complicated legal holes. Yes, there are problems of finding the projects that need funding, but once again, businesses are more equipped to examine their own dependencies than developers are to try and figure out everyone who's relying on them and how important their libraries are to those companies.
And yes, you are absolutely correct that not all developers want to get paid traditionally (or even paid at all), and that's a choice we should preserve. But in some ways, that's exactly why this is a corporate problem: it's good that people get into Open Source with different motivations and needs, and it is better for the tech industry to evolve and figure out how to support those developers through nontraditional means (QA volunteering, patches, documentation, attention/promotion, one-off donations, etc), than it would be to try and "professionalize" Open Source. Even in the scenarios where people want literally nothing, and they don't want to be critical infrastructure at all, it's still kind of the company's responsibility to figure that out and to figure out if they're comfortable taking on the risks, or if they need to either use something else or fork the project.
For all of its faults, Open Source works pretty well, that's why companies rely on it. And I think part of that is the messy non-commercial aspects, the accessibility of contributing that means a company might be using a library built by someone who's only 15 (which for sure makes corporate funding complicated), the lack of hard requirements or contracts that mean a developer might walk away from something a company is relying on -- these are not accidents, they're deliberate parts of the system that allow non-professional people to take part in building the commons and solving their own problems. And yet for all of that messiness, Open Source produces software that's good enough that businesses rely on it. So when we have a system that is producing good software that people rely on, but the funding methods and support methods that businesses are capable of engaging with don't always line up with that system -- this is a case where businesses and the surrounding tech industry that should change, not the system that's producing good software that people rely on.
I will note that in the case of log4j, the developers are interested in normal funding -- this specific situation isn't a problem with figuring out in what way to support developers, it's a problem stemming from the fact that businesses don't know how to analyze their dependencies and figure out which parts need support (which is why they didn't realize that log4j devs wanted funding), and that businesses don't know how to donate to those dependencies or that the businesses aren't flexible enough to make those donations using the payment systems that many Open Source developers prefer. So there are broader questions about what projects want support, but log4j is kind of one of the easier examples; if businesses can't figure out how to donate to this project without an invoice process (even if the reason why is complicated and protracted and multifaceted and hard to solve), then businesses really are just broken in this regard.
Thanks so much :) No promises on timing, but sure, I'll do my best to write something up.
And thanks for commenting as well; I'm honestly really relieved that this apparently didn't come off as too critical, I was somewhat worried about that. It's a weird situation where your post is one of the better ones about Log4j2 that I have seen today, and there's stuff there that I really appreciated you writing and articulating, particularly around your hesitation to make things that companies would start relying on. But it was also the only one that got up to the top of HN that I saw when I logged in, and... I kind of went back and forth whether it was right to complain about a broader trend underneath it, given that the actual substance of your article really isn't falling into the trap I was complaining about.
Anyway, just reiterating that you wrote a good article and a good take, and it's not even that the title is egregious or worth a rant in isolation, it's fine. It was just the Nth title over X months that I've seen about Open Source funding that happened to be phrased as the Open Source problem, directly after I finished reading a different article that was suggesting that Open Source devs all need to learn how to set up their own LLCs and invoicing departments.
That analogy is a false one. Duck hunting is a self-selecting, non-mandated recreational activity for privileged people, not an activity that forms a critical role in a global pro-business economy.
The correct analogy is:
If the law mandates the indiscriminate killing of animals, you don’t title an article that some animals have become extinct, you say that the indiscriminate killing of animals has caused the extinction event.
The given analogy misattributes the source of the harm based on proximate factors… in effect it’s saying ‘i didn’t kill the animal… the bullet from the gun I fired caused the animals heart to stop’ - it’s a VERY shoddy argument.
What law mandates that companies can't donate to someone on Patreon or help triage bugs or dedicate QA/security time to identifying issues? What law mandates that companies have to ignore maintainer burdens? Each company made an individual choice to use infrastructure that they weren't funding/supporting, to effectively transfer bug-testing and security reviews onto unpaid maintainers. Then the infrastructure they weren't supporting broke.
The mistake I'm trying to point out is in looking at a corporate problem, where corporations are not doing due diligence to ensure the success of the commons that their own products critically rely on, and then implying that it's the responsibility of Open Source maintainers to make it easier to fund them or to alter their culture/projects to better fit company priorities. Well if everyone relies on this stuff, then the people who rely on it can figure out how to support it.
That I'm seeing articles suggesting that the problem is that Github sponsorships are hard to explain to accountants -- well, it sounds like the giant accountant firms that are being paid a lot of money aren't doing their jobs well, and aren't actually able to navigate financial situations that are outside of their comfort zone. But that's not the Open Source community's problem to solve, and the law doesn't mandate that companies be unable to navigate those spaces.
Companies ended up in the situation where an undersupported library that they needed to be stable instead broke because of their individual choices as companies about what parts of their infrastructure they would and wouldn't fund/support.
There is a systemic problem here, but it's not systemic in the exact same way as many other systemic problems that we face -- it's not systemic primarily due to outside pressure or laws, it's only systemic in the sense that companies are systemically and culturally unable to think about infrastructure or the commons in a responsible, long-term way. Sometimes systemic problems are really hard and complicated, but sometimes there are systemic problems that basically boil down to, "a bunch of people are irresponsible, and if they stopped being irresponsible the situation would get somewhat better." I don't think that Minecraft is the victim of circumstances outside of its control, I think it's really reasonable to expect a game bringing in that much money for Microsoft to be able to look at its dependencies and proactively identify/reinforce fragile parts of their infrastructure. Minecraft wouldn't have needed to solve the entire Open Source funding problem to avoid this bug, they would have needed to figure out how to support the extremely finite number of libraries that they rely on and that are directly linked to the success of their product.
And we can talk about wide-scale problems that hold Open Source back, we can get into the weeds on concepts like UBI, or better payment platforms, of IP laws, or whatever. It's not that those conversations are bad to have or that they're not important in their own ways. But they're not prerequisites for Microsoft giving money to people. And even in a world with full UBI or in a fully post-Capitalist society, you still might have Open Source developers making really useful stuff, where those developers don't want to spend all of their time or energy on that project or want to take it in a narrow direction, and that's fine. That shouldn't be a situation that we're trying to eliminate. Open Source is accessible and it allows people to dip their toes in, to solve narrow problems, to pick up and port/extend other libraries without a complicated legal process, to collaborate across national borders, to evolve their priorities and to jump between or even abandon projects -- and it turns out despite everything that is a really great ecosystem to live in. I don't think it's right to try and tear that ecosystem down and rebuild it into something that's purely professional, which is what I think a lot of corporations want. I think it's a lot more reasonable to ask businesses to learn how to interact with and support developers who may or may not be professionally working full-time on each project; I think it's more reasonable to ask why when the Open Source community is building stuff that other people find useful, that it is also our job to figure out how to make funding us attractive. And more directly relevant to your argument, I don't believe that there's a legislative reason why companies like Microsoft/Google/Apple can't get better at this stuff right now.
The law that mandates that companies can't donate to someone on Patreon or help triage bugs or dedicate QA/security time to identifying issues is the requirement for CEO's to demonstrate good judgment in managing the company by maximizing profit for shareholders. The law that mandates that companies have to ignore maintainer burdens is similar, but much more obtuse, mainly concerning commercial and workplace agenda issues founded on aversion to risk.
The mistake I'm trying to point out is your analogy is wrecked, it's only a very small, but well scoped rebuttal. Your analogy, granted it has been taken out of the context of the comment, but it's important that analogies used to make a point actually map on to the concrete situation, and your analogy clearly doesn't achieve that. Anyway, let's move on to the substance of your comment. You want to shift the burden of fixing what is a very well documented and well understood market failure (free riding) on to corporates. I get that. You want to do that by shifting the burden of the fix to them. What you fail to grasp are the free market maxims which rule these companies. You are, in effect, asking people to stop writing articles about (say) wearing a face mask in public when faced with a public health epidemic and instead write articles about how animal husbandry practices in a small market in Wuhan is the real story. What your comment fails to capture is the systemic failure of Open Source. In the same way, an article about how a virus that is harmful to human health that focuses on hygeine ina market in Wuhan won't help anyone stay safe once it becomes an epidenic. You are, mistaking an epidemic for a malpractice suit. You don't solve an epidemic by suing the market traders in Wuhan, you write articles about wearing face coverings and public helath policy programmes like vaccines.
So, your argument is bogus.
Open source is broken, as a system, it is meant to be broken, it was designed to be broken in the same way Windows is designed to be broken, because it suits people that promote it.
If you are making FOSS you are perpetuating a broken system and are accountable for that.
If you design your house with no doors or windows and then proudly announce the fact it has no doors and windows and everyone is welcome to take a look around you don't get to blame people who wander in from time to time and take a look around.
The rest of your comment here seemd to flip flop between whether the problem is systemic or not based on ideas of what the system is, and what it is not.
I am not convinced by that analysis because the systemic failure is self-evident here and so to discuss whether open source software production is a system or not, or it is interacts with other systems or not seems naive.
Your point about Minecraft seems to show some naivety around the way production systems interact with economic systems.
Some form of interpretation from either the history of the industrial revolution or the economics corpus would probably be enough to disabuse you of your reluctance to admit the interplay between economic and technological systems.
Your opinions suffer from a widespread tendency for peoples opinions to be wrong. I include mine in that category too, but at least readers may benefit from beinga given a choice as to how wrong they wish to be.
Sorry, I didn't mean 'mandate' as in 'legal', I meant more like 'Social License to Operate' (SLO) which is more at the social/cultural level, although there are of course legal ways to keep corporations away from code... AGPL/Copyleft/Ethical Source/Noncommercial licening and Social Domain licenses all seem to be pointing to a new economic future that, despite outr differences in opinion here, I think we can both agree on, would be more desirable than the current situation?
> The law that mandates that companies can't donate to someone on Patreon or help triage bugs or dedicate QA/security time to identifying issues is the requirement for CEO's to demonstrate good judgment in managing the company by maximizing profit for shareholders
Dows this law forbid them from paying support contracts to Oracle or IBM/Red Hat or anyone else? Hey, if nothing happens that needs support, that money could have gone to the shareholders, right?
And yet, I can't recall ever seeing any stories about shareholder revolts against management because they paid "unnecessary" support fees to software providers. You got any handy links to such stories?
If not, it seems it's your argument that is bogus.
You don't seem to understand the dialectical shape of this argument. You would have to try to understand better how two things that seem opposite could both be true.
For example, Microsoft could pay Red Hat for whatever they like, but this does not contradict the general law of profit maximization. It is possible for a large tech company to achieve both these goals together (support for open source and undermining open source) without undermining the general law, which is to reduce costs wherever possible and maximize profits for shareholders however possible.
You need to think a bit more about the motivations and rules operating here, and if you do, you can't fail to come down on the conclusion that it is open source that is broken, because it reproduces the free rider problem as a well documented and persistent market failure.
> You don't seem to understand the dialectical shape of this argument.
A) No, you don't seem to understand the simple logic of the issue at hand.
B) "dialectical shape"... Yeah, use a lot of Big Words flim-flam, that'll surely make your argument so much more convincing. Sheesh.
> Microsoft could pay Red Hat for whatever they like, but this does not contradict the general law of profit maximization.
Exactly. So they could pay Red Hat for support and maintenance on this piece of software, too. Or, waitaminnit... Does this only work for paying Red Hat, specifically; are they mentioned by name in the laws on fiduciary prudence, or what?
Otherwise, one would have thought that if they can pay Red Hat to maintain this code, they can just as well pay someone else for that. Like, for instance, its original author(s).
> You need to think a bit more about the motivations and rules operating here
Yup. Mainly yours.
> and if you do, you can't fail to come down on the conclusion that it is open source that is broken
Oh yes, sure I can. Fail to come to that conclusion, that is. Wake up and adopt my perspective, and you'll see that if this shows anything, it's that it's the corporate model that is broken: It repeatedly leads to exactly this kind of simple-minded attempts to defeat the elegant copyleft judo trick at the root of open source, which repeatedly get the prospective beneficiaries... Exactly fuck-all.
> because it reproduces the free rider problem as a well documented and persistent market failure.
If this shows anything, it's the exact opposite: The habitual corporate parasites have been notified that there is no free support-and-maintenance plan for them to freeload on.
Yeah, the market is full of failures. Assholes thinking there is such a thing as a Free Lunch -- for them, only -- without any obligation for them to do anything for anyone else, is one of them. Once enough of them have failed that way, maybe the rest will learn from that. (Not that I'm holding my breath.)
> the requirement for CEO's to demonstrate good judgment in managing the company by maximizing profit for shareholders.
this is an inanely incorrect urban legend of a claim. The business judgement rule overrides it except in amazingly egregious circumstances, and paying the maintainers of business-critical upstreams would be profoundly unlikely to be such a circumstance.
Not really. Payments made to maintainers of business-critical upstreams are only sanctioned at board level if the failure to pay could result in identifiable additional risk to the business. As a general rule, this plays out as a kind of high level socialist monopolizing for big tech, and low level capitalist competition for everyone else.
> The law that mandates that companies can't donate to someone on Patreon or help triage bugs or dedicate QA/security time to identifying issues is the requirement for CEO's to demonstrate good judgment in managing the company by maximizing profit for shareholders.
People place an over-emphasis on this. Minecraft broke, the situation they ran into is no different than if their engineering team had introduced an XSS error in their own codebase. If this isn't something that's affecting company profits, then why are they complaining? And if it is affecting company profits, then it's in the shareholder interest to figure out how to support the work so their stuff doesn't break. Nobody says that the law mandates that companies can't have a QA team, companies are allowed to care about reliability. So if donating to someone's Patreon or kicking resources their way improves the stability of a product, then that's in a company's interest, it's not violating shareholder rights to take tangible steps to make your product more secure/reliable.
In general, companies are not quite as constrained as you are suggesting by requirements to pursue profit in the first place, but even from that perspective if we assume they are completely bound in that way, this is still either:
A) not a problem they should be complaining about since apparently it doesn't affect their profits, or
B) their problem to solve, since it affects their profits.
----
> If you design your house with no doors or windows and then proudly announce the fact it has no doors and windows and everyone is welcome to take a look around you don't get to blame people who wander in from time to time and take a look around.
I don't think anyone here is blaming people for using Open Source projects for free, that's by design. I'm blaming them for then turning around and saying, "hey, this thing we're using for free without contributing at all broke, something is clearly wrong with your process, why didn't you stop us from using your thing for free?"
It is directly by design that people can use Open Source projects without contributing back. That's not really the issue here.
----
> If you are making FOSS you are perpetuating a broken system and are accountable for that.
See, this kind of gets at the core of my criticism. The log4j devs didn't wake up in the morning with their house on fire. Minecraft did. Log4j devs didn't have a contract with Minecraft, they weren't losing money because Minecraft's house was on fire, none of this had to be an emergency for them. But somehow, not only is this suddenly log4j's problem to solve, but also it's their fault that Minecraft used their code and they're somehow responsible for perpetuating a 'broken' system?
It just doesn't make any sense; if you don't think that Open Source is maintainable or safe, then don't use it in your company. If you think it's valuable, then think more than 3 months down the road and commit to helping it thrive so you can continue to rely on it (and explain to your shareholders that sometimes share price is affected by zero-day vulnerabilities in products). Or don't, but then don't expect us to do a bunch of soul searching over how we can serve you better or change our culture to suite you.
Feels very weird to be relying on a commons as critical infrastructure by your own choice, and then complaining that the people building the commons are the problem because they're somehow enabling the system.
> AGPL/Copyleft/Ethical Source/Noncommercial licening and Social Domain licenses all seem to be pointing to a new economic future that
I don't understand why it's the job of people working for free to not only give people their code for free, but also to figure out the entire social/economic structure for how to get companies to contribute to the ecosystem.
> it's in the shareholder interest to figure out how to support the work so their stuff doesn't break.
100% incorrect. The motivation is to make as much money as possible which could mean anything... mothballing an investment, firing workers, outsourcing, making code proprietary, buying out competitors... whatever it takes to make money. You really have a very naive view of the profit at any cost rule that makes a corporate run.
Donating to someone's Patreon does NOT improve the stability of a product, so it is not in a company's interest. What they are more likely to do is hire the lead developer.
The corporates motivation is not to make a product more secure/reliable, it's to make their profits more secure and reliable, and very often this comes at a cost to product reliability and stability.
The entire Big Tech model is about creating artificial scarcity in tech and premature product obsolescence.
More money is made from financialization of the company than from products at the highest level. You need to look at that.
My understanding is your position is that Open Source isn't broken, it's all the free riding that's the problem.
The trouble with that is it is an argument from proximate cause. It seeks to eliminate the negligence on behalf of FOSS developers, the negligence of NOT fixing their work to a licensing regime that deters free riders.
> The log4j devs didn't wake up in the morning with their house on fire.
No, but they woke up everyday with a house they made from tinder, and built it in a dry and overheated climate, so how responsible is that?
> I don't understand why it's the job of people working for free to not only give people their code for free, but also to figure out the entire social/economic structure for how to get companies to contribute to the ecosystem.
You need to understand. That's what you need to do.
> Donating to someone's Patreon does NOT improve the stability of a product
Saying this more forcibly doesn't make it true. Demonstrably, a bunch of people's stuff broke because log4j was underfunded. You can't claim with such certainty that funding Open Source doesn't make products more stable after a bunch of companies just had a bunch of critical severity bugs because the project wasn't funded and didn't have enough eyes on it. That's a wild thing to say.
"Locking doors doesn't deter criminals, so our investors aren't going to pay for locks at my business", as you actively watch masked thieves walk out of your office building holding a flat-screen TV. Come on. :)
On the other hand, if it doesn't impact corporate profits, if Open Source stability isn't affecting businesses, then corporations can stop complaining about Open Source bugs, and we can all stop having these hot takes. But I think the reason we have these hot takes coming out corporate mouths is because they recognize that bugs do impact stability and they're interested in trying to make that into someone else's problem.
> You need to understand. That's what you need to do.
See, this is the thing though, I and the Open Source community don't need to understand this. The point I'm making here is that the log4j developers were not affected by this bug, it wasn't their stuff that was on fire, and nobody had a contract with them forcing them to care. Donating something to a company is not an obligation to service that thing.
Nor would it be "irresponsible" for the log4j maintainers to leave companies in that state. The Open Source community could just ignore all of this. The Open Source community doesn't benefit from Minecraft using their stuff for free, the Open Source community could turn over and go back to bed when people start panicking about Minecraft bugs. The Open Source community does not need to worry about anything other than the Open Source community, it is an act of both social and personal charity that people release code under permissive licenses, and doing so does not open them up to any additional obligation for support or any additional responsibility to guarantee stability.
If you want that support, then pay for it. And if you're not willing to pay for it, then fine, but then don't complain or expect sympathy from the Open Source community if your stuff breaks.
----
> My understanding is your position is that Open Source isn't broken, it's all the free riding that's the problem.
My position is not that free riding is the problem, free riding is a big part of Open Source, free riding is fine. My position is twofold:
- First, when you give someone something for free, and they come back with additional demands or complaints that it doesn't work as well as they want it to because they're not engaged in support -- it's not your problem or your job to devote additional work to making it easier for them free ride.
- Second, that at a systemic level people giving stuff away for free does not give them some kind of additional obligation to individually overthrow Capitalism or rework our entire economic system, and I think it's wild to look at arguably one of the most successful Anarchist spaces in the entire modern world and say, "it's not the businesses that are the problem, it's these people, because they haven't done enough to overthrow the entire tech industry."
----
You seem to be dipping your toes into a very cynical take on the tech industry that I'm not going to argue for or against. What I am going to say is that if I take your position, if I assume that the tech industry doesn't care about stability at all, that it only cares about rapid growth, that security vulnerabilities are acceptable to investors, that this all and elaborate shell game to monopolize and undercut competitors and choke down on the market and its workers -- from that perspective, it makes even less sense for us to have an earnest conversation about how Open Source can become more "professional" or how it can encourage companies to give back.
If I start from your view of the tech industry, then I am even more convinced that Open Source bears no obligation to these companies and that it's fine for the Open Source community to go off and do its own things and leave them to figure out their own problems. It doesn't make sense to have such a cynical view of how companies work, and then to say that Open Source developers are now somehow responsible for cleaning up this mess that companies caused. You seem very cynical about the potential stability of corporate products in general; but if they're so fundamentally broken then why not let them break?
It is a very strange philosophy for you to have where you're pointing at corporations and investor mentality as a fundamentally broken system, and then saying that Open Source devs are being irresponsible because they're somehow "enabling" these people. If someone sets out a bowl of Halloween candy and some kid comes up and takes the entire bowl, who is the primary person that you blame in that situation?
But sure, whatever. If I understand you, the central problem is that free riding is baked into our industry, and yet somehow it's individual unpaid developers building software outside of that profit-maximizing system that are to blame for all of it. So instead of holding companies to task, or trying to support the people building commons that aren't designed to monopolize or grow at all costs, or reworking economic systems to improve incentives, or even just acknowledging that Open Source devs don't have an obligation to support the industry, what we should actually do instead is criticize the Open Source community for not being itself Capitalistic enough. That will definitely help, and definitely won't just result in cementing the very systems you criticize. /s
> Donating to someone's Patreon does NOT improve the stability of a product
>> Saying this more forcibly doesn't make it true.
Sorry, my intention was to emphasize some basic economic logic, not enforce it.
Let me try again. Unless there is agreement between the financial donor and the recipient that the donation will be reciprocated with demonstrably more fitting outputs for the donor, do not expect to see any positive correlation between levels of funding and product stability.
Apache already has the model for log4j... and I'm not being facetious here, but for the sake of clarity only they call it 'governance' which is a comprehensive regime of massive corporate sponsorship, and volunteer 'PMCs' who are drawn from elite engineering backgrounds and participate mainly for social status, not money.
This is because people like myself, and people that like 'The Apache Way' see individual philanthropy and good science as a very complex relationship... and people like me would say... 'bad relationship'. Good science tends to be funded socially... through government organizations and civic institutions, Apache Foundation is one such institution. They accept private donations but it just goes into general funds AFAIK, most of the work done there is sponsored by Big Tech. We can argue that, if you want?
So, underfunding of log4j was not the issue at all. Apache projects I believe are generally well resourced and well managed. No?
> ...the reason we have these hot takes coming out corporate mouths is because they recognize that bugs do impact stability and they're interested in trying to make that into someone else's problem.
So, no... the reason is because corporate mouths are connected to corporate hands, and they have been dishing out money to Apache from the beginning. They believe they are owed something... and to some extent they are. You don't sh*t on your donors. That's the rule in the third sector.
This is why the log4j team are being held accountable. They trade off Apache reputation and the foundation they work for takes the money off many big corporate sponsors.
When you see the history of these issues it all makes sense and although your sentiment might appeal to lots of people, that is all it is... just like 'we shouldn't feck with cats'. That is the sort of argument you are involving yourself with. Sure, in an ideal world no one would feck with cats, but my argument is... when you see someone fecking with a cat, you don't just let them do it, sure, lock them up and rehabilitate them or get them to do some community service or whatever but mainly you want to be thinking about making sure that cats aren't so vulnerable... so you do stuff like make sure breeders are registered, make sure owners look after them properly and don't let their cats stray and so on.
You don't seem to have a very good grasp of the what The Open Source community actually is... it's about big corporates. All the millions of individuals, small and medium sized developers and end users are basically bystanders.
It might be worth coming back once you've got a clearer picture of the landscape. It's not what you think it is. It's not a pastoral idyll of happy, flourishing code crofters, it's a highly industrialized and monstrous tyranny dominated by surveillance capital...
When you see that, tell me if you still care if some prestigious Apache PMC engineer who chooses to work on something for free is really surprised when additional demands or complaints come in to the Brand he is trading off.
That's the deal here.
The systemic level is elite engineers on good salaries and high social standing working on high profile projects on the understanding that their reputation rides on being professional.
For them, it is not about overthrowing Capitalism or reworking our entire economic system, quite the reverse. Open Source for these people is about working to extend that system around the world. I'm using linux now and am under no illusion that almost all of it has been commodified... made alien to the people that worked on it... in the exact same way proprietary software is... the kernel included.
Open Source is capitalist, not Anarchist. I hope that much has been made obvious.
You misstate my position, I said big tech only cares about stability as far as it impacts on profits. Very often it will seek to make a product less stable in order to make money. Dishonesty is not a bug, it's a feature of all corporates.
Open Source is one big corporate hussle. Maybe you will want to look into that a bit more before you assume that Open Source is anything else? Thanks.
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 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.
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.
> 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.
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.
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.
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.
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!
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.
The broken part is dependency management. People will install anything as a dependency, and just because the code functionally works today they often assume that they can expect maintenance, support, and security into the future.
One of the biggest myths of "open source" is that it can replace commercial software in every way, but for free. It simply doesn't. Code is code, but nobody buys just code. They buy trust, support, a warranty, expertise, and a contract to back it up in court. You get none of this when your engineers `npm install who-knows-where-this-code-comes-from`
Engineers are kicking the can down the road, and I don't think management in most places truly understand the extent of the code their companies are running for which:
* they employ nobody who is familiar with it
* they have no vendors on call who are familiar with it
* they have no idea who is committing to it
* if anything goes wrong, there is nobody to help them
It's stronger than ever. Sure there's churn but to say it's broken is to challenge anyone making that claim to get along without it for any significant amount of time and continue their job, usages of the internet, and advantages thereof. I bet they will quickly revise their claim to some more specific aspect of open source.
Reading through the article the author doesn't seem be able to separate pay from success and uses anecdotes to support their point that open source is broken. They don't separate how any core library from a commercial company would have been any different in their security failures. This is like a poorly written first draft of a freshman research paper.
No it isn't. Not at all. The author is mixing systems of project governance with monetary incentives.
Open source is a system is project governance and maintenance, whether engineers are paid for working on those is a completely orthogonal question.
The log4j vulnerability is a perfect example. Software has bugs. Open source is no exception.
But instead of this being hidden inside some corporate closed code we all now about it, and a fix was already out when the story.
I do (strongly) agree with the Author on the fact that "freeloading" open source software does not work. In the end to some extent you get what you pay for.
Personally I am lucky enough to be paid to work (in part) on open source software.
Once there was a company who's main office had a water leak. Actually, water was leaking into the building from the basement. Turns out, it was built on a natural spring.
The water was perfectly drinkable. The employees on the lower floors started going into the basement and filling their canteens from the water there.
Eventually the company stopped paying the water company, because they were able to source all of their water locally.
But every once in awhile, there was an algae bloom somewhere upstream, the water was contaminated, and all of the employees got sick and had to stay in bed for a week. The company essentially shut down while the employees recovered.
The building manager tried to have the municipal water reconnected, but he was promptly fired, because they had free water in the basement.
Heck, they ran some tests and found that the water in the basement was actually, technically, more pure than the water from the taps. Except, you know, when it was making people sick.
Some local villagers who knew about the spring even showed up and helped maintain the basement spring. Not being paid employees, they were not beholden to the interests of the company, and weren't paid, but they still tried to sway management at the company to continue using the well. Coincidentally, they all had "well tender for 4 years" as their resume headlines.
Some employees, tired of getting sick and losing work, started building rain collectors on the roof. Management shut that initiative down quickly, because they were falling into "Not Invented Here" syndrome, and "reinventing the wheel" instead of pushing features.
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?
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?
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.
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?
Everyone involved has their own incentives, and gets to make their own decisions about when and where to invest their time and money.
Some devs are in it for the passion, some for the experience, some for the challenge, some for the learning, some so their work will live on when they change employers.
Startups get to use well-tested community supported libraries and don't have to build everything from scratch. Big companies get tech branding cred and can attract better talent, etc, etc.
And yes, maintainers sometimes get burnt out, consumers sometimes act inappropriately entitled, massively profitable enterprises often give back relatively little in return.
But that's all part of the deal going in, and everyone is fully aware of all the trade-offs straight from the onset.
What's so beautiful is that there are so many options whenever conditions change for any party. A maintainer goes to jail for vehicular manslaughter and a bugs needs fixing, no problem. Stand up a fork and the project continues on. A company's new leadership takes its own source project in a questionable direction and consumers are upset, no problem. Community forks and the project lives on.
And the result is we have this thriving, organic, creative, productive ecosystem which benefits us all in the end.