Live data from Hacker News

Professional maintainers: a wake-up call

blog.filippo.io

131–140 of 464 posts

Re: Professional maintainers: a wake-up call

#131
post #2

Unpopular opinion: Maybe there is nothing wrong with the "status quo", maybe we don't need yet another attempt to finance small FOSS projects where it's hard to explain how money will actually solve any of these issues. Maybe people just need to be more considerate of what they depend upon. And in the case that a popular yet well maintained project has a CVE on day, maybe we need to accept that popularity does not ma…

Quite honestly, I think that if companies paid open source maintainers to get the features they wanted, the log4j problem would NOT have been averted at all, it would likely have happened earlier... notice that the source of the issue (support for JNDI lookups right into any log messages) was introduced because of someone asking for that feature (and getting it for free!)... if a company had paid for it, it would've been just the same, I doubt very much the company would have done any kind of security veto on the implementation.

What's needed is for open source libraries to somehow get "rated" by security experts before they get used by businesses. If those businesses using it paid for that, and then paid someone to fix any issues found, then I think we would have a working solution. Just paying for features would just make things worse... have you ever seen companies paying for security features, though?? No, I haven't at least... they pay for business features that will make them money, they hope, security is kind of just implied (and they might lay the blame entirely on the developer if they actually had a business relationship with them - which may be a big nightmare, actually, for OSS developers - and I am one of them myself... you can no longer use a license that just says you're not liable to anything bad that happens).

Re: Professional maintainers: a wake-up call

#132

Earlier quoted context omitted.

It seems like you haven't quite got the concept of open source. If everybody consumes and nobody contributes, how long will that last? A while back I bought a cheap robot vacuum. Their scheduling feature didn't meet my needs, so I reverse-engineered the protocol and open-sourced a cron-friendly CLI tool and a library so people could do other things with it: https://github.com/wpietri/sucks Honestly, this was a mistak…

IMO, I think the golden age of completely FOSS apps (no open core) is ending/has ended as users expect more features and apps struggle to meet demands without effective monetization. I think open source will always have a place for libraries and tools, but end user applications will either become open core or no longer open source.

Entirely possible. Although I suspect more libraries and tools will go that way as well. Note that mine was in theory a library/tool. And the examples mentioned in the blog post were similarly infrastructural.

Most of us work at such high levels of abstraction we couldn't even name all our dependencies. Which in effect makes us the same sort of consumers app users are: expecting a lot out but not putting anything in.

Re: Professional maintainers: a wake-up call

#133
It's a bit dubious that paying maintainers more will make them write more secure code. Certainly professional developers who write closed source have produced plenty of vulnerable code in exchange for their six-figure salaries. If you're really concerned whether a particular open source package is secure, it'd make more sense to pay a third party to audit it than the maintainer.

Re: Professional maintainers: a wake-up call

#134
post #74

> Now is the perfect time for Open Source maintainers to become legible to the big companies that depend on them—and that want to get more out of them—and send them five-to-six figure invoices. Well, this is exactly what I've been doing around VideoLAN (VLC, x264) and FFmpeg for the last few years. In order to do that, I've created 2 official companies Videolabs and FFlabs (besides the non-profit orgs) and I've gone…

It is really not that hard with the right licensing.

Offer your FOSS project with the meanest anti-corporation license you can find (AGPL?) which is not going to bother your user base but it is going to be a major hurdle for any corporation and then offer the software with a corporate friendly license for 100.000 / year.

Wouldn't this work?

Re: Professional maintainers: a wake-up call

#135

Earlier quoted context omitted.

Reviewing code is the elephant in the room. Filosotile -perhaps out of ignorance or disconnect- fails to mention that the vast majority of open source projects (log4j being a great recent example) are absolute shit. Nobody should be building anything on top, nevermind giving the maintainers more money. In-house development, software BOMs, rising of standards and multiple rounds of code review are the processes that t…

I would be fascinated to see your evidence that in-house code is any better on average than open-source code. I haven't done a lot of consulting lately, so I haven't seen much in-house code in the last few years. But my experience is that the average in-house codebase is worse. And that makes sense from the incentives. Open-source projects that want more than one contributor need to be approachable enough that people…

I worked at engineers-call-the-shots fintech and later SV shops for many years. No, their in-house code is not worse than open-source.

In fact one can safely say that top companies that attract top talent also have methodologies in place that lead to better than average code quality.

Re: Professional maintainers: a wake-up call

#136

Earlier quoted context omitted.

Money spent on dedicated testing might have discovered it earlier perhaps?

I don't really see how the Log4J2 issue would have been uncovered by testing. It's not really a bug but more of a design flaw. The reason is that the whole JNDI string interpolation feature by itself opens a door to a whole world of layered complexity which you can't comprehend. And even if you could comprehend it all Java could add some feature to JNDI which introduces an issue which wasn't there when it was all tes…

Exactly, the JNDI feature has been on the docs for everyone to see for several years: https://logging.apache.org/log4j/2.x/manual/lookups.html

Anyone who knows anything about JNDI would've immediately recognized that this was an incredibly bad idea, as JNDI attacks are well known around black-hat circles (LDAP is just one of the things you can do once you have JNDI available).

Yet, here we are, several years later, acting surprised this thing existed and thinking that tests would've helped!? What kind of tests, exactly?!!? I think I am to blame myself, as many other Java developers who actually use log4j, has a good understanding of how it works, knows JNDI and LDAP, yet never connected the dots and noticed what this incredibly stupid feature was making possible.

Re: Professional maintainers: a wake-up call

#137
post #74

> Now is the perfect time for Open Source maintainers to become legible to the big companies that depend on them—and that want to get more out of them—and send them five-to-six figure invoices. Well, this is exactly what I've been doing around VideoLAN (VLC, x264) and FFmpeg for the last few years. In order to do that, I've created 2 official companies Videolabs and FFlabs (besides the non-profit orgs) and I've gone…

It is really not that hard with the right licensing. Offer your FOSS project with the meanest anti-corporation license you can find (AGPL?) which is not going to bother your user base but it is going to be a major hurdle for any corporation and then offer the software with a corporate friendly license for 100.000 / year. Wouldn't this work?

You run into problems when there are contributors other than yourself.

Re: Professional maintainers: a wake-up call

#138

Earlier quoted context omitted.

> I feel this is a problem of companies being cheapskates, not of OSS maintainers. So do not make it their problem. I do not make OSS for companies, but for enthusiasts, contributing to building cool stuff, students and researchers. I'm starting to do something different at my company. I'm finding the package maintainers for the non-commercial stuff we use in our product and making a donation. I'm also going to start…

What do you think of hiring maintainers to audit? Answer specific questions about usage and security, with some visibility into your codebase? We’ve talked this over and hit risks concerning access to code where we’d like an NDA that a consultant may dislike.

Consultants sometimes dislike NDA, because as a consultant, you are already expected not to disclose. It is strongly implied, like patient-confidentiality. Airing dirty laundry or competitive advantage as someone visiting many companies a year, is like a doctor amputating the wrong leg. You do this once, then you are out of a job and reputation.

Risk is on your end, so you pay for it. A 10k contract becomes a 12k contract. You clarify your risks, your mitigation method (NDA), and that the extra money is for the legal liability the consultant takes on.

Re: Professional maintainers: a wake-up call

#139

Earlier quoted context omitted.

Reviewing code is the elephant in the room. Filosotile -perhaps out of ignorance or disconnect- fails to mention that the vast majority of open source projects (log4j being a great recent example) are absolute shit. Nobody should be building anything on top, nevermind giving the maintainers more money. In-house development, software BOMs, rising of standards and multiple rounds of code review are the processes that t…

I would be fascinated to see your evidence that in-house code is any better on average than open-source code. I haven't done a lot of consulting lately, so I haven't seen much in-house code in the last few years. But my experience is that the average in-house codebase is worse. And that makes sense from the incentives. Open-source projects that want more than one contributor need to be approachable enough that people…

As someone that has to support a lot of in-house code, yea, it's a bunch of crap too.

"Works good enough" is how our world generally operates unless under strict regulatory guidelines.

Re: Professional maintainers: a wake-up call

#140
post #104
post #94

Earlier quoted context omitted.

> You need a proper "asshole" in such organizations that will go and threaten complete lack of support if the bill isn't paid. That's the point, they don't pay, and they don't get support. But they still complain when there is a major CVE. > For comparison, $1M is the total yearly cost of ~3 average engineers at FAANGs. I wish we got that...

1) Create a funding report newsletter for FFMPEG 2) When funding is low, big scary exclamation marks all over the place 3) Include a bulleted list of doomsday scenarios showing what could happen to YOU if a bug/vulnerability is found 4) Add a picture of a sad kitten or crying baby for good measure Now just subscribe all of the non-tech business people at organizations that use FFMPEG, and wait for them to panic. (Mak…

> Now just subscribe all of the non-tech business people at organizations that use FFMPEG ...

Don't do that bit unless you're sure it's not illegal in your (and their) jurisdiction.

Spam being a thing, and there being laws against it.

Post reply on HN