Who's Paying to Fix Open Source Software? (dev.to) 142
The Log4Shell exploit "exposes how a vulnerability in a seemingly simple bit of infrastructure code can threaten the security of banks, tech companies, governments, and pretty much any other kind of organization," writes VentureBeat. But the incident also raises some questions:
Should large deep-pocketed companies besides Google, which always seems to be heavily involved in such matters, be doing more to support the cause with people and resources?
Long-time Slashdot reader frank_adrian314159 shares a related article from a programming author on Dev.To, who'd read hot takes like "Open source needs to grow the hell up." and "Open source' is broken". [T]he log4j developers had this massive security issue dumped in their laps, with the expectation that they were supposed to fix it. How did that happen? How did a group of smart, hard-working people get roped into a thankless, high-pressure situation with absolutely no upside for themselves...?
It is this communal mythology I want to talk about, this great open source brainwashing that makes maintainers feel like they need to go above and beyond publishing source code under an open source license — that they need to manage and grow a community, accept contributions, fix issues, follow vulnerability disclosure best practices, and many other things...
In reality what is happening, is that open source maintainers are effectively unpaid outsourcing teams for giant corporations.
The log4j exploit was first reported by an engineer at Alibaba — a corporation with a market capitalization of $348 billion — so the article wonders what would happen if log4j's team had sent back a bill for the time they'd spend fixing the bug.
Some additional opinions (via the "This Week in Programming" column):
Long-time Slashdot reader frank_adrian314159 shares a related article from a programming author on Dev.To, who'd read hot takes like "Open source needs to grow the hell up." and "Open source' is broken". [T]he log4j developers had this massive security issue dumped in their laps, with the expectation that they were supposed to fix it. How did that happen? How did a group of smart, hard-working people get roped into a thankless, high-pressure situation with absolutely no upside for themselves...?
It is this communal mythology I want to talk about, this great open source brainwashing that makes maintainers feel like they need to go above and beyond publishing source code under an open source license — that they need to manage and grow a community, accept contributions, fix issues, follow vulnerability disclosure best practices, and many other things...
In reality what is happening, is that open source maintainers are effectively unpaid outsourcing teams for giant corporations.
The log4j exploit was first reported by an engineer at Alibaba — a corporation with a market capitalization of $348 billion — so the article wonders what would happen if log4j's team had sent back a bill for the time they'd spend fixing the bug.
Some additional opinions (via the "This Week in Programming" column):
- PuTTY maintainer Andrew Ducker: "The internet (and many large companies) are dependent on software maintained by people in their spare time, for free. This may not be sustainable."
- Filippo Valsorda, a Go team member at Google: "The role of Open Source maintainer has failed to mature from a hobby into a proper profession... The status quo is unsustainable.... GitHub Sponsors and Patreon are a nice way to show gratitude, but they are an extremely unserious compensation structure."
Valsorda hopes to eventually see "a whole career path with an onramp for junior maintainers, including training, like a real profession."
This is a really simple problem to fix. (Score:5, Insightful)
If your company sells software to "banks, tech companies, governments" then your company is responsible for the security of that software whether you wrote it or utilized open source.
Re: (Score:2)
So now the only part missing is turning a vague "responsibility" into a legal obligation, to create an incentive for actually fixing stuff instead of waiting for the next disaster.
No, it is NOT a simple problem to fix (Score:2)
I even think the roots of the problems are complicated. On the one hand there is great confusion around "free" and "freedom", but the larger hand involves the lack of plausible economic models.
So as a little thought experiment, here's another angle of my favorite delusional solution approach (perhaps within the control of a CSB (Charity Share Brokerage)):
Any software module that involves network access would check itself and then 'phone home' to see if it's safe. Unless it gets the okay, the software will f
Re: (Score:2)
I think that the Apache Web Server offers a unique opportunity in that it's very name implies a lot of code churn:
There are other sources for the "patchy" software pun theory, including the project's official documentation in 1995, which stated: "Apache is a cute name which stuck. It was based on some existing code and a series of software patches, a pun on 'A PAtCHy' server." [wikipedia.org]
So, you have a piece of software that is literally used everywhere for web based software AND it has regular code churn, from a multi
That was over 20 years ago (Score:2)
Apache got that name in the 1990s, over 20 years ago. It was a bunch of patches to the NCSA server. Is your comment part of the Radio Shack Superbowl ad? :)
Apache matured around 2001 or so.
Re: (Score:2)
I was trying to focus on an economic approach to the original (admittedly broad) problem, but you are turning towards a much nastier mess. Or possibly intended your reply to go to someone else?
However, if you look in your new direction with a filter for the economic perspective, then it's the old problem of "achieving security" by making the attack too expensive relative to the value of the information that is being attacked. From that perspective, I'm already motivated to say "Surrender, Dorothy!" The situ
Re: (Score:2)
I agree that economics certainly play into it because good security practices make everything more difficult and incur costs
Most businesses need a demonstration of the "down side" before they are willing to budget money to mitigate it (otherwise there is no clear comparison)
I was pleasantly surprised to see how quickly our vendors got on it and delivered mitigation strategies, but that nasty little voice inside my head says there are more and we will really need to wait it out and see what comes to the fore
Re: (Score:2)
I really can't imagine that level of coordination because there is no economic motivation. And mostly because Microsoft "firmly" established the lack of liability for the damages.
But I think the situation regarding Apache is much bleaker than you seem to think... Imagine each contributing programmer as one link in the chain of security...
Re:This is a really simple problem to fix. (Score:5, Insightful)
Corporations (mostly) treat open source as a "free gift" - just as they treat the air, the water, and all other natural resources.
Because they can.
The root problem is the nature of the corporation as legally defined for the past 250 years. They have far too much power and far too little accountability.
Re: This is a really simple problem to fix. (Score:2, Interesting)
Re: (Score:3)
log4J is actually a quite nice piece of software. No idea what you have to object against it.
Why they introduced that idiotic feature of side loading classes, and that even via LDAP (and there is some murky text expansion/substitution stuff involved) I have no idea.
Re: (Score:2)
Re: (Score:2)
It seems like there is a trend among many open source projects to become overly-generic. The developers want to handle every edge case that any potential user might encounter. But that is precisely the problem. The more weird edge-cases a tool handles, the greater the risk there is of exploits.
There shouldn't be one tool that can do everything. Those who have weird edge-cases to handle can just write their own tool or find a specialized one.
I remember a few years back when some remote code execution exp
Re: (Score:2)
Re: (Score:3)
Log4j is clearly some poorly written module that shouldn't even be used.
I suspect your use of the word "clearly" indicates that you know very little about log4J, how it works, why people use it, and the alternatives.
Are you a politician or a lawyer by any chance? They are usually the ones who, immediately on hearing of a problem, are able to diagnose exactly what caused it and what "clearly" should be done to fix it.
Then it falls to subordinate pond life to carry out the orders from on high.
Re:This is a really simple problem to fix. (Score:4, Insightful)
If you sell software to *anybody* then you have responsibility. Unfortunately most vendors responsibility will just result in the CTO ranting at some poor developer who has zero experience with the inner workings of log4j to, "just get it done", before going back to his multimillion dollar Winnipesaukee lake home.
The reality is that most executive boards are living in la-la land about the use of OSS in their products and services. They want all of the good (immediately available without having to pay for its development), but rarely find money or time in their budgets to give back.
Re: (Score:2, Offtopic)
If you sell software to *anybody* then you have responsibility.
I guess you haven't read the Windows license agreement [microsoft.com] you simply clicked through:
Limited Warranty. Depending on how you obtained the Windows software, Microsoft, or the device manufacturer or installer, warrants that properly licensed software will perform substantially as described in any Microsoft materials that accompany the software. This limited warranty does not cover problems that you cause, that arise when you fail to follow instructions, or that are caused by events beyond the reasonable control of Microsoft, or the device manufacturer or installer. The limited warranty starts when the first user acquires the software, and lasts for one year if acquired from Microsoft, or for 90 days if acquired from a device manufacturer or installer. If you obtain updates or supplements directly from Microsoft during the 90-day term of the device manufacturer’s or installer’s limited warranty, Microsoft provides the limited warranty for those updates or supplements. Any supplements, updates, or replacement software that you may receive from Microsoft during that year are also covered, but only for the remainder of that one-year period if acquired from Microsoft, or for 90 days if acquired from a device manufacturer or installer, or for 30 days, whichever is longer. Transferring the software will not extend the limited warranty.
Damages. Except for any repair, replacement, or refund that Microsoft, or the device manufacturer or installer, may provide, you may not under this limited warranty, under any other part of this agreement, or under any theory, recover any damages or other remedy, including lost profits or direct, consequential, special, indirect, or incidental damages. The damage exclusions and remedy limitations in this agreement apply even if repair, replacement, or a refund does not fully compensate you for any losses, if Microsoft, or the device manufacturer or installer, knew or should have known about the possibility of the damages, or if the remedy fails of its essential purpose. Some states and countries do not allow the exclusion or limitation of incidental, consequential, or other damages, so those limitations or exclusions may not apply to you. If your local law allows you to recover damages from Microsoft, or the device manufacturer or installer, even though this agreement does not, you cannot recover more than you paid for the software (or up to $50 USD if you acquired the software for no charge).
The software will perform substantially as described. I mean, that can be taken to mean almost anything. And it's not just Windows; their flagship ERP solution, Dynamics 365 - an enterprise mission critical piece of software - has a similar clause.
Basically, no matter how you obtain software, you're on your own when things go wrong.
Re: (Score:2)
Whether or not you are responsible for fixing the open source software depends on what you sold your customer. You could be just selling a platform on which open source runs, including any drivers or integration layers for various open source components, but the customer is still responsible for maintaining their own open source components.
For example, when a company sells you a PC with Windows on it, you're still getting your Windows support from Microsoft. So if that PC comes with free Linux, your support
Re: (Score:2, Interesting)
I do agree with you, but this bit from the summary really bothers me:
"[T]he log4j developers had this massive security issue dumped in their laps, with the expectation that they were supposed to fix it. How did that happen? How did a group of smart, hard-working people get roped into a thankless, high-pressure situation with absolutely no upside for themselves...?"
Am I missing something here? We've got a bunch of people who write a piece of software that's well used, they don't do it out of absolute altruis
Yep. They can complain. (Score:5, Insightful)
"...and then they're complaining about having to fix said defect?"
Maybe on day one that's unreasonable. But if somebody writes a successful library and then inherits the expectation that they are subject to to never-ending support and swift response times in perpetuity... well, that's a good reason to never, EVER contribute open source anything.
The original developer who introduced the issue can probably be determined from the changelog and commits... but I'll bet they're long gone, too.
Like it or not, this is the Achille's heel of open source. You either implicitly accept it, or you mitigate it contractually with third parties. But don't hold volunteers to a commercial contract standard you don't have and they don't offer.
Re: (Score:2)
The flip side of that is that paying for a library also does not guarantee "support as long as you pay". Commercial software providers don't want to maintain the same thing forever, either -- they want people to move to the latest version, for various mostly defensible reasons.
Re: (Score:3, Insightful)
Quite easy to say as an anonymous armchair critic.
Re: This is a really simple problem to fix. (Score:2)
Re: (Score:2)
As a developer I wouldn't dream of shipping something open source then demanding someone pay me a bunch of money to fix a security defect in it. It's just astoundingly unprofessional and childish, and if a developer has this attitude then anyone should steer clear of them, their projects, and their code.
And we the multi-billion dollar conglomerates who rely on your free work thank you dearly. To show our appreciation we'll clap from our window to make you feel good about yourself. Oh by the way hurry the fuck up this issue is serious and costing us money. We will half our virtue signaling for every hour longer you take.
Re:This is a really simple problem to fix. (Score:5, Insightful)
Yes, you are missing something here.
Providing a free gift to the world does not obligate one to continue providing free gifts to the world. The source code for log4j was the free gift, and every wealthy corporation that accepted this gift has everything they need to fix it themselves. Further, THEY have an obligation to do so, because they sold a product for money. Selling a product for money is different that giving a free gift, and comes with higher obligations.
In this case, these corporations who accepted a free gift are treating the donor as if they had purchased a product from said donor. They did not. They have no leg to stand on. If they don't like these bugs, nor the pace at which they can be corrected, then they can simply stop accepting free gifts, and instead build their products themselves.
This situation is not the result of the open source community being immature and acting like children. It is the result of wealthy people-of-means scooping up free stuff and then feeling entitled to even more free stuff.
Re:This is a really simple problem to fix. (Score:5, Informative)
Providing a free gift to the world does not obligate one to continue providing free gifts to the world. [...] Selling a product for money is different that giving a free gift, and comes with higher obligations.
As many READMEs used to put it: "this is free which means if it breaks you get to keep both halves".
Re: (Score:2)
Providing a free gift to the world does not obligate one to continue providing free gifts to the world.
I've often thought of this as the 'volunteer's paradox'. If you volunteer for something, do good work, then later quit, you're thought of less well than someone who never volunteered in the first place.
Re: (Score:2)
Counterpoint: where I work, open source has to be supported. I can't take ownership and call it supported. Even if I fix security problems like this, the label on the tin has to say "supported" with the expectation that security issues get fixed upstream.
Re: (Score:2)
Counterpoint: where I work, open source has to be supported. I can't take ownership and call it supported. Even if I fix security problems like this, the label on the tin has to say "supported" with the expectation that security issues get fixed upstream.
Then you submit your patch to fix whatever issues you find. That is how issues get fixed upstream.
Re: (Score:3)
Which of the cloud providers contribute fixes for things that are "hidden" from the customer? I believe Amazon work with Xen but I don't think they contribute hardware for testing big installs on.
MS (obviously) wanted to have their hyper-v client supported, so contributed code to the kernel, due to selfish interest. What about other things? I know they're a Debian consumer for their ACS (Azure Cloud Switch), it says so in the wikipedia page https://github.com/Azure/SONiC... [github.com], and there's LWN membership for d
Re: (Score:2)
Yes.
And here's the thing. If your company is not paying a support contract to the open source vendor, then the open source vendor has NO obligation to help. Fix it yourself. That is the damn point. The software license says right there "no warranty, not responsible for any misuse (be it good or evil)"
The ideal situation is that if an open source product is being used by a big corporation, that big corporation is obligated to pay into the development of that product, be that in the form of cash or developmen
Re: (Score:2)
Exactly and especially in this case.
Log4j is a library, not a user facing application. Developers made a conscious decision to use it in their projects, and saved time by doing so. If log4j had not been available, they would have either had to write equivalent functionality themselves or pay someone else to do it.
There's nothing to stop such developers from joining log4j and contributing towards it. Any one of the myriad of developers making use of log4j could potentially contribute a fix for a vulnerabili
It has to be sustainable (Score:5, Insightful)
Re: (Score:3)
If you want people to pay you, you have to sell them something they want to buy. If your customer insists to only want to buy a closed sourced product from you, well, the choice is yours - close it and take their money, or keep it open and work free, in every sense of the word, as in: you're free to make whatever design choices, free to fix or not to fix any bug, and free as in work for free. One alternative is to convince your customer that you know better what they want - good luck with that. Another alte
Re: (Score:2, Interesting)
The fix for this issue was a configuration [cert.org]
If people want to use free software and then fail to configure it to run in a safe manner, then that is on them
RedHat makes it's money from services, if the are selling consulting services and then misconfigure it to be vulnerable they would be liable for it
Re: (Score:2)
Or Plan C - fork a proprietary version for your paying customers and decide for yourselves what bug fixes you've encountered in the proprietary branch you wish to back-port to the free version.
If your client(s) paid you to develop a proprietary-branch fix, under a contract which precluded (or delayed by X.Y major
Re:It has to be sustainable (Score:4, Interesting)
Today, Red Hat makes its money not from selling any "product," but by selling services. [zdnet.com]
That is what happened to Red Hat, and it is the clearest way to capitalize an open source project since it can be really hard to properly configure most of the time
Re: (Score:2)
If FOSS ends up being majority supported by corporate money, eventually they'll just decide it should all be proprietary instead. Isn't that what happened to Redhat?
No, RedHat sofware is not proprietary and in fact you can get the same software without branding or support from Rocky Linux [rockylinux.org]. Almost all other software provided by RedHat, such as Ansible has some similar model. They provide openly without support our if you get the version they distribute you get support in return for money.
Here's the deal... (Score:3, Insightful)
They under paid cheap developers who used whatever kewl shiny bit of code they could find as fast as they could, to shove a product out the door as fast as they could.
NOW, someone is trying to blame open source, because managers/executive filled their pockets with that process.
I'll say what the devs tell end users when they complain... Don't like it? Fix it yourself or pay for it to be fixed.
Stop looking around and asking "who should pay" (OMG... ME?! Take responsibility? Heaven forbid!!!)
Re: (Score:2)
Entirely depends on your attitude (Score:5, Interesting)
If someone sends me an email demanding that I fix something in their deployment of some open source software, without even clearly stating what problem they are having, they'll get a terse reply probably with a link to a page about the right way to get help (ie not by being an asshole).
If they then reply within "just fix it, damn, I WANT this feature and the user is always right", then I might reply with something like "if you want that feature, add it or hire someone to add it. Bye."
On the other hand, if someone submits an issue on GitHub that carefully describes what they tried, what they expected to happen, and what happened instead, along with logs or screenshots, I'll probably fix the issue right away. Because I *can* fix the issue - they've provided the needed info.
We know which response OP gets, and it matches up with what we'd expect from the time he tends to use.
Re: (Score:2)
Re: (Score:2)
"and the user is always right"
I would remind the complainer that the phrase is "the customer is always right", and that "the customer" pays money, sometimes in advance.
It's an important question. (Score:2)
My employers do. Yours might (Score:5, Insightful)
My last four employers have paid to help open source development.
When we had to med for software, I presented the cost-benefit for open source vs the $130,000/year proprietary software. When we wanted the open source software to do something different or better, or to have better documentation for a certain thing, I told my employer "I can make that happen". Then I did it. Over the last decades I've spent a Lot of time at work working on open source.
I never presented it to the employer as "you should support open source". I presented it as "we need X for Y business. I can make X happen next week. I'll do it using Moodle". (Apache, or a change into the Linux kernel or whatever).
From my experience, when any employer needs X done, they've normally say yes to me doing X, by modifying / improving some open source. Your employer probably also wants their problems solved.
By the way, you don't have to be a programmer to contribute. Most projects need documentation improvements. I started to say the only skill needed is to be able to write English, but actually that's not needed at all. Documentation in other languages would be great too.
Disciplined, organized testing is also needed. If you use the software, you can support it by doing some careful testing and it doesn't take long to learn how.
Re: (Score:3)
This seems strange. You were deciding to go open source because you could get it to meet your needs, and your suddenly 'needed' everything the next commercial version of the library needed? How were you going to deal with the requirements gap before? If you didn't have a requirements gap prior to the next commercial release, why would you care about keeping up with the commercial software?
Re: (Score:2)
The user community who defines the product backlog are usually informed on features by sales reps for commercial software and will demand the new features be delivered by their internal dev
that and you didn't use Git or patch? (Score:2)
Yeah it was foolish for the reason you said. Also because the new features should be a "git pull" away if the dev was anything like professional and did their changes as commits.
Corporations love free labor (Score:5, Insightful)
Re: (Score:2)
So do we all. I love the free labor Linus Torvalds has done for me over the years. I also love the "slave labor", if you want to call it that, that various paid Linux contributors have done over the years.
You can't really expect corporations to turn down gifts that you yourself wouldn't turn down.
It has nothing to do with being open source (Score:5, Insightful)
It has to do with huge numbers of developers and companies all using the same code/framework as everyone else. It is a single point of failure. The Solar Winds fiasco while maybe not apparent to some, is of the same kind. A single point of failure. It wouldn't matter if it was a commercially developed piece of software or open source, if everyone uses it, and it has a flaw, everyone experiences the flaw. And unlike what these articles try to portray, Log4J is managed by a highly reputable organization, Apache, that has a great deal of corporate support. [apache.org]
This does however point out how using frameworks too freewheeling, can lead to more places for code to fail, sometimes (maybe not in this case) without needing to. A lot of frameworks should maybe be more broken up with few dependencies between the pieces, allowing developers to omit more code that they might not need. And this still doesn't matter whether it is corporate/for profit libraries or open source.
Re: (Score:2)
"It has to do with huge numbers of developers and companies all using the same code/framework as everyone else. It is a single point of failure."
Are you proposing a world in which developers have to write everything from the ground up, including loggers? My car doesn't cost $100,000 because Toyota doesn't have to make a mirror or a cruise control circuit from scratch.
Re: (Score:2)
Re: (Score:2)
I think you exaggerate. But the answer is no, you don't have to do this, but if you don't, you have to deal with massive security issues when everyone and their dog suffer the same security bug at the same time. And then because there are a huge number of places with security holes, the bad guys have a field day until everyone gets things patched. And we know that all places patch things super fast at the same time, right? It's a trade off.
Maybe people should code to a standard of safety and security, and
Re: (Score:3)
It has to do with huge numbers of developers and companies all using the same code/framework as everyone else. It is a single point of failure.
For some libraries you might have a point. But this is about logging. Most people don't choose a logging library, they stick with what's already in use. You don't want logging from different components going to different files, and you don't want confusion around how to write 'logger.info(...)' because different logging libraries have different APIs. You don't want JAR hell because you use logger X but also library Y that depends on logger Z.
And there aren't a lot of viable alternatives in this space anyw
Re: (Score:2)
slf4j and its equivalent, commons logging exist to deal with your first point which is that the JDK introduced their own logger.
That is a solved problem from more than a decade and a half ago.
Re: (Score:2)
My parent should be modded +INTERESTING or +INFORMATIVE.
And everyone interested in that stupid "log4J feature", that got exploited, should read his blog.
It is very interesting.
Re: (Score:2)
The fact that it's widely used is partly because it's open source. As is the fact that not enough scrutiny went into it. Without a license requirement, it's hard to know who's using it and how widely it's used. The lack of income also means the maintainers can't pay for a security audit.
That's not to say making it proprietary necessarily fixes things, since you can skimp on security in the name of profit too. What's needed is a paid contract to help ensure the software is secure, however that happens.
Re: (Score:2)
Yes!! In my younger days, I was warned against adding trivial features to code because it was a risk. "You wouldn't want to be the guy that brought down the system because you wanted it to send you a text on your birthday (or insert your own odd feature), would you?" Many OS libraries are tight and specific, but sometimes they suffer from feature bloat.
In the end, that's not a coding problem, open source issue, and it's not even QA. I just don't need my logging system to make JNDI calls on its own (I
Re: (Score:2)
The guy who doesn't get it.
How it is supposed to work.... (Score:5, Interesting)
Re: (Score:2)
We get seriously dinged if we report a bug without fixing it.
So, if you spot a very hairy hard-to-solve but very-critical security bug you will be punished if you responsibly report it before you figure out the solution???
Re: (Score:2)
Re: (Score:2)
Re:How it is supposed to work.... (Score:5, Informative)
I've tried this with several FOSS projects, but I am not a developer, I'm a system admin and blue-team hacker. I noticed the bug, tested and trouble-shot the bug, traced it through and figured out a fix for the bug, submitted the PR and the bug report simultaneously, but the PR ended up gathering cobwebs because I didn't do the other eighteen things the developer wanted before they'd look at the PR.
Again, I am not a developer. I don't know how to write unit tests and I don't have time to read all the documentation to figure out how to sign my code (Which goes through Github, not e-mail), so a requirement of having said unit tests meant my PR sat, unnoticed. Some of the bugs in some projects have been fixed by others who were able to check all the boxes and get their PR accepted, which was the same as mine but bigger and fixed two bugs instead of the one I had. Other projects still have the same bug (Oldest is 3 years old now) but radio silence from their developers. For one project, I had to move away from it, for others I've written work-arounds, which I hate but keep it from filling up the drive with deleted logs, or crashing when exhausting memory.
Re: (Score:2)
Re: (Score:2)
which was the same as mine but bigger and fixed two bugs instead of the one I had.
That is considered bad practice.
There should only be one "ticket" per PR/patch. In other words: ake one fix, push it and ask for pull, then fix the other one.
Obviously it gets more tricky if yoou have to rework a complex piece of code which can not really be split up into separate fixes.
Not all open source is the same (Score:2)
Some open source is nothing more than a "reference implementation" or "this works, barely, on my machine, today, but don't rely on it except as a guide" code that shouldn't be used as-is in any production environment.
Other open-source code is rock-solid, professionally-written, and well-maintained.
Still other open-source code is small enough and simple enough that most professionals can understand it inside-and-out with a few hours of study, or less. This code basically doesn't need any maintenance except
Who should pay? (Score:2)
Re: (Score:2)
Yes it would (Score:2)
Re: Who should pay? (Score:3)
They shouldnâ(TM)t need to pay, but if they have highly trained and capable software developers, then contributing a fix would be in their self interest. There is a price for everything, even for free code, since at some point the original developers need to earn a living just like everyone else.
Re: (Score:2)
Or the original developers could get a job and develop their FLOSS project as a hobby, win for all.
Re: (Score:2)
A win until there's a zero day that affects projects of all kinds, all over the world, and no one wants to fix it because it's just a hobby.
Re: (Score:2)
Here we go again (Score:5, Interesting)
The old idealized image of FOSS versus the reality. The incorrect image some people insist on holding onto - where the Linux kernel, for example, is mostly maintained by a bunch of people in their spare time, who aren't paid to write the software.
But generally that doesn't hold up to even a few minutes browsing the changelogs and tracking down the repeat committers' LinkedIn pages. Last time we had this sort of discussion on Slashdot (about the kernel, that time), I did exactly that - and most of the people maintaining the kernel seem to be paid by numerous employers to do exactly that.
Go look at who's names are attached to the various fixes for log4j, then look up who those people are. These people are professional, paid coders. The linked article doesn't seem to have talked to them, so - did they develop log4j in "their spare time, for free", as is claimed? Or did they do it on the clock, either trying to solve some problem related to whatever job they were in at the time, or as a contractor? And, when they work on the patches, are they generally doing it on their employers' clock, or in their own free time?
Maybe the FOSS ecosystem does need some adjustments made... but, first, we should be forming our opinions based a realistic view of the situation - not some idealized view of what we think FOSS is, or what we'd like it to be.
Re: (Score:2)
Well,
if I could find a free lance contract to do FOSS, I gladly would jump on it.
Any links for places where to look?
I've seen it work out.. (Score:2)
For one, one of the writers is paid by Google to work on Go. That right there is a prime example of a viable profession. However, his experience suggests that he doesn't think he is valued for it. Which may be disappointing, but I don't know that he'd have a better experience if they did have a direct revenue stream associated with his work. Commercial software developers aren't universally happy with their career path (notably, ask EA employees...). I have a viable career in open source that pays on par
Re: (Score:2)
To be honest, while "this bug" is extremely annoying (I have problems to call it a bug, it is just a completely useless "feature" for most people, it actually should never have been pulled into the code base, but alas), "that bug" is also extremely difficult to exploit.
It can basically only be exploited via an inside job or under rare lucky circumstances.
Closed-source just flies under the radar. (Score:2)
This is spun as if open source is just not pulling its weight because nobody is paying enough for it. The reality is that closed-source components have the same types of issues, sometimes moreso because they can't have drive-by viewers carping on about something. Commercial companies are often better at getting ahead of and squashing news reports, but they often don't do anything at all about fixing things until someone forces them to.
A secondary problem is that since open source is free(-ish), it gets in
Lots of People are Paying. Help not wanted. (Score:2)
Most of the important projects are being worked on by people at work, people whose employers use the software.
Some people have this silly idea that there is some sort of work shortage for open source projects, but actually, there is a huge amount of competition among people who would like to be the one to fix any bug. If you go to a project and ask what you can do to help out, they'll usually tell you to try to write high level documentation for beginners, and submit it for review. But they accept very litt
Easily solved... (Score:2)
So, fix the broken code, and release it on a paid basis (for commercial use) for the first 6 months, before changing back to an open license.
You'll either make a reasonable living, or get the people making money off of it to contribute fixes and then you're off the hook.
Re: Easily solved... (Score:2)
Re: (Score:2)
Contractual restrictions get in the way (Score:2)
Moral Hazard (Score:5, Insightful)
Corporations cause moral hazard with their use of open source. They are not required to pay for the development of the software, which leads to hoping that volunteers will do necessary work for them. When there's a problem, they depend on the volunteers to patch things.
If volunteers didn't patch software, companies using open source would have two choices: either write the patch themselves (and probably bungle it in the process), or just outright not do it. Short of someone hacking the corporation and then bragging about it, the corporation isn't going to prove to anyone that they wrote, tested, and applied their own patch. You'd probably never know who was secure and who wasn't. That would lead to a lot of companies getting hacked, and a lot of users compromised.
OSS devs know this. That's why they go to great lengths to write code and fix bugs, whether anyone gives them any credit for it (much less money) or not. They know that their actions will lead directly to people either being harmed or helped. They could just say "fuck it, i'm going on vacation, I'll write a patch in two weeks.... maybe...." But they don't want to do that. They want to continue writing open source, and they know their work impacts people. They feel that moral obligation to make sure it works right. There's a lot of reasons people get into OSS, but the primary reason is a need to share and cooperate with others for the betterment of all.
It would be great if we truly valued and repaid all the people in society who do the difficult work it takes to keep society going. If we properly paid teachers, nurses, social workers, waste disposal, water & power, etc workers for all the good they do society. And maybe if we properly funded open source work, we would actually get a lot more re-usable technology and advancements that weren't locked up behind NDAs and kept in the code vaults of a single company. But we don't do that, because we don't really appreciate the work that keeps us all living our nice comfy lives.
If you volunteer to help push civilization up the hill, you're also volunteering for all the shit that's going to slide downhill at you. No good deed goes unpunished.
Re:Moral Hazard (Score:5, Insightful)
"companies using open source would...write the patch themselves (and probably bungle it in the process)" Why is that? If some company discovered the bug, it seems like they're in a good position to correctly patch it, because they've gone to the trouble of discovering the problem, and probably at that point understand it better than anyone else.
And I think there are lots of examples of exactly that happening: company X discovers a flaw in some OSS library L, implements a fix, and uploads it to the maintainer of L.
Re: (Score:2)
I meant it as a hypothetical where a hacker posts a 0day, not a company with a well-funded security and development team that publishes a patch. There's still tens of thousands of companies who just use the software and don't do security research or have experts in each language/framework, and so are reliant on vendors shipping them patches.... and waiting for somebody to ship them those patches. They are lucky because OSS devs do the work for them... but if OSS devs just went on vacation, they'd be SOL and
Re: (Score:2)
Like you say, a company is allowed to patch an OSS bug and keep the patch secret and not contribute it to the community. But that's usually a dumb move. It means they have to maintain the patch indefinitely themselves. If a new version of the OSS software comes out, it could be incompatible so the patch might have to be rewritten. In most cases the company is better off, from a pure selfish perspective, contributing the patch to the community. That is reflected in real live - a large proportion of OSS devel
ObXKCD (Score:3)
This XKCD actually summarizes the problem quite nicely.
https://xkcd.com/2347/ [xkcd.com]
I'm not going to spoil it.
The mouse in the room (Score:2)
There's a mouse in the room. Let's note that a fix for log4j has been out for a little while now as has a workaround if for some reason you can't move to the fixed version.
The remaining problems are related to the scramble to apply the update. A problem that you also have with commercial proprietary solutions.
Personal Dilema - Open source my project (or NOT) (Score:3)
I have been trying to get more people to try it out (for free) by downloading it from the website. I have lots of people tell me that I should just open source it. On the one hand, it will probably get a lot more people interested in it if I do. On the other hand, it could turn into a nightmare where I have thousands of people demanding all kinds of changes, fixes, documentation, etc. without any willingness to pay for any of it. Will it still be a 'fun project' in that case? I love to program. Actively maintaining an open source project might not be something I enjoy.
Re: (Score:2)
Assuming items are in random order, a system can be sped up by trading search-time operations for pre-search operations+data/space (this is excluding custom hardware like the asics used for fast parallel text search used by some large companies).
You say without needing separate indexes, but you would need to have some sort of pre-processing and data structure to be orders of magnitu
Re: (Score:2)
Re: (Score:2)
Same with closed source software (Score:2)
The issue is the same with closed source software, but at least with log4j you got to see the source code.
If you "purchase" (read license/rent) a Delphi component (yes I am that old), or a closed source database driver, you'd have no idea what is included in your final application. You might have the best developers on board, but still ship a rootkit it an updated version of those libraries had hidden backdoors.
With open source you get the same exact level of guarantees: i.e.: none. But you can look at the
Re: (Score:2)
There exist software licenses that discriminate against the giant corporations.
When you choose a license, you're expressing your preference. These developers have no problem with giant corporations freely using the software.
It's so weird for other people to get upset on their behalf.
Re: (Score:2)
It's so weird for other people to get upset on their behalf.
This trope goes around everywhere. When the developers chose to use e.g. the MIT license instead of the GPL license, it's not their own freedom that they gave away, it's the freedom of their users. I personally believe that is within the developers rights, though it is an arguable point. What's important though, is since it's the user's freedom which is being given away, it's the user's responsibility to get upset about it.
In my opinion, when users find themselves with developers doing this to them, the
Re: Free makes the world go flat. (Score:2)
it takes money to make things happen.
You almost had me there... :-)
Joking aside, taking money they do all right. Making things happen... not so much. You're not paying much attention if you thing closed-source, proprietary software is any way better or more reliable than Free or Open.
In the end it's about incentives. Given a profit incentive, if they can get away with not fixing stuff, they won't fix it.
Re: (Score:2)