Meta has spent massive sums of money to train these models and they've released the models to the public. You can fine-tune the models. You can see the source code and the architecture of the model. The EULA is commercially-friendly.
You are free to quibble over how truly "open source" these models are, but I am very thankful that Meta has released them.
Open source developers have spent far more time to develop the truly free stack that Meta uses to power its business in the first place.
I am grateful to these developers. I am not grateful for a half open release and the redefinition of established terms. Which, judging by the downvoting in this thread, are now spread with fire and sword.
The stack was very usable in 2010. At that time, some gcc and kernel developers were employed by SuSE and RedHat. It was not common to be employed by a large corporation to work on open source.
Projects like Python were completely usable then. But the corporations came, infiltrated existing projects and added often useless things. Python is not much better now than in 2010.
So you have perhaps React and PyTorch. That is a tiny bit of the huge OSS stack. Does Meta pay for ncurses? for xterm? Of course not, it only supports flashy projects that are highly marketable and takes the rest for granted.
So no, only a tiny fraction of the really important OSS devs are employed by FAANG.
Meta employs kernel developers (and MySQL developers and memcache developers and the people that created and released zstd and a lot more). Aside from all of these are also a bunch of python code developers, and you might want to recheck the performance improvements of 2010 vs 2024 python - much of it driven by FAANG developers!
Should they? Both of those are client-side software that aren't even really being monetized or profited-off by Meta. You could maybe get mad at Meta's employees for not donating to the software they rely on, but in the case of ncurses and xterm they're both provided without cost. They're not even server-side software, much less a deliberate infrastructure decision.
There's an oddly extremist sect of people that seem to entirely misunderstand what GNU and Free software is. It does not exist to stop people from charging money for software. It does not exist to prevent private interests or corporations from contributing to projects. It does not exist to solicit donations from it's users. All of these are options that some GNU or FOSS projects can choose to embody, not a static rule that they must all abide by. Since Cathedral and the Bazaar was published, people have been scrutinizing different approaches to Free Software and contrasting their impacts. We don't have to champion one approach versus the other because they ultimately coexist and often end up stimulating FOSS development in the long run.
> Python is not much better now than in 2010.
C'mon, now. Next you're going to tell me about how great Perl is in 2024.
So, in this submission Meta adjacent opinions have called OSS supporters all sorts of names while being upvoted.
At least Meta is shows its true colors here. It must have hurt that the OSS position has arrived at the Economist yesterday, so everyone is circling the wagons.
Nobody here really has an agenda, least of all on HN where the majority of us hate Facebook like the living devil. Everyone remembers Cambridge Analytica and the ensuing drama, but we're also up-to-date on all of FAANG's exploits. Meta is a supporter of Open Source, and arguably contributes multitudes more than Apple or Amazon does. This idea that strings-attached weights releases tank their reputation is stupid; Meta's contribution is self-evident, and only looks stupid when you hold them to nonsense standards that no company would hold up to. Really, which Fortune 500 companies are donating to xterm and ncurses anyways? Is there anyone?
Again, there are arguments you can make that have weight but this isn't one of them. Every person with connection to wireless internet is running a firmware blob on their "open source" computer, it doesn't mean they're unable to bootstrap from source. Similarly, people that design Open Source infrastructure around Meta's binary weights aren't threatening their business at all. An "open" release of Llama wouldn't help those end-users, isn't even guaranteed to build Llama, and is too large to effectively fork or derive from. There's a good reason engineers aren't paying attention to the dramatic and insubstantial exposes that get written in finance rags.
Imposing financial discipline is one thing. Mistaking ephemeral "brand value" for engineering prowess and reputation (typical of marketing-oriented mgmt), as cited above, is quite another.
Being required to optimize for another real-world constraint (i.e., cost in this case) is more work, but ultimately just another task for an engineer. Being required to not engineer greatest-practical-stuff, but just slap the name on some junk is not the same thing, but marketing people can't see that, even though customers can.
I'm concerned about the Chinese ownership, but that seems murky now, since NEVS bought a stake or strategic partnership, then got bought 51% by Chinese real estate conglomerate Evergrande, which is deeply in debt, and NEVS is now in "permanent hibernation mode", essentially liquidating. I wonder if there's opportunity to get it back in control of democratic nations. Anyone have deeper information?
Saab had been nationally subsidized for a while and I think expected to receive support that didn’t work out. It was strange how all projections showed failure but they continued on.
Not sure why Sweden decided to make them go independent, but if GM hadn’t bought them, they would have died sooner
Then there's the question of how the electric grid will sustain this significant new increase in demand. As with mandates banning gas cars, the grid supply and stability is always regarded as a mere detail to be sorted out later.
Slack is great in small doses, but a complete time-waster beyond a certain threshold. I don't have ADHD, but I still have had problems with Slack. Don't feel bad about shutting all notifications off, or, better yet, closing the app entirely, and only opening it once or twice a day. You will almost instantly feel better. Some people may get annoyed that you're not instantly available, but if you're not able to get your work done then many more people will get annoyed. There is no perfect solution.
I have worked in both semiconductor manufacturing and drug discovery industries. Reliably and profitably producing 5 nm chips is an extreme engineering challenge, but- it is an engineering challenge. Drug discovery is a question of science and requires a fundamentally different mindset that semiconductor manufacturing. Human biology is much more complicated than manufacturing chips (and that is extremely complicated); drug discovery is about "unknown unknowns". Discovering a drug that has the intended effects without causing terrible adverse effects is something that some of the best-funded companies on the planet struggle with.
I've done some engineering and drug development...
Image trying to write code where you can't actually see what you wrote, where each time you compile it costs $1000 and the binary randomly is corrupted 50% of the time. And the only way to find out is to push it to prod and wait a few months for someone to call you. And every prod setup is subtly different without any documentation. That's about 100x easier than drug development.
Not in medicine, but I don't think that's true. It's very hard to understand what all the consequences are going to be when you manufacture those T cells, and you also have to figure out what to manufacture in the first place, based on experimental trial and error.
Drugs ultimately have to be converted from the lab to mass production. How is it any different, they all require research, iteration, and ultimately (hopefully) engineered mass production?
If there's one thing I learned with biomedical data modeling and machine learning, it's that "it's complicated". For biomedical scenarios, getting more data is often not simple at all. This is especially the case for rare diseases. For areas like drug discovery, getting a single new data point (for example, the effect of a drug candidate in human clinical settings) may require a huge expenditure of time and money. Biomedical results are often plagued with confounding variables, hidden and invisible, and simply adding in more data without detection and consideration of these bias sources can be disastrous. For example, measurements from lab #1 may show persistent errors not present in lab #2, and simply adding in more data blindly from lab #1 can make for worse models.
My conclusion is that you really need domain knowledge to know if you're fooling yourself with your great-looking modeling results. There's no simple statistical test to tell you if your data is acceptable or not.
One of the big differences between the US and Europe in this regard is the much larger proportion of bicyclists in Europe. In Europe, the larger number of bicyclists trains you as a driver to always be on the lookout for them. Driving past a bicyclist in the US is a much rarer event. Drivers should of course always be vigilant for anything in their way, but as a practical matter it's easier to mentally drift off when bicyclists are much less common.
With this kind of uncertainty, is it any wonder that many people don't trust medical science when we are told to behave in a certain way, or when we are told to take a certain medical treatment?
How many years have we been told that saturated fat is the nutritional devil? This is a great example of why censorship of "misinformation" is not justified- who is to say what constitutes misinformation?
There is PhD level math involved. And yet, ML (deep learning in particular) is much more of an empirical endeavor than many would like to admit. A deep understanding of the underlying mathematics does not necessarily give you a better model. Modern models are so complicated that no one can reason through them. Parameter spaces are non-convex and fully of ugly pathologies that make neat and tidy analysis methods useless.
From one perspective, it is disheartening that a deep understanding of the underlying methods doesn't necessarily win the day. From another, it is quite remarkable that having good implementation skills and a methodical mindset can get you quite far.
Calling YOLOv5 a "fraud" is a bit harsh. It has many excellent aspects for practitioners: easy to use, fast inference time, scalable model architecture, and it has many helpful utilities built-in for model deployment. In my experience, in real use-cases the models achieve about the same precision / recall / mAP as well as "state of the art" methods that report better stats on benchmarks.
You are free to quibble over how truly "open source" these models are, but I am very thankful that Meta has released them.