←back to thread

1124 points CrankyBear | 1 comments | | HN request time: 0.212s | source
Show context
phkahler ◴[] 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 ◴[] 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 #
Aurornis ◴[] No.45896339[source]
> 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 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.

For some projects you can basically forget about upstreaming anything other than an obvious and urgent bug fix because the barriers can be so high.

replies(3): >>45897333 #>>45903363 #>>45903441 #
1. kazinator ◴[] No.45903441[source]
> 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.