Tailwind CSS and the disappearing case for open source projects

In the world of AI, is there even an incentive for open source anymore?

I’m sure everyone’s heard the news about Tailwind CSS laying off 75% of their engineering team  this week due to the impact AI has had on their business.

This made me think a lot about the implications of AI advancements on the incentive models of open source projects, and how we may see a dramatic shift in how open source projects operate in 2026.

Tailwind CSS & Tailwind Labs

I’ll admit, I’ve rarely used Tailwind; in fact, this blog is the first time I’m using it at all. At first, I never really saw the appeal. To me, it was just another styling tool among the many types of styling systems out there.

The premise of Tailwind CSS is that by providing a set of low-level utility classes directly within your HTML, you can rapidly build custom user interfaces without ever needing to write custom CSS from scratch.

When I talk to other engineers, I find that Tailwind is quite a polarizing topic; they either love it (to the point they exclusively use it in their own projects) or they hate it.

What I found most remarkable about Tailwind and the Tailwind Labs team is that they managed to grow “just another styling system” into one of the most adopted styling systems used by frontend developers. The simplicity of the framework has allowed it to be adopted by some of the largest projects out there, along with a reputation as a “must-have” to get a new project started quickly.

Almost every frontend framework, whether that be Vercel’s Next.js or Tanner Linsley’s Tanstack Start, has documentation and starter kits that include Tailwind CSS out of the box.

The open source incentive model

There are broadly two different aspects to open source incentive models: contributors and dependencies. These models must then be converted into viable business models for ongoing maintenance via stable cash flows.

Contributors

Developers contribute to open source projects to gain more experience, maintain a library to an acceptable standard, or help build something interesting. Regardless of the motives of a developer contributing to these projects, open source projects used by hundreds of thousands of developers require ongoing maintenance by a group of developers to keep the project to a high standard.

As a project sees major adoption, the expectations increase dramatically. All of a sudden, you cannot just accept a completely random contributor’s code. Pull requests take lots of time to review, especially if they do not understand the coding standards and patterns already built into the project. Bug tickets increase dramatically, and someone has to go through them and triage what is critical and what is outright user misuse of the project.

Large open source projects are not just about the developers; they include staff who have to triage bugs, communicate with sponsors, maintain documentation, etc. Most of the time, it’s hard to find volunteers who are willing to sacrifice their personal time to help maintain open source projects. Developers may be able to gain more technical experience, but other roles will often see a lot less gain in their technical experience. Software engineers and software engineering are often an exception to this rule, mainly due to the high salary nature of their jobs (at least in North America).

The most prominent examples of projects that have paid staff to help with operations are MapLibre  and The Linux Foundation . Their respective financial transparency disclosures show how significant expenses are for their paid staff. This is also by no means a generous high salary job either. Entities like The Linux Foundation have large corporate sponsors with revenue in the hundreds of millions, allowing them to pay their staff generously , but that’s an exception to the rule. Most open source projects do not have that kind of backing and have to pay staff significantly less for their contributions.

It takes a lot out of contributors to dedicate time to projects in which they see little to no monetary compensation for their work. Sure, there may be some technical experience gain along the way, but their time is an important factor to the business models of open source projects.

Dependencies

The idea of dependencies is very simple: large corporations, and even other large open source projects, depend on the work of open source projects.

Think about it like being a parent; you have a large dependency chain ahead of you. Your child depends on your care; if you neglect them, the effects of their neglect will propagate to their friends, neighbors, their school, and your community. Now open source is different in that just because you depend on something doesn’t mean you have to take care of it by law, but you do have to maintain them for your own project or business’s bottom line.

Large entities like those described above have had a large incentive to sponsor open source projects because they heavily depend on them. Almost every company in the world, even lemonade stands, directly or indirectly depend on The Linux Foundation to maintain the Linux operating system. Almost every company that requires digital maps depends on the OpenStreetMap Foundation  (even Google, as seen in the Google Maps attributions).

Sometimes, incentives are also found in unexpected places. Think of DeepSeek’s announcement of their open source models , there was a significant incentive for Chinese entities to influence and disrupt  the western AI industry using innovation powered through open source projects.

Because entities depend on open source projects, assisting in the maintenance of these projects aligns heavily with their own incentives: profit.

Incentives and open source business models

How do open source projects effectively convert their incentives into viable business models? There are roughly three successful models that work specifically for open source projects: open core, system integration, and managed services.

Open core

The idea of an open core business model is that the open source aspect of the project contains the “core” features that the library aims to solve. They then provide a “premium” layer on top of the core feature set that enables features for the library that would be useful in a commercial context. One of the most prominent examples of the open core business model is React Flow  where they have the React Flow Pro  layer which provides users with detailed examples and a say in new feature requests.

Read it from their own words:

With your subscription, you are ensuring the sustainable maintenance and development of the React Flow library. This is how we make sure React Flow stays MIT-licensed. In return, you get a high-quality, maintained, updated library, along with benefits like direct support, prioritized feature requests, and access to our Pro Examples.

System integration

The system integration model is the model that deals with the commercialization of technology integrations into client companies’ platforms. This is usually in the form where a company that owns the open source technology actively maintains the project by providing a service of building out the client’s desired solutions for them using their own technology.

A good example of this is Percona’s  open source database. Not only does Percona provide a service of system integration , a whole industry was born from consulting companies offering system integration services, both non-profit like open source projects, and for-profit entities.

Managed services

Managed services, otherwise known as software-as-a-service (SaaS), are probably the most common types of open source business models out there. Entities release the open source software in its entirety, often through MIT or Apache 2.0 licenses, but they build a platform on top of their open source project as a managed service and charge based on subscription tiers or usage.

While I can think of many different examples of this type of business model, the most notable ones, especially nowadays in the startup world, are Database/Auth via Supabase , Next.js via Vercel , and Database via MongoDB .

Read it in their words:

Because Vercel is the owner / maintainer of Next.js, they’re able to natively integrate it into their commercial frontend-as-a-service product in a few interesting ways. Along with some nifty performance optimizations, every function in the “api” folder automatically gets deployed as a serverless function in Vercel, which is at least one way to build an easy backend.

Let MongoDB Atlas take care of the infrastructure operations you need for performance at scale, from always-on security to point-in-time recovery.

There are a couple more examples of open source business models like advertisements, premium communities, and partnerships that I won’t cover here.

Was Tailwind an isolated case?

I thought hard about why exactly this happened to Tailwind. There’s some lengthy discussions about the situation everywhere from HackerNews  to Reddit .

Ultimately, here’s my opinion on why this happened to Tailwind.

No consumer pain points

In the case of Tailwind, you’ll see both contributors and dependencies heavily influencing the incentives of Tailwind. Let’s go back to the premise of Tailwind:

The premise of Tailwind CSS is that by providing a set of low-level utility classes directly within your HTML, you can rapidly build custom user interfaces without ever needing to write custom CSS from scratch.

The interesting thing about Tailwind is that they solved this problem too well for those that have adopted the framework; there are no pain points. Let me expand: there are no pain points big enough that this affects the dependency chain significantly.

Styling is not an inherently difficult problem; systemizing styling standards, however, is very difficult to get right. Not only did they solve this problem well for adopters of the framework, most of the issues are easily understood and can be solved with other workarounds.

Every engineer has heard the quote “if it works, leave it alone.” Large entities who depend on Tailwind would rather work around the problem or leave the problems alone altogether rather than work with the maintainers of the project.

Some companies intentionally place a paywall on crucial aspects of a project’s functionality to guarantee a revenue stream for profits or ongoing maintenance, sometimes retroactively placing a paywall on originally open source features. For some entities, this is their only option, artificially creating a “consumer pain point” to ensure consistent revenues.

Poorly designed business model

So Tailwind had it all: a large collection of dependents on the framework, high user satisfaction, and a well-solved problem. How exactly did they fail to generate revenue? Tailwind used a version (not really) of the open core business model by creating Tailwind Plus , a library of UI Blocks, Templates, and a UI Kit at a premium for developers to get started even faster.

The reason I say Tailwind used a version of the open core model is because it’s not exactly an open core model. An open core model is a business model that gates specific functionality that would be useful in a commercial context. Tailwind Plus does not gate any functionality; it’s a new product that is built on top of the open source project.

The problem here is simple: there was simply no demand, or an insignificant value proposition for this product. Not only does the open source library solve the problem too well, every company’s design system is too specialized for a general product like Tailwind Plus to generate meaningful value.

Tailwind Plus is like Home Depot giving out lumber, screws, and insulation for free while attempting to sell you blueprints to a single type of house in the name of efficiency. The building standards around building a home have been established for decades and yet every house is built differently. In Home Depot’s hypothetical business plan, they’re not wrong; buying blueprints, especially if it’s a proven design, is in fact efficient. But that doesn’t mean everyone wants their home to be built that way.

Sure, Tailwind does also accept individual and corporate sponsorships , but a brief estimation of their monthly revenue from sponsorships alone is barely enough for 4 - 5 developers at an average salary per month. And that’s excluding other expenses that go into the maintenance of a large open source project like Tailwind CSS.

Now the official statement from Tailwind is that they had four engineers and they cut 75%. TLDR: they cut three engineers. With the previous figures, we can assume their payroll for engineers was around ~$40,000/month. This means that they used to be generating at least ~$40,000 from Tailwind Plus, which supposedly shrunk significantly due to AI.

While I don’t disagree that AI had a strong impact on their monthly revenues— enough that they needed to lay off three of their four engineers—I think their flaw was that they had a product and open source business model that generated little to no value to begin with.

Where does AI fit into the problem of open source?

Tailwind and AI

So Tailwind claims that increased AI traffic plummeted their revenues. How did AI exactly impact Tailwind Plus? Well, AI completely eliminated the need for Tailwind Plus altogether. Why buy a UI template package when you can just generate one with AI? Seriously, it’s probably faster to generate a whole UI kit using AI with Tailwind than to go through the payment portal and enter your credit card information.

Tailwind’s styling system is so thoroughly documented that AI can retrieve all the information it needs just by crawling their documentation , which it then uses to build out a custom design system. Most models already default to Tailwind styling if you do not specify a styling framework to use for your pages or design system. You can test it out yourself.

Some AI consultants recommend that you exclusively use Tailwind for your AI-generated websites .

I would not be surprised if Tailwind Plus has made its way into the training of AI models already. I say this because there are those who use AI code generation and analysis tools along with Tailwind Plus in their existing applications. Most may be unknowingly (or negligently) using indefinite or long-term data-retentive models which have absorbed Tailwind Plus during code analysis and feedback cycles which is then distributed to millions implicitly.

The open source dilemma

This presents an interesting dilemma. If you build out an open source tool or library that solves a problem many people experience, that can be downloaded by anyone, and you provide all the examples AI needs to succeed at its own implementation, your troubleshooting threads are all publicly accessible for crawlers, and the changelogs are all published after regular maintenance; it’s hard to come up with a viable revenue stream to begin with.

The technology is free, distribution is free, maintenance is free, the instruction manuals are free, and support is free.

Most open source projects have at least one aspect of the product lifecycle behind a paywall. Tailwind (and many other projects just like it) have no paywalls in any part of their product lifecycle. Even if there are projects that have even just one, depending on the nature of the project, there could be no value proposition behind the product or service being paywalled if AI can work around it instead.

Open source protections against AI

There really aren’t any protections for open source projects and AI at the moment. The most widely used licenses, MIT and Apache 2.0, generally do not restrict who can use the code for what purpose, including AI training. There are some frameworks that aim to allow AI agents to understand your project better , but there are no explicit provisions to prevent unauthorized access to the original work.

Copyleft licenses do exist but it’s hard to enforce the origins of AI-generated code since AI model and model training is usually a giant black box, making it hard to detect and enforce instances of copyleft infringement.

It’s hard to say if something was even an instance of copyleft infringement in the first place. If AI uses your open source project as a basis for recreating something new, but it doesn’t directly modify the existing open source implementation, could you say that is really copyleft infringement?

What will happen to open source in 2026

The open source promise

We’ve now seen how even one of the most loved and widely adopted open source projects can succumb to the effects of AI adoption and how AI affects open source projects out there. While Tailwind in particular may have been more than just an AI problem, all open source projects are being impacted by AI in different ways.

Smart engineers producing open source software is what effectively built the digital world we now have today. The promise of open source lies in our ability to produce reliable, flexible, and high-quality software. With that promise also comes an implicit contract that individual and corporate sponsors who enjoy and profit off of open source software will “give back” to the open source community.

With AI, not only has adoption of open source software grown exponentially, the expectations on the quality of those projects have also been raised. Most importantly, we’ve added a middleman (or middlerobot?) that obscures who the real consumers of our projects are. Without knowing who profits off of our work, it’s hard to enforce the social contract of “giving back” in the first place.

Looking forward

2026 will be an interesting year for open source projects.

At the end of 2025, we saw the acquisition of Bun by Anthropic , which marked a pivotal moment in the open source community. Bun has never generated revenue , and yet they were acquired because Bun is the core technology that enables one of Anthropic’s core business lines: Claude Code. Bun is also a popular runtime for running MCP servers, another technology created by Anthropic.

As AI companies continue to consume and adopt open source projects for the betterment and profit of their business lines, open source projects with poor protections against AI (like Tailwind) will continue to see a downward trend in revenue. Dare I say, they may collapse entirely.

If these trends continue, I would not be surprised to see beaten-down, but highly adopted open source projects that are useful for AI adoption continue to be acquired by large companies in the AI space, while projects that fail to be useful for AI development but see massive adoption through AI get left behind.

At our current pace, I doubt there will be strong protections in place for open source projects before they are all consumed for AI training and development. However, I do think we will have fair AI usage frameworks developed by established open source foundations that ensure AI companies track the usage of open source projects for the development and training of AI as well as in responses such that they can give back to the open source community accordingly, similar to revenue share agreements between media publishers and AI providers.

Tags

Related posts