←back to thread

1124 points CrankyBear | 2 comments | | HN request time: 0s | 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 #
skrebbel ◴[] No.45891966[source]
How could ffmpeg maintainers kill three major AWS product lines with an email?
replies(5): >>45891984 #>>45892034 #>>45892354 #>>45895260 #>>45899217 #
zxspectrum1982 ◴[] No.45891984[source]
Easy: ffmpeg discontinues or relicenses some ffmpeg functionality that AWS depends on for those product alines and AWS is screwed. I've seen that happen in other open source projects.
replies(3): >>45892090 #>>45892103 #>>45894363 #
NewsaHackO ◴[] No.45892103[source]
But if it gets relicensed, they would still be able to use the current version. Amazon definitely would be able to fund an independent fork.
replies(6): >>45892164 #>>45892171 #>>45892460 #>>45894578 #>>45894811 #>>45900051 #
deaddodo ◴[] No.45894578[source]
And then the argument for refusing to just pay ffmpeg developers gets even more flimsy.

The entire point here is to pay for the fixes/features you keep demanding, else the project is just going to do as it desires and ignore you.

More and more OSS projects are getting to this point as large enterprises (especially in the SaaS/PaaS spheres) continue to take advantage of those projects and treat them like unpaid workers.

replies(2): >>45895750 #>>45898949 #
zdragnar ◴[] No.45895750[source]
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.

replies(4): >>45896076 #>>45896101 #>>45896612 #>>45898528 #
AnthonyMouse ◴[] No.45896101[source]
> 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 wisely upstreams it so they can pay less than you by not maintaining an internal fork. Meanwhile you're still paying the money even though the public version has the fix because now you either need to keep maintaining your incompatible fork or pay again to switch back off of it. So what you've done is buy yourself a competitive disadvantage.

> that's how executives think.

That's how cargo cult executives think.

Just because you've seen someone else doing something doesn't mean you should do it. They might not be smarter than you.

replies(1): >>45903000 #
1. illuminator83 ◴[] No.45903000[source]
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.
replies(1): >>45904013 #
2. AnthonyMouse ◴[] No.45904013[source]
The tragedy of the commons is actually something else. The problem there comes from one of two things.

The first is that you have a shared finite resource, the classic example being a field for grazing which can only support so many cattle. Everyone then has the incentive to graze their cattle there and over-graze the field until it's a barren cloud of dust because you might as well get what you can before it's gone. But that doesn't apply to software because it's not a finite resource. "He who lights his taper at mine, receives light without darkening me."

The second is that you're trying to produce an infinite resource, and then everybody wants somebody else to do it. This is the one that nominally applies to software, but only if you weren't already doing it for yourself! If you can justify the effort based only on your own usage then you don't lose anything by letting everyone else use it, and moreover you have something to gain, both because it builds goodwill and encourages reciprocity, and because most software has a network effect so you're better off if other people are using the same version you are. It also makes it so the effort you have to justify is only making some incremental improvement(s) to existing code instead of having to start from scratch or perpetually pay the ongoing maintenance costs of a private fork.

This is especially true if your company's business involves interacting with anything that even vaguely resembles a consolidated market, e.g. if your business is selling or leasing any kind of hardware. Because then you're in "Commoditize Your Complement" territory where you want the software to be a zero-margin fungible commodity instead of a consolidated market and you'd otherwise have a proprietary software company like Microsoft or Oracle extracting fees from you or competing with your hardware offering for the customer's finite total spend.