Last year they claimed they had $800k in ARR from sponsors alone[1]. Add to that whatever they made by selling Tailwind Plus ($299 individual / $979 teams one time payment)

How much money do you really need to maintain a CSS library? I understand everyone wants a really fancy office in an expensive city, lots of employees with very high salaries and generous perks, and so on. But all that is not needed to maintain a CSS library (that is kind of feature complete already).

I think Tailwind was making a lot of money (surely over a million), expanded and got bloated unnecessarily just because they had all that money, and now that their income dropped to what still is a lot of money for a CSS library, they're angry that they have to cut expenses to a more reasonable level.

I guess it worked out for them because now they have even more sponsoring.

And they used the AI bad get out of jail free card when a lot of their drop in sales probably comes from shadcn/ui and others which offer something similar for free.

[1] https://petersuhm.com/posts/2025/

▲

onion2k a day ago | parent | next [-]

How much money do you really need to maintain a CSS library?

If you want to continue to develop new versions, you need enough to pay as many engineers as you need to do that. If you're not developing new versions then the money from sponsors will eventually stop.

And they used the AI bad get out of jail free card when a lot of their drop in sales probably comes from shadcn/ui and others which offer something similar for free.

shadcn is built on top of Tailwind. If Tailwind dies, so does shadcn.

▲

hu3 20 hours ago | parent | next [-]

> shadcn is built on top of Tailwind. If Tailwind dies, so does shadcn.

They can fork tailwind into openwind and keep using the stable version for a looong time with minor fixes.

And that would probably benefit shadcn somewhat since they would have more control.

▲

ib33 16 hours ago | parent [-]

And how would you adjust Shadcn salaries to account for this additional work? Do we expect open source labour to be subsidised by maintainers while the rest of us find work at FAANG?

▲

hu3 15 hours ago | parent [-]

How much work are we talking?

It would be in their best interest to keep "openwind" stable since changes to the CSS lib would require extra work in their component.

Different incentives.

▲

ib33 10 hours ago | parent [-]

Enough for multiple full time jobs. They've laid off staff who handled tasks they can no longer afford to pay for.

Is keeping both stable in their best interest or yours?

The set of options includes choosing to not keep anything stable. They can abandon both and go do other things. If the market wants them to keep x alive, it can offer a premium.

	▲	hu3 9 hours ago \| parent [-]
		We'll have to agree to disagree then. Because to me Tailwind maintenance look like a 2 devs jobs at best. They have 3 founders. They don't even need to hire.

▲

skybrian 15 hours ago | parent | prev [-]

This seems kinda circular: they need to release new versions to pay developers. They need to pay developers to create new versions.

I hope they have better reasons to release new versions? Not releasing new versions also has its charm: less churn.

▲

Culonavirus 18 hours ago | parent | prev [-]

> How much money do you really need to maintain a CSS library?

Seems to me like Tailwind is a relatively complex beast covering a lot of ground, not to mention that web browsers are living/evergreen projects that are costantly moving forward, and so the lib needs frequent updates. I don't think you can avoid this (just by the nature of the project). You also need to be a css expert who follows the browser and feature development closely on top of having an excellent grasp of js/ts and the build (lightining css, vite...) ecosystem. I mean ... A few excellent engineers and a designer is probably just the bare minimum to keep Tailwind maintained.

▲

skybrian 15 hours ago | parent [-]

If browsers are breaking old CSS, making new releases necessary, then that seems like a bad situation. I thought browsers were good at maintaining backward compatibility? Not so for Tailwind?

▲

Culonavirus 11 hours ago | parent [-]

I mean just go over v4.x.x release changelogs [0].

The "web platform" is evolving at a decent pace in general [1][2]. You can sometimes do the same thing in 50 different ways (thanks to the breadth of css features and js apis and backwards compatibility), but there may be a much more elegant and robust solution on the horizon and when it hits the baseline, chances are it would likely lead to a simpler framework codebase and/or shrinked output if integrated... and therefore such a feature should be integrated. Now do this a zillion times over the life of the project. You have to keep up.

Less hacks, less code, smaller outputs.

And THEN you have all the bug reports and new feature requests.

And THEN you're supposed to work on something built on top of Tailwind that you can actually sell so you have something to eat tomorrow.

[0]: https://github.com/tailwindlabs/tailwindcss/releases

[1]: https://web.dev/blog

[2]: https://developer.chrome.com/new

	▲	skybrian 11 hours ago \| parent [-]
		If the old way didn't break, it's not true that you have to change it. You can ignore the new stuff if you want to.