Tailwind Laid Off 3 of 4 Engineers at Peak Usage

Record Downloads, 80% of Revenue Gone

There’s a piece of news that quietly slipped by this past January.

The company behind the CSS framework Tailwind laid off 3 of its 4 engineers. Around the same time, Tailwind’s monthly downloads hit 75 million, and according to the 2025 State of CSS¹ survey, its developer adoption rate reached 51% — making it the most widely used CSS framework in history. Product usage hit an all-time high, yet the company still cut its engineering team from 4 people to 1.

Here are the numbers founder Adam Wathan shared: traffic to the official docs site down roughly 40% from 2023, and revenue down roughly 80%.

This isn’t a case of a product failing — it’s a case of the revenue pipeline running through that product getting cut off. Tailwind made money by selling paid products to visitors who came through its official documentation, and as that traffic dried up, so did the revenue. And this structure isn’t unique to Tailwind — it runs across the entire open-source supply chain that your company’s products are built on.

🚰 AI Slop Is Clogging the Channel for Outside Contributions

Let’s start with what’s happening on the technical side.

If you’re reading this right now, you just used a piece of software called cURL. Even if you haven’t opened a browser, if you’ve touched a smartphone, laptop, TV, or car today, you’ve used it too. libcurl, cURL’s core component, is estimated to have been installed more than 20 billion times. It’s a component we use every single day without ever thinking about the fact that it’s embedded inside everything.

cURL is an open-source project that first appeared in 1996. It was created by Swedish developer Daniel Stenberg (55), who still maintains it full-time today. The contributor list has grown past 3,000 names, but there’s exactly one full-timer.

“I’ve long been cURL’s only full-time person. Everyone else is a volunteer, and they come and go. I have no idea who’ll still be around tomorrow.” (Daniel Stenberg)

Eric S. Raymond called people like this “load-bearing internet people” — walls that hold up the weight of the building but that nobody ever looks at.

But this January, Stenberg shut down the bug bounty² program he’d run for 6 years. Over those 6 years, the program had paid out $86,000 (~₩120,000,000) and fixed 78 genuine vulnerabilities. There was exactly one reason for shutting it down: an explosion of AI slop³.

Stenberg said that across 6 years, not a single AI-generated submission had ever identified a real vulnerability. Instead, what poured in were plausible-looking fake reports, complete with GDB session logs and register dumps referencing functions that didn’t even exist.

He wrote:

“The endless stream of slop reports takes a serious mental toll to manage, and takes forever to refute. It’s time and energy completely wasted. And it eats away at our will to live.”

That same month, Steve Ruiz, founder of the digital whiteboard tool tldraw, started automatically closing pull requests⁴ from outside contributors. He’s not against writing code with AI — he uses it himself and recommends it to his team. The problem lay elsewhere.

“If writing the code is the easy part, why would I want someone else to write it for me?” (Steve Ruiz)

AI-generated contributions are formally correct but miss context, misread the codebase, and above all, their authors don’t show up for the follow-up conversation. In the old days, a new contributor would learn the project over time and eventually become a trusted maintainer. Now all it takes is pointing a tool at the project, so there’s no reason for the person submitting the contribution to ever actually learn it.

Review costs have stayed the same while the cost of producing a contribution has collapsed to zero. A paper published this past March labeled this phenomenon a “tragedy of the commons”: the productivity gains of the individual get passed on as costs to reviewers, maintainers, and the community as a whole.

💰 The Money Trail Got Cut Off

Now let’s turn to the economics. This brings us back to Tailwind.

Tailwind’s business model worked like a loop. A developer searches “how to center a div” → lands on the official docs → sees an ad for a paid product (Tailwind UI) next to the docs → buys it. Documentation traffic was the sales funnel.

LLMs have eliminated the “lands on the official docs” step from this flow. Developers no longer come to the docs — they ask Claude or ChatGPT instead. The irony is that those models can answer only because they were trained on Tailwind’s documentation and community discussions.

Product usage is at an all-time high, yet revenue has dropped to a fifth of what it was. That single number captures what’s happening in the open-source ecosystem right now.

In January this year, a research team led by economist Miklós Koren at Central European University (CEU) published a paper titled “Vibe Coding Kills Open Source.”⁵ It applies international trade models to open source, and its conclusion is unambiguous.

Running experiments across six coding models, the team found that packages frequently recommended by models see downloads surge, but that activity never converts into the kind of engagement that sustains maintainers. Bots install packages, but they don’t file issues, don’t read documentation, and don’t say thanks.

The paper’s conclusion: “Under traditional business models where developer revenue depends entirely on direct user engagement, the open-source ecosystem cannot survive broad AI adoption.”

As Koren put it:

“For a developer, the question becomes: if I want to build a following among people, why would I build something only machines use?”

The same pattern shows up on Stack Overflow. Just before ChatGPT launched, the site was getting over 100,000 questions a month; now it’s under 1,500. The answer rate has fallen from 80% to roughly half that. The public archive of questions and answers that anyone could search has been shrinking, and in its place, private conversation logs stored inside big tech companies have taken over.

🔑 What kept open source running wasn’t just code — it was attention and reputation

We’ve always understood open source as “giving away code for free.” But in practice, it was a structure where you gave away code and got something back — just not money.

• Surface level — Out: code / In: (nothing, free)
• Actual level — Out: code / In: attention, reputation, issue reports, documentation traffic, career capital

What actually drove open source was the second line. Labor that looked unpaid was in fact being compensated with attention and reputation instead of money. A contribution history became a line on a résumé, documentation visitors were potential customers for a paid product, and a high GitHub star count helped you land your next job.

AI coding tools produce the code itself, but they don’t pass along the attention that used to flow to maintainers. Instead, they redirect that attention toward themselves. The attention users once gave maintainers now shows up as a $100–200 monthly subscription fee, paid to the Silicon Valley company that built the tool.

Rich Harris (creator of Svelte) put his finger on exactly this.

“Until very recently, the idea that you’d effectively pay rent to a Silicon Valley company for the privilege of using software would have seemed completely absurd.”

An artist named Mierle Laderman Ukeles wrote the “Manifesto for Maintenance Art” in 1969. She pointed out that maintenance labor is always devalued relative to creative labor — that society assigns maintainers “the pathetic status.” And she asked:

“After the revolution, who’s going to pick up the garbage on Monday morning?”

That question is 57 years old, and it’s playing out verbatim on GitHub issue trackers today. Generative AI was designed and marketed as a tool for creation. Have you, dear reader, ever seen an AI product advertised as “a breakthrough in maintenance”? I haven’t. Maintenance is work with no shortcuts.

So What Happens to Our Product

One of FT’s apps depends on more than 2,000 open-source packages. Your company’s product probably isn’t much different. A large chunk of those 2,000 packages hangs on a single maintainer, and that one person is now growing weary of slop reports.

A famous xkcd comic drew this exact structure: a massive tower of blocks labeled “all modern digital infrastructure,” resting on one thin block held up by “some random person in Nebraska who has been thanklessly maintaining it since 2003.”

While putting together GTM strategies, I’ve opened plenty of technical due-diligence files, and the dependency lists in them usually just checked whether “the license is clean” and moved on. I did the same. Who’s maintaining this, and whether that person is burning out was never on the checklist. Looking back now, that was the biggest hole in the whole process.

Here are three things worth checking right away.

• Check the bus factor⁶: Among your product’s core dependencies, how many packages had more than 80% of their commits over the last 12 months come from a single person? You can check this in GitHub Insights in 30 minutes.
• Check who you’re actually funding: Of those packages, how many are you actually paying for? For most companies, the answer is zero. Sending even a few tens of dollars a month through GitHub Sponsors or Open Collective changes the odds of a maintainer walking away.
• Fix your contribution policy: Are your engineers throwing AI-generated PRs at outside open-source projects? The moment your company’s name gets attached to the side producing slop, it costs you on recruiting and employer branding too.

Oswarld’s Lens

Honestly, I’m wary of this whole issue getting reduced to “AI is bad.”

Even Stenberg himself isn’t against AI tools as such. He publicly praised a developer who used AI-assisted tools to surface a large batch of genuine, real issues. Here’s the core of what he said:

“Writing the first version of some code has in general never been a problem in any project. The challenge in a project is to maintain it over time, to fix the bugs. [AI] is not that good at fixing problems. It’s much better at finding them.”

Looking at this structure, what strikes me is that this isn’t a technology problem — it’s a settlement-structure problem.

Nearly 20 years of building go-to-market strategy has shown me one recurring pattern: what actually collapses in a market isn’t the product — it’s a business model where the point where value gets created and the point where money gets collected have drifted apart. Tailwind created value in code but collected money from documentation traffic. AI simply cut the search-inflow channel connecting the two. The real problem was that, from the start, that single documentation visit was the only channel linking them.

So I don’t see it as “open source is dying” so much as “open source’s settlement model is being forcibly redesigned.” And the cost of that redesign ultimately gets split among every company that sells software — that is, us. Right now, maintainers are absorbing that cost personally, out of their own time and stamina. If they can’t hold on any longer, there will be no one left to fix the bugs in the packages we use every single day.

Something Karen Sandler (Software Freedom Conservancy) said has stayed with me. She said these tools have the potential to let “anyone fix the software they depend on, themselves.” I believe in that possibility too. But it won’t arrive on its own — it’s a future that’s only possible if the people who know how to fix things are still around to do it.

Closing

Here’s the summary.

• The channel for outside contributions has closed. cURL shut down its bug bounty program, and tldraw closed off external contributions. Maintainers are personally absorbing the cost of reviewing AI slop.
• The revenue pipeline has dried up. Tailwind gets 75 million downloads a month, yet its revenue has dropped roughly 80%. What maintainers used to get paid in wasn’t money so much as attention — documentation visits, issue reports — and that attention has migrated to AI tools.
• The cost comes back to us. The maintainers of the thousands of packages our products depend on are burning out and leaving, one by one. I’d suggest checking just two things today: bus factor and whether the project is being sponsored.

Building is harder than destroying, and maintaining is harder than building. We usually don’t notice maintenance until something breaks — and we only realize a maintainer was there after they’re gone.

💬 Is there an open-source package your company’s product depends on that effectively has just one maintainer? Or, on the flip side, if you’ve ever submitted an AI-generated PR to an external project, I’d love to hear how it was received. Drop a comment — it might become material for the next issue.

---

💬 Share your experience with the question above in the comments · 📨 If you have a colleague wrestling with dependency management, send them this piece

---

References & Further Reading

Primary sources

• Koren, M., Békés, G., & Hinz, J., “Vibe Coding Kills Open Source”, arXiv:2601.15494, January 2026. : This is the economic backbone of this piece. What’s especially interesting is applying an international trade model to open source. If you’re short on time, the conclusion alone is worth reading.
• Daniel Stenberg, “The end of the curl bug-bounty program”, January 2026. : This is the maintainer’s own voice. The exhaustion in the sentences says more than any number could.
• Steve Ruiz, “Stay away from my trash!”, tldraw blog, January 17, 2026. : The question “if writing code is the easy part, why would you want someone else to do it for you?” is the starting point for this entire piece.
• DevClass, “Tailwind Labs lays off 75 percent of its engineers thanks to ‘brutal impact’ of AI”, January 8, 2026. : This is the most concrete case of the open source revenue model collapsing.

Background

• Mierle Laderman Ukeles, “Manifesto for Maintenance Art 1969!”, 1969. : A classic text on the devaluation of maintenance labor. It’s not about software, but it reads like it is.
• xkcd, “Dependency”, xkcd #2347. : This single cartoon summarizes everything in this piece.

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.

📝 Glossary

Footnotes

1. State of CSS: An annual survey of web developers worldwide on their use of CSS tools. It’s used industry-wide as the de facto standard metric for adoption rates. ↩

2. Bug bounty: A program in which outside developers are rewarded for finding and reporting security vulnerabilities in software. It exists to catch flaws that internal teams alone can’t find, but because there’s a cash reward attached, it also draws a flood of low-quality, opportunistic reports. ↩

3. AI slop: Content mass-produced by AI that looks plausible but has no real substance. In the coding world, it refers to bug reports or code suggestions that are “formally perfect but contextually wrong.” ↩

4. Pull request (PR): The process of submitting a proposal to an open source project saying “please make this change to the code.” It only gets merged into the actual codebase after a trusted maintainer reviews and approves it. The core of the problem right now is that proposing takes seconds, while reviewing takes hours. ↩

5. Vibe coding: A development approach where, instead of reading and writing code directly, you give instructions in natural language and use whatever the AI produces as-is. It’s fast, but if you lack the ability to verify the output, you’re helpless once something goes wrong. ↩

6. Bus factor: A metric measuring “how many people would have to get hit by a bus before this project grinds to a halt.” A bus factor of 1 means the entire project hinges on a single person. ↩