Ghostty is now fis­cally spon­sored by Hack Club, a reg­is­tered 501(c)(3) non-profit.

Fiscal spon­sor­ship is a le­gal and fi­nan­cial arrange­ment in which a rec­og­nized non-profit ex­tends its tax-ex­empt sta­tus to a pro­ject that aligns with its mis­sion. This al­lows Ghostty to op­er­ate as a char­i­ta­ble ini­tia­tive while Hack Club man­ages com­pli­ance, do­na­tions, ac­count­ing, and gov­er­nance over­sight.

Being non-profit clearly demon­strates our com­mit­ment to keep­ing Ghostty free and open source for every­one. It paves the way for a model for sus­tain­able de­vel­op­ment be­yond my per­sonal in­volve­ment. And it also pro­vides im­por­tant le­gal pro­tec­tions and as­sur­ances to the peo­ple and com­mu­ni­ties that adopt and use Ghostty.

Since the be­gin­ning of the pro­ject in 2023 and the pri­vate beta days of Ghostty, I’ve re­peat­edly ex­pressed my in­ten­tion that Ghostty legally be­come a non-profit. This in­ten­tion stems from sev­eral core be­liefs I have.

First, I want to lay bricks for a sus­tain­able fu­ture for Ghostty that does­n’t de­pend on my per­sonal in­volve­ment tech­ni­cally or fi­nan­cially. Financially, I am still the largest donor to the pro­ject, and I in­tend to re­main so, but a non-profit struc­ture al­lows oth­ers to con­tribute fi­nan­cially with­out fear of mis­ap­pro­pri­a­tion or mis­use of funds (as pro­tected by le­gal re­quire­ments and over­sight from the fis­cal spon­sor).

Second, I want to squelch any pos­si­ble con­cerns about a

“rug pull”. A non-profit struc­ture pro­vides en­force­able as­sur­ances: the mis­sion can­not be qui­etly changed, funds can­not be di­verted to pri­vate ben­e­fit, and the pro­ject can­not be sold off or re­pur­posed for com­mer­cial gain. The struc­ture legally binds Ghostty to the pub­lic-ben­e­fit pur­pose it was cre­ated to serve.

Finally, de­spite be­ing decades-old tech­nol­ogy, ter­mi­nals and ter­mi­nal-re­lated tech­nolo­gies re­main foun­da­tional to mod­ern com­put­ing and soft­ware in­fra­struc­ture. They’re of­ten out of the lime­light, but they’re ever pre­sent on de­vel­oper ma­chines, em­bed­ded in IDEs, vis­i­ble as read-only con­soles for con­tin­u­ous in­te­gra­tion and cloud ser­vices, and still one of the pri­mary ways re­mote ac­cess is done on servers around the world.

I be­lieve in­fra­struc­ture of this kind should be stew­arded by a mis­sion-dri­ven,

non-com­mer­cial en­tity that pri­or­i­tizes pub­lic ben­e­fit over pri­vate profit.

That struc­ture in­creases trust, en­cour­ages adop­tion, and cre­ates the con­di­tions for Ghostty to grow into a widely used and im­pact­ful piece of open-source in­fra­struc­ture.

From a tech­ni­cal per­spec­tive, noth­ing changes for Ghostty. Our tech­ni­cal goals for the pro­ject re­main the same, the li­cense (MIT) re­mains the same, and we con­tinue our work to­wards bet­ter Ghostty GUI re­leases and

libghostty.

Financially, Ghostty can now ac­cept tax-de­ductible do­na­tions in the United States. This opens up new av­enues for fund­ing the pro­ject and sus­tain­ing de­vel­op­ment over the long term. Most im­me­di­ately, I’m ex­cited to be­gin

com­pen­sat­ing con­trib­u­tors, but I also in­tend to sup­port up­stream de­pen­den­cies, fund com­mu­nity events, and pay for bor­ing op­er­a­tional costs.

All our fi­nan­cial trans­ac­tions will be trans­par­ent down to in­di­vid­ual trans­ac­tions for both in­flows and out­flows. You can view our pub­lic ledger at Ghostty’s page on Hack Club Bank. At the time of writ­ing, this is empty, but you’ll soon see some ini­tial fund­ing from me and the be­gin­ning of pay­ing for some of our op­er­a­tional costs.

All ap­plic­a­ble names, marks, and in­tel­lec­tual prop­erty as­so­ci­ated with Ghostty have been trans­ferred to Hack Club and are now owned un­der the non-profit um­brella. Copyright con­tin­ues to be held by in­di­vid­ual con­trib­u­tors un­der the con­tin­ued and ex­ist­ing li­cense struc­ture.

From a lead­er­ship per­spec­tive, I re­main the pro­ject lead and fi­nal au­thor­ity on all de­ci­sions, but as stated ear­lier, the cre­ation of a non-profit struc­ture lays the ground­work for an even­tual fu­ture be­yond this model.

As our fis­cal spon­sor, Hack Club pro­vides es­sen­tial ser­vices to Ghostty, in­clud­ing ac­count­ing, le­gal com­pli­ance, and gov­er­nance over­sight. To sup­port this, 7% of all do­na­tions to Ghostty go to Hack Club to cover these costs in ad­di­tion to sup­port­ing their broader mis­sion of em­pow­er­ing young peo­ple around the world in­ter­ested in tech­nol­ogy and cod­ing.

In the words of Zach Latta, Hack Club’s founder and ex­ec­u­tive di­rec­tor this is a “good-for-good” trade. Instead of donor fees go­ing to a for-profit man­age­ment com­pany or cov­er­ing pure over­head of a sin­gle pro­ject, the fees go to an­other non-profit do­ing im­por­tant work in the tech com­mu­nity and the over­head is amor­tized across many pro­jects.

In ad­di­tion to the 7% fees, my fam­ily is per­son­ally do­nat­ing $150,000

di­rectly to the Hack Club pro­ject1 (not to Ghostty within it). Hack Club does amaz­ing work and I would’ve sup­ported them re­gard­less of their fis­cal spon­sor­ship of Ghostty, but I wanted to pair these two things to­gether to am­plify the im­pact of both.

Please con­sider do­nat­ing to sup­port Ghostty’s con­tin­ued de­vel­op­ment.

I rec­og­nize that Ghostty is al­ready in an ab­nor­mally for­tu­nate po­si­tion to have my­self as a backer, but I do en­vi­sion a fu­ture where Ghostty is more equally sup­ported by a broader com­mu­nity. And with our new struc­ture, you can be as­sured about the us­age of your funds

to­wards pub­lic-ben­e­fit goals.

This post is­n’t meant to di­rectly be a fundrais­ing pitch

so it is pur­posely lack­ing crit­i­cal de­tails about our fund­ing goals, bud­get, pro­ject goals, pro­ject met­rics, etc. I’ll work on those in the fu­ture. In the mean time, if you’re in­ter­ested in talk­ing more about sup­port­ing Ghostty, please email me at m@mitchellh.com.

I’m thank­ful for Hack Club and their team for work­ing with us to make this hap­pen. I’m also thank­ful for the Ghostty com­mu­nity who has sup­ported this pro­ject and has trusted me and con­tin­ues to trust me to stew­ard it re­spon­si­bly.

For more in­for­ma­tion about Ghostty’s non-profit struc­ture, see the

ded­i­cated page on Ghostty’s web­site.

is a se­nior ed­i­tor and found­ing mem­ber of The Verge who cov­ers gad­gets, games, and toys. He spent 15 years edit­ing the likes of CNET, Gizmodo, and Engadget.

is a se­nior ed­i­tor and found­ing mem­ber of The Verge who cov­ers gad­gets, games, and toys. He spent 15 years edit­ing the likes of CNET, Gizmodo, and Engadget.

The game it­self is a Windows ex­e­cutable, right? At a core level, the Linux op­er­at­ing sys­tem does not even know how to load the pro­gram, and so, in­stead of in­vok­ing it through the OS, you in­voke it through Proton, which is go­ing to do the first step of set­ting up the ad­dress space, load­ing the seg­ments of code into mem­ory. The code com­ing from the app is all x86, and so Proton is a fa­cil­i­ta­tor. It puts the ex­ist­ing code of the app in a for­mat and a lay­out that the Linux OS can un­der­stand and then starts ex­e­cut­ing that code.

I grabbed lunch with a for­mer Microsoft coworker I’ve al­ways ad­mired—one of those en­gi­neers who can take any idea, even a mediocre one, and im­me­di­ately find the gold in it. I wanted her take on Wanderfugl 🐦, the AI-powered map I’ve been build­ing full-time. I ex­pected en­cour­age­ment. At worst, overly gen­er­ous feed­back be­cause she knows what I’ve sac­ri­ficed.

Instead, she re­acted to it with a level of neg­a­tiv­ity I’d never seen her di­rect at me be­fore.

When I fi­nally got her to ex­plain what was wrong, none of it had any­thing to do with what I built. She talked about Copilot 365. And Microsoft AI. And every mis­er­able AI tool she’s forced to use at work. My prod­uct barely fea­tured. Her re­ac­tion was­n’t about me at all. It was about her en­tire en­vi­ron­ment.

Her PM had been laid off months ear­lier. The team asked why. Their di­rec­tor told them it was be­cause the PM org “wasn’t ef­fec­tive enough at us­ing Copilot 365.”

I ner­vously laughed. This di­rec­tor got up in a group meet­ing and said that some­one lost their job over this?

After a pause I tried to share how much bet­ter I’ve been feel­ing—how AI tools helped me learn faster, how much they ac­cel­er­ated my work on Wanderfugl. I did­n’t fully grok how tone deaf I was be­ing though. She’s drown­ing in re­sent­ment.

I left the lunch de­flated and weirdly guilty, like build­ing an AI prod­uct made me part of the prob­lem.

But then I re­al­ized this was big­ger than one con­ver­sa­tion. Every time I shared Wanderfugl with a Seattle en­gi­neer, I got the same re­flex­ive, crit­i­cal, neg­a­tive re­sponse. This was­n’t true in Bali, Tokyo, Paris, or San Francisco—people were cu­ri­ous, en­gaged, wanted to un­der­stand what I was build­ing. But in Seattle? Instant hos­til­ity the mo­ment they heard “AI.”

The peo­ple at big tech in Seattle are not ok

When I joined Microsoft, there was still a sense of pos­si­bil­ity. Satya was push­ing “growth mind­set” every­where. Leaders talked about em­pow­er­ment and break­ing down si­los. And even though there was al­ways a gap be­tween the slo­gans and re­al­ity, there was room to try things.

I leaned into it. I pushed into ar­eas no­body wanted to touch, like Windows up­date com­pres­sion, be­cause it lived awk­wardly across three teams. Somehow, a 40% im­prove­ment made it out alive. Leadership backed it. The peo­ple try­ing to kill it shrank back into their fief­doms. It felt like the cul­ture wanted change.

That world is gone.

When the lay­off di­rec­tive hit, every org braced for im­pact. Anything not strictly in­side the org’s char­ter was axed. I went from ship­ping a ma­jor im­prove­ment in Windows 11 to hav­ing zero pro­jects overnight. I quit shortly af­ter. In hind­sight, get­ting laid off with sev­er­ance might’ve been bet­ter than watch­ing the cul­ture col­lapse in slow mo­tion.

Then came the AI panic.

If you could clas­sify your pro­ject as “AI,” you were safe and pres­ti­gious. If you could­n’t, you were no­body. Overnight, most en­gi­neers got re­branded as “not AI tal­ent.” And then came the fi­nal in­sult: every­one was forced to use Microsoft’s AI tools whether they worked or not.

Copilot for Word. Copilot for PowerPoint. Copilot for email. Copilot for code. Worse than the tools they re­placed. Worse than com­peti­tors’ tools. Sometimes worse than do­ing the work man­u­ally.

But you weren’t al­lowed to fix them—that was the AI org’s turf. You were sup­posed to use them, fail to see pro­duc­tiv­ity gains, and keep quiet.

Meanwhile, AI teams be­came a pro­tected class. Everyone else saw comp stag­nate, stock re­fresh­ers evap­o­rate, and per­for­mance re­views tank. And if your team failed to meet ex­pec­ta­tions? Clearly you weren’t “embracing AI.”

Bring up AI in a Seattle cof­fee shop now and peo­ple re­act like you’re ad­vo­cat­ing as­bestos.

Amazon folks are slightly more in­su­lated, but not by much. The old Seattle deal—Ama­zon treats you poorly but pays you more—only masks the rot.

This be­lief sys­tem—that AI is use­less and that you’re not good enough to work on it any­way—hurts three groups:

1. The com­pa­nies.

They’ve taught their best en­gi­neers that in­no­va­tion is­n’t their job.

2. The en­gi­neers.

They’re stuck in re­sent­ment and self-doubt while their ca­reers stall.

3. Anyone try­ing to build any­thing new in Seattle.

Say “AI” and peo­ple treat you like a threat or an id­iot.

And the loop feeds it­self:

Engineers don’t try be­cause they think they can’t.

Companies don’t em­power them be­cause they as­sume they should­n’t.

Bad prod­ucts re­in­force the be­lief that AI is doomed.

The spi­ral locks in.

My for­mer coworker—the com­pos­ite of three peo­ple for anonymity—now be­lieves she’s both un­qual­i­fied for AI work and that AI is­n’t worth do­ing any­way. She’s wrong on both counts, but the cul­ture made sure she’d land there.

Seattle has tal­ent as good as any­where. But in San Francisco, peo­ple still be­lieve they can change the world—so some­times they ac­tu­ally do.

Update 2025/02/04: Oracle asks the USPTO to dis­miss our pe­ti­tion. Read more

Update 2024/11/22: We’ve filed a pe­ti­tion to can­cel with the USPTO. Read more

Update 2025/02/04: Oracle asks the USPTO to dis­miss our pe­ti­tion. Read more

Update 2024/11/22: We’ve filed a pe­ti­tion to can­cel with the USPTO. Read more

You have long ago aban­doned the JavaScript trade­mark, and it is caus­ing

wide­spread, un­war­ranted con­fu­sion and dis­rup­tion.

JavaScript is the world’s most pop­u­lar pro­gram­ming lan­guage, pow­er­ing web­sites every­where. Yet, few of the mil­lions who pro­gram in it re­al­ize that JavaScript is a trade­mark you, Oracle, con­trol. The dis­con­nect is glar­ing: JavaScript has be­come a gen­eral-pur­pose term used by count­less in­di­vid­u­als and com­pa­nies, in­de­pen­dent of any Oracle prod­uct.

Oracle’s hold on the JavaScript trade­mark clearly fits the le­gal de­f­i­n­i­tion of

trade­mark aban­don­ment. A pre­vi­ous

blog post ad­dressed this is­sue, re­quest­ing that you, Oracle, re­lease the trade­mark. Unsurprisingly, the re­quest was met with si­lence. It is there­fore time to take ac­tive steps in or­der to bring the JavaScript trade­mark into the pub­lic do­main, where it be­longs.

A mark shall be deemed to be “abandoned” if ei­ther of the fol­low­ing oc­curs:

When

its use has

been dis­con­tin­ued with in­tent not to re­sume

such use.

Intent not to re­sume may be in­ferred from cir­cum­stances. Nonuse for 3

con­sec­u­tive years shall be prima fa­cie ev­i­dence of aban­don­ment.

“Use”

of

a mark means

the bona

fide use of

such mark made

in the or­di­nary course of trade, and not made merely to re­serve a right in

a mark.

When any course of con­duct of the owner, in­clud­ing acts of omis­sion as well

as com­mis­sion, causes

the mark to

be­come the generic name for the goods or ser­vices on or in con­nec­tion with

which it is used or oth­er­wise to lose its sig­nif­i­cance as

a mark.

Purchaser mo­ti­va­tion shall not be a test for de­ter­min­ing aban­don­ment un­der

this para­graph.

In the case of JavaScript, both cri­te­ria ap­ply.

The JavaScript trade­mark is cur­rently held by Oracle America, Inc. (US Serial Number: 75026640, US Registration Number: 2416017). How did this come to be?

In 1995, Netscape part­nered with Sun Microsystems to cre­ate in­ter­ac­tive web­sites. Brendan Eich fa­mously spent only 10 days cre­at­ing the first ver­sion of JavaScript, a dy­namic pro­gram­ming lan­guage with a rough syn­tac­tic lin­eage from Sun’s Java lan­guage. As a re­sult of this part­ner­ship, Sun held the JavaScript trade­mark. In 2009, Oracle ac­quired Sun Microsystems and the JavaScript trade­mark as a re­sult.

The trade­mark is sim­ply a relic of this ac­qui­si­tion. Neither Sun nor Oracle has ever built a prod­uct us­ing the mark. Legal staff, year af­ter year, have re­newed the trade­mark with­out ques­tion. It’s likely that only a few within Oracle even know they pos­sess the JavaScript trade­mark, and even if they do, they likely don’t un­der­stand the frus­tra­tion it causes within the de­vel­oper com­mu­nity.

Oracle has aban­doned the JavaScript trade­mark through nonuse.

Oracle has never se­ri­ously of­fered a prod­uct called JavaScript. In the 1990s and early 2000s, Netscape Navigator, which sup­ported JavaScript as a browser fea­ture, was a key player. However, Netscape’s us­age and in­flu­ence faded by 2003, and the browser saw its fi­nal re­lease in 2008. JavaScript, mean­while, evolved into a widely used, in­de­pen­dent pro­gram­ming lan­guage, em­bed­ded in mul­ti­ple browsers, en­tirely sep­a­rate from Oracle.

The most re­cent

spec­i­men, filed with the USPTO in 2019, ref­er­ences nodejs.org (a pro­ject cre­ated by Ryan Dahl, the au­thor of this let­ter) and Oracle’s

JavaScript Extension Toolkit (JET). But Node.js is not an Oracle prod­uct, and JET is merely a set of JavaScript li­braries for Oracle ser­vices, par­tic­u­larly Oracle Cloud. There are mil­lions of JavaScript li­braries; JET is not spe­cial.

Oracle also of­fers GraalVM, a JVM that can ex­e­cute JavaScript, among other lan­guages. But GraalVM is far from a canon­i­cal JavaScript im­ple­men­ta­tion; en­gines like V8, JavaScriptCore, and SpiderMonkey hold that role. GraalVM’s prod­uct page does­n’t even men­tion “JavaScript”; you must dig into the doc­u­men­ta­tion to find its sup­port.

Oracle’s use of JavaScript in GraalVM and JET does not re­flect gen­uine use of

the trade­mark. These weak con­nec­tions do not sat­isfy the re­quire­ment for con­sis­tent, real-world use in trade.

A mark can also be con­sid­ered aban­doned if it be­comes a generic term.

In 1996, Netscape

an­nounced

a meet­ing of the ECMA International stan­dards or­ga­ni­za­tion to stan­dard­ize the JavaScript pro­gram­ming lan­guage. Sun (now Oracle), re­fused to give up the “JavaScript” mark for this use though, so it was de­cided that the lan­guage would be called “ECMAScript” in­stead. (Microsoft hap­pily of­fered up “JScript”, but no-one else wanted that.) Brendan Eich, the cre­ator of JavaScript and a co-sig­na­tory of this let­ter,

wrote in 2006

that “ECMAScript was al­ways an un­wanted trade name that sounds like a skin dis­ease.”

Ecma International formed TC39, a tech­ni­cal steer­ing com­mit­tee, which pub­lishes ECMA-262, the spec­i­fi­ca­tion for JavaScript. This com­mit­tee in­cludes par­tic­i­pants from all ma­jor browsers, like Google’s Chrome, Apple’s Safari, and Mozilla’s Firefox, as well as rep­re­sen­ta­tives from server-side JavaScript run­times like Node.js and Deno.

Oracle’s own­er­ship of the JavaScript trade­mark only causes con­fu­sion. The term “JavaScript” is used freely by mil­lions of de­vel­op­ers, com­pa­nies, and or­ga­ni­za­tions around the world, with no in­ter­fer­ence from Oracle. Oracle has done noth­ing to as­sert its rights over the JavaScript name, likely be­cause they do not be­lieve their claim to the mark would hold up in court. Unlike typ­i­cal trade­mark hold­ers who pro­tect their trade­marks by ex­tract­ing li­cens­ing fees or en­forc­ing us­age re­stric­tions, Oracle has al­lowed the JavaScript name to be used by any­one. This in­ac­tion fur­ther sup­ports the ar­gu­ment that the trade­mark has lost its sig­nif­i­cance and has be­come generic.

Programmers work­ing with JavaScript have formed in­nu­mer­able com­mu­nity or­ga­ni­za­tions. These or­ga­ni­za­tions, like the stan­dards bod­ies, have been forced to painstak­ingly avoid nam­ing the pro­gram­ming lan­guage they are built around—for ex­am­ple, JSConf. Sadly, with­out risk­ing a le­gal trade­mark chal­lenge against Oracle, there can be no “JavaScript Conference” nor a “JavaScript Specification.” The world’s most pop­u­lar pro­gram­ming lan­guage can­not even have a con­fer­ence in its name.

There is a vast mis­align­ment be­tween the trade­mark’s own­er­ship and its

wide­spread, generic use.

By law, a trade­mark is aban­doned if it is ei­ther not used or be­comes a generic

term. Both ap­ply to JavaScript.

It’s time for the USPTO to end the JavaScript trade­mark and rec­og­nize it as a generic name for the world’s most pop­u­lar pro­gram­ming lan­guage, which has mul­ti­ple im­ple­men­ta­tions across the in­dus­try.

Oracle, you likely have no real busi­ness in­ter­est in the mark. It’s re­newed sim­ply be­cause le­gal staff are ob­lig­ated to re­new all trade­marks, re­gard­less of their rel­e­vance or use.

We urge you to re­lease the mark into the pub­lic do­main. However, ask­ing nicely has been tried be­fore, and it was met with si­lence. If you do not act, we will chal­lenge your own­er­ship by fil­ing a pe­ti­tion for can­cel­la­tion with the USPTO.

Buying a home or re­fi­nanc­ing a mort­gage is tough enough with­out con­fus­ing ads from banks and big lenders.

Credit unions can of­fer com­pet­i­tive rates com­pared to big banks be­cause they’re mem­ber-owned, non-profit in­sti­tu­tions. They fo­cus on serv­ing their mem­bers, not max­i­miz­ing prof­its for share­hold­ers.

But with­out big bud­gets and mar­ket­ing de­part­ments, credit union rates aren’t al­ways easy to find or com­pare. That’s why we built a daily-up­dated com­par­i­son of mort­gage rates from over 120 credit unions across the United States.

When we bought our home, the big bank I’d been us­ing for years tried to sell me on a mort­gage with 7% APR. Turns out a lo­cal credit union was of­fer­ing 5.5% for the ex­act same mort­gage.

What sur­prised me most was­n’t that there were cheaper op­tions, but that two mort­gages can be ex­actly the same prod­uct, just with dif­fer­ent pack­ag­ing.

In the USA, the gov­ern­ment buys al­most all mort­gages, re­quir­ing them to be stan­dard­ized. So why the price dif­fer­ence? As ex­plored in this Bloomberg Odd Lots episode about credit card rates, higher rates are mostly to pay for ad­ver­tis­ing and mar­ket­ing. Big banks have mar­ket­ing de­part­ments that non-profit credit unions don’t have.

That “exclusive” in­box of­fer from Chase or Wells Fargo is­n’t gen­eros­ity. It’s a bet that you won’t shop around. My goal with this tool is sim­ple: help peo­ple re­al­ize they have op­tions and po­ten­tially save thou­sands of dol­lars a year.

Rates are col­lected through­out the day from the web­sites of ap­prox­i­mately 120 credit unions. National bench­marks come from the St. Louis Federal Reserve Bank, aka FRED: 30-Year Fixed bench­mark (15Y). These up­date weekly.

Some rates (around a dozen) are hid­den by de­fault be­cause they’re sta­tis­ti­cal out­liers: likely er­rors or ul­tra-spe­cial­ized prod­ucts. Toggle “Show out­liers” in the fil­ters if you want to see them any­way.

Our dash­board can only take you so far. Your ac­tual rate de­pends on: credit score, down pay­ment (20%+ is ideal), prop­erty type (primary res­i­dence gets best rates), and whether you pay points for a lower rate (always com­pare APR).

Next step: Get quotes from mul­ti­ple lenders by us­ing the rate table above to con­tact in­sti­tu­tions.

Protip: Before sub­mit­ting to any credit checks, pro­tect your pri­vacy with optout­pre­screen.com, an­other free and reg­u­lated ser­vice I wish I’d known about sooner.

Still not sure about buy­ing or re­fi­nanc­ing? Check out these in­ter­ac­tive guides:

FinFam is built around col­lab­o­ra­tive fi­nan­cial plan­ning, in­clud­ing com­mu­nity-au­thored, spread­sheet-pow­ered guides, like those above.

Read more in our docs.

Have ques­tions about these rates or sug­ges­tions for im­prov­ing this tool? Reach out to us at blog@fin­fam.app.

Don’t see your fa­vorite CU here? As long as it has a web­site with a pub­lic rates page and clear el­i­gi­bil­ity re­quire­ments, we’d be happy to add it!

These rates are in­for­ma­tional only and don’t rep­re­sent rate locks. Your ac­tual rate will vary. Contact lenders with the links in the rate table to get your per­son­al­ized quotes. FinFam has no in­sti­tu­tional af­fil­i­a­tion and re­ceives no re­fer­ral fees, nor pro­vides any guar­an­tees.

Shoutout /r/dataisbeautiful for the en­cour­age­ment. And big thanks to Asheesh Laroia for his guid­ance on the mat­ter of mort­gages.

See his spread­sheet-friendly take on the data.

Self-host and scale web apps

with­out the com­plex­ity

Take your Docker Compose apps to pro­duc­tion with zero-down­time de­ploy­ments, au­to­matic HTTPS, and cross-ma­chine scal­ing. No Kubernetes re­quired.

# Start with any cloud VM or your own server

$ uc ma­chine init [email protected]

# Deploy your app with au­to­matic HTTPS

$ uc run –name my-app -p app.ex­am­ple.com:8000/​https app-im­age:lat­est

✨ Your app is avail­able at https://​app.ex­am­ple.com

# Achieve high avail­abil­ity by adding more ma­chines and scal­ing the app

$ uc ma­chine add [email protected]

$ uc scale my-app 2

PaaS-like work­flow on your own servers

Deploy with the sim­plic­ity of Heroku or Fly.io while keep­ing full con­trol over your in­fra­struc­ture.

Full con­trol over your servers and data

SSH into ma­chines and de­bug with stan­dard tools

Build, push, and de­ploy with one com­mand

No con­trol plane or quo­rum to man­age

Uncloud re­places com­plex clus­ters with a sim­ple net­work of ma­chines work­ing seam­lessly to­gether — no main­te­nance over­head, just re­li­able in­fra­struc­ture.

Each ma­chine joins a WireGuard mesh net­work with au­to­matic peer dis­cov­ery

and NAT tra­ver­sal. Containers get unique IPs and can com­mu­ni­cate di­rectly

across ma­chines.

Unlike tra­di­tional or­ches­tra­tors, there’s no cen­tral con­trol plane to

main­tain. Each ma­chine main­tains a syn­chro­nised copy of the clus­ter

state

through peer-to-peer com­mu­ni­ca­tion, keep­ing clus­ter op­er­a­tions

func­tional

even if some ma­chines go of­fline.

Control your en­tire in­fra­struc­ture us­ing in­tu­itive Docker-like com­mands from

any­where. Deploy, mon­i­tor, and scale ap­pli­ca­tions across all your ma­chines

while the CLI only needs SSH ac­cess to a sin­gle ma­chine.

Run your apps on any Linux ma­chine — from cloud VMs and ded­i­cated servers to bare metal at your of­fice or home.

Get free TLS cer­tifi­cates and au­to­matic HTTPS for your do­mains with zero con­fig­u­ra­tion us­ing built-in Caddy re­verse proxy.

Distribute traf­fic across con­tainer repli­cas run­ning on dif­fer­ent ma­chines for im­proved re­li­a­bil­ity and per­for­mance.

Access any ser­vice by its name from any con­tainer us­ing the built-in DNS that au­to­mat­i­cally tracks ser­vices across your net­work.

Define your en­tire app stack in a fa­mil­iar Docker Compose file. No need to learn a new con­fig for­mat.

Mix cloud providers and your own hard­ware freely to op­ti­mise costs and per­for­mance, with­out chang­ing how you de­ploy or man­age apps.

Deploy a highly avail­able web app with au­to­matic HTTPS across mul­ti­ple re­gions and on-premises in just a cou­ple min­utes.

Lately I’ve been read­ing Sean Goedecke’s es­says on be­ing a Staff+ en­gi­neer. His work (particularly Software en­gi­neer­ing un­der the spot­light and It’s Not Your Codebase) is ra­zor-sharp and feels painfully fa­mil­iar to any­one in Big Tech.

On pa­per, I fit the mold he de­scribes: I’m a Senior Staff en­gi­neer at Google. Yet, read­ing his work left me with a lin­ger­ing sense of un­ease. At first, I dis­missed this as cyn­i­cism. After re­flect­ing, how­ever, I re­al­ized the prob­lem was­n’t Sean’s writ­ing but my read­ing.

Sean is­n’t be­ing bleak; he is ac­cu­rately de­scrib­ing how to deal with a world where en­gi­neers are fun­gi­ble as­sets and pri­or­i­ties shift quar­terly. But my job looks noth­ing like that and I know deep down that if I tried to op­er­ate in that en­vi­ron­ment or in the way he de­scribed I’d burn out within months.

Instead I’ve fol­lowed an al­ter­nate path, one that op­ti­mizes for sys­tems over spot­lights, and stew­ard­ship over fun­gi­bil­ity.

The foun­da­tional rea­son for our di­verg­ing paths is that Sean and I op­er­ate in en­tirely dif­fer­ent worlds with dif­fer­ent laws gov­ern­ing them.

From Sean’s re­sume, my un­der­stand­ing is that he has pri­mar­ily worked in prod­uct teams build­ing for ex­ter­nal cus­tomers. Business goals pivot quar­terly, and suc­cess is mea­sured by rev­enue or MAU. Optimizing for the “Spotlight” makes com­plete sense in this en­vi­ron­ment. Product de­vel­op­ment at big tech scale is a crowded room: VPs, PMs and UX de­sign­ers all have strong opin­ions. To suc­ceed, you have to be ag­ile and en­sure you are work­ing specif­i­cally on what ex­ec­u­tives are cur­rently look­ing at.

On the other hand, I’ve spent my en­tire ca­reer much more be­hind the scenes: in de­vel­oper tools and in­fra teams.

My team’s cus­tomers are thou­sands of en­gi­neers in Android, Chrome, and through­out Google . End users of Google prod­ucts don’t even know we ex­ist; our fo­cus is on mak­ing sure de­vel­op­ers have the tools to col­lect prod­uct and per­for­mance met­rics and de­bug is­sues us­ing de­tailed traces.

In this en­vi­ron­ment, our re­la­tion­ship with lead­er­ship is very dif­fer­ent. We’re never the “hot pro­ject every­one wants,” so ex­ecs are not fight­ing to work with us. In fact, my team has his­tor­i­cally strug­gled to hire PMs. The PM ca­reer lad­der at Google in­cen­tivizes splashy ex­ter­nal launches so we can­not pro­vide good “promotion ma­te­r­ial” for them. Also, our feed­back comes di­rectly from en­gi­neers. Adding a PM in the mid­dle causes a loss in trans­la­tion, slow­ing down a tight, high-band­width feed­back loop.

All of this to­gether means our team op­er­ates “bottom-up”: in­stead of ex­ecs telling us “you should do X”, we fig­ure out what we think will have the most im­pact to our cus­tomers and work on build­ing those fea­tures and tools. Execs en­sure that we’re ac­tu­ally solv­ing these prob­lems by con­sid­er­ing our im­pact on more prod­uct fac­ing teams.

In the prod­uct en­vi­ron­ments Sean de­scribes, where goals pivot quar­terly and fea­tures are of­ten ex­per­i­men­tal, speed is the ul­ti­mate cur­rency. You need to ship, it­er­ate, and of­ten move on be­fore the mar­ket shifts. But in Infrastructure and Developer Experience, con­text is the cur­rency.

Treating en­gi­neers as fun­gi­ble as­sets de­stroys con­text. You might gain fresh eyes, but you lose the im­plicit knowl­edge of how sys­tems ac­tu­ally break. Stewardship, stay­ing with a sys­tem long-term, un­locks com­pound­ing re­turns that are im­pos­si­ble to achieve on a short ro­ta­tion.

The first is ef­fi­ciency via pat­tern match­ing. When you stay in one do­main for years, new re­quests are rarely truly “new.” I am not just de­bug­ging code; I am de­bug­ging the in­ter­sec­tion of my tools and hun­dreds of di­verse en­gi­neer­ing teams. When a new team comes to me with a “unique” prob­lem, I can of­ten reach back in time: “We tried this ap­proach in 2021 with the Camera team; here is ex­actly why it failed, and here is the ar­chi­tec­ture that ac­tu­ally works”.

But the more pow­er­ful re­turn is sys­temic in­no­va­tion. If you ro­tate teams every year, you are lim­ited to solv­ing acute bugs that are vis­i­ble right now. Some prob­lems, how­ever, only re­veal their shape over long hori­zons.

Take Bigtrace, a pro­ject I re­cently led; it was a so­lu­tion that emerged solely be­cause I stuck around long enough to see the shape of the prob­lem:

* Start of 2023 (Observation): I be­gan notic­ing a pat­tern. Teams across Google were col­lect­ing ter­abytes or even petabytes of per­for­mance traces, but they were strug­gling to process them. Engineers were writ­ing brit­tle, cus­tom pipelines to parse data, of­ten com­plain­ing about how slow and painful it was to it­er­ate on their analy­sis.

* Most of 2023 (Research): I did­n’t jump to build a pro­duc­tion sys­tem. Instead, I spent the best part of a year pro­to­typ­ing qui­etly in the back­ground while work­ing on other pro­jects. I gath­ered feed­back from these same en­gi­neers who had com­plained and be­cause I had es­tab­lished long-term re­la­tion­ships, they gave me hon­est and in­tro­spec­tive feed­back. I learned what sort of UX, la­tency and through­put re­quire­ments they had and fig­ured out how I could meet them.

* End of 2023 to Start of 2024 (Execution): We built and launched Bigtrace, a dis­trib­uted big data query en­gine for traces. Today, it processes over 2 bil­lion traces a month and is a crit­i­cal part of the daily work­flow for 100+ en­gi­neers.

If I had fol­lowed the ad­vice to “optimize for fun­gi­bil­ity” (i.e. if I had switched teams in 2023 to chase a new pro­ject) Bigtrace would not ex­ist.

Instead, I would have left dur­ing the re­search phase and my suc­ces­sor would have seen the same “noise” of en­gi­neers com­plain­ing. But with­out the his­tor­i­cal con­text to rec­og­nize a miss­ing puz­zle piece, I think they would have strug­gled to build some­thing like Bigtrace.

One of the most se­duc­tive ar­gu­ments for chas­ing the “Spotlight” is that it guar­an­tees re­sources and ex­ec­u­tive at­ten­tion. But that at­ten­tion is a dou­ble-edged sword.

High-visibility pro­jects are of­ten volatile. They come with shift­ing ex­ec­u­tive whims, po­lit­i­cal ma­neu­ver­ing, and of­ten end up in sit­u­a­tions where long-term qual­ity is sac­ri­ficed for short-term sur­vival. For some en­gi­neers, nav­i­gat­ing this chaos is a thrill. For those of us who care about sys­tem sta­bil­ity, it feels like a trap.

The ad­van­tage of stew­ard­ship is that it gen­er­ates a dif­fer­ent kind of cap­i­tal: trust. When you have spent years de­liv­er­ing re­li­able tools, you earn the po­lit­i­cal cap­i­tal to say “No” to the spot­light when it threat­ens the prod­uct.

Recently, the spot­light has been on AI. Every team is un­der pres­sure to in­cor­po­rate it. We have been asked re­peat­edly: “Why don’t you in­te­grate LLMs into Perfetto?” If I were op­ti­miz­ing for vis­i­bil­ity, the an­swer would be ob­vi­ous: build an LLM wrap­per, demo it to lead­er­ship, and claim we are “AI-first.” It would be an easy win for my ca­reer.

But as a stew­ard of the sys­tem, I know that one of Perfetto’s core val­ues is pre­ci­sion. When a ker­nel de­vel­oper is de­bug­ging a race con­di­tion, they need ex­act time­stamps, not a hal­lu­ci­na­tion. Users trust that when we tell them “X is the prob­lem” that it ac­tu­ally is the prob­lem and they’re not go­ing to go chas­ing their tail for the next week, de­bug­ging an is­sue which does­n’t ex­ist.

But it’s im­por­tant not to take this too far: skep­ti­cism should­n’t be­come ob­struc­tion­ism. With AI, it’s not “no for­ever” but “not un­til it can be done right” .

A spot­light-seek­ing en­gi­neer might view this ap­proach as a missed op­por­tu­nity; I view it as pro­tect­ing what makes our prod­uct great: user trust.

The most com­mon fear en­gi­neers have about leav­ing the “Spotlight” is ca­reer stag­na­tion. The logic goes: If I’m not launch­ing flashy fea­tures at Google I/O, and my work is­n’t on my VP’s top 5 list, how will I ever get pro­moted to Staff+?

It is true that you lose the cur­rency of “Executive Visibility.” But in in­fra­struc­ture, you gain two al­ter­nate cur­ren­cies that are just as valu­able, and po­ten­tially more sta­ble.

In a prod­uct or­ga­ni­za­tion, you of­ten need to im­press your man­ager’s man­ager. In an in­fra­struc­ture or­ga­ni­za­tion, you need to im­press your cus­tomers’ man­agers.

I call this the Shadow Hierarchy. You don’t need your VP to un­der­stand the in­tri­ca­cies of your code. You need the Staff+ Engineers in other crit­i­cal or­ga­ni­za­tions to need your tools.

When a Senior Staff Engineer in Pixel tells their VP, “We lit­er­ally can­not de­bug the next Pixel phone with­out Perfetto”, that state­ment car­ries im­mense weight. It trav­els up their re­port­ing chain, crosses over at the Director/VP level, and comes back down to your man­ager.

This kind of ad­vo­cacy is pow­er­ful be­cause it is tech­ni­cal, not po­lit­i­cal. It is hard to fake. When you are a stew­ard of a crit­i­cal sys­tem, your pro­mo­tion packet is filled with tes­ti­mo­ni­als from the most re­spected en­gi­neers in the com­pany say­ing, “This per­son’s work en­abled our suc­cess”.

While prod­uct teams might be por­ing over daily ac­tive users or rev­enue, we rely on met­rics track­ing en­gi­neer­ing health:

* Utility: Every bug fixed us­ing our tools is an en­gi­neer find­ing us use­ful. It is the purest mea­sure of util­ity.

* Criticality: If the Pixel team uses Perfetto to de­bug a launch-block­ing stut­ter, or Chrome uses it to fix a mem­ory leak, our im­pact is im­plic­itly tied to their suc­cess.

* Ubiquity: Capturing a sig­nif­i­cant per­cent­age of the en­gi­neer­ing pop­u­la­tion proves you’ve cre­ated a tech­ni­cal “lingua franca”. This be­comes es­pe­cially ob­vi­ous when you see dis­con­nected parts of the com­pany col­lab­o­rat­ing with each other, us­ing shared Perfetto traces as a “reference every­one un­der­stands”.

* Scale: Ingesting petabytes of data or pro­cess­ing bil­lions of traces proves ar­chi­tec­tural re­silience bet­ter than any de­sign doc.

When you com­bine Criticality (VIP teams need this) with Utility (bugs are be­ing fixed), you cre­ate a pro­mo­tion case that is im­mune to ex­ec­u­tive re­or­ga­ni­za­tions.

I am far from the first to no­tice the idea of “there are mul­ti­ple ways to be a staff soft­ware en­gi­neer”. In his book Staff Engineer, Will Larson cat­e­go­rizes Staff-plus en­gi­neers into four dis­tinct ar­che­types.

Sean de­scribes the Solver or the Right Hand: en­gi­neers who act as agents of ex­ec­u­tive will, drop­ping into fires and mov­ing on once the prob­lem is sta­bi­lized. I am de­scrib­ing the Architect or the Tech Lead: roles de­fined by long-term own­er­ship of a spe­cific do­main and deep tech­ni­cal con­text.

I can hear the crit­i­cism al­ready: “You just got lucky find­ing your team. Most of us don’t have that lux­ury.”

There are two caveats to all my ad­vice in this post. First, the strat­egy I have em­ployed so far re­quires a com­pany prof­itable enough to sus­tain long-term in­fra­struc­ture. This path gen­er­ally does not ex­ist in star­tups or early growth com­pa­nies; it is op­ti­mized for Big Tech.

Second, luck does play a role in land­ing on a good team. It is very hard to ac­cu­rately eval­u­ate team and com­pany cul­ture from the out­side. But while find­ing the team might have in­volved luck, stay­ing there for al­most a decade was a choice.

And, at least in my ex­pe­ri­ence, my team is not par­tic­u­larly spe­cial: I can name five other teams in Android alone . Sure, they might have a di­rec­tor change here or a VP change there, but the core mis­sion and the en­gi­neer­ing team re­mained sta­ble.

The rea­son these teams seem rare is not that they don’t ex­ist, but that they are of­ten ig­nored. Because they don’t of­fer the rapid, vis­i­ble “wins” of a prod­uct launch nor are they work­ing on the “shiny cool fea­tures”, they at­tract less com­pe­ti­tion. If you are mo­ti­vated by “shipping to bil­lions of users” or see­ing your friends and fam­ily use some­thing you built, you won’t find that sat­is­fac­tion here. That is the price of ad­mis­sion.

But if you want to build long-term sys­tems and are will­ing to trade ex­ter­nal val­i­da­tion for deep tech­ni­cal own­er­ship, you just need to look be­hind the cur­tain.

The tech in­dus­try loves to tell you to move fast. But there is an­other path. It is a path where lever­age comes from depth, pa­tience, and the quiet sat­is­fac­tion of build­ing the foun­da­tion that oth­ers stand on.

You don’t have to chase the spot­light to have a mean­ing­ful, high-im­pact ca­reer at a big com­pany. Sometimes, the most am­bi­tious thing you can do is stay put, dig in, and build some­thing that lasts. To sit with a prob­lem space for years un­til you un­der­stand it well enough to build a Bigtrace.

When you pur­chase through links in our ar­ti­cles, we may earn a small com­mis­sion. This does­n’t af­fect our ed­i­to­r­ial in­de­pen­dence.

RAM is so ex­pen­sive, Samsung won’t even sell it to Samsung

Due to ris­ing prices from the “AI” bub­ble, Samsung Semiconductor re­port­edly re­fused a RAM or­der for new Galaxy phones from Samsung Electronics.

The price of eggs has noth­ing on the price of com­puter mem­ory right now. Thanks to a sup­ply crunch from the “AI” bub­ble, RAM chips are the new gold, with prices on con­sumer PC mem­ory kits bal­loon­ing out of con­trol. In an ob­ject les­son in the ridicu­lous­ness of an eco­nomic bub­ble, Samsung won’t even sell its mem­ory to… Samsung.

Here’s the sit­u­a­tion. Samsung makes every­thing from re­frig­er­a­tors to su­per­mas­sive oil tankers. Getting all that stuff made re­quires an or­ga­ni­za­tion that’s lit­er­ally dozens of af­fil­i­ated com­pa­nies and sub­sidiaries, which don’t nec­es­sar­ily work as closely or har­mo­niously as you might as­sume. For this story, we’re talk­ing about Samsung Electronics, which makes Galaxy phones, tablets, lap­tops, watches, etc., and Samsung Semiconductor Global, which man­u­fac­tures mem­ory and other chips and sup­plies the global mar­ket. That global mar­ket in­cludes both Samsung sub­sidiaries and their com­peti­tors—lap­tops from Samsung, Dell, and Lenovo sit­ting on a Best Buy store shelf might all have Samsung-manufactured mem­ory sit­ting in their RAM slots.

Samsung sub­sidiaries are, nat­u­rally, go­ing to look to Samsung Semiconductor first when they need parts. Such was re­port­edly the case for Samsung Electronics, in search of mem­ory sup­plies for its newest smart­phones as the com­pany ramps up pro­duc­tion for 2026 flag­ship de­signs. But with so much RAM hard­ware go­ing into new “AI” data cen­ters—and those com­pa­nies will­ing to pay top dol­lar for their hard­ware—mem­ory man­u­fac­tur­ers like Samsung, SK Hynix, and Micron are pri­or­i­tiz­ing data cen­ter sup­pli­ers to max­i­mize prof­its.

The end re­sult, ac­cord­ing to a re­port from SE Daily spot­ted by SamMobile, is that Samsung Semiconductor re­jected the orig­i­nal or­der for smart­phone DRAM chips from Samsung Electronics’ Mobile Experience di­vi­sion. The smart­phone man­u­fac­tur­ing arm of the com­pany had hoped to nail down pric­ing and sup­ply for an­other year. But re­ports say that due to “chipflation,” the phone-mak­ing di­vi­sion must rene­go­ti­ate quar­terly, with a long-term sup­ply deal re­jected by its cor­po­rate sib­ling. A short-term deal, with higher prices, was re­port­edly ham­mered out.

Assuming that this in­for­ma­tion is ac­cu­rate—and to be clear, we can’t in­de­pen­dently con­firm it—con­sumers will see prices rise for Samsung phones and other mo­bile hard­ware. But that’s hardly a sur­prise. Finished elec­tron­ics prob­a­bly won’t see the same me­te­oric rise in prices as con­sumer-grade RAM mod­ules, but this ris­ing tide is flood­ing all the boats. Raspberry Pi, which strives to keep its mod-friendly elec­tron­ics as cheap as pos­si­ble, has re­cently had to bring prices up and called out mem­ory costs as the cul­prit. Lenovo, the world’s largest PC man­u­fac­turer, is stock­pil­ing mem­ory sup­plies as a bul­wark against the mar­ket.

But if you’re hop­ing to see prices lower in 2026, don’t hold your breath. According to a fore­cast from mem­ory sup­plier TeamGroup, com­po­nent prices have tripled re­cently, caus­ing fin­ished mod­ules to jump in prices as quickly as 100 per­cent in a month. Absent some kind of dis­as­trous mar­ket col­lapse, prices are ex­pected to con­tinue ris­ing into next year, and sup­ply could re­main con­strained well into 2027 or later.

Michael is a 10-year vet­eran of tech­nol­ogy jour­nal­ism, cov­er­ing every­thing from Apple to ZTE. On PCWorld he’s the res­i­dent key­board nut, al­ways us­ing a new one for a re­view and build­ing a new me­chan­i­cal board or ex­pand­ing his desk­top “battlestation” in his off hours. Michael’s pre­vi­ous by­lines in­clude Android Police, Digital Trends, Wired, Lifehacker, and How-To Geek, and he’s cov­ered events like CES and Mobile World Congress live. Michael lives in Pennsylvania where he’s al­ways look­ing for­ward to his next kayak­ing trip.

AMD’s FSR Redstone tech to get wider roll­out in December

: Parenting and lead­er­ship is sim­i­lar. Teach a man to fish, etc.

I spent a cou­ple of years man­ag­ing a team, and I en­tered that role — like many — with­out know­ing any­thing about how to do it. I tried to fig­ure out how to be a good man­ager, and do­ing so I ended up read­ing a lot about ser­vant lead­er­ship. It never quite sat right with me, though. Servant lead­er­ship seems to me a lot like curl­ing par­ent­ing: the leader/​par­ent an­tic­i­pate prob­lems and sweep the way for their di­rect re­ports/​chil­dren.

To be clear, this prob­a­bly feels very good (initially, any­way) for the di­rect re­ports/​chil­dren. But the ser­vant leader/​curl­ing par­ent quickly be­comes an over­worked sin­gle point of fail­ure, and once they leave there is no­body else who knows how to han­dle the ob­sta­cles the leader moved out of the way for every­one. In the worst cases, they leave be­hind a group of peo­ple who have been com­pletely iso­lated from the rest of the or­gan­i­sa­tion, and has no idea what their pur­pose is and how to fit in with the rest of the world.

I would like to in­vent my own buzz­word: trans­par­ent lead­er­ship. In my book, a good leader

ex­plains val­ues and prin­ci­ples em­braced by the or­gan­i­sa­tion to aid them in

mak­ing aligned de­ci­sions on their own,

cre­ates di­rect links be­tween sup­ply and de­mand (instead of de­lib­er­ately mak­ing

them­selves a mid­dle man),

al­lows their di­rect re­ports ca­reer growth by grad­u­ally tak­ing over lead­er­ship

re­spon­si­bil­i­ties,

The mid­dle man­ager that does­n’t per­form any use­ful work is a fun stereo­type, but I also think it’s a good tar­get to aim for. The dif­fer­ence lies in what to do once one has ren­dered one­self re­dun­dant. A com­mon re­sponse is to in­vent new work, ask for sta­tus re­ports, and add bu­reau­cracy.

A bet­ter re­sponse is to go back to work­ing on tech­ni­cal prob­lems. This keeps the man­ager’s skills fresh and gets them more re­spect from their re­ports. The man­ager should turn into a high-pow­ered spare worker, rather than a pa­per-shuf­fler.