AI Killed One Open Source Business Model, Not Open Source

January 12, 2026 By Adam Poulemanos 11 min read

DANGER: THE SKY IS FALLING… or is it?

This week’s developer chatter was dominated by Tailwind’s struggles. Revenue down 80%, layoffs, and a CEO publicly questioning whether their open source business model can survive in the AI era. All while it gets 75M monthly downloads.

If you don’t know: Tailwind CSS is one of the most popular open source projects in the world. Their utility-first CSS framework has revolutionized web development, and their documentation site is a go-to resource for developers everywhere. Their business model has long been based on providing premium content, tools, and services around their open source project.

The panic spread quickly: “AI killed open source!” “The OSS dream is dead!”

As someone building an open source company right now, this hit close to home.

Tailwind is one company. I needed to know:

Is this an isolated incident, or a sign of a broader trend?

I spent the weekend looking at the data. Here’s what I found: AI killed one specific business model. Meanwhile, other open source companies are printing money at a pace we’ve never seen before.

Open Source Winners Are Winning Big

While Tailwind struggled, here’s what happened to other open source companies over the past 12-18 months:

Databricks raised $10 billion at a $62 billion valuation in December 2024, then another $4 billion at $134 billion in December 2025. Revenue hit $4.8 billion with 55% year-over-year growth.
Vercel (the company behind Next.js) reached a $9.3 billion valuation with 82% ARR growth. Their AI development agent v0 attracted 3.5 million users.
Supabase achieved a $2 billion valuation with revenue exploding from $20 million to $70 million—that’s 250% growth.
Temporal hit $2.5 billion valuation with 4.4x revenue growth in 18 months.
Hugging Face maintained its $4.5 billion valuation with revenue growing from $70 million to $130 million.
HashiCorp sold to IBM for $6.4 billion.
PostHog just hit unicorn status at ~$1.2 billion valuation. These aren’t small wins. These are record-breaking valuations happening RIGHT NOW, during the supposed “death of open source.”

What Changed?

Tailwind’s struggles reflect two key issues that AI has introduced for open source projects: business model disruption and contribution quality.

The difference isn’t that Tailwind makes bad software. It’s that AI fundamentally changed how people consume documentation-heavy products.

Tailwind’s Model vs. AI

The Tailwind model:

Create amazing documentation → People visit your website → Convert some percentage to paid customers (UI Kit, Catalyst, Refactoring UI). The content itself drives the business.

The problem: AI doesn’t visit websites and doesn’t click buy. It caches documentation, extracts what it needs, and generates code without ever hitting your servers. The traffic disappears. The conversion funnel breaks.

The Winners’ Models

The companies thriving? They’re selling cloud services and enterprise contracts.

Databricks sells data processing. Vercel sells deployment infrastructure.
Supabase sells hosted Postgres.
Temporal sells workflow orchestration.
Hugging Face sells model hosting and inference.
HashiCorp sells enterprise versions of infrastructure tools for secrets management, networking, and infrastructure as code (Terraform).

These are services AI can’t cache away. When a developer needs to deploy something or process actual data, they have to connect to the real service.

If your business model was “great documentation drives traffic drives sales,” AI just killed your funnel. If your business model is “use our OSS locally, pay us to run it in production,” you’re probably having your best year ever.

The Other Problem: Contribution Quality

But there’s a second issue that’s less talked about:

AI is flooding popular open source projects with low-quality contributions, and it’s forcing maintainers to rethink what “open source” even means.

Yesterday, I checked Github’s Spec-kit repo because I was using it to guide a major architecture decision for Thread. If you’re not familiar with Spec-Kit, it’s dead simple: a collection of markdown files and a few shell scripts to guide AI assistants through a structured spec-writing process. It is simple but effective, and popular — it currently has ~62,000 stars on GitHub.

One thing caught my eye: 507 open issues. For markdown files.

To be exact: 507 issues for a repo consisting of 14 markdown files, 1 python typer cli file for installation, 5 bash scripts and 5 equivalent powershell scripts.

I dove in. Here’s what I found:

Most issues are low/no-effort contributions or feature requests (only 10% are labeled ‘bug’, and most of those are symptoms of AI behavior and scaffolding, not actual bugs, like: “gemini used gemini.md and not constitution.md”).
The overlwhelming majority aren’t issues at all. It has devolved into a discussion forum for people asking simple questions about how to use the tool, or requesting new features. The questions are often covered in the docs already or easily answered with a quick Google search.
One third of the Contributing guidelines are dedicated to reducing low-quality AI generated contributions.
There are 73 open pull requests. Those are OK; nearly all are for adding support for a new model or AI client. But the maintainers have to sift through all of them to find the few that are actually useful. (You can usually ‘add support’ for a new client or model by simply copying and pasting the files into the client’s directory. No real code changes needed.)

The Grinch said it best: “Noise. Noise. Noise. Noise. Noise.”

At least for Spec-Kit, the problem isn’t truly low quality AI contributions, it’s vibe coders ¹. A flood from people unfamiliar with repository norms and best practices, don’t take the time to learn them, and can’t be bothered to read the docs themselves.

Many projects do report a flood of low-quality AI-generated PRs and issues. The maintainers are overwhelmed, and it’s forcing them to rethink how they manage contributions.

We Already Have Good Examples for Managing Contributions

There are many open source projects that don’t rely on mass contributions to thrive. If you treat contributions as a bonus, and only if they meet your standards, you can maintain quality without drowning in noise. Oddly enough, you can also use AI to triage contributions.

Some examples of projects known for restrictions on contributions:

Django has a clear process for contributions, including a requirement to sign a Contributor License Agreement (CLA).
Caddy sets a high bar for contributions without being exclusionary.
Commercially-oriented open projects like Posthog, Plausible Analytics, and others have clear contribution guidelines, often requiring agreeing to a CLA, and sometimes limiting contributions to certain types of changes. The overall theme is: “contributions are welcome if they meet our standards and align with our goals.”

The message is shifting from “you build it, they come, everyone wins” to “build in public, keep it open for good players, protect yourself and your time.”

The Licensing Question - The Calculus Has Changed

This brings me to something I’m personally wrestling with right now.

I’m building Knitli, which includes two main products: CodeWeaver (a semantic search tool currently in open alpha) and Thread (a pre-release real-time codebase intelligence platform). Thread is licensed under AGPL-3.0 with commercial licensing available. CodeWeaver is currently MIT OR Apache-2.0.

I’m about 90% decided to move CodeWeaver to AGPL-3.0

MIT and Apache-2.0 were the default choices for open source projects for a long time. They’re permissive, developer-friendly, and have wide community acceptance. Many developers won’t even use a project unless it’s under one of these licenses.:

MIT and Apache-2.0 are still great for side projects, prototypes, and learning tools, and for large established players like Microsoft, Facebook, and Google who can monetize in other ways.
The MIT/Apache-2.0 business model is broken for new open source companies trying to build sustainable businesses in the AI era.
The old premise: get mass adoption with permissive licenses, then monetize later, no longer holds.
What happens now is: AI companies train on your permissively licensed code, large players fork and wrap your work, and you have limited options to build a business around what you created.
Anyone marketing for developers was more-or-less forced to go permissive to get adoption. Now, with AI changing the game, it’s a strategic choice, and developer attitudes are shifting, too.

The new normal is more complex. Here are some trends I’m seeing:

Big growth in major projects with commercial intent choosing AGPL-3.0. Examples include Firecrawl, MinerU, Daytona, WrenAI, and Pydantic AI Gateway
Projects with many stars with substantial or all of their code under “fair use” (not open source) licenses, such as n8n and OpenHands
Growing use of commons clause additions to licenses, which restrict commercial use and is not considered open source by OSI, including: dokploy, ReactBits, claude-task-master, and GenAI_Agents
More projects with fully proprietary code in public repositories — usually alongside open source code — including n8n, PostHog, and others. Visible for transparency and trust, but not open source or freely usable.

I expect these trends to accelerate and we will see more open code, closed source projects in the near future.

I haven’t seen a fully proprietary major public repo yet, but I expect that to change soon.

What This Means for Maintainers

If you’re maintaining an open source project as a business or part of a business model, the rules have changed.

Re-evaluate your licensing strategy. The permissive licenses that once drove adoption may no longer protect your business in an AI-driven world. Consider licenses like AGPL-3.0 or fair use licenses that align with your business goals. Don’t let philosophy override practicality (the good new: developers seem to increasingly understand this.).
Tighten contribution guidelines. You want to make low effort, low quality contributions difficult. Set clear standards, require steps like CLA signing, and be prepared to reject contributions that don’t meet your criteria.
Focus on building services, not just code. If your business model relies on documentation-driven traffic, it’s time to pivot. Consider how you can offer hosted services, enterprise features, or other value that AI can’t easily replicate.
Transparency still matters. Even if you move to more restrictive licenses or proprietary code, keeping your repository public builds trust with your users and community.

What I’m Doing About It

I’m currently completing a major refactor of CodeWeaver, which will be released as Alpha 6. I may decide to change its license to AGPL-3.0 at that time. My considerations in addition to those above:

CodeWeaver is a developer tool. Most developers can pick it up and use it, or modify it for their own use, without needing to contribute back. AGPL-3.0 doesn’t block that.
The main risk is AI companies using CodeWeaver as a feature in their own products (i.e. “new to Claude Code: powerful search!”) without contributing back. AGPL-3.0 severely limits that risk.
Like most innovations, CodeWeaver and Thread are incremental improvements on existing ideas. AGPL-3.0 protects against large players taking the core ideas and building proprietary versions without contributing back.
AGPL-3.0 is still very much open source, and actually makes it difficult for it to ever not be open source. It requires anyone who modifies and hosts the software to share their changes, keeping the ecosystem healthy.

The decision is harder for CodeWeaver than for Thread. Thread is an infrastructure-level product. It always needed a strong copyleft license to protect its business model. It signals that this is a serious business tool while keeping it open for developers who want to understand how it works and build on it for fun.

I’m still figuring this out. But watching the Tailwind situation unfold while simultaneously watching Databricks raise $14 billion has clarified something: Open source isn’t dying. One business model is dying. The companies that adapt are thriving.

I’m Adam, founder of Knitli. I’m building AI-first context curation tools and figuring out open source business models in real time. If you’re wrestling with similar questions, I’d love to hear from you. You can reach me on Bluesky or Twitter or LinkedIn.

I’m not calling out all vibe coders. Many do read the docs and contribute meaningfully. But a significant portion don’t, and more importantly, there are a lot of them now, and they’re drowning out the signal. (And definitions for vibe coders vary. I’m using it here to mean people who could not produce meaningful contributions without AI assistance. I heavily use AI myself, but I make sure I understand the code and context first.) ↩

Meet the Author

Adam Poulemanos

Founder & CEO

Building better developer tools at Knitli. Former intelligence leader turned technologist with a passion for AI context management and making software development more humane.