$ cat ~/posts/tailwind-and-open-source-in-the-llm-era-when-documentation-no-longer-monetizes.txt
Opening file...

Over the past few days, a discussion around Tailwind has brought a fundamental question back to the table:

how do you fund an open source project?

Okay, the question isn’t new, and you might be wondering what it has to do with the GitHub discussion above.

Let’s talk about it.

The request was simple: add an llms.txt file, so the documentation could be more easily consumed by LLMs.

The response was just as simple: no, for economic reasons.

But what’s the connection between the two?

Less traffic = less money

The reasoning is actually very simple, and it was explained by Adam Wathan (creator of Tailwind):

$ echo
>

Traffic to our docs is down about 40% from early 2023 despite Tailwind being more popular than ever. The docs are the only way people find out about our commercial products, and without customers we can't afford to maintain the framework.

Today, documentation is the main marketing channel for Tailwind’s commercial products (sponsorships, Tailwind Plus, etc.).

Yet since 2023, traffic to the docs has dropped significantly, even though Tailwind has never been more popular.

So the equation is simple:

  • less traffic
  • fewer conversions
  • nearly 80% less revenue
  • and very concretely, 75% of the team laid off

In this context, making documentation easier for LLMs to consume means accelerating the loss of the only real revenue source.

From a purely economic standpoint, the decision makes sense.

It’s not anti-AI — it’s simply an economic reality, as Adam points out:

$ echo
>

Right now there's just no correlation between making Tailwind easier to use and making development of the framework more sustainable. I need to fix that before making Tailwind easier to use benefits anyone, because if I can't fix that this project is going to become unmaintained abandonware when there is no one left employed to work on it. I appreciate the sentiment and agree in spirit, it's just more complicated than that in reality right now.

Slowing down LLM integration: solution or defensive strategy?

The real question isn’t “is it justified?”, but rather:

$ echo
>

Is it viable in the medium term?

In my opinion, probably not. Usage has changed: developers no longer systematically read docs. They ask ChatGPT, Copilot, Cursor, or Claude.

Documentation is consumed indirectly.

Denying this reality comes with several risks:

  • approximate implementations generated by LLMs
  • more “AI-native” competitors being favored
  • a gradual loss of relevance, despite apparent adoption

In other words, protecting traffic today may cost relevance tomorrow.

A problem larger than Tailwind

This debate goes far beyond Tailwind.

I use Nuxt a lot, I really like this framework, and it seems to me that they faced similar issues with Nuxt UI or Nuxt Studio.

I’m using Nuxt as an example, but the problem is clearly general.

Since the acquisition by Vercel, these projects eventually became fully open source, and something tells me that adoption of Nuxt UI has exploded.

In fact — and especially with AI — the traditional build vs buy dilemma is being completely reshaped. It’s easier to prototype quickly, so the perceived value of tools goes down, and monetization becomes more difficult.

I’m not saying that Nuxt, Tailwind Plus, or Nuxt UI are easily reproducible with AI. There is also the vision of their creators, which makes these tools unique. And it’s precisely because they are open source that feedback loops are stronger and these tools keep improving.

But many developers might be tempted not to buy the paid layer of an open source project, under the assumption that it’s now much more accessible to build something themselves.

In short, selling add-ons on top of open source projects is hard — and that’s not exactly breaking news, we already knew that.

In this context, Nuxt’s acquisition by Vercel can be seen as a way to get some breathing room and secure development. But it’s also an externalization of the problem, with an obvious cost: loss of control and a risk of under-investment in the long term.

It’s not a structural solution. It’s a compromise.

Coming back to the main topic, one hypothesis is becoming increasingly clear:

documentation will no longer be a human marketing channel.

It will be read by machines, summarized, transformed, and injected into prompts.

Refusing this evolution is a risk in itself.

But accepting it without an economic model is another.

What possible paths forward?

I’ve been thinking about it, and I see several interesting directions.

The question is no longer how do we bring developers to the website?, but rather how do we show up where they actually code?

Let’s start with one option — the one that appeals to me the least:

Docs consumable via API with a paywall

We could imagine exposing llms.txt through a paid or semi-paid API:

  • with rate limiting
  • potentially restricted to customers or sponsors

It’s technically feasible, but I can’t really imagine developers paying a subscription for every existing llms.txt file.

Now, a second direction seems more interesting to me: what if we moved marketing closer to users?

EDIT: Someone just pointed out to me the existence of a new protocol currently being tested by Cloudflare in beta: pay-per-crawl.

On paper, this could be interesting. The idea is to trigger an exchange between the crawler and Cloudflare in order to charge an AI a fee for crawling a given page.

If this were to become a standard, and if the per-request cost were very low (for example, $0.00001 per call), and **if **AI agents were able to integrate this into their own pricing models for end users, then this could potentially work and provide a new source of funding for open source projects.

That’s a lot of “ifs”, but why not.

Official MCP / AI server

Imagine Tailwind offering its official MCP resource, but with instructions for AI agents to mention paid products at the right moment.

This could take the form of a banner displayed occasionally in the console to encourage visiting the site or to highlight paid products.

It could also warn users when they’re reimplementing something that already exists in the paid offering, for example in Tailwind Plus.

The idea isn’t to create intrusive ads, but to show the right message, at the right time.

EDIT : Alternatively, you can create a paid MCP server that is very useful for use with your product. That’s the approach of DaisyUI. This MCP server includes various tools that go beyond simply knowing the documentation, with best practices, migration tools, and templates.

Conclusion

I believe the real shift to make is this: stop looking for monetization only in the browser, and instead in the tools developers actually work in.

Today, that’s the prompt.

And something tells me this problem is also generalizable to search engines, which are increasingly being bypassed as well — but that’s another story. What’s certain is that I wouldn’t be surprised to see product placement inside LLMs in the future.

In short, the problem isn’t AI. The problem is that the open source economic model was built for a world that no longer exists — and if usage has moved from the browser to the prompt, monetization will have to follow.

$ exit

0 Comments

No comments yet. Be the first to comment!