Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

811–820 of 913 posts

Re: FFmpeg to Google: Fund us or stop sending bugs

#811
is this a fundamental problem with the open source model, though? if we work within a model of continuous refinement and improvement but also accept the constraint that there's a fundamental limit to the resources someone is willing to give up in exchange for nothing (whether the resource in question is dev effort for no money or money for no ownership stake in the final product) then you see where something infinite is running up against something infinite and there's just no way to square that.

Re: FFmpeg to Google: Fund us or stop sending bugs

#813

People volunteer to make billionaires even more profit - crazy world. Who even have the time and resources to volunteer so much??? I don't get all this at all.

The mixture of motivations includes a desire to contribute something to humanity, a desire to make a mark or achieve recognition, or a desire to gain experience that might enhance your ability to get hired.

It can be a hobby like model trains and it can be a a social context like joining a club or going to church.

But it's safe to say that nobody is volunteering "to make billionaires even more profit."

Re: FFmpeg to Google: Fund us or stop sending bugs

#814

Is it unreasonable to ask that if a massive company funds someone to find a CVE in an open source project, they should also submit a patch? Google is a search company. Seems kind of... evil... to pay your devs to find holes in something with nothing to do with searching, then refuse to pay them to fix the problem they noticed.

Google contributes to ffmpeg on a fairly regular basis https://git.ffmpeg.org/gitweb/ffmpeg.git/search/HEAD?s=@goog... No it's not "unreasonable" to ask for patches along with bug fixes, but it is unreasonable to be mad if they don't. They could just not file the bug reports at all, and that is an objectively worse outcome.

>No it's not "unreasonable" to ask for patches along with bug fixes, but it is unreasonable to be mad if they don't

Your stance seems to be is that it is unreasonable to be annoyed by someone who is being unreasonable.

When I searched for synonyms for "unreasonable" in a major English language thesarus, the following synonyms were listed:

indefensible, mindless, reasonless, senseless, unjustified, untenable, unwarranted

So yes, it absolutely is valid for the FFMPEG crew to feel trolled by Project Zero.

Re: FFmpeg to Google: Fund us or stop sending bugs

#815

From TFA this was telling: Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and liste…

Finding the bug is 95% of the effort. The idea that reporting obscure security bugs is worthless is BS.

Re: FFmpeg to Google: Fund us or stop sending bugs

#816

Earlier quoted context omitted.

Not really. Their whole reason for not funding open source is it essentially funds their competitors who use the same projects. That's why they'd rather build a closed fork in-house than just hand money to ffmpeg. It's a dumb reason, especially when there are CVE bugs like this one, but that's how executives think.

> Their whole reason for not funding open source is it essentially funds their competitors who use the same projects. That's why they'd rather build a closed fork in-house than just hand money to ffmpeg. So the premise here is that AWS should waste their own money maintaining an internal fork in order to try to make their competitors do the same thing? But then Google or Intel or someone just fixes it a bit later and…

It's the tragedy of the commons all over again. You can see it in action everywhere people or communities should cooperate for the common good but don’t. Because many either fear being taken advantage of or quietly try to exploit the situation for their own gain.

Re: FFmpeg to Google: Fund us or stop sending bugs

#817

Earlier quoted context omitted.

You dont get to decide that lmao. Telling everyone this project doesnt care about security if they ignore my CVE is obviously a demand and your traditions can not change that

> Telling everyone this project doesnt care about security Google did nothing like this. If people infer that a hypothetical project doesn't care about security because they didn't fix anything, then they're right. It's not google's fault they're factually bad at security. Making someone look bad is not always a bad action. Drawing attention to that decision by publicly reporting a bug is not a demand for what the de…

Bullshit. That is exactly what google is doing. Demands aren’t necessarily malicious, but they’re certainly annoying for the person being demanded.

Re: FFmpeg to Google: Fund us or stop sending bugs

#818

Earlier quoted context omitted.

I've been a proponent of upstreaming fixes for open source software. Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do. Unfortunately, in my experience, there's often a lot of barriers within comp…

> Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate. I’ve been at several companies where upstreaming was encouraged for everything. The fewer internal forks we could maintain, the better. What surprised me was how many obstacles we’d run into in some of the upstream projects. The amount…

[deleted]

Re: FFmpeg to Google: Fund us or stop sending bugs

#819

Earlier quoted context omitted.

I've been a proponent of upstreaming fixes for open source software. Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do. Unfortunately, in my experience, there's often a lot of barriers within comp…

> Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate. I’ve been at several companies where upstreaming was encouraged for everything. The fewer internal forks we could maintain, the better. What surprised me was how many obstacles we’d run into in some of the upstream projects. The amount…

> The amount of time we lost to trying to appease a few maintainers who were never happy with code unless they wrote it themselves was mind boggling.

That brings us full circle to the topic because one important thing that gets people motivated into accepting other people's changes to their code is being paid.

If you work in FOSS side projects as well as a proprietary day job, you know it: you accept changes at work that you wouldn't in those side projects.

In the first place, you write the code in ways you wouldn't due to conventions you disagree with, in some crap language you wouldn't use voluntarily, and so it geos.

People working on their own FOSS project want everything their way, because that's one of the benefits of working on your own FOSS project.

Post reply on HN