Over the years, Flutter has at­tracted mil­lions of de­vel­op­ers who built user in­ter­faces across every plat­form. Flutter be­gan as a UI toolkit for mo­bile - iOS and Android, only. Then Flutter added sup­port for web. Finally, Flutter ex­panded to Mac, Windows, and Linux. Across this mas­sive ex­pan­sion of scope and re­spon­si­bil­ity, the Flutter team has only mar­gin­ally in­creased its size. To help ex­pand Flutter’s avail­able la­bor, and ac­cel­er­ate de­vel­op­ment, we’re cre­at­ing a fork of Flutter, called Flock.

Let’s do some back-of-the-nap­kin math to ap­pre­ci­ate the Flutter team’s la­bor short­age.

How many Flutter de­vel­op­ers ex­ist in the world, to­day? My guess is that it’s on the or­der of 1,000,000 de­vel­op­ers. The real num­ber is prob­a­bly higher, but one mil­lion should be rea­son­ably con­ser­v­a­tive.

How large is the Flutter team, to­day? Google does­n’t pub­lish this in­for­ma­tion, but my guess is that the team is about 50 peo­ple strong.

That’s 50 peo­ple serv­ing the needs of 1,000,000. Doing a lit­tle bit of di­vi­sion, that means that every sin­gle mem­ber of the Flutter team is re­spon­si­ble for the needs of 20,000 Flutter de­vel­op­ers! That ra­tio is clearly un­work­able for any sem­blance of cus­tomer sup­port.

A la­bor short­age can al­ways be fixed through hir­ing. However, due to com­pany-wide is­sues at Google, the Flutter team’s head count was frozen circa 2023, and then ear­lier in 2024 we learned of a small num­ber of lay­offs. It seems that the team may now be ex­pand­ing again, through out­sourc­ing, but we’re not likely to see the Flutter team dou­ble or quadru­ple its size any time soon.

To make mat­ters worse, Google’s cor­po­rate re-fo­cus on AI caused the Flutter team to de-pri­or­i­tize all desk­top plat­forms. As we speak, the Flutter team is in main­te­nance mode for 3 of its 6 sup­ported plat­forms. Desktop is quite pos­si­bly the great­est un­tapped value for Flutter, but it’s now mostly stag­nant.

Limited la­bor comes at a great cost for a toolkit that has rapidly ex­panded its user base, along with its over­all scope.

With so few de­vel­op­ers to work on tick­ets, many tick­ets linger in the back­log. They can eas­ily linger for years, if they’re ever ad­dressed at all.

By the time a mem­ber of the Flutter team be­gins to in­ves­ti­gate a ticket, the ticket might be years old. At that point, the Flutter team de­vel­oper typ­i­cally asks for fur­ther in­for­ma­tion from the per­son who filed the ticket. In my ex­pe­ri­ence, when this hap­pens to me, I’ve long since stopped work­ing with the client who had the ini­tial is­sue. I’ve writ­ten hun­dreds of thou­sands of lines of code since then. I of­ten don’t even re­mem­ber fil­ing the is­sue, let alone the ob­scure de­tails re­lated to the orig­i­nal is­sue. The team can’t fix the bug with­out in­for­ma­tion from me, and it’s been too long for me to pro­vide in­for­ma­tion to the team. So the bug gets buried for a fu­ture de­vel­oper to re­dis­cover.

Timing is­n’t just an is­sue for even­tu­ally root caus­ing and fix­ing bugs. It’s also a ma­jor prod­uct prob­lem. Imagine that you’re the en­gi­neer­ing di­rec­tor, or CTO of a com­pany whose next re­lease is blocked by some Flutter bug. What do you do if the team won’t work on that bug for 2 years? Well, if it’s a se­ri­ous bug for your com­pany, then you stop us­ing Flutter. You don’t have a choice. You need to keep mov­ing for­ward. Your team does­n’t know how to work on the Flutter frame­work, and the Flutter frame­work team is ei­ther un­re­spon­sive, or at least com­pletely non-com­mit­tal to­wards a fix. Oh well - can’t use Flutter any more. Flutter won’t sur­vive if these kinds of ex­pe­ri­ences be­come com­mon.

Flutter has two very valu­able qual­i­ties. First, it’s open source, so any de­vel­oper can see how any part of Flutter is im­ple­mented, and can even change it. Second, the Flutter frame­work is writ­ten in the same lan­guage as Flutter apps. Because of these two qual­i­ties, ex­pe­ri­enced Flutter app de­vel­op­ers, and pack­age de­vel­op­ers can con­tribute to the Flutter frame­work.

How many Flutter de­vel­op­ers ex­ist in the world to­day who are ca­pa­ble of con­tribut­ing at a pro­duc­tive level to the Flutter frame­work? Conservatively, I would guess there are about 1,000 of them. In other words, there are at least 1,000 Flutter de­vel­op­ers in the world who could con­ceiv­ably be hired to the Flutter team, if the team wanted to hire that many de­vel­op­ers.

Remember that ra­tio of 1 Flutter team mem­ber per 20,000 de­vel­op­ers? If every ca­pa­ble Flutter frame­work con­trib­u­tor in the world reg­u­larly con­tributed to Flutter, that ra­tio of 1:20,000 would drop to 1:1,000. That’s still a big ra­tio, but it’s much bet­ter than what it is now.

Moreover, as more ex­ter­nal con­trib­u­tors get com­fort­able sub­mit­ting fixes and fea­tures to Flutter, they’ll tend to help train oth­ers to do the same. Thus, the sup­port ra­tio would con­tinue to move in a bet­ter di­rec­tion.

If in­creased ex­ter­nal con­tri­bu­tions is the path to a bet­ter Flutter world, then why fork Flutter when every­one could just work di­rectly with the Flutter team?

It’s a tempt­ing propo­si­tion to setup a con­certed ef­fort to con­tribute di­rectly to Flutter. After all, the Flutter team reg­u­larly touts the num­ber of ex­ter­nal con­tri­bu­tions that it rolls into each re­lease. According to the Flutter pub­lic re­la­tions ef­fort, they’d love all those ex­ter­nal con­tri­bu­tions!

But, sadly, try­ing to work with the Flutter team de­liv­ers a dif­fer­ent re­al­ity. While some de­vel­op­ers have had suc­cess work­ing with the Flutter team, many other de­vel­op­ers have found it frus­trat­ing, if not un­work­able. There are, no doubt, a num­ber of fac­tors that con­tribute to this re­sult. Different de­vel­op­ers will ex­pe­ri­ence dif­fer­ent is­sues. But here are some of them:

* Limited re­view la­bor:

The de­vel­op­ers who don’t have enough time to write code are the same de­vel­op­ers tapped

to re­view con­tri­bu­tions. Therefore, it can take a long time for re­view or up­dates.

The time crunch also seems to lend it­self to con­tentious re­view con­ver­sa­tions.

* The de­vel­op­ers who don’t have enough time to write code are the same de­vel­op­ers tapped

to re­view con­tri­bu­tions. Therefore, it can take a long time for re­view or up­dates.

* The time crunch also seems to lend it­self to con­tentious re­view con­ver­sa­tions.

* Everything takes for­ever, and it al­ways seems to be about non-crit­i­cal de­tails.

* Communication mono­cul­ture - most of the team seems to ex­pect a cer­tain way of com­mu­ni­cat­ing,

which does­n’t match the va­ri­ety of per­son­al­i­ties in the world. Thus, some peo­ple have an

ex­cep­tion­ally dif­fi­cult time nav­i­gat­ing oth­er­wise quick and sim­ple con­ver­sa­tions.

The re­sult of the afore­men­tioned is­sues, and prob­a­bly oth­ers that aren’t listed, is that the to­tal num­ber of peo­ple who have ever con­tributed to the Flutter frame­work is cur­rently less than 1,500. That num­ber in­cludes peo­ple who dropped by, one time, to fix a typo in a Dart Doc and then never con­tributed again. That’s not the num­ber of reg­u­lar con­trib­u­tors who add sig­nif­i­cant value.

Whatever your ex­pe­ri­ence with con­tri­bu­tions to Flutter, one has to crit­i­cally as­sess why a team that loves ex­ter­nal con­tri­bu­tions has only man­aged to merge con­tri­bu­tions from 1,500 de­vel­op­ers over a span of nearly a decade. My hum­ble sug­ges­tion is that it’s be­cause the invit­ing mes­sage of the PR team does­n’t match the ex­pe­ri­ence of ac­tu­ally push­ing a change through the team’s poli­cies, de­vel­oper avail­abil­ity, and tech­ni­cal cul­ture.

The only peo­ple who can change this re­al­ity are the peo­ple within the Flutter or­ga­ni­za­tion. However, most of those peo­ple don’t ac­tu­ally think any of this is a prob­lem. I know, be­cause a num­ber of them have ex­pressed this to me, di­rectly. There are a num­ber of sig­nif­i­cant blind spots for the Flutter team, which largely re­volve around the fact that mem­bers of the team have never been re­spon­si­ble for rou­tinely de­liv­er­ing app fea­tures and fixes that are built upon Flutter. In other words, I be­lieve there are blind spots be­cause Flutter team mem­bers don’t ac­tu­ally use Flutter. Thus, the ur­gency around many is­sues is­n’t ap­pre­ci­ated, nor is the ur­gency and time cost as­so­ci­ated with sub­mit­ting fixes di­rectly to Flutter as an ex­ter­nal con­trib­u­tor.

If the Flutter team does­n’t rec­og­nize the con­tri­bu­tion prob­lem, and there­fore won’t take steps to ad­dress it, then what else can be done? That’s where we find our­selves in this post, and in this ef­fort. We’ve de­cided that the one thing we can do to help the la­bor is­sue is to fork Flutter.

Our fork of Flutter is called Flock. We de­scribe Flock as “Flutter+”. In other words, we

do not want, or in­tend, to fork the Flutter com­mu­nity. Flock will re­main con­stantly up to date with Flutter. Flock will add im­por­tant bug fixes, and pop­u­lar com­mu­nity fea­tures, which the Flutter team ei­ther can’t, or won’t im­ple­ment.

By fork­ing Flutter, we get to de­cide what gets merged. We won’t lower the qual­ity bar, but by con­trol­ling merge de­ci­sions, we do gain the fol­low­ing op­por­tu­ni­ties:

* Recruit a much larger PR re­view team than the Flutter team. This means faster re­view times.

* Recruit PR re­view­ers who are ready to fa­cil­i­tate con­tri­bu­tions, in­stead of merely tol­er­at­ing them.

This means sup­port for a wider con­trib­u­tor au­di­ence.

* Optimize poli­cies. E.g., don’t blindly de­mand de­sign docs and con­fer­ence calls when they won’t

sub­stan­tially add to the ef­fec­tive­ness of the task at hand.

* Use con­tri­bu­tion suc­cesses to so­cially pro­mote more con­tri­bu­tions.

* We’re all Flutter users - lever­age team and com­pany re­la­tion­ships to iden­tify mar­ket pri­or­ity.

As Flock ships im­por­tant bug fixes and fea­tures, the Flutter team can then choose to add those to Flutter, on their sched­ule. The com­mu­nity will no longer be lim­ited by the Flutter team’s avail­abil­ity, nor will the com­mu­nity need to beg the Flutter team to please ac­cept a change. The Flutter team can use Flock’s so­lu­tions, or not, but all Flock users will have ac­cess to them, elim­i­nat­ing your com­pany and team’s ur­gency and des­per­a­tion.

Flock, as the name im­plies, will only go as far as the com­mu­nity that sup­ports it. We would love for you to get in­volved.

Flock’s first step is to mir­ror Flutter. This means au­to­mat­i­cally mir­ror­ing the mas­ter,

beta, and sta­ble branches, along with repli­cat­ing all re­lease tags. Additionally, once the frame­work is mir­rored, Flock will need to au­to­mat­i­cally build and up­load the en­gine, and make those en­gine bi­na­ries avail­able to Flock users.

As we work through the mir­ror­ing process, it would be a big help if you would try build­ing your apps with Flock. You should­n’t see any dif­fer­ence be­tween Flock and Flutter, and you can con­fig­ure Flock with a tiny Flutter Version Manager (FVM) con­fig­u­ra­tion.

Check our in­struc­tions to get started.

Flock needs to re­cruit dozens of re­view­ers. Reviewers are re­spon­si­ble for en­forc­ing a qual­ity bar that’s sim­i­lar to Flutter’s. This in­cludes re­quir­ing de­scrip­tive class, method, and prop­erty names, ef­fec­tive Dart Docs, and ap­pro­pri­ate tests.

But we want re­view­ers to go even fur­ther than that. We don’t just want to tol­er­ate con­tri­bu­tions - we want to fa­cil­i­tate them. Many of us have had the ex­pe­ri­ence of get­ting a PR 90% to the fin­ish line only to have a Flutter team re­viewer de­clare that it can’t merge un­til we do some­thing that we don’t know how to do. It’s an aw­ful ex­pe­ri­ence, and we aim to avoid it with Flock.

We want Flock re­view­ers who are will­ing to step in and help a con­trib­u­tor achieve the fi­nal 10% of the PR. This does­n’t mean con­trib­u­tors get to be lazy. But if a con­trib­u­tor has done every­thing that he knows how to do, and the PR is close to com­plete, then we want the re­viewer to step in and pro­vide di­rec­tion for the fi­nal 10%. This is how we ed­u­cate con­trib­u­tors and en­sure that the next PR is 100% com­plete.

If you’d like to be­come a Flock re­viewer, please reach out to us.

Maintaining and ex­tend­ing a long-lived fork of Flutter re­quires some num­ber of ex­perts who di­rect spe­cific ar­eas of the pro­ject. For ex­am­ple, I’m ini­tially step­ping up at the Director of Flock, as well as the Framework Lead. Jesse Ezell has stepped up as the Engine Lead.

We’d like to bring in a Flutter Tool lead, who di­rects ex­ten­sions to the flut­ter CLI tool.

We’d also like to break up the en­gine re­spon­si­bil­i­ties with a Lead per plat­form: Android, iOS, Mac, Windows, Linux.

If you’d like to di­rect ef­forts for an area of Flock, please reach out to us.

Let’s shift Flutter into over­drive and help make it the uni­ver­sal UI toolkit it should have been. Flutter has the po­ten­tial to out­shine every al­ter­na­tive in the mar­ket. But it needs the com­mu­nity to Flock to­gether to help get it there. Let’s do this!

Apple un­veils the new iMac with M4, su­per­charged by Apple Intelligence and avail­able in fresh col­ors

The world’s best all-in-one desk­top fea­tures even more per­for­mance, a nano-tex­ture dis­play op­tion, a 12MP Center Stage cam­era, and Thunderbolt 4 con­nec­tiv­ity — all in a strik­ingly thin de­sign

CUPERTINO, CALIFORNIA Apple to­day an­nounced the new iMac, fea­tur­ing the pow­er­ful M4 chip and Apple Intelligence, in its stun­ning, ul­tra-thin de­sign. With M4, iMac is up to 1.7x faster for daily pro­duc­tiv­ity, and up to 2.1x faster for de­mand­ing work­flows like photo edit­ing and gam­ing, com­pared to iMac with M1.1 With the Neural Engine in M4, iMac is the world’s best all-in-one for AI and is built for Apple Intelligence, the per­sonal in­tel­li­gence sys­tem that trans­forms how users work, com­mu­ni­cate, and ex­press them­selves, while pro­tect­ing their pri­vacy. The new iMac is avail­able in an ar­ray of beau­ti­ful new col­ors, and the 24-inch 4.5K Retina dis­play of­fers a new nano-tex­ture glass op­tion.2 iMac fea­tures a new 12MP Center Stage cam­era with Desk View, up to four Thunderbolt 4 ports,3 and color-matched ac­ces­sories that in­clude USB-C. Starting at just $1,299, now with 16GB of uni­fied mem­ory, the new iMac is avail­able to pre-or­der to­day, with avail­abil­ity be­gin­ning Friday, November 8.

“iMac is beloved by mil­lions of users, from fam­i­lies at home to en­tre­pre­neurs hard at work. With the in­cred­i­ble fea­tures of Apple Intelligence and the pow­er­ful per­for­mance of Apple sil­i­con, the new iMac changes the game once again,” said John Ternus, Apple’s se­nior vice pres­i­dent of Hardware Engineering. “With M4 and Apple Intelligence, gor­geous new col­ors that pop in any space, an ad­vanced 12MP Center Stage cam­era, and a new nano-tex­ture glass dis­play op­tion, it’s a whole new era for iMac.”

Three peo­ple watch a scene from an an­i­mated movie on iMac.

iMac is shown in the store­front of a busi­ness.

The new iMac brings even more fun with bold new col­ors, en­abling users to add a pop of per­son­al­iza­tion in their homes, work­spaces, or store­fronts.

The new iMac brings even more fun with bold new col­ors, en­abling users to add a pop of per­son­al­iza­tion in their homes, work­spaces, or store­fronts.

On a pur­ple iMac, a user has two win­dows open as they mul­ti­task be­tween Safari and Excel.

iMac with M4 fea­tures the world’s fastest CPU core, mak­ing mul­ti­task­ing across apps like Safari and Excel light­ning fast.

With the power of M4 and its ad­vanced GPU, iMac en­ables in­cred­i­bly smooth game­play in ti­tles like the highly an­tic­i­pated Civilization VII.

The new iMac with M4 flies through de­mand­ing cre­ative work­flows, such as ap­ply­ing com­plex fil­ters and ef­fects in apps like Adobe Photoshop and Adobe Premiere Pro.

With sys­temwide Writing Tools pow­ered by Apple Intelligence, users can rewrite, proof­read, and sum­ma­rize text nearly every­where they write — from Apple apps like Keynote, to third-party apps like Craft and Bear.

Apple Intelligence does all this while pro­tect­ing users’ pri­vacy at every step. At its core is on-de­vice pro­cess­ing, and for more com­plex tasks, Private Cloud Compute gives users ac­cess to Apple’s even larger, server-based mod­els and of­fers ground­break­ing pro­tec­tions for per­sonal in­for­ma­tion. In ad­di­tion, users can ac­cess ChatGPT for free with­out cre­at­ing an ac­count, and pri­vacy pro­tec­tions are built in — their IP ad­dresses are ob­scured and OpenAI won’t store re­quests. For those who choose to con­nect their ac­count, OpenAI’s data-use poli­cies ap­ply.

The re­designed Siri helps users ac­cel­er­ate tasks through­out their day. Siri can be placed any­where on the desk­top for easy ac­cess, and with the op­tion to type re­quests, users can get Siri’s help in even a quiet space like an of­fice.

From left to right: (1) iMac fea­tures a color-matched key­board and mouse or track­pad. (2) These ac­ces­sories now come with USB-C ports, so users can charge all of their fa­vorite de­vices with just a sin­gle ca­ble.

(1) iMac fea­tures a color-matched key­board and mouse or track­pad. (2) These ac­ces­sories now come with USB-C ports, so users can charge all of their fa­vorite de­vices with just a sin­gle ca­ble.

With a new nano-tex­ture glass op­tion, which re­duces glare while de­liv­er­ing out­stand­ing im­age qual­ity, users can place iMac in even more spaces, such as a sun-drenched liv­ing room or bright store­front.

A new 12MP Center Stage cam­era makes video calls even more en­gag­ing, per­fectly cen­ter­ing users and those around them in the frame, even when mov­ing around.

Customers can pre-or­der the new iMac with M4 start­ing to­day, October 28, on ap­ple.com/​store and in the Apple Store app in 28 coun­tries and re­gions, in­clud­ing the U. S. It will be­gin ar­riv­ing to cus­tomers, and will be in Apple Store lo­ca­tions and Apple Authorized Resellers, be­gin­ning Friday, November 8.

iMac starts at $1,299 (U.S.) and $1,249 (U.S.) for ed­u­ca­tion, and is avail­able in green, yel­low, or­ange, pink, pur­ple, blue, and sil­ver. It fea­tures an 8-core CPU, an 8-core GPU, 16GB of uni­fied mem­ory con­fig­urable up to 24GB, 256GB SSD con­fig­urable up to 1TB, two Thunderbolt/USB 4 ports, Magic Keyboard, and Magic Mouse or Magic Trackpad.

iMac with a 10-core CPU and 10-core GPU starts at $1,499 (U.S.) and $1,399 (U.S.) for ed­u­ca­tion, and is avail­able in green, yel­low, or­ange, pink, pur­ple, blue, and sil­ver. It fea­tures 16GB of uni­fied mem­ory con­fig­urable up to 32GB, 256GB SSD con­fig­urable up to 2TB, four Thunderbolt 4 ports, Magic Keyboard with Touch ID, and Magic Mouse or Magic Trackpad.

Additional tech­ni­cal spec­i­fi­ca­tions — in­clud­ing the nano-tex­ture dis­play op­tion, con­fig­ure-to-or­der op­tions, and ac­ces­sories — are avail­able at ap­ple.com/​mac.

With Apple Trade In, cus­tomers can trade in their cur­rent com­puter and get credit to­ward a new Mac. Customers can visit ap­ple.com/​shop/​trade-in to see what their de­vice is worth.

Apple Intelligence is avail­able now as a free soft­ware up­date for Mac with M1 and later, and can be ac­cessed in most re­gions around the world when the de­vice and Siri lan­guage are set to U.S. English. The first set of fea­tures is in beta and avail­able with ma­cOS Sequoia 15.1, with more fea­tures rolling out in the months to come.

Apple Intelligence is quickly adding sup­port for more lan­guages. In December, Apple Intelligence will add sup­port for lo­cal­ized English in Australia, Canada, Ireland, New Zealand, South Africa, and the U.K., and in April, a soft­ware up­date will de­liver ex­panded lan­guage sup­port, with more com­ing through­out the year. Chinese, English (India), English (Singapore), French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, and other lan­guages will be sup­ported.

AppleCare+ for Mac pro­vides un­par­al­leled ser­vice and sup­port. This in­cludes un­lim­ited in­ci­dents of ac­ci­den­tal dam­age, bat­tery ser­vice cov­er­age, and 24/7 sup­port from the peo­ple who know Mac best.

Every cus­tomer who buys di­rectly from Apple Retail gets ac­cess to Personal Setup. In these guided on­line ses­sions, a Specialist can walk them through setup, or fo­cus on fea­tures that help them make the most of their new de­vice. Customers can also learn more about get­ting started with their new de­vice with a Today at Apple ses­sion at their near­est Apple Store.

Apple un­veils the new iMac with M4, su­per­charged by Apple Intelligence and avail­able in fresh col­ors

The world’s best all-in-one desk­top fea­tures even more per­for­mance, a nano-tex­ture dis­play op­tion, a 12MP Center Stage cam­era, and Thunderbolt 4 con­nec­tiv­ity — all in a strik­ingly thin de­sign

CUPERTINO, CALIFORNIA Apple to­day an­nounced the new iMac, fea­tur­ing the pow­er­ful M4 chip and Apple Intelligence, in its stun­ning, ul­tra-thin de­sign. With M4, iMac is up to 1.7x faster for daily pro­duc­tiv­ity, and up to 2.1x faster for de­mand­ing work­flows like photo edit­ing and gam­ing, com­pared to iMac with M1.1 With the Neural Engine in M4, iMac is the world’s best all-in-one for AI and is built for Apple Intelligence, the per­sonal in­tel­li­gence sys­tem that trans­forms how users work, com­mu­ni­cate, and ex­press them­selves, while pro­tect­ing their pri­vacy. The new iMac is avail­able in an ar­ray of beau­ti­ful new col­ors, and the 24-inch 4.5K Retina dis­play of­fers a new nano-tex­ture glass op­tion.2 iMac fea­tures a new 12MP Center Stage cam­era with Desk View, up to four Thunderbolt 4 ports,3 and color-matched ac­ces­sories that in­clude USB-C. Starting at just $1,299, now with 16GB of uni­fied mem­ory, the new iMac is avail­able to pre-or­der to­day, with avail­abil­ity be­gin­ning Friday, November 8.

“iMac is beloved by mil­lions of users, from fam­i­lies at home to en­tre­pre­neurs hard at work. With the in­cred­i­ble fea­tures of Apple Intelligence and the pow­er­ful per­for­mance of Apple sil­i­con, the new iMac changes the game once again,” said John Ternus, Apple’s se­nior vice pres­i­dent of Hardware Engineering. “With M4 and Apple Intelligence, gor­geous new col­ors that pop in any space, an ad­vanced 12MP Center Stage cam­era, and a new nano-tex­ture glass dis­play op­tion, it’s a whole new era for iMac.”

The M4 chip brings a boost in per­for­mance to iMac. Featuring a more ca­pa­ble CPU with the world’s fastest CPU core,4 the new iMac is up to 1.7x faster than iMac with M1. Users will feel this per­for­mance across every­day ac­tiv­i­ties like mul­ti­task­ing be­tween their fa­vorite apps and brows­ing web­pages in Safari. And with an im­mensely pow­er­ful GPU fea­tur­ing Apple’s most ad­vanced graph­ics ar­chi­tec­ture, iMac with M4 han­dles more in­tense work­loads like photo edit­ing and gam­ing up to 2.1x faster than iMac with M1. This also en­ables a smoother game­play ex­pe­ri­ence in ti­tles like the up­com­ing Civilization VII. The new iMac comes stan­dard with 16GB of faster uni­fied mem­ory — con­fig­urable up to 32GB. The Neural Engine in M4 is now over 3x faster than on iMac with M1, mak­ing it the world’s best all-in-one for AI, and ac­cel­er­at­ing the pace at which users can get things done.

Families, small busi­nesses, and en­tre­pre­neurs can fly through daily pro­duc­tiv­ity tasks with up to 1.7x faster per­for­mance1 in apps like Microsoft Excel, and up to 1.5x faster brows­ing per­for­mance5 in Safari com­pared to iMac with M1.

Gamers can en­joy in­cred­i­bly smooth game­play, with up to 2x higher frame rates5 than on iMac with M1.

Content cre­ators can edit like never be­fore, with up to 2.1x faster photo and video edit­ing per­for­mance when ap­ply­ing com­plex fil­ters and ef­fects in apps like Adobe Photoshop1 and Adobe Premiere Pro5 com­pared to iMac with M1.

Compared to the most pop­u­lar 24-inch all-in-one PC with the lat­est Intel Core 7 proces­sor, the new iMac is up to 4.5x faster.1

Compared to the most pop­u­lar Intel-based iMac model, the new iMac is up to 6x faster.1

A New Era with Apple Intelligence on the Mac

Apple Intelligence ush­ers in a new era for the Mac, bring­ing per­sonal in­tel­li­gence to the per­sonal com­puter. Combining pow­er­ful gen­er­a­tive mod­els with in­dus­try-first pri­vacy pro­tec­tions, Apple Intelligence har­nesses the power of Apple sil­i­con and the Neural Engine to un­lock new ways for users to work, com­mu­ni­cate, and ex­press them­selves on Mac. It is avail­able in U.S. English with ma­cOS Sequoia 15.1. With sys­temwide Writing Tools, users can re­fine their words by rewrit­ing, proof­read­ing, and sum­ma­riz­ing text nearly every­where they write. With the newly re­designed Siri, users can move flu­idly be­tween spo­ken and typed re­quests to ac­cel­er­ate tasks through­out their day, and Siri can an­swer thou­sands of ques­tions about Mac and other Apple prod­ucts. New Apple Intelligence fea­tures will be avail­able in December, with ad­di­tional ca­pa­bil­i­ties rolling out in the com­ing months. Image Playground gives users a new way to cre­ate fun orig­i­nal im­ages, and Genmoji al­lows them to cre­ate cus­tom emoji in sec­onds. Siri will be­come even more ca­pa­ble, with the abil­ity to take ac­tions across the sys­tem and draw on a user’s per­sonal con­text to de­liver in­tel­li­gence that is tai­lored to them. In December, ChatGPT will be in­te­grated into Siri and Writing Tools, al­low­ing users to ac­cess its ex­per­tise with­out need­ing to jump be­tween tools.

Apple Intelligence does all this while pro­tect­ing users’ pri­vacy at every step. At its core is on-de­vice pro­cess­ing, and for more com­plex tasks, Private Cloud Compute gives users ac­cess to Apple’s even larger, server-based mod­els and of­fers ground­break­ing pro­tec­tions for per­sonal in­for­ma­tion. In ad­di­tion, users can ac­cess ChatGPT for free with­out cre­at­ing an ac­count, and pri­vacy pro­tec­tions are built in — their IP ad­dresses are ob­scured and OpenAI won’t store re­quests. For those who choose to con­nect their ac­count, OpenAI’s data-use poli­cies ap­ply.

The new iMac comes in seven vi­brant col­ors, bring­ing fresh shades of green, yel­low, or­ange, pink, pur­ple, and blue, along­side sil­ver. The back of iMac fea­tures bold col­ors de­signed to stand out, while the front ex­presses sub­tle shades of the new palette so users can fo­cus on do­ing their best work. Every iMac comes with a color-matched Magic Keyboard and Magic Mouse or op­tional Magic Trackpad, all of which now fea­ture a USB-C port, so users can charge their fa­vorite de­vices with a sin­gle ca­ble.

The ex­pan­sive 24-inch 4.5K Retina dis­play on iMac is its high­est-rated fea­ture, and for the first time, it’s avail­able with a nano-tex­ture glass op­tion that dras­ti­cally re­duces re­flec­tions and glare, while main­tain­ing out­stand­ing im­age qual­ity.2 With nano-tex­ture glass, users can place iMac in even more spaces, such as a sun-drenched liv­ing room or bright store­front.

A new 12MP Center Stage cam­era with sup­port for Desk View makes video calls even more en­gag­ing. Center Stage keeps every­one per­fectly cen­tered on a video call — great for fam­i­lies gath­ered on FaceTime. Desk View makes use of the wide-an­gle lens to si­mul­ta­ne­ously show the user and a top-down view of their desk, which is use­ful for ed­u­ca­tors pre­sent­ing a les­son to stu­dents, or cre­ators show­ing off their lat­est DIY pro­ject. Rounding out the un­ri­valed au­dio and video ex­pe­ri­ence is the beloved stu­dio-qual­ity three-mi­cro­phone ar­ray with beam­form­ing and an im­mer­sive six-speaker sound sys­tem.

On the new iMac, all four USB-C ports sup­port Thunderbolt 4 for su­per­fast data trans­fers, so users can con­nect even more ac­ces­sories like ex­ter­nal stor­age, docks, and up to two 6K ex­ter­nal dis­plays, cre­at­ing a mas­sive can­vas with more than 50M pix­els for users to spread out their work.3 iMac also sup­ports both Wi-Fi 6E and Bluetooth 5.3. And with the ad­vanced se­cu­rity of Touch ID, users can eas­ily and se­curely un­lock their com­puter, make on­line pur­chases with Apple Pay, and down­load apps.6 Additionally, Touch ID works with Fast User Switching, so cus­tomers can switch be­tween dif­fer­ent user pro­files with just the press of a fin­ger.

ma­cOS Sequoia com­pletes the new iMac ex­pe­ri­ence with a host of ex­cit­ing fea­tures, in­clud­ing iPhone Mirroring, al­low­ing users to wire­lessly in­ter­act with their iPhone, its apps, and its no­ti­fi­ca­tions di­rectly from their Mac.7 Safari, the world’s fastest browser,8 now of­fers Highlights, which quickly pulls up rel­e­vant in­for­ma­tion from a site; a smarter, re­designed Reader with a table of con­tents and high-level sum­mary; and a new Video Viewer to watch videos with­out dis­trac­tions. With Distraction Control, users can hide items on a web­page that they may find dis­rup­tive to their brows­ing. Gaming gets even more im­mer­sive with fea­tures like Personalized Spatial Audio and im­prove­ments to Game Mode, along with a breadth of ex­cit­ing ti­tles, in­clud­ing the up­com­ing Assassin’s Creed Shadows. Easier win­dow tiling means users can stay or­ga­nized with a win­dows lay­out that works best for them. The all-new Passwords app gives con­ve­nient ac­cess to pass­words, passkeys, and other cre­den­tials, all stored in one place. And users can ap­ply beau­ti­ful new built-in back­grounds for video calls, in­clud­ing a va­ri­ety of color gra­di­ents and sys­tem wall­pa­pers, or up­load their own pho­tos.

Better for the Environment

The new iMac with M4 is de­signed with the en­vi­ron­ment in mind, with 100 per­cent re­cy­cled alu­minum in the stand, and 100 per­cent re­cy­cled gold plat­ing, tin sol­der­ing, and cop­per in mul­ti­ple printed cir­cuit boards. iMac meets Apple’s high stan­dards for en­ergy ef­fi­ciency, and is free of mer­cury, bromi­nated flame re­tar­dants, and PVC. New this year, the pack­ag­ing of iMac is en­tirely fiber-based, bring­ing Apple closer to its goal to re­move plas­tic from its pack­ag­ing by 2025.

Today, Apple is car­bon neu­tral for global cor­po­rate op­er­a­tions and, as part of its am­bi­tious Apple 2030 goal, plans to be car­bon neu­tral across its en­tire car­bon foot­print by the end of this decade.

Customers can pre-or­der the new iMac with M4 start­ing to­day, October 28, on ap­ple.com/​store and in the Apple Store app in 28 coun­tries and re­gions, in­clud­ing the U.S. It will be­gin ar­riv­ing to cus­tomers, and will be in Apple Store lo­ca­tions and Apple Authorized Resellers, be­gin­ning Friday, November 8.

iMac starts at $1,299 (U.S.) and $1,249 (U.S.) for ed­u­ca­tion, and is avail­able in green, yel­low, or­ange, pink, pur­ple, blue, and sil­ver. It fea­tures an 8-core CPU, an 8-core GPU, 16GB of uni­fied mem­ory con­fig­urable up to 24GB, 256GB SSD con­fig­urable up to 1TB, two Thunderbolt/USB 4 ports, Magic Keyboard, and Magic Mouse or Magic Trackpad.

iMac with a 10-core CPU and 10-core GPU starts at $1,499 (U.S.) and $1,399 (U.S.) for ed­u­ca­tion, and is avail­able in green, yel­low, or­ange, pink, pur­ple, blue, and sil­ver. It fea­tures 16GB of uni­fied mem­ory con­fig­urable up to 32GB, 256GB SSD con­fig­urable up to 2TB, four Thunderbolt 4 ports, Magic Keyboard with Touch ID, and Magic Mouse or Magic Trackpad.

Additional tech­ni­cal spec­i­fi­ca­tions — in­clud­ing the nano-tex­ture dis­play op­tion, con­fig­ure-to-or­der op­tions, and ac­ces­sories — are avail­able at ap­ple.com/​mac.

With Apple Trade In, cus­tomers can trade in their cur­rent com­puter and get credit to­ward a new Mac. Customers can visit ap­ple.com/​shop/​trade-in to see what their de­vice is worth.

Apple Intelligence is avail­able now as a free soft­ware up­date for Mac with M1 and later, and can be ac­cessed in most re­gions around the world when the de­vice and Siri lan­guage are set to U.S. English. The first set of fea­tures is in beta and avail­able with ma­cOS Sequoia 15.1, with more fea­tures rolling out in the months to come.

Apple Intelligence is quickly adding sup­port for more lan­guages. In December, Apple Intelligence will add sup­port for lo­cal­ized English in Australia, Canada, Ireland, New Zealand, South Africa, and the U.K., and in April, a soft­ware up­date will de­liver ex­panded lan­guage sup­port, with more com­ing through­out the year. Chinese, English (India), English (Singapore), French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, and other lan­guages will be sup­ported.

AppleCare+ for Mac pro­vides un­par­al­leled ser­vice and sup­port. This in­cludes un­lim­ited in­ci­dents of ac­ci­den­tal dam­age, bat­tery ser­vice cov­er­age, and 24/7 sup­port from the peo­ple who know Mac best.

Every cus­tomer who buys di­rectly from Apple Retail gets ac­cess to Personal Setup. In these guided on­line ses­sions, a Specialist can walk them through setup, or fo­cus on fea­tures that help them make the most of their new de­vice. Customers can also learn more about get­ting started with their new de­vice with a Today at Apple ses­sion at their near­est Apple Store.

About Apple

Apple rev­o­lu­tion­ized per­sonal tech­nol­ogy with the in­tro­duc­tion of the Macintosh in 1984. Today, Apple leads the world in in­no­va­tion with iPhone, iPad, Mac, AirPods, Apple Watch, and Apple Vision Pro. Apple’s six soft­ware plat­forms — iOS, iPa­dOS, ma­cOS, watchOS, vi­sionOS, and tvOS — pro­vide seam­less ex­pe­ri­ences across all Apple de­vices and em­power peo­ple with break­through ser­vices in­clud­ing the App Store, Apple Music, Apple Pay, iCloud, and Apple TV+. Apple’s more than 150,000 em­ploy­ees are ded­i­cated to mak­ing the best prod­ucts on earth and to leav­ing the world bet­ter than we found it.

Testing was con­ducted by Apple in September and October 2024. See ap­ple.com/​imac for more in­for­ma­tion.

Actual di­ag­o­nal screen mea­sure­ment is 23.5 inches. Nano-texture dis­play is an op­tion on mod­els with 10-core CPU and 10-core GPU.

All four USB-C ports sup­port Thunderbolt 4 on mod­els with 10-core CPU and 10-core GPU.

Testing was con­ducted by Apple in October 2024 us­ing ship­ping com­pet­i­tive sys­tems and se­lect in­dus­try-stan­dard bench­marks.

Results are com­pared to pre­vi­ous-gen­er­a­tion 24-inch iMac sys­tems with Apple M1, 8-core CPU, 8-core GPU, 16GB of RAM, and 2TB SSD.

iMac with 8-core CPU and 8-core GPU can con­fig­ure to Magic Keyboard with Touch ID and Numeric Keypad, and iMac with 10-core CPU and 10-core GPU comes stan­dard with Touch ID.

Available on Mac com­put­ers with Apple silicon and Intel-based Mac com­put­ers with a T2 Security Chip. Requires that the user’s iPhone and Mac are signed in with the same Apple Account us­ing two-fac­tor au­then­ti­ca­tion, their iPhone and Mac are near each other and have Bluetooth and Wi-Fi turned on, and their Mac is not us­ing AirPlay or Sidecar. Some iPhone fea­tures (e.g., cam­era and mi­cro­phone) are not com­pat­i­ble with iPhone Mir­ror­ing.

Testing was con­ducted by Apple in August 2024. See ap­ple.com/​sa­fari for more in­for­ma­tion.

Copy text

* Families, small busi­nesses, and en­tre­pre­neurs can fly through daily pro­duc­tiv­ity tasks with up to 1.7x faster per­for­mance1 in apps like Microsoft Excel, and up to 1.5x faster brows­ing per­for­mance5 in Safari com­pared to iMac with M1.

* Gamers can en­joy in­cred­i­bly smooth game­play, with up to 2x higher frame rates5 than on iMac with M1.

* Content cre­ators can edit like never be­fore, with up to 2.1x faster photo and video edit­ing per­for­mance when ap­ply­ing com­plex fil­ters and ef­fects in apps like Adobe Photoshop1 and Adobe Premiere Pro5 com­pared to iMac with M1.

* Compared to the most pop­u­lar 24-inch all-in-one PC with the lat­est Intel Core 7 proces­sor, the new iMac is up to 4.5x faster.1

* Compared to the most pop­u­lar Intel-based iMac model, the new iMac is up to 6x faster.1

* Customers can pre-or­der the new iMac with M4 start­ing to­day, October 28, on ap­ple.com/​store and in the Apple Store app in 28 coun­tries and re­gions, in­clud­ing the U.S. It will be­gin ar­riv­ing to cus­tomers, and will be in Apple Store lo­ca­tions and Apple Authorized Resellers, be­gin­ning Friday, November 8.

* iMac starts at $1,299 (U.S.) and $1,249 (U.S.) for ed­u­ca­tion, and is avail­able in green, yel­low, or­ange, pink, pur­ple, blue, and sil­ver. It fea­tures an 8-core CPU, an 8-core GPU, 16GB of uni­fied mem­ory con­fig­urable up to 24GB, 256GB SSD con­fig­urable up to 1TB, two Thunderbolt/USB 4 ports, Magic Keyboard, and Magic Mouse or Magic Trackpad.

* iMac with a 10-core CPU and 10-core GPU starts at $1,499 (U.S.) and $1,399 (U.S.) for ed­u­ca­tion, and is avail­able in green, yel­low, or­ange, pink, pur­ple, blue, and sil­ver. It fea­tures 16GB of uni­fied mem­ory con­fig­urable up to 32GB, 256GB SSD con­fig­urable up to 2TB, four Thunderbolt 4 ports, Magic Keyboard with Touch ID, and Magic Mouse or Magic Trackpad.

* Additional tech­ni­cal spec­i­fi­ca­tions — in­clud­ing the nano-tex­ture dis­play op­tion, con­fig­ure-to-or­der op­tions, and ac­ces­sories — are avail­able at ap­ple.com/​mac.

* With Apple Trade In, cus­tomers can trade in their cur­rent com­puter and get credit to­ward a new Mac. Customers can visit ap­ple.com/​shop/​trade-in to see what their de­vice is worth.

* Apple Intelligence is avail­able now as a free soft­ware up­date for Mac with M1 and later, and can be ac­cessed in most re­gions around the world when the de­vice and Siri lan­guage are set to U.S. English. The first set of fea­tures is in beta and avail­able with ma­cOS Sequoia 15.1, with more fea­tures rolling out in the months to come.

* Apple Intelligence is quickly adding sup­port for more lan­guages. In December, Apple Intelligence will add sup­port for lo­cal­ized English in Australia, Canada, Ireland, New Zealand, South Africa, and the U.K., and in April, a soft­ware up­date will de­liver ex­panded lan­guage sup­port, with more com­ing through­out the year. Chinese, English (India), English (Singapore), French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, and other lan­guages will be sup­ported.

* AppleCare+ for Mac pro­vides un­par­al­leled ser­vice and sup­port. This in­cludes un­lim­ited in­ci­dents of ac­ci­den­tal dam­age, bat­tery ser­vice cov­er­age, and 24/7 sup­port from the peo­ple who know Mac best.

* Every cus­tomer who buys di­rectly from Apple Retail gets ac­cess to Personal Setup. In these guided on­line ses­sions, a Specialist can walk them through setup, or fo­cus on fea­tures that help them make the most of their new de­vice. Customers can also learn more about get­ting started with their new de­vice with a Today at Apple ses­sion at their near­est Apple Store.

* Testing was con­ducted by Apple in September and October 2024. See ap­ple.com/​imac for more in­for­ma­tion.

* Actual di­ag­o­nal screen mea­sure­ment is 23.5 inches. Nano-texture dis­play is an op­tion on mod­els with 10-core CPU and 10-core GPU.

* All four USB-C ports sup­port Thunderbolt 4 on mod­els with 10-core CPU and 10-core GPU.

* Testing was con­ducted by Apple in October 2024 us­ing ship­ping com­pet­i­tive sys­tems and se­lect in­dus­try-stan­dard bench­marks.

* Results are com­pared to pre­vi­ous-gen­er­a­tion 24-inch iMac sys­tems with Apple M1, 8-core CPU, 8-core GPU, 16GB of RAM, and 2TB SSD.

* iMac with 8-core CPU and 8-core GPU can con­fig­ure to Magic Keyboard with Touch ID and Numeric Keypad, and iMac with 10-core CPU and 10-core GPU comes stan­dard with Touch ID.

* Available on Mac com­put­ers with Apple silicon and Intel-based Mac com­put­ers with a T2 Security Chip. Requires that the user’s iPhone and Mac are signed in with the same Apple Account us­ing two-fac­tor au­then­ti­ca­tion, their iPhone and Mac are near each other and have Bluetooth and Wi-Fi turned on, and their Mac is not us­ing AirPlay or Sidecar. Some iPhone fea­tures (e.g., cam­era and mi­cro­phone) are not com­pat­i­ble with iPhone Mir­ror­ing.

* Testing was con­ducted by Apple in August 2024. See ap­ple.com/​sa­fari for more in­for­ma­tion.

Testing was con­ducted by Apple in September and October 2024. See ap­ple.com/​imac for more in­for­ma­tion.

Actual di­ag­o­nal screen mea­sure­ment is 23.5 inches. Nano-texture dis­play is an op­tion on mod­els with 10-core CPU and 10-core GPU.

All four USB-C ports sup­port Thunderbolt 4 on mod­els with 10-core CPU and 10-core GPU.

Testing was con­ducted by Apple in October 2024 us­ing ship­ping com­pet­i­tive sys­tems and se­lect in­dus­try-stan­dard bench­marks.

Results are com­pared to pre­vi­ous-gen­er­a­tion 24-inch iMac sys­tems with Apple M1, 8-core CPU, 8-core GPU, 16GB of RAM, and 2TB SSD.

iMac with 8-core CPU and 8-core GPU can con­fig­ure to Magic Keyboard with Touch ID and Numeric Keypad, and iMac with 10-core CPU and 10-core GPU comes stan­dard with Touch ID.

Available on Mac com­put­ers with Apple silicon and Intel-based Mac com­put­ers with a T2 Security Chip. Requires that the user’s iPhone and Mac are signed in with the same Apple Account us­ing two-fac­tor au­then­ti­ca­tion, their iPhone and Mac are near each other and have Bluetooth and Wi-Fi turned on, and their Mac is not us­ing AirPlay or Sidecar. Some iPhone fea­tures (e.g., cam­era and mi­cro­phone) are not com­pat­i­ble with iPhone Mir­ror­ing.

Testing was con­ducted by Apple in August 2024. See ap­ple.com/​sa­fari for more in­for­ma­tion.

Dropshipping AliExpress watches, AI-generated SEO spam web­sites… mar­gin­ally le­gal and eth­i­cal pas­sive in­come schemes, that serve to gen­er­ate that in­come mostly for their pro­mot­ers, can feel like a mod­ern phe­nom­e­non. The promise of big money for lit­tle work is one of the fun­da­men­tal hu­man weak­nesses, though, and it has been ex­ploited by “business coaches” and “investment pro­mot­ers” for about as long as the con­cept of in­vesst­ment has ex­isted. We used to re­fer mostly to the “get rich quick” scheme, but fash­ions change with the time, and at the mo­ment “passive in­come” is the watch­word of busi­ness YouTubers and Instagram ad­ver­tis­ing.

And what in­come is more pas­sive than vend­ing ma­chine coin rev­enue? Automated vend­ing has had a bit of a re­nais­sance, with so­cial me­dia in­flu­encers buy­ing old ma­chines and turn­ing them into a busi­ness. The split of their rev­enue be­tween vend­ing ma­chine in­come and so­cial me­dia spon­sor­ship is ques­tion­able, but it’s def­i­nitely brought some younger eyes to an in­dus­try that is as rife with pas­sive in­come scams as your av­er­age spam folder. Perhaps it’s the en­force­ment ef­forts of the SEC, or per­haps to­day’s youth just need a lit­tle more time to ad­vance their art, but I haven’t so far seen a vend­ing ma­chine hus­tle quite as fi­nan­cial­ized as the post-di­vesti­ture pay­phone in­dus­try.

For much of the his­tory of the tele­phone sys­tem, pay­phones were owned and op­er­ated by tele­phone car­ri­ers. As with the broader tele­phone mo­nop­oly, there were tech­ni­cal rea­sons for this in­te­gra­tion. Payphones, more specif­i­cally called coin op­er­ated tele­phones, were “dumb” de­vices that re­lied on the tele­phone ex­change for con­trol. In the case of a man­ual ex­change, you would pick up a pay­phone and ask the op­er­a­tor for your party–-and they would ad­vise you of the price and tell you to in­sert coins. The coin ac­cep­tor in the pay­phone used a sim­ple elec­tri­cal sig­nal­ing scheme to no­tify the op­er­a­tor of which and how many coins you had in­serted, and it was up to the op­er­a­tor to check that it was cor­rect and con­nect the call. If coins needed to be re­turned af­ter the call, the op­er­a­tor would sig­nal the phone to do so.

With the in­tro­duc­tion of electro­mechan­i­cal and then dig­i­tal ex­changes, coin con­trol be­came au­to­mated, but pay­phones con­tin­ued to use spe­cial­ized sig­nal­ing schemes to com­mu­ni­cate with the coin con­trol sys­tem. They had to be con­nected to spe­cial loops, usu­ally called “coin lines,” with the equip­ment to re­ceive and send these sig­nals. The pay­phone it­self was a di­rect ex­ten­sion of the tele­phone sys­tem, un­der re­mote con­trol of the ex­change, much like later de­vices like line con­cen­tra­tors. It was only nat­ural that they would be op­er­ated by the same com­pany that op­er­ated the con­trol sys­tem they re­lied on.

Well, a lot of things have changed about the pay­phone in­dus­try. The 1968 Carterfone de­ci­sion rev­o­lu­tion­ized the tele­phone in­dus­try by al­low­ing the cus­tomer to con­nect their own de­vice. Coin op­er­ated tele­phones in the tra­di­tional sense were un­af­fected, but Carterfone opened the door to a whole new kind of pay­phone.

In 1970, bur­glar alarm man­u­fac­turer Robotguard blazed the trail into a new tele­phone busi­ness. They im­ported a Japanese pay­phone that was a lit­tle dif­fer­ent from the American mod­els of the time: it im­ple­mented coin pay­ment in­ter­nally. Robotguard con­nected the pay­phone through one of their bur­glar alarm au­to­di­alers, a de­vice that was al­ready fully com­pli­ant with tele­phone in­dus­try reg­u­la­tions, and then hooked it up to a Southwestern Bell tele­phone line in a de­part­ment store in in St. Louis. By in­sert­ing a dime, the phone was en­abled and you could make a lo­cal call (the au­to­di­aler was used, in part, to limit di­al­ing to 7 dig­its to en­sure that only lo­cal calls were made).

Robotguard had done their home­work, con­sult­ing the same law firm that rep­re­sented Carterfone in the 1968 case. They be­lieved the scheme to be le­gal, since the mod­i­fied Japanese pay­phone be­haved, to the tele­phone com­pany, just like any other cus­tomer-owned phone. The New York Times quotes Southwestern Bell, whose at­ti­tude is per­haps best de­scribed as res­ig­na­tion:

Spokesmen for the Southwestern Bell Telephone Company, the op­er­at­ing com­pany in that area, ac­knowl­edge that the equip­ment is in the store, that it is work­ing as de­scribed and that it ap­pears com­pletely le­gal. There is noth­ing they can do about it at this time, they say.

There was, in­deed, noth­ing that they could do about it. Robotguard had in­tro­duced the Customer-Owned Coin-Operated Telephone, or COCOT, to the United States. Payphones were now a com­pet­i­tive busi­ness.

Despite a cer­tain air of in­evitabil­ity, COCOTs had a slow start. First, there would in­deed be an ef­fort by tele­phone com­pa­nies to legally re­strict COCOTs. This was never en­tirely suc­cess­ful, but did re­sult in a set of state reg­u­la­tions (and to a lesser ex­tent, fed­eral reg­u­la­tions re­lated to long-dis­tance calls) that made the pay­phone busi­ness harder to get into. More im­por­tantly, though, the tech­ni­cal ca­pa­bil­i­ties of COCOTs were lim­ited. The Robotguard de­sign could charge only a fixed fee per call, which made it a prac­ti­cal ne­ces­sity to limit the pay­phone to lo­cal calls. Telephone com­pany pay­phones, which al­lowed long-dis­tance calls at a higher rate, had an ad­van­tage. Long-distance calls were also typ­i­cally billed by minute, which made it im­por­tant for a pay­phone to im­pose a time limit be­fore charg­ing more. These ca­pa­bil­i­ties were dif­fi­cult to im­ple­ment in a rea­son­ably com­pact, ro­bust de­vice in the 1970s.

A num­ber of ar­ti­cles will tell you that COCOTs be­came far more com­mon as a re­sult of pay­phone dereg­u­la­tion stem­ming from the 1984 breakup of AT&T. I would love to hear ev­i­dence to the con­trary, but from my re­search I be­lieve this is a mis­con­cep­tion, or at least not the en­tire story. In fact, pay­phones were dereg­u­lated by the Telecommunications Act of 1996, but that was done in large part be­cause COCOTs were al­ready com­mon and tele­phone com­pa­nies were un­happy that con­ven­tional pay­phones were sub­ject to rate reg­u­la­tion while COCOTs were not [1].

Divestiture did def­i­nitely open the flood­gates of COCOTs, al­though I think that the ad­vances in elec­tron­ics around that time were also a sig­nif­i­cant fac­tor in their pro­lif­er­a­tion. In any case, sev­eral man­u­fac­tur­ers in­tro­duced COCOTs in 1984 and 1985.

These later-gen­er­a­tion COCOTs were sig­nif­i­cantly more so­phis­ti­cated than the me­chan­i­cal sys­tem used by Robotguard. To the user, they were pretty much in­dis­tin­guish­able from car­rier-op­er­ated pay­phones, charg­ing vary­ing rates based on call du­ra­tion and lo­cal or long dis­tance. This lo­cal sim­u­la­tion of the tele­phone ex­change’s charg­ing de­ci­sions re­quired that each COCOT have, in in­ter­nal mem­ory, a pre­fix and rate table to de­ter­mine charges. Early ex­am­ples used ROM chips shipped by their man­u­fac­turer, but over time the in­dus­try shifted to re­mote pro­gram­ming via modems. These so­phis­ti­cated, elec­tron­i­cally-con­trolled coin op­er­ated phones that did not rely on an ex­change-pro­vided coin line came to be known as “smart pay­phones” and even, oc­ca­sion­ally, as “smartphones.”

Smart pay­phones greatly sim­pli­fied pay­phone op­er­a­tions and were even adopted by the es­tab­lished tele­phone com­pa­nies, where they could save money com­pared to the more com­plex ex­change-con­trolled sys­tem. But they also made COCOTs com­pletely prac­ti­cal, as good to the con­sumer as any other pay­phone. As COCOTs be­came re­motely pro­gram­ma­ble, the pay­phone busi­ness started to feel like a way to gen­er­ate–-dare I say it–-pas­sive in­come. All you had to do was col­lect the coins. Well, that and keep the phone in work­ing or­der, which would be­come a strug­gle for the thinly staffed and over­lever­aged Payphone Service Providers (PSPs) that would come to dom­i­nate the in­dus­try.

One of the new en­trants into the pay­phone busi­ness was a com­pany that spe­cial­ized in ex­actly the kind of re­mote man­age­ment these new smart pay­phones re­quired: Jaroth Inc., which would do busi­ness as Pacific Telemanagement Solutions or PTS. Today, PTS is the largest PSP in the United States, but that is­n’t say­ing a whole lot. They en­joyed great suc­cess in the 1990s, though, and were so well-po­si­tioned as a PSP in the ’00s that they of­ten pur­chased the ex­ist­ing pay­phone fleet from for­mer Bell Operating Companies that de­cided to aban­don the pay­phone busi­ness.

The 1990s were a good time for pay­phones, and they were also a good time for in­vest­ment scams. Loose en­force­ment of reg­u­la­tions around in­vest­ment of­fer­ings, the Dot Com Boom, and a gen­er­ally strong econ­omy cre­ated a lot of op­por­tu­ni­ties for “telecom en­tre­pre­neurs” that were more in­ter­ested in mov­ing money than in­for­ma­tion.

The prob­lem of 1990s telecom­mu­ni­ca­tions com­pa­nies funded in un­scrupu­lous ways is not at all unique to pay­phones, al­though it did reach a sort of apex there. I will take this op­por­tu­nity to go on a tan­gent, one of those things that I have al­ways wanted to write an ar­ti­cle about but have never quite had enough ma­te­r­ial for: MMDS, the Multichannel Multipoint Distribution Service.

MMDS was, es­sen­tially, ca­ble tele­vi­sion up­con­verted to a mi­crowave band and then put through di­rec­tional an­ten­nas. It was of­ten mar­keted as “Wireless Cable,” sort of an odd term, but it was in­tended as a di­rect com­peti­tor to con­ven­tional ca­ble tele­vi­sion. I think it’s fair to call it an an­ces­tor of what we now call WISPs, us­ing small roof-mounted par­a­bolic an­ten­nas as an al­ter­na­tive to costly CATV out­side plant. Some MMDS in­stal­la­tions lit­er­ally were early WISPs: MMDS could carry a mod­i­fied ver­sion of DOCSIS.

Wireless ca­ble got a pretty bad rap, though. If you pay at­ten­tion to WISPs, you will no doubt have no­ticed that while the low cap­i­tal in­vest­ment re­quired can en­able ben­e­fi­cial com­pe­ti­tion, it also en­ables a lot of com­pa­nies that you might call “fly by night.” Some start out with good in­ten­tions and just aren’t up to the task, while some come from “entrepreneurs” with a his­tory of fraud, but ei­ther way they end up col­lect­ing money and then dis­ap­pear­ing with it.

MMDS had a huge prob­lem with shady op­er­a­tors, and more of­ten of the “history of fraud” type. Supposed MMDS star­tups would take out tele­vi­sion and news­pa­per ads na­tion­wide of­fer­ing an in­cred­i­ble op­por­tu­nity to in­vest in this ex­cit­ing new in­dus­try. The scam took dif­fer­ent forms in the de­tails, but the most com­mon model was to sell “shares” of a new MMDS com­pany in the four-to-five-digit range. Investors were told that the com­pany was us­ing the cap­i­tal to build out their net­work and would shortly have hun­dreds of cus­tomers.

In prac­tice, most of these “MMDS star­tups” were in cities with pow­er­ful in­cum­bent ca­ble com­pa­nies and, even worse, pre­ex­ist­ing MMDS op­er­a­tors us­ing the lim­ited spec­trum avail­able for such a wide­band ser­vice. They never had any chance of get­ting a li­cense, and did­n’t have any­one with the ex­per­tise to ac­tu­ally build an MMDS sys­tem even if they got one. They just pock­eted the money and were next seen on a beach in Mexico or in prison, de­pend­ing on the whims of for­tune.

These wire­less ca­ble schemes be­came so com­mon, and so no­to­ri­ous, that if you asked a lot of peo­ple what wire­less ca­ble was the two an­swers you’d get are prob­a­bly “no idea” and “an old scam.”

It only takes a brief look at news­pa­per archives to find that the pay­phone in­dus­try was a lit­tle sketchy. There are con­stant, na­tion­wide, near-iden­ti­cal clas­si­fied ads with text like “buy and re­tire now” and “$150k yearly po­ten­tial” and “CALL NOW!”. Sometimes more than one ap­pear back to back, and they’re still nearly iden­ti­cal. None of these ads give a com­pany name or re­ally any­thing but a phone num­ber, and the phone num­bers re­peat so in­fre­quently that I sus­pect the ad­ver­tis­ers were in­ten­tion­ally ro­tat­ing them. This was pretty much the Craigslist “work from home” post of the era.

To un­der­stand pay­phone eco­nom­ics bet­ter, let’s talk a lit­tle about how the pay­phone busi­ness op­er­ated. Telephone com­pa­nies had long run pay­phones on the same pay­ment model, by find­ing a lo­ca­tion for the pay­phone (or be­ing con­tacted by the pro­pri­etor of a lo­ca­tion) and then of­fer­ing the lo­ca­tion a por­tion of rev­enue. In the case of in­cum­bent tel­cos, this was of­ten a fixed rate per call. So some­one owned the lo­ca­tion and the pay­phone op­er­a­tor paid them in the form of a roy­alty.

COCOTs en­abled a some­what more com­plex model. A COCOT might be lo­cated in a busi­ness, con­nected to a tele­phone com­pany line, and re­motely pro­grammed by a ser­vice provider, all of which were dif­fer­ent com­pa­nies from the per­son that ac­tu­ally col­lected the money. The rev­enue had to get split be­tween all of these par­ties some­how, but COCOTS weren’t reg­u­lated and that was all a mat­ter of ne­go­ti­a­tion.

Much like the vend­ing ma­chine in­dus­try to­day, one of the most dif­fi­cult parts of mak­ing money with a pay­phone was ac­tu­ally find­ing a good lo­ca­tion–-one that was­n’t al­ready taken by an­other op­er­a­tor. As more and more PSPs spread across the coun­try, this be­came more and more of a chal­lenge. So you can imag­ine the ap­peal of get­ting into the pay­phone hus­tle with­out hav­ing to do all that lo­ca­tion scout­ing and ne­go­ti­a­tion. Thus all the ads for pay­phone routes for sale… os­ten­si­bly a turnkey busi­ness, ready to go.

Ah, but peo­ple with turnkey, prof­itable busi­nesses don’t tend to sell them. Something is up.

Not all of these were out­right scams, or at least I as­sume some of them weren’t. There prob­a­bly were some PSPs that fi­nanced ex­pan­sion by sell­ing or leas­ing rights to some of their de­vices. But there were also a lot of… well, let’s talk about the sec­ond largest PSP of the late ’90s.

Somewhere around 1994, Charles Edwards of Atlanta, Georgia had an idea. His his­tory is ob­scure, but he seems to have been an ex­pe­ri­enced sales­man, per­haps in the in­sur­ance in­dus­try. He put his tal­ent for sales to work rais­ing cap­i­tal for ETS Payphones, Inc., which would place and op­er­ate pay­phones on the be­half of in­vestors.

The deal was some­thing like this: ETS iden­ti­fied lo­ca­tions for pay­phones and ne­go­ti­ated an agree­ment to place them. Then, they sold the pay­phone it­self, along with rights to the lo­ca­tion, to an in­vestor for five to seven thou­sand dol­lars a pop. ETS would then op­er­ate and main­tain the pay­phone while pay­ing a fixed monthly lease to the in­vestor who had pur­chased it–-some­thing like $83 a month.

It was a great deal for the in­vestors–-they did­n’t need any ex­per­tise or re­ally to do any work, since ETS arranged the lo­ca­tion, in­stalled the phones, and even col­lected the coins. In fact, most in­vestors pur­chased phones in cities far from where they lived, such was the con­ve­nience of the ETS model. There was vir­tu­ally no risk for in­vestors, ei­ther. ETS promised a monthly pay­ment up front, and the con­tract said that they would re­fund the in­vestor if the pay­phone did­n’t work out.

The ETS net­work was far larger than just Edwards could man­age. Most of the in­vest­ment deals were sold by in­de­pen­dent rep­re­sen­ta­tives, the ma­jor­ity of them in­sur­ance agents, who could pick it up as a side busi­ness to earn some com­mis­sion. Edwards sold nearly 50,000 pay­phones on this ba­sis, many of them in deals of over $100,000. Small-time in­vestors con­vinced of the value by their in­sur­ance agents, many of them re­tirees, put over $300 mil­lion into ETS from 1996 to 2000.

There was, as you might have guessed, a catch. One won­ders if the pay­phones were even real. I think that at least many of them were; ETS ran job list­ings for pay­phone tech­ni­cians in mul­ti­ple cities and oc­ca­sion­ally re­sponded to press in­quiries and com­plaints about mal­func­tion­ing pay­phones bear­ing their logo. Besides, the tele­com in­dus­try rec­og­nized ETS as a huge PSP in terms of both in­stalled base and call vol­ume.

What def­i­nitely was­n’t real was the rev­enue. ETS was a ponzi scheme. In 2000, the SEC went for Charles Edwards, show­ing that ETS had never been prof­itable. Edwards spon­sored a NASCAR team and di­rected mil­lions of dol­lars in salary and con­sult­ing fees to him­self, but in the first half of 2000 ETS lost $33 mil­lion. The monthly lease pay­ments to in­vestors were be­ing made from the cap­i­tal put in by newer in­vestors, and even that was dry­ing up.

SEC v. ETS went on for six years, in good part due to an ap­peal to the Supreme Court based on ETS’ the­ory that a con­tract that paid a fixed, rather than vari­able, monthly rate could not be con­sid­ered a se­cu­rity. In 2006, Charles Edwards was con­victed of 83 counts of wire fraud and sen­tenced to thir­teen years in prison.

Edwards was far from the only coin-op fraud­ster. ETS was not un­usual ex­cept in that it man­aged to be the largest. When a class-ac­tion firm and sev­eral state at­tor­neys gen­eral went af­ter ETS, their press re­leases al­most al­ways men­tioned a few other sim­i­lar pay­phone schemes fac­ing sim­i­lar le­gal chal­lenges. Remember all of those clas­si­fied ads? I sus­pect some of them were ETS, but ETS also had a more so­phis­ti­cated sales op­er­a­tion than two-line clas­si­fieds. Most of them were prob­a­bly from com­peti­tors.

The pay­phone in­dus­try crashed along­side ETS; ETS al­most cer­tainly would have col­lapsed (albeit likely more slowly) even if it had been above board. Increasing cell­phone own­er­ship from the ’90s to ’00s made pay­phones largely ob­so­lete, and more and more es­tab­lished tel­cos and PSPs de­cided to drop them. One of the rea­sons for PTS’s as­cent was its will­ing­ness to buy out op­er­a­tors who wanted out: in 2008, PTS bought most of AT&T’s fleet. In 2011, they bought most of Verizon’s fleet. Almost every in­cum­bent tele­phone com­pany got out of the pay­phone busi­ness and most of them sold to PTS.

Given all that, you might think that pay­phone scams were only a thing of the ’90s. And they mostly were, but you can imag­ine that there was an op­por­tu­nity for any­one who could adapt the ETS model to the in­ter­net age.

Pantheon Holdings did just that. It’s even more dif­fi­cult to un­tan­gle the early days of Pantheon than it is ETS. Pantheon op­er­ated through a va­ri­ety of shell com­pa­nies and brands, but “the Internet Machine Company” was per­haps the most to the point. Around 2005, Pantheon built “internet kiosks” where cus­tomers could check their email, print doc­u­ments, and even make phone calls for a nom­i­nal cash or credit card pay­ment. Sometimes called “global busi­ness cen­ters,” these kiosks were pre­sented as an ex­cit­ing busi­ness op­por­tu­nity to mostly el­derly in­vestors who were given the op­por­tu­nity to buy one for just $18,000.

Once again, the kiosks were real, but the rev­enue was not. Pantheon placed the ma­chines in low-traf­fic lo­ca­tions and did noth­ing to mar­ket them. By 2009, more than a dozen peo­ple had been con­victed of fraud in re­la­tion to the Internet Machines.

Pantheon kiosks still turn up on the junk mar­ket.

[1] I spent quite a bit of time re­search­ing the his­tory of pay­phone reg­u­la­tion to try to un­der­stand ex­actly what did change in 1984, how many COCOTs op­er­ated and on what le­gal ba­sis from 1970-1984, etc. I did not have much suc­cess. What I can tell is that COCOTs were very rare prior to 1984 (so rare that the FCC ap­par­ently did­n’t know of any, ac­cord­ing to a 1984 memo, de­spite the 1970 ex­am­ple), and by the late ’80s were very com­mon. The FCC seems to have taken the view, in 1984, that COCOTs had al­ways been le­gal, and just weren’t be­ing made or used on any sig­nif­i­cant scale. That’s some­what in­con­sis­tent, though, with the fact that sud­denly af­ter 1984 di­vesti­ture a bunch of com­pa­nies started mak­ing COCOTs for the first time. My best guess right now is that from 1970-1984 COCOTs were prob­a­bly le­gal but were some­thing of a gray area be­cause of the lack of any reg­u­la­tions specif­i­cally ap­ply­ing to them. Some com­bi­na­tion of di­vesti­ture broadly “shaking up” the phone in­dus­try, elec­tron­ics mak­ing COCOTs much more fea­si­ble, and who knows what else lead mul­ti­ple com­pa­nies to get into the COCOT busi­ness in the mid-’80s. That lead the FCC to is­sue a se­ries of reg­u­la­tory opin­ions on COCOTs that con­sis­tently up­held them as le­gal, cul­mi­nat­ing in the 1996 act drop­ping pay­phone reg­u­la­tion en­tirely.

sin­cerely,

j. b. craw­ford

me@com­puter.rip

Support me on Ko-Fi and re­ceive EYES ONLY, a monthly or more spe­cial edi­tion.

Discuss this, com­plain, etc: #computer.rip:waffle.tech on Matrix

Me, else­where: Mastodon, Pixelfed, YouTube

This web­site is be­grudg­ingly gen­er­ated by the use of soft­ware. Letters to the

ed­i­tor are wel­come via fac­sim­ile to +1 (505) 926-5492 or mail to PO Box 26924,

Albuquerque, NM 87125.

A re­turn to hand-writ­ten notes by learn­ing to read & write

We pre­sent a model to con­vert pho­tos of hand­writ­ing into a dig­i­tal for­mat that re­pro­duces com­po­nent pen strokes, with­out the need for spe­cial­ized equip­ment.

Digital note-tak­ing is gain­ing pop­u­lar­ity, of­fer­ing a durable, ed­itable, and eas­ily in­dex­able way of stor­ing notes in a vec­tor­ized form. However, a sub­stan­tial gap re­mains be­tween dig­i­tal note-tak­ing and tra­di­tional pen-and-pa­per note-tak­ing, a prac­tice still fa­vored by a ma­jor­ity of peo­ple. Bridging this gap by con­vert­ing a note tak­er’s phys­i­cal writ­ing into a dig­i­tal form is a process called deren­der­ing. The re­sult is a se­quence of strokes, or tra­jec­to­ries of a writ­ing in­stru­ment like a pen or fin­ger, recorded as points and stored dig­i­tally. This is also known as an “online” rep­re­sen­ta­tion of writ­ing, or “digital ink”.The con­ver­sion to dig­i­tal ink of­fers users who still pre­fer tra­di­tional hand­writ­ten notes ac­cess to their notes in a dig­i­tal form. Instead of sim­ply us­ing op­ti­cal char­ac­ter recog­ni­tion (OCR), which would al­low the writ­ing to be tran­scribed to a text doc­u­ment, by cap­tur­ing the hand­writ­ten doc­u­ments as a col­lec­tion of strokes, it’s pos­si­ble to re­pro­duce them in a form that can be edited freely by hand in a way that is more nat­ural. It al­lows the user to cre­ate doc­u­ments with a re­al­is­tic look that cap­tures their hand­writ­ing style, rather than sim­ply a col­lec­tion of text. This rep­re­sen­ta­tion al­lows the user to later in­spect, mod­ify or com­plete their hand­writ­ten notes, which gives their notes en­hanced dura­bil­ity, seam­less or­ga­ni­za­tion and in­te­gra­tion with other dig­i­tal con­tent (images, text, links) or dig­i­tal as­sis­tance.For these rea­sons, this field has gained sig­nif­i­cant in­ter­est in both acad­e­mia and in­dus­try, with soft­ware so­lu­tions that dig­i­tize hand­writ­ing and hard­ware so­lu­tions that lever­age smart pens or spe­cial pa­per for cap­ture. The need for ad­di­tional hard­ware and ac­com­pa­ny­ing soft­ware stack is, how­ever, an ob­sta­cle for wider adop­tion, as it cre­ates both on­board­ing fric­tion and car­ries ad­di­tional ex­pense for the user.With this in mind, in “InkSight: Offline-to-Online Handwriting Conversion by Learning to Read and Write”, we pro­pose an ap­proach to deren­der­ing that can take a pic­ture of a hand­writ­ten note and ex­tract the strokes that gen­er­ated the writ­ing with­out the need for spe­cial­ized equip­ment. We also re­move the re­liance on typ­i­cal geo­met­ric con­structs, where gra­di­ents, con­tours, and shapes in an im­age are uti­lized to ex­tract writ­ing strokes. Instead, we train the model to build an un­der­stand­ing of “reading”, so it can rec­og­nize writ­ten words, and “writing”, so it can out­put strokes that re­sem­ble hand­writ­ing. This re­sults in a more ro­bust model that per­forms well across di­verse sce­nar­ios and ap­pear­ances, in­clud­ing chal­leng­ing light­ing con­di­tions, oc­clu­sions, etc. You can ac­cess the model and the in­fer­ence code on our GitHub repo.

The key goal of this ap­proach is to cap­ture the stroke-level tra­jec­tory de­tails of hand­writ­ing. The user can then store the re­sult­ing strokes in the note tak­ing app of their choice.

Left: Offline hand­writ­ing. Right: Output dig­i­tal ink (online hand­writ­ing). In every word, char­ac­ter col­ors tran­si­tion from red to pur­ple, fol­low­ing the rain­bow se­quence, ROYGBIV. Within each stroke, the shade pro­gresses from darker to lighter.

Under the hood, we ap­ply an off the shelf OCR model to iden­tify hand­writ­ten words, then use the model to con­vert them to strokes. To fos­ter re­pro­ducibil­ity, reusabil­ity, and ease of adop­tion, we com­bine the widely pop­u­lar and read­ily avail­able ViT en­coder with an mT5 en­coder-de­coder.

While the fun­da­men­tal con­cept of deren­der­ing ap­pears straight­for­ward — train­ing a model that gen­er­ates dig­i­tal ink rep­re­sen­ta­tions from in­put im­ages — the prac­ti­cal im­ple­men­ta­tion for ar­bi­trary in­put im­ages pre­sents two sig­nif­i­cant chal­lenges:Lim­ited Supervised Data: Acquiring paired data with cor­re­spond­ing im­ages and ground truth dig­i­tal ink for su­per­vised train­ing can be ex­pen­sive and time-con­sum­ing. To our knowl­edge, no datasets with suf­fi­cient va­ri­ety ex­ist for this task.Scal­a­bil­ity to large im­ages: The model must ef­fec­tively han­dle ar­bi­trar­ily large in­put im­ages with vary­ing res­o­lu­tions and amount of con­tent.

To ad­dress the first prob­lem while avoid­ing oner­ous data col­lec­tion, we pro­pose a multi-task train­ing setup that com­bines recog­ni­tion and deren­der­ing tasks. This en­ables the model to gen­er­al­ize on deren­der­ing tasks with var­i­ous styles of im­ages as in­put, and in­jects the model with both se­man­tic un­der­stand­ing and knowl­edge of the me­chan­ics of writ­ing hand­writ­ten text.This ap­proach thus dif­fers from meth­ods that rely on geo­met­ric con­structs, where gra­di­ents, con­tours, and shapes in an im­age are uti­lized to ex­tract writ­ing strokes. Learning to read en­hances the mod­el’s ca­pa­bil­ity in pre­cisely lo­cat­ing and ex­tract­ing tex­tual el­e­ments from the im­ages. Learning to write en­sures that the re­sult­ing vec­tor rep­re­sen­ta­tion, the dig­i­tal ink, closely aligns with the typ­i­cal hu­man ap­proach of writ­ing in terms of phys­i­cal dy­nam­ics and the or­der of strokes. Combined, these al­low us to train a model in the ab­sence of large amounts of paired sam­ples, which are dif­fi­cult to ob­tain.

One so­lu­tion to the prob­lem of scal­a­bil­ity is to train a model with very high-res­o­lu­tion in­put im­ages and very long out­put se­quences. However, this is com­pu­ta­tion­ally pro­hib­i­tive. Instead, we break down the deren­der­ing of a page of notes into three steps: (1) OCR to ex­tract word-level bound­ing boxes, (2) deren­der­ing each of the words sep­a­rately, and (3) re­plac­ing the of­fline (pixel) rep­re­sen­ta­tion of the words with the deren­dered strokes us­ing the color cod­ing de­scribed above to im­prove vi­su­al­iza­tion.To nar­row the do­main gap be­tween the syn­thetic im­ages of ren­dered inks and the real pho­tos, we aug­ment the data in tasks that take ren­dered ink as in­put. Data aug­men­ta­tion is done by ran­dom­iz­ing the ink an­gle, color, stroke width, and by adding Gaussian noise and clut­tered back­grounds.

We cre­ate a train­ing mix­ture that com­prises five dif­fer­ent task types. The first two tasks are deren­der­ing tasks (i.e., they gen­er­ate a dig­i­tal ink out­put). One uses only an im­age as in­put and the other uses both an im­age and the ac­com­pa­ny­ing text that has been rec­og­nized by the OCR model. The fol­low­ing two tasks are recog­ni­tion tasks that pro­duce text out­put, the first of which lever­ages real im­ages and the lat­ter, syn­thetic ones. Finally, a fifth task is a com­bi­na­tion of recog­ni­tion and deren­der­ing, hence a mixed task with text-and-ink out­put.Each type of task uti­lizes a task-spe­cific in­put text, en­abling the model to dis­tin­guish be­tween tasks dur­ing both train­ing and in­fer­ence. Below you will find a recog­ni­tion and a deren­der­ing task.

Derendering with text: Takes an im­age and a text in­put and out­puts the ink that would gen­er­ate that text in the style of the im­age.

Recognition of syn­thetic im­ages: Takes an im­age and rec­og­nizes what is writ­ten within.

To train the sys­tem, we pair im­ages of text and cor­re­spond­ing dig­i­tal ink. The dig­i­tal ink is sam­pled from real-time writ­ing tra­jec­to­ries and sub­se­quently rep­re­sented as a se­quence of strokes. Each stroke is rep­re­sented by a se­quence of points, ob­tained by sam­pling from the writ­ing or draw­ing tra­jec­tory at a con­stant rate (e.g., 50 points per sec­ond). The cor­re­spond­ing im­age is cre­ated by ren­der­ing the ink - cre­at­ing a bitmap at a pre­spec­i­fied res­o­lu­tion. This cre­ates a pixel-stroke cor­re­spon­dence, that is a pre­cur­sor for the model in­put-out­put pairs.

A fur­ther nec­es­sary step, and a unique one for this modal­ity, is the ink to­k­enizer, which rep­re­sents the points in a for­mat that is friendly to a large lan­guage model (LLM). Each point is con­verted into two to­kens, one each en­cod­ing its x and y co­or­di­nates. The to­ken se­quence for this ink be­gins with b, sig­ni­fy­ing the be­gin­ning of the stroke, fol­lowed by the to­kens for the co­or­di­nates of the sam­pled points.

Illustration of the ink to­k­eniza­tion for a sin­gle-stroke ink. The dark red ink de­picts the ink stroke, with num­bered cir­cles mark­ing sam­pled points af­ter time re­sam­pling. The color gra­di­ent of the sam­pled points (1–7) in­di­cates the point or­der. Each point is rep­re­sented with two to­kens en­cod­ing its co­or­di­nates x (left half of the shaded box) and y (right half). The to­ken se­quence for this ink be­gins with b, sig­ni­fy­ing the be­gin­ning of the stroke, fol­lowed by the to­kens for co­or­di­nates of sam­pled points.

To eval­u­ate the per­for­mance of our ap­proach, we first col­lected an eval­u­a­tion dataset. We started with OCR data, and then added paired sam­ples that we col­lected man­u­ally by ask­ing peo­ple to trace text im­ages they were shown (human-generated traces).We then trained three vari­ants of the model: Small-p (∼340M pa­ra­me­ters, “-p” for “public” setup), Small-i (“-i” for “in-house”), and Large-i (∼1B pa­ra­me­ters). We com­pared our ap­proach to a General Virtual Sketching (GVS) base­line.We show that the vec­tor rep­re­sen­ta­tions pro­duced by our sys­tem are both se­man­ti­cally and geo­met­ri­cally sim­i­lar to the in­put im­ages, and are sim­i­lar to hu­man-gen­er­ated dig­i­tal ink data, as mea­sured by both au­to­matic and hu­man eval­u­a­tions.

We show the per­for­mance of our mod­els and GVS com­pared to two pub­lic eval­u­a­tion datasets, IAM and IMGUR5K, and an out of do­main dataset of sketches. Our mod­els mostly pro­duce re­sults that ac­cu­rately re­flect the text con­tent, dis­re­gard­ing se­man­ti­cally ir­rel­e­vant back­ground. They can also han­dle oc­clu­sions, high­light­ing the ben­e­fit of the learned read­ing prior. In con­trast, GVS pro­duces mul­ti­ple du­pli­cate strokes and has dif­fi­culty dis­tin­guish­ing be­tween back­ground and fore­ground. Our Large-i model is fur­ther able to re­tain more de­tails and ac­com­mo­date more di­verse im­age styles. See the pa­per for more ex­am­ples.

Comparison be­tween per­for­mance of GVS, Small-i, Small-p, and Large-i on two pub­lic eval­u­a­tion datasets (Rows 1–3, IAM; rows 4–6, IMGUR5K).

Out-of-domain be­hav­ior: Sketch deren­der­ing for Small-p, Small-i, Large-i and GVS. Our mod­els are mostly able to deren­der sim­ple sketches, how­ever they do still ex­hibit sig­nif­i­cant ar­ti­facts like ex­tra­ne­ous or mis­aligned strokes.

At pre­sent, the field has not es­tab­lished met­rics or bench­marks for quan­ti­ta­tive eval­u­a­tion of this task. So, we con­duct both hu­man and au­to­mated eval­u­a­tion to com­pare the sim­i­lar­ity of our model out­put to the orig­i­nal im­age and to hu­man-gen­er­ated dig­i­tal inks.Here we pre­sent the hu­man eval­u­a­tion re­sults, with nu­mer­ous other re­sults de­rived from au­to­mated eval­u­a­tions and an ab­la­tion study in our pa­per. We per­formed a hu­man eval­u­a­tion of the qual­ity of the deren­dered inks pro­duced by the three model vari­ants. We used the “golden” hu­man traced data from the HierText dataset as the con­trol group and the out­put of our model on these sam­ples as the ex­per­i­men­tal group.

Comparison of the per­for­mance of our mod­els (Small-p, Small-i and Large-i) and man­ual trac­ing on two sam­ples of text of vary­ing dif­fi­culty from the HierText dataset.

In the fig­ure above, no­tice the er­ror in the quote for all mod­els on the top row (the dou­ble-quote mark), which the hu­man trac­ing got cor­rect. On the bot­tom row the sit­u­a­tion is re­versed, with the hu­man trac­ing fo­cus­ing solely on the main word, miss­ing most other el­e­ments. The hu­man trac­ing is also not per­fectly aligned with the un­der­ly­ing im­age, em­pha­siz­ing the com­plex­ity and trac­ing dif­fi­culty of the hand­writ­ten parts of the HierText dataset.Eval­u­a­tors were shown the orig­i­nal im­age along­side a ren­dered dig­i­tal ink sam­ple, which was ei­ther model-gen­er­ated or hu­man-traced (unknown to the eval­u­a­tors). They were asked to an­swer two ques­tions: (1) Is the dig­i­tal ink out­put a rea­son­able trac­ing of the in­put im­age? (Answers: “Yes, it’s a good trac­ing,” “It’s an okay trac­ing, but has some small er­rors,” “It’s a bad trac­ing, has some ma­jor ar­ti­facts.”) (2) Could this dig­i­tal ink out­put have been pro­duced by a hu­man? (Answers: “Yes” or “No”.) The eval­u­a­tion in­cluded 16 in­di­vid­u­als fa­mil­iar with dig­i­tal ink, but not in­volved in this re­search. Each sam­ple was eval­u­ated by three raters and ag­gre­gated with ma­jor­ity vot­ing.

The re­sults show that a ma­jor­ity of deren­dered inks, gen­er­ated with the Large-i model per­form about as well as hu­man-gen­er­ated ones. Moreover 87% of the Large-i out­puts are marked as good or hav­ing only small er­rors.

In this work we pre­sent a first-of-its-kind ap­proach to con­vert pho­tos of hand­writ­ing into dig­i­tal ink. We pro­pose a train­ing setup that works with­out paired train­ing data. We show that our method is ro­bust to a va­ri­ety of in­puts, can work on full hand­writ­ten notes, and gen­er­al­izes to out-of-do­main sketches to some ex­tent. Furthermore, our ap­proach does not re­quire com­plex mod­el­ing and can be con­structed from stan­dard build­ing blocks.

We want to thank all the au­thors of this work, Arina Rak, Julian Schnitzler, and Chengkun Li, who formed a stu­dent team work­ing with Google Research for the du­ra­tion of the pro­ject, as well as Claudiu Musat, Henry Rowley and Jesse Berent. All au­thors, with the ex­cep­tion of the stu­dent team, are now part of Google Deepmind.

In this ar­ti­cle I’ll dis­cuss dif­fer­ent strate­gies for in­cre­men­tally adding Rust into a server writ­ten in an­other lan­guage, such as JavaScript, Python, Java, Go, PHP, Ruby, etc. The main rea­son why you’d want to do this is be­cause you’ve pro­filed your server, iden­ti­fied a hot func­tion which is not meet­ing your per­for­mance re­quire­ments be­cause it’s bot­tle­necked by the CPU, and the usual tech­niques of mem­o­iz­ing the func­tion or im­prov­ing its al­go­rithm would­n’t be fea­si­ble or ef­fec­tive in this sit­u­a­tion for what­ever rea­son. You have come to the con­clu­sion that it would be worth in­ves­ti­gat­ing swap­ping out the func­tion im­ple­men­ta­tion for some­thing writ­ten in a more CPU-efficient lan­guage, like Rust. Great, then this is def­i­nitely the ar­ti­cle for you.

The strate­gies are or­dered in tiers, where “tier” is short for “tier of Rust adop­tion.” The first tier would be not us­ing Rust at all. The last tier would be rewrit­ing the en­tire server in Rust.

The ex­am­ple server which we’ll be ap­ply­ing and bench­mark­ing the strate­gies on will be im­ple­mented in JS, run­ning on the Node.js run­time. The strate­gies can be gen­er­al­ized to any other lan­guage or run­time though.

Let’s say we have a Node.js server with an HTTP end­point that takes a string of text as a query pa­ra­me­ter and re­turns a 200px by 200px PNG im­age of the text en­coded as a QR code.

Here’s what the server code would look like:

const ex­press = re­quire(‘ex­press’);

const gen­er­ate­Qr­Code = re­quire(‘./​gen­er­ate-qr.js’);

const app = ex­press();

app.get(‘/​qr­code’, async (req, res) => {

const { text } = req.query;

if (!text) {

re­turn res.sta­tus(400).send(‘miss­ing “text” query param’);

if (text.length > 512) {

re­turn res.sta­tus(400).send(’text must be

And here’s what the hot func­tion would look like:

const QRCode = re­quire(‘qr­code’);

* @param {string} text - text to en­code

* @returns {Promise

We can hit that end­point by call­ing:

Which will cor­rectly pro­duce this QR code PNG:

Anyway, let’s throw tens of thou­sands of re­quests at this server for 30 sec­onds and see how it per­forms:

Since I haven’t de­scribed my bench­mark­ing method­ol­ogy these re­sults are mean­ing­less on their own, we can’t say whether this is “good” or “bad” per­for­mance. That’s okay, since we don’t care about the ab­solute num­bers, we’re go­ing to use these re­sults as a base­line to com­pare all of the fol­low­ing im­ple­men­ta­tions against. Every server is tested in the same en­vi­ron­ment so rel­a­tive com­par­isons will be ac­cu­rate.

Regarding the ab­nor­mally high mem­ory us­age, it’s be­cause I’m run­ning Node.js in “cluster mode”, which spawns 12 processes for each of the 12 CPU cores on my test ma­chine, and each process is a stand­alone Node.js in­stance which is why it takes up 1300+ MB of mem­ory even though we have a very sim­ple server. JS is sin­gle-threaded so this is what we have to do if we want a Node.js server to make full use of a multi-core CPU.

For this strat­egy we rewrite the hot func­tion in Rust, com­pile it as a stand­alone CLI tool, and then call it from our host server.

Let’s start by rewrit­ing the func­tion in Rust:

/** qr_lib/​lib.rs **/

use qr­code::{Qr­Code, EcLevel};

use im­age::Luma;

use im­age::codecs::png::{Com­pres­sion­Type, FilterType, PngEncoder};

pub type StdErr = Box

/** qr_­cli/​main.rs **/

use std::{env, process};

use std::io::{self, BufWriter, Write};

use qr_lib::StdErr;

fn main() -> Result

We can use this CLI like so:

qr-cli https://​youtu.be/​cE0wfjsy­bIQ?t=74 > crab-rave.png

Now let’s up­date the hot func­tion in our host server to call this CLI:

const { spawn } = re­quire(‘child_process’);

const path = re­quire(‘path’);

const qr­Cli­Path = path.re­solve(__dirname, ‘./qr-cli’);

* @param {string} text - text to en­code

* @returns {Promise

Now let’s see how this change af­fected per­for­mance:

Wow, I was not ex­pect­ing through­put to in­crease by 76%! This is a very cave­man-brain strat­egy so it’s funny to see that it was that ef­fec­tive. Average re­sponse size also halved from 1506 bytes to 778 bytes, the com­pres­sion algo in the Rust li­brary must be bet­ter than the one in the JS li­brary. We’re serv­ing sig­nif­i­cantly more re­quests per sec­ond and re­turn­ing sig­nif­i­cantly smaller re­sponses, so I’d say this is a great re­sult.

For this strat­egy we’ll com­pile the Rust func­tion into a Wasm mod­ule, and then load and run it from the host server us­ing a Wasm run­time. Some links to Wasm run­times across dif­fer­ent lan­guages:

Since we’re in­te­grat­ing into a Node.js server let’s use wasm-bind­gen to gen­er­ate the glue code that our Rust Wasm code and our JS code will use to in­ter­act with each other.

/** qr_was­m_bind­gen/​lib.rs **/

use was­m_bind­gen::pre­lude::*;

#[wasm_bindgen(js_name = gen­er­ate­Qr­Code)]

pub fn gen­er­ate_qr_­code(text: &str) -> Result

After com­pil­ing that code us­ing wasm-pack, we can copy the built as­sets over to our Node.js server and use them in the hot func­tion like this:

const wasm = re­quire(‘./​qr_was­m_bind­gen.js’);

* @param {string} text - text to en­code

* @returns {Buffer} - QR code

mod­ule.ex­ports = func­tion gen­er­ate­Qr­Code(text) {

re­turn Buffer.from(wasm.generateQrCode(text));

Using Wasm dou­bled our through­put com­pared to the base­line! However the jump in per­for­mance com­pared to the ear­lier cave­man-brain strat­egy of call­ing a CLI tool is smaller than I would have ex­pected.

Anyway, while wasm-bind­gen is an ex­cel­lent JS to Rust Wasm bind­ing gen­er­a­tor there’s no equiv­a­lent of it for other lan­guages such as Python, Java, Go, PHP, Ruby, etc. I don’t want to leave those folks out to dry, so I’ll ex­plain how to write the bind­ings by hand. Disclaimer: the code is go­ing to get ugly, so un­less you’re re­ally in­ter­ested in see­ing how the sausage is made you can just skip over the next sec­tion.

The funny thing about Wasm is that it only sup­ports four data types: i32, i64, f32, and f64. Yet for our use-case we need to pass a string from the host to a Wasm func­tion, and the Wasm func­tion needs to re­turn an ar­ray to the host. Wasm does­n’t have strings or ar­rays. So how are we sup­posed to solve this prob­lem?

The an­swer hinges on hav­ing a cou­ple in­sights:

* The Wasm mod­ule’s mem­ory is shared be­tween the Wasm in­stance and the host, both can read and mod­ify it.

* A Wasm mod­ule can only re­quest up to 4GB of mem­ory, so every pos­si­ble mem­ory ad­dress can be en­coded as an i32, so this data type is also used as a mem­ory ad­dress pointer.

If we want to pass a string from the host to a Wasm func­tion the host has to di­rectly write the string into the Wasm mod­ule’s mem­ory, and then pass two i32s to the Wasm func­tion: one point­ing to the string’s mem­ory ad­dress and an­other spec­i­fy­ing the string’s byte length.

And if we want to pass an ar­ray from a Wasm func­tion to the host, the host first needs to pro­vide the Wasm func­tion an i32 point­ing to the mem­ory ad­dress where the ar­ray should be writ­ten, and then when the Wasm func­tion com­pletes it re­turns an i32 which rep­re­sents the num­ber of bytes that were writ­ten.

However, now we have a new prob­lem: when the host writes to the Wasm mod­ule’s mem­ory, how can it en­sure it does­n’t over­write mem­ory that the Wasm mod­ule is us­ing? For the host to be able to safely write to mem­ory, it must first ask the Wasm mod­ule to al­lo­cate space for it.

Okay, now with all of that con­text out of the way we can fi­nally look at this code and ac­tu­ally un­der­stand it:

/** qr_wasm/​lib.rs **/

use std::{al­loc::Lay­out, mem, slice, str};

// host calls this func­tion to al­lo­cate space where

// it can safely write data to

#[no_mangle]

pub un­safe ex­tern “C” fn al­loc(size: usize) -> *mut u8 {

let lay­out = Layout::from_size_align_unchecked(

size * mem::size_of::

After com­pil­ing this Wasm mod­ule here’s how we’d use it from JS:

const path = re­quire(‘path’);

const fs = re­quire(‘fs’);

// fetch Wasm file

const qr­Wasm­Path = path.re­solve(__dirname, ‘./qr_wasm.wasm’);

const qr­Wasm­Bi­nary = fs.read­File­Sync(qr­Wasm­Path);

// in­stan­ti­ate Wasm mod­ule

const qr­Was­m­Mod­ule = new WebAssembly.Module(qrWasmBinary);

const qr­Was­mIn­stance = new WebAssembly.Instance(

qr­Was­m­Mod­ule,

// JS strings are UTF16, but we need to re-en­code them

// as UTF8 be­fore pass­ing them to our Wasm mod­ule

const tex­tEn­coder = new TextEncoder();

// tell Wasm mod­ule to al­lo­cate two buffers for us:

// - 1st buffer: an in­put buffer which we’ll

// write UTF8 strings into that

// the gen­er­ate­Qr­Code func­tion

// will read

// - 2nd buffer: an out­put buffer that the

// gen­er­ate­Qr­Code func­tion will

// write QR code PNG bytes into

// and that we’ll read

const textMemLen = 1024;

const textMem­Off­set = qr­Was­mIn­stance.ex­ports.al­loc(textMemLen);

const out­put­MemLen = 4096;

This has been a hard post for me to write af­ter par­tic­i­pat­ing in WordPress since be­fore I even started a ca­reer in tech and, un­til 3 months ago, for my en­tire tech ca­reer. That said, it has been in the mak­ing for quite a while now and it is time that I make it of­fi­cial.

I’ve of­fi­cially left the WordPress pro­ject af­ter 14+ years of con­tribut­ing in­clud­ing:

* Over 11 years as mostly the sole mod­er­a­tor for the of­fi­cial WordPress jobs site

It’s true that I had largely been mov­ing away from the WordPress pro­ject since at least 2017. I think that is when I re­al­ized just how dis­hon­est so much of the “community” around WordPress re­ally is.

I’ve watched peo­ple pour their lives into giv­ing back only to have it all tossed out be­cause their im­por­tant work is­n’t what Matt wanted peo­ple to fo­cus on.

I’ve watched good peo­ple try to make the com­mu­nity stronger and pro­tect users by con­tribut­ing to pri­vacy, ac­ces­si­bil­ity, gov­er­nance and so many more vi­tal ar­eas only to, not only have their con­tri­bu­tions ig­nored, but to see the con­trib­u­tors them­selves abused and pushed out of the com­mu­nity en­tirely for their ba­sic ad­vo­cacy.

I’ve watched WordPress com­pany af­ter WordPress com­pany claim to be “better” in how it treats its peo­ple. The truth is nearly all of them used WordPress’ virtues as an ex­cuse to un­der pay peo­ple and abuse them. From some of the most re­spected prod­uct com­pa­nies to some of the most promi­nent agen­cies I’ve watched them chew up good peo­ple with threats that they “aren’t good enough to leave” and sim­i­lar to con­tinue to jus­tify low pay and ben­e­fits.

I’ve watched a full cult form around Automattic, the com­pany be­hind word­press.com. In 2014 I even ap­plied to work there but by that point I was al­ready at a stage where I did­n’t trust the org due to abuse I had seen a friend go through. I con­fess I took the paid trial but I in­ten­tion­ally did not take it se­ri­ously and I ac­cepted an­other role be­fore the trial started. All that is to say, Automattic was never hon­est about who it is so I re­ally did­n’t feel too bad at the time about go­ing through such mo­tions. They had the chance to change my mind then but that not only did­n’t hap­pen but the whole ex­pe­ri­ence in­stead low­ered my re­spect for the org even fur­ther.

The list goes on and on but WordPress was never an hon­est com­mu­nity, yet I stayed, for far too long.

I joined WP Engine in 2018 be­cause it was the one com­pany that re­ally did seem to be hon­est about who they were. Like every other com­pany they were in it to make money, but un­like every other com­pany they did­n’t hide that fact be­hind abu­sive lan­guage. They did­n’t claim I was “family.” They did­n’t claim their work was vir­tu­ous and there­fore some­how “better” than non-Word­Press orgs. No, they said they wanted to be the biggest host and went af­ter that with the best pay I saw in the WordPress ecosys­tem and in­ter­est­ing work on top of it.

I left WP Engine in July of this year for a lot of rea­sons, but I don’t re­gret why I joined them. I stand by the fact that they were the most hon­est com­pany in WordPress, an ecosys­tem where hon­esty is of­ten harder to come by than in any other I’ve worked in.

So that brings us to the cur­rent WordPress im­plo­sion. There are plenty of folks writ­ing the time­line of events of what is go­ing on. That is­n’t why I’m writ­ing this post. That said, up un­til September I was hap­pily still work­ing on Kana, my WordPress de­vel­op­ment en­vi­ron­ment, and ex­plor­ing a few plu­gin ideas I’ve had, even if WordPress is­n’t the best tool for blog­ging any­more.

The ut­ter hypocrisy of Matt Mullenweg’s ac­tions is­n’t re­ally un­sur­pris­ing to any­one who has watched Automattic for the last decade or more but it is my fi­nal straw. Yes, I should’ve left ear­lier when I saw friends hurt. Somehow I guess I al­ways thought my ac­tions would some­how help the sit­u­a­tion. It was a naive po­si­tion, I now re­al­ize.

I won’t say WP Engine is blame­less in the wider world of WordPress and open source, I did­n’t leave there on a whim af­ter all. The na­ture of the at­tack on them now, how­ever, is be­yond the pale. It fi­nally shows the world what WordPress re­ally is, an abu­sive, preda­tory or­ga­ni­za­tion/​com­mu­nity ly­ing about its virtues to abuse other com­pa­nies and or­ga­ni­za­tions in an ef­fort to get free work.

The truth is that WordPress is, at best, past its peak and we’re go­ing to see more fights be­tween the com­pa­nies in its or­bit as they each bat­tle for a larger slice of a shrink­ing pie. That is­n’t some­thing any­one can change with its cur­rent lead­er­ship and pro­ject struc­ture.

With this ac­tion I fi­nally see that there is no help­ing the sit­u­a­tion and I fear that my con­tin­ued in­volve­ment can only serve to sig­nal to oth­ers that their own work and ef­forts are both safe and worth­while. They are nei­ther. I won’t be re­spon­si­ble for lead­ing good peo­ple to an abu­sive ecosys­tem.

With this I’ve archived my last re­main­ing WordPress pro­jects, Kana and the theme for this site, un­til such a time as there is proper gov­er­nance in the WordPress pro­ject. I’ve also stepped back and will no longer con­tribute to Meetups or other WordPress events (something I was ex­cited about re­join­ing just this past sum­mer). I’ve even stopped mod­er­at­ing jobs.word­press.net, some­thing I had done al­most daily since the sum­mer of 2013.

Should the pro­ject find new life, prefer­ably with lesser am­bi­tions that a huge share of the whole in­ter­net, and com­pe­tent gov­er­nance in the spirit of the virtues it claims to rep­re­sent I will re­think my po­si­tion. For now, how­ever, So Long WordPress, and thanks for all the fish.

Finally, a note to the many good peo­ple still work­ing in WordPress:

Thank you, all of you, for the years of con­ver­sa­tion and sup­port. While I speak of WordPress as a whole there are many of you both in­di­vid­u­ally and in smaller com­mu­ni­ties that have done so much for the peo­ple in WordPress. I look for­ward to con­tin­u­ing con­ver­sa­tions and sup­port for your work in the fu­ture, re­gard­less of where we all wind up.

I do, how­ever, ask that you please con­sider the ef­fects your ac­tions have on oth­ers and be care­ful not to lead new vic­tims to fu­ture abuse.

← This Site Now Runs on Hugo

There’s a com­mon nar­ra­tive that Microsoft was mori­bund un­der Steve Ballmer and then later saved by the mirac­u­lous lead­er­ship of Satya Nadella. This is the dom­i­nant nar­ra­tive in every on­line dis­cus­sion about the topic I’ve seen and it’s a com­monly ex­pressed be­lief “in real life” as well. While I don’t have any­thing neg­a­tive to say about Nadella’s lead­er­ship in this post, this nar­ra­tive un­der­rates Ballmer’s role in Microsoft’s suc­cess. Not only did Microsoft’s fi­nan­cials, rev­enue and profit, look great un­der Ballmer, Microsoft un­der Ballmer made deep, long-term bets that set up Microsoft for suc­cess in the decades af­ter his reign. At the time, the bets were widely panned, in­di­cat­ing that they weren’t nec­es­sar­ily ob­vi­ous, but we can see in ret­ro­spect that the com­pany made very strong bets de­spite the crit­i­cism at the time.

In ad­di­tion to over­see­ing deep in­vest­ments in ar­eas that peo­ple would later credit Nadella for, Ballmer set Nadella up for suc­cess by clear­ing out po­lit­i­cal bar­ri­ers for any suc­ces­sor. Much like Gary Bernhardt’s talk, which was panned be­cause he made the prob­lem state­ment and so­lu­tion so ob­vi­ous that peo­ple did­n’t re­al­ize they’d learned some­thing non-triv­ial, Ballmer set up Microsoft for fu­ture suc­cess so ef­fec­tively that it’s easy to crit­i­cize him for be­ing a bum be­cause his suc­ces­sor is so suc­cess­ful.

For peo­ple who weren’t around be­fore the turn of the cen­tury, in the 90s, Microsoft used to be con­sid­ered the biggest, bad­dest, com­pany in town. But it was­n’t long be­fore peo­ple’s opin­ions on Microsoft changed — by 2007, many peo­ple thought of Microsoft as the next IBM and Paul Graham wrote Microsoft is Dead, in which he noted that Microsoft be­ing con­sid­ered ef­fec­tive was an­cient his­tory:

A few days ago I sud­denly re­al­ized Microsoft was dead. I was talk­ing to a young startup founder about how Google was dif­fer­ent from Yahoo. I said that Yahoo had been warped from the start by their fear of Microsoft. That was why they’d po­si­tioned them­selves as a “media com­pany” in­stead of a tech­nol­ogy com­pany. Then I looked at his face and re­al­ized he did­n’t un­der­stand. It was as if I’d told him how much girls liked Barry Manilow in the mid 80s. Barry who? Microsoft? He did­n’t say any­thing, but I could tell he did­n’t quite be­lieve any­one would be fright­ened of them.

These kinds of com­ments of­ten came with com­ments that Microsoft’s rev­enue was des­tined to fall, such as these com­ments by Graham:

Actors and mu­si­cians oc­ca­sion­ally make come­backs, but tech­nol­ogy com­pa­nies al­most never do. Technology com­pa­nies are pro­jec­tiles. And be­cause of that you can call them dead long be­fore any prob­lems show up on the bal­ance sheet. Relevance may lead rev­enues by five or even ten years.

Graham names Google and the web as pri­mary causes of Microsoft’s death, which we’ll dis­cuss later. Although Graham does­n’t name Ballmer or note his in­flu­ence in Microsoft is Dead, Ballmer has been a fa­vorite punch­ing bag of techies for decades. Ballmer came up on the busi­ness side of things and later be­came EVP of Sales and Support; techies love be­lit­tling non-tech­ni­cal folks in tech. A com­mon crit­i­cism, then and now, is that Ballmer did­n’t un­der­stand tech and was a poor leader be­cause all he knew was sales and the bot­tom line and all he can do is copy what other peo­ple have done. Just for ex­am­ple, if you look at on­line com­ments on tech fo­rums (minimsft, HN, slash­dot, etc.) when Ballmer pushed Sinofsky out in 2012, Ballmer’s lead­er­ship is nearly uni­ver­sally panned. Here’s a fairly typ­i­cal com­ment from some­one claim­ing to be an anony­mous Microsoft in­sider:

Dump Ballmer. Fire 40% of the work­force start­ing with the loser on­line ser­vices (they are never go­ing to get any bet­ter). Reinvest the bil­lions in start-up op­por­tu­ni­ties within the puget sound that can be ac­cre­tive to MSFT and ac­qui­si­tion tar­gets … Reset Windows - Desktop and Tablet. Get se­ri­ous about busi­ness cloud (like Salesforce …)

To the ex­tent that Ballmer de­fended him­self, it was by point­ing out that the mar­ket ap­peared to be un­der­valu­ing Microsoft. Ballmer noted that Microsoft’s mar­ket cap at the time was ex­tremely low rel­a­tive to its fun­da­men­tals/​fi­nan­cials rel­a­tive to Amazon, Google, Apple, Oracle, IBM, and Salesforce. This seems to have been a fair as­sess­ment by Ballmer as Microsoft has out­per­formed all of those com­pa­nies since then.

When Microsoft’s mar­ket cap took off af­ter Nadella be­came CEO, it was only nat­ural the nar­ra­tive would be that Ballmer was killing Microsoft and that the com­pany was strug­gling un­til Nadella turned it around. You can pick other dis­cus­sions if you want, but just for ex­am­ple, if we look at the most re­cent time Microsoft is Dead hit #1 on HN, a quick ctrl+F has Ballmer’s name show­ing up 24 times. Ballmer has some de­fend­ers, but the stan­dard nar­ra­tive that Ballmer was hold­ing Microsoft back is there, and one of the de­fend­ers even uses part of the stan­dard nar­ra­tive: Ballmer was an unimag­i­na­tive hack, but he at least set up Microsoft well fi­nan­cially. If you look at high rank­ing com­ments, they’re all dunk­ing on Ballmer.

And if you look on less well in­formed fo­rums, like Twitter or Reddit, you see the same at­tacks, but Ballmer has fewer de­fend­ers. On Twitter, when I search for “Ballmer”, the first four re­sults are un­am­bigu­ously mak­ing fun of Ballmer. The fifth hit could go ei­ther way, but from the com­ments, seems to gen­er­ally be taken as mak­ing of Ballmer, and as I far as I scrolled down, all but one of the re­main­ing videos was mak­ing fun of Ballmer (the one that was­n’t was an in­ter­view where Ballmer notes that he of­fered Zuckerberg “$20B+, some­thing like that” for Facebook in 2009, which would’ve been the 2nd largest tech ac­qui­si­tion ever at the time, sec­ond only to Carly Fiorina’s ac­qui­si­tion of Compaq for $25B in 2001). Searching red­dit (incognito win­dow with no his­tory) is the same story (excluding the sto­ries about him as an NBA owner, where he’s re­spected by fans). The top story is mak­ing fun of him, the next one notes that he’s wealth­ier than Bill Gates and the top com­ment on his per­for­mance as a CEO starts with “The irony is that he is Microsofts [sic] worst CEO” and then has the stan­dard nar­ra­tive that the only rea­son the com­pany is do­ing well is due to Nadella sav­ing the day, that Ballmer missed the boat on all of the im­por­tant changes in the tech in­dus­try, etc.

To sum it up, for the past twenty years, peo­ple hav­ing been dunk­ing on Ballmer for be­ing a buf­foon who does­n’t un­der­stand tech and who was, at best, some kind of bean counter who knew how to keep the lights on but did­n’t know how to fos­ter in­no­va­tion and caused Microsoft to fall be­hind in every im­por­tant mar­ket.

The com­mon view is at odds with what ac­tu­ally hap­pened un­der Ballmer’s lead­er­ship. In fi­nan­cially ma­te­r­ial pos­i­tive things that hap­pened un­der Ballmer since Graham de­clared Microsoft dead, we have:

* 2009: Bing launched. This is con­sid­ered a huge fail­ure, but the bar here is fairly high. A quick web search finds that Bing al­legedly made $1B in profit in 2015 and $6.4B in FY 2024 on $12.6B of rev­enue (given Microsoft’s PE ra­tio in 2022, a rough es­ti­mate for Bing’s value in 2022 would be $240B)

* 2010: Microsoft cre­ates Azure I can’t say that I per­son­ally like it as a prod­uct, but in terms of run­ning large scale cloud in­fra­struc­ture, the three com­pa­nies that are head-and-shoul­ders ahead of every­one else in the world are Amazon, Google, and Microsoft. From a busi­ness stand­point, the worst thing you could say about Microsoft here is that they’re a solid #2 in terms of the busi­ness and the biggest threat to be­come the #1 The en­ter­prise sales arm, built and ma­tured un­der Ballmer, was and is crit­i­cal to the suc­cess of Azure and Office

* I can’t say that I per­son­ally like it as a prod­uct, but in terms of run­ning large scale cloud in­fra­struc­ture, the three com­pa­nies that are head-and-shoul­ders ahead of every­one else in the world are Amazon, Google, and Microsoft. From a busi­ness stand­point, the worst thing you could say about Microsoft here is that they’re a solid #2 in terms of the busi­ness and the biggest threat to be­come the #1

* The en­ter­prise sales arm, built and ma­tured un­der Ballmer, was and is crit­i­cal to the suc­cess of Azure and Office

* 2010: Office 365 re­leased Microsoft tran­si­tioned its en­ter­prise / busi­ness suite of soft­ware from boxed soft­ware to sub­scrip­tion-based soft­ware with on­line op­tions there is­n’t re­ally a fixed date for this; the of­fi­cial re­lease of Office 365 seems like as good a year as any Like Azure, I don’t per­son­ally like these prod­ucts, but if Microsoft were to split up into ma­jor busi­ness units, the en­ter­prise soft­ware suite is the busi­ness unit that could pos­si­bly ri­val Azure in mar­ket cap

* Microsoft tran­si­tioned its en­ter­prise / busi­ness suite of soft­ware from boxed soft­ware to sub­scrip­tion-based soft­ware with on­line op­tions there is­n’t re­ally a fixed date for this; the of­fi­cial re­lease of Office 365 seems like as good a year as any

* there is­n’t re­ally a fixed date for this; the of­fi­cial re­lease of Office 365 seems like as good a year as any

* Like Azure, I don’t per­son­ally like these prod­ucts, but if Microsoft were to split up into ma­jor busi­ness units, the en­ter­prise soft­ware suite is the busi­ness unit that could pos­si­bly ri­val Azure in mar­ket cap

There are cer­tainly plenty of big misses as well. From 2010-2015, HoloLens was one of Microsoft’s biggest bets, be­hind only Azure and then Bing, but no one’s big AR or VR bets have had good re­turns to date. Microsoft failed to cap­ture the mo­bile mar­ket. Although Windows Phone was gen­er­ally well re­ceived by re­view­ers who tried it, de­pend­ing on who you ask, Microsoft was ei­ther too late or was­n’t will­ing to sub­si­dize Windows Phone for long enough. Although .NET is still used to­day, in terms of mar­ket­share, .NET and Silverlight did­n’t live up to early promises and crit­i­cal parts were ham­strung or killed as a side ef­fect of in­ter­nal po­lit­i­cal bat­tles. Bing is, by rep­u­ta­tion, a fail­ure and, at least given Microsoft’s choices at the time, prob­a­bly needed an­titrust ac­tion against Google to suc­ceed, but this fail­ure still re­sulted in a busi­ness unit worth hun­dreds of bil­lions of dol­lars. And de­spite all of the fail­ures, the biggest bet, Azure, is prob­a­bly worth on the or­der of a tril­lion dol­lars.

The en­ter­prise sales arm of Microsoft was built out un­der Ballmer be­fore he was CEO (he was, for a time, EVP for Sales and Support, and ac­tu­ally started at Microsoft as the first busi­ness man­ager) and con­tin­ued to get built out when Ballmer was CEO. Microsoft’s sales play­book was so ef­fec­tive that, when I was Microsoft, Google would of­fer some cus­tomers on Office 365 Google’s en­ter­prise suite (Docs, etc.) for free. Microsoft sales­peo­ple noted that they would still usu­ally be able to close the sale of Microsoft’s paid prod­uct even when com­pet­ing against a Google that was giv­ing their prod­uct away. For the en­ter­prise, the com­bi­na­tion of Microsoft’s of­fer­ing and its en­ter­prise sales team was so ef­fec­tive that Google could­n’t even give its prod­uct away.

If you’re read­ing this and you work at a “tech” com­pany, the com­pany is over­whelm­ingly likely to choose the Google en­ter­prise suite over the Microsoft en­ter­prise suite and the en­ter­prise sales pitch Microsoft sales peo­ple have prob­a­bly sounds ridicu­lous to you.

An ac­quain­tance of mine who ran a startup had a Microsoft Azure sales­per­son come in and try to sell them on Azure, open­ing with “You’re on AWS, the con­sumer cloud. You need Azure, the en­ter­prise cloud”. For most peo­ple in tech com­pa­nies, en­ter­prise is syn­ony­mous with over­priced, un­re­li­able, junk. In the same way it’s easy to make fun of Ballmer be­cause he came up on the sales and busi­ness side of the house, it’s easy to make fun of an en­ter­prise sales pitch when you hear it but, over­all, Microsoft’s en­ter­prise sales arm does a good job. When I worked in Azure, I looked into how it worked and, hav­ing just come from Google, there was a night and day dif­fer­ence. This was in 2015, un­der Nadella, but the cul­ture and processes that let Microsoft scale this up were built out un­der Ballmer. I think there were mul­ti­ple months where Microsoft hired and on­boarded more sales­peo­ple than Google em­ployed in to­tal and every stage of the sales pipeline was fairly ef­fec­tive.

When peo­ple point to a long list of fail­ures like Bing, Zune, Windows Phone, and HoloLens as ev­i­dence that Ballmer was some kind of buf­foon who was hold­ing Microsoft back, this demon­strates a lack of un­der­stand­ing of the tech in­dus­try. This is like point­ing to a list of failed com­pa­nies a VC has funded as ev­i­dence the VC does­n’t know what they’re do­ing. But that’s silly in a hits based in­dus­try like ven­ture cap­i­tal. If you want to claim the VC is bad, you need to point out poor to­tal re­turn or a lack of big suc­cesses, which would im­ply poor to­tal re­turn. Similarly, a large com­pany like Microsoft has a large port­fo­lio of bets and one suc­cess­ful bet can pay for a huge num­ber of fail­ures. Ballmer’s crit­ics can’t point to a poor to­tal re­turn be­cause Microsoft’s to­tal re­turn was very good un­der his tenure. Revenue in­creased from , de­pend­ing on whether you want to count from when Ballmer be­came President in July 1998 or when Ballmer be­came CEO in January 2000. The com­pany was also quite prof­itable when Ballmer left, record­ing $27B in profit the pre­vi­ous four quar­ters, more than the rev­enue of the com­pany he took over. By mar­ket cap, Azure alone would be in the top 10 largest pub­lic com­pa­nies in the world and the en­ter­prise soft­ware suite mi­nus Azure would prob­a­bly just miss be­ing in the top 10.

As a re­sult, crit­ics also can’t point to a lack of hits when Ballmer presided over the cre­ation of Azure, the con­ver­sion of Microsoft’s en­ter­prise soft­ware from set of lo­cal desk­top apps to Office 365 et al., the cre­ation of the world’s most ef­fec­tive en­ter­prise sales org, the cre­ation of Microsoft’s video game em­pire (among other things, Ballmer was CEO when Microsoft ac­quired Bungie and made Halo the Xbox’s flag­ship game on launch in 2001), etc. Even Bing, widely con­sid­ered a fail­ure, on last re­ported rev­enue and cur­rent P/E ra­tio, would be 12th most valu­able tech com­pany in the world, be­tween Tencent and ASML. When at­tack­ing Ballmer, peo­ple cite Bing as a fail­ure that oc­curred on Ballmer’s watch, which tells you some­thing about the de­gree of suc­cess Ballmer had. Most com­pa­nies would love to have their suc­cesses be as suc­cess­ful as Bing, let alone their fail­ures. Of course it would be bet­ter if Ballmer was pre­scient and all of his bets suc­ceeded, mak­ing Microsoft worth some­thing like $10T in­stead of the lowly $3T mar­ket cap it has to­day, but the crit­i­cism of Ballmer that says that he had some fail­ures and some $1T suc­cesses is a crit­i­cism that he was­n’t the great­est CEO of all time by a gi­gan­tic mar­gin. True, but not much of a crit­i­cism.

And, un­like Nadella, Ballmer did­n’t in­herit a com­pany that was eas­ily set up for suc­cess. As we noted ear­lier, it was­n’t long into Ballmer’s tenure that Microsoft was con­sid­ered a bor­ing, ir­rel­e­vant com­pany and the next IBM, mostly due to de­ci­sions made when Bill Gates was CEO. As a very se­nior Microsoft em­ployee from the early days, Ballmer was also par­tially re­spon­si­ble for the state of Microsoft at the time, so Microsoft’s prob­lems are also at least par­tially at­trib­ut­able to him (but that also means he should get some credit for the suc­cess Microsoft had through the 90s). Nevertheless, he nav­i­gated Microsoft’s most dif­fi­cult prob­lems well and set up his suc­ces­sor for smooth sail­ing.

Earlier, we noted that Paul Graham cited Google and the rise of the web as two causes for Microsoft’s death prior to 2007. As we dis­cussed in this look at an­titrust ac­tion in tech, these both share a com­mon root cause, an­titrust ac­tion against Microsoft. If we look at the doc­u­ments from the Microsoft an­titrust case, it’s clear that Microsoft knew how im­por­tant the in­ter­net was go­ing to be and had plans to con­trol the in­ter­net. As part of these plans, they used their mo­nop­oly power on the desk­top to kill Netscape. They tech­ni­cally lost an an­tirust case due to this, but if you look at the ac­tual out­comes, Microsoft ba­si­cally got what they wanted from the courts. The reme­dies levied against Microsoft are widely con­sid­ered to have been use­less (the ini­tial de­ci­sion in­volved break­ing up Microsoft, but they were able to re­verse this on ap­peal), and the case dragged on for long enough that Netscape was doomed by the time the case was de­cided, and the reme­dies that weren’t specif­i­cally tar­geted at the Netscape sit­u­a­tion were mean­ing­less.

A later part of the plan to dom­i­nate the web, dis­cussed at Microsoft but never ex­e­cuted, was to kill Google. If we’re judg­ing Microsoft by how “dangerous” it is, how ef­fec­tively it crushes its com­peti­tors, like Paul Graham did when he judged Microsoft to be dead, then Microsoft cer­tainly be­came less dan­ger­ous, but the feel­ing at Microsoft was that their hand was forced due to the cir­cum­stances. One part of the plan to kill Google was to redi­rect users who typed google.com into their ad­dress bar to MSN search. This was be­fore Chrome ex­isted and be­fore mo­bile ex­isted in any mean­ing­ful form. Windows desk­top mar­ket­share was 97% and IE had be­tween 80% to 95% mar­ket­share de­pend­ing on the year, with most of the rest of the mar­ket­share be­long­ing to the rapidly de­clin­ing Netscape. If Microsoft makes this move, Google is killed be­fore it can get Chrome and Android off the ground and, bar­ring ex­treme an­titrust ac­tion, such as a breakup of Microsoft, Microsoft owns the web to this day. And then for dessert, it’s not clear there would­n’t be a rea­son not to go af­ter Amazon.

After in­ter­nal de­bate, Microsoft de­clined to kill Google not due to fear of an­titrust ac­tion, but due to fear of bad PR from the en­su­ing an­titrust ac­tion. Had Microsoft redi­rected traf­fic away from Google, the im­pact on Google would’ve been swifter and more se­vere than their moves against Netscape and in the time it would take for the DoJ to win an­other case against Microsoft, Google would suf­fer the same fate as Netscape. It might be hard to imag­ine this if you weren’t around at the time, but the DoJ vs. Microsoft case was reg­u­lar front-page news in a way that we haven’t seen since (in part be­cause com­pa­nies learned their les­son on this one — Google sup­pos­edly killed the 2011-2012 FTC against them with lob­by­ing and has clev­erly ma­neu­vered the more re­cent case so that it does­n’t dom­i­nate the news cy­cle in the same way). The clos­est thing we’ve seen since the Microsoft an­titrust me­dia cir­cus was the me­dia re­sponse to the Crowdstrike out­age, but that was a flash in the pan com­pared to the DoJ vs. Microsoft case.

If there’s a crit­i­cism of Ballmer here, per­haps it’s some­thing like Microsoft did­n’t pre-emp­tively learn the lessons its younger com­peti­tors learned from its big an­titrust case be­fore the big an­titrust case. A suf­fi­ciently pre­scient ex­ec­u­tive could’ve ad­vo­cated for heavy lob­by­ing to head the an­titrust case off at pass, like Google did in 2011-2012, or ma­neu­vered to make the an­titrust case just an­other news story, like Google has been do­ing for the cur­rent case. Another pos­si­ble crit­i­cism is that Microsoft did­n’t cor­rectly read the po­lit­i­cal tea leaves and re­al­ize that there was­n’t go­ing to be se­ri­ous US tech an­titrust for at least two decades af­ter the big case against Microsoft. In prin­ci­ple, Ballmer could’ve over­rid­den the de­ci­sion to not kill Google if he had the right ex­per­tise on staff to re­al­ize that the United States was en­ter­ing a two decade pe­riod of re­duced an­titrust scrutiny in tech.

As crit­i­cisms go, I think the for­mer crit­i­cism is cor­rect, but not an in­dict­ment of Ballmer un­less you ex­pect CEOs to be , so as ev­i­dence that Ballmer was a bad CEO, this would be a very weak crit­i­cism. And it’s not clear that the lat­ter crit­i­cism is cor­rect. While Google was able to get away with things like hard­cod­ing the search en­gine in Android to pre­vent users from chang­ing their search en­gine set­ting to hav­ing bad­ware in­stallers trick users into mak­ing Chrome the de­fault browser, they were con­sid­ered the “good guys” and did­n’t get much scrutiny for these sorts of ac­tions, Microsoft was­n’t treated with kid gloves in the same way by the press or the gen­eral pub­lic. Google did­n’t trig­ger a se­ri­ous an­titrust in­ves­ti­ga­tion un­til 2011, so it’s pos­si­ble the lack of se­ri­ous an­titrust ac­tion be­tween 2001 and 2010 was an ar­ti­fact of Microsoft be­ing care­ful to avoid an­titrust scrutiny and Google be­ing too small to draw scrutiny and that a move to kill Google when it was still pos­si­ble would’ve drawn se­ri­ous an­titrust scrutiny and an­other PR cir­cus. That’s one way in which the com­pany Ballmer in­her­ited was in a more dif­fi­cult sit­u­a­tion than its com­peti­tors — Microsoft’s hands were per­ceived to be tied and may have ac­tu­ally been tied. Microsoft could and did get se­vere crit­i­cism for tak­ing an ac­tion when the ex­act same ac­tion taken by Google would be lauded as clever.

When I was at Microsoft, there was a lot of con­ster­na­tion about this. One funny ex­am­ple was when, in 2011, Google of­fi­cially called out Microsoft for un­eth­i­cal be­hav­ior and the me­dia jumped on this as yet an­other ex­am­ple of Microsoft be­hav­ing badly. A num­ber of peo­ple I talked to at Microsoft were up­set by this be­cause, ac­cord­ing to them, Microsoft got the idea to do this when they no­ticed that Google was do­ing it, but rep­u­ta­tions take a long time to change and ac­tions taken while Gates was CEO sig­nif­i­cantly re­duced Microsoft’s abil­ity to ma­neu­ver.

Another dif­fi­culty Ballmer had to deal with on tak­ing over was Microsoft’s in­tense in­ter­nal pol­i­tics. Again, as a very se­nior Microsoft em­ployee go­ing back to al­most the be­gin­ning, he bears some re­spon­si­bil­ity for this, but Ballmer man­aged to clear the board of the worst bad ac­tors so that Nadella did­n’t in­herit such a dif­fi­cult sit­u­a­tion. If we look at why Microsoft did­n’t dom­i­nate the web un­der Ballmer, in ad­di­tion to con­cerns that killing Google would cause a PR back­lash, in­ter­nal po­lit­i­cal ma­neu­ver­ing killed most of Microsoft’s most promis­ing web prod­ucts and re­duced the ap­peal and reach of most of the rest of its web prod­ucts. For ex­am­ple, Microsoft had a work­ing com­peti­tor to Google Docs in 1997, one year be­fore Google was founded and nine years be­fore Google ac­quired , but it was killed for po­lit­i­cal rea­sons. And like­wise for NetMeeting and other promis­ing prod­ucts. Microsoft cer­tainly was­n’t alone in hav­ing in­ter­nal po­lit­i­cal strug­gles, but it was fa­mous for hav­ing more bru­tal pol­i­tics than most.

Although Ballmer cer­tainly did­n’t do a per­fect job at clean­ing house, when I was at Microsoft and asked about promis­ing pro­jects that were side­lined or killed due to in­ter­nal po­lit­i­cal strug­gles, the biggest re­cent sources of those is­sues were shown the door un­der Ballmer, leav­ing a much more func­tional com­pany for Nadella to in­herit.

Stepping back to look at the big pic­ture, Ballmer in­her­ited a com­pany that was a fi­nan­cially strong po­si­tion that was hemmed in by in­ter­nal and ex­ter­nal pol­i­tics in a way that caused out­side ob­servers to think the com­pany was over­whelm­ingly likely to slide into ir­rel­e­vance, lead­ing to pre­dic­tions like Graham’s fa­mous pre­dic­tion that Microsoft is dead, with rev­enues ex­pected to de­cline in five to ten years. In ret­ro­spect, we can see that moves made un­der Gates lim­ited Microsoft’s abil­ity to use its mo­nop­oly power to out­right kill com­peti­tors, but there was no in­flec­tion point at which a mirac­u­lous turn­around was mounted. Instead, Microsoft con­tin­ued its very strong ex­e­cu­tion on en­ter­prise prod­ucts and con­tin­ued mak­ing rea­son­able bets on the fu­ture in a suc­cess­ful ef­fort to sup­plant rev­enue streams that were in­ter­nally viewed as long-term dead ends, even if they were go­ing to be prof­itable dead ends, such as Windows and boxed (non-subscription) soft­ware.

Unlike most com­pa­nies in that po­si­tion, Microsoft was will­ing to very heav­ily sub­si­dize a se­ries of bets that lead­er­ship thought could power the com­pany for the next few decades, such as Windows Phone, Bing, Azure, Xbox, and HoloLens. From the in­ter­nal and ex­ter­nal com­men­tary on these bets, you can see why it’s so hard for com­pa­nies to use their suc­cess­ful lines of busi­ness to sub­si­dize new lines of busi­ness when the writ­ing is on the wall for the suc­cess­ful busi­nesses. People panned these bets as stu­pid moves that would kill the com­pany, say­ing the com­pany should fo­cus is ef­forts on its most prof­itable busi­nesses, such as Windows. Even when there’s very clear data show­ing that buck­ing the sta­tus quo is the right thing, peo­ple usu­ally don’t do it, in part be­cause you look like an id­iot when it does­n’t pan out, but Ballmer was will­ing to make the right bets in the face of decades of ridicule.

Not all of the bets panned out, but if we look at com­ments from crit­ics who were say­ing that Microsoft was doomed be­cause it was sub­si­diz­ing the wrong bets or younger com­pa­nies would sur­pass it, well, to­day, Microsoft is worth 50% more than Google and twice as much as Meta. If we look at the broader his­tory of the tech in­dus­try, Microsoft has had sus­tained strong ex­e­cu­tion from its found­ing in 1975 un­til to­day, a nearly fifty year run, a run that’s ar­guably been un­matched in the tech in­dus­try. Intel’s been around as bit longer, but they stum­bled very badly around the turn of the cen­tury and they’ve had a num­ber of prob­lems over the past decade. IBM has a long his­tory, but it just was­n’t all that big dur­ing its early his­tory, e.g., when T. J. Watson re­named Computing-Tabulating-Recording Company to International Business Machines, its rev­enue was still well un­der $10M a year (inflation ad­justed, on the or­der of $100M a year). Computers started be­com­ing big and IBM was big for a tech com­pany by the 50s, but the an­titrust case brought against IBM in 1969 that dragged on un­til it was dropped for be­ing “without merit” in 1982 ham­strung the com­pany and its cul­ture in ways that are still vis­i­ble when you look at, for ex­am­ple, why IBM’s var­i­ous cloud ef­forts have failed and, in the 90s, the com­pany was on its deathbed and only man­aged to sur­vive at all due to Gerstner’s turn­around. If we look at older com­pa­nies that had long sus­tained runs of strong ex­e­cu­tion, most of them are gone, like DEC and Data General, or had very bad stum­bles that nearly ended the com­pany, like IBM and Apple. There are com­pa­nies that have had sim­i­larly long pe­ri­ods of strong ex­e­cu­tion, like Oracle, but those com­pa­nies haven’t been nearly as ef­fec­tive as Microsoft in ex­pand­ing their lines of busi­ness and, as a re­sult, Oracle is worth per­haps two Bings. That makes Oracle the 20th most valu­able pub­lic com­pany in the world, which cer­tainly is­n’t bad, but it’s no Microsoft.

If Microsoft stum­bles badly, a younger com­pany like Nvidia, Meta, or Google could over­take Microsoft’s track record, but that would be no fault of Ballmer’s and we’d still have to ac­knowl­edge that Ballmer was a very ef­fec­tive CEO, not just in terms of bring­ing the money in, but in terms of set­ting up a vi­sion that set Microsoft up for suc­cess for the next fifty years.

Besides the head­line items men­tioned above, off the top of my head, here are a few things I thought were in­ter­est­ing that hap­pened un­der Ballmer since Graham de­clared Microsoft to be dead

* 2011: Suimt Gulwani, at MSR, pub­lishes “Automating string pro­cess­ing in spread­sheets us­ing in­put-out­put ex­am­ples”, named a most in­flu­en­tial POPL pa­per 10 years later This pa­per is about us­ing pro­gram syn­the­sis for spread­sheet “autocomplete/inference” I’m not a fan of patents, but I would guess that the rea­son au­to­com­plete/​in­fer­ence works fairly well in Excel and ba­si­cally does­n’t work at all in Google Sheets is that MS has a patent on this based on this work

* This pa­per is about us­ing pro­gram syn­the­sis for spread­sheet “autocomplete/inference”

* I’m not a fan of patents, but I would guess that the rea­son au­to­com­plete/​in­fer­ence works fairly well in Excel and ba­si­cally does­n’t work at all in Google Sheets is that MS has a patent on this based on this work

* 2012: Microsoft re­leases TypeScript This has to be the most widely used pro­gram­ming lan­guage re­leased this cen­tury and it’s a plau­si­ble can­di­date for be­com­ing the most widely used lan­guage, pe­riod (as long as you don’t also count TS us­age as JS)

* This has to be the most widely used pro­gram­ming lan­guage re­leased this cen­tury and it’s a plau­si­ble can­di­date for be­com­ing the most widely used lan­guage, pe­riod (as long as you don’t also count TS us­age as JS)

* 2012: Microsoft Surface re­leased Things haven’t been look­ing so good for the Surface line since Panos Panay left in 2022, and this was ar­guably fail­ure even in 2022, but this was a $7B/yr line of busi­ness in 2022, which goes to show you how big and suc­cess­ful Microsoft is — most com­pa­nies would love to have some­thing do­ing as well as a failed $7B/yr busi­ness

* Things haven’t been look­ing so good for the Surface line since Panos Panay left in 2022, and this was ar­guably fail­ure even in 2022, but this was a $7B/yr line of busi­ness in 2022, which goes to show you how big and suc­cess­ful Microsoft is — most com­pa­nies would love to have some­thing do­ing as well as a failed $7B/yr busi­ness

* 2015: Microsoft re­leases vs­code (after the end of Ballmer’s tenure in 2014, but this work came out of work un­der Ballmer’s tenure in mul­ti­ple ways) This seems like the most widely used ed­i­tor among pro­gram­mers to­day by a very large mar­gin. When I looked at sur­vey data on this a num­ber of years back, I was shocked by how quickly this hap­pened. It seems like vs­code has achieved a level of pro­gram­mer ed­i­tor dom­i­nance that’s never been seen be­fore. Probably the clos­est thing was Visual Studio a decade be­fore Paul de­clared Microsoft dead, but that never achieved the same level of mar­ket­share due to a com­bi­na­tion of ef­fec­tively be­ing Windows only soft­ware and also cost­ing quite a bit of money Heath Borders notes that Erich Gamma, hired in 2011, was highly in­flu­en­tial here

* This seems like the most widely used ed­i­tor among pro­gram­mers to­day by a very large mar­gin. When I looked at sur­vey data on this a num­ber of years back, I was shocked by how quickly this hap­pened. It seems like vs­code has achieved a level of pro­gram­mer ed­i­tor dom­i­nance that’s never been seen be­fore. Probably the clos­est thing was Visual Studio a decade be­fore Paul de­clared Microsoft dead, but that never achieved the same level of mar­ket­share due to a com­bi­na­tion of ef­fec­tively be­ing Windows only soft­ware and also cost­ing quite a bit of money

* Heath Borders notes that Erich Gamma, hired in 2011, was highly in­flu­en­tial here

One re­sponse to Microsoft’s fi­nan­cial suc­cess, both the di­rect suc­cess that hap­pened un­der Ballmer as well as later suc­cess that was set up by Ballmer, is that Microsoft is fi­nan­cially suc­cess­ful but ir­rel­e­vant for trendy pro­gram­mers, like IBM. For one thing, rounded to the near­est Bing, IBM is prob­a­bly worth ei­ther zero or one Bings. But even if we put aside the fi­nan­cial as­pect and we just look at how much each $1T tech com­pany (Apple, Nvidia, Microsoft, Google, Amazon, and Meta) has im­pacted pro­gram­mers, Nvidia, Apple, and Microsoft all have a lot of pro­gram­mers who are de­pen­dent on the com­pany due to some kind of ecosys­tem de­pen­dence (CUDA; iOS; .NET and Windows, the lat­ter of which is still the plat­form of choice for many large ar­eas, such as AAA games).

You could make a case for the big cloud ven­dors, but I don’t think that com­pa­nies have a nearly forced de­pen­dency on AWS in the same way that a se­ri­ous English-language con­sumer app com­pany re­ally needs an iOS app or an AAA game com­pany has to re­lease on Windows and over­whelm­ingly likely de­vel­ops on Windows.

If we look at pro­gram­mers who aren’t pinned to an ecosys­tem, Microsoft seems highly rel­e­vant to a lot of pro­gram­mers due to the cre­ation of tools like vs­code and TypeScript. I would­n’t say that it’s nec­es­sar­ily more rel­e­vant than Amazon since so many pro­gram­mers use AWS, but it’s hard to ar­gue that the com­pany that cre­ated (among many other things) vs­code and TypeScript un­der Ballmer’s watch is ir­rel­e­vant to pro­gram­mers.

Shortly af­ter join­ing Microsoft in 2015, I bet Derek Chiou that Google would beat Microsoft to $1T mar­ket cap. Unlike most ex­ter­nal com­men­ta­tors, I agreed with the bets Microsoft was mak­ing, but when I looked around at the kinds of in­ter­nal dys­func­tion Microsoft had at the time, I thought that would cause them enough prob­lems that Google would win. That was wrong — Microsoft beat Google to $1T and is now worth $1T more than Google.

I don’t think I would’ve made the bet even a year later, af­ter see­ing Microsoft from the in­side and how ef­fec­tive Microsoft sales was and how good Microsoft was at ship­ping things that are ap­peal­ing to en­ter­prises and the com­par­ing that to Google’s cloud ex­e­cu­tion and strat­egy. But you could say that I made a mis­take that was fairly anal­o­gous to what ex­ter­nal com­men­ta­tors made un­til I saw how Microsoft op­er­ated in de­tail.

Thanks to Laurence Tratt, Yossi Kreinin, Heath Borders, Justin Blank, and Fabian Giesen for com­ments/​cor­rec­tions/​dis­cus­sion

HTML Forms have pow­er­ful val­i­da­tion mech­a­nisms, but they are heav­ily un­der­used. In fact, not many peo­ple even know much about them. Is this be­cause of some flaw in their de­sign? Let’s ex­plore.

Beyond that, there is a bunch of other ways that you can add con­straints to your in­put. Precisely, there are three ways to do it:

* Using spe­cific type at­tribute val­ues, such as “email”, “number”, or “url”

* Using other in­put at­trib­utes that cre­ate con­straints, such as “pattern” or “maxlength”

* Using the set­Cus­tom­Va­lid­ity DOM method of the in­put

The last one is the most pow­er­ful as it al­lows to cre­ate ar­bi­trary val­i­da­tion logic and han­dle com­plex cases. Do you no­tice how it dif­fers from the first two tech­niques? The first two are de­fined with at­trib­utes, but set­Cus­tom­Va­lid­ity

is a method.

Here’s a great write-up that ex­plains the dif­fer­ences be­tween DOM at­trib­utes and prop­er­ties: https://​jakearchibald.com/​2024/​at­trib­utes-vs-prop­er­ties/

The fact that set­Cus­tom­Va­lid­ity API is ex­posed only as a method and does­n’t have an at­tribute equiv­a­lent leads to some ter­ri­ble er­gonom­ics. I’ll show you with an ex­am­ple.

But first, a very quick in­tro to how this API works:

This would make in­put in­valid and the browser will show the rea­son as “Any text mes­sage”.

Passing an empty string makes the in­put valid (unless other con­straints are ap­plied).

That’s pretty much it! Now let’s ap­ply this knowl­edge.

Let’s say we want to im­ple­ment an equiv­a­lent of the re­quired at­tribute. That means that an empty in­put must be pre­vent the form from be­ing sub­mit­ted.

This kind of looks like we’re done and this code should be enough to ac­com­plish the task. But try to see it in ac­tion:

It may seem to work, but there’s just one im­por­tant edge case: the in­put is in a valid state ini­tially. If you re­set the com­po­nent and press the “submit” but­ton, the form sub­mis­sion will go through. But surely, be­fore we ever touch the in­put, it is empty, and there­fore must be in­valid. But we only ever do some­thing when the in­put value changes.

How can we fix this?

Let’s ex­e­cute some code when the com­po­nent mounts:

Great! Now every­thing works as ex­pected. But at what cost?

Let’s look at our clumsy way to val­i­date the ini­tial value:

Ugh! Wouldn’t want to write that one each time. Let’s think about what’s wrong with this.

* The val­i­da­tion logic is du­pli­cated be­tween the on­Change han­dler and the ini­tial ren­der phase

* The ini­tial val­i­da­tion is not co-lo­cated with the in­put, so we’re los­ing code co­he­sion.

It’s frag­ile: if you up­date val­i­da­tion logic, you might for­get to up­date code in both places.

* The useRef + use­Lay­ouEf­fect + on­Change combo is just too much cer­e­mony,

es­pe­cially when a form has a lot of in­puts. And it gets even more con­fus­ing if only some of those in­puts use cus­tom­Va­lid­ity

This is what hap­pens when you deal with a purely im­per­a­tive API in a de­clar­a­tive com­po­nent.

Unlike val­i­da­tion at­trib­utes, CustomValidity is a purely im­per­a­tive API. In other words, there’s no in­put at­tribute that we can use to set cus­tom va­lid­ity.

In fact, I would ar­gue that this is the main rea­son for poor adop­tion of na­tive form val­i­da­tion. If the API is cum­ber­some, some­times it just does not mat­ter how pow­er­ful it is.

In essence, this is the at­tribute we need:

In a de­clar­a­tive frame­work, this would al­low to de­fine in­put val­i­da­tions in a very pow­er­ful way:

Pretty cool! In my opin­ion, at least. Though you can right­fully ar­gue that this ac­com­plishes only what the ex­ist­ing re­quired at­tribute is al­ready ca­pa­ble of. Where’s the “power”?

Let me show you, but first, since there’s no ac­tual cus­tom-va­lid­ity cur­rently in the HTML Spec, let’s im­ple­ment it in user­land.

This will work well for our demo pur­poses.

For a pro­duc­tion-ready com­po­nent check out a more com­plete im­ple­men­ta­tion.

Now we’ll ex­plore which non-triv­ial cases this de­sign can help solve.

In real-world apps, val­i­da­tion of­ten gets more com­plex than lo­cal checks. Imagine a user­name in­put that should be valid only if the user­name is not taken. This would re­quire async calls to your server and an in­ter­me­di­ary state: the form should not be valid while the check is in progress. Let’s see how our ab­strac­tion can han­dle this.

Play around with this ex­am­ple. It uses the re­quired to pre­vent empty in­puts. But then it re­lies on cus­tom­Va­lid­ity to mark in­put as in­valid dur­ing the load­ing state and based on the re­sponse.

First, we cre­ate an async func­tion to check whether the user­name is unique that im­i­tates a server re­quest with a de­lay.

Next, we’ll cre­ate a con­trolled form com­po­nent and use re­act-query to man­age to server re­quest when the in­put value changes:

Great! We have the setup in place. It con­sists of two cru­cial parts:

* Our cus­tom com­po­nent that is ca­pa­ble of tak­ing the cus­tom­Va­lid­ity prop

That’s it! We’re de­scrib­ing the whole async val­i­da­tion flow, in­clud­ing load­ing, er­ror and suc­cess states, in one at­tribute. You can go back to see the re­sult again if you wish

This one will be shorter, but also in­ter­est­ing, be­cause it cov­ers de­pen­dent in­put fields. Let’s im­ple­ment a form that re­quires to re­peat the en­tered pass­word:

You can try it out:

I hope I’ve been able to show you how set­Cus­tom­Va­lid­ity can cover val­i­da­tion needs of all kinds.

But the real power comes from great APIs.

And hope­fully, you are now equipped with one of those.

And even more hope­fully, we will see it na­tively in the HTML Spec one day.

Older (Access-J): 2024.08.03: Clang vs. Clang: You’re mak­ing Clang an­gry. You would­n’t like Clang when it’s an­gry. #compilers #optimization #bugs #timing #security #codescans

2024.10.28: The sins of the 90s: Questioning a puz­zling claim about mass sur­veil­lance. #attackers #governments #corporations #surveillance #cryptowars

2024.08.03: Clang vs. Clang: You’re mak­ing Clang an­gry. You would­n’t like Clang when it’s an­gry. #compilers #optimization #bugs #timing #security #codescans

2024.06.12: Bibliography keys: It’s as easy as [1], [2], [3]. #bibliographies #citations #bibtex #votemanipulation #paperwriting

2023.11.25: Another way to botch the se­cu­rity analy­sis of Kyber-512:

2023.10.23: Reducing “gate” counts for Kyber-512: Two al­go­rithm analy­ses, from first prin­ci­ples, con­tra­dict­ing NIST’s cal­cu­la­tion. #xor #popcount #gates #memory #clumping

2023.10.03: The in­abil­ity to count cor­rectly:

2022.08.05: NSA, NIST, and post-quan­tum cryp­tog­ra­phy: Announcing my sec­ond law­suit against the U. S. gov­ern­ment. #nsa #nist #des #dsa #dualec #sigintenablingproject #nistpqc #foia

2022.01.29: Plagiarism as a patent am­pli­fier:

2020.12.06: Optimizing for the wrong met­ric, part 1: Microsoft Word: Review of “An Efficiency Comparison of Document Preparation Systems Used in Academic Research and Development” by Knauff and Nejasmic. #latex #word #efficiency #metrics

2019.10.24: Why EdDSA held up bet­ter than ECDSA against Minerva:

2019.04.30: An in­tro­duc­tion to vec­tor­iza­tion: Understanding one of the most im­por­tant changes in the high-speed-soft­ware ecosys­tem. #vectorization #sse #avx #avx512 #antivectors

2017.11.05: Reconstructing ROCA: A case study of how quickly an at­tack can be de­vel­oped from a lim­ited dis­clo­sure. #infineon #roca #rsa

2017.10.17: Quantum al­go­rithms to find col­li­sions: Analysis of sev­eral al­go­rithms for the col­li­sion prob­lem, and for the re­lated multi-tar­get preim­age prob­lem. #collision #preimage #pqcrypto

2017.07.23: Fast-key-erasure ran­dom-num­ber gen­er­a­tors: An ef­fort to clean up sev­eral messes si­mul­ta­ne­ously. #rng #forwardsecrecy #urandom #cascade #hmac #rekeying #proofs

2017.07.19: Benchmarking post-quan­tum cryp­tog­ra­phy: News re­gard­ing the SUPERCOP bench­mark­ing sys­tem, and more rec­om­men­da­tions to NIST. #benchmarking #supercop #nist #pqcrypto

2016.10.30: Some chal­lenges in post-quan­tum stan­dard­iza­tion: My com­ments to NIST on the first draft of their call for sub­mis­sions. #standardization #nist #pqcrypto

2016.06.07: The death of due process: A few notes on tech­nol­ogy-fu­eled nor­mal­iza­tion of lynch mobs tar­get­ing both the ac­cuser and the ac­cused. #ethics #crime #punishment

2016.05.16: Security fraud in Europe’s “Quantum Manifesto”: How quan­tum cryp­tog­ra­phers are steal­ing a quar­ter of a bil­lion Euros from the European Commission. #qkd #quantumcrypto #quantummanifesto

2016.03.15: Thomas Jefferson and Apple ver­sus the FBI: Can the gov­ern­ment cen­sor how-to books? What if some of the read­ers are crim­i­nals? What if the books can be un­der­stood by a com­puter? An in­tro­duc­tion to free­dom of speech for soft­ware pub­lish­ers. #censorship #firstamendment #instructions #software #encryption

2015.11.20: Break a dozen se­cret keys, get a mil­lion more for free: Batch at­tacks are of­ten much more cost-ef­fec­tive than sin­gle-tar­get at­tacks. #batching #economics #keysizes #aes #ecc #rsa #dh #logjam

2015.03.14: The death of op­ti­miz­ing com­pil­ers: Abstract of my tu­to­r­ial at ETAPS 2015. #etaps #compilers #cpuevolution #hotspots #optimization #domainspecific #returnofthejedi

2015.02.18: Follow-You Printing: How Equitrac’s mar­ket­ing de­part­ment mis­rep­re­sents and in­ter­feres with your work. #equitrac #followyouprinting #dilbert #officespaceprinter

2014.06.02: The Saber clus­ter: How we built a clus­ter ca­pa­ble of com­put­ing 3000000000000000000000 mul­ti­pli­ca­tions per year for just 50000 EUR. #nvidia #linux #howto

2014.05.17: Some small sug­ges­tions for the Intel in­struc­tion set: Low-cost changes to CPU ar­chi­tec­ture would make cryp­tog­ra­phy much safer and much faster. #constanttimecommitment #vmul53 #vcarry #pipelinedocumentation

2014.04.11: NIST’s cryp­to­graphic stan­dard­iza­tion process: The first step to­wards im­prove­ment is to ad­mit pre­vi­ous fail­ures. #standardization #nist #des #dsa #dualec #nsa

2014.03.23: How to de­sign an el­lip­tic-curve sig­na­ture sys­tem: There are many choices of el­lip­tic-curve sig­na­ture sys­tems. The stan­dard choice, ECDSA, is rea­son­able if you don’t care about sim­plic­ity, speed, and se­cu­rity. #signatures #ecc #elgamal #schnorr #ecdsa #eddsa #ed25519

2014.02.05: Entropy Attacks! The con­ven­tional wis­dom says that hash out­puts can’t be con­trolled; the con­ven­tional wis­dom is sim­ply wrong.

Meredith Whittaker, pres­i­dent of the Signal Foundation, gave an in­ter­est­ing

talk

at NDSS 2024 ti­tled “AI, Encryption, and the Sins of the 90s”.

I won’t try to sum­ma­rize every­thing the talk is say­ing: go watch the talk video your­self, or at least read through the tran­script. But I’ll say some­thing here about what the “sins” part of the talk’s ti­tle is re­fer­ring to.

The talk says that, in the 1990s, “cryptosystems were still clas­si­fied as mu­ni­tions and sub­ject to strict ex­port con­trols”. The talk de­scribes the “crypto wars” as “a se­ries of le­gal bat­tles, cam­paigns, and pol­icy de­bates that played out in the US across the 1990s”, re­sult­ing in “the lib­er­al­iza­tion of strong en­cryp­tion in 1999″, al­low­ing peo­ple to “develop and use strong en­cryp­tion with­out be­ing sub­ject to con­trols”.

OK, that sounds fa­mil­iar. Which parts are the “sins”?

Answer: the talk claims that “the legacy of the crypto wars was to trade pri­vacy for en­cryp­tion—and to usher in an age of mass cor­po­rate sur­veil­lance”.

Wow. That sounds bad, and sur­pris­ing, def­i­nitely some­thing worth un­der­stand­ing bet­ter. If cryp­to­graphic ex­port con­trols had in­stead re­mained in place af­ter 1999, how would that have im­proved pri­vacy and re­duced cor­po­rate sur­veil­lance?

Answer: the talk claims that, with­out strong cryp­tog­ra­phy, “the metasta­tic growth of SSL-protected com­merce and RSA-protected cor­po­rate data­bases would not have been pos­si­ble”.

Wait, what? Let’s look at the facts.

Internet com­merce was al­ready boom­ing by 1999. Let’s look specif­i­cally at the his­tory of Amazon.

Amazon was founded in 1994. Its ini­tial pub­lic stock of­fer­ing was in

1997. Amazon was sued by Barnes & Noble in

1997, and was sued by Wal-Mart in 1998. Bezos was named Time Magazine’s Person of the Year in 1999:

Bezos’ vi­sion of the on­line re­tail­ing uni­verse was so com­plete, his Amazon.com site so el­e­gant and ap­peal­ing, that it be­came from Day One the point of ref­er­ence for any­one who had any­thing to sell on­line. And that, it turns out, is every­one.

Amazon’s

rev­enue

was 15.75 mil­lion dol­lars in 1996, 147.79 mil­lion dol­lars in 1997, 609.82 mil­lion dol­lars in 1998, and 1.64 bil­lion dol­lars in 1999. Amazon was com­pe­tently ex­e­cut­ing a busi­ness plan that from the out­set

ex­plic­itly pri­or­i­tized growth.

Where does any­one get the idea that con­tin­ued cryp­to­graphic ex­port con­trols would have stopped the growth of Internet com­merce, rather than sim­ply lim­it­ing the se­cu­rity level of Internet com­merce? How do we rec­on­cile this idea with the ob­served facts of Amazon al­ready grow­ing rapidly in the 1990s? The ex­port con­trols were still in place; to the ex­tent that Internet com­merce was en­crypted at all, it was en­crypted pri­mar­ily with a weak cryp­tosys­tem, namely 512-bit RSA.

Just to em­pha­size how fast Amazon’s growth was at that point: Amazon’s rev­enue was more than dou­bling every year. If that had kept up, Amazon’s rev­enue in 2023 would have been more than 26000000 bil­lion dol­lars. In re­al­ity, Amazon’s rev­enue in 2023 was only 575 bil­lion dol­lars.

Okay, okay, 575 bil­lion dol­lars is a lot of money, and Amazon is now

fight­ing an­titrust reg­u­la­tors. But how is Amazon’s growth be­fore and af­ter 1999 a story about a change in cryp­tog­ra­phy reg­u­la­tion, rather than a story about cus­tomers lik­ing a con­ve­nient shop­ping site that pro­vided fast, rea­son­ably re­li­able de­liv­er­ies of an ever-ex­pand­ing col­lec­tion of prod­ucts at com­pet­i­tive prices?

These are nat­ural ques­tions for any­one check­ing whether the talk’s claims match the avail­able ev­i­dence. But the talk does­n’t an­swer any of these ques­tions. Look, for ex­am­ple, at the full para­graph con­tain­ing the “would not have been pos­si­ble” quote:

It’s not that 1999 was­n’t a win, at least in a nar­row sense. Indeed, we can craft a coun­ter­fac­tual his­tory in which the lib­er­al­iza­tion of en­cryp­tion did­n’t hap­pen, in which we in­stead ac­cepted some janky, back­doored, gov­ern­ment-stan­dard cryp­tosys­tem—some sad Clipper chip DES ad­mix­ture—and that in­stead be­came the thing: a world in which strong cryp­tosys­tems did not re­ceive the ben­e­fit of many eyes and open scrutiny. But of course the fu­ture from then to now would have been very dif­fer­ent—not least of all be­cause the metasta­tic growth of SSL-protected com­merce and RSA-protected cor­po­rate data­bases would not have been pos­si­ble.

Aside from ir­rel­e­vant de­tails, how is the “counterfactual his­tory” of a “janky, back­doored, gov­ern­ment-stan­dard cryp­tosys­tem” dif­fer­ent from the re­al­ity of ex­port-con­trolled cryp­tog­ra­phy in the late 1990s, when 95%

of SSL con­nec­tions were lim­ited to RSA-512? The ex­plo­sion of Internet com­merce was al­ready hap­pen­ing at that point.

Where does the “would not have been pos­si­ble” claim come from? I’m not al­ler­gic to the phrase “of course”, but I try to limit it to cases where things are re­ally ob­vi­ous, which is def­i­nitely not the sit­u­a­tion here.

Government reg­u­la­tions are just one of many sources of weak cryp­tog­ra­phy. Weak cryp­tog­ra­phy, in turn, is just one of many sources of Internet-security fail­ures.

Companies re­ported spend­ing

more than 0.5% of rev­enue in 2023

on things la­beled as “cybersecurity”. A cy­ber­se­cu­rity com­pany named CrowdStrike ac­ci­den­tally

took down mil­lions of Windows com­put­ers

in July 2024, caus­ing long ser­vice out­ages for many other com­pa­nies. CrowdStrike had been given con­trol over all those com­put­ers be­cause it was say­ing that this would help pro­tect those com­put­ers against at­tacks. Delta Airlines, in a law­suit filed this month against CrowdStrike,

said that

the out­age “crippled its op­er­a­tions for sev­eral days, cost­ing more than $500 mil­lion in lost rev­enue and ex­tra ex­penses”. Meanwhile there are end­less re­ports of ran­somware run­ning ram­pant, as il­lus­trated by BlackCat dis­rupt­ing var­i­ous health-care ser­vices for

weeks

start­ing in February 2024.

And yet, de­spite the ev­i­dent dis­rup­tions, Internet com­merce con­tin­ues.

Do we want bet­ter se­cu­rity to stop the at­tacks? Yes. Does not hav­ing bet­ter se­cu­rity mean that the en­tire sys­tem of Internet com­merce will be de­stroyed?

Um, well, it’s con­ceiv­able that there will be such a dra­matic in­crease in at­tacks that we’ll all re­treat to non-In­ter­net com­merce (because, y’­know, non-In­ter­net com­merce is se­cure). But some­how the at­tack­ers don’t seem in­ter­ested in killing the goose that lays the golden eggs.

Let’s rewind to 1999. The CIH virus had de­stroyed data on

a mil­lion com­put­ers, and was just one of many ex­am­ples of at­tacks. This did­n’t stop the Internet from sky­rock­et­ing in pop­u­lar­ity; it sim­ply prompted ef­fort to fix vul­ner­a­bil­i­ties.

One of the vul­ner­a­bil­i­ties at that time was the use of RSA-512. From the per­spec­tive of stop­ping at­tacks, this vul­ner­a­bil­ity was

im­por­tant to fix. But, from the same per­spec­tive, there were many other vul­ner­a­bil­i­ties that were also im­por­tant to fix, in­clud­ing many that were

cheaper to ex­ploit

than at­tack­ing RSA-512. My own ex­pe­ri­ence is that ex­ploitable buffer over­flows were very easy to find back then.

Does it sound plau­si­ble if some­one picks one of the sys­tem vul­ner­a­bil­i­ties in 1999 and claims that fix­ing this vul­ner­a­bil­ity is what made the dif­fer­ence be­tween Internet com­merce suc­ceed­ing and Internet com­merce fail­ing? I’d ex­pect such a claim to be backed by

ev­i­dence that Internet com­merce was on such a knife’s edge (rather than be­ing a clear win for its con­ve­nience) and

an ex­pla­na­tion of what was so spe­cial about this vul­ner­a­bil­ity.

Otherwise the claim sounds like noth­ing more than wish­ful think­ing about the im­por­tance of some par­tic­u­lar area of se­cu­rity.

Let’s move on to the sec­ond part of the claim that, with­out strong cryp­tog­ra­phy, “the metasta­tic growth of SSL-protected com­merce and RSA-protected cor­po­rate data­bases would not have been pos­si­ble”.

The mass-sur­veil­lance in­dus­try is much older than 1999. See, for ex­am­ple, the book

“IBM and the Holocaust”, which traces how IBM’s punch-card data­bases were used to “organize nearly every­thing in Germany and then Nazi Europe, from the iden­ti­fi­ca­tion of the Jews in cen­suses, reg­is­tra­tions, and an­ces­tral trac­ing pro­grams to the run­ning of rail­roads and or­ga­niz­ing of con­cen­tra­tion camp slave la­bor”.

Does a data­base not count as a “corporate data­base” if the de­ci­sions of what’s go­ing into the data­base are be­ing made by a gov­ern­ment, in this case the Nazis? Does that make the data­base less evil? Also, does the level of evil de­pend on whether this was a data­base op­er­ated by IBM for the Nazis

or a data­base op­er­ated by the Nazis us­ing tech­nol­ogy pro­vided by IBM? Somehow I don’t think these dis­tinc­tions mat­tered for peo­ple in the con­cen­tra­tion camps.

As the 20th cen­tury con­tin­ued, more and more pow­er­ful tech­nol­ogy made sur­veil­lance less and less ex­pen­sive. Here’s a

quote

from a 2007 study “Engaging pri­vacy and in­for­ma­tion tech­nol­ogy in a dig­i­tal age”, is­sued by a com­mit­tee formed by the U. S. National Academies of Sciences, Engineering, and Medicine:

Beginning in the late 1950s, the com­puter be­came a cen­tral tool of or­ga­ni­za­tional sur­veil­lance. It ad­dressed prob­lems of space and time in the man­age­ment of records and data analy­sis and fu­eled the trend of cen­tral­iza­tion of records. The power of data­bases to ag­gre­gate in­for­ma­tion pre­vi­ously scat­tered across di­verse lo­ca­tions gave in­sti­tu­tions the abil­ity to cre­ate com­pre­hen­sive per­sonal pro­files of in­di­vid­u­als, fre­quently with­out their knowl­edge or co­op­er­a­tion. The pos­si­bil­ity of the use of such power for au­thor­i­tar­ian pur­poses awak­ened im­ages of Orwellian dystopia in the minds of count­less jour­nal­ists, schol­ars, writ­ers, and politi­cians dur­ing the 1960s, draw­ing wide-scale pub­lic at­ten­tion to sur­veil­lance and lend­ing ur­gency to the emerg­ing le­gal de­bate over pri­vacy rights.

One of the sec­tors that im­me­di­ately ben­e­fited from the in­tro­duc­tion of com­puter data­base tech­nol­ogy was the credit-re­port­ing in­dus­try. … But the credit and in­sur­ance in­dus­tries were not alone. Banks, util­ity com­pa­nies, tele­phone com­pa­nies, med­ical in­sti­tu­tions, mar­ket­ing firms, and many other busi­nesses were com­pil­ing na­tional and re­gional dossiers about their clients and com­peti­tors in quan­ti­ties never be­fore seen in the United States.

Surely the 1960s sur­veil­lance dossiers by “the credit-re­port­ing in­dus­try” and “marketing firms” and so on count as ex­am­ples of “corporate data­bases”.

What’s the mech­a­nism by which con­tin­ued cryp­to­graphic ex­port con­trols would have sup­pos­edly stopped the growth of sur­veil­lance? How do we rec­on­cile this with the ob­served facts of gov­ern­ment sur­veil­lance and cor­po­rate sur­veil­lance al­ready ex­plod­ing in the sec­ond half of the 20th cen­tury, when cryp­to­graphic ex­port con­trols were in place? Why does it mat­ter for this growth whether data­bases were “RSA-protected” or not? Or, more to the point, whether they were pro­tected by some­thing stronger than RSA-512?

The talk does­n’t an­swer any of these ques­tions ei­ther.

I was, as the talk men­tions, one of the peo­ple fight­ing ex­port con­trols in the 1990s. The rea­son I was tak­ing ac­tion is that I had stud­ied the sit­u­a­tion and was trou­bled by it. In par­tic­u­lar, I had con­cluded that the ex­port con­trols were con­tribut­ing to at­tacks. If I was wrong about that, then I’d like to un­der­stand why.

The talk claims that mov­ing to stronger cryp­tog­ra­phy had the neg­a­tive ef­fect of cre­at­ing at­tacks: specif­i­cally, of cre­at­ing cor­po­rate mass sur­veil­lance. I’d like to un­der­stand the ra­tio­nale for this claim. But I don’t see where the talk ex­plains the sup­posed mech­a­nism, or pro­vides any ev­i­dence, or ad­dresses the con­trary ev­i­dence pro­vided by 20th-century sur­veil­lance.

Beyond claim­ing that the ac­tions against ex­port con­trols con­tributed to cor­po­rate sur­veil­lance, the talk claims that these ac­tions came from a nar­row per­spec­tive

of see­ing the gov­ern­ment as the only prob­lem. For ex­am­ple:

The talk claims that “strategic mis­takes in the 1990s—in par­tic­u­lar, the mis­take of trust­ing in­dus­try and ‘the free mar­ket’ while view­ing the gov­ern­ment as the sole threat to fun­da­men­tal rights—is a big part of how we got here”.

The talk crit­i­cizes the “dated, mar­ket-cen­tric folk wis­dom that is con­tent to leave the gov­er­nance of sig­nif­i­cant choices about fun­da­men­tal rights—like ex­pres­sion and pri­vacy—to a hand­ful of pri­vate com­pa­nies, as­sum­ing the in­vis­i­ble hand will work some BCorp magic”.

The talk crit­i­cizes “conflating en­cryp­tion with pri­vacy and fo­cus­ing nar­rowly on the tech it­self—on en­cryp­tion as the goal, not a means to the goal—while fo­cus­ing con­cerns about pri­vacy in­va­sion solely on gov­ern­ments, as­sumed to be al­ways on the verge of tyranny—while ig­nor­ing (or even cel­e­brat­ing) the in­ter­ests of mar­ket ac­tors”.

In con­text, the talk is at­tribut­ing these per­spec­tives to those of us fight­ing the “crypto wars”.

Why are pop­u­lar­iz­ing ed­u­ca­tional newslet­ter-fre­quency writ­ers of im­por­tant fields like Matt Levine for fi­nance so rare? Because most fields are too slow or am­bigu­ous, and writ­ers of the right com­bi­na­tion of ex­per­tise, ob­ses­sion, and per­sis­tence are also rare.

[For sup­port of key web­site fea­tures (link an­no­ta­tion pop­ups/​popovers & tran­sclu­sions, col­lapsi­ble sec­tions, back­links, ta­ble­sort­ing, im­age zoom­ing, side­notes etc), you must en­able JavaScript.]

Matt Levine is the most well-known newslet­trist (“Money Stuff”) in the fi­nan­cial in­dus­try, hav­ing blogged or writ­ten since , find­ing his niche in pop­u­lar­iza­tion af­ter stints in Wall Street & law. His com­men­tary is in­flu­en­tial, peo­ple leak to him, he some­times in­ter­views ma­jor fig­ures (notoriously, Sam Bankman-Fried) or re­counts in­side in­for­ma­tion, and a num­ber of phrases like his “laws of in­sider trad­ing” (specifically, how not to) have gained cur­rency to the point where read­ers can now do much of the work of sourc­ing an is­sue for him.

He is read by hun­dreds of thou­sands of read­ers (including my­self)—every­one from shoeshine boy to bil­lion­aire. The size of his au­di­ence is re­spectable, but per­haps its most re­mark­able fea­ture is that many of those read­ers have noth­ing to do with the fi­nan­cial in­dus­try. Though his newslet­ter is of­fi­cially a Bloomberg News newslet­ter which he sim­ply writes, many of his read­ers will visit Bloomberg solely for him, and in­deed, might have lit­tle idea who or what a Bloomberg is. Nevertheless, read­ers loy­ally tune in for each in­stall­ment every few days to learn about ar­cane fi­nan­cial in­stru­ments they have never heard of be­fore, and (except for Levine) never will again.

One might ask (and in­deed, a bil­lion­aire once did), “where are the other Matt Levines?” or “who are the Matt levines of other fields?” That is, where are the Matt Levines of, say, chem­istry or drug de­vel­op­ment, who ex­plain & pop­u­lar­ize other ma­jor in­dus­tries which are vi­tal to mod­ern life, di­rectly or in­di­rectly ap­pear in the news of­ten, and yet peo­ple are widely ig­no­rant of it, and deeply mis­un­der­stand its fun­da­men­tal dy­nam­ics? Why don’t we have a Matt Levine for every in­dus­try? Where is the Levine of, I don’t know, pe­tro­leum re­fin­ing or frack­ing, of ship­ping con­tain­ers? Are we just in need of a good list of rec­om­men­da­tions? Or could we just set up a prize to coax out some po­ten­tial Levines in other in­dus­tries?

When I first met Matt, the first thing I said was “Matt Levine, only you can do what you do!”

My pes­simistic con­clu­sion is that Matt Levines are not made, they are born, and that the Matt Levine for­mula is largely ir­re­pro­ducible: there are few in­dus­tries where it makes sense, and there are few peo­ple suited for this job, and that is the sim­ple an­swer why there are not many Levines.

So, what is the for­mula, ex­actly? The Matt Levine for­mula is weighty mat­ters, leav­ened by hu­mor, with ba­sic ex­pla­na­tions of com­pli­cated fi­nan­cial mat­ters. As Levine has been do­ing this on­line for so long (~13 years), rel­a­tively speak­ing, he can of­ten re­fer to his pre­vi­ous cov­er­age and com­ment on how things turned out. Certain themes re­peat pe­ri­od­i­cally so of­ten that they re­ceive their own catch­phrases, like “worries about bond mar­ket liq­uid­ity” or the laws of in­sider trad­ing.

Many peo­ple owe most of what they know about stock trad­ing, bonds, ar­cane but con­tro­ver­sial mat­ters like naked shorts, meme stocks etc to Levine; and I would be em­bar­rassed to ad­mit how much of my eco­nom­ics knowl­edge comes through Levine rather than some more rig­or­ous source like my old eco­nom­ics text­books. This is be­cause Levine pro­vides 3 key in­gre­di­ents which fos­ter learn­ing:

cases with known out­comes/​an­swers: to de­velop ex­per­tise in a sub­ject, the sub­ject ide­ally pro­vides many prob­lems, with known an­swers, of high ac­cu­racy. Most sub­jects do not. But Levine’s sub­ject (finance & law) does.

A good sub­ject for de­vel­op­ing ex­per­tise is some­thing like chess: an end­less num­ber of chess games can be played rapidly, they all have a clear out­come (win/draw/loss), and one can study each one care­fully to un­der­stand what went right or wrong. A bad sub­ject is some­thing like mil­i­tary strat­egy: there are not many large-scale wars which have been doc­u­mented ad­e­quately, each war is unique and un­re­peat­able and a gen­eral may par­tic­i­pate in only a few in a life­time, and the out­comes (never mind any in­di­vid­u­al’s con­tri­bu­tion) are of­ten dif­fi­cult or im­pos­si­ble to judge. Many ar­eas are more like mil­i­tary strat­egy than chess—how do you judge the ex­per­tise of a CEO, or a Hollywood di­rec­tor, or a sci­en­tist fore­cast­ing the dis­tant fu­ture?

Levine works in an area which does pro­vide many clearcut ex­am­ples, be­cause he fo­cuses on law­suits, pros­e­cu­tions, crimes, and deals. These are ex­am­ples where the out­come will usu­ally be known in a few years, at most, or at least a ma­jor up­date/​de­vel­op­ment, and where the in­volved par­ties do all the re­search nec­es­sary, and where the ev­i­dence is of­ten com­pletely un­am­bigu­ous—Levine just has to read their fil­ings, and ex­cerpt the text mes­sage where some­one boasts about their in­sider trad­ing in no un­cer­tain terms.

In re­ly­ing on re­port­ing & fil­ings for his com­men­tary, Levine is very much like the dy­ing lo­cal news­pa­per crime re­porter, who re­lies on the po­lice blot­ter & court­room ac­cess to rapidly file their ar­ti­cles. These ar­ti­cles are nearly end­less, and mostly for­get­table be­cause there are, broadly speak­ing, not re­ally any prin­ci­ples gov­ern­ing lo­cal crime. “Some guy got drunk and into a fight and killed an­other guy” is some­thing that hap­pens fre­quently, but it il­lu­mi­nates no uni­ver­sal prin­ci­ple; it sheds no light on any­thing else. It was just some­thing hor­ri­ble that of­ten hap­pens at ran­dom when peo­ple take dan­ger­ous drugs like al­co­hol rather than safe ones like nico­tine, and is of no broader im­por­tance; true-crime ad­dicts con­sume it for its en­ter­tain­ment value, like darker ver­sions of Hollywood tabloids—“who mur­dered who” in­stead of “who’s sleep­ing with who”. It’s just “one d—n thing af­ter an­other”. (The TV show Cops has run for 36 years now, and could run for an­other 36 years with­out break­ing a sweat, but af­ter 72 sea­sons, what would you have learned that you did­n’t learn af­ter the first few?)

But in Levine’s area, this is not the case. Many of these ex­am­ples are due to highly in­tel­li­gent, mo­ti­vated, com­pe­tent peo­ple and or­ga­ni­za­tions clash­ing for deep rea­sons. This means that to un­der­stand them, you need…

first-prin­ci­ples ex­pla­na­tions: most peo­ple ex­pe­ri­ence an “illusion of depth”, in that they be­lieve they un­der­stand the causal me­chan­ics of an area far bet­ter than they do. But in fact, they have learned only a su­per­fi­cial model of the area. Levine cor­rects this.

Particularly in eco­nomic mat­ters, peo­ple be­lieve many in­tu­itive folk eco­nom­ics like eg. build­ing new houses can­not lower prices, or that busi­nesses raise prices sim­ply “when they feel greedy”, or that vol­un­tary trans­ac­tions must have a loser & a win­ner when other peo­ple trans­act (but not them­selves per­son­ally), or that a pol­icy will have only in­tended ef­fects be­cause every­one will just do what they are or­dered to (even though they per­son­ally work around poli­cies or rules all the time for doubt­less no­ble rea­sons).

Levine pa­tiently gives from first-prin­ci­ples (supply-and-demand, mar­ket ef­fi­ciency & ad­verse se­lec­tion, peo­ple fol­low­ing in­cen­tives, pub­lic choice the­ory) ex­pla­na­tions of why some thing about mar­kets or con­tracts is the way it is, how it op­er­ated (or failed to op­er­ate) in a par­tic­u­lar case, and what (and why) the var­i­ous coun­ter­fac­tual fu­ture out­comes are.

These re­peated ex­pla­na­tions—how­ever sim­pli­fied and ab­stracted—grad­u­ally build up gen­uine knowl­edge which can trans­fer to the real world be­yond some crammed sup­ply-and-de­mand schemat­ics in a long-for­got­ten eco­nom­ics class.

spaced rep­e­ti­tion en­abled by fast turnover: a newslet­ter is in­her­ently spaced in time, and by re­turn­ing to themes re­peat­edly, with var­i­ous twists or in­stan­ti­a­tions, the reader learns due to the spac­ing ef­fect.

In nor­mal news con­sump­tion, as op­posed to the drip-feed of a colum­nist on a steady beat, one might read about some in­stance of fi­nan­cial malfea­sance in great depth in the WSJ or NYT, say—but once.

This cov­er­age might be ex­tremely high qual­ity, but nev­er­the­less, such “massed pre­sen­ta­tion” is a recipe for for­get­ting. It is like cram­ming flash­cards the night be­fore the test: no mat­ter how good the flash­cards are or how much you re­mem­ber while tak­ing the test, most of it will be for­got­ten.

However, in Levine’s case, even if spe­cific cases or events re­solve quickly, the same prin­ci­ple will show up again soon enough.

So, that is the Levine for­mula: the global econ­omy fur­nishes him many rapidly-re­solved ex­am­ples which he can use to en­ter­tain­ingly il­lus­trate ba­sic prin­ci­ples of eco­nom­ics, and by do­ing that so reg­u­larly over so long, read­ers gain a gen­uine durable ed­u­ca­tion in eco­nom­ics which they will re­mem­ber and where they can ap­ply those prin­ci­ples on their own.

Analyzed into parts, we can see why many ar­eas can­not sup­port a Levine: they lack one of the 3 in­gre­di­ents:

Crime re­port­ing cov­ers crimes which are nu­mer­ous and rapidly-re­solved, but there is not much to learn.

Logistics like frack­ing or oil or con­tain­ers may cover many cases which have broad prin­ci­ples, but those cases are of­ten re­solved in se­crecy and due to the ex­treme boom-bust cy­cle of those in­dus­tries, may take decades to ‘mature’ (eg. an over-ex­tended oil com­pany might not go bust for decades de­pend­ing on how ex­actly cy­cles play out).

And ar­eas like drug de­vel­op­ment may be cursed by all 3: drug de­vel­op­ment of­ten ends in fail­ure for un­known rea­sons, in the dark, decades later, and what rea­sons are known may be to­tally idio­syn­cratic to a spe­cific drug or dis­ease; what is known may be at best a loose rule of thumb.

It would be nice to have a blog like Matt Levine cov­er­ing, say, evo­lu­tion­ary bi­ol­ogy or Greco-Roman phi­los­o­phy, but it’s ob­vi­ous why that is­n’t go­ing to work—you can’t have a very en­ter­tain­ing newslet­ter when it might take cen­turies for a de­bate to re­solve, if any­one can agree it was re­solved at all, and you cer­tainly aren’t go­ing to be able to pro­vide so many clear il­lus­tra­tions of ba­sic prin­ci­ples that read­ing the newslet­ter con­sti­tutes an ed­u­ca­tion. (You can read & learn about them, but their nat­ural form would be, well, a text­book or a mono­graph or some­thing like that, and def­i­nitely not a newslet­ter.)

And most ar­eas are more like drug de­vel­op­ment than they are like hedge funds su­ing each other over some con­trac­tual gim­mick or cler­i­cal er­ror.

OK, but surely there are still plenty of ar­eas where the pre­con­di­tions are met? (Particularly rapidly-de­vel­op­ing ones, like cryp­tocur­rency or AI re­cently?) So where are their Matt Levines?

This brings us to the sec­ond half of the equa­tion of the Matt Levine for­mula: the Matt Levine part.

Consider the im­pli­ca­tion of the 3 re­quire­ments for the au­thor, rather than the reader: they are go­ing to see the same hu­man come­dies play out, again and again, and have to shout it into the void again, only to watch it hap­pen yet again. The au­thor feels the weight of the rep­e­ti­tion far more than any reader does. It is like a teacher who must teach the same cur­ricu­lum for the 30th time—and again read & grade each of dozens of as­sign­ments on it by hun­dreds of stu­dents.

It is not every per­son who can do so well, or at all. Often a great ex­pert will make a ter­ri­ble teacher, be­cause they are un­able to en­dure the rep­e­ti­tion, or un­der­stand the ig­no­rance of the be­gin­ner, or treat the floun­der­ing stu­dent with kind­ness.

I per­son­ally ap­pre­ci­ate Levine’s per­ma­nent fas­ci­na­tion with fi­nance, his will­ing­ness to ex­plain the same things over and over. But I don’t think I (or most peo­ple) would be able to do so for a long time with­out turn­ing it into a dull ticket-punch­ing ex­er­cise as part of a mun­dane job rather than an av­o­ca­tion; and in­deed, I have shunned my op­por­tu­ni­ties to be­come a Levine of some area, when I felt my in­ter­est & pa­tience for fools rapidly wan­ing. (Particularly dark­net mar­kets: there was con­sid­er­able de­mand for com­men­ta­tors like Eileen Ormsby or DeepDotWeb, but I could see no new prin­ci­ples to main­tain my in­ter­est and just an end­less in­fosec churn of tem­po­rary trivia—a warn­ing that burnout was ap­proach­ing—and quit the area while I was ahead.)

Indeed, ex­per­tise is a rea­son to stop teach­ing en­tirely: if you are re­ally in­ter­ested in an area, and good at it (good enough to un­der­stand and com­men­tate on­go­ing events), then even if you are a great teacher who is gifted at ex­plain­ing the area to lay­men, why would you set­tle for teach­ing about it in­stead of do­ing it? But if you do it, then you will strug­gle to write about it reg­u­larly pub­licly: ac­tu­ally do­ing some­thing, in­stead of read­ing a court sum­mary of it, can take years of hard work, and pro­hibit you from writ­ing about it in var­i­ous ways. (It will also usu­ally pay much worse—Matt Levine is doubt­less com­pen­sated hand­somely by Bloomberg, but per­haps not as hand­somely as if he had kept ris­ing through Big Law, and su­per­star out­comes im­ply most would-be newslet­trists are paid peanuts.)

So you have a se­ri­ous prob­lem: any­one good enough to be ‘the Matt Levine of an area’ is also un­der con­sid­er­able pres­sure to not be him.

Why would any­one want to? Well, if you ask some­one like Richard Feynman or Andrej Karpathy or Tom Lehrer why they pur­sued ped­a­gogy in­stead of the pro­fes­sional pur­suits that brought them fame & wealth, the an­swer would have to be that “they love to teach”. Which is a fine rea­son, but a pas­sion for teach­ing a par­tic­u­lar sub­ject is far from com­mon.

So you have a fil­ter with many lay­ers: you need ar­eas which ful­fill a strin­gent set of con­di­tions for such an ed­u­ca­tional newslet­ter, and you need a very un­usual sort of in­di­vid­ual, some­one who is ex­pert in the area and has prefer­ably got­ten their hands dirty, who is good enough to work pro­fes­sion­ally in it, but who also is ca­pa­ble of ex­plain­ing it well, at a be­gin­ner level, many times, end­lessly with­out burn­ing out or get­ting bored, be­cause of their in­tense in­ter­est in the area (but again, not quite in­tense enough to make them go do it in­stead of write about it).

Each step here fil­ters out most can­di­dates, and by the end, there’s just not that much left. You can’t fix these fil­ters eas­ily. No prize or Substack tweak will sud­denly make drug dis­cov­ery hap­pen fast and fail for clear rea­sons, or con­jure up a Levine in a spe­cific area when you want one.

So, that’s why there are so few Matt Levines, and ex­plains where the other Matt Levines are: they don’t, and usu­ally can’t, ex­ist.

[Similar links by topic]

[Bibliography of links/​ref­er­ences used in page]