Hacker News Reader

Comment by dewey | Hacker News Reader

> As our internal fork became increasingly outdated, we collaborated with FFmpeg developers, FFlabs, and VideoLAN to develop features in FFmpeg that allowed us to fully deprecate our internal fork and rely exclusively on the upstream version for our use cases.

Some comments seem to glance over the fact that they did give back and they are not the only ones benefitting from this. Could they give more? Sure, but this is exactly one of the benefits of open source where everyone benefits from changes that were upstreamed or financially supported by an entity instead of re-implementing it internally.

View on HN

One thing people can't fault Meta for is that they contribute back to the community at large.

We're using React Native, hello!?

We're using React!

Tons of projects, we should be very grateful they give so much tbh.

Let alone PyTorch, which greatly boosted the entire LLM wave. Thanks, Meta.

Those who benefit others deserve to be benefited in return — and if we could, we should help make them more fit.

hey hey hey the world would be a better place if we all used JAX instead :)

Yes, they do that, but it's not out of altruism. Gratitude may be the wrong word when Meta and Zuck have actively worked to erode people's trust in society and reality, while actualizing a technofuedalist vision of serfdom; literally a 21st century scheme for world domination and subjugation of the poors.

I agree with you - but the tools they gave out for free still stand no?

Just like the farm tools the serfs used were free too

They stand out as great examples of commoditising your complement.

When your business is pushing ads to people while they watch cat videos, then video processing software is your complement, and you want it to be as cheap as possible.

[0] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

zstd and the Folly C++ library are two that come to mind.

Yeah, but who needs the features of a corp who has to process zillions of videos? Very very very few. So your argument about FOSS is deeply flawed and only serves those in power.

Well the alternative is them just never upstreaming and maintaining their own fork, which seems worse for everybody

You missed the point. Who even needs their features? If you are as big as Meta you have the money and means to do whatever you want.

It's a positive development, but we can't minimize or ignore the conditions that precipitated it, giving back was less than hanging onto the changes for private benefit.

Still, Meta has also put a lot out there in open source, from a differentiation perspective it doesn't seem to go unnoticed.

A gentle reminder that all the big techs companies would not exist without open source projects

Would Microsoft not exist without open source project? Microsoft is that company founded in 1975, but the GPL license only appeared in 1989, and BSD licenses appearing at roughly the same time just because of the Unix Wars.

Big tech companies can easily hire manpower to make proprietary versions of software, or just pay licensing fees for other proprietary software. They don’t rely on open source. Microsoft bought 86-DOS to produce MS-DOS; Microsoft paid the Unix license to produce Xenix; and when Microsoft hired former DEC people to make NT, it later paid DEC.

Instead, modern startups wouldn’t exist without open source.

Indeed, open source exists despite Microsoft trying its hardest to kill it. Microsoft was (and still is) a ruthless, savage competitor. Their image has softened as of late but I'll never forget the BS they did under Bill Gates and Steve Ballmer.

Microsoft wouldn't exist without the theft of CPU time on time-shared computers.

I think they would due to massive financial incentive. On the other hand, a lot more developers might actually be getting compensated for their work, instead of putting their code on the internet for free and then complaining on social media that they feel exploited.

it's the exact opposite but alright, take a look at who's behind funding and sending code to the linux kernel if you want an example

The exact opposite? Can you elaborate?

I would more say it's both: this is kind of the idea of open source, at least for the large-scale projects that are permissively licensed.

And a gentle reminder that most of open source you use was developed and is maintained by tech companies.

Take a glance and contributor lists for your projects sometime.

Yes, they contributed to open source - this is a good thing.

But personally, I took issue with the tone of the blog post, characterised by this opening framing:

>For many years we had to rely on our own internally developed fork of FFmpeg to provide features that have only recently been added to FFmpeg

Could they not have upstreamed those features in the first place? They didn't integrate with upstream and now they're trying to spin this whole thing as a positive? It doesn't seem to acknowledge that they could've done better (e.g. the mantra of 'upstream early; upstream often').

The attempt to spin it ("bringing benefits to Meta, the wider industry, and people who use our products") just felt tone-deaf. The people reading this post are engineers - I don't like it when marketing fluff gets shoe-horned into a technical blog post, especially when it's trying to put lipstick on a story that is a mix of good and not so good things.

So yeah, you're right, they've contributed to OSS, which is good. But the communication of that contribution could have been different.

I find it hard to be too upset, better late than never. Would it have been better to upstream shortly after they wrote the code? Yes. Would it have been better if they also made a sizable contribution to fmmpeg? Yes. But at the end of the day they did contribute back valuable code and that is worth celebrating even if it was done purely because of the benefit to them. Let's hope that this is a small step and they do even more in the future.

As I said, the contribution is good, it's the communication via this blog post that I don't entirely like. It could have been different. It could have acknowledged better ways of engaging with ffmpeg (that would've benefitted both Meta and ffmpeg/the community, not _just_ ffmpeg).

But corporate blog posts often go this way. I'm not mad at them or anything. Just a mild dislike ;)

Yeah, I see what you mean. It basically shows that they contributed to ffmpeg purely because it helped them, but then they wrote this post to get good will for that contribution.

:thumbs-up:

I'm glad to know that outcomes are affected by having pure intentions. /s

I’ll take it. Metas purpose isnt to help the community, it’s to make money. Sucks to hear that out loud, but that is how capitalism works.

But you can use that to steer Meta. Explain how doing x (which also helps the community) makes them more money.

> Could they not have upstreamed those features in the first place?

Hard to say without being there, but in my experience it's very easy to end up in "we'll just patch this thing quickly for this use case" to applying a bunch of hacks in various places and then ending up with an out of sync fork. As a developer I've been there many times.

It's a big step to go from patching one specific company internal use case to contributing a feature that works for every user of ffmpeg and will be accepted upstream.

I've also had that experience of patching an OSS project internally, with the best intention of upstreaming externally-useful improvements in the future (when allowed).

However, my interpretation of the article was that they did a lot more than just patching pieces. They, perhaps, could have taken a much earlier opportunity to work with the core maintainers of ffmpeg to help define its direction and integrate improvements, rather than having to assist a significant overhaul now (years later).

> e.g. the mantra of 'upstream early; upstream often'

This is the gold standard, sure. In practice, you end up maintaining a branch simply because upstream isn't merging your changes on your timescale, or because you don't quite match their design — this is completely reasonable on both sides, because they have different priorities.

Getting something accepted upstream is orders of magnitude harder than patching it internally.

The typical situation is that you need to write a proof of concept internally and get it deployed fast. Then you can iterate on it and improve it through real world use. Once it matures you can start working on aligning with upstream, which may take a lot of effort if upstream has different ideas about how it should be designed.

I’ve also had cases where upstream decided that the feature was good but they didn’t want it. If it doesn’t overlap with what the maintainers want for the project then you can’t force them to take it.

Upstreaming is a good goal to aim toward but it can’t be a default assumption.

> Could they not have upstreamed those features in the first place?

This can be harder than you think. Some time ago I worked a $BIGCORP and internally we used an open source library with some modifications to allow it to fit better into our architecture. In order to get things upstreamed we had to become official contributors AND lobby to get everyone involved to see the usefulness of what we were trying to do. This took a lot of back-and-forth and rethinking the design to make it less specific to OUR needs and more generally applicable to everyone. It's a process. I'm not surprised that Facebook's initial approach would be an internal fork instead of trying to play the political games necessary to get everything upstreamed right off the bat. That's exactly the situation we were in, so I get it.

> Could they not have upstreamed those features in the first place?

Often when you are working on a downstream code base either you are inheriting the laziness of non-upstreaming of others or you are dealing with an upstream code base that’s really opinionated and doesn’t want many of your teams patches. It can vary, and I definitely empathize.

I guess it is much more frequent to maintain internal patches rather than doing all the merging work into upstream, especially the feature is non-trivial. Merging upstream consumes more time externally and internally, and many developers are working with an aggressive timeline. I don't think it is fair to criticize them because they didn't do ideal things from the beginning.

>For many years we had to rely on our own internally developed fork of FFmpeg to provide features that have only recently been added to FFmpeg

I really wonder if they couldn't have run the fork as an open source project. They present their options as binary when it fact they had many different options from the get go. They could have run the fork in an open-source fashion for developers of FFmpeg to see what their work was and be able to understand what the features they were working on was.

Keeping everything close source and then contributing back X amount of years later feels a little bit disingenuous.

Reply on news.ycombinator.com