Brian Casel: [00:00:00] Hey, this is Open Threads. I'm Brian Casel. It's my podcast. Welcome to it. Today, I'm talking to my buddy, Adam Wathan. He is the creator of the very popular TailwindCSS. That's a open source CSS framework, which makes it incredibly easy to design and build. And I think the most important value is the ability to really easily maintain a long term project.

And I've been a fan and using it in all of my projects these last few years. So it's been awesome to get to know Adam. And, you know, in this conversation today, we talked about open source software as a thing on the internet, but also like how it actually relates to building businesses on the internet, whether you're leveraging open source software in the things that you're building, which just about all of us are, or it's actually a key component in your own business as it [00:01:00] is for Adams with talent, of course, he's been able to build.

Tailwind Labs, an incredibly successful business on top and around, uh, this thing that, that he's been able to create called Tailwind. So, you know, we got into all the ins and outs of what OSS, open source software is all about. but for now, here's my chat with Adam enjoy.

Hey, Adam, how's it going, man? Good, man. All right. We'll look at to hop on the mics with you. Well, in this segment, I would definitely like to get into open source software as a thing on the internet and what it's like to be working on, on one. Obviously you're working for several years on TailwindCSS.

We're not going to get a full backstory of talent. You can find that. I mean, on your own podcast that you have and everything else that you've put out there, but I just want to say upfront, it has been such a game changer in my experience as a tool for designing and building on the internet. I mean, I just can't thank you enough for making it because it has really changed the game.

Adam Wathan: It's a [00:02:00] fun tool to work with, for sure. I felt like I was trying to figure out, I was trying to solve CSS for myself for a long time, you know, like trying different approaches. And this was kind of the last thing I thought to try because it was not what people say is the right way to kind of write CSS.

Brian Casel: That's the thing with CSS, it seems like with many parts of software development, the dogma around CSS and standards and all that stuff just was really strong in the CSS world and Tailwind sort of like flips all that on its head. I feel like there's a misconception a lot of times with Tailwind about what the true value of it is.

Like people look at it as a way to rapidly create a new site or a new app from the ground up. And that's true. It definitely speeds up the building process. But in my experience, the real value is maintaining a project for a long period of time. My apps and my sites now are using Talent. I'm able to run these things for years on end and be able to hop in anytime to like completely rework [00:03:00] a layout or rework a feature without having to refactor all the CSS in the whole app.

Adam Wathan: I agree, and I think that's the thing that is unintuitive. I think people expect it to be the reverse. They think, well, sure, it might be great for prototyping and getting something started, but I wouldn't want to come back to that HTML file two years later and have to understand how it works and make changes and stuff like that.

Yeah. Reality is it's way easier to come back to the HTML file and make changes than it is to come back to a bunch of custom nested CSS that you have to basically re understand from scratch. Like ML4 does the same thing on every Tailwind site you're ever going to build. And it only does it to that one element.

It's really easy to just, okay, we need to add a little bit more space around this element. I know exactly how to do it. And I know that I can do it without messing up anything else on the site. It's way better long term in my experience too.

Brian Casel: Well, we won't get into all the technical details of what Tailwind is and how it works, but I mean, I'm just looking at the public [00:04:00] GitHub repo for TailwindCSS.

Right now, what do we usually look at to popularity of a thing? Like this thing has right now, 53 K stars.

Adam Wathan: I think I got a notification on Twitter the other day that tailwind is 69 most starred repo on all of GitHub, which is pretty wild.

Brian Casel: Wow. That's pretty incredible. Yeah. I mean, you know, the other thing that I always look at when I'm like evaluating new libraries or things to use in my work is like how recent pushes commits were.

And I mean, in this case, there was one like 10 hours ago.

Adam Wathan: Yeah, it's pretty actively maintained for sure. GitHub added this stat now too, where you can see how many other projects on GitHub use as a dependency. So it looks like there's 658, 000 GitHub repos that have Tailwind installed, which is pretty mental.

Brian Casel: Well, that's what I want to get into. I mean, where to begin? Cause like today, it just seems like there's so much like chaos in your world. And running such a popular, well known, heavily used framework. So I want to sort of like, get to that [00:05:00] point here in this conversation. But before that, like, just like going back to when you started out talent and even before, like, what was your experience with open source?

Software. I mean, obviously everyone uses open source, but like, were you publishing other projects before you published tailwind and things like that?

Adam Wathan: Yeah, sure. So I think like my initial exposure to open source as a concept that I really understood was when I first got into using Laravel because I didn't really get into programming as a career until.

2013 or 2012. Glareval was already out. It was in version three. I think at the time I had sort of discovered it by like Googling around on the internet, looking for PHP frameworks. Cause we had to do some web projects in college and PHP. I just knew that PHP that's that language people use to make dynamic websites.

I had no idea that you could build like a website in Ruby or something. I thought you had to use like a language that was made for the web. So that's why I just like defaulted to PHP. So I was searching around and I [00:06:00] found Laravel and really enjoyed working with it. And that's my exposure to this idea of like open source software and tools, having communities around them and fiddling around with GitHub and stuff like that.

I think like some of my first open source contributions were just working on little tools for my own websites. Like I remember I made a little wrapper library. That'll let you generate bootstrap style forms from your Laravel templates really easily, you know, with like a nice DSL and stuff like that.

And that was one of the first things that I did. And I worked on a bunch of other little things like that, that aren't really that important.

Brian Casel: When you say you worked on those and you published them, you made them available for other people too.

Adam Wathan: Yeah. Like they were on GitHub. I published them to like Packagist, which is the PHP sort of version of Ruby gems.

A bunch of those things did get. Do you get used by a decent amount of people? Nothing to the sort of scale of tailwind. But I think like my motivation for that was it's kind of a topic. I think it's kind of interesting, actually, that is probably somewhat [00:07:00] controversial. There's a lot of sort of sentiment in the tech industry around open source being like a very political stand.

You create open source software because you believe in the ideals of. Free software and anti capitalist, whatever. But I think for me, and I think for almost everyone I know that creates open source software, they do it not because they actually really have a deep understanding of any of those ideals or like value them.

It's more just like GitHub is SoundCloud for programmers. And if you have an idea. And you want to build it and you want to post it somewhere and you want to get those endorphins and that positive rush from getting feedback on it and seeing people like it and stuff. Making it an MIT licensed thing on GitHub is just part of that story.

And I think that's why. So many people make open source software because programming is like a creative thing, just like making music or something for most programmers who do it in their spare time. Anyways, not because they have [00:08:00] some idealistic mission or something, you know, it's just, I just want to put something out there and I want people to see it and I want to feel good about people liking it.

Um, so that's why I got into open source.

Brian Casel: That's cool. I never really heard of that analogy behind it. I've always had this like internal conflict with open source software, where part of it is like, I feel like I'm, look, it's all free. It's available to use and leverage in our projects. My first real interaction with it is probably with WordPress.

Using WordPress on so many websites and then literally building businesses on top of WordPress as so many other people have, but my conflict with it has always been like, I feel obligated to contribute in some way to the WordPress project or to open source in general, like, how can I get this much value from all these open source tools that are out there and for me and for my business and everything.

Without me giving back, there's that piece of it. But then I also feel like this to this day where it's like, but I'm not good enough to publish or like my [00:09:00] contributions are not technically sound enough for other people to use. And of course, like the level of developer who would be creating popular software, open source software and contributing by their nature, they're much more advanced than I am in my abilities to design and deploy code.

Then I always feel this like hesitation, like, well, I don't want to screw something up on the internet by pushing.

Adam Wathan: Yeah, I think that's valid. I think that's a common feeling. There's definitely a hurdle to get over in developing the confidence to put out your code on the internet for everyone to see.

Even as just like, your own library, where there are no like gatekeepers per se. Or no people you have to worry about disappointing in terms of contributing a patch that's not high quality or whatever. I can't say I really remember much about, like, how I got past that, or if, like, I made a library before I submitted a PR somewhere or not.

I do think it's probably is a little bit easier to make something that's just yours first, where you don't have to worry about, like, the judgment of other people [00:10:00] involved in a project. There's a lot of projects out there that are easier to contribute to than you might expect. It can be intimidating at first, but a lot of the time, fixing something is a one line fix, and you just kind of have to find where it is, especially if there's tests.

But yeah, what you're saying about feeling an obligation to contribute back, or carrying any sort of guilt around like, these people are making this for free, and I'm using it, and I'm not paying them any money, feel like I owe them something. I think that mentality is not super real. Most people who create open source, like I said, create it as a creative outlet.

They don't expect anything from anyone. But eventually projects can get to a point where they're popular enough and dependent on enough that this thing that you just made for free for fun as a creative Adventure in your spare time starts to become something that you feel obligated to maintain, that you feel a lot of pressure and responsibility around.

And that's when a lot of open source developers [00:11:00] start to get a bit resentful, I think, and start feeling like they should be being compensated because they're not doing it for fun anymore. They're doing it because they feel like I have to fix this because it's being used by all these people. I wanted to go out for wings with my buddy tonight, but I can't now because I'm too stressed about getting this bug fixed.

Brian Casel: Yeah, that is where I want to get this conversation into is can an open source project become too big for its own good where it gets popularity becomes a detractor from the actual value of the thing. I feel like we've seen this in a few different ways, right? I mean, I want to get into your experience with.

Growing talent to its current size, but like how many gems or plugins or libraries have been really valuable and useful to a lot of people, but then the developer just abandons them because they can't sustain it. They can't work for free to maintain this thing that everybody depends on it. Essentially, I guess what happened there is.

Either they just lost interest, which probably happens all the time, or they couldn't figure out a way to monetize [00:12:00] and build some sort of business that could help them sustain this very popular library.

Adam Wathan: Or they don't even want to monetize it. There are examples of people say you could sell like enterprise support contracts with SLAs attached to them and stuff.

So, cause that's a value to big customers, right? But. That can be like more stressful than just the weight of carrying the project. You know, if you feel like crap, I need to have a pager on me in case like there's a bug because this customer's paying me, you know, I think the beauty of it and the thing that you have to always just remember is that it's a gift to the world and people can take that and do what they want with it.

And you just have to remember that's all that you're on, like, you're not on the hook for anything. Like, I think the MIT license is pretty clear about this. Like, what is the exact terminology? This software is provided as is without warranty of any kind, express or implied, including, but not limited to blah, blah, blah, blah.

It's like, I made this code. If you want to use this as a starting point, it's here. [00:13:00] But that's it. The deal is done in that sense. It's hard to remember that and remind yourself of that as a, an open source maintainer, but I think it is the only way to really have like a healthy relationship with the work that you're doing.

And I guess as a consumer of open source, something that I always remind myself of that I don't think a lot of people really take to heart is basically any open source library you're using. You have to be prepared to take ownership of yourself. At any point, we've certainly like forked libraries and use that as a base and made it our code.

So now we're maintaining it ourselves. And I think if you're not willing to do that, you just have to also accept that you're depending on something you don't control. And there's risks with that. And you don't really have any right to be upset about it, but it is still stressful.

Brian Casel: Yeah. As that project is larger and you have dependencies on other libraries, then yeah, I guess you must come to those decision points where it's like.

Does it make [00:14:00] sense for us to take this under our way or take a fork of it under our wing to maintain it versus just depend on this other party to maintain it?

Adam Wathan: Yeah, that's the whole deal, right? If a library you depend on has a bug and then it hasn't been updated in two years and the maintainer is AWOL, you don't really have the right to be frustrated with the maintainer.

The code is there, just take it and fix it yourself. It's a given to you for free to do whatever you want with it. And I think it's important to remember that, but it is still more complicated than that in a lot of ways, because of course there's a lot of open source software that everyone depends on every day that isn't realistic to maintain yourself like open SSL, like all the encrypted traffic on the internet is open source and of course I depend on that.

As a consumer of things that use that in a lot of indirect ways, but I certainly don't feel qualified to maintain that software. So it is a bit of house of Cards in a lot of ways, but I think for me, it all comes back just trying to have this healthy relationship with the stuff you make yourself where just remember that for me especially, certainly I build things that [00:15:00] are tools to solve problems, but it's also art at the end of the day.

It's a creative thing. I'm doing it because it's fun and I can make the computer do cool things and in ways that I think are fun to work with. I put that stuff out there because I had fun making it and I want to share it with the world. I mean, once you start trying to make money off of it, it does get more complicated too.

Brian Casel: It's an interesting take on like product design and product development. Tailwind is a product, but it's also a free open source product that anyone can use. Obviously you have other paid products that go along with that, but people think about product design or software products as like you're responding to market demand or feature requests and things like this and solving specific customer problems and stuff like that.

I feel like this goes under talked about where it's like. You kind of have to have a certain vision for the world or how a problem should be tackled or designed and whether that's exactly how the market is asking you to build again, like on this, like open source project of tailwind, like, what [00:16:00] does it look like for you now?

Like day to day, what is the sort of volume of requests for people who aren't that experienced in maintaining such a big thing, just as like an insight into what it looks like. So you've got like people filing like issues in the public GitHub repo of like, Oh, notice this bug. Like, why doesn't this work?

And I'd imagine there's a lot of those that are like, it's not a bug. That's like a customer support request. Essentially. What does that look like? And then, but also wrapped into their, like, what are some strategies that you've figured out over the last few years to keep your sanity with this kind of stuff?

Adam Wathan: Yeah, so a lot of interesting things to talk about. There's a lot of volume. We get a lot of issues and a lot of pull requests, a lot of different projects. I think we manage it better than most projects, like the Tailwind repo right now has 43 open issues. Whereas if you look at a lot of other popular open source projects, you might see 950 open issues or Whatever.

I think there's a point that's probably maybe like around 150 issues, whether you accept it in your own brain or not effectively [00:17:00] decided you are never going to be on top of that flow of work. And that's a huge source of stress for open source maintainers. A lot of the time, you know, the reality is most of those projects don't have that many bugs.

One example, not to pick on anyone, but just to give like a real example is a create react app is a really popular scaffolding tool for. Building react apps, right? They have a 1. 2, like 1200 open issues, but there's no way that there's 1200 bugs that are really their responsibility. So a huge amount of those are just on triaged support requests that take an extreme amount of time to sift through what someone's actually trying to communicate to you.

There's so much missing context and almost every open issue all the time. And it might take you. 25 or 30 minutes or sometimes even two hours just to realize that the issue that this person has raised is because of a configuration problem in their project.

Brian Casel: And I got to imagine that of 1200 open issues, you got to figure like [00:18:00] probably 400 of them are like the same issue.

Adam Wathan: Sure. Yeah. Yeah. There's probably duplicates and then there's probably a lot of stuff that's just actually a bug with another library or not a bug at all. And just a question, if you're not careful, GitHub especially used to be worse for this because. They added the GitHub discussions feature sometime in the last, like, maybe year, maybe two years.

I don't know. Time goes by fast as you get old. But before that, everything was an issue. A question was an issue. A bug was an issue. A feature request was an issue. And because there's a little number next to it in the GitHub you sort of feel like I have to acknowledge and respond to every one of these.

And I can't get this number down without closing it, which means I really have to have an answer. And sometimes that answer is I'm not going to do anything about this. And that's like very stressful as a maintainer, just sitting there, spending 10 minutes trying to figure out what is the response that I can write here to like, let this person down gently.

Where they're not going to think I'm an asshole and I'm not [00:19:00] going to be on the hook for doing this thing that's really just not my problem. So it's like a lot of baggage to deal with there, but GitHub out of this discussions thing has made it a lot better. Some specific things that we've done in the Tailwind projects to limit the amount of issue traffic that we get is they have issue templates.

And we actually don't use the actual issue template features, but we use the templates, which is that if you start using templates, when you go to create a new screen or a new issue, they give you a screen first that lets you choose the template. And those templates can also be external links. So when you go to create an issue on the Tailwind repo.

The first thing that you see is a screen that basically asks you, like, what the category of issue you're trying to create is. So, we have, like, get help, feature request, bug report, documentation issue, because those are sort of the most common things that were coming up. And we deliberately put bug report as, like, the third thing in the list, because people just always click the first one.

And by default, GitHub is going to make bug [00:20:00] report the first one, especially if you're using real issue templates. And this is, like, super in the weeds about the details of how some of this GitHub stuff works.

Brian Casel: You mentioned like triaging all these issues. It's interesting to hear how you can start to like, actually like automate and let people like sort of self triage.

Adam Wathan: Yeah. So we try really hard to funnel as much stuff into GitHub discussions as possible because so many things are actually just, someone thinks it's a bug, but really they just need help getting it to work. If bug report is the easiest thing to click, then more things that aren't bugs are going to get reported as bugs.

But this way, people click get help, they go to discussions, it has a little template there, they fill it out. In discussions, there's no like counter saying how many are open and you can have discussions that are closeable, but generally they're just threads where other people can pitch in. And when the mentality that I sort of take is things that are in discussions, like that's the community and like they can help each other.

And that's the only way for me to Maintain any balance in my life in terms of being able to do the things that I want to do and not feel like obligated to just [00:21:00] be helping people all day long, because the other challenge is as a tool gets more popular. Of course, you get more questions, but the questions actually get worse because.

The more popular a tool is, the more inexperienced people start using it. So the quality of issues and the quality of requests actually like goes down as the tool gets more popular. So not only are you now dealing with a higher volume, you're dealing with like a higher volume of lower quality things where there's like more back and forth, more, hey, this picture that you took of your computer screen on your phone.

Is not as helpful as a real screenshot, which is also not as helpful as an actual reproduction repository.

Brian Casel: In my experience where documentation comes into play, I think with Talwin, you guys have done such an incredible, I think that's a huge factor in what makes a big open source project popular is the quality of the documentation from a user experience, how a user can pick up and use the first run experience with a new library by [00:22:00] following.

The examples in the documentation, I feel like that's where so many libraries really fall short because I still consider myself pretty new to software development, even though I've been doing it for years now, I'll still run into things where, like, I need to pick up a tool to solve some problem in my app and I'll Google and find one.

Like I have the sense, like this thing probably solves my problem, but I can't figure it out easily or quickly enough because the documentation isn't there. I'd imagine that as a thing gets more popular in the early days of open source project, it's so small that documentation isn't a high priority or it's, it's really only geared for more technical people.

If the documentation doesn't become more beginner friendly over time, I feel like it's just going to really exacerbate that issue of like more beginner questions coming in.

Adam Wathan: Yeah, you definitely have to work really hard to preemptively avoid these questions getting asked. You know, it's easy to just answer the same question over and over again.

And not take the steps to hopefully reduce the number of times that question gets asked, although it's impossible to reduce it 100 percent because so many people just won't read the documentation. [00:23:00] We regularly get issues where we've gone out of our way to add a warning in the console that explains what the problem is, and someone will open an issue and paste in the warning from the console, say my project's not working, and they paste that in.

And I have to basically say, What I'm going to type in this response is exactly what was in that error message. And then magically they solve their problem. Cause they actually take the time to read it. You know what I mean? You can reduce it for sure, but it's hard to get rid of, um, a hundred percent of it.

We do a lot with like saved replies to like you would managing customer support on helps scout or whatever. And that helps a lot, but admittedly, like, I don't think we have it a hundred percent solved. It's one of the more stressful parts of running the business because we have our own priorities of new things that we want to build.

We need to figure out how do we balance that with just making sure that issue count is not just like slowly going up forever, making sure we're actually closing more issues than are being open or figuring out a way to just become okay with there being lots of issues like there are on most projects.

The [00:24:00] problem with that is once they hit a certain number they just might as well not even be there because of course like any important issues you're going to fix but you're not fixing them because you saw them get opened on github you're fixing them because someone dm'd you on twitter or you find out about important problems through other channels.

My friend Caleb who runs AlpineJS he like disabled issues on github completely and just uses discussions and he has a bug report category. And people report bugs there, and most of the time they're actually support requests, and he fixes the important bugs. And honestly, I feel like that's a lot healthier in a lot of ways.

Like, you do audio production too, right? So maybe this analogy makes sense to you, or maybe this sounds right to you. But all of those tools, like Pro Tools and stuff like that, they all have forums. Bug reports are often just like a category in the forum. And as like a user of Pro Tools or something, I'm not expecting that to go to zero.

I'm not expecting that all of them even get looked at. And I'm also not expecting visibility into what the [00:25:00] company is doing. But with open source, there sort of is that expectation. It's tricky. When I think about it from an outside perspective like that, it makes it a little easier to be willing to let go of that and not be focused on getting things down to zero, but even just the UI of GitHub and the way they present that stuff, it really does put a lot of pressure and stress on maintainers because you could almost imagine a world where GitHub color coded the count on issues and it got more and more red as the number went high.

You know what I mean? It's borderline that experience already.

Brian Casel: Yeah, exactly. And it just adds like a big flag when a new person is like evaluating a project or whether or not they're going to use it as like, do they see a high open issue? You know, you made a really great segue into what I want to get into the next segment with you here.

You know, where you said, how do you maintain such a popular open source while still doing what you want to do and actually building a business and keeping your own priorities straight without constantly having to chase that, that issue. So I definitely want to get into that in the next segment. So we'll wrap this piece up here.