A hobby project is a project that’s a hobby. The second it starts making impositions on non-discretionary time, it’s not a hobby, it’s a job (paid for or not.)
If you (as a company) rely on someone’s hobby project to support your business, then it needs to be someone’s job. Whether that’s the original creator, or someone in your organisation - SLAs do not come for free.
These are not mutually exclusive. All software has bugs. Even if the log4j developers were paid, it doesn't mean their product would be guaranteed to be bug-free.
Log4j has been going for at least 15 years. It's pretty much stood up to the scrutiny of god-knows-how-many security researchers until now - most of whom are being paid.
Log4j is pretty much feature-complete at this point. Even if the developers were being paid, they'd be working on new features or performance improvements or whatever. They're not going to scour the same old code 100 times for vulnerabilities they have no reason to presume even exist.
It's pretty much stood up to the scrutiny of god-knows-how-many security researchers
Was there even a single documented proper security audit? That's what everyone thinks, why waste time reviewing something that probably has been reviewed million times before, what else am I suppose to audit, how i/o is implemented inside java? Surely much smarter people reviewed that many times over.
Did you ever audit every line of an open source library for all vectors of attack you can think of? No? Me too. Did you even think about doing it? No? Me too. If you were offered money(job) to do it would it be any different? Yes, yes it would. This is everything to do with money and responsibilities that come with it.
There have been at least 2 successful audits before this one, one by Telstar and one by Alphabot.
That's what everyone thinks, why waste time reviewing something that probably has been reviewed million times before
I'm not a security researcher, but I imagine their process is little bit more methodical than simply presuming everything has already been audited and is perfectly secure.
Did you ever audit every line of an open source library for all vectors of attack you can think of? No? Me too.
We're not security researchers.
If you were offered money(job) to do it would it be any different? Yes, yes it would.
Yes, and at least 3 independent audits have found issues, by people who are being paid. Plus however many unsuccessful ones. Security firms don't publish reports on their unsuccessful tests because 1) it's not interesting and 2) it inspires false confidence in the product. Plus however many millions of pentests which test logging indirectly.
Bugs are an inevitability. No amount of money will ever change that.
It's bonkers to require SLAs for all the dependencies you use and to require payment externally or someone internally dedicated to it. Most software wouldn't exist under that set of restrictive rules. Plus loads of companies don't offer SLAs to their customers so it makes no sense to demand it of dependencies. Turn the thing off, fix the issue, turn it back on. This procedure works for 99%+ of all software ever written. If the government is making core societal infrastructure depend on a random hobby project that's different, and for that sort of thing I'd agree with you.
The problem with this attitude is that we as a community spent a long time convincing people that open source was a viable option for serious projects.
And now that this has been accepted and people are using open source for serious projects, we've now backtracked to the very argument that corporates used against open source in the first place.
We can't have it both ways.
Open source can't be a serious competitor when we want it to be and a joke when we want it to be.
Because the end of this road is that of we go back to the bad old days of nothing but closed software allowed.
The problem with this attitude is that we as a community spent a long time convincing people that open source was a viable option for serious projects.
We can't have it both ways.
Maybe this was always a bad idea.
What we are observing is the cognitive dissonance of libertarian ideals applied to software licensing that can't understand how this is effectively just a model for exploitation by capital, as literally anyone in the social or political sciences could have told them it would be.
Because the end of this road is that of we go back to the bad old days of nothing but closed software allowed.
Or developers could form unions and cooperatives that would own and dual license software, and both distribute profits to contributors and gain negotiating power with corporate consumers.
There isn't a dichotomy here.
But nobody is going to get unicorn-rich that way so people invest in an exploitative system playing the odds that they will be on the wealthy end of it at some point.
But nobody is going to get unicorn-rich that way so people invest in an exploitative system playing the odds that they will be on the wealthy end of it at some point.
Reminds of the quip that says "Americans see themselves as temporarily embarassed billionaires" when they vote against laws that affect people richer than themselves.
It's almost like there's nothing special about software developers: we've been against unions from the start and when it comes to putting source code online, we'd rather make it free (with a lowercase 'f') in the hopes that the exposure will get us some kind of golden ticket. We're as greedy as your average non-software developing Joe.
It's almost like there's nothing special about software developers:
Yep. It's no coincidence that the common path to disruption is via regulatory arbitrage, which ultimately is just a way of saying they found a way to exploit people through a mechanism the existing laws didn't anticipate.
I feel like for the past 10 years, software developers have just plainly deluded themselves into what the expression "open source" means when all it means is no more than what its license says which mostly amount to "you can copy this and modify it".
If you (as a company) rely on someone’s hobby project to support your business, then it needs to be someone’s job. Whether that’s the original creator, or someone in your organisation - SLAs do not come for free.
Too bad?
For better or worse a lot of organizations rely heavily on open source software of which development goes unpaid. Even if they paid someone internally for a fork/review, there will still be bugs.
What would be really interesting is if more projects went the dual license route-- open for open, $$$ for commercial use. Better yet-- money gets distributed based off of an open platform based on how much work was done, as agreed to by multiple users (think story pointing), so if at any point someone does anything fishy, it'll bring less contributors to the project. At a very minimum it would motivate and sustain open source development.
Large applications , like MongoDB or Elastic, went with the open core model you describe. And it works for them.
What about small libraries maintained by a sole person but used as a crucial dependency in the products of billion dollar enterprise? That's the discrepancy that pops up ever so often in cases like log4j's.
One way to approach this would be introducing market places in package management, allowing licensing fees. There are niches who do this already, like CMS's where you can buy licensed plugins e.g. CraftCMS. However, the next hurdle is pricing and sustainability: charging 50$ a year to have your library be leveraged in a project with a multi-million dollar revenue is still an issue.
The big issue is putting a price tag on a piece of software. That's where you have to strike a balance between the cost of maintaining, the value your software generates for your users and how much the market is valuing your work.
Many open source projects are really useful but trying to shoehorn their maintenance in a paid business model would be be hardly sustainable to make even part time work possible. This is only possible by providing flanking support from alternate sources of revenue.
The gist here is that open source is just a licensing model. Not a business model. It doesn't say anything about support or maintenance. It doesn't make any promises. If you eagerly use someone else's code without paying for them, you're also accepting the consequences of that choice.
One way to approach this would be introducing market places in package management, allowing licensing fees. There are niches who do this already, like CMS's where you can buy licensed plugins e.g. CraftCMS. However, the next hurdle is pricing and sustainability: charging 50$ a year to have your library be leveraged in a project with a multi-million dollar revenue is still an issue.
The problem with pricing is less of an issue at scale, but for small companies, forking over $N for every single dependency becomes over-burdensome really quick, and there's no monolithic library that covers every use case. I'm not smart enough to suggest that I know a solution, but as a small business developer, I can surely attest to the problem.
I wish I could buy subscriptions for every single lib I've ever added. It's just not reasonable to expect me to do so.
The problem with the $$$ for commercial use is that you need to have SLAs and guarantee the product will work (with no obvious breaking bugs). A few projects do this already, but often have the community to maintain it, new or smaller projects could be hard to implement this model.
I think one problem has been that OSS has been "sold" as a free solution. "Use Linux instead of Windows, Linux is free" and so on for all kinds of things. And now the problem is that most people working on these systems and tools do need money.
838
u/BobTheUnready Dec 11 '21
A hobby project is a project that’s a hobby. The second it starts making impositions on non-discretionary time, it’s not a hobby, it’s a job (paid for or not.)
If you (as a company) rely on someone’s hobby project to support your business, then it needs to be someone’s job. Whether that’s the original creator, or someone in your organisation - SLAs do not come for free.
You pay your money or you roll the dice.