In the early days of high-per­for­mance com­put­ing, the ma­jor tech com­pa­nies of the day each in­vested heav­ily in de­vel­op­ing their own closed source ver­sions of Unix. It was hard to imag­ine at the time that any other ap­proach could de­velop such ad­vanced soft­ware. Eventually though, open source Linux gained pop­u­lar­ity — ini­tially be­cause it al­lowed de­vel­op­ers to mod­ify its code how­ever they wanted and was more af­ford­able, and over time be­cause it be­came more ad­vanced, more se­cure, and had a broader ecosys­tem sup­port­ing more ca­pa­bil­i­ties than any closed Unix. Today, Linux is the in­dus­try stan­dard foun­da­tion for both cloud com­put­ing and the op­er­at­ing sys­tems that run most mo­bile de­vices — and we all ben­e­fit from su­pe­rior prod­ucts be­cause of it.

I be­lieve that AI will de­velop in a sim­i­lar way. Today, sev­eral tech com­pa­nies are de­vel­op­ing lead­ing closed mod­els. But open source is quickly clos­ing the gap. Last year, Llama 2 was only com­pa­ra­ble to an older gen­er­a­tion of mod­els be­hind the fron­tier. This year, Llama 3 is com­pet­i­tive with the most ad­vanced mod­els and lead­ing in some ar­eas. Starting next year, we ex­pect fu­ture Llama mod­els to be­come the most ad­vanced in the in­dus­try. But even be­fore that, Llama is al­ready lead­ing on open­ness, mod­i­fi­a­bil­ity, and cost ef­fi­ciency.

Today we’re tak­ing the next steps to­wards open source AI be­com­ing the in­dus­try stan­dard. We’re re­leas­ing Llama 3.1 405B, the first fron­tier-level open source AI model, as well as new and im­proved Llama 3.1 70B and 8B mod­els. In ad­di­tion to hav­ing sig­nif­i­cantly bet­ter cost/​per­for­mance rel­a­tive to closed mod­els, the fact that the 405B model is open will make it the best choice for fine-tun­ing and dis­till­ing smaller mod­els.

Beyond re­leas­ing these mod­els, we’re work­ing with a range of com­pa­nies to grow the broader ecosys­tem. Amazon, Databricks, and NVIDIA are launch­ing full suites of ser­vices to sup­port de­vel­op­ers fine-tun­ing and dis­till­ing their own mod­els. Innovators like Groq have built low-la­tency, low-cost in­fer­ence serv­ing for all the new mod­els. The mod­els will be avail­able on all ma­jor clouds in­clud­ing AWS, Azure, Google, Oracle, and more. Companies like Scale. AI, Dell, Deloitte, and oth­ers are ready to help en­ter­prises adopt Llama and train cus­tom mod­els with their own data. As the com­mu­nity grows and more com­pa­nies de­velop new ser­vices, we can col­lec­tively make Llama the in­dus­try stan­dard and bring the ben­e­fits of AI to every­one.

Meta is com­mit­ted to open source AI. I’ll out­line why I be­lieve open source is the best de­vel­op­ment stack for you, why open sourc­ing Llama is good for Meta, and why open source AI is good for the world and there­fore a plat­form that will be around for the long term.

Why Open Source AI Is Good for Developers

When I talk to de­vel­op­ers, CEOs, and gov­ern­ment of­fi­cials across the world, I usu­ally hear sev­eral themes:

We need to train, fine-tune, and dis­till our own mod­els. Every or­ga­ni­za­tion has dif­fer­ent needs that are best met with mod­els of dif­fer­ent sizes that are trained or fine-tuned with their spe­cific data. On-device tasks and clas­si­fi­ca­tion tasks re­quire small mod­els, while more com­pli­cated tasks re­quire larger mod­els. Now you’ll be able to take the most ad­vanced Llama mod­els, con­tinue train­ing them with your own data and then dis­till them down to a model of your op­ti­mal size — with­out us or any­one else see­ing your data.

We need to con­trol our own des­tiny and not get locked into a closed ven­dor. Many or­ga­ni­za­tions don’t want to de­pend on mod­els they can­not run and con­trol them­selves. They don’t want closed model providers to be able to change their model, al­ter their terms of use, or even stop serv­ing them en­tirely. They also don’t want to get locked into a sin­gle cloud that has ex­clu­sive rights to a model. Open source en­ables a broad ecosys­tem of com­pa­nies with com­pat­i­ble tool­chains that you can move be­tween eas­ily.

We need to pro­tect our data. Many or­ga­ni­za­tions han­dle sen­si­tive data that they need to se­cure and can’t send to closed mod­els over cloud APIs. Other or­ga­ni­za­tions sim­ply don’t trust the closed model providers with their data. Open source ad­dresses these is­sues by en­abling you to run the mod­els wher­ever you want. It is well-ac­cepted that open source soft­ware tends to be more se­cure be­cause it is de­vel­oped more trans­par­ently.

We need a model that is ef­fi­cient and af­ford­able to run. Developers can run in­fer­ence on Llama 3.1 405B on their own in­fra at roughly 50% the cost of us­ing closed mod­els like GPT-4o, for both user-fac­ing and of­fline in­fer­ence tasks.

We want to in­vest in the ecosys­tem that’s go­ing to be the stan­dard for the long term. Lots of peo­ple see that open source is ad­vanc­ing at a faster rate than closed mod­els, and they want to build their sys­tems on the ar­chi­tec­ture that will give them the great­est ad­van­tage long term.

Why Open Source AI Is Good for Meta

Meta’s busi­ness model is about build­ing the best ex­pe­ri­ences and ser­vices for peo­ple. To do this, we must en­sure that we al­ways have ac­cess to the best tech­nol­ogy, and that we’re not lock­ing into a com­peti­tor’s closed ecosys­tem where they can re­strict what we build.

One of my for­ma­tive ex­pe­ri­ences has been build­ing our ser­vices con­strained by what Apple will let us build on their plat­forms. Between the way they tax de­vel­op­ers, the ar­bi­trary rules they ap­ply, and all the prod­uct in­no­va­tions they block from ship­ping, it’s clear that Meta and many other com­pa­nies would be freed up to build much bet­ter ser­vices for peo­ple if we could build the best ver­sions of our prod­ucts and com­peti­tors were not able to con­strain what we could build. On a philo­soph­i­cal level, this is a ma­jor rea­son why I be­lieve so strongly in build­ing open ecosys­tems in AI and AR/VR for the next gen­er­a­tion of com­put­ing.

People of­ten ask if I’m wor­ried about giv­ing up a tech­ni­cal ad­van­tage by open sourc­ing Llama, but I think this misses the big pic­ture for a few rea­sons:

First, to en­sure that we have ac­cess to the best tech­nol­ogy and aren’t locked into a closed ecosys­tem over the long term, Llama needs to de­velop into a full ecosys­tem of tools, ef­fi­ciency im­prove­ments, sil­i­con op­ti­miza­tions, and other in­te­gra­tions. If we were the only com­pany us­ing Llama, this ecosys­tem would­n’t de­velop and we’d fare no bet­ter than the closed vari­ants of Unix.

Second, I ex­pect AI de­vel­op­ment will con­tinue to be very com­pet­i­tive, which means that open sourc­ing any given model is­n’t giv­ing away a mas­sive ad­van­tage over the next best mod­els at that point in time. The path for Llama to be­come the in­dus­try stan­dard is by be­ing con­sis­tently com­pet­i­tive, ef­fi­cient, and open gen­er­a­tion af­ter gen­er­a­tion.

Third, a key dif­fer­ence be­tween Meta and closed model providers is that sell­ing ac­cess to AI mod­els is­n’t our busi­ness model. That means openly re­leas­ing Llama does­n’t un­der­cut our rev­enue, sus­tain­abil­ity, or abil­ity to in­vest in re­search like it does for closed providers. (This is one rea­son sev­eral closed providers con­sis­tently lobby gov­ern­ments against open source.)

Finally, Meta has a long his­tory of open source pro­jects and suc­cesses. We’ve saved bil­lions of dol­lars by re­leas­ing our server, net­work, and data cen­ter de­signs with Open Compute Project and hav­ing sup­ply chains stan­dard­ize on our de­signs. We ben­e­fited from the ecosys­tem’s in­no­va­tions by open sourc­ing lead­ing tools like PyTorch, React, and many more tools. This ap­proach has con­sis­tently worked for us when we stick with it over the long term.

Why Open Source AI Is Good for the World

I be­lieve that open source is nec­es­sary for a pos­i­tive AI fu­ture. AI has more po­ten­tial than any other mod­ern tech­nol­ogy to in­crease hu­man pro­duc­tiv­ity, cre­ativ­ity, and qual­ity of life — and to ac­cel­er­ate eco­nomic growth while un­lock­ing progress in med­ical and sci­en­tific re­search. Open source will en­sure that more peo­ple around the world have ac­cess to the ben­e­fits and op­por­tu­ni­ties of AI, that power is­n’t con­cen­trated in the hands of a small num­ber of com­pa­nies, and that the tech­nol­ogy can be de­ployed more evenly and safely across so­ci­ety.

There is an on­go­ing de­bate about the safety of open source AI mod­els, and my view is that open source AI will be safer than the al­ter­na­tives. I think gov­ern­ments will con­clude it’s in their in­ter­est to sup­port open source be­cause it will make the world more pros­per­ous and safer.

My frame­work for un­der­stand­ing safety is that we need to pro­tect against two cat­e­gories of harm: un­in­ten­tional and in­ten­tional. Unintentional harm is when an AI sys­tem may cause harm even when it was not the in­tent of those run­ning it to do so. For ex­am­ple, mod­ern AI mod­els may in­ad­ver­tently give bad health ad­vice. Or, in more fu­tur­is­tic sce­nar­ios, some worry that mod­els may un­in­ten­tion­ally self-repli­cate or hy­per-op­ti­mize goals to the detri­ment of hu­man­ity. Intentional harm is when a bad ac­tor uses an AI model with the goal of caus­ing harm.

It’s worth not­ing that un­in­ten­tional harm cov­ers the ma­jor­ity of con­cerns peo­ple have around AI — rang­ing from what in­flu­ence AI sys­tems will have on the bil­lions of peo­ple who will use them to most of the truly cat­a­strophic sci­ence fic­tion sce­nar­ios for hu­man­ity. On this front, open source should be sig­nif­i­cantly safer since the sys­tems are more trans­par­ent and can be widely scru­ti­nized. Historically, open source soft­ware has been more se­cure for this rea­son. Similarly, us­ing Llama with its safety sys­tems like Llama Guard will likely be safer and more se­cure than closed mod­els. For this rea­son, most con­ver­sa­tions around open source AI safety fo­cus on in­ten­tional harm.

Our safety process in­cludes rig­or­ous test­ing and red-team­ing to as­sess whether our mod­els are ca­pa­ble of mean­ing­ful harm, with the goal of mit­i­gat­ing risks be­fore re­lease. Since the mod­els are open, any­one is ca­pa­ble of test­ing for them­selves as well. We must keep in mind that these mod­els are trained by in­for­ma­tion that’s al­ready on the in­ter­net, so the start­ing point when con­sid­er­ing harm should be whether a model can fa­cil­i­tate more harm than in­for­ma­tion that can quickly be re­trieved from Google or other search re­sults.

When rea­son­ing about in­ten­tional harm, it’s help­ful to dis­tin­guish be­tween what in­di­vid­ual or small scale ac­tors may be able to do as op­posed to what large scale ac­tors like na­tion states with vast re­sources may be able to do.

At some point in the fu­ture, in­di­vid­ual bad ac­tors may be able to use the in­tel­li­gence of AI mod­els to fab­ri­cate en­tirely new harms from the in­for­ma­tion avail­able on the in­ter­net. At this point, the bal­ance of power will be crit­i­cal to AI safety. I think it will be bet­ter to live in a world where AI is widely de­ployed so that larger ac­tors can check the power of smaller bad ac­tors. This is how we’ve man­aged se­cu­rity on our so­cial net­works — our more ro­bust AI sys­tems iden­tify and stop threats from less so­phis­ti­cated ac­tors who of­ten use smaller scale AI sys­tems. More broadly, larger in­sti­tu­tions de­ploy­ing AI at scale will pro­mote se­cu­rity and sta­bil­ity across so­ci­ety. As long as every­one has ac­cess to sim­i­lar gen­er­a­tions of mod­els — which open source pro­motes — then gov­ern­ments and in­sti­tu­tions with more com­pute re­sources will be able to check bad ac­tors with less com­pute.

The next ques­tion is how the US and de­mo­c­ra­tic na­tions should han­dle the threat of states with mas­sive re­sources like China. The United States’ ad­van­tage is de­cen­tral­ized and open in­no­va­tion. Some peo­ple ar­gue that we must close our mod­els to pre­vent China from gain­ing ac­cess to them, but my view is that this will not work and will only dis­ad­van­tage the US and its al­lies. Our ad­ver­saries are great at es­pi­onage, steal­ing mod­els that fit on a thumb drive is rel­a­tively easy, and most tech com­pa­nies are far from op­er­at­ing in a way that would make this more dif­fi­cult. It seems most likely that a world of only closed mod­els re­sults in a small num­ber of big com­pa­nies plus our geopo­lit­i­cal ad­ver­saries hav­ing ac­cess to lead­ing mod­els, while star­tups, uni­ver­si­ties, and small busi­nesses miss out on op­por­tu­ni­ties. Plus, con­strain­ing American in­no­va­tion to closed de­vel­op­ment in­creases the chance that we don’t lead at all. Instead, I think our best strat­egy is to build a ro­bust open ecosys­tem and have our lead­ing com­pa­nies work closely with our gov­ern­ment and al­lies to en­sure they can best take ad­van­tage of the lat­est ad­vances and achieve a sus­tain­able first-mover ad­van­tage over the long term.

When you con­sider the op­por­tu­ni­ties ahead, re­mem­ber that most of to­day’s lead­ing tech com­pa­nies and sci­en­tific re­search are built on open source soft­ware. The next gen­er­a­tion of com­pa­nies and re­search will use open source AI if we col­lec­tively in­vest in it. That in­cludes star­tups just get­ting off the ground as well as peo­ple in uni­ver­si­ties and coun­tries that may not have the re­sources to de­velop their own state-of-the-art AI from scratch.

The bot­tom line is that open source AI rep­re­sents the world’s best shot at har­ness­ing this tech­nol­ogy to cre­ate the great­est eco­nomic op­por­tu­nity and se­cu­rity for every­one.

With past Llama mod­els, Meta de­vel­oped them for our­selves and then re­leased them, but did­n’t fo­cus much on build­ing a broader ecosys­tem. We’re tak­ing a dif­fer­ent ap­proach with this re­lease. We’re build­ing teams in­ter­nally to en­able as many de­vel­op­ers and part­ners as pos­si­ble to use Llama, and we’re ac­tively build­ing part­ner­ships so that more com­pa­nies in the ecosys­tem can of­fer unique func­tion­al­ity to their cus­tomers as well.

I be­lieve the Llama 3.1 re­lease will be an in­flec­tion point in the in­dus­try where most de­vel­op­ers be­gin to pri­mar­ily use open source, and I ex­pect that ap­proach to only grow from here. I hope you’ll join us on this jour­ney to bring the ben­e­fits of AI to every­one in the world.

You can ac­cess the mod­els now at llama.meta.com.

Meta AI Is Now Multilingual, More Creative and Smarter

We’re ex­pand­ing ac­cess to Meta AI, adding new cre­ative tools and giv­ing you the op­tion to use our most ad­vanced open-source model in­side Meta AI for tough math and cod­ing ques­tions.

Meta AI Is Now Multilingual, More Creative and Smarter

To help per­son­al­ize con­tent, tai­lor and mea­sure ads, and pro­vide a safer ex­pe­ri­ence, we use cook­ies. By click­ing or nav­i­gat­ing the site, you agree to al­low our col­lec­tion of in­for­ma­tion on and off Facebook through cook­ies. Learn more, in­clud­ing about avail­able con­trols: Cookie Policy

You can ac­cess data from deleted forks, deleted repos­i­to­ries and even pri­vate repos­i­to­ries on GitHub. And it is avail­able for­ever. This is known by GitHub, and in­ten­tion­ally de­signed that way.

This is such an enor­mous at­tack vec­tor for all or­ga­ni­za­tions that use GitHub that we’re in­tro­duc­ing a new term: Cross Fork Object Reference (CFOR). A CFOR vul­ner­a­bil­ity oc­curs when one repos­i­tory fork can ac­cess sen­si­tive data from an­other fork (including data from pri­vate and deleted forks). Similar to an Insecure Direct Object Reference, in CFOR users sup­ply com­mit hashes to di­rectly ac­cess com­mit data that oth­er­wise would not be vis­i­ble to them.

Consider this com­mon work­flow on GitHub:

You com­mit code to your fork

Is the code you com­mit­ted to the fork still ac­ces­si­ble? It should­n’t be, right? You deleted it.

It is. And it’s ac­ces­si­ble for­ever. Out of your con­trol.

In the video be­low, you’ll see us fork a repos­i­tory, com­mit data to it, delete the fork, and then ac­cess the “deleted” com­mit data via the orig­i­nal repos­i­tory.

You might think you’re pro­tected by need­ing to know the com­mit hash. You’re not. The hash is dis­cov­er­able. More on that later.

Pretty of­ten. We sur­veyed a few (literally 3) com­monly-forked pub­lic repos­i­to­ries from a large AI com­pany and eas­ily found 40 valid API keys from deleted forks. The user pat­tern seemed to be this:

Hard-code an API key into an ex­am­ple file.

But this gets worse, it works in re­verse too:

You have a pub­lic repo on GitHub. You com­mit data af­ter they fork it (and they never sync their fork with your up­dates).

Is the code you com­mit­ted af­ter they forked your repo still ac­ces­si­ble?

GitHub stores repos­i­to­ries and forks in a repos­i­tory net­work, with the orig­i­nal “upstream” repos­i­tory act­ing as the root node. When a pub­lic “upstream” repos­i­tory that has been forked is “deleted”, GitHub re­as­signs the root node role to one of the down­stream forks. However, all of the com­mits from the “upstream” repos­i­tory still ex­ist and are ac­ces­si­ble via any fork.

In the video be­low, we cre­ate a repo, fork it and then show how data not synced with the fork can still be ac­cessed by the fork af­ter the orig­i­nal repo is deleted.

This is­n’t just some weird edge case sce­nario. This un­folded last week:

I sub­mit­ted a P1 vul­ner­a­bil­ity to a ma­jor tech com­pany show­ing they ac­ci­den­tally com­mit­ted a pri­vate key for an em­ploy­ee’s GitHub ac­count that had sig­nif­i­cant ac­cess to their en­tire GitHub or­ga­ni­za­tion. They im­me­di­ately deleted the repos­i­tory, but since it had been forked, I could still ac­cess the com­mit con­tain­ing the sen­si­tive data via a fork, de­spite the fork never sync­ing with the orig­i­nal “upstream” repos­i­tory.

The im­pli­ca­tion here is that any code com­mit­ted to a pub­lic repos­i­tory may be ac­ces­si­ble for­ever as long as there is at least one fork of that repos­i­tory.

Consider this com­mon work­flow for open-sourc­ing a new tool on GitHub:

You cre­ate a pri­vate repo that will even­tu­ally be made pub­lic. You cre­ate a pri­vate, in­ter­nal ver­sion of that repo (via fork­ing) and com­mit ad­di­tional code for fea­tures that you’re not go­ing to make pub­lic.You make your “upstream” repos­i­tory pub­lic and keep your fork pri­vate.

Are your pri­vate fea­tures and re­lated code (from step 2) view­able by the pub­lic?

Yes. Any code com­mit­ted be­tween the time you cre­ated an in­ter­nal fork of your tool and when you open-sourced the tool, those com­mits are ac­ces­si­ble on the pub­lic repos­i­tory.

Any com­mits made to your pri­vate fork af­ter you make the “upstream” repos­i­tory pub­lic are not view­able. That’s be­cause chang­ing the vis­i­bil­ity of a pri­vate “upstream” repos­i­tory re­sults in two repos­i­tory net­works - one for the pri­vate ver­sion, and one for the pub­lic ver­sion.

In the video be­low, we demon­strate how or­ga­ni­za­tions open-source new tools while main­tain­ing pri­vate in­ter­nal forks, and then show how some­one could ac­cess com­mit data from the pri­vate in­ter­nal ver­sion via the pub­lic one.

Unfortunately, this work­flow is one of the most com­mon ap­proaches users and or­ga­ni­za­tions take to de­vel­op­ing open-source soft­ware. As a re­sult, it’s pos­si­ble that con­fi­den­tial data and se­crets are in­ad­ver­tently be­ing ex­posed on an or­ga­ni­za­tion’s pub­lic GitHub repos­i­to­ries.

Destructive ac­tions in GitHub’s repos­i­tory net­work (like the 3 sce­nar­ios men­tioned above) re­move ref­er­ences to com­mit data from the stan­dard GitHub UI and nor­mal git op­er­a­tions. However, this data still ex­ists and is ac­ces­si­ble (if you know the com­mit hash). This is the tie-in be­tween CFOR and IDOR vul­ner­a­bil­i­ties - if you know the com­mit hash you can di­rectly ac­cess data that is not in­tended for you.

If a user knows the SHA-1 com­mit hash of a par­tic­u­lar com­mit they want to see, they can di­rectly nav­i­gate to that com­mit at the end­point: https://​github.com/. They’ll see a yel­low ban­ner ex­plain­ing that “[t]his com­mit does not be­long to any branch of this repos­i­tory, and may be­long to a fork out­side of the repos­i­tory.”

Where do you get these hash val­ues?

Commit hashes can be brute forced through GitHub’s UI, par­tic­u­larly be­cause the git pro­to­col per­mits the use of short SHA-1 val­ues when ref­er­enc­ing a com­mit. A short SHA-1 value is the min­i­mum num­ber of char­ac­ters re­quired to avoid a col­li­sion with an­other com­mit hash, with an ab­solute min­i­mum of 4. The key­space of all 4 char­ac­ter SHA-1 val­ues is 65,536 (16^4). Brute forc­ing all pos­si­ble val­ues can be achieved rel­a­tively eas­ily.

For ex­am­ple, con­sider this com­mit in TruffleHog’s repos­i­tory:

To ac­cess this com­mit, users typ­i­cally visit the URL con­tain­ing the full SHA-1 com­mit hash: https://​github.com/​truf­flese­cu­rity/​truf­fle­hog/​com­mit/​07f01e8337c1073d2c45b­b12d688170fcd44c637

But users don’t need to know the en­tire 32 char­ac­ter SHA-1 value, they only need to cor­rectly guess the Short SHA-1 value, which in this case is 07f01e.

But what’s more in­ter­est­ing; GitHub ex­poses a pub­lic events API end­point. You can also query for com­mit hashes in the events archive which is man­aged by a 3rd party, and saves all GitHub events for the past decade out­side of GitHub, even af­ter the re­pos get deleted.

We re­cently sub­mit­ted our find­ings to GitHub via their VDP pro­gram. This was their re­sponse:

After re­view­ing the doc­u­men­ta­tion, it’s clear as day that GitHub de­signed repos­i­to­ries to work like this.

We ap­pre­ci­ate that GitHub is trans­par­ent about their ar­chi­tec­ture and has taken the time to clearly doc­u­ment what users should ex­pect to hap­pen in the in­stances doc­u­mented above.

Our is­sue is this:

The av­er­age user views the sep­a­ra­tion of pri­vate and pub­lic repos­i­to­ries as a se­cu­rity bound­ary, and un­der­stand­ably be­lieves that any data lo­cated in a pri­vate repos­i­tory can­not be ac­cessed by pub­lic users. Unfortunately, as we doc­u­mented above, that is not al­ways true. Whatsmore, the act of dele­tion im­plies the de­struc­tion of data. As we saw above, delet­ing a repos­i­tory or fork does not mean your com­mit data is ac­tu­ally deleted.

We have a few take­aways from this:

As long as one fork ex­ists, any com­mit to that repos­i­tory net­work (ie: com­mits on the “upstream” repo or “downstream” forks) will ex­ist for­ever. This fur­ther ce­ments our view that the only way to se­curely re­me­di­ate a leaked key on a pub­lic GitHub repos­i­tory is through key ro­ta­tion. We’ve spent a lot of time doc­u­ment­ing how to ro­tate keys for the most pop­u­larly leaked se­cret types - check our work out here: how­toro­tate.com.

GitHub’s repos­i­tory ar­chi­tec­ture ne­ces­si­tates these de­sign flaws and un­for­tu­nately, the vast ma­jor­ity of GitHub users will never un­der­stand how a repos­i­tory net­work ac­tu­ally works and will be less se­cure be­cause of it.

As se­cret scan­ning evolves, and we can hope­fully scan all com­mits in a repos­i­tory net­work, we’ll be alert­ing on se­crets that might not be our own (ie: they might be­long to some­one who forked a repos­i­tory). This will re­quire more dili­gent triag­ing. While these three sce­nar­ios are shock­ing, that does­n’t even cover all of the ways GitHub could be stor­ing deleted data from your repos­i­to­ries. Check out our re­cent post (and re­lated TruffleHog up­date) about how you also need to scan for se­crets in deleted branches.

Finally, while our re­search fo­cused on GitHub, it’s im­por­tant to note that some of these is­sues ex­ist on other ver­sion con­trol sys­tem prod­ucts.

Artificial gen­eral in­tel­li­gence (AGI) with ad­vanced math­e­mat­i­cal rea­son­ing has the po­ten­tial to un­lock new fron­tiers in sci­ence and tech­nol­ogy.

We’ve made great progress build­ing AI sys­tems that help math­e­mati­cians dis­cover new in­sights, novel al­go­rithms and an­swers to open prob­lems. But cur­rent AI sys­tems still strug­gle with solv­ing gen­eral math prob­lems be­cause of lim­i­ta­tions in rea­son­ing skills and train­ing data.

Today, we pre­sent AlphaProof, a new re­in­force­ment-learn­ing based sys­tem for for­mal math rea­son­ing, and AlphaGeometry 2, an im­proved ver­sion of our geom­e­try-solv­ing sys­tem. Together, these sys­tems solved four out of six prob­lems from this year’s International Mathematical Olympiad (IMO), achiev­ing the same level as a sil­ver medal­ist in the com­pe­ti­tion for the first time.

The IMO is the old­est, largest and most pres­ti­gious com­pe­ti­tion for young math­e­mati­cians, held an­nu­ally since 1959.

Each year, elite pre-col­lege math­e­mati­cians train, some­times for thou­sands of hours, to solve six ex­cep­tion­ally dif­fi­cult prob­lems in al­ge­bra, com­bi­na­torics, geom­e­try and num­ber the­ory. Many of the win­ners of the Fields Medal, one of the high­est hon­ors for math­e­mati­cians, have rep­re­sented their coun­try at the IMO.

More re­cently, the an­nual IMO com­pe­ti­tion has also be­come widely recog­nised as a grand chal­lenge in ma­chine learn­ing and an as­pi­ra­tional bench­mark for mea­sur­ing an AI sys­tem’s ad­vanced math­e­mat­i­cal rea­son­ing ca­pa­bil­i­ties.

This year, we ap­plied our com­bined AI sys­tem to the com­pe­ti­tion prob­lems, pro­vided by the IMO or­ga­niz­ers. Our so­lu­tions were scored ac­cord­ing to the IMO’s point-award­ing rules by promi­nent math­e­mati­cians Prof Sir Timothy Gowers, an IMO gold medal­ist and Fields Medal win­ner, and Dr Joseph Myers, a two-time IMO gold medal­ist and Chair of the IMO 2024 Problem Selection Committee.

The fact that the pro­gram can come up with a non-ob­vi­ous con­struc­tion like this is very im­pres­sive, and well be­yond what I thought was state of the art.

First, the prob­lems were man­u­ally trans­lated into for­mal math­e­mat­i­cal lan­guage for our sys­tems to un­der­stand. In the of­fi­cial com­pe­ti­tion, stu­dents sub­mit an­swers in two ses­sions of 4.5 hours each. Our sys­tems solved one prob­lem within min­utes and took up to three days to solve the oth­ers.

AlphaProof solved two al­ge­bra prob­lems and one num­ber the­ory prob­lem by de­ter­min­ing the an­swer and prov­ing it was cor­rect. This in­cluded the hard­est prob­lem in the com­pe­ti­tion, solved by only five con­tes­tants at this year’s IMO. AlphaGeometry 2 proved the geom­e­try prob­lem, while the two com­bi­na­torics prob­lems re­mained un­solved.

Each of the six prob­lems can earn seven points, with a to­tal max­i­mum of 42. Our sys­tem achieved a fi­nal score of 28 points, earn­ing a per­fect score on each prob­lem solved — equiv­a­lent to the top end of the sil­ver-medal cat­e­gory. This year, the gold-medal thresh­old starts at 29 points, and was achieved by 58 of 609 con­tes­tants at the of­fi­cial com­pe­ti­tion.

Graph show­ing per­for­mance of our AI sys­tem rel­a­tive to hu­man com­peti­tors at IMO 2024. We earned 28 out of 42 to­tal points, achiev­ing the same level as a sil­ver medal­ist in the com­pe­ti­tion.

AlphaProof is a sys­tem that trains it­self to prove math­e­mat­i­cal state­ments in the for­mal lan­guage Lean. It cou­ples a pre-trained lan­guage model with the AlphaZero re­in­force­ment learn­ing al­go­rithm, which pre­vi­ously taught it­self how to mas­ter the games of chess, shogi and Go.

Formal lan­guages of­fer the crit­i­cal ad­van­tage that proofs in­volv­ing math­e­mat­i­cal rea­son­ing can be for­mally ver­i­fied for cor­rect­ness. Their use in ma­chine learn­ing has, how­ever, pre­vi­ously been con­strained by the very lim­ited amount of hu­man-writ­ten data avail­able.

In con­trast, nat­ural lan­guage based ap­proaches can hal­lu­ci­nate plau­si­ble but in­cor­rect in­ter­me­di­ate rea­son­ing steps and so­lu­tions, de­spite hav­ing ac­cess to or­ders of mag­ni­tudes more data. We es­tab­lished a bridge be­tween these two com­ple­men­tary spheres by fine-tun­ing a Gemini model to au­to­mat­i­cally trans­late nat­ural lan­guage prob­lem state­ments into for­mal state­ments, cre­at­ing a large li­brary of for­mal prob­lems of vary­ing dif­fi­culty.

When pre­sented with a prob­lem, AlphaProof gen­er­ates so­lu­tion can­di­dates and then proves or dis­proves them by search­ing over pos­si­ble proof steps in Lean. Each proof that was found and ver­i­fied is used to re­in­force AlphaProof’s lan­guage model, en­hanc­ing its abil­ity to solve sub­se­quent, more chal­leng­ing prob­lems.

We trained AlphaProof for the IMO by prov­ing or dis­prov­ing mil­lions of prob­lems, cov­er­ing a wide range of dif­fi­cul­ties and math­e­mat­i­cal topic ar­eas over a pe­riod of weeks lead­ing up to the com­pe­ti­tion. The train­ing loop was also ap­plied dur­ing the con­test, re­in­forc­ing proofs of self-gen­er­ated vari­a­tions of the con­test prob­lems un­til a full so­lu­tion could be found.

Process in­fo­graphic of AlphaProof’s re­in­force­ment learn­ing train­ing loop: Around one mil­lion in­for­mal math prob­lems are trans­lated into a for­mal math lan­guage by a for­mal­izer net­work. Then a solver net­work searches for proofs or dis­proofs of the prob­lems, pro­gres­sively train­ing it­self via the AlphaZero al­go­rithm to solve more chal­leng­ing prob­lems.

AlphaGeometry 2 is a sig­nif­i­cantly im­proved ver­sion of AlphaGeometry. It’s a neuro-sym­bolic hy­brid sys­tem in which the lan­guage model was based on Gemini and trained from scratch on an or­der of mag­ni­tude more syn­thetic data than its pre­de­ces­sor. This helped the model tackle much more chal­leng­ing geom­e­try prob­lems, in­clud­ing prob­lems about move­ments of ob­jects and equa­tions of an­gles, ra­tio or dis­tances.

AlphaGeometry 2 em­ploys a sym­bolic en­gine that is two or­ders of mag­ni­tude faster than its pre­de­ces­sor. When pre­sented with a new prob­lem, a novel knowl­edge-shar­ing mech­a­nism is used to en­able ad­vanced com­bi­na­tions of dif­fer­ent search trees to tackle more com­plex prob­lems.

Before this year’s com­pe­ti­tion, AlphaGeometry 2 could solve 83% of all his­tor­i­cal IMO geom­e­try prob­lems from the past 25 years, com­pared to the 53% rate achieved by its pre­de­ces­sor. For IMO 2024, AlphaGeometry 2 solved Problem 4 within 19 sec­onds af­ter re­ceiv­ing its for­mal­iza­tion.

Illustration of Problem 4, which asks to prove the sum of ∠KIL and ∠XPY equals 180°. AlphaGeometry 2 pro­posed to con­struct E, a point on the line BI so that ∠AEB = 90°. Point E helps give pur­pose to the mid­point L of AB, cre­at­ing many pairs of sim­i­lar tri­an­gles such as ABE ~ YBI and ALE ~ IPC needed to prove the con­clu­sion.

As part of our IMO work, we also ex­per­i­mented with a nat­ural lan­guage rea­son­ing sys­tem, built upon Gemini and our lat­est re­search to en­able ad­vanced prob­lem-solv­ing skills. This sys­tem does­n’t re­quire the prob­lems to be trans­lated into a for­mal lan­guage and could be com­bined with other AI sys­tems. We also tested this ap­proach on this year’s IMO prob­lems and the re­sults showed great promise.

Our teams are con­tin­u­ing to ex­plore mul­ti­ple AI ap­proaches for ad­vanc­ing math­e­mat­i­cal rea­son­ing and plan to re­lease more tech­ni­cal de­tails on AlphaProof soon.

We’re ex­cited for a fu­ture in which math­e­mati­cians work with AI tools to ex­plore hy­pothe­ses, try bold new ap­proaches to solv­ing long-stand­ing prob­lems and quickly com­plete time-con­sum­ing el­e­ments of proofs — and where AI sys­tems like Gemini be­come more ca­pa­ble at math and broader rea­son­ing.

We thank the International Mathematical Olympiad or­ga­ni­za­tion for their sup­port. AlphaProof de­vel­op­ment was led by Thomas Hubert, Rishi Mehta and Laurent Sartran; AlphaGeometry 2 and nat­ural lan­guage rea­son­ing ef­forts were led by Thang Luong.AlphaProof was de­vel­oped with key con­tri­bu­tions from Hussain Masoom, Aja Huang, Miklós Z. Horváth, Tom Zahavy, Vivek Veeriah, Eric Wieser, Jessica Yung, Lei Yu, Yannick Schroecker, Julian Schrittwieser, Ottavia Bertolli, Borja Ibarz, Edward Lockhart, Edward Hughes, Mark Rowland, Grace Margand. Alex Davies and Daniel Zheng led the de­vel­op­ment of in­for­mal sys­tems such as fi­nal an­swer de­ter­mi­na­tion, with key con­tri­bu­tions from Iuliya Beloshapka, Ingrid von Glehn, Yin Li, Fabian Pedregosa, Ameya Velingker and Goran Žužić. Oliver Nash, Bhavik Mehta, Paul Lezeau, Salvatore Mercuri, Lawrence Wu, Calle Soenne, Thomas Murrills, Luigi Massacci and Andrew Yang ad­vised and con­tributed as Lean ex­perts. Past con­trib­u­tors in­clude Amol Mandhane, Tom Eccles, Eser Aygün, Zhitao Gong, Richard Evans, Soňa Mokrá, Amin Barekatain, Wendy Shang, Hannah Openshaw, Felix Gimeno. This work was ad­vised by David Silver and Pushmeet Kohli.The de­vel­op­ment of AlphaGeometry 2 was led by Trieu Trinh and Yuri Chervonyi, with key con­tri­bu­tions by Mirek Olšák, Xiaomeng Yang, Hoang Nguyen, Junehyuk Jung, Dawsen Hwang and Marcelo Menegali. The de­vel­op­ment of the nat­ural lan­guage rea­son­ing sys­tem was led by Golnaz Ghiasi, Garrett Bingham, YaGuang Li, with key con­tri­bu­tions by Swaroop Mishra, Nigamaa Nayakanti, Sidharth Mudgal, Qijun Tan, Junehyuk Jung, Hoang Nguyen, Alex Zhai, Dawsen Hwang, Mingyang Deng, Clara Huiyi Hu, Jarrod Kahn, Maciej Kula, Cosmo Du. Both AlphaGeometry and nat­ural lan­guage rea­son­ing sys­tems were ad­vised by Quoc Le.David Silver, Quoc Le, Demis Hassabis, and Pushmeet Kohli co­or­di­nated and man­aged the over­all pro­ject.We’d also like to thank Insuk Seo, Evan Chen, Zigmars Rasscevskis, Kari Ragnarsson, Junhwi Bae, Jeonghyun Ahn, Jimin Kim, Hung Pham, Nguyen Nguyen, Son Pham, and Pasin Manurangsi who helped eval­u­ate the qual­ity of our lan­guage rea­son­ing sys­tem. Jeff Stanway, Jessica Lo, Erica Moreira and Kareem Ayoub for their sup­port for com­pute pro­vi­sion and man­age­ment. Prof Gregor Dolinar and Dr Geoff Smith MBE from the IMO Board, for the sup­port and col­lab­o­ra­tion; and Tu Vu, Hanzhao Lin, Chenkai Kuang, Vikas Verma, Yifeng Lu, Vihan Jain, Henryk Michalewski, Xavier Garcia, Arjun Kar, Lampros Lamprou, Kaushal Patel, Ilya Tolstikhen, Olivier Bousquet, Anton Tsitsulin, Dustin Zelle, CJ Carey, Sam Blackwell, Abhi Rao, Vahab Mirrokni, Behnam Neyshabur, Ethan Dyer, Keith Rush, Moritz Firsching, Dan Shved, Ihar Bury, Divyanshu Ranjan, Hadi Hashemi, Alexei Bendebury, Soheil Hassas Yeganeh, Shibl Mourad, Simon Schmitt, Satinder Baveja, Chris Dyer, Jacob Austin, Wenda Li, Heng-tze Cheng, Ed Chi, Koray Kavukcuoglu, Oriol Vinyals, Jeff Dean and Sergey Brin for their sup­port and ad­vice.Fi­nally, we’d like to thank the many con­trib­u­tors to the Lean and Mathlib pro­jects, with­out whom AlphaProof would­n’t have been pos­si­ble.

We’re in­tro­duc­ing a se­ries of up­dates across the Gemini fam­ily of mod­els, in­clud­ing the new 1.5 Flash, our light­weight model for speed and ef­fi­ciency, and Project Astra, our vi­sion for the fu­ture…

The model de­liv­ers dra­mat­i­cally en­hanced per­for­mance, with a break­through in long-con­text un­der­stand­ing across modal­i­ties.

Introducing Gemini: our largest and most ca­pa­ble AI model

Making AI more help­ful for every­one

AlphaZero: Shedding new light on chess, shogi, and Go

In late 2017 we in­tro­duced AlphaZero, a sin­gle sys­tem that taught it­self from scratch how to mas­ter the games of chess, shogi (Japanese chess), and Go, beat­ing a world-cham­pion pro­gram in each…

Powerful, gen­eral AI sys­tems that mas­tered a range of board games and video games — and are now help­ing us solve real-world prob­lems.

Solving novel prob­lems and set­ting a new mile­stone in com­pet­i­tive pro­gram­ming.

Novel AI sys­tem mas­tered the an­cient game of Go, de­feated a Go world cham­pion, and in­spired a new era of AI.

Have a ques­tion about this pro­ject? Sign up for a free GitHub ac­count to open an is­sue and con­tact its main­tain­ers and the com­mu­nity.

By click­ing “Sign up for GitHub”, you agree to our terms of ser­vice and pri­vacy state­ment. We’ll oc­ca­sion­ally send you ac­count re­lated emails.

Already on GitHub? Sign in

to your ac­count

There are 47 mil­lion­aires work­ing for Central States Manufacturing, and they’re not all in the C-Suite. Many of them are dri­vers or ma­chin­ists—blue-col­lar work­ers for the com­pany.

How? The com­pany is owned by its em­ploy­ees. Every worker gets a salary but also a per­cent­age of their salary in stock own­er­ship. When the com­pany does well, so do the em­ploy­ees—all of them, not just the ones at the top.

And the com­pany is do­ing well. “When we sat down eight years ago, we said we want to be a bil­lion-dol­lar com­pany and have 1,500 peo­ple, we are on track to be both of those this year,” Tim Ruger, pres­i­dent of Central States, tells me.

That’s right, this man­u­fac­tur­ing com­pany will be­come a uni­corn this year—one of only 6,000 com­pa­nies in the world earn­ing more than $1 bil­lion in rev­enue. But un­like Walmart, Amazon, and Apple, it’s not just the ex­ec­u­tives get­ting paid out.

“It’s not like 80 per­cent of the com­pany is owned by man­age­ment and the rest is owned by em­ploy­ees, it’s re­ally well spread across all func­tions,”  Ruger tells me. “We’ve got a num­ber of peo­ple that have been here 15, 20 years and they have $1 mil­lion plus bal­ances, which is re­ally cool for a per­son that came out of high school and runs our roll­former. You can’t do that every­where.”

He’s right, and be­cause you can’t do that every­where there is a huge wealth dis­par­ity in America. Even though the econ­omy has been on an up­ward tra­jec­tory for a cen­tury, the wealth it gen­er­ates has fun­neled to a much smaller pop­u­la­tion who owns it. After a 1990s bill meant ex­ec­u­tives started get­ting paid in stock op­tions while the rest of their em­ploy­ees earned a sta­tic salary, ex­ec­u­tive pay sky­rock­eted with the mar­ket while their work­ers’ pay stag­nated.

If em­ploy­ees had also owned part of the com­pany, their pay would have sky­rock­eted with the mar­ket too, but they did­n’t. “It’s hard to build true wealth for your­self if you don’t have some type of own­er­ship in some­thing, and it’s hard for most peo­ple to get own­er­ship in some­thing,” Ruger says.

Upping the min­i­mum wage won’t fix that. As Nathan Schneider says in his book Everything for Everyone: “One way or an­other, wealth is go­ing to the own­ers—of where we live, where we work, and what we con­sume.”

So why not make work­ers the own­ers?

There is a grow­ing move­ment to do just that. Central States is one of 6,533 com­pa­nies that have formed an Employee Stock Ownership Plan (or ESOP) in the United States, and that num­ber is grow­ing by about 250 com­pa­nies an­nu­ally. That’s 14.7 mil­lion em­ploy­ees who have own­er­ship in com­pa­nies worth, col­lec­tively, $2.1 tril­lion.

Every year, those em­ploy­ees get a per­cent­age of their salaries in com­pany stock. During Central States’ worst year, em­ploy­ees earned the equiv­a­lent of 6 per­cent of their pay in stock, dur­ing their best they earned 26 per­cent. Last year, an em­ployee earn­ing $100,000 a year re­ceived $26,000 worth of stock in their ac­count. As the com­pany has grown, the value of that stock has av­er­aged 20 per­cent re­turns an­nu­ally, out­per­form­ing the stock mar­ket.

Just like Jeff Bezos can sell a por­tion of his Amazon stock to buy a new house, em­ploy­ees at ESOPs can pull money out of their stock ac­counts to pay for tu­ition, med­ical bills, or as a down­pay­ment on a pri­mary res­i­dence.

“We have sev­eral in pro­duc­tion and dri­vers who have been here for over 20 years that have multi-mil­lion dol­lar ac­counts,” Chad Ware, Central States’ CFO tells me. “We’ve had sev­eral folks take out enough money to buy a home out­right.”

An ESOP ac­count func­tions a lot like a sec­ond 401k, but in­vested solely in the com­pany. Employees can pull out when­ever they’d like, but out­side of those ap­proved uses they will have to pay taxes and an early with­drawal fee to re­move the funds be­fore the age of 59 ½. After they leave the com­pany or re­tire, the com­plete bal­ance of their ac­counts will be paid out to them over a six-year pe­riod.

This means the com­pany needs to have that cash on hand to pay out, and this has to be bud­geted into their an­nual cash flow. But it also means the em­ploy­ees are in­cen­tivized to par­tic­i­pate in the well­be­ing of the com­pany.

On the stock mar­ket, ex­ec­u­tives are ex­pected to pro­duce quar­terly re­sults, of­ten to the detri­ment of their com­pa­nies’ long-term suc­cess. After Boeing fa­mously rushed the roll­out of its 737 MAX air­craft to meet quar­terly ex­pec­ta­tions, fa­tal crashes and safety con­cerns killed 346 peo­ple and cost the com­pany $20 bil­lion. Companies like Wells Fargo, Sears, and Bausch Health have sim­i­larly cut cor­ners to in­flate short-term re­sults at the ex­pense of their long-term health.

But an em­ployee at Central States does­n’t care about one good quar­ter, they care about a good 10 years, and a good 50. If the com­pa­ny’s prod­ucts turn out to be in­fe­rior next year their stock in the com­pany will tank, if the com­pany goes bank­rupt in 20 years it will go down to zero. It’s in their best in­ter­est to act in the long-term in­ter­est of the com­pany, and to grow it sus­tain­ably rather than quickly.

“One of our CEOs likes to say that these com­pa­nies are not look­ing to hit home runs, they’re look­ing to hit sin­gles and dou­bles on a reg­u­lar ba­sis,” Noelle Montaño, ex­ec­u­tive di­rec­tor for Employee-owned S Corporations of America (or ESCA) tells me. “When the C-Suite goes into work every day, they see the re­cep­tion­ist, the per­son on the fac­tory floor, the guy who’s build­ing the build­ing or dig­ging the ditches, and they know that those are the share­hold­ers they are re­spon­si­ble for. They take that se­ri­ously.”

Every month, Central States ex­ec­u­tives share the com­pa­ny’s P&L with em­ploy­ees, and every year they share the fi­nan­cials of the busi­ness at an­nual share­hold­ers meet­ings, where em­ployee-own­ers can par­tic­i­pate in dis­cus­sions about the fu­ture of the com­pany. After a new plant was strug­gling with sales in its sec­ond year, one em­ployee-owner raised his hand at a share­holder meet­ing and said, “This is­n’t help­ing our com­pany, and it’s not help­ing my share price, can we dis­cuss the clo­sure of this plant?”

“It was a great con­ver­sa­tion, I love the fact that it’s not some­body else’s prob­lem,” Ruger says. “They’re think­ing like busi­ness own­ers, which is what you want, right?”

As a re­sult, ESOPs are gen­er­ally health­ier com­pa­nies. “These com­pa­nies do bet­ter at em­ployee re­ten­tion, they do bet­ter at re­tire­ment ben­e­fits, they de­fault less of­ten on loans,” Montaño says. “Our com­pa­nies did bet­ter dur­ing the Great Recession, they did bet­ter dur­ing Covid.”

There are se­ri­ous ben­e­fits to the com­pany for op­er­at­ing this way. ESOPs are a vi­able al­ter­na­tive to unions—there is no rift be­tween the own­ers and the work­ers, work­ers are the own­ers! They are also ex­empt from pay­ing in­come tax—though they tend to spend those dol­lars on their em­ploy­ees in­stead.

“It helped us grow when we were smaller. Now that we’re larger, what we’re pay­ing out each year to our em­ployee-own­ers is prob­a­bly more than we would pay in tax, quite hon­estly,” Ruger says. “But if I have to choose who we pay our money to, I’d rather pay em­ployee own­ers than give it back to the gov­ern­ment. I think it’s prob­a­bly the right way.”

He brings up a good point. I’ve men­tioned be­fore that I do not think the an­swer to our wealth dis­par­ity is to “tax the rich.” Don’t take Jeff Bezos’ money and give it to the gov­ern­ment, bet­ter dis­trib­ute Amazon’s earn­ings among its em­ploy­ees—not just to its founder.

“I think our taxes are way too bur­den­ing and we don’t do a good job us­ing the money. I would­n’t mind pay­ing more if we were us­ing it well, I just don’t know if we are,” Ruger says. “Why re­dis­trib­ute the wealth af­ter it’s al­ready been earned, why can’t we earn it be­fore­hand? It nat­u­rally lev­els out the haves and have-nots.”

It’s worth not­ing that the “haves” still ben­e­fit from this equa­tion.

“Most ESOP com­pa­nies start be­cause the founder wants to exit or cash out, but they don’t want to sell to a pri­vate eq­uity firm that will run their com­pany into the ground or slash and burn em­ployee head­count,” Ware says. “A lot of own­ers built a com­pany and were in the trenches with the peo­ple be­side them. They want to take care of them, but they also want to cash out. A good op­tion is to set up an ESOP, and that’s ex­actly how Central States got started.”

Carl Carpenter founded Central States in 1988, but sold it to his em­ploy­ees when he re­tired in 1991. More specif­i­cally: He sold a por­tion of the shares of his com­pany to an ESOP trust, which holds the com­pa­ny’s shares on be­half of the em­ploy­ees. In 2011, the com­pany bought the re­main­ing shares and be­came 100% em­ployee-owned. Carpenter sailed into the sun­set with a nice re­tire­ment pack­age even as he al­lowed his em­ploy­ees to start build­ing their own, and I don’t see why every founder should­n’t do the same.

“There are real ben­e­fits for an owner turn­ing the com­pany into an ESOP,” Ruger says. “They per­son­ally ben­e­fit from the sale when they exit the busi­ness. Additionally, there are some real tax ben­e­fits to turn it into an ESOP—they pay a whole lot less taxes when they sell the com­pany.”

The only rea­son they don’t do it more of­ten is be­cause they don’t know about it. “The num­ber one is­sue is ed­u­ca­tion,” Montaño says. “If you’re look­ing to sell your busi­ness and you go to your ac­coun­tant or lawyer, they may not say ‘Have you thought about an ESOP?’”

It’s also not a quick process—founders in­ter­ested in sell­ing to their em­ploy­ees need to plan ahead. A fea­si­bil­ity study needs to be con­ducted to en­sure the vi­a­bil­ity of an ESOP plan and an in­de­pen­dent val­u­a­tion of the com­pany needs to be con­ducted to de­ter­mine the fair mar­ket value of the shares. A trust needs to be de­fined and struc­tured, and a trustee ap­pointed to over­see it on be­half of the em­ploy­ees. “If an owner just wants to get out, an ESOP is not for them,” Montaño says.

That might be chang­ing, ESOPs have bi-par­ti­san sup­port in Congress and moves have been made to im­prove ed­u­ca­tion about ESOPS and make the tran­si­tion eas­ier for founders. “We have sup­port from Members of Congress across the po­lit­i­cal spec­trum…. It’s cap­i­tal­ism at its best,”  Montaño says. “A year and a half ago, there was leg­is­la­tion man­dat­ing the Department of Labor to open an Office of Employee Ownership, and they’ve taken a more ro­bust in­ter­est in ESOP com­pa­nies and re­cently ap­pointed some­one from the em­ployee own­er­ship com­mu­nity to this im­por­tant role.”

In 2022, only 34 per­cent of fam­i­lies in the bot­tom half of in­come dis­tri­b­u­tion held stocks, while 78 per­cent of fam­i­lies in the up­per-mid­dle-in­come group did—95 per­cent of fam­i­lies in the top one per­cent held stocks. But em­ployee own­er­ship changes that equa­tion. As the process be­comes eas­ier and ed­u­ca­tion about ESOPs grows, more and more founders will exit by sell­ing their com­pa­nies to their em­ploy­ees, and the re­sult is that more and more of the wealth will be owned by every­one who works, not just the per­son they work for.

As the stock mar­ket gets richer, so will we all, and that’s a fu­ture I’m ex­cited about work­ing to­ward.

“I’d love to see it more and more and more,” Ruger says. “It’s re­ally gen­er­at­ing wealth for peo­ple, I’m con­vinced we’re go­ing to change gen­er­a­tions.”

This is a con­tin­u­a­tion of my cap­i­tal­ism se­ries which is fig­ur­ing out how cap­i­tal­ism can work bet­ter for every­one while serv­ing as re­search for my utopian novel. I hope you’ll join us in the com­ments for fur­ther dis­cus­sion!

P. S. If you en­joyed this post, please share it or rec­om­mend my work to your sub­scribers! That’s how I meet new peo­ple and earn a liv­ing as a writer. Thank you so much for your sup­port.

You must log in or reg­is­ter to re­ply here.

So you think you know box shad­ows?

Four years ago I found out my m1 can ren­der a stu­pid num­ber of these bad boys and so I set out to see just how far you can push them and boy did I. If you are look­ing for a how to use box shad­ows to get the look of the lat­est UX trend, this is not the right ar­ti­cle for you. But if you like some janky cre­ativ­ity, stay tuned.

I want to share some of the worst pos­si­ble things one can do with box shad­ows all on a sin­gle div. Things which should­n’t work at all yet some­how they do. But be­fore get­ting into that, a ques­tion must be an­swered.

What ex­actly is a box shadow?

A box shadow is a kind of drop shadow. And a drop shadow is a kind of im­age fil­ter which is par­tic­u­larly pop­u­lar in graphic de­sign due to how ver­sa­tile it is at adding an ap­prox­i­ma­tion of depth to com­po­si­tion.

The fil­ter takes the raster of an im­age and shifts the pix­els along the x and y axis. It will draw these pix­els as a sin­gle color be­hind the source im­age. This gives an il­lu­sion of depth by drop­ping the out­line of an im­age as a “shadow” into the com­po­si­tion hence the name drop shadow.

We can use the css fil­ter prop­erty to see this in ac­tion.

There are many dif­fer­ent im­ple­men­ta­tions of a drop shadow fil­ter across dif­fer­ent tools like pho­to­shop, gimp, figma, and css each hav­ing a dif­fer­ent set of fea­tures. For ex­am­ple css also sup­ports an op­tional blur value to ap­ply to the drop shadow.

By lay­er­ing sev­eral drop fil­ters one can eas­ily add in­ter­est­ing depth to a com­po­si­tion.

For ex­am­ple, here are 2 lay­ered drop-shadow fil­ters.

A box shadow is a form of drop fil­ter with many trade offs. First, the name “Box” has to do with the fil­ter only sup­port­ing box shapes. For ex­am­ple, lets try ap­ply­ing it to the pre­vi­ous ex­am­ple.

Notice that the shadow shape is lim­ited to the bound­ing box of the con­tainer and how the shadow can break out of the bound­ing box. This seems lim­it­ing but it comes with a few more fea­tures one of which is per­for­mance.

It turns out that the ma­jor­ity of user in­ter­faces are made up of boxes. It also turns out that some smart peo­ple fig­ured out maths hacks to draw rounded boxes for su­per cheap which UI peeps love be­cause with this hack boxes can be so round as to ap­pear as cir­cles. And the css box shadow im­ple­men­ta­tion sup­ports this math hack.

This means that de­sign­ers can be lib­eral with box shad­ows rather than re­ly­ing on pre­ren­dered source im­ages bloat­ing down­load sizes.

This lit­tle mixer shows the va­ri­ety of shapes avail­able. Tap to ran­dom­ize the color.

This opens up a all kinds of free­dom for UI de­sign. Layering these to­gether can pro­duce amaz­ing re­sults. You can play around with a bor­der ed­i­tor here.

Layering. That is an im­por­tant word. You can layer or chain many box shad­ows to­gether on a sin­gle div. The above ex­am­ple uses this to set the col­ors.

How not to use box shad­ows

Usually, a de­signer will care­fully po­si­tion squares within other squares with con­sis­tent mar­gins, paddings, and ty­pog­ra­phy for op­ti­mal ac­ces­si­bil­ity and un­der­stand­abil­ity. Wisely, they fur­ther add lay­ered shad­ows and per­haps a few im­ages to help vi­su­ally dis­tin­guish wid­get in­ter­ac­tion and state.

That is all well and good but what we are re­ally work­ing with is a kind of paint­ing api. We can paint an ar­bi­trary num­ber of squares to the screen op­tion­ally ap­ply­ing a blur to them.

I ini­tially ex­plored this with somme min­i­mal art in an ear­lier write up.

every­thing changed when the fire na­tion at­tackedWe are not wor­thy!

The con­fig that dri­ves this is pretty sim­ple.

Now the nat­ural ques­tion I am sure you have and I cer­tainly had was, “can we do more box shad­ows?” What about blur­ring or trans­parency? How do they im­pact per­for­mance?

I whipped up a lit­tle vi­sual tool where a gi­ant box shadow is cre­ated and set on a div like so.

Animation is han­dled by set­ting the box shadow string every 300ms and then let­ting tran­si­tion: all prop do the an­i­ma­tion. This causes some jank and ended up be­ing slower that set­ting the box shadow on every frame.

The re­sult is an app where you can tap to remix a color palette with a his­tory of the last 10 palettes to the left. Here is an ex­am­ple with 100 box shad­ows. Tap around.

I no­ticed that ap­ply­ing a blur slowed down the num­ber you could an­i­mate which makes sense. However, us­ing a trans­par­ent color sig­nif­i­cantly slowed down the num­ber that can be drawn too which does­n’t make as much sense to me. I’d imag­ine that with hard­ware to­day trans­parency should be some­what free. The div size also im­pacts per­for­mance which makes me think there is some soft­ware ras­ter­izer in­volved when things are an­i­mated. I could look into the source code of browsers but it would be dif­fer­ent de­pend­ing on the js en­gine.

However, I found that if I did­n’t set any trans­parency or blur, my m1 lap­top could draw buck­ets of box shad­ows. Like thou­sands of them.

How to not use box shad­ows

Ok, many box shad­ows can be drawn. Now what?

Well we can­not ro­tate the box shad­ows but they can be cir­cles and a cir­cle kinda looks like a ball. So what if I made a bunch of balls that could bounce around? And maybe I can “fake” a 3d ef­fect by scal­ing the size based on a z value. This would­n’t be ac­cu­rate per­spec­tive but would add some 3d depth.

This one is pretty sim­ple. Just a big’ol “gamestate” up­dated in a re­ques­tAni­ma­tion­Frame and then set a gi­ant box shadow string on div. You can touch some­where to pull the balls to­wards you. The balls are con­tained to a box and will bounce to stay in frame.

Updating the sim­u­la­tion is­n’t com­pli­cated but for the sake of brevity I will use a bit of psu­docode.

const up­date: GameFunction = (state) => {

for (const ball in state) {

up­date­Ball();

con­tain­Ball();

addFric­tion();

if (touched) pull­To­Point(touchX, touchY);

Now ren­der­ing is the in­ter­est­ing part. What is go­ing to be run 60 time a sec­ond is the fol­low­ing.

Sort the balls based on z in­dex and fill an ar­ray of box shad­ows. The size cal­cu­la­tion is based off of want­ing to have x,y,z rep­re­sent the cen­ter of a ball with a ra­dius of size. The z scale is a hack to have some z “depth” where the size is scaled based on a fixed ra­tio.

Here are 50 balls. Drag em around and make em bounce on the sides.

The 3d scal­ing works pretty well to give a lit­tle bit of depth even if it is to­tal bs. You can no­tice that when a ball gets close to the “camera” at a cer­tain point it is no longer a cir­cle. This is be­cause the box shadow div is too small for the scal­ing method. Increasing the con­tainer size fixes this but a larger con­tainer means slower per­for­mance.

Let’s see what hap­pens if the balls can bounce off each other with some good old fash­ion n^2 col­li­sion check. Now, I am only go­ing to re­flect the balls ve­loc­ity on a col­li­sion de­tec­tion which is in­ac­cu­rate but sim­ple. This is not sim­u­lat­ing any real physics in­ter­ac­tion. I will also fix the z po­si­tion to make it 2d so it is eas­ier to see what is hap­pen­ing.

Not very in­ter­est­ing. I think some­thing more ac­cu­rate physics would look nicer but maybe an­other time. Adding a phone gyro as in­put to this could be fun too but again maybe an­other time.

I re­pro­duced an­other setup where the balls al­ways try and find their way home to a ran­dom start­ing po­si­tion. The force of a touch is enough to pull them away how­ever. This give an ef­fect al­most like a sponge where you can pull bits off. I can think of ways this could be used for some foam spray in fake fluid sim as part of a game or some­thing. Kind of fun.

I no­ticed that the fake 3d re­ally comes out in the above ex­am­ple as the balls slowly travel back home. How could the 3d as­pect be taken fur­ther? Maybe I could draw point clouds with the box shad­ows as points? I could pro­ject points on dif­fer­ence sur­faces and then draw the points like some go­daw­ful 3d ren­derer.

I thought a good start­ing point would be to sim­ply map pix­els from a pic­ture as points on a 2d plane. This would also be a good stress test to find out what the up­per limit is on num­ber of re­al­time sim­u­lated box shad­ows. Here is the map­ping func­tion.

const pix­els = await getIm­agePix­els(

“/images/starry_night_full.jpg” as any,

width

const dx = win­dow.in­ner­Width / pix­els[0].length;

const dy = win­dow.in­ner­Height / pix­els.length;

for (let y = 0; y < pix­els.length; y++) {

for (let x = 0; x < pix­els[0].length; x++) {

const px = x * dx + dx / 2,

py = y * dy + dy / 2,

pz = 60 + Math.random() * 3;

state.par­ti­cles.push({

size: pSize,

x: px,

y: py,

z: pz,

ox: px,

oy: py,

oz: pz,

dx: Math.random() * 3,

dy: Math.random() * 3,

dz: Math.random() * 3,

color: pix­els[y][x],

The im­age is scaled to fit a max width which can be con­fig­ured in a query param but oth­er­wise it is the same as be­fore. If you want the source, here is the code­sand­box.

I started with one of my all time fa­vorite paint­ings ever. Tap around.

Depending on your de­vice, this demo may be melt­ing it as it is ren­der­ing sev­eral thou­sand box shad­ows in sim­u­lated 3d space. You can drag around to kinda ex­plode the im­age up. This is tak­ing the pre­vi­ous ex­am­ples and set­ting the start­ing po­si­tions and col­ors based on an im­age.

I am go­ing to bump up the count and ro­tate the cam­era. I will record this one to save some bat­tery life. If you want to burn your bat­tery give a live ver­sion a try here. You have been warned.

This is promis­ing. I per­son­ally love how this has an al­most painted style due to the cir­cu­lar pix­els look­ing kinda splat­ted on. Here is an­other ex­am­ple with an in­creased count and some in­ter­ac­tion.

You can see it is chug­ging at this scale. For ref­er­ence, this is some­where in the ball­park of 12,000 box shad­ows. I mean, damn. I won­der if per­haps it is so fast be­cause the m1 has shared gpu and cpu mem­ory? My desk­top cer­tainly can­not push this many box shad­ows nei­ther can my iphone or old an­droid. Crazy re­sult tho.

What about a pro­ject­ing the points uni­formly on to the sur­face of a mesh?

It turns out with a bit of math it to­tally works. Here is a cube us­ing a for­mula with uni­form point dis­tri­b­u­tion.

You can tap to in­ter­act with it. Kinda re­minds me of jello. I also added a small light which fol­lows the mouse po­si­tion­ing. This adds a bit more depth. The light is not ac­cu­rate at all with magic con­stants left and right but what is pro­gram­ming with­out a sprin­kling of magic? 😊

.map(([p, co­ord]) => {

const zIn­dexS­cale = 1 + co­ord.z / 40;

const size = p.size * zIn­dexS­cale;

const half­Size = (size - state.ren­der­Con­tain­er­Size) / 2;

const hcs = state.ren­der­Con­tain­er­Size / 2;

const light­Dist = Math.sqrt(dist(coord, light­Pos));

const in­ten­sity = (1 - light­Dist / 900) * 1; // I have no idea what i was do­ing here.

const lu­men = Math.min(2, (1 / light­Dist ** 2) * 60000);

re­turn [

co­ord.x + hcs,

“px ”,

co­ord.y + hcs,

“px 0 ”,

half­Size,

“px ”,

dark­en­Hex­Color(p.color, lu­men),

].join(“”);

I used gyp­ity to give me a func­tion to do the cube par­ti­cle map­ping among a few other math helpers. Sometimes gyp­ity-g would work but some­times it would­n’t and I have to stop be­ing lazy. More on this later…

The first func­tion gyp­tiy gave was a ran­dom dis­tri­b­u­tion which I did­n’t want. I wanted a uni­form place­ment of points across the sur­face of a uni­form sized cube. It was able to get this on the sec­ond try.

const half­Side­Length = Math.floor(cubeSideLength / 2);

This is a very short book about copy­ing. Its con­tents, un­less

oth­er­wise noted, are li­censed un­der

CC-BY SA 4.0

(more on that in a bit). You can down­load, copy, remix, ex­cerpt,

change, and re­post it how­ever you see fit.

Charles Eames said it best: “We don’t do ‘art’ — we solve prob­lems.”

To buy fur­ni­ture in 1950, you had to choose be­tween af­ford­able and en­dur­ing, be­tween rugged and fash­ion­able. Charles and Ray de­signed a chair that was all the above and sold it for $20.95.

They called it the LCW.

The LCW em­bod­ies the Eames’ ob­ses­sion with sim­plic­ity in ma­te­r­ial and method. “We want to make the best for the most for the least,” they said.

The de­sign was rev­o­lu­tion­ary: in 1999, Time mag­a­zine called the LCW “the best de­sign of the cen­tury.”

Today, you can buy a brand new LCW from Herman Miller (the of­fi­cially li­censed man­u­fac­turer of Eames prod­ucts) for $1,195.

Or, you can buy a chair called the “Fathom” from a com­pany called Modway for $145.

Functionally and aes­thet­i­cally, the chairs are iden­ti­cal.

There’s an LCW from 1946 in MOMA’s col­lec­tion. It’s one of the very first ever made. Most peo­ple would call it the orig­i­nal LCW.

Charles and Ray Eames sold the man­u­fac­tur­ing rights for their fur­ni­ture to Herman Miller in 1947. Collectors call the LCWs made in the ’40s and ’50s “originals.” But in some sense, these — and the more re­cently man­u­fac­tured Herman Miller ver­sions — are copies of that LCW in the MOMA col­lec­tion.

And then there’s the Modway Fathom. It’s clearly a copy, an un­li­censed one at that. But at $145 (the equiv­a­lent of $12.78 in 1947) it’s more af­ford­able than the LCW was when it was first man­u­fac­tured and sold. In spirit, it’s more of an orig­i­nal than any LCW: the best, for the most, for the least.

I’m shar­ing this story be­cause it demon­strates a sur­pris­ing fact: what makes some­thing “original” (the first, the best, the most fa­mous, the most true) or a “copy” (an iden­ti­cal copy, an unau­tho­rized replica, an in­ter­pre­ta­tion or a remix) is­n’t al­ways ob­vi­ous — or im­por­tant.

I’m a de­signer. As a de­signer, I feel the need to be orig­i­nal. If you’re a de­signer, or even if you’re just in­ter­ested in de­sign, you prob­a­bly feel the need to be orig­i­nal, too. We tend to wor­ship in­ven­tors and orig­i­na­tors, de­sign­ers who were trail­blaz­ing and in­no­v­a­tive. And we copy them.

This oxy­moron of a craft can drive a per­son crazy. There’s lots of space be­tween orig­i­nal­ity and in­dus­try, au­thor­ship and ac­knowl­edge­ment, riff­ing and rip­ping. I wrote this very short book to ex­plore that space.

Some peo­ple have been frus­trated by copy­ing, re­fused to ac­cept it, and strug­gled with every ounce of their strength against it. Other peo­ple have used copy­ing to their ad­van­tage, whether to im­prove them­selves, build a com­mu­nity, or sub­vert au­thor­ity.

I’ve only been able to have a ca­reer in de­sign be­cause I copied.

I hope that by the time you’ve fin­ished read­ing, you’ll see how im­por­tant copy­ing is. Right or wrong, virtue or vice, copy­ing is the way de­sign works.

Steve Jobs copied.

“Great artists steal,” he said, quot­ing Pablo Picasso (or was it Stravinsky? T. S. Eliot?). Jobs and Apple copied many de­signs in their early days, most no­tably from a Xerox re­search lab­o­ra­tory in Palo Alto. The story goes like this:

In the early 20th cen­tury, Xerox was a pi­o­neer of of­fice tech­nol­ogy. By the mid­dle of the cen­tury, com­put­ers were get­ting smaller and more af­ford­able, and Xerox knew they’d have to work hard to keep their mar­ket dom­i­nance. In 1970, The Xerox Palo Alto Research Center — Xerox PARC — was founded to ex­plore the fu­ture of the “paperless of­fice.”

Within two years, Xerox PARC had de­signed a ground­break­ing com­puter called the Alto. One of its in­no­va­tions was a graph­i­cal user in­ter­face: pro­grams and files were dis­played in vir­tual win­dows which users nav­i­gated us­ing a mouse. It was an eerily ac­cu­rate pic­ture of what per­sonal com­put­ers would look like 30 years later.

Jef Raskin, leader of the Macintosh pro­ject at Apple, had seen Xerox’s work. He wanted Steve Jobs to see it for him­self, and set up a meet­ing.

“I thought it was the best thing I’d ever seen in my life,” Jobs said of the Alto’s user in­ter­face. “Within ten min­utes it was ob­vi­ous to me that all com­put­ers would work like this some day.”

When the Macintosh was re­leased in 1984, it fea­tured a graph­i­cal user in­ter­face. Programs and files were dis­played in vir­tual win­dows which users nav­i­gated us­ing a mouse.

It was just like the Alto.

Steve Jobs did­n’t like to be copied.

In 1985, a year af­ter the Macintosh was launched, Apple sued a com­pany called Digital Research Interactive for copy­ing the Macintosh’s user in­ter­face. Digital Research set­tled out of court, and changed the ap­pear­ance of its icons, win­dows, and mouse point­ers.

In 1990, Apple sued both Microsoft and Hewlett-Packard. The case was a re­peat: Microsoft’s Windows and HP’s NewWave fea­tured de­signs that Apple claimed were copies of the Macintosh’s op­er­at­ing sys­tem. But early li­cens­ing agree­ments be­tween Apple and Microsoft made it un­clear if any in­fringe­ment took place; the case was thrown out.

In the mid­dle of Apple’s case against Microsoft, Xerox sued Apple, hop­ing to es­tab­lish its rights as the in­ven­tor of the desk­top in­ter­face. The court threw out this case, too, and ques­tioned why Xerox took so long to raise the is­sue.

Bill Gates later re­flected on these cases: “we both had this rich neigh­bor named Xerox … I broke into his house to steal the TV set and found out that [Jobs] had al­ready stolen it.”

The ram­pant copy­ing fu­el­ing the ex­plo­sive growth of con­sumer com­put­ers meant that by 1990, the desk­top user in­ter­face was ubiq­ui­tous; it was im­pos­si­ble to de­ter­mine who orig­i­nated any part of it, or who copied who. The quest to stake their claim nearly con­sumed Apple. But when they emerged, they had learned a thing or two. Today, Apple holds more than 2,300 de­sign patents.

This story ends in 2011, with Apple su­ing Samsung for copy­ing the de­sign of its soft­ware and hard­ware prod­ucts. One of the most re­mark­able claims: Samsung broke the law when it sold “a rec­tan­gu­lar prod­uct with four evenly rounded cor­ners.”

The court re­jected Apple’s claim to own rounded rec­tan­gles. But it up­held the other claims, fin­ing Samsung a blis­ter­ing $539 mil­lion for patent vi­o­la­tions.

Designers copy. We steal like great artists. But when we see a copy of our work, we’re livid. Jobs, on Google’s Android: “I will spend my last dy­ing breath if I need to, and I will spend every penny of Apple’s $40 bil­lion in the bank, to right this wrong. I’m go­ing to de­stroy Android, be­cause it’s a stolen prod­uct.”

Steve Jobs was un­matched in his vi­sion­ary ded­i­ca­tion to in­no­va­tion. But he never came to terms with the in­evitabil­ity of copy­ing.

John Carmack had a dif­fer­ent re­la­tion­ship with copy­ing. For him, copy­ing was a way to learn, a chal­lenge to over­come, and a source of new ideas.

Carmack was — still is — a bril­liant coder. He’s best known for pro­gram­ming the ul­tra­vi­o­lent and ac­tion-packed first-per­son shoot­ers Doom and Quake. Those games pushed the lim­its of con­sumer com­put­ers and de­fined a genre. But his first real break­through game was sim­pler, cuter, more whim­si­cal. It was called Commander Keen.

Growing up in the early ’90s, I loved Commander Keen. It’s a goofy ad­ven­ture game; you guide an eight-year-old boy wear­ing a foot­ball hel­met and red Converses through alien plan­ets, col­lect­ing candy bars and zap­ping mon­sters with a ray gun.

Keen be­gan life as a copy of an­other of my fa­vorite games: Super Mario Bros. 3.

Before Keen, Carmack was work­ing for a sub­scrip­tion soft­ware com­pany called Softdisk. Carmack and the other pro­gram­mers at Softdisk churned out these games at a prodi­gious rate: to­day, block­buster games can take more than five years to cre­ate;

Softdisk pro­duced a brand-new full-length game every sin­gle month.

In September 1990, Carmack de­cided that for his next game, he’d try to tackle a new and daunt­ing chal­lenge: scrolling. At the time, only con­soles like the Nintendo had enough com­put­ing power to smoothly scroll scenery, char­ac­ters, and en­e­mies. The PCs were stuck to sim­ple one-screen-at-a-time games. But if Carmack was go­ing to sell mil­lions of games like Nintendo had with Super Mario Bros., he needed to fig­ure out how to recre­ate the ef­fect.

So, on September 19, 1990, Carmack and an­other de­vel­oper named Tom Hall de­cided to re­verse-en­gi­neer the first level of Super Mario Bros. 3. Working through the night, Carmack coaxed his PC into scrolling and an­i­mat­ing the world of Super Mario; Hall jumped back and forth be­tween a TV screen and his com­puter, play­ing the Nintendo ver­sion, paus­ing to copy the im­ages pixel-for-pixel.

The next day, their cowork­ers were floored. Nobody had ever seen a PC game work like this. John Romero, Carmack’s clos­est col­league and fu­ture col­lab­o­ra­tor on Doom and Quake, called it “the fuck­ing coolest thing on the planet.”

He in­sisted that they keep copy­ing un­til they had fin­ished an ex­act replica of the full game. They were go­ing to send it to Nintendo.

Unfortunately for Carmack and his team, Nintendo was­n’t in­ter­ested in a PC ver­sion of Super Mario (their con­sole ver­sion was do­ing just fine, thank you very much).

Disappointed, but not de­feated, they re­solved to build a bet­ter ver­sion of Mario. Starting with Carmack’s code for scrolling and an­i­mat­ing the screen, the coders — call­ing them­selves Ideas from the Deep, keep­ing the game a se­cret from their day jobs at Softdisk — put their Super Mario copy through a com­plete meta­mor­pho­sis. In place of Mario, it starred eight-year-old Billy Blaze. Instead of tur­tles and mush­rooms, the en­e­mies were aliens called Yorps. Instead of eat­ing a mush­room to jump higher, Billy Blaze hopped on a pogo stick.

The de­but Commander Keen game, Commander Keen in Invasion of the Vorticons, was a huge suc­cess. More than 50,000 copies were sold, mak­ing Keen one of the best-sell­ing PC games of its time.

Unlike Steve Jobs, John Carmack never changed his mind about copy­ing. When his boss at Softdisk sug­gested that they patent Carmack’s PC scrolling tech­nique, Carmack reeled. “If you ever ask me to patent any­thing,” he said, “I’ll quit.”

In a 2005 fo­rum post, John Carmack ex­plained his thoughts on patents. While patents are framed as pro­tect­ing in­ven­tors, he wrote, that’s sel­dom how they’re used. Smart pro­gram­mers work­ing on hard prob­lems tend to come up with the same so­lu­tions. If any one of those pro­gram­mers patents their so­lu­tion, the rest are screwed.

He con­cluded: “I’ll have no part of it. Its [sic] ba­si­cally mug­ging some­one.”

In his games af­ter Keen, Carmack would go be­yond sim­ply re­fus­ing to patent his in­ven­tions. He would re­lease the source code to the biggest games of the ’90s, Wolfenstein 3D, Doom, and Quake. Everyone is free to down­load, mod­ify, or copy them.

It’s one thing to copy.

It’s an­other to en­cour­age oth­ers to copy from you. Richard Stallman went even fur­ther — he made copy­ing a right.

In 1983, Richard Stallman wanted to build a new op­er­at­ing sys­tem. At the time, Unix was the most pop­u­lar and in­flu­en­tial op­er­at­ing sys­tem, but it was ex­pen­sive to li­cense. Commercial li­censes cost $20,000 — that’s $52,028 in 2020 money.

And Unix was closed-source.

So on September 27, 1983, he wrote this mes­sage on the Unix Wizards mes­sage board:

That Stallman would write soft­ware and give it to oth­ers to use, for free, was a rad­i­cal no­tion. To drive the point home, Stallman wrote a man­i­festo, defin­ing the idea of free soft­ware (“Free soft­ware is soft­ware that users have the free­dom to dis­trib­ute and change.”) The man­i­festo kicked off the free soft­ware move­ment.

The en­dur­ing in­no­va­tion of Stallman’s move­ment was how he and his co-con­spir­a­tors used soft­ware li­censes. They flipped tra­di­tional li­cens­ing on its head: in­stead of pro­hibit­ing the copy­ing or dis­tri­b­u­tion of the soft­ware, a free soft­ware li­cense guar­an­tees the right of peo­ple to use, mod­ify, dis­trib­ute, and learn from its code.

Instead of pro­hibit­ing the copy­ing or dis­tri­b­u­tion of the soft­ware,

a free soft­ware li­cense guar­an­tees the right of peo­ple to use,

mod­ify, dis­trib­ute, and learn from its code.

New kinds of soft­ware li­censes weren’t the only prod­uct of the free soft­ware move­ment. Ideological off­shoots quickly spun out into new groups, like the open-source soft­ware move­ment. While Stallman’s free soft­ware fac­tion was cen­tered around a small group of hard-line pro­gres­sive coders, the open-source move­ment was broad and in­clu­sive, aban­don­ing some of Stallman’s more po­lit­i­cal lan­guage to spread far­ther and find new au­di­ences.

Permissive li­cens­ing and dis­trib­uted source con­trol form the en­gine of mod­ern soft­ware de­vel­op­ment. They cre­ate a feed­back loop, or a sym­bi­otic pair, or a liv­ing or­gan­ism, or maybe even a virus: the tools that soft­ware de­vel­op­ers use are them­selves prod­ucts of the open-source phi­los­o­phy. Free and open-source code repli­cates it­self, mu­tates, and spreads in­stantly across the world.

The free and open-source soft­ware move­ments (sometimes com­bined into a sin­gle acronym, FOSS) were echoed by an­other rev­o­lu­tion in how cre­ative works are li­censed. In 2001, Lawrence Lessig, Hal Abelson, and Eric Eldred started Creative Commons, a non-profit and in­ter­na­tional net­work ded­i­cated to en­abling the shar­ing and reuse of “creativity and knowl­edge through the pro­vi­sion of free le­gal tools.”

Nearly 20 years later, nearly half of a mil­lion im­ages on Flickr have Creative Commons (or CC) li­censes. Wikipedia uses CC li­censes on all its pho­tos and art. MIT pro­vides more than 2,400 courses on­line for free un­der Creative Commons li­censes. Countless mil­lions of cre­ative works have ben­e­fited from the open-source ap­proach to li­censes and per­mis­sions.

An im­age of a feed­back loop from Flickr’s Creative Commons

archive

A decade ago, the open-source move­ment came to de­sign. Michael Cho cre­ated Unsplash

in 2013 to share a few pho­tographs he thought might be use­ful to de­sign­ers at star­tups; as of September 2020, Unsplash hosts 2,147,579 pho­tos, and all-time photo down­loads are well over 2 bil­lion.

Pablo Stanley re­cently re­leased Humaaans, a col­lec­tion of Creative Commons-licensed de­signs that can be re-as­sem­bled into ed­i­to­r­ial graph­ics. Feather icons, Heroicons, and Bootstrap Icons

are all open-source and free-to-use col­lec­tions of UI icons, used by de­sign­ers to build web­sites and ap­pli­ca­tions.

Meanwhile, the ex­plo­sion of open-source de­sign re­sources has been bol­stered by a new class of tools for shar­ing and col­lab­o­rat­ing on de­sign. Abstract

is a ver­sion-con­trol sys­tem for de­sign that promises “collaboration with­out the chaos.” With Abstract, many de­sign­ers can con­tribute to a sin­gle file, with­out wor­ry­ing about over­writ­ing each oth­er’s changes or al­ways need­ing to down­load the lat­est ver­sions. Figma, too, has just launched its com­mu­nity fea­ture

, al­low­ing de­sign­ers to pub­lish files and down­load each oth­er’s pro­jects. It’s not hard to imag­ine how this will evolve into a de­sign­er’s ver­sion of GitHub

in the near fu­ture. Other de­sign tools have fol­lowed suit: both Sketch and Framer have launched com­mu­nity con­tent hubs, lay­ing the ground­work for dis­trib­uted source con­trol.

Copying is fun­da­men­tal to de­sign, just as it is to soft­ware. The rise of per­mis­sive li­censes and ver­sion con­trol tools makes it seem like copy­ing is a new idea, an in­no­v­a­tive ap­proach in an in­dus­try that thrives on nov­elty. But the truth is, copy­ing has in­formed art and in­dus­try for thou­sands of years.

In China, there are many con­cepts of a copy, each with dis­tinct sub­text. Fangzhipin (仿製品) are copies that are ob­vi­ously dif­fer­ent from the orig­i­nal — like small sou­venir mod­els of a statue. Fuzhipin (複製品) are ex­act, life-size re­pro­duc­tions of the orig­i­nal. Fuzhipin are just as valu­able as orig­i­nals, and have no neg­a­tive stigma.

In 1974, lo­cal farm­ers in the Xi’an re­gion of China un­earthed life-sized sculp­tures of sol­diers made of terra cotta clay. When Chinese arche­ol­o­gists came to in­ves­ti­gate the site, they un­cov­ered fig­ure af­ter fig­ure, in­clud­ing horses and char­i­ots, all ex­quis­itely de­tailed. All told, there were more than 8,000 terra cotta sol­diers. They were dated to 210 BCE.

The ter­ra­cotta war­riors in­stantly be­came cul­tural trea­sures. A mu­seum was built on the site of the ex­ca­va­tion, but many of the stat­ues were also ex­hib­ited in trav­el­ing shows. Hundreds of thou­sands of mu­se­um­go­ers all over the world lined up in gal­leries to see the sol­diers.

Then, in 2007, a rev­e­la­tion rocked the Museum für Völkerkunde in Hamburg, Germany: some of the ter­ra­cotta war­riors it had on dis­play were not the orig­i­nals that had been dis­cov­ered in the field in Xi’an. They were copies.

The Museum für Völkerkunde’s di­rec­tor be­came a pariah: “We have come to the con­clu­sion that there is no other op­tion than to close the ex­hi­bi­tion com­pletely, in or­der to main­tain the mu­se­um’s good rep­u­ta­tion.” The mu­seum is­sued re­funds to vis­i­tors. The event kicked off a rash of geopo­lit­i­cal fin­ger-point­ing: German of­fi­cials cried foul, say­ing they were duped; Chinese of­fi­cials washed their hands, since they never claimed the stat­ues were orig­i­nals to be­gin with.

The stat­ues in the Hamburg mu­seum were fuzhipin, ex­act copies. They were equiv­a­lent to the orig­i­nals. After all, the orig­i­nals were them­selves prod­ucts of mass man­u­fac­tur­ing, made with mod­ules and com­po­nents cast from molds. Almost as soon as the ter­ra­cotta war­riors were dis­cov­ered, Chinese ar­ti­sans be­gan pro­duc­ing repli­cas, con­tin­u­ing the work that had started more than 2,000 years be­fore.

It’s easy to at­tribute this ap­proach to copy­ing as a cul­tural cu­rios­ity, an aber­ra­tion par­tic­u­lar to China. But copy­ing was just as vi­tal to Western artists.

Japanese art was one of the main sources of in­spi­ra­tion for Vincent van Gogh, him­self one of the most in­flu­en­tial European painters of the 19th cen­tury, if not of all time. Van Gogh was fas­ci­nated by the wood­block prints of artists like Hiroshige: styl­ized and vivid, they cap­tured dra­matic mo­ments within com­pelling sto­ries.

Van Gogh’s in­ter­est went be­yond in­spi­ra­tion. To study the tech­niques mas­tered by Japanese artists, he copied prints by Keisei Eisen and Utagawa Hiroshige. He tried to repli­cate their bold lines, their en­er­getic com­po­si­tions, and their strong col­ors. For his copy of Eisen’s A cour­te­san, van Gogh started by trac­ing the out­line of the cour­te­san’s fig­ure di­rectly from the May 1886 edi­tion of Paris Illustré. For Flowering Plum Tree and The Bridge in the Rain, both copies of Hiroshige prints, he added bor­ders of Japanese cal­lig­ra­phy he had seen on other prints.

Sudden Shower over Shin-Ōhashi bridge and Atake

(1857) by Hiroshige

The Bridge in the Rain (after Hiroshige) (1887) by

Vincent Van Gogh

His prac­tice with Japanese styles pro­vided a cru­cial break­through. Van Gogh be­gan to flat­ten land­scapes. He out­lined his sub­jects in bold black strokes. He painted with eye-wa­ter­ing col­ors. His in­ter­pre­ta­tions of re­al­ity lit the art world on fire, in­flu­enc­ing artists and de­sign­ers to this day.

By copy­ing di­rectly from Japanese artists, van Gogh’s works be­came what we know to­day.

He was clear about this in­flu­ence. In a let­ter to his brother Theo, he wrote: “All my work is based to some ex­tent on Japanese art.”

There’s an­other word in Chinese for a copy: shanzhai (山寨). It’s trans­lated to English as “fake,” but as with most Chinese words, the trans­la­tion is lack­ing. Shanzhai lit­er­ally means “mountain strong­hold;” the word is a ne­ol­o­gism, a re­cent in­ven­tion, in­spired by a fa­mous novel in which the pro­tag­o­nists hide in a moun­tain strong­hold to fight against a cor­rupt regime. Shanzhai prod­ucts are play­ful, draw­ing at­ten­tion to the fact that they aren’t orig­i­nal, putting their mak­ers’ cre­ativ­ity on dis­play.

Take the pop­u­lar shanzhai novel Harry Potter and the Porcelain Doll; in it, Harry goes to China to stop Voldemort and Voldemort’s Chinese coun­ter­part. It does­n’t pre­tend to be an orig­i­nal. It plays on its fake-ness: Harry speaks Chinese flu­ently, but he has trou­ble eat­ing with chop­sticks.

Today, we are an­nounc­ing Mistral Large 2, the new gen­er­a­tion of our flag­ship model. Compared to its pre­de­ces­sor, Mistral Large 2 is sig­nif­i­cantly more ca­pa­ble in code gen­er­a­tion, math­e­mat­ics, and rea­son­ing. It also pro­vides a much stronger mul­ti­lin­gual sup­port, and ad­vanced func­tion call­ing ca­pa­bil­i­ties.

This lat­est gen­er­a­tion con­tin­ues to push the bound­aries of cost ef­fi­ciency, speed, and per­for­mance. Mistral Large 2 is ex­posed on la Plateforme and en­riched with new fea­tures to fa­cil­i­tate build­ing in­no­v­a­tive AI ap­pli­ca­tions. Mistral Large 2 has a 128k con­text win­dow and sup­ports dozens of lan­guages in­clud­ing French, German, Spanish, Italian, Portuguese, Arabic, Hindi, Russian, Chinese, Japanese, and Korean, along with 80+ cod­ing lan­guages in­clud­ing Python, Java, C, C++, JavaScript, and Bash.Mistral Large 2 is de­signed for sin­gle-node in­fer­ence with long-con­text ap­pli­ca­tions in mind — its size of 123 bil­lion pa­ra­me­ters al­lows it to run at large through­put on a sin­gle node. We are re­leas­ing Mistral Large 2 un­der the Mistral Research License, that al­lows us­age and mod­i­fi­ca­tion for re­search and non-com­mer­cial us­ages. For com­mer­cial us­age of Mistral Large 2 re­quir­ing self-de­ploy­ment, a Mistral Commercial License must be ac­quired by con­tact­ing us.Mis­tral Large 2 sets a new fron­tier in terms of per­for­mance / cost of serv­ing on eval­u­a­tion met­rics. In par­tic­u­lar, on MMLU, the pre­trained ver­sion achieves an ac­cu­racy of 84.0%, and sets a new point on the per­for­mance/​cost Pareto front of open mod­els.Fol­low­ing our ex­pe­ri­ence with Codestral 22B and Codestral Mamba, we trained Mistral Large 2 on a very large pro­por­tion of code. Mistral Large 2 vastly out­per­forms the pre­vi­ous Mistral Large, and per­forms on par with lead­ing mod­els such as GPT-4o, Claude 3 Opus, and Llama 3 405B.A sig­nif­i­cant ef­fort was also de­voted to en­hanc­ing the mod­el’s rea­son­ing ca­pa­bil­i­ties. One of the key fo­cus ar­eas dur­ing train­ing was to min­i­mize the mod­el’s ten­dency to “hallucinate” or gen­er­ate plau­si­ble-sound­ing but fac­tu­ally in­cor­rect or ir­rel­e­vant in­for­ma­tion. This was achieved by fine-tun­ing the model to be more cau­tious and dis­cern­ing in its re­sponses, en­sur­ing that it pro­vides re­li­able and ac­cu­rate out­puts.Ad­di­tion­ally, the new Mistral Large 2 is trained to ac­knowl­edge when it can­not find so­lu­tions or does not have suf­fi­cient in­for­ma­tion to pro­vide a con­fi­dent an­swer. This com­mit­ment to ac­cu­racy is re­flected in the im­proved model per­for­mance on pop­u­lar math­e­mat­i­cal bench­marks, demon­strat­ing its en­hanced rea­son­ing and prob­lem-solv­ing skills:Per­for­mance ac­cu­racy on code gen­er­a­tion bench­marks (all mod­els were bench­marked through the same eval­u­a­tion pipeline)Per­for­mance ac­cu­racy on MultiPL-E (all mod­els were bench­marked through the same eval­u­a­tion pipeline, ex­cept for the “paper” row)Per­for­mance ac­cu­racy on GSM8K (8-shot) and MATH (0-shot, no CoT) gen­er­a­tion bench­marks (all mod­els were bench­marked through the same eval­u­a­tion pipeline)We dras­ti­cally im­proved the in­struc­tion-fol­low­ing and con­ver­sa­tional ca­pa­bil­i­ties of Mistral Large 2. The new Mistral Large 2 is par­tic­u­larly bet­ter at fol­low­ing pre­cise in­struc­tions and han­dling long multi-turn con­ver­sa­tions. Below we re­port the per­for­mance on MT-Bench, Wild Bench, and Arena Hard bench­marks:Per­for­mance on gen­eral align­ment bench­marks (all mod­els were bench­marked through the same eva­l­u­ta­tion pipeline)On some bench­marks, gen­er­at­ing lengthy re­sponses tends to im­prove the scores. However, in many busi­ness ap­pli­ca­tions, con­cise­ness is para­mount — short model gen­er­a­tions fa­cil­i­tate quicker in­ter­ac­tions and are more cost-ef­fec­tive for in­fer­ence. This is why we spent a lot of ef­fort to en­sure that gen­er­a­tions re­main suc­cinct and to the point when­ever pos­si­ble. The graph be­low re­ports the av­er­age length of gen­er­a­tions of dif­fer­ent mod­els on ques­tions from the MT Bench bench­mark:A large frac­tion of busi­ness use cases to­day in­volve work­ing with mul­ti­lin­gual doc­u­ments. While the ma­jor­ity of mod­els are English-centric, the new Mistral Large 2 was trained on a large pro­por­tion of mul­ti­lin­gual data. In par­tic­u­lar, it ex­cels in English, French, German, Spanish, Italian, Portuguese, Dutch, Russian, Chinese, Japanese, Korean, Arabic, and Hindi. Below are the per­for­mance re­sults of Mistral Large 2 on the mul­ti­lin­gual MMLU bench­mark, com­pared to the pre­vi­ous Mistral Large, Llama 3.1 mod­els, and to Cohere’s Command R+.Performance on Multilingual MMLU (measured on the base pre­trained model)Mis­tral Large 2 is equipped with en­hanced func­tion call­ing and re­trieval skills and has un­der­gone train­ing to pro­fi­ciently ex­e­cute both par­al­lel and se­quen­tial func­tion calls, en­abling it to serve as the power en­gine of com­plex busi­ness ap­pli­ca­tions.You can use Mistral Large 2 to­day via la Plateforme un­der the name mis­tral-large-2407, and test it on le Chat. It is avail­able un­der the ver­sion 24.07 (a YY.MM ver­sion­ing sys­tem that we are ap­ply­ing to all our mod­els), and the API name mis­tral-large-2407. Weights for the in­struct model are avail­able and are also hosted on HuggingFace.we are con­sol­i­dat­ing the of­fer­ing on la Plateforme around two gen­eral pur­pose mod­els, Mistral Nemo and Mistral Large, and two spe­cial­ist mod­els, Codestral and Embed. As we pro­gres­sively dep­re­cate older mod­els on la Plateforme, all Apache mod­els (Mistral 7B, Mixtral 8x7B and 8x22B, Codestral Mamba, Mathstral) re­main avail­able for de­ploy­ment and fine-tun­ing us­ing our SDK mis­tral-in­fer­ence and mis­tral-fine­tune.Start­ing to­day, we are ex­tend­ing fine-tun­ing ca­pa­bil­i­ties on la Plateforme: those are now avail­able for Mistral Large, Mistral Nemo and Codestral.We are proud to part­ner with lead­ing cloud ser­vice providers to bring the new Mistral Large 2 to a global au­di­ence. In par­tic­u­lar, to­day we are ex­pand­ing our part­ner­ship with Google Cloud Platform to bring Mistral AI’s mod­els on Vertex AI via a Managed API. Mistral AI’s best mod­els are now avail­able on Vertex AI, in ad­di­tion to Azure AI Studio, Amazon Bedrock and IBM wat­sonx.ai.

Please make sure your browser sup­ports JavaScript and cook­ies and that you are not block­ing them from load­ing. For more in­for­ma­tion you can re­view our Terms of

Service and Cookie Policy.