The developer world panicked this week when Tailwind CSS—one of the most popular open source projects with 75M monthly downloads—announced an 80% revenue drop and questioned whether their business model can survive the AI era.
As someone building an open source company right now (Knitli), this hit close to home. I needed to know: is this the beginning of the end for open source, or something else entirely?
I spent the weekend digging into the data. Here's what I found: AI killed one specific business model. Meanwhile, other open source companies are having their best years ever.
The Winners Are Winning BIG
While Tailwind struggled, here's what happened to other open source companies over the past 12-18 months:
- Databricks: Raised $10B at $62B valuation in Dec 2024, then another $4B at $134B in Dec 2025. Revenue hit $4.8B with 55% YoY growth.
- Vercel (Next.js): Reached $9.3B valuation with 82% ARR growth. Their AI tool v0 attracted 3.5M users.
- Supabase: Hit $2B valuation with revenue exploding from $20M to $70M—that's 250% growth.
- Temporal: $2.5B valuation with 4.4x revenue growth in 18 months.
- Hugging Face: Maintained $4.5B valuation, revenue grew from $70M to $130M.
- HashiCorp: Sold to IBM for $6.4B.
- PostHog: Just hit unicorn status at ~$1.2B valuation.
These aren't small wins. These are record-breaking valuations happening RIGHT NOW, during the supposed "death of open source."
What Actually Changed?
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, etc.)
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 thriving companies? 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
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 Hidden Problem: Contribution Quality
There's a second issue that's less talked about: AI is flooding popular open source projects with low-quality contributions.
Yesterday, I checked GitHub's Spec-Kit repo—a collection of markdown files and shell scripts to guide AI through spec-writing. Simple but effective, with ~62,000 stars.
One thing caught my eye: 507 open issues. For a repo with 14 markdown files and a handful of scripts.
I dove in:
- Most issues are low-effort contributions or feature requests (only 10% are actual bugs)
- The majority aren't issues at all—they're people asking questions already covered in docs
- One third of the Contributing guidelines are dedicated to reducing low-quality AI contributions
- 73 open pull requests, mostly simple copy-paste additions
The problem isn't truly AI-generated contributions—it's people unfamiliar with repository norms who can't be bothered to read the docs themselves. A flood of "vibe coders" drowning out the signal.
Good Examples Already Exist
Many successful projects don't rely on mass contributions:
- Django requires a Contributor License Agreement (CLA)
- Caddy sets a high bar for contributions without being exclusionary
- PostHog, Plausible Analytics, and others have clear guidelines: "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
This brings me to something I'm personally wrestling with right now.
I'm building Knitli, which includes CodeWeaver (semantic code search) and Thread (real-time codebase intelligence). Thread is AGPL-3.0. CodeWeaver is currently MIT OR Apache-2.0.
I'm about 90% decided to move CodeWeaver to AGPL-3.0
Here's why the calculus has changed:
The old way:
- MIT/Apache-2.0 were defaults for open source
- Permissive licenses drove adoption
- Get mass adoption, monetize later
The new reality:
- AI companies train on your permissively licensed code
- Large players fork and wrap your work
- You have limited options to build a sustainable business
What I'm seeing now:
- Big growth in projects with commercial intent choosing AGPL-3.0 (Firecrawl, MinerU, Daytona)
- Projects with many stars using "fair use" (not open source) licenses (n8n, OpenHands)
- Growing use of commons clause additions (dokploy, ReactBits)
- More fully proprietary code in public repositories
I expect these trends to accelerate. We'll see more "open code, closed source" projects soon.
My Reasoning for CodeWeaver
- It's a developer tool. Most developers can use or modify it without contributing back. AGPL-3.0 doesn't block that.
- The main risk is AI companies using CodeWeaver as a feature without contributing back. AGPL-3.0 limits that risk.
- AGPL-3.0 is still very much open source—it just requires anyone who modifies and hosts it to share their changes, keeping the ecosystem healthy.
- It protects against large players taking core ideas and building proprietary versions.
The decision is harder for CodeWeaver than Thread. Thread is infrastructure—it always needed strong copyleft protection. CodeWeaver is more of a developer tool, where permissive licenses traditionally made sense.
What This Means for Maintainers
If you're maintaining an open source project as a business, the rules have changed:
Re-evaluate your licensing strategy. Permissive licenses that once drove adoption may no longer protect your business. Consider AGPL-3.0 or fair use licenses that align with your goals. Don't let philosophy override practicality.
Tighten contribution guidelines. Make low-effort contributions difficult. Set clear standards, require CLAs, and be prepared to reject contributions that don't meet your criteria.
Focus on building services, not just code. If your business relies on documentation-driven traffic, pivot. Offer hosted services, enterprise features, or other value AI can't replicate.
Transparency still matters. Even with restrictive licenses or proprietary code, keeping your repository public builds trust.
The Bottom Line
Watching Tailwind struggle while Databricks raises $14B has clarified something:
Open source isn't dying. One business model is dying. The companies that adapt are thriving.
I'm still figuring this out in real time. But the data are clear: if you're building open source software as a business, the path forward isn't about abandoning open source—it's about choosing the right model and protecting what you build.
I'm Adam, founder of Knitli. I'm building AI context management 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 on Bluesky, Twitter, or LinkedIn.
CodeWeaver is in alpha and I need users! Try it out, break it.
This post originally appeared on the Knitli blog at https://blog.knitli.com/ai-killed-one-open-sorce-business-model-not-open-source/
Top comments (0)