For var­i­ous rea­sons, I have de­cided to move as many ser­vices and sub­scrip­tions as pos­si­ble from non-EU coun­tries to the EU or to switch to European ser­vice providers. The rea­sons for this are the cur­rent global po­lit­i­cal sit­u­a­tion and im­proved data pro­tec­tion. I don’t want to go into the first point any fur­ther for var­i­ous rea­sons, but the sec­ond point should be im­me­di­ately ob­vi­ous, since the EU cur­rently has the most user-friendly laws when it comes to data pro­tec­tion. Below, I will list both the old and new ser­vice providers; this is not an ad­ver­tise­ment, but sim­ply the re­sult of my re­search, which was aimed at achiev­ing the same or bet­ter qual­ity at af­ford­able prices.

I would call this post an in­terim re­port, and I will ex­pand on it if I end up mi­grat­ing more ser­vices.

In my opin­ion, Fastmail is one of the best email providers. In all the years I’ve had my email ac­counts there, I’ve never had any prob­lems. I paid 10 eu­ros a month for two ac­counts, could use an un­lim­ited num­ber of my own do­mains, and could not only set up catch-all ad­dresses but also send emails from any email ad­dress I wanted. This is im­por­tant for my email setup. The cal­en­dar is also solid and was used within the fam­ily. All of this was also avail­able in a well-de­signed Android app. Finding a European al­ter­na­tive that of­fers all of this proved dif­fi­cult. First, I tried mail­box.org, which I can gen­er­ally rec­om­mend with­out reser­va­tion. Unfortunately, you can’t send emails from any ad­dress on your own do­main with­out a workaround, so the search con­tin­ued. Eventually, I landed on Uberspace. This “pay what you want” provider of­fers a shell ac­count, web host­ing, email host­ing, and more at fair prices. In ad­di­tion, you can use as many of your own do­mains as you like for both web and email, and send emails from any sender ad­dress. There is­n’t a ded­i­cated app, which is why I now use Thunderbird for Android and am very sat­is­fied with it.

Uberspace does­n’t of­fer a built-in cal­en­dar so­lu­tion. So I tried in­stalling var­i­ous CalDAV servers, but none of them re­ally con­vinced me. In the end, I sim­ply in­stalled NextCloud on my Uberspace Asteroid, which has CalDAV and CardDAV built in. On my desk­top, I use Thunderbird as a client; on Android, I use DAVx5 and Fossil Calendar. It works great, even if NextCloud does come with some over­head. In re­turn, I can now eas­ily share files with oth­ers and, in the­ory, also use NextCloud’s on­line of­fice func­tion­al­ity.

Now that I’m al­ready us­ing Uberspace for my email and cal­en­dar, I was able to host this web­site there as well. I pre­vi­ously had a VPS with Hetzner for this pur­pose, which I no longer need. The only mi­nor hur­dle was that I use SSI on this site to man­age the header cen­trally. I had pre­vi­ously used Nginx, but Uberspace hosts on Apache, where the SSI im­ple­men­ta­tion is han­dled slightly dif­fer­ently. However, adapt­ing my HTML code was quite sim­ple, so I was able to quickly mi­grate the site to Uberspace.

For a long time, I was a sat­is­fied Namecheap cus­tomer. They of­fer good prices, a wide se­lec­tion of avail­able do­mains, their DNS man­age­ment has every­thing you need, and their sup­port team has helped me quickly on sev­eral oc­ca­sions. But now it was time to look for a com­pa­ra­ble provider in the EU. In the end, I set­tled on host­ing.de. Some of the rea­sons were the prices, re­views, the lo­ca­tion in Germany, and the avail­abil­ity of .is do­mains. So far, every­thing has been run­ning smoothly; sup­port helped me quickly and com­pe­tently with one is­sue; and while prices for non-Ger­man do­mains are slightly higher, they’re still within an ac­cept­able range.

At some point, pretty much every­one had their code on GitHub (or still does). I was no ex­cep­tion, though I had also hosted my own Gitea in­stance. Eventually, I got tired of that too and mi­grated all my Git repos­i­to­ries to code­berg.org. Codeberg is a German-based non­profit or­ga­ni­za­tion, and it’s hard to imag­ine go­ing wrong with this choice.

No changes here. I’ve al­ways been a happy Mullvad cus­tomer. For 5 eu­ros a month, I pay a Swedish com­pany that has proven it does­n’t log any data and does­n’t even re­quire me to cre­ate an ac­count. No sub­scrip­tion traps, no weird Black Friday deals, no dis­counts: just 5 eu­ros a month for a re­li­able, trust­wor­thy ser­vice.

For many years, I used my work smart­phone for per­sonal use as well. I was more than sat­is­fied with the Pixel 6, but un­der­stand­ably, I was­n’t al­lowed to in­stall a cus­tom ROM or use al­ter­na­tive app stores like F-Droid. That’s why I de­cided to buy a sep­a­rate per­sonal smart­phone. I chose the Pixel 9a, which is sup­ported by Graphene OS. I still in­stalled the Google Play Store so I could in­stall a sig­nif­i­cant num­ber of apps that are only avail­able there. However, I can now use al­ter­na­tive app stores, which al­lows me to in­stall and use apps like NewPipe. This way, I can en­joy YouTube ad-free and with­out an ac­count.

For ca­sual use on the couch, a Chromebook has been un­beat­able for me so far. It’s af­ford­able, the bat­tery lasts for­ever, and it wakes up from sleep mode ex­tremely quickly. To break away from Google here as well, I re­cently bought a cheap used 11-inch MacBook Air (A1465) to in­stall MX Linux with Fluxbox on it and use it for brows­ing and watch­ing videos. I haven’t had a chance to test it out yet, but I’m hop­ing it will be able to re­place the Chromebook.

To use the Mastodon web ap­pli­ca­tion, please en­able JavaScript. Alternatively, try one of the na­tive apps for Mastodon for your plat­form.

Scarcely a day goes by with­out an out­age at a cloud ser­vice. Forget five nines — the way things are go­ing, one nine is look­ing like an am­bi­tious goal.

GitHub has had a rough month so far. On February 9, Actions, pull re­quests, no­ti­fi­ca­tions, and Copilot all ex­pe­ri­enced is­sues. The Microsoft ten­ta­cle ad­mit­ted it was hav­ing prob­lems with “some GitHub ser­vices” at 1554 UTC be­fore it con­fessed to no­ti­fi­ca­tion de­lays of “around 50 min­utes”.

It took un­til 1929 UTC for the com­pany to con­firm that things were back to nor­mal, al­though the de­lay was down to “approximately 30 min­utes” by 1757 UTC.

One of its flag­ship tech­nolo­gies, Copilot, also suf­fered. From 1629 UTC on February 9 to 0957 UTC on February 10, GitHub re­ported prob­lems in Copilot pol­icy prop­a­ga­tion for some users. The code shack said: “This may pre­vent newly en­abled mod­els from ap­pear­ing when users try to ac­cess them.”

And so it goes on. GitHub changed its sta­tus page a while ago, mak­ing it harder to vi­su­al­ize the avail­abil­ity of its ser­vices. Yes, the de­tails are front and cen­ter, but get­ting a sense of how things have gone over the last 90 days, par­tic­u­larly over­all up­time, is trick­ier.

The “missing” sta­tus page ex­ists in re­con­structed form via the pub­lic sta­tus feed, though this is an un­of­fi­cial source so re­quires cau­tion. It re­veals that GitHub’s sta­bil­ity has been poor: up­time dropped be­low 90 per­cent at one point in 2025.

The code shack is­n’t alone in ex­pe­ri­enc­ing ser­vice in­sta­bil­ity. While five nines (99.999 per­cent up­time) rep­re­sents the gold stan­dard, some ven­dors strug­gle to main­tain even 90 per­cent — a con­cern for cus­tomers re­ly­ing on these plat­forms.

GitHub’s Service Level Agreement for Enterprise Cloud cus­tomers spec­i­fies 99.9 per­cent up­time, al­though the com­pany does not guar­an­tee this for all users.

The tra­vails of GitHub cus­tomers high­light the need to plan for down­time as well as up­time. ®

The Tin Can phone is meant for kids, like an old school land­line.

An icon in the shape of a light­ning bolt.

This story is avail­able ex­clu­sively to Business Insider

sub­scribers. Become an Insider

and start read­ing now.

Have an ac­count? .

Tin Can is a kid-friendly WiFi phone that repli­cates an old-fash­ioned land­line.

It’s aimed at par­ents who want to de­lay giv­ing their kids a cell­phone.

“It’s im­por­tant for kids to have so­cial au­ton­omy,” the co­founder tells Business Insider.

Alison Bennett, a mom in Los Angeles, has been go­ing “full ’90s” in her ef­forts to avoid buy­ing her 8-year-old a phone. Bennett bought her an MP3 player for mu­sic, rents DVDs for movies, and gets pa­per de­liv­ery of the Los Angeles Times.

Now, she’s found an­other way to put off get­ting her daugh­ter a cell­phone: She or­dered three $75 Tin Can “landline” phones — one for her 8-year-old daugh­ter, and two for friends.

“I want my daugh­ter to be able to chat with her friends, like I did as a child in the ’90s” Bennett said — with­out wor­ry­ing about all the other stuff that comes with a mo­bile phone. She said she heard about the Tin Can on a Facebook group.

Tin Can is a phone that runs off your home’s WiFi. It’s sim­i­lar to a reg­u­lar VoIP phone, ex­cept that it has parental con­trols so that only ap­proved con­tacts can call, and only dur­ing ap­proved hours. There’s also a free plan where Tin Can users can call only other Tin Can users.

The com­pany was founded last fall by three friends in the Seattle area. Two of them were dads, and they wanted to cre­ate a phone for their own kids. They sat around the kitchen table with sol­der­ing irons, work­ing on a pro­to­type with an old corded land­line phone.

“We did­n’t know if this would be a busi­ness or a cool walkie-talkie,” Chet Kittleson, co­founder of Tin Can, said in an in­ter­view.

Soon, they started giv­ing a few of these phones to their kids’ friends so they would have some­one to talk to.

“I was like, ‘Let’s just see if our kids use it,’” Kittleson said. “They lost their minds. Kids used the crap out of the thing. They were so ex­cited when it rang, they would jump over the couch.”

The com­pany has raised $3.5 mil­lion so far, a spokesper­son said, in­clud­ing from Pioneer Square Ventures, Newfund Capital, Mother Ventures, and Solid Foundation, among a few oth­ers. The are seven full-time em­ploy­ees, in­clud­ing Kittleson and his co-founders, Max Blumen and Graeme Davies.

Kittleson said they’ve sold “tens of thou­sands” of the phones since launch­ing in early 2025 — and tens of thou­sands just in the last month. They’re back­o­rdered un­til December.

The Tin Can comes as a newish move­ment of par­ents are want­ing to de­lay giv­ing older kids and tweens a phone un­til as late as pos­si­ble — some not un­til high school, even.

But that leaves kids stuck with­out a way to com­mu­ni­cate with friends, and forces par­ents to act as their kids’ so­cial sec­re­tary, field­ing texts from other par­ents to set up play­dates or other com­mu­ni­ca­tions.

There’s also a mar­ket for older kids who aren’t quite ready for a full cell­phone, but need to com­mu­ni­cate with par­ents or friends. This mar­ket is mainly served by a va­ri­ety of smart­watches, flip phones, or de­vices from com­pa­nies like Gabb, Troomi, or Pinwheel that are usu­ally Android smart­phones with heavy parental con­trol soft­ware.

But a WiFi “landline” phone is some­thing dif­fer­ent than just a safe cell­phone — and some par­ents are re­dis­cov­er­ing it.

An added ben­e­fit is giv­ing kids a crash course in phone eti­quette. (Alarmingly, some Gen Zers don’t say “hello” when they an­swer a phone call; they ex­pect the caller to just start talk­ing.)

I started see­ing moms talk about the Tin Can on a few dif­fer­ent Facebook groups in late August. (That’s where I heard Bennett say she had bought one.) By the time I men­tioned to other par­ents at Business Insider that I was work­ing on this story, a bunch of them had al­ready heard about the prod­uct.

Kittleson said part of his mo­ti­va­tion in cre­at­ing the phone was men­tal health. “I want to cre­ate a world where, struc­turally, my kids are less likely to be anx­ious,” he said. “And I think all this stuff [social me­dia] can def­i­nitely be a cause of anx­i­ety.”

When Kittleson gave the first Tin Can pro­to­type to his daugh­ter and a few of her friends, he said they were thrilled. But he was even more de­lighted when he dis­cov­ered that his daugh­ter and her friend had set up a play­date all on their own — using their Tin Cans — no par­ents needed. He dropped her off at the friend’s house and mar­veled at how easy it was.

“It’s im­por­tant for kids to have so­cial au­ton­omy — in­de­pen­dence to con­nect with peo­ple they want to con­nect with,” Kittleson said. “If we push back the age for cell­phones, which I be­lieve we should, then we must find an al­ter­na­tive. That’s the role I see Tin Can play­ing.”

GrapheneOS, the pri­vacy-fo­cused Android fork, said in a post on X on Friday that it will not com­ply with emerg­ing laws re­quir­ing op­er­at­ing sys­tems to col­lect user age data at setup. “GrapheneOS will re­main us­able by any­one around the world with­out re­quir­ing per­sonal in­for­ma­tion, iden­ti­fi­ca­tion or an ac­count,” the pro­ject stated. “If GrapheneOS de­vices can’t be sold in a re­gion due to their reg­u­la­tions, so be it.”

The state­ment came af­ter Brazil’s Digital ECA (Law 15.211) took ef­fect on March 17, im­pos­ing fines of up to R$50 mil­lion (roughly $9.5 mil­lion) per vi­o­la­tion on op­er­at­ing sys­tem providers that fail to im­ple­ment age ver­i­fi­ca­tion. California’s Digital Age Assurance Act (AB-1043), signed by Governor Newsom in October 2025, takes ef­fect on January 1, 2027, and re­quires every OS provider to col­lect a user’s age or date of birth dur­ing ac­count setup and pipe that data to app stores and de­vel­op­ers through a real-time API. Colorado’s SB26-051 passed the state sen­ate on March 3 with sim­i­lar re­quire­ments.

GrapheneOS is de­vel­oped by the GrapheneOS Foundation, a reg­is­tered Canadian non­profit. None of these laws orig­i­nate in Canada, but ques­tions around ju­ris­dic­tion re­main open. U. S. fed­eral pros­e­cu­tors suc­cess­fully ex­tra­dited and con­victed the de­vel­op­ers of Samourai Wallet, a pri­vacy-fo­cused Bitcoin mixer, in a case where one de­fen­dant lived in Portugal. California’s AB-1043 car­ries civil penal­ties of up to $2,500 per af­fected child for neg­li­gent vi­o­la­tions and $7,500 for in­ten­tional ones, en­forced by the state at­tor­ney gen­eral.

Motorola and GrapheneOS an­nounced a long-term part­ner­ship at MWC on March 2, to bring to bring the hard­ened OS to fu­ture Motorola hard­ware, end­ing GrapheneOS’s long-stand­ing ex­clu­siv­ity to Google Pixel de­vices. A GrapheneOS-powered Motorola phone is ex­pected in 2027. If Motorola sells de­vices with GrapheneOS pre-in­stalled, those de­vices would need to com­ply with lo­cal reg­u­la­tions in every mar­ket where they ship, or Motorola may need to re­strict sales ge­o­graph­i­cally.

GrapheneOS is­n’t the first and won’t be the last com­pany to out­right refuse com­pli­ance with in­com­ing age ver­i­fi­ca­tion laws. The de­vel­op­ers of open-source cal­cu­la­tor firmware DB48X is­sued a le­gal no­tice re­cently, stat­ing that their soft­ware “does not, can­not and will not im­ple­ment age ver­i­fi­ca­tion,” while MidnightBSD up­dated its li­cense to ban users in Brazil.

California’s law does­n’t re­quire photo ID or bio­met­ric ver­i­fi­ca­tion; users sim­ply self-re­port their age dur­ing setup. Critics, in­clud­ing over 400 com­puter sci­en­tists who signed an open let­ter, have ar­gued that the laws cre­ate sur­veil­lance in­fra­struc­ture with­out mean­ing­fully pro­tect­ing chil­dren, since self-de­c­la­ra­tion is triv­ially by­passed.

Follow Tom’s Hardware on Google News, or add us as a pre­ferred source, to get our lat­est news, analy­sis, & re­views in your feeds.

As of 08:00 lo­cal time at Terminal B, from where Air Canada op­er­ates, a board showed every de­part­ing flight for Monday morn­ing, bar one, had been can­celled. Confused pas­sen­gers were seen hud­dled on benches or sleep­ing on the floor. Many had small chil­dren with them.

In 1944, the Wehrmacht launched into Hitler’s last ditch ef­fort to save the Third Reich. The Battle of the Bulge was a doomed cam­paign and a doomed gam­ble from a doomed regime, but its bru­tal­ity was a true sec­ond test of the US Army on the Western Front. During the bat­tle, Army his­to­rian S. L.A Marshall be­gan in­ter­view­ing in­fantry com­pa­nies who’d been bap­tised in com­bat. Published 3 years later in his 1947 book, Men Against Fire, Marshall’s re­search showed that just 15-20% of ri­fle­men in ac­tive com­bat po­si­tions ever fired their weapons - most kept their heads down. They moved when they were or­dered and they held their po­si­tions, and they mim­ic­ked the out­ward ap­pear­ance of a sol­dier in bat­tle - but shoot, they did not. By any stan­dard or­gan­i­sa­tional met­ric, the men were pre­sent and ac­counted for, but 4 out of 5 never pulled the trig­ger.

You can de­bate the ex­tent of Marshall’s num­bers, and you can de­bate his method­ol­ogy, but his ra­tio shows up, again and again. IBM stum­bled onto it in the ’60s when they dis­cov­ered that 80% of com­puter us­age came from 20% of the sys­tem’s fea­tures. The pat­tern re­curs be­cause it de­scribes some­thing real about how ef­fort is dis­trib­uted in­side groups, where a frac­tion of the peo­ple do most of the work, and the rest pro­vide what you might ~charitably call “structural sup­port.”

Anyone who has worked in any large or­gan­i­sa­tion knows ex­actly what I’m talk­ing about.

The mod­ern tech in­dus­try looked at the prob­lem of hu­man co­or­di­na­tion and par­tic­i­pa­tion and de­cided the so­lu­tion was “collaboration.” If only 20% of us are op­er­at­ing with a “killer in­stinct” we need to be bet­ter at man­ag­ing the shared in­stincts of the other 80%. And so col­lab­o­ra­tion be­came our shared ob­ses­sion. We pur­sue “teamwork” as a holy grail.

The team­work rev­o­lu­tion, if you can call it that, gave us Notion for our doc­u­ments, ClickUp for our tasks, Slack for our con­ver­sa­tions, Jira for our tick­ets, Monday for our boards, Teams for the calls that should been emails, emails for the things that we could­n’t squeeze in any­where else, and now agents at­tempt­ing to re-in­vent the whole stack. The av­er­age knowl­edge worker main­tains ac­counts across sys­tem af­ter sys­tem, switch­ing be­tween ap­pli­ca­tions hun­dreds of times per day. And they pro­duce, in ag­gre­gate, a stag­ger­ing amount of co­or­di­nated and col­lab­o­ra­tive ac­tiv­ity that never ac­tu­ally be­comes any­thing re­sem­bling ~output.

When you strip away the prod­uct mar­ket­ing and the dev re­la­tions and the blog posts and the fund­ing rounds and the fuck­ery-upon-fuck­ery of it all, we’re left with a sim­u­la­tion of col­lec­tive en­gage­ment - but very lit­tle else. Transparency got con­fused with progress, vis­i­bil­ity got con­fused with ac­count­abil­ity, and be­ing in­cluded in the thread be­came the same thing, so­cially and or­ga­ni­za­tion­ally, as own­ing the out­come.

Once that con­fu­sion set in at the cul­tural level it be­came nearly im­pos­si­ble to dis­lodge. The feel­ing of col­lab­o­ra­tion is pleas­ant in a way that per­sonal ac­count­abil­ity can never be. Owning some­thing means you, specif­i­cally and vis­i­bly you, can fail at it, specif­i­cally and vis­i­bly, in ways that at­tach to your name.

Collaborating means the fail­ure be­longs to the process.

So every­one chose col­lab­o­ra­tion, and we called it cul­ture.

Marshall’s ri­fle­men were or­di­nary peo­ple re­spond­ing to the dif­fu­sion of re­spon­si­bil­ity that hap­pens in­side any group. Maximilien Ringelmann mea­sured the same phe­nom­e­non with ropes in 1913, long be­fore there were Slack work­spaces to of­fer an emoji-re­act to it. Individual ef­fort drops pre­dictably as group size in­creases. The pres­ence of oth­ers dis­solves the sense of per­sonal re­spon­si­bil­ity in a way that feels, to every­one ex­pe­ri­enc­ing it, en­tirely rea­son­able. You’re part of a team, you’re con­tribut­ing, you’re also (measurably) pulling less hard than you would if the rope were yours alone. Every sin­gle per­son on the rope is do­ing this si­mul­ta­ne­ously, which is why the to­tal force never adds up the way the head­count says it should.

Frederick Brooks iden­ti­fied the same dy­namic in soft­ware de­vel­op­ment in 1975, watch­ing IBM’s System/360 pro­ject il­lus­trate his emerg­ing the­sis that adding peo­ple to a late pro­ject makes it later. Communication over­head grows faster than head­count, co­or­di­na­tion costs com­pound, and every new per­son con­tributes their ca­pac­ity along with their re­la­tion­ships to every­one else. Those re­la­tion­ships re­quire main­te­nance and pro­duce mis­align­ment and gen­er­ate the need for more meet­ings to ad­dress the mis­align­ment those meet­ings cre­ated.

Brooks might as well have de­scribed your com­pa­ny’s Q3 roadmap plan­ning cy­cle and your star­tup’s sprint ret­ro­spec­tive, all of which have got­ten longer every year and pro­duced, rel­a­tive to their in­vest­ment, less.

The col­lab­o­ra­tion in­dus­try has spent a for­tune ob­scur­ing a dirty truth: most com­plex, high-qual­ity work is done by in­di­vid­u­als or very small groups op­er­at­ing with clear au­thor­ity and sharp ac­count­abil­ity, then ra­tio­nal­ized into the lan­guage of team­work af­ter­ward. Dostoevsky wrote _The Brothers Karamazov_ alone. The Apollo Guidance Computer came from a team at MIT small enough to have real own­er­ship, hi­er­ar­chi­cal enough that Margaret Hamilton’s name could go on the er­ror-de­tec­tion rou­tines she per­son­ally de­signed.

Communication mat­ters, and shared con­text mat­ters. But there’s a huge dif­fer­ence be­tween com­mu­ni­ca­tion and col­lab­o­ra­tion as in­fra­struc­ture to sup­port in­di­vid­ual, high-agency own­er­ship, and com­mu­ni­ca­tion and col­lab­o­ra­tion as the pri­mary ac­tiv­ity of an or­gan­i­sa­tion. Which, if we’re hon­est, is what most col­lab­o­ra­tion-first cul­tures have ac­tu­ally built. They’ve con­structed ex­tra­or­di­nar­ily so­phis­ti­cated ma­chin­ery for the so­cial man­age­ment of work, with­out ac­tu­ally do­ing the work they’re so­cial­is­ing about.

If and when it ex­ists, own­er­ship looks like an in­di­vid­ual who deeply gives a shit, mak­ing a call with­out wait­ing for group-con­sen­sus. That in­di­vid­ual will be right some­times, and they’ll be wrong other times, and they’ll own it. They won’t sit around wait­ing to find out who has the au­thor­ity to move a card from one col­umn to an­other and post about it in the #celebrations  chan­nel.

But be­ing that per­son sucks when “collaboration” is the reign­ing value, be­cause every uni­lat­eral de­ci­sion gets read as a cul­tural vi­o­la­tion and a sig­nal that you aren’t a team player. Collaboration-as-ideology has made own­er­ship and re­spon­si­bil­ity feel an­ti­so­cial, which is a hell of a thing, given that own­er­ship is the only mech­a­nism that gets any­thing across the fin­ish line.

You can see this ex­cess every­where. Standups where peo­ple an­nounce their busy work and as long as every­one’s “on the same page” no­body changes course. Documents that are writ­ten to per­form think­ing so some­body else can per­form think­ing, with no de­ci­sion in sight. Retros, and kick­offs, and WIP meet­ings that spawn their own ret­ros, kick­offs and WIP meet­ings like cells di­vid­ing and re-di­vid­ing, with zero con­nec­tion to the work that it’s nom­i­nally or­gan­is­ing around.

Every pro­ject now seems to carry more co­or­di­na­tion over­head than ex­e­cu­tion time, and when it fails the post­mortem just rec­om­mends more col­lab­o­ra­tion…

At some point (and I think that point was fuck­ing yes­ter­day) we have to ask our­selves - what are we ac­tu­ally pro­duc­ing and who is ac­tu­ally re­spon­si­ble for pro­duc­ing it?

Because at some level, the an­swer for “who is re­spon­si­ble for X” has to be one sin­gle per­son, no mat­ter how much the col­lab­o­ra­tive ap­pa­ra­tus lay­ered over mod­ern work has been en­gi­neered to make that per­son in­vis­i­ble and dis­solve ac­count­abil­ity.

We need to find some path back to trust­ing that in­di­vid­u­als will do their jobs, with­out every re­spon­si­bil­ity be­ing vis­i­ble to an en­tire or­gan­i­sa­tion, with­out fol­low-ups be­ing sched­uled by a cadre of over­paid man­agers with their overfed met­rics.

Maybe - just maybe - we could make our lives a lit­tle eas­ier. Maybe we could let hu­man be­ings keep their own lists of tasks, and we could let them sink or swim by how they man­age those tasks, and we could as­sign blame to them and to them alone when they fuck up. Maybe we could do it with­out need­ing to have team-level views of every Kanban, cal­en­dar and task list. And maybe - if we let go of the warm, ex­pen­sive fic­tion of col­lec­tive en­deav­our - we could make it a lit­tle eas­ier to see who among us are pulling the trig­ger and who are just keep­ing their heads down.

Skip to con­tent

Secure your code as you build

We read every piece of feed­back, and take your in­put very se­ri­ously.

Include my email ad­dress so I can be con­tacted

Use saved searches to fil­ter your re­sults more quickly

To see all avail­able qual­i­fiers, see our doc­u­men­ta­tion.

Sign up

You signed in with an­other tab or win­dow. Reload to re­fresh your ses­sion.

You signed out in an­other tab or win­dow. Reload to re­fresh your ses­sion.

You switched ac­counts on an­other tab or win­dow. Reload to re­fresh your ses­sion.

Notifications

You must be signed in to change no­ti­fi­ca­tion set­tings

Runs in your lo­cal de­vel­oper en­vi­ron­ment, in CI, and in­side Antithesis.

Bombadil is new and ex­per­i­men­tal. Stuff is go­ing to change in the early days. Even so, we hope you’ll try it out!

Learn all about Bombadil with the fol­low­ing re­sources:

Or, if you want to hack on it, see Contributing.

Old Tom Bombadil is a merry fel­low,

Bright blue his jacket is, and his boots are yel­low.

Bugs have never fooled him yet, for Tom, he is the Master:

His specs are stronger specs, and his fuzzer is faster.

There was an er­ror while load­ing. Please re­load this page.

There was an er­ror while load­ing. Please re­load this page.

You can’t per­form that ac­tion at this time.

If DSPy is So Great, Why Isn’t Anyone Using It?

View more blogs with the tag ai View more blogs with the tag ai  , View more blogs with the tag dspy View more blogs with the tag dspy  , View more blogs with the tag en­gi­neer­ing View more blogs with the tag en­gi­neer­ing  , View more blogs with the tag llm

The evo­lu­tion of every AI sys­tem Stage 2: “Can we tweak the prompt with­out de­ploy­ing?” Stage 6: “How do we know if this is get­ting bet­ter?” What this looks like with DSPy What you should ac­tu­ally do

For a frame­work that promises to solve the biggest chal­lenges in AI en­gi­neer­ing, this gap is sus­pi­cious. Still, com­pa­nies us­ing Dspy con­sis­tently re­port the same ben­e­fits.

They can test a new model quickly, even if their cur­rent prompt does­n’t trans­fer well. Their sys­tems are more main­tain­able. They are fo­cus­ing on the con­text more than the plumb­ing.

So why aren’t more peo­ple us­ing it?

DSPy’s prob­lem is­n’t that it’s wrong. It’s that it’s hard. The ab­strac­tions are un­fa­mil­iar and force you to think a litle bit dif­fer­ently. And what you want right now is not to think dif­fer­ently; you just want the pain to go away.

But I keep watch­ing the same thing hap­pen: peo­ple end up im­ple­ment­ing a worse ver­sion of Dspy. I like to jok­ingly say there’s a Khattab’s Law now (based off of Greenspun’s Law about Common Lisp):

You’re go­ing to build these pat­terns any­way. You’ll just do it worse, af­ter a lot of time, and through a lot of pain.

Let’s walk through how vir­tu­ally every team ends up im­ple­ment­ing their own “Dspy at home”. We’ll use a sim­ple struc­tured ex­trac­tion task as an ex­am­ple through­out. Don’t let the sim­plic­ity of the ex­am­ple fool you though; these pat­terns only be­come more im­por­tant as the sys­tem be­comes more com­plex.

Let’s say you need to ex­tract com­pany names from some text, you might start out with the OpenAI API:

It ba­si­cally works. So you ship it and life is good.

But in­evitably, Product will want to it­er­ate faster. Redeploying for every prompt change is too an­noy­ing. So you de­cide to store prompts in a data­base:

Now you have a prompts table, a lit­tle ad­min UI to edit it. And of course you had to add ver­sion his­tory af­ter some­one broke prod last Tuesday.

You no­tice the model some­times re­turns “Company: Acme Corp” in­stead of just “Acme Corp”. So you add struc­tured out­puts:

You now have typed in­puts and out­puts and higher con­fi­dence the sys­tem is do­ing what it should.

After run­ning for a while, you’ll no­tice tran­sient fail­ures like 529 er­rors or rare cases where pars­ing fails. So you add re­tries:

Now each call has a bit more re­silience. Though, in prac­tice you might fall­back to a dif­fer­ent provider be­cause retry­ing against an over­loaded ser­vice re­turn­ing 529s is a recipe for… an­other 529 er­ror.

Eventually, you might start pars­ing more es­o­teric com­pany names, and the model might not be good enough to rec­og­nize an en­tity as a com­pany name. So you want to add RAG against known com­pany in­for­ma­tion to help im­prove the ex­trac­tion:

Now we have two prompts: one to cre­ate the query and one to cre­ate parse the com­pany. And we have also in­tro­duced other pa­ra­me­ters like k. It’s worth not­ing that not all of these pa­ra­me­ters are in­de­pen­dent. Since the re­trieved doc­u­ments feed into the fi­nal prompt, any changes here af­fect the over­all per­for­mance.

You keep chang­ing both prompts, the em­bed­ding model, k, and any pa­ra­me­ter you can get your hands on to fix bugs as they are re­ported. But you’re never quite sure if your change com­pletely fixed the is­sue. And you’re never quite sure if your changes broke some­thing else. So you fi­nally re­al­ize you need those “evals” every­one is talk­ing about:

Data ex­trac­tion tasks are amongst the eas­i­est to eval­u­ate be­cause there’s a known “right” an­swer. But even here, we can imag­ine some of the com­plex­ity. First, we need to make sure that the dataset passed in is al­ways rep­re­sen­ta­tive of our real data. And gen­er­ally: your data will shift over time as you get new users and those users start us­ing your plat­form more com­pletely. Keeping this dataset up to date is a key main­te­nance chal­lenge of evals: mak­ing sure the eval mea­sures some­thing you ac­tu­ally (and still) care about.

Inevitably, some com­pany will re­lease a new model that’s ex­cit­ing that some­one will want to try. Let’s say Anthropic re­leases a new model. Unfortunately, your code is full of ope­nai.chat.com­ple­tions.cre­ate, which won’t ex­actly work for Anthropic. Your prompts might not even work well with the new model.

So you de­cide you need to refac­tor every­thing:

You now have typed sig­na­tures, com­pos­able mod­ules, swap­pable back­ends, cen­tral­ized retry logic, and prompt man­age­ment sep­a­rated from ap­pli­ca­tion code.

Congrats! You just built a worse ver­sion of Dspy.

Here’s the same com­pany ex­trac­tion task — with RAG, eval­u­a­tion, and model swap­ping — in DSPy:

That’s it. Typed I/O, RAG, chain-of-thought rea­son­ing, model-ag­nos­tic. No prompt man­age­ment table. No retry dec­o­ra­tors. No get_prompt(“ex­trac­t_­com­pa­ny_v3”).

Want to try Claude in­stead? One line:

No refac­tor. No new API client. No re-tun­ing prompts by hand. The op­ti­mizer can even re-op­ti­mize for the new model au­to­mat­i­cally!

Dspy pack­ages im­por­tant pat­terns every se­ri­ous AI sys­tem ends up need­ing:

These are just soft­ware en­gi­neer­ing fun­da­men­tals. Separation of con­cerns. Composability. Declarative in­ter­faces. But for some rea­son, many good en­gi­neers ei­ther for­get about these or strug­gle to ap­ply them to AI sys­tems.

So en­gi­neers do what works in the mo­ment. Inline prompts. Copy-paste with tweaks. One-off so­lu­tions that be­come per­ma­nent.

But 6 months later, they are drown­ing in the com­plex­ity of their half-baked ab­strac­tions.

DSPy has adop­tion prob­lems be­cause it asks you to think dif­fer­ently be­fore you’ve ac­tu­ally felt the pain of think­ing the same way every­one else does.

The pat­terns DSPy em­bod­ies aren’t op­tional. If your AI sys­tem gets com­plex enough, you will rein­vent them. The only ques­tion is whether you do it de­lib­er­ately or ac­ci­den­tally.

You don’t have to use DSPy. But you should build like some­one who un­der­stands why it ex­ists.

If this res­onated, let’s con­tinue the con­ver­sa­tion on X or LinkedIn!

Add AP News as your pre­ferred source to see more of our sto­ries on Google.

Add AP News as your pre­ferred source to see more of our sto­ries on Google.

HANOI, Vietnam (AP) — The war in Iran is ex­pos­ing the world’s re­liance on frag­ile fos­sil fuel routes, lend­ing ur­gency to calls for has­ten­ing the shift to re­new­able en­ergy.

Fighting has all but halted oil ex­ports through the Strait of Hormuz, the nar­row wa­ter­way that car­ries about a fifth of the world’s oil and liq­ue­fied nat­ural gas, or LNG. The dis­rup­tion has jolted en­ergy mar­kets, push­ing up prices and strain­ing im­port-de­pen­dent economies.

Asia, where most of the oil was headed, has been hit hard­est, but the dis­rup­tions also are a strain for Europe, where pol­i­cy­mak­ers are look­ing for ways to cut en­ergy de­mand, and for Africa, which is brac­ing for ris­ing fuel costs and in­fla­tion.

Unlike dur­ing pre­vi­ous oil shocks, re­new­able power is now com­pet­i­tive with fos­sil fu­els in many places. More than 90% of new re­new­able power pro­jects world­wide in 2024 were cheaper than fos­sil-fuel al­ter­na­tives, ac­cord­ing to the International Renewable Energy Agency.

Oil is used in many in­dus­tries be­yond gen­er­at­ing elec­tric­ity, such as fer­til­izer and plas­tics pro­duc­tion. So most coun­tries are feel­ing the im­pact, while those with more re­new­able power are more in­su­lated since re­new­ables rely on do­mes­tic re­sources like sun and wind, not im­ported fu­els.

“These crises reg­u­larly oc­cur,” said James Bowen of the Australia-based con­sul­tancy, ReMap Research. “They are a fea­ture, not a bug, of a fos­sil fuel-based en­ergy sys­tem.”

China and India, the world’s two most pop­u­lous coun­tries, face the same chal­lenge of gen­er­at­ing enough elec­tric­ity to power growth for over a bil­lion peo­ple. Both have ex­panded re­new­able en­ergy, but China did so on a far larger scale de­spite its con­tin­ued re­liance on coal-fired power.

Today China leads the world in re­new­ables. About one in 10 cars in China are elec­tric, found the International Energy Agency. It’s still the world’s largest im­porter of crude oil and the biggest buyer of Iranian oil. But elec­tri­fy­ing parts of its econ­omy with re­new­ables has re­duced its re­liance on im­ports.

Without that shift, China would be “far more vul­ner­a­ble to sup­ply and price shocks,” said Lauri Myllyvirta of the Centre for Research on Energy and Clean Air. China also can rely on re­serves built when prices were low and shift be­tween us­ing coal and oil as fuel in fac­to­ries, he said.

India also has ex­panded its use of clean en­ergy, es­pe­cially so­lar power, but more slowly and with less gov­ern­ment sup­port for man­u­fac­tur­ing re­new­able en­ergy equip­ment and con­nect­ing so­lar to its power grid.

After Russia’s in­va­sion of Ukraine in 2022, India pri­or­i­tized en­ergy se­cu­rity by buy­ing dis­counted Russian oil and boost­ing coal pro­duc­tion. It also ramped up so­lar and wind, help­ing to cush­ion sup­ply dis­rup­tions but not avoid them en­tirely, said Duttatreya Das of the think tank Ember.

“Everyone can­not be China,” Das said.

India is now fac­ing a short­age of cook­ing gas. That’s dri­ving a rush to buy in­duc­tion cook­tops and rais­ing fears of restau­rant shut­downs. Fertilizers and ce­ram­ics in­dus­tries may also be hit.

The en­ergy shock is fa­mil­iar to wealthy coun­tries in Europe and East Asia.

In 2022, some European gov­ern­ments tried to cut de­pen­dence on fos­sil fu­els. But many soon fo­cused on find­ing new fos­sil fuel sup­pli­ers in­stead, said Pauline Heinrichs, who stud­ies cli­mate and en­ergy at King’s College London.

Germany rushed to build LNG ter­mi­nals to re­place Russian gas with mostly American fuel while the en­ergy tran­si­tion, in­clud­ing ef­forts to cut de­mand, slowed, she said.

Europe’s ex­cess spend­ing on fos­sil fu­els since the Russia-Ukraine War amounted to about 40% of the in­vest­ment needed to tran­si­tion its power sys­tem to clean en­ergy, ac­cord­ing to a 2023 study.

“In Europe, we learned the wrong les­son,” Heinrichs said.

In im­port-de­pen­dent Japan, pol­icy re­sponses to past shocks have fo­cused on di­ver­si­fy­ing fos­sil fuel im­ports rather than in­vest­ing in do­mes­tic re­new­ables, said Ayumi Fukakusa of Friends of the Earth Japan.

Solar and wind make up just 11% of Japan’s en­ergy pro­duc­tion, on a par with India but be­hind China’s 18%, ac­cord­ing to Ember. Japan’s en­ergy use is much lower than both na­tions.

The Iran war led the agenda dur­ing Japanese Prime Minister Sanae Takaichi ’s meet­ing this week with U. S. President Donald Trump. Trump, who has long urged Japan to buy more American LNG, re­cently called on al­lied na­tions like Japan to “step up” in as­sist­ing se­cure The Strait of Hormuz.

South Korean President Lee Jae-myung said the cri­sis could be “a good op­por­tu­nity” to shift faster to re­new­able en­ergy.

Poorer na­tions in Asia and Africa are com­pet­ing with wealthy European and Asian coun­tries and big buy­ers like India and China for lim­ited gas sup­plies, push­ing up prices.

Import-dependent economies — such as Benin and Zambia in Africa and Bangladesh and Thailand in Asia — could face some of the biggest shocks. Costly fuel makes trans­port and food more ex­pen­sive, and many coun­tries have lim­ited for­eign-ex­change re­serves, re­strict­ing their abil­ity to pay for im­ports if prices stay high.

Africa may be es­pe­cially ex­posed be­cause many coun­tries rely on im­ported oil to run their trans­port and sup­ply chains.

It makes strate­gic sense for African coun­tries to build their long-term en­ergy se­cu­rity by in­vest­ing in cleaner en­ergy, said Kennedy Mbeva, a re­search as­so­ci­ate at the Centre for the Study of Existential Risk at the University of Cambridge.

But not all are opt­ing for re­new­ables: South Africa is con­sid­er­ing build­ing an LNG im­port ter­mi­nal and new gas-fired power plants.

Others, like Ethiopia which banned gaso­line and diesel fu­eled cars in 2024 to pro­mote elec­tric ve­hi­cles, are dou­bling down on re­new­ables.

The real chal­lenge is not just to with­stand the next shock, but to en­sure it does­n’t “derail the coun­try’s de­vel­op­ment tra­jec­tory,” said Hanan Hassen, an an­a­lyst at Ethiopia’s gov­ern­ment-linked think tank, the Institute of Foreign Affairs.

Increased use of re­new­able en­ergy has helped shield some Asian coun­tries from the en­ergy shock.

Pakistan’s so­lar boom has pre­empted more than $12 bil­lion in fos­sil fuel im­ports since 2020 and could save an­other $6.3 bil­lion in 2026 at cur­rent prices, ac­cord­ing to think tanks Renewables First and the Centre for Research on Energy and Clean Air.

Vietnam’s cur­rent so­lar gen­er­a­tion will help the coun­try save hun­dreds of mil­lions of dol­lars in po­ten­tial coal and gas im­ports in the com­ing year, based on cur­rent high prices, ac­cord­ing to the re­search group, Zero Carbon Analytics.

Bangladesh has closed uni­ver­si­ties to save elec­tric­ity. It has lim­ited stor­age ca­pac­ity to ab­sorb sup­ply shocks, so the gov­ern­ment started ra­tioning fuel af­ter a flurry of panic buy­ing at fill­ing sta­tions, said Khondaker Golam Moazzem, an econ­o­mist with the Centre for Policy Dialogue in Dhaka.

For now, gov­ern­ments must just man­age short­ages and con­trol prices. Thailand has sus­pended pe­tro­leum ex­ports, boosted its gas pro­duc­tion and be­gun draw­ing on re­serves.

If the con­flict bleeds into April, Thailand’s fi­nite re­serves and lim­ited bud­get for sub­si­dies mean prices will shoot higher, warned Areeporn Asawinpongphan, a re­search fel­low with the Thailand Development Research Institute.

“The time for pro­mot­ing do­mes­tic re­new­ables should have hap­pened a long time ago,” Asawinpongphan said.

Delgado re­ported from Bangkok, Thailand, and Olingo re­ported from Nairobi, Kenya.

The Associated Press’ cli­mate and en­vi­ron­men­tal cov­er­age re­ceives fi­nan­cial sup­port from mul­ti­ple pri­vate foun­da­tions. The AP is solely re­spon­si­ble for all con­tent. Find AP’s stan­dards for work­ing with phil­an­thropies, a list of sup­port­ers and funded cov­er­age ar­eas at AP.org.