←back to thread

FFmpeg to Google: Fund us or stop sending bugs

(thenewstack.io)
1125 points CrankyBear | 2 comments | 11 Nov 25 18:32 UTC | HN request time: 0.039s | 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 #
Astronaut3315 ◴[11 Nov 25 23:46 UTC] No.45894472[source]▶
I upstreamed a 1-line fix, plus tests, at my previous company. I had to go through a multi-month process of red tape and legal reviews to make it happen. That was a discouraging experience to say the least.
replies(4): >>45894676 #>>45895604 #>>45899267 #>>45902666 #
jamwil ◴[12 Nov 25 02:07 UTC] No.45895604[source]▶
In this scenario does your employer have strong controls around what whether you can write hobby code on your own time?
replies(2): >>45895732 #>>45897416 #
achierius ◴[12 Nov 25 02:27 UTC] No.45895732[source]▶
Generally yes. Or yes, you could just do it yourself in your free time.
replies(2): >>45896897 #>>45896939 #
1. dgunay ◴[12 Nov 25 06:16 UTC] No.45896897[source]▶
Even at places that are permissive about hobby code, a company ought to want to put its name on open source contributions. These build awareness in the programming community of the company and can possibly serve as a channel for recruitment leads. But the (usually false) perception of legal risk and misguided ideas about what constitutes productivity usually sink any attempts.
replies(1): >>45898079 #
2. whstl ◴[12 Nov 25 09:22 UTC] No.45898079[source]▶
It is amazing how companies want this "marketing" but don't want to put the actual effort to make it possible.

A tech company I worked at once had a "sponsorship fund" to "sponsor causes" that employees wanted, it was actually good money but a drop in the bucket for a company. A lot of employees voted for sponsoring Vue.js, which is what we used. Eventually, after months of silence, legal/finance decided it was too much work.

But hey it wasn't an exception. The local animal shelter was the second most voted and legal/finance also couldn't figure it out how to donate.

In the end the money went to nowhere.

The only "developer marketing" they were doing was sending me in my free time to do panels with other developers in local universities and conferences. Of course it was unpaid, but in return I used it to get another job.