←back to thread

FFmpeg to Google: Fund us or stop sending bugs

(thenewstack.io)
1125 points CrankyBear | 3 comments | 11 Nov 25 18:32 UTC | HN request time: 0.001s | source
Show context
phkahler ◴[11 Nov 25 19:41 UTC] No.45891830[source]▶
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 listen to me … ”

I agree with the headline here. If Google can pay someone to find bugs, they can pay someone to fix them. How many time have managers said "Don't come to me with problems, come with solutions"

replies(8): >>45891966 #>>45891973 #>>45893060 #>>45893320 #>>45896629 #>>45898338 #>>45902990 #>>45906281 #
skhameneh ◴[11 Nov 25 21:46 UTC] No.45893320[source]▶
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 companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate.

I have a very distinct recollection of talks about hardware aspirations and upstreaming software fixes at a large company. The cultural response was jarring.

replies(10): >>45894455 #>>45894472 #>>45894483 #>>45894572 #>>45895043 #>>45896339 #>>45896674 #>>45897121 #>>45901635 #>>45902318 #
cornonthecobra ◴[12 Nov 25 00:49 UTC] No.45895043[source]▶
I've literally had my employer's attorneys tell me I can't upstream patches because it would put my employer's name on the project, and they don't want the liability.

No, it didn't help giving them copies of licenses that have the usual liability clauses.

It seems a lot of corporate lawyers fundamentally misunderstand open source.

replies(5): >>45895275 #>>45895290 #>>45896892 #>>45898347 #>>45899056 #
mmooss ◴[12 Nov 25 06:15 UTC] No.45896892[source]▶
Why would they invest resources - scarce, expensive time of attorneys - in researching and solving this problem? The attorneys' job is to help the company profit, to maximize ROI for legal work. Where is the ROI here? And remember, just positive ROI is unacceptable; they want maximum ROI per hour worked. When the CEO asks them how this project maximized ROI, what do they say?

I believe in FOSS and can make an argument that lots of people on HN will accept, but many outside this context will not understand it or care.

replies(1): >>45896982 #
1. grumbelbart2 ◴[12 Nov 25 06:31 UTC] No.45896982[source]▶
If you fixed something in an open source library you use, and you don't push that upstream, you are bound to re-apply that patch with every library update you do. And today's compliance rules require you to essentially keep all libraries up to date all the time, or your CVE scanners will light up. So fixing this upstream in the original project has a measurable impact on your "time spent on compliance and updates KPI".
replies(2): >>45897282 #>>45898817 #
2. mmooss ◴[12 Nov 25 07:27 UTC] No.45897282[source]▶
That is a real benefit, I agree.
3. cornonthecobra ◴[12 Nov 25 11:22 UTC] No.45898817[source]▶
This touches on what I ended up telling them: maintaining a local patchset is expensive and fragile. Running customized versions of things is a self-inflicted compliance problem.

I still had to upstream anonymously, though.