Nvidia has been in talks to ac­quire Hugging Face, the pop­u­lar AI plat­form for shar­ing and build­ing with open-source mod­els, in what could be one of the chip gi­ant’s biggest deals yet.

The two par­ties have had ac­qui­si­tion con­ver­sa­tions in re­cent weeks about a deal that would value Hugging Face at more than $13 bil­lion, ac­cord­ing to a per­son fa­mil­iar with the mat­ter. The com­pa­nies have not yet reached a deal, and the talks could still fall apart, the per­son said. Business Insider on Sunday was the first to re­port that Hugging Face was field­ing takeover in­ter­est.

Nvidia and Hugging Face did not re­spond to re­quests for com­ment.

Nvidia has in­creas­ingly ramped up deal­mak­ing with its enor­mous cash pile. The com­pany said Wednesday that it has $18 bil­lion com­mit­ted to eq­uity in­vest­ments for the rest of its fis­cal year, on top of $47.9 bil­lion it al­ready holds in pri­vate com­pa­nies.

Microsoft also met with Hugging Face, but the per­son fa­mil­iar and a sec­ond per­son said talks are not on­go­ing.

Nvidia al­ready has a re­la­tion­ship with Hugging Face. The chip­maker par­tic­i­pated in its $235 mil­lion fund­ing round in 2023 that val­ued it at $4.5 bil­lion.

Hugging Face turned down a $500 mil­lion in­vest­ment of­fer from Nvidia late last year that would have val­ued it at $7 bil­lion, the Financial Times pre­vi­ously re­ported. Hugging Face said at the time it did not want a dom­i­nant in­vestor that could sway de­ci­sions.

Hugging Face sits at the cen­ter of the open-source AI ecosys­tem, host­ing mil­lions of AI mod­els and datasets that de­vel­op­ers can build on. Owning the plat­form could give Nvidia a big­ger foothold with those de­vel­op­ers — and po­ten­tially drive more work­loads onto its chips.

Hugging Face was founded in 2016 by French en­tre­pre­neurs Clément Delangue, Julien Chaumond, and Thomas Wolf.

But Nvidia own­er­ship could also com­pli­cate one of Hugging Face’s strengths: its neu­tral­ity. The plat­form sup­ports mod­els and hard­ware from across the in­dus­try, in­clud­ing Nvidia com­peti­tors such as AMD and Intel.

Have a tip?

Contact Katie Roof via email at kroof@busi­nessin­sider.com or Signal at @kroof.26

Contact Geoff Weiss via email at gweiss@busi­nessin­sider.com or Signal at @geoffweiss.25.

Contact Ashley Stewart via email at astew­art@busi­nessin­sider.com or Signal at +1 – 425-344 – 8242.

Use a per­sonal email ad­dress and a non­work de­vice; here’s our guide to shar­ing in­for­ma­tion se­curely.

Read next

Geoff Weiss

You’re cur­rently fol­low­ing this au­thor! Want to un­fol­low? Unsubscribe via the link in your email.

Geoff Weiss is a se­nior re­porter on Business Insider’s tech team, where he writes about AI star­tups and Y Combinator, the in­ter­sec­tion of AI and the me­dia in­dus­try, and work­place dy­nam­ics within top AI labs and chip com­pa­nies.Pre­vi­ously, Geoff was on the me­dia desk, cov­er­ing YouTube and Netflix, and themes like the in­ter­sec­tion of Hollywood and the cre­ator econ­omy. His work on Netflix’s video pod­cast­ing am­bi­tions and Mr Beast’s lessons for Hollywood won sec­ond and first prize, re­spec­tively, at the 2025 LA Press Club Awards.Prior to join­ing Business Insider, Geoff was the se­nior ed­i­tor of Tubefilter and a staff writer at Entrepreneur. He grad­u­ated from New York University with a de­gree in English Literature.He can be reached at gweiss@busi­nessin­sider.com, on Signal @geoffweiss.25, and on LinkedIn. Have a tip? Use a per­sonal email ad­dress and a non­work de­vice; here’s our guide to shar­ing in­for­ma­tion se­curely.Se­lected sto­ries:Nvidia crushed its quar­ter — and CEO Jensen Huang said in a leaked all-hands that ’the mar­ket did not ap­pre­ci­ate it’N­vidia will foot the bill for Trump’s new visa fees. Here’s what CEO Jensen Huang told staff.Mas­sive AI salaries and RTO are fu­el­ing a real es­tate boom in San Francisco: ’It’s go­ing to rain mon­ey’The AI tal­ent wars are ric­o­chet­ing across star­tups. Here’s how they’re com­pet­ing with Big Tech.

Ashley Stewart

You’re cur­rently fol­low­ing this au­thor! Want to un­fol­low? Unsubscribe via the link in your email.

AI

Big Tech

Venture Capital

More

Exclusive

Dolly Parton, one of the great­est singer-song­writ­ers in coun­try mu­sic, who was also much cher­ished for her phil­an­thropy, has died aged 80.

Her death was an­nounced by nephew Brian Seaver on Instagram. “I have imag­ined the heav­i­ness of this mo­ment but haven’t truly felt it un­til now,” he said. “It is an ho­n­our, an ho­n­our that is mixed with ab­solute pride and great sad­ness.”

Parton’s team con­firmed the singer died Tuesday “after bravely fac­ing a brief bat­tle with can­cer.”

“Dolly de­parted her Earthly life to­day at the Vanderbilt-Ingram Cancer Center sur­rounded by loved ones,” the state­ment con­tin­ued.

So gifted that she wrote two of the 20th cen­tu­ry’s great­est songs — Jolene and I Will Always Love You — in a sin­gle day, Parton’s song­writ­ing was char­ac­terised by its vivid sto­ry­telling, emo­tional acu­ity and melodic strength, all sung with stri­dent clar­ity. From an even­tual cat­a­logue of hun­dreds of songs, she scored a record 25 US coun­try No 1 sin­gles and 47 al­bums in the coun­try Top 10. She crossed over into the pop charts with 9 to 5, a US No 1 hit in 1980; bal­anced her mu­sic ca­reer with ac­claimed act­ing, twice earn­ing Golden Globe nom­i­na­tions for her roles; and do­nated more than 300m books to chil­dren through her Imagination Library lit­er­acy pro­ject.

This was all done with con­sid­er­able panache, rhine­stoned glam­our and tow­er­ing hair­dos, with her im­mor­tal as­ser­tion re­gard­ing her ap­pear­ance — “it takes a lot of money to look this cheap” — the most quoted ex­am­ple of Parton’s ready wit.

Parton was born in poverty in a one-room cabin in Tennessee, the fourth child to a mother who would have 12 chil­dren by the age of 35, and a fa­ther who was a farmer and con­struc­tion worker. One of her best-loved songs, Coat of Many Colours, was about her mother cre­at­ing patch­work clothes; Parton’s first gui­tar was cob­bled to­gether from a man­dolin with bass gui­tar strings. Her first proper gui­tar was given to her aged eight by her un­cle, and she went from singing in church to ap­pear­ing on lo­cal tele­vi­sion aged 10, to cut­ting her first record aged 13. That year, she ap­peared at the Grand Ole Opry, the con­cert hall in Nashville at the cen­ter of coun­try mu­sic, and her per­for­mance was in­tro­duced by Johnny Cash. “I’ve al­ways be­lieved things would go well, and I dreamed that they would even be­fore I was in high school,” she later said. “I al­ways wanted to be a star. It just seemed nat­ural to me.”

After grad­u­at­ing high school in 1964, she moved to Nashville and started out as a song­writer rather than per­former. The fol­low­ing year, she was signed as an artist and ini­tially moulded as a pop singer, with­out suc­cess; af­ter she was al­lowed to switch to coun­try, she scored back-to-back hits and re­leased her de­but al­bum Hello, I’m Dolly. In 1966, she mar­ried Carl Dean — who died in 2025, with the cou­ple re­new­ing their vows in 2016 to mark 50 years to­gether.

Beginning in 1967, a duet part­ner­ship with coun­try singer and TV per­son­al­ity Porter Wagoner helped her star con­tinue to as­cend, and she had her first coun­try No 1 in 1971 with the song Joshua.

Jolene, her un­for­get­tably raw and des­per­ate plea to a ri­val lover, was re­leased in 1973 and be­came her first UK suc­cess, reach­ing No 7. I Will Always Love You, writ­ten to Wagoner as a farewell af­ter their cre­ative part­ner­ship ended, was a coun­try No 1 in 1974 and again via a re-recorded ver­sion in 1982, and would go on to be a huge pop suc­cess when re­vived by Whitney Houston for the sound­track of The Bodyguard in 1992: it is still the best­selling sin­gle of all time by a woman, with an es­ti­mated 20m sales.

In the mid 1970s, Parton broad­ened her sound, em­brac­ing pop-rock arrange­ments on songs such as 1977’s Light of a Clear Blue Morning — its ac­com­pa­ny­ing al­bum New Harvest … First Gathering was her first en­try in the pop al­bum chart. Later that year, its fol­low-up, Here You Come Again, reached the Top 20 and was her first mil­lion-sell­ing LP, pow­ered in part by its hit ti­tle track, which also won Parton the first of her 10 Grammy awards.

The year 1980 was a peak in her suc­cess, with three back-to-back coun­try No 1s, in­clud­ing 9 to 5, taken from the film of the same name, which Parton starred in along­side Jane Fonda and Lily Tomlin, earn­ing her an Oscar nom­i­na­tion for best orig­i­nal song. Parton would later write songs for a stage mu­si­cal ver­sion of 9 to 5, in 2008.

Another clas­sic sin­gle came in 1983 — Islands in the Stream, a duet with Kenny Rogers, which topped the US pop charts — and a Christmas al­bum with Rogers in 1984 went two times plat­inum. There were more no­table film roles in the 1980s, too, op­po­site Burt Reynolds in The Best Little Whorehouse in Texas, Sylvester Stallone in Rhinestone, and an all-star fe­male en­sem­ble in Steel Magnolias.

af­ter newslet­ter pro­mo­tion

A land­mark Parton al­bum came in 1987 with Trio, an ex­quis­itely har­monised, spring­wa­ter-clear col­lab­o­ra­tion with Emmylou Harris and Linda Ronstadt, earn­ing Parton her only nom­i­na­tion for al­bum of the year at the Grammys. Another all-star trio record­ing came in 1993, with Tammy Wynette and Loretta Lynn on the al­bum Honky-Tonk Angels, fol­lowed by a re­union with Harris and Ronstadt for Trio II in 1999, fea­tur­ing a Grammy-winning cover of Neil Young’s After the Gold Rush.

The turn of the cen­tury brought a tril­ogy of ac­claimed blue­grass al­bums, and Parton would re­lease 10 more LPs, the most re­cent be­ing Rockstar in 2023. She was courted by a younger gen­er­a­tion of stars, ap­pear­ing with coun­try artists such as Brad Paisley as well as pop singers such as Kesha, and her god­daugh­ter Miley Cyrus. There were fewer act­ing roles, but she lent her voice to an­i­mated film Gnomeo and Juliet in 2011 and the fol­low­ing year ap­peared along­side Queen Latifah and more in the mu­si­cal film Joyful Noise.

Alongside her mu­sic and act­ing, Parton was an as­tute busi­ness­woman and phil­an­thropist. She founded the film and TV pro­duc­tion com­pany Sandollar, with for­mer man­ager Sandy Gallin, which went on to pro­duce hits such as Buffy the Vampire Slayer and the Father of the Bride film se­ries. In 1986, she took a stake in the Silver Dollar City theme park in Tennessee and re­named it Dollywood, dou­bling its size over the next two decades, and a Dollywood-branded spa, cabin com­plex, the­atre-restau­rant con­cept and wa­ter­park have since been opened.

The Dollywood Foundation, funded through these busi­ness ven­tures and cre­ative pro­jects, was cre­ated in 1988, ini­tially award­ing col­lege schol­ar­ships and run­ning a pro­gram to help chil­dren com­plete high school in her na­tive Sevier county, Tennessee. In 1995, Parton be­gan her Imagination Library pro­ject, which sent an age-ap­pro­pri­ate book to every child in the county every month un­til they were five. “My fa­ther could not read and write, and I saw how crip­pling that could be,” she ex­plained. It ex­panded na­tion­wide in 2000, in­ter­na­tion­ally in 2006, and 40m books are now dis­trib­uted each year across the US, Canada, Australia, the UK and Ireland.

In 2022, Jeff Bezos do­nated $100m (£83m) to the foun­da­tion. That year, Parton ex­plained that as well as im­prov­ing child lit­er­acy, “it’s the fact they get recog­nised. They get this lit­tle book with their lit­tle name on it in the mail, and they feel spe­cial. They start tak­ing pride in them­selves, and they know that some­body out there is think­ing of [them].”

Parton also set up a re­serve in 2003 to help pre­serve the bald ea­gle; con­tributed $500,000 to the open­ing of a Sevier county hos­pi­tal in 2006; co­or­di­nated re­lief ef­forts for peo­ple af­fected by the Smoky moun­tain wild­fires of 2016; and con­tributed to an HIV/Aids char­ity al­bum. She sup­ported Black Lives Matter and trans­gen­der rights, op­pos­ing a North Carolina “bathroom bill” that re­stricted trans­gen­der peo­ple’s ac­cess to toi­lets (Parton was also nom­i­nated for an Oscar for her song in trans drama Transamerica, en­ti­tled Travelin’ Thru).

She made a num­ber of do­na­tions to Vanderbilt University’s med­ical cen­ter in Nashville, Tennessee, where her niece was treated for leukemia. The most high-pro­file of these was in 2020, when she do­nated $1m for re­search into Covid-19, which formed the ba­sis for the even­tual Moderna vac­cine.

In May 2026, Parton can­celled her Las Vegas res­i­dency over health is­sues. A Broadway mu­si­cal is also set to open later this year af­ter a run in Nashville.

Lectronz is a mar­ket­place for open-source hard­ware mak­ers and DIY elec­tron­ics. Most of our sell­ers are not fac­to­ries or well-funded start-ups. They are en­gi­neers, in­de­pen­dent de­sign­ers, and hard­ware en­thu­si­asts work­ing from spare rooms, garages, and tiny work­shops.

Some earn a liv­ing from their prod­ucts. Some sell only a hand­ful of boards each year. Others build ten units sim­ply be­cause they cre­ated some­thing use­ful and want to share it with the com­mu­nity. Occasionally, one of those ex­per­i­ments grows into a real busi­ness. Every Arduino be­gins some­where.

But the European Union’s new pack­ag­ing rules now threaten to kill the world of mak­ers and mi­cro-en­tre­pre­neurs, putting jobs, liveli­hoods and an en­tire ecosys­tem of in­no­va­tion at risk.

And this threat is not just lim­ited to mak­ers and en­gi­neers. It af­fects artists, crafts­peo­ple and other mi­cro-en­tre­pre­neurs sell­ing their work across the EU.

A good idea, a ter­ri­ble im­ple­men­ta­tion

The EU has re­quired pro­duc­ers to take re­spon­si­bil­ity for pack­ag­ing waste for many years through Extended Producer Responsibility (EPR) schemes. The new Packaging and Packaging Waste Regulation (PPWR), which gen­er­ally ap­plies from 12 August 2026, aims to har­monise pack­ag­ing rules across the European Union and re­duce waste.

The main idea of EPR is sen­si­ble: busi­nesses that place pack­ag­ing on the mar­ket should help fi­nance its col­lec­tion and re­cy­cling.

For mak­ers, this means tak­ing re­spon­si­bil­ity for the boxes, en­velopes, plas­tic bags and other pack­ag­ing used to de­liver their prod­ucts. This is an idea we can all get be­hind.

Unfortunately, in­stead of cre­at­ing a sin­gle European sys­tem, the PPWR pre­serves a frag­mented na­tional model. A busi­ness sell­ing di­rectly to cus­tomers across the EU must reg­is­ter and ful­fil its oblig­a­tions sep­a­rately in every Member State where its pack­ag­ing be­comes waste. For large com­pa­nies, this is part of the cost of do­ing busi­ness; for mi­cro-busi­nesses sell­ing only a hand­ful of prod­ucts into each coun­try, the cost and ad­min­is­tra­tive bur­den can be wildly dis­pro­por­tion­ate to the amount of pack­ag­ing in­volved.

Imagine an en­gi­neer in Greece who de­signs a €25 open-source sen­sor board…

During the first year, he sells five to Germany, two to France, two to Austria and one to Belgium. Each ships in a small an­ti­sta­tic bag and a padded en­ve­lope. The amount of pack­ag­ing gen­er­ated for each sale is prob­a­bly around 50 grams.

He has just be­come a pack­ag­ing waste pro­ducer in four coun­tries.

Based on in­dica­tive prices cur­rently quoted by na­tional schemes and com­pli­ance providers, the an­nual cost for France alone can look like this:

Registering for a pack­ag­ing scheme, to­talling €110 in fees per year.

Using the ser­vices of an Authorised rep­re­sen­ta­tive, adding €190 to €300 in costs per year.

Spending time reg­is­ter­ing, doc­u­ment­ing, and re­port­ing waste cre­ated.

These in­dica­tive costs con­tinue to add up for each coun­try:

Belgium: €50 to €100 ad­min­is­tra­tive fees per year, plus the ser­vices of an au­tho­rised rep­re­sen­ta­tive (approx. €250 to €450).

Germany: reg­is­tra­tion is free, but pack­ag­ing-scheme par­tic­i­pa­tion starts at ap­prox­i­mately €10 per year, plus an au­tho­rised rep­re­sen­ta­tive cost­ing around €190 per year.

Austria: €250 ad­min­is­tra­tive fees per year, plus the ser­vices of an au­tho­rised rep­re­sen­ta­tive (approx. €100).

In short, the bar­rier to en­try for these four coun­tries to­tals €1150 per year in an op­ti­mistic sce­nario.

The weight-based en­vi­ron­men­tal con­tri­bu­tion as­so­ci­ated with half a kilo­gram of pack­ag­ing should be mea­sured in cents. The bu­reau­cracy re­quired to ac­count for it is mea­sured in thou­sands of eu­ros.

Now imag­ine you want to sell to all 27 Member States! To make it worth­while, our Greek en­gi­neer needs to sell not 10 boards, not 100, but lit­er­ally thou­sands of boards every year from the very start.

It sim­ply is­n’t worth it any­more.

Killing in­no­va­tion softly

Often, in­no­va­tion does­n’t come from large es­tab­lished cor­po­ra­tions, but from small busi­nesses that start from scratch with new ideas and lit­tle money. Before be­com­ing suc­cess­ful and sell­ing mil­lions of prod­ucts, many com­pa­nies started sell­ing 10, then 100, then 1000. Most busi­nesses never make it there. But there has to be space where ideas can be tested. This is one of the rea­sons Lectronz ex­ists.

In the past year, while some sell­ers on Lectronz sold hun­dreds of prod­ucts, half of our reg­is­tered sell­ers got fewer than 10 or­ders. This is not a bug, but the na­ture of a mar­ket­place like Lectronz where mak­ers are free to ex­per­i­ment with prod­uct ideas. Some ideas don’t work. Some cre­ators on Lectronz only build 10 units and share them with the com­mu­nity with­out mak­ing a profit. But even prod­ucts that “fail” have a value. When hard­ware cre­ators share them with the com­mu­nity, they help oth­ers grow as well. One piece of hard­ware may un­lock the cre­ation of an­other, lead­ing to new prod­uct ideas and in­no­va­tion.

The EPR reg­u­la­tions threaten the ex­is­tence of this in­no­v­a­tive space in the EU.

EU pol­i­cy­mak­ers keep sound­ing the alarm about Europe’s lack of in­no­va­tion, but seem hell-bent on mak­ing it as hard as pos­si­ble for in­no­va­tion to emerge at all, with reg­u­la­tions that cre­ate a dis­pro­por­tion­ate bar­rier to en­try for mi­cro-en­ter­prises and SMEs. It’s an en­vi­ron­ment where only big play­ers like Amazon, Temu, or eBay can ex­ist.

Lectronz is also a mi­cro-en­ter­prise

Lectronz col­lects a 5% fee on every trans­ac­tion it processes. We waive this fee on the first five sales to en­cour­age sell­ers to test our plat­form. After years of work, and with the re­cent surge of new sell­ers join­ing our plat­form in 2026, Lectronz now gen­er­ates roughly the equiv­a­lent of one mod­est salary.

I did not build it to be­come the next Amazon. I built it be­cause in­de­pen­dent hard­ware cre­ators de­serve a mar­ket­place de­signed for them.

If these rules force many of our sell­ers to with­draw from the European mar­ket, they could also make Lectronz it­self un­vi­able. After every­thing we have built to­gether, that would be per­son­ally heart­break­ing.

For now, Lectronz sell­ers should not ex­pect any im­me­di­ate dis­rup­tion. It re­mains un­clear how na­tional au­thor­i­ties will en­force these rules against mak­ers and mi­cro-en­ter­prises, and we will con­tinue mon­i­tor­ing the sit­u­a­tion closely.

What are the so­lu­tions?

If these reg­u­la­tions are ap­plied strictly, the short-term so­lu­tion for mak­ers is sim­ple: stop sell­ing in the EU and ship ex­clu­sively to non-EU mar­kets.

Yes, you read that right. For a French mi­cro-en­tre­pre­neur, it makes more sense to ship prod­ucts to the US than to ship to neigh­bour­ing Germany or Belgium, for ex­am­ple. This is true even with any US tar­iffs in place.

Of course, lim­it­ing sales to the US is not a vi­able so­lu­tion for some sell­ers. It’s also a loss for the European econ­omy it­self. I still hope that we can work out re­al­is­tic so­lu­tions that can help re­store the EU sin­gle mar­ket for mi­cro-en­ter­prises. Here are some ideas.

Solution #1: Introduce an EU-wide de min­imis thresh­old.

Exempt small-vol­ume sell­ers and mi­cro-en­ter­prises from cross-bor­der pack­ag­ing oblig­a­tions. The thresh­old would ap­ply only to pro­duc­ers that are be­low a spe­cific vol­ume of waste and/​or a spe­cific yearly turnover.

Solution #2: Create an EU EPR One Stop Shop.

Create a cen­tralised EU por­tal where sell­ers can reg­is­ter, re­port waste, and pay truly rea­son­able fees at once, for all Member States where they ship prod­ucts. This could mimic the mech­a­nism that al­ready ex­ists for VAT with the One Stop Shop (OSS).

Ideally, since we are in 2026, most of this work should be done through a mod­ern open RESTful API (not web forms) and open-source soft­ware, to be as au­to­mated as pos­si­ble.

Solution #3: Allow mar­ket­places to rep­re­sent and man­age mi­cro-en­ter­prises col­lec­tively as if it were a sin­gle pro­ducer.

A mech­a­nism should al­low mar­ket­places like Lectronz or Tindie to reg­is­ter, re­port waste, and pay rea­son­able fees on be­half of all their sell­ers as if they were col­lec­tively one pro­ducer of waste.

This means that the mar­ket­place would pay ad­min­is­tra­tive fees and other EPR costs cor­re­spond­ing to a sin­gle pro­ducer, that would col­lec­tively rep­re­sent all its sell­ers. For Lectronz, this would have a non-triv­ial im­pact in terms of cost and ad­min­is­tra­tive work, but it might be achiev­able un­der the right con­di­tions.

As stated above, us­ing a com­mon API stan­dard for all coun­tries would help au­to­mate things.

Make your voice heard

Again, to re­it­er­ate, we sup­port the idea of re­duc­ing waste and pro­mot­ing sus­tain­abil­ity. But there’s got to be a bet­ter, sim­pler, and fairer way to do it.

This reg­u­la­tion is hav­ing a mas­sive ef­fect on the en­tire ecosys­tem of mi­cro-busi­nesses, not just mak­ers. It af­fects artists who sell their cre­ations on­line. Local tra­di­tional food pro­duc­ers who ex­port their prod­ucts across the EU. It also af­fects crafts­peo­ple who sell their work on­line through their own web­site or ded­i­cated plat­forms like Etsy. Beyond the small world of mak­ers and DIY elec­tron­ics, this will have an im­pact on the liveli­hood of po­ten­tially hun­dreds of thou­sands of peo­ple in the EU.

And to be clear: these rules af­fect not only busi­nesses in the EU, but any busi­ness that sells to buy­ers in the EU.

Jeanette Koňarčíková, an in­de­pen­dent artist and mi­cro-en­tre­pre­neur from Slovakia, launched an on­line pe­ti­tion to draw the at­ten­tion of pol­i­cy­mak­ers to this is­sue:

https://​www.change.org/​p/​stop-de­stroy­ing-eu-mi­cro-busi­nesses-im­me­di­ate-mora­to­rium-on-cross-bor­der-epr-fees

The pe­ti­tion is thought­ful and well-writ­ten. I en­cour­age you to read and sign it!

The European Commission also has an open pub­lic feed­back page for this is­sue here:

https://​ec.eu­ropa.eu/​info/​law/​bet­ter-reg­u­la­tion/​have-your-say/​ini­tia­tives/​15352-Pack­ag­ing-and-pack­ag­ing-waste-rules-on-na­tional-reg­is­ters-of-pro­duc­er­s_en

Consider leav­ing feed­back there as well.

Recently, the European Commission has be­gun to recog­nise part of the prob­lem and has pro­posed sus­pend­ing the re­quire­ment to ap­point an au­tho­rised rep­re­sen­ta­tive in every des­ti­na­tion coun­try un­til 2035. But this pro­posal has not yet been adopted. Unfortunately, this pro­posal may take time to be voted on and en­ter into force. By then, many small busi­nesses may have closed. More im­por­tantly, re­mov­ing the au­tho­rised-rep­re­sen­ta­tive re­quire­ment would ad­dress only part of the prob­lem. Rules like this risk un­der­min­ing trust in the European pro­ject it­self. What’s the point of the EU if the sin­gle mar­ket no longer ex­ists for mi­cro-en­ter­prises?

Here at Lectronz, we will con­tinue to move for­ward and hope for the best.

But make your voice heard now to make sure pol­i­cy­mak­ers un­der­stand the ur­gency of this is­sue!

Over the past cou­ple weeks I’ve been do­ing agent-dri­ven re­verse en­gi­neer­ing of pe­riph­er­als that hap­pen to be within ar­m’s reach. From those de­vices, I’ve come away with a full plain­text com­mand shell in­side my mi­cro­phone, a we­b­cam whose ac­tiv­ity LED I can switch off while it records, and a key light that hands out mem­ory writes to any­one on the WiFi. Peripherals have proven to be an ideal tar­get for agen­tic RE - they’re tiny com­put­ers at­tached to my com­puter, with a data con­nec­tion to the host and usu­ally a firmware up­date mech­a­nism, so an agent has some­thing to it­er­ate against. The net out­come is bet­ter con­trol and un­der­stand­ing of my ma­chine.

My process was pretty much the same for each of these de­vices: grab a copy of the de­vice’s firmware and as­so­ci­ated up­date tool from the man­u­fac­turer, throw it into my re­verse en­gi­neer­ing en­vi­ron­ment, tell Claude Opus 5 what my goals are, and let it churn. Depending on the de­vice, the goals were some­what dif­fer­ent, but they usu­ally looked some­thing like:

In this di­rec­tory is the firmware and up­date util­ity for ___. The de­vice is also at­tached to this com­puter, and you may in­ter­act with it in non-mu­tat­ing ways. Exhaustively doc­u­ment and cross-val­i­date the en­tire firmware, in­clud­ing the fol­low­ing goals:

* re­verse en­gi­neer the firmware up­date for­mat and up­date pro­to­col * im­ple­ment our own up­date util­ity * de­ter­mine the se­cu­rity prop­er­ties of the up­date pro­to­col, in­clud­ing check­sums, sig­na­ture val­i­da­tion, se­cure boot * use sta­tic and dy­namic analy­sis to de­ter­mine all pro­to­col sur­faces and com­pletely enu­mer­ate func­tion­al­ity * find any hid­den or de­bug func­tion­al­ity in the prod­uct and how to ac­cess it

Depending on the re­sults, there were dif­fer­ent di­rec­tions of fol­low-up, but you should get the gen­eral idea. Let’s run through the list - each de­vice links to a GitHub repo full of gen­er­ated-slop docs and scripts, most of which have been val­i­dated live against real hard­ware. I’ve also in­cluded the ef­fort each de­vice took, pulled out of the Claude Code ses­sion tran­scripts. “Churn” is the time Claude was ac­tu­ally work­ing, with the long idle gaps re­moved. “Prompts from me” is every mes­sage I typed, in­clud­ing the one-word ones telling it to keep go­ing. All five de­vices to­gether came out to about 13 hours of churn and 98 prompts, spread across two weeks of evenings.

Everything I own

Insta360 Link we­b­cam

GitHub repo - 3.7 hours of Claude churn, 33 prompts from me

I use an Insta360 Link we­b­cam, which is a nice gim­baled pan-tilt-zoom cam­era that does face track­ing for au­to­mat­i­cally fram­ing the shot. I wanted to know if it was pos­si­ble to sub­vert the ac­tiv­ity LED, like in the clas­sic iSeeYou ex­ploit.

Interestingly, it was im­me­di­ately ob­vi­ous that this cam­era has a lot go­ing on in­side it. It turns out that it runs a whole RTOS (ThreadX) sourced from the up­stream SoC ven­dor, Ambarella. The RTOS hosts sev­eral small vi­sion mod­els that pro­vide things like the afore­men­tioned face track­ing, as well as ges­ture de­tec­tion for con­trol­ling set­tings. Pretty amaz­ing com­plex­ity in­side a tiny we­b­cam, but it also means there’s some ex­cit­ing at­tack sur­face here.

Over the USB Video Class in­ter­face, there’s an XU (Extension Unit) com­mand that kicks the de­vice into “mass stor­age” mode. This then lets us trans­fer a staged firmware up­date to the de­vice’s in­ter­nal FAT filesys­tem, which the de­vice then ap­plies to it­self on re­boot. This route does re­quire user in­ter­ven­tion to re­boot with a re­plug, but there’s ac­tu­ally an­other com­mand chan­nel that ex­poses ar­bi­trary read/​write of files and a re­boot com­mand over the USB ven­dor class. With this, we can fully flash the de­vice with­out any user in­ter­ac­tion. Once the firmware is in the right place, there’s ef­fec­tively no anti-tam­per, just an ap­pended MD5 hash to en­sure in­tegrity.

The in­di­ca­tor LED turns out to have a well-struc­tured set of “patterns” in the firmware that dic­tate color, blink pat­tern, etc. that are in­dexed into for var­i­ous de­vice states. I had Claude write a tool to patch out the table en­try for cam­era ac­tiv­ity, fix up the in­tegrity hash, and flash it to the cam­era. A quick test showed that the green LED that nor­mally il­lu­mi­nates while record­ing no longer turned on. Horrifying! On this de­vice, the gim­bal it­self also de­flects down when not record­ing, so it’s not com­pletely stealth, but it still does­n’t feel great.

The LED be­hav­ior be­fore and af­ter patch­ing.

ASUS ROG Swift PG42UQ mon­i­tor

GitHub repo - 1.2 hours of Claude churn, 13 prompts from me

My ASUS ROG Swift PG42UQ mon­i­tor was ac­tu­ally where I started, be­cause I got an­noyed at the pop-up over­lay that comes up every once in a while that tells me to run “pixel clean­ing”. I have never in­ten­tion­ally run pixel clean­ing on this mon­i­tor and I never will, I don’t care, and I would like for that over­lay to go away for­ever. Maybe there’s a de­bug menu or some­thing that can turn it off, or worst case we patch a branch in the firmware?

Claude found that the firmware has ef­fec­tively no pro­tec­tion what­so­ever - there’s a two-slot A/B scheme and a sim­ple check­sum, but ul­ti­mately we can write what­ever we want to the thing. Firmware up­dates run over an I2C bus bridged over USB.

The pixel clean­ing warn­ing turns out to have no na­tive way to dis­able it, and it’ll al­ways show up af­ter 8 hours of run­time. Oh well. Claude did find the ap­pro­pri­ate area to patch to kill the func­tion­al­ity though. I haven’t ac­tu­ally been brave enough to write a mod­i­fied firmware to the thing yet - it’s a pretty ex­pen­sive mon­i­tor - but I’ll get there at some point.

Another neat thing was ex­plor­ing the DDC/CI in­ter­face. This is the con­trol chan­nel avail­able over the dis­play ca­ble it­self, al­low­ing the host to change in­puts and other set­tings. I be­lieve ASUS of­fers this through their Windows util­ity, DisplayWidget, but that does lit­tle for me on Linux. So, now I have a shell script that can flip through some of the DDC/CI fea­tures like the hard­ware crosshair or zoom over­lays, FPS counter, and count­down timer. I might set up some of these on hotkeys in the fu­ture for easy ac­cess.

Shure MV7 mi­cro­phone

GitHub repo - 4.2 hours of Claude churn, 32 prompts from me

At this point, there’s less ac­tual in­cen­tive to keep pop­ping these de­vices and more just mor­bid cu­rios­ity. My mi­cro­phone, the Shure MV7, con­nects over USB and ob­vi­ously has some amount of smarts to it, with on-de­vice dig­i­tal vol­ume con­trols and such.

The firmware for this one turned out to be hid­den in­side the Windows soft­ware, MOTIV Mix, so Claude in­stalled that in Wine, found the up­date server, and pulled it down. I was­n’t on the lat­est, so there was ac­tu­ally a rea­son­able in­cen­tive here to get this work­ing just to up­date my mi­cro­phone from Linux. The firmware turned out to con­tain both DSP and MCU firmware, and was hon­estly pretty bor­ing as you might ex­pect. Again, no real se­cu­rity on the firmware flash it­self.

However, the up­date pro­to­col re­vealed that the en­tire thing ac­tu­ally runs over a USB HID ven­dor class pro­to­col that im­ple­ments a full plain­text com­mand shell, with 48 dif­fer­ent com­mands. Since it’s HID, we can ac­tu­ally hit this over WebHID from a web­page in Chrome, so I had Claude build a web in­ter­face for us­ing the shell. There’s all sorts of in­ter­est­ing set­tings in here in­clud­ing a dozen DSP knobs, ar­bi­trary mem­ory read/​write, LED con­trol, and a 4-tier user priv­i­lege sys­tem whose en­tire au­then­ti­ca­tion is a string com­par­i­son against the name of the tier you asked for. su sup just works, and the top tier can dis­able the touch panel so you can’t mute at the de­vice, and drive the mute LED in­de­pen­dently of whether the mi­cro­phone is ac­tu­ally muted. It’s the we­b­cam LED trick again, on a mi­cro­phone. Obviously, be aware that you could prob­a­bly break your de­vice if you use that UI and do some­thing stu­pid with it.

The WebHID shell in­ter­face. The DSP knobs on the left are the de­vice’s own set­tings; the con­sole on the right is the plain­text com­mand shell talk­ing over HID.

Elgato Cam Link 4K video cap­ture

GitHub repo - 1.5 hours of Claude churn, 10 prompts from me

The Elgato Cam Link 4K is just an HDMI video cap­ture de­vice, and hon­estly was just more of the same. The in­ter­est­ing thing for this one was that I let it go fully un­at­tended - I lit­er­ally kicked off the process be­fore go­ing to sleep and woke up to a tear­down and func­tion­ing firmware up­dater. The firmware con­tains an MCU im­age and an FPGA bit­stream for the ac­tual HDMI han­dling, so you could po­ten­tially do some­thing fun with the FPGA if you went deep enough into the re­verse en­gi­neer­ing there. There’s no pro­tec­tion on the firmware up­date path.

I was able to pull out all the EDID in­for­ma­tion used for ne­go­ti­at­ing video pa­ra­me­ters, so we know ex­actly what res­o­lu­tions, re­fresh rates, color spaces, and chroma sub­sam­pling op­tions are of­fered to de­vices.

The ven­dor HID pro­to­col does in­clude tun­neled ac­cess to the in­ter­nal I2C bus, which is kinda neat as you can poke the in­ter­nal HDMI re­ceiver reg­is­ters.

Elgato Key Light Mini

GitHub repo - 2.4 hours of Claude churn, 10 prompts from me

Finally, I poked at some­thing that was­n’t con­nected over USB but WiFi in­stead, the Elgato Key Light Mini. This one turned out to be way more in­ter­est­ing than I ex­pected: it’s the only one with mean­ing­ful firmware in­tegrity pro­tec­tion. Elgato signs the firmware up­dates with Ed25519 over a SHA-512 hash of the firmware pay­load, and re­jects firmware that does­n’t val­i­date. This makes sense to do, as the de­vice ba­si­cally con­nects to a WiFi net­work and then pro­vides unau­then­ti­cated ac­cess to any­one on the same net­work, so the threat model is in­her­ently dif­fer­ent.

Unfortunately, while that’s an im­prove­ment over all of the other de­vices we’ve looked at, it pro­tects the firmware at ex­actly one point in time: when an up­date is hap­pen­ing. It’s not a boot time check en­forced by the boot­loader or any other kind of se­cure boot scheme, and the up­dater hap­pens to be run­ning while every­thing else in the de­vice is still op­er­at­ing, mean­ing there’s huge at­tack sur­face to try to dis­able that sig­na­ture val­i­da­tion. I asked Claude to look for an ex­ploit that might en­able this, and it found a doozy: an HTTP POST re­quest that drops a pay­load straight into the in­ter­nal UART, which in­cludes a mem­ory poke com­mand. This means that a sin­gle HTTP POST of ATSE=0200ED94,0E001009 turns the sig­na­ture check into a no-op, and we can freely up­date to a firmware im­age with­out a le­git­i­mate sig­na­ture. I suc­cess­fully tested this with a sim­ple patch that changed the name of the de­vice, so uh, yeah, don’t put these on an un­trusted net­work.

…, owned

I have a lot of feel­ings about this whole thing. As I wrote back in March, this is in­cred­i­ble for in­ter­op­er­abil­ity and fix­ing things that don’t work how we want them to. Hardware is al­most uni­ver­sally “open” for tin­ker­ing at this point with just a cou­ple hours of mostly hands-off ma­chine-dri­ven la­bor each, and I look for­ward to a near fu­ture where I can add fea­tures to my we­b­cam firmware as eas­ily as I can to soft­ware that runs on my Linux ma­chine it­self.

On the other hand, as a se­cu­rity pro­fes­sional, this scares me for sev­eral rea­sons. I would work from the op­er­at­ing as­sump­tion that any de­vice at­tached to a com­puter could have had a ma­li­cious firmware im­plant per­formed, where pre­vi­ously that re­quired sig­nif­i­cant per-model in­vest­ment and was stereo­typed as a “state ac­tor” kind of ac­tiv­ity. Operating sys­tems aren’t re­ally equipped to work with the user to en­sure that a mi­cro­phone stays a mi­cro­phone, and does­n’t spon­ta­neously turn into a key­board that hits Win+R and drops a pay­load to steal all your data when the room is quiet enough that it can as­sume you aren’t watch­ing. And the ex­is­tence of WebUSB, WebHID, and WebBluetooth mean that for some de­vices, de­pend­ing on the specifics of which classes are used, a mo­ment of user in­dis­cre­tion in ac­cept­ing a per­mis­sions prompt could per­ma­nently back­door one of their at­tached de­vices.

Network-connected de­vices seem near uni­ver­sally fucked at this point? There are a few oth­ers I’ve poked at that I haven’t doc­u­mented here, but I’ve got­ten a root shell on a com­mer­cial Dell dis­play, and RCE on an Eaton UPS. Obviously it was never best prac­tice to let un­trusted clients touch these things, but the speed and scale at which this can be ex­e­cuted makes the risk so much higher now.

Finally, I can’t help but think about what an AI-equipped au­to­mat­i­cally-re­verse-en­gi­neer­ing worm could do to­day. It’s only a tiny leap to imag­ine that some­one could make a self-repli­cat­ing piece of mal­ware that probes its en­vi­ron­ment, re­lay­ing re­con­nais­sance back to a smart com­mand-and-con­trol that ac­tively works to push it­self into ac­ces­sories and IoT de­vices and in­dus­trial equip­ment found ad­ja­cent to an in­fected tar­get. Two things have kept this from hap­pen­ing: every de­vice model needs its own re­verse en­gi­neer­ing, and val­i­dat­ing any of it needs the hard­ware in hand. The first is the la­bor I just handed to an agent. The sec­ond is free to mal­ware al­ready sit­ting on an in­fected host. Honestly, I would­n’t be sur­prised if this al­ready ex­ists, and I think the next few years are go­ing to be ex­tremely in­ter­est­ing. 🫠

M6: Optimized Design and Enhanced Performance

Text of this ar­ti­cle

Text of this ar­ti­cle

Media in this ar­ti­cle

Media in this ar­ti­cle

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

Testing was con­ducted by Apple in August 2026 us­ing pre­pro­duc­tion Mac mini with M6 with 12-core CPU, 12-core GPU, and 32GB of mem­ory; 14-inch MacBook Pro with M5 with 10-core CPU, 10-core GPU, and 32GB of mem­ory; and Mac mini with M1 with 8-core CPU, 8-core GPU, and 16GB of mem­ory. Performance was mea­sured us­ing se­lect in­dus­try‑stan­dard bench­marks. Performance tests were con­ducted us­ing spe­cific com­puter sys­tems and re­flect the ap­prox­i­mate per­for­mance of Mac mini. See ap­ple.com/​mac-mini for more in­for­ma­tion.

Testing was con­ducted by Apple in August 2026 us­ing pre­pro­duc­tion Mac Studio with M5 Ultra with 36-core CPU, 80-core GPU, and 256GB of mem­ory; Mac Studio with M3 Ultra with 32-core CPU, 80-core GPU, and 256GB of mem­ory; and Mac Studio with M1 Ultra with 20-core CPU, 64-core GPU, and 64GB of mem­ory. Performance was mea­sured us­ing se­lect in­dus­try‑stan­dard bench­marks. Performance tests were con­ducted us­ing spe­cific com­puter sys­tems and re­flect the ap­prox­i­mate per­for­mance of Mac Studio. See ap­ple.com/​mac-stu­dio for more in­for­ma­tion.

Apple Intelligence fea­tures are cur­rently avail­able for test­ing through the Apple Beta Software Program, and will be avail­able with ma­cOS 27 this fall for users with an Apple Intelligence-enabled de­vice set to a sup­ported lan­guage. Apple Intelligence is avail­able with sup­port for these lan­guages: English, Danish, Dutch, French, German, Italian, Norwegian, Portuguese, Spanish, Swedish, Turkish, Vietnamese, Chinese (simplified), Chinese (traditional), Japanese, and Korean. Some fea­tures may not be avail­able in all re­gions or lan­guages. For fea­ture and lan­guage avail­abil­ity and sys­tem re­quire­ments, see ap­ple.com/​ap­ple-in­tel­li­gence.

This repos­i­tory was archived by the owner on Aug 26, 2026. It is now read-only.

zedeus

/

nit­ter

Public archive

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

Fork 1.1k

Star 13.8k

Star 13.8k

Code

Issues 133

Pull re­quests 23

Discussions

Actions

Wiki

Security and qual­ity

Insights

This repos­i­tory was archived by the owner on Aug 26, 2026. It is now read-only.

Open

Open

#1442

Description

AlexandrPutenikhin

opened

https://​web.archive.org/​web/​20260825143445/​https://​twi­iit.com/

Every in­stance has the same Instance has been rate lim­ited. er­ror.

Metadata

Metadata

Assignees

No one as­signed

Labels

No la­bels

No la­bels

Projects

No pro­jects

Milestone

No mile­stone

Relationships

None yet

Development

No branches or pull re­quests

Issue ac­tions

2026 – 08-26 | 10 min

Today, we’re an­nounc­ing that DuckLabs will join Amazon Web Services (AWS), which is ex­pected to be ef­fec­tive in early September.

Our team will re­main to­gether in Amsterdam, con­tin­u­ing our work on DuckDB, DuckLake, Quack, and the broader com­mu­nity. Joining AWS gives us the re­sources and reach to bring this tech­nol­ogy to many more de­vel­op­ers and or­ga­ni­za­tions, and to pur­sue ideas at a scale that would have been dif­fi­cult for us to reach alone.

Most im­por­tantly, the foun­da­tions of the pro­ject will re­main firmly in place. DuckDB and the other open-source com­po­nents of the “Duck Stack” will re­main free and open source un­der the MIT li­cense, with the non­profit DuckDB Foundation con­tin­u­ing its stew­ard­ship of the pro­jects.

This is a sig­nif­i­cant mo­ment for all of us at DuckLabs. It marks the end of one chap­ter that we are im­mensely proud of, and the be­gin­ning of an­other that we be­lieve can take DuckDB much fur­ther.

Our Journey to This Point

We founded DuckLabs a lit­tle over five years ago to give the team be­hind DuckDB a sta­ble, long-term home.

At the time, DuckDB was be­gin­ning to gain real mo­men­tum. The first com­mer­cial con­tracts to pri­or­i­tize fea­tures were ma­te­ri­al­iz­ing, and ven­ture cap­i­tal firms were call­ing. We chose a dif­fer­ent path: a boot­strapped com­pany, fully owned by its founders and de­vel­op­ment team.

That de­ci­sion shaped DuckLabs in ways we value deeply. It gave us the free­dom to build pa­tiently, to put the tech­nol­ogy first, and to grow with­out los­ing sight of why we started. From a small group gath­ered around an am­bi­tious open-source pro­ject, we grew into a team of more than 30 peo­ple in Amsterdam, all while con­tin­u­ing to in­vest in DuckDB and the com­mu­nity tak­ing shape around it.

During those years, DuckDB trav­eled much fur­ther than we imag­ined when the pro­ject be­gan. Today, we see more than one mil­lion down­loads every day. Developers around the world use it to ex­plore data, power prod­ucts, teach new ideas, con­duct re­search, and build sys­tems we could never have an­tic­i­pated our­selves.

Watching that hap­pen has been one of the great priv­i­leges of our pro­fes­sional lives. But the lim­its of our ex­ist­ing model also be­came in­creas­ingly clear. As founders, we wor­ried that DuckDB’s growth would even­tu­ally out­pace our abil­ity to sup­port it. That our small com­pany could be­come a bot­tle­neck for the pro­ject, the team, and the peo­ple build­ing busi­nesses on top of it.

We also wor­ried that scal­ing DuckLabs into a much larger sales, sup­port, and op­er­a­tions or­ga­ni­za­tion would pull our at­ten­tion away from the tech­ni­cal work and open-source com­mu­nity that made DuckDB suc­cess­ful in the first place.

Our part­ner­ships work best with highly tech­ni­cal or­ga­ni­za­tions — of­ten com­pa­nies with sub­stan­tial data­base ex­per­tise of their own. Reaching a much broader group of users re­quires us to solve more com­plete and spe­cial­ized prob­lems, serve the needs of dif­fer­ent in­dus­tries, in­vest sub­stan­tially more in in­fra­struc­ture, and reach peo­ple who may never think to seek out an an­a­lyt­i­cal data­base di­rectly.

We be­lieve the DuckDB rev­o­lu­tion can grow by an­other cou­ple of or­ders of mag­ni­tude. To give it that op­por­tu­nity, we re­al­ized we needed a dif­fer­ent setup.

Why AWS

DuckLabs and AWS have al­ready been work­ing closely to­gether for more than a year. During that time, we came to un­der­stand how our teams col­lab­o­rate, what each brings to the table, and what might be­come pos­si­ble by com­bin­ing DuckLabs’ tech­ni­cal ex­per­tise with AWS’s in­fra­struc­ture, scale, and cus­tomer reach.

That ex­pe­ri­ence gave us con­fi­dence in tak­ing this next step.

Together, we plan to use DuckDB, DuckLake, and Quack to help power a new gen­er­a­tion of data ser­vices. Our am­bi­tion is to reach peo­ple who may even­tu­ally de­pend on the Duck Stack every day, whether they in­ter­act with it di­rectly or en­counter it qui­etly in­side the prod­ucts and ser­vices they use.

For the DuckLabs team, join­ing AWS cre­ates the space to con­cen­trate on the tech­ni­cal work we care about most while op­er­at­ing at a scale we could not eas­ily achieve on our own. It al­lows us to think fur­ther ahead, be bolder, tackle harder prob­lems, and bring the ideas be­hind DuckDB to many more peo­ple.

AWS has com­mit­ted to sup­port­ing the con­tin­ued de­vel­op­ment of DuckDB and its wider com­mu­nity for the long term. That com­mit­ment mat­ters deeply to us.

Quote “DuckDB is an in­cred­i­ble open source pro­ject with an amaz­ing com­mu­nity; it is broadly used and very much loved by S3 cus­tomers to­day. After about two years of work­ing closely with Mark, Hannes and the whole team at DuckLabs I’m ex­cited at the op­por­tu­nity to help the pro­ject have an even broader im­pact. Also, and maybe a lit­tle self­ishly, I’ve found the DuckLabs team to be one of the most tech­ni­cally deep, hum­ble, and high-ve­loc­ity teams that I’ve ever had a chance to work with and I’m de­lighted that we get to do a lot more of that.”

– Andy Warfield (Distinguished Engineer and Vice President, AWS)

Quote “DuckDB is an in­cred­i­ble open source pro­ject with an amaz­ing com­mu­nity; it is broadly used and very much loved by S3 cus­tomers to­day. After about two years of work­ing closely with Mark, Hannes and the whole team at DuckLabs I’m ex­cited at the op­por­tu­nity to help the pro­ject have an even broader im­pact. Also, and maybe a lit­tle self­ishly, I’ve found the DuckLabs team to be one of the most tech­ni­cally deep, hum­ble, and high-ve­loc­ity teams that I’ve ever had a chance to work with and I’m de­lighted that we get to do a lot more of that.”

– Andy Warfield (Distinguished Engineer and Vice President, AWS)

What Will Remain the Same

We know that an an­nounce­ment like this brings im­por­tant — and un­der­stand­able — ques­tions for users, con­trib­u­tors, cus­tomers, and part­ners.

DuckDB, DuckLake, Quack, and the other open-source com­po­nents of the Duck Stack will re­main free and open source un­der the MIT li­cense. The non­profit DuckDB Foundation will con­tinue to stew­ard these pro­jects, and the DuckLabs team will con­tinue to con­tribute to the pro­ject and re­main to­gether in Amsterdam.

The open-source pro­jects will con­tinue to serve a broad com­mu­nity of users, con­trib­u­tors, plat­forms, and ven­dors. The open­ness that al­lowed DuckDB to flour­ish will re­main cen­tral to its fu­ture.

We care deeply about the trust this com­mu­nity has placed in us. Protecting that trust has been one of the most im­por­tant con­sid­er­a­tions through­out this process.

Quote “As the CWI rep­re­sen­ta­tive on the DuckDB Foundation, I would like to con­grat­u­late Hannes, Mark and all DuckLabs em­ploy­ees with this new chap­ter. When DuckLabs spun out of CWI, we cre­ated this foun­da­tion, which holds all IP of open-source DuckDB, and will con­tinue to do so. I am de­lighted that AWS is com­mit­ted to keep ad­vanc­ing open-source DuckDB, and I an­tic­i­pate it to even ac­cel­er­ate its in­no­va­tion. Via the DuckDB Foundation we will also make sure that the voices of its sup­port­ers and all mem­bers of the open-source DuckDB com­mu­nity at large, will con­tinue to be heard. I am very proud of DuckDB and its cre­ators; this de­vel­op­ment un­der­lines it is state-of-the-art tech­nol­ogy, which re­al­izes many ideas from the data­base ar­chi­tec­ture re­search group in open source, for every­body’s ben­e­fit.”

– Peter Boncz (Database Architectures group lead at CWI Amsterdam, DuckDB Foundation board mem­ber)

Quote “As the CWI rep­re­sen­ta­tive on the DuckDB Foundation, I would like to con­grat­u­late Hannes, Mark and all DuckLabs em­ploy­ees with this new chap­ter. When DuckLabs spun out of CWI, we cre­ated this foun­da­tion, which holds all IP of open-source DuckDB, and will con­tinue to do so. I am de­lighted that AWS is com­mit­ted to keep ad­vanc­ing open-source DuckDB, and I an­tic­i­pate it to even ac­cel­er­ate its in­no­va­tion. Via the DuckDB Foundation we will also make sure that the voices of its sup­port­ers and all mem­bers of the open-source DuckDB com­mu­nity at large, will con­tinue to be heard. I am very proud of DuckDB and its cre­ators; this de­vel­op­ment un­der­lines it is state-of-the-art tech­nol­ogy, which re­al­izes many ideas from the data­base ar­chi­tec­ture re­search group in open source, for every­body’s ben­e­fit.”

– Peter Boncz (Database Architectures group lead at CWI Amsterdam, DuckDB Foundation board mem­ber)

Quote “Over the course of five years, DuckDB’s open na­ture, its sheer hack­a­bil­ity, and the re­mark­ably friendly com­mu­nity of de­vel­op­ers has turned the sys­tem into one of the pre­mier plat­forms for data­base re­search as well as teach­ing. For both, it is es­sen­tial that we can in­spect and tin­ker with DuckDB’s ker­nel. I am thus ex­cited to learn that DuckDB will re­main open source un­der the um­brella of AWS. An even wider range of op­por­tu­ni­ties is in reach now. We are glad to be able to be a part of this new era for DuckLabs and DuckDB.”

– Torsten Grust (Professor of Computer Science and Database Systems re­search group lead at Universität Tübingen, Germany)

Quote “Over the course of five years, DuckDB’s open na­ture, its sheer hack­a­bil­ity, and the re­mark­ably friendly com­mu­nity of de­vel­op­ers has turned the sys­tem into one of the pre­mier plat­forms for data­base re­search as well as teach­ing. For both, it is es­sen­tial that we can in­spect and tin­ker with DuckDB’s ker­nel. I am thus ex­cited to learn that DuckDB will re­main open source un­der the um­brella of AWS. An even wider range of op­por­tu­ni­ties is in reach now. We are glad to be able to be a part of this new era for DuckLabs and DuckDB.”

– Torsten Grust (Professor of Computer Science and Database Systems re­search group lead at Universität Tübingen, Germany)

What We Plan to Expand

Joining AWS will give us greater ca­pac­ity to in­vest in both the tech­nol­ogy and the com­mu­nity around it. Going for­ward, the DuckDB Foundation will in­clude a tech­ni­cal ad­vi­sory board, so that lead­ing com­mu­nity mem­bers can pro­vide their in­put on the pro­jec­t’s tech­ni­cal di­rec­tion. We also plan to open the ex­ten­sion stack so that ex­ten­sions signed by other de­vel­op­ers and or­ga­ni­za­tions can run in DuckDB.

There is a great deal of work ahead, and many de­tails still to shape. We will share more as these plans de­velop.

Quote “Amazon putting its weight be­hind DuckDB is go­ing to add a ton of mo­men­tum and strengthen the ecosys­tem. This is great news for those of us who be­lieve in DuckDB as the plat­form on which the fu­ture of an­a­lyt­ics is be­ing built.”

– Jordan Tigani (CEO, MotherDuck)

Quote “Amazon putting its weight be­hind DuckDB is go­ing to add a ton of mo­men­tum and strengthen the ecosys­tem. This is great news for those of us who be­lieve in DuckDB as the plat­form on which the fu­ture of an­a­lyt­ics is be­ing built.”

– Jordan Tigani (CEO, MotherDuck)

Quote “Amazon is the ideal home for DuckLabs. DuckDB is the cen­ter of the ven­dor-neu­tral open data stack, and Amazon has the com­mit­ment to open­ness, and the track record of work­ing with the en­tire cloud ecosys­tem, to en­able the DuckDB pro­ject to con­tinue to thrive in this role.”

– George Fraser (CEO and co-founder, Fivetran)

Quote “Amazon is the ideal home for DuckLabs. DuckDB is the cen­ter of the ven­dor-neu­tral open data stack, and Amazon has the com­mit­ment to open­ness, and the track record of work­ing with the en­tire cloud ecosys­tem, to en­able the DuckDB pro­ject to con­tinue to thrive in this role.”

– George Fraser (CEO and co-founder, Fivetran)

The Next Chapter

DuckDB’s suc­cess has al­ways be­longed to a much larger com­mu­nity than the peo­ple work­ing in­side DuckLabs.

It be­longs to every­one who has used it, con­tributed code, re­ported a bug, writ­ten an ex­ten­sion, an­swered a ques­tion, pub­lished a bench­mark, taught a class, built a prod­uct, chal­lenged our as­sump­tions, or rec­om­mended DuckDB to some­one else. Every one of those acts helped the pro­ject be­come what it is to­day.

We do not take that sup­port — or the trust be­hind it — for granted.

Joining AWS gives the DuckLabs team an ex­tra­or­di­nary op­por­tu­nity to bring the Duck Stack to a much larger au­di­ence while con­tin­u­ing to in­vest in the open-source tech­nol­ogy at its heart. We en­ter this next chap­ter with the same cu­rios­ity, care, and tech­ni­cal am­bi­tion that brought us here, along­side a team that has been through the en­tire jour­ney to­gether.

To every­one who helped us reach this point: thank you. We are proud of what we have built to­gether, ex­cited by what now lies ahead, and look­ing for­ward to build­ing the next chap­ter with you.

You’re also wel­come to check out our press re­lease and the me­dia kit.

You’re also wel­come to check out our press re­lease and the me­dia kit.

Open Executive

An AI sys­tem that acts as your com­pa­ny’s vir­tual ex­ec­u­tive team — a se­nior ad­vi­sor with Harvard MBA-level knowl­edge, cus­tomized for your spe­cific busi­ness.

Demo

A walk­through of Open Executive in ac­tion — watch on YouTube.

What It Does

Developed by sen­te­labs.ai Open Executive pro­vides a sin­gle co­her­ent ex­ec­u­tive voice backed by eight spe­cial­ist AI agents:

Chief Strategy Officer — com­pet­i­tive analy­sis, M&A, mar­ket po­si­tion­ing, OKRs

Chief Financial Officer — fi­nan­cial mod­el­ing, fundrais­ing, unit eco­nom­ics, cash flow

Chief HR/People Officer — hir­ing, com­pen­sa­tion, per­for­mance, cul­ture

General Counsel — con­tracts, IP, em­ploy­ment law ba­sics, com­pli­ance

Chief Operating Officer — process de­sign, ven­dor man­age­ment, op­er­a­tional scal­ing

Chief Marketing Officer — GTM strat­egy, brand, com­mu­ni­ca­tions, PR

Chief Product Officer — roadmap, pri­or­i­ti­za­tion, prod­uct strat­egy

Board Communications Director — board decks, in­vestor re­la­tions, gov­er­nance

All re­sponses come from one con­sis­tent ex­ec­u­tive voice. The in­ter­nal agent ar­chi­tec­ture is never ex­posed to the user. Beyond Q&A, the sys­tem main­tains episodic mem­ory of past de­ci­sions and ini­tia­tives across ses­sions, and a built-in sched­uler can proac­tively sur­face fol­low-ups and time-sen­si­tive ac­tions.

Architecture

User mes­sage ↓ Executive Orchestrator (claude-sonnet-4 – 6) ↓ tool use → par­al­lel spe­cial­ist calls CSO / CFO / CHRO / GC / COO / CMO / CPO / Board ↓ each spe­cial­ist re­trieves rel­e­vant con­text from ChromaDB Built-in MBA knowl­edge + Your com­pany doc­u­ments ↓ Synthesized ex­ec­u­tive re­sponse

Knowledge — Two re­trieval lay­ers per spe­cial­ist call: (1) built-in MBA-level Markdown (knowledge/builtin/, git-tracked) seeded into ChromaDB at startup, and (2) your up­loaded com­pany doc­u­ments chun­ked and stored in a sep­a­rate com­pa­ny_­docs col­lec­tion. RAG con­text is in­jected into the user turn, never the cached sys­tem prompt.

Episodic mem­ory — After every re­sponse, a back­ground claude-haiku-4 – 5 pass ex­tracts key de­ci­sions, ini­tia­tives, and ad­vice into SQLite. The next ses­sion opens with a <past_decisions> block so the Executive re­mem­bers what it rec­om­mended last month.

Scheduler — A built-in job run­ner claims due ac­tions via UPDATE … RETURNING to pre­vent dou­ble-fir­ing. The API must run as a sin­gle in­stance; do not hor­i­zon­tally scale it with­out gat­ing the sched­uler first.

Prompt caching — The sys­tem prompt is struc­tured so the Executive per­sona, com­pany pro­file, and knowl­edge in­dex are cached sep­a­rately (up to 85% cache hit rate af­ter the first few turns). No dy­namic con­tent ever goes in a cached block.

See docs/​ar­chi­tec­ture.md for the full de­sign.

Tech Stack

Repo Layout

openex­ec­u­tive/ ├── pack­ages/ │ ├── core/ │ │ └── openex­ec­u­tive/ │ │ ├── or­ches­tra­tor/ # Executive per­sona + rout­ing loop │ │ ├── agents/ # 8 spe­cial­ist agents │ │ ├── knowl­edge/ # ChromaDB store + RAG pipeline │ │ ├── mem­ory/ # Company pro­file + episodic mem­ory │ │ ├── on­board­ing/ # Wizard state ma­chine + pro­file builder │ │ ├── prompts/ # Persona + do­main prompts + cache man­ager │ │ ├── api/ # FastAPI app + routes │ │ ├── in­te­gra­tions/ # Slack, Email, Telegram, Google Chat, Discord │ │ ├── sched­uler/ # Background job run­ner (single-instance) │ │ ├── alerts/ # Proactive alert sys­tem │ │ ├── au­dit/ # Audit log­ging │ │ ├── ar­chi­tec­ture/ # Internal ar­chi­tec­ture util­i­ties │ │ ├── work­flows/ # Multi-step work­flow de­f­i­n­i­tions │ │ └── cli.py # Click CLI │ └── ui/ # Next.js 15 web UI ├── evals/ # Eval sce­nar­ios + LLM-as-judge run­ner ├── fix­tures/ # Demo com­pany fix­tures (profiles, docs, ros­ters) ├── scripts/ # Operator scripts (Fly se­crets, Google auth) ├── docker/ # Dockerfile(s) + docker-com­pose.yml ├── fly.api.toml / fly.ui.toml # Fly.io con­figs — dev API + UI apps ├── fly.api.qa.toml / fly.ui.qa.toml # Fly.io con­figs — QA API + UI apps ├── fly.hon­cho.toml # Fly.io con­fig — Honcho mem­ory app (optional) └── docs/ # Architecture + de­ploy­ment docs

Quick Start

# Clone the repo git clone https://​github.com/​Sen­te­Lab­sAI/​OpenEx­ec­u­tive.git cd OpenExecutive

# Set your Anthropic API key cp .env.example .env # Edit .env and add ANTHROPIC_API_KEY=sk-ant-… # For the web UI’s Google sign-in, also fill in the AUTH_* block # (see docs/​auth.md for the Google Cloud Console steps).

# Start every­thing make dev

All con­fig­u­ra­tion lives in that repo-root .env — make dev and make docker both load it for the API and the UI (Auth.js needs AUTH_SECRET / AUTH_GOOGLE_ID / AUTH_GOOGLE_SECRET at run­time). A pack­ages/​ui/.​env.lo­cal is also read for UI-only keys, but for keys pre­sent in both files the root .env takes prece­dence.

Open http://​lo­cal­host:3000 to start chat­ting with your ex­ec­u­tive. The API runs on port 8000 and the UI on 3000.

First run: re­quires Python 3.11+ and Node 22+. The ini­tial uv sync pulls heavy ML de­pen­den­cies (ChromaDB + sen­tence-trans­form­ers/​Py­Torch), and the first boot down­loads a small em­bed­ding model (~90 MB) to build the lo­cal vec­tor in­dex — so the first make dev takes a few min­utes be­fore the app is ready. Subsequent starts are fast.

First run: re­quires Python 3.11+ and Node 22+. The ini­tial uv sync pulls heavy ML de­pen­den­cies (ChromaDB + sen­tence-trans­form­ers/​Py­Torch), and the first boot down­loads a small em­bed­ding model (~90 MB) to build the lo­cal vec­tor in­dex — so the first make dev takes a few min­utes be­fore the app is ready. Subsequent starts are fast.

For con­trib­u­tors not us­ing make:

cd pack­ages/​core uv sync source .venv/bin/activate uvi­corn openex­ec­u­tive.api.main:app –reload –port 8000

# In a sec­ond ter­mi­nal cd pack­ages/​ui && npm in­stall && npm run dev

Run the Discord Bot

Create a Discord ap­pli­ca­tion at https://​dis­cord.com/​de­vel­op­ers/​ap­pli­ca­tions

Enable the Message Content priv­i­leged in­tent (Bot → Privileged Gateway Intents)

Invite the bot with bot + ap­pli­ca­tions.com­mands scopes

Set env vars in .env: DISCORD_BOT_TOKEN, DISCORD_APP_ID, DISCORD_GUILD_IDS

Run the API nor­mally — the bot starts as part of the FastAPI lifes­pan when DISCORD_BOT_TOKEN is set:

make dev

The bot is em­bed­ded in the API process (alongside the email poller, sched­uler, and re­sumer) so it shares the same SQLite data­base and ChromaDB vec­tor store un­der /data in pro­duc­tion. Skip the to­ken to dis­able.

For it­er­at­ing on bot-only code with­out restart­ing the API, make dis­cord runs the bot as a stand­alone process against the same lo­cal DB.

Users can DM the bot, @mention it in a chan­nel (replies in a thread), or use /ask and /today slash com­mands. Slash com­mands sync to DISCORD_GUILD_IDS in­stantly on startup; leave blank for global reg­is­tra­tion (up to 1-hour prop­a­ga­tion de­lay).

Deploying to pro­duc­tion

Just set the se­crets on the ex­ist­ing API app — no new Fly app re­quired:

fly­ctl se­crets set -a openexec-api-dev \ DISCORD_BOT_TOKEN=… \ DISCORD_APP_ID=… \ DISCORD_GUILD_IDS=…

Discord user ac­cess is man­aged via the /people UI — add a Person row with dis­cord_user_id set.

The ma­chine restarts and the bot starts on the next lifes­pan boot. To dis­able in prod: fly­ctl se­crets un­set -a openexec-api-dev DISCORD_BOT_TOKEN.

Onboarding Your Company

The first time you visit the app, you’ll be guided through a wiz­ard to set up your com­pany pro­file:

Company ba­sics (name, in­dus­try, stage, team size)

Business model and rev­enue

Competitive land­scape

Strategic pri­or­i­ties

Culture and val­ues

Optional: fi­nan­cial po­si­tion, doc­u­ment up­load

After on­board­ing, the Executive will ref­er­ence your spe­cific com­pany con­text in every re­sponse.

Interfaces

Document Upload

Upload your pitch deck, fi­nan­cial model, strat­egy docs, or any com­pany doc­u­ments via the web UI or API. The Executive will ref­er­ence them when rel­e­vant.

# Via CLI openex­ec­u­tive up­load deck.pdf model.xlsx strat­egy.md

# Via API curl -X POST http://​lo­cal­host:8000/​doc­u­ments \ -F “file=@deck.pdf” \ -F “domain=strategy”

Deployment (Fly.io)

Two en­vi­ron­ments, each a sep­a­rate set of Fly apps, dri­ven by branch:

Both work­flows use dorny/​paths-fil­ter to de­ploy only the changed app (API, UI, or both). QA is a sta­ble twin of dev — same im­age and run­time, only the app name dif­fers (fly.api.qa.toml / fly.ui.qa.toml) — so it lags main and stays vet­ted. An op­tional Honcho mem­ory app (fly.honcho.toml) de­ploys in­de­pen­dently.

Topology

⚠️ Single-instance only: The sched­uler claims rows via UPDATE … RETURNING. Running two API ma­chines would dou­ble-fire sched­uled ac­tions. max_­ma­chines_run­ning = 1 is set in fly.api.toml / fly.api.qa.toml — do not over­ride it.

⚠️ Single-instance only: The sched­uler claims rows via UPDATE … RETURNING. Running two API ma­chines would dou­ble-fire sched­uled ac­tions. max_­ma­chines_run­ning = 1 is set in fly.api.toml / fly.api.qa.toml — do not over­ride it.

Required GitHub Actions se­crets

Deploys au­then­ti­cate with per-app Fly de­ploy to­kens stored as repo (or org) Actions se­crets. Generate each with fly­ctl to­kens cre­ate de­ploy -a <app> -x 999999h:

Per-app run­time se­crets (ANTHROPIC_API_KEY, BACKEND_SHARED_SECRET, the AUTH_* set, in­te­gra­tion to­kens) are set di­rectly on each Fly app — see scripts/​fly-se­crets.sh.ex­am­ple.

One-time boot­strap (dev)

# 1. Create apps and vol­ume fly­ctl apps cre­ate openexec-api-dev fly­ctl apps cre­ate openexec-ui-dev fly­ctl vol­umes cre­ate ex­ec­u­tive_­data –region iad –size 1 -a openexec-api-dev

# 2. Set the re­quired se­cret fly­ctl se­crets set -a openexec-api-dev ANTHROPIC_API_KEY=sk-ant-…

# 3. Create de­ploy to­kens and add as GitHub se­crets FLY_API_TOKEN_API and FLY_API_TOKEN_UI fly­ctl to­kens cre­ate de­ploy -a openexec-api-dev -x 999999h fly­ctl to­kens cre­ate de­ploy -a openexec-ui-dev -x 999999h

# 4. First de­ploy gh work­flow run “Deploy (dev)” -f tar­get=both

QA boot­straps the same way against the -qa app names (push to the qa branch, or gh work­flow run “Deploy (qa)“). See docs/​de­ploy­ment.md for the full run­book (operations, roll­back, com­mon fail­ure modes, why .flycast is­n’t used).

Access con­trol

The de­ployed UI is gated be­hind Google sign-in with an email al­low-list, and the pub­lic API is pro­tected by a shared-se­cret header be­tween the UI proxy and the FastAPI back­end. See docs/​auth.md for the full setup (Google Cloud Console steps, re­quired Fly se­crets, adding/​re­mov­ing users, ro­tat­ing se­crets, and a de­bug­ging table).

Configuration

All set­tings via en­vi­ron­ment vari­ables. Minimum re­quired: ANTHROPIC_API_KEY — un­less you con­fig­ure a lo­cal or OpenRouter back­end in­stead (see Running on Local Models). At least one provider must be set or the app re­fuses to start.

See .env.example for the full list.

¹ ANTHROPIC_API_KEY is re­quired only when you serve Claude mod­els di­rectly. It can be omit­ted en­tirely if you run on lo­cal mod­els (LOCAL_MODELS_ENABLED) or route through OpenRouter (OPENROUTER_ENABLED).

¹ ANTHROPIC_API_KEY is re­quired only when you serve Claude mod­els di­rectly. It can be omit­ted en­tirely if you run on lo­cal mod­els (LOCAL_MODELS_ENABLED) or route through OpenRouter (OPENROUTER_ENABLED).

Running on Local Models

Open Executive can run against any OpenAI-compatible lo­cal server — Ollama, LM Studio, vLLM, or llama.cpp — in­stead of (or along­side) the Anthropic API. Local model slugs route to your server through the same provider ab­strac­tion the hosted mod­els use; no agent or or­ches­tra­tor code changes.

# 1. Pull a ca­pa­ble, tool-use-friendly model (example: Ollama) ol­lama pull lla­ma3.3

# 2. In .env — point at the lo­cal server and list the slugs to ex­pose LOCAL_MODELS_ENABLED=true LOCAL_BASE_URL=http://​lo­cal­host:11434/​v1 # Ollama de­fault LOCAL_MODELS=llama3.3

# 3. (Optional) run with NO Anthropic key — make lo­cal the de­fault every­where DEFAULT_MODEL=llama3.3 DEEP_REASONING_MODEL=llama3.3 ROUTING_MODEL=llama3.3 # …and leave ANTHROPIC_API_KEY un­set

The listed slugs ap­pear in the Council UI model drop­down, so you can also run a hy­brid setup — keep the Executive on Claude while flip­ping in­di­vid­ual spe­cial­ists to a lo­cal model per-agent.

Caveats. Server-side web search (ENABLE_WEB_SEARCH) and Anthropic prompt caching / ex­tended think­ing have no lo­cal equiv­a­lent and are au­to­mat­i­cally dis­abled for lo­cal mod­els. Multi-agent rout­ing leans heav­ily on tool use, so pick a model that’s strong at it (e.g. Llama 3.3 70B, Qwen2.5) — small mod­els may route poorly. LOCAL_API_KEY is only needed if your server (vLLM, or a gate­way) re­quires a bearer to­ken; Ollama and LM Studio need none.

Adding a New Specialist Agent

Create pack­ages/​core/​openex­ec­u­tive/​agents/​your_a­gent.py ex­tend­ing BaseAgent

Add a sys­tem prompt con­stant in pack­ages/​core/​openex­ec­u­tive/​prompts/​do­main_prompts.py

Register in pack­ages/​core/​openex­ec­u­tive/​or­ches­tra­tor/​router.py — add to SPECIALIST_REGISTRY and the spe­cial­ist enum in SPECIALIST_TOOLS

Add do­main alias to DOMAIN_ALIASES in pack­ages/​core/​openex­ec­u­tive/​knowl­edge/​re­triever.py

Add knowl­edge docs to knowl­edge/​builtin/​your_­do­main/

This post has made it to the Hacker News front page. See the dis­cus­sion.

Last week I came across a post on Hacker News that en­cour­aged ap­pli­ca­tion de­vel­op­ers to stop mak­ing ter­mi­nal user in­ter­faces1 (a.k.a. TUIs) and in­stead fo­cus on graph­i­cal user in­ter­faces (a.k.a. GUIs). The post reached the HN front page and sparked a lively de­bate in the com­ments sec­tion.

I think there is merit in both sides of the de­bate. On one hand, I un­der­stand the GUI-positive ar­gu­ments of the post au­thor. In the­ory, the ca­pa­bil­i­ties of GUI ap­pli­ca­tion frame­works are a su­per­set of the ca­pa­bil­i­ties of their TUI coun­ter­parts, so they should be pre­ferred. On the other hand, as a heavy ter­mi­nal user, I also greatly ap­pre­ci­ate all TUIs that al­low me to “stay” in the ter­mi­nal and ful­fill all my needs.

But I want to op­pose a re­cur­ring ar­gu­ment in fa­vor of TUIs that in my opin­ion does not have a solid foun­da­tion2. To para­phrase var­i­ous com­menters:

TUIs should be pre­ferred be­cause they are key­board-dri­ven.

TUIs should be pre­ferred be­cause they are key­board-dri­ven.

While it’s true that if you ran­domly pick a GUI and a TUI ap­pli­ca­tion, the lat­ter is more prob­a­ble to be fully key­board-dri­ven, this does not tip the scale in fa­vor of de­vel­op­ing TUIs over GUIs3. What it does is high­light the in­ad­e­qua­cies of key­board nav­i­ga­tion in many GUI ap­pli­ca­tions.

There is noth­ing pre­vent­ing a GUI from be­ing fully key­board-dri­ven4 just like — or even bet­ter than — a TUI. In fact, many GUI frame­work ap­pli­ca­tion guide­lines ex­plic­itly en­cour­age GUI ap­pli­ca­tion de­vel­op­ers to pro­vide sup­port for key­board-dri­ven nav­i­ga­tion that cov­ers the whole func­tion­al­ity of the ap­pli­ca­tion.

For ex­am­ple, the GNOME Human Interface Guidelines state that just as it should be pos­si­ble to per­form every ac­tion with a point­ing de­vice, every ac­tion should also be pos­si­ble with the key­board and that it should be pos­si­ble to move around and in­ter­act with every part of your user in­ter­face us­ing the key­board.

This res­onates with me as a user. Being able to in­tu­itively — and pre­dictably — nav­i­gate around a GUI ap­pli­ca­tion with only my key­board gives me more in­cen­tive to choose it com­pared to its al­ter­na­tives.

Knowing that, and when wear­ing my de­vel­oper hat, I have to make sure that my ap­pli­ca­tions are key­board-friendly. For my first ever GUI ap­pli­ca­tion, Klisi, I in­vested some time to im­ple­ment key­board short­cuts tar­get­ing the whole range of avail­able ac­tions.

Keyboard nav­i­ga­tion is not that hard to achieve in most cases and re­sults in an over­all bet­ter user ex­pe­ri­ence. It is not a mat­ter of fea­si­bil­ity, but a mat­ter of will on the ap­pli­ca­tion de­vel­op­er’s part.

The take­away is sim­ple. Do not com­pro­mise on the user ex­pe­ri­ence you pro­vide with your ap­pli­ca­tion. Strive to make it as in­tu­itive as pos­si­ble. To that end, en­abling full key­board nav­i­ga­tion should not be ig­nored.

Or al­ter­na­tively text-based user in­ter­faces. ↩

Or al­ter­na­tively text-based user in­ter­faces. ↩

The orig­i­nal post au­thor men­tions this as well. ↩

The orig­i­nal post au­thor men­tions this as well. ↩

There are other more com­pelling ar­gu­ments to­wards tip­ping that scale, for ex­am­ple ease of porta­bil­ity. ↩

There are other more com­pelling ar­gu­ments to­wards tip­ping that scale, for ex­am­ple ease of porta­bil­ity. ↩

Of course, the dex­ter­ity achieved via mouse is still pre­ferred — or even re­quired — for some tasks. ↩

Of course, the dex­ter­ity achieved via mouse is still pre­ferred — or even re­quired — for some tasks. ↩