Hacker News

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.

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

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.

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.

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.

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.

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

> 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.

> 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.

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.

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.

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.

> 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.

> 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.

I would guess if you have it export multiple files from the same source in one go it already does but could be wrong.

It wouldn't really be a good fundraising move to tell everyone that Meta took care of everything this fundraising year.

I'd say this post reads more like them beating their chest about how great their improvements are.

I think that WordPress is still big enough to keep PHP alive. Furthermore, the sheer number of developer that started coding web apps with PHP in year 2000 plus minus 5 years is large enough to give PHP a critical mass for the next 20 years.

> Meta is the sole reason PHP is still alive.

This could not be more wrong. Meta is still using PHP AFAIK but I'm not sure it's modern. They created the Hack programming language ~10 years ago but it doesn't look like it's been updated in several years. Most of the improvements they touted were included in PHP 7 years ago.

Yeah we’re in React SPA hell instead. I’d rather be in MVC hell.

And what in my comment said anything about there being a problem??

You make a lot of money, Meta makes A LOT of money.

doesn't matter how you worship ffmpeg if a company, which makes billions by destroying our society, gives a little bit of handout back.

So good for you? Bad for ffmpeg, society and the rest of the world.

I never said they didn't sponsor them, it just isnt enough, not even close.

and I know the teams love ffmpeg, there are some great folks at meta just not a lot in the c suite

[dead]