How Fred Schott built two open source projects with 20,000+ GitHub stars

Fred Schott 0:00
You're learning from what people tell you about your thing, the things they want to use it for. If you don't know if that code is going to live, the next week, when you go and learn something else about it, why would you spend too much time on it? It's way better to see it happily made, but still see it working, because then you'll get so much more insight.

Jack Bridger 0:17
Hi, everyone. I'm Jack, and you're listening to scanning dev tools, the show that investigates dev tools go from zero to one. I'm joined today by Fred Sharpe, who is CO creator of Astro and co founder of the Astro technology company. And Astro is a web framework that is really fast. And it's kind of built from the ground up to have like, really fast blogs and content sites. And it's it's really taking off right now. So it's really exciting to have Fred on the on the call. So thanks so much for joining Fred.

Fred Schott 0:50
I'm happy to be here. Thanks for having me on.

Jack Bridger 0:52
Could you tell us a bit about Astro and what you're working on?

Fred Schott 0:56
Oh, yeah, I mean, you nailed it in the intro. Yeah, Astro is a web framework. So way to build websites, we're trying to bring kind of the best of all the frameworks that are out there, specifically for the use case of building content focus sites. So if you're building a homepage, or a marketing site, or a personal blog, personal portfolio, kind of all the way up to even like an E commerce site. Astra is designed to give you this really nice easy to use experience built around server first html focused, really, really focused on being easy to pick up and use, while still letting you bring your favourite framework. So it works with React, spelt view, solid, whatever your thing is, um, you can kind of bring that in for the interactive UI on your page. So it's a fairly unique architecture in the web space. But ultimately, its job is just to be faster than everyone else, and make it easier to spin up a site easy to use, and easy to be productive.

Jack Bridger 1:51
Yeah, it's really cool. And I'm someone that can kind of came in to web development, when react was kind of the default choice for absolutely everything that you ever did on the internet. And it feels really interesting and exciting that you're thinking so much about like, Well, is it always the right choice? If you're just doing if you're, if you've got like a very static site? And it's really exciting.

Fred Schott 2:20
Yeah, I mean, the last like decade, it feels like almost has been defined by these like full stack JavaScript. So like spa is right at this SBA single page app like, and I grow up as a driver, but I've been using React my entire web career, like, I love react, I'm a fan of react. But it's that like architecture of like, everything's react that is I think what we're challenging the most. So an Astra you still use React, but like, it's not the only tool in your arsenal, it doesn't have to be like everything's, you know, when you all you have is a hammer, everything's a nail. Instead, we can have this kind of server first html rendering, and that's going to do the server rendering for you. And then you get to sprinkle in the React components where you need them. So instead of having to ship your whole website, as a Javascript app, you're shipping your whole page as HTML, and then sprinkling in that JavaScript, so it's much more performant. And I like to think simpler, is kind of like it's a callback to like old school architecture. But now we'd like this modern twist on it. So yeah, it's like, it's so so much how the old web used to work. But the last decade has been this other architecture. So it's almost like a return to those basics without sacrifice, integrate

Jack Bridger 3:29
the axe. Yeah, maybe that's why it's caught on so much. Because devs just always love to go back to the way it used to be with a simple

Fred Schott 3:38
meme is the Scooby Doo meme where they're like pulling the mask off the villain, and it's Astro, you pull it off. It's just like PHP, it feels a lot like that PHP, like, I'm going to mix in the server logic with this templating logic, like, it kind of gives you what React is now doing with server components. That's basically Astro. But built in from day one versus something that now they're having to kind of retrofit. You can mix your server code with your template logic in a really clean way, because it was designed literally for that use case from day one.

Jack Bridger 4:07
Yeah, that's, that's really, really cool. And it's, it has been taking off. And one of the things that I'm really curious about is, in our introduction for you, you have two sides. So you're the CO creator of Astro, and you're also the co founder of the Astro technology company. And interestingly, when I went to kind of see or how to how does Astro work, how does the business work? It's really hard to find like the Astro like business from the Astro. Like the Astro project site, and it was like very kind of cool the way that it's seems like it's very much kind of separate, in a sense.

Fred Schott 4:51
Yeah. Yeah. It's it's fairly unique. I mean, there's not a lot on the Astro technology company just because it's fairly new still, we're still figuring out what the best way A is to build a kind of sustainable company around an open source project. But from day one, what we've been thinking about is getting that relationship, right, like, Astro is an open source project, it's not owned by this company that we've formed. It's not like by being an employee, you automatically get to like set the direction of the project, we've actually tried to flip that script as much as possible. All the people who created after with me, we all really care about open source communities, building really sustainable projects, like we came to this project as lovers of open source, not like as a way to like, make a quick buck. So from day one, it's always been that the community is kind of Astro and Astro is an open source project. And the company exists to support that. So by joining the company, you're not automatically becoming like a full member of the community, you kind of still have to earn that you still have to be a part of the community and kind of earn your spot there before you can, you know, vote on proposals make governance changes, you're actually like a more like core maintainer is someone who comes through the volunteer the open source community, they have more kind of privileges than someone who just gets hired by the company to work on Astro. So it's a fairly unique model. I don't think anyone else is doing it at our scale right now. But it's something we all really believe in as you know, the company is not the project. They're they're very different. The company supports the project, but it's not the other way around.

Jack Bridger 6:20
Yeah, I mean, this really important to create that trust. And yeah, it's it's very exciting. And you mentioned that you're a lover of open source. And I think you've pretty much proven that. Is this the first project that's had more than 10,000? GitHub stars?

Fred Schott 6:38
Oh, that's a great, I don't know, definitely more than 10,000. I don't know how many projects have built it up that but I've been working in open source for a long time I've been I mean, my first job I was lucky enough, my college I had something that was like, just by total luck got to the front page of Hacker News, like a total goofy project. It barely worked. But the bar was a lot lower back then. So I guess I got I got it snuck my way in on like a Sunday morning when no one was posting anything. But yeah, I've been working open source for a long time, I've I've always had a soft spot in my, in my heart for just people building whatever they want without, you know, asking permission.

Jack Bridger 7:13
Yeah, that's very cool. And the main focus of this episode is going to be about this article that you've written about how to how to build open source projects, and what you've learned by doing it. But before we dive into that, could you just give us a brief kind of overview of what you worked on, in terms of open source before Astro?

Fred Schott 7:34
Yeah, so I've been leading open source projects. And so for the last maybe like five or so years, but before that I I just was always a like maintainer, like I jumped into other people's projects. So going back to my first job ever, I was working with a web team at a company called box. I was like a junior employee, like software engineer, like they had a ladder, I was like, years away from a sort of promotion. And I was bottom of the ladder I, I didn't have I liked, I was just excited to be in San Francisco, I was, you know, big, wide eyed kind of engineer coming from from Boston. But I pretty quickly realised that there was this like almost other world of I could like, get involved with software, I was just hungry, I wanted to learn new things. And I found this open source project, that time that we were using it box was called request, which like, it's I think deprecated at this point, it was like the top five NPM package. It was how you did web requests in node at the time. So like, now, Axios are just native fetch, but 10 years ago that didn't exist, there was this request package that like everyone used. And so I pretty quickly was like fixing bugs that I was finding my own work, and then just started to get more involved. And, you know, it was it was like a classic open source project, more issues, and there were people could work on those issues. So just pretty quickly. I was kind of like deputised Are you enough bug fixes, or someone's like, great, that's awesome. And Michael Rogers, who was running the project, who's amazing, like an old school, he was one of the people that the node fork back in the day, if anyone remembers that, like, he's an awesome, awesome kind of someone, I look up to a tonne and open source. From the node, like kind of early days, he had been running that project himself, he created it. And he was like, very quick to be like, you've got time, clearly, I don't like go do some stuff. And so he very quickly just gave me more and more responsibility. And I was still junior, I was still making mistakes, but he kind of let me make those mistakes and give me a platform to just try things and make changes and actually, like, try out like, what does it feel like to merge someone else's PR and I was very lucky to find a project where someone was it was kind of willing to give me a shot. So super, just kind of lucky to have found that but also a tonne of work involved to just kind of contribute back to this project. And yeah, the biggest thing for me was just like, you know, I'd be this like, lowest rung employee at a company and then I'd go home and open up my laptop and I was shipping out to like, every company that was using node was using this package. So like, that weird dichotomy, just like that always stuck in my head is like, oh, I can have a real impact here. Like I can have real responsibility here that would take me years to get anywhere else. And in a job I all of a sudden, I'm able to contribute at a really high level. That was really exciting to me.

Jack Bridger 10:21
Yeah, that's so amazing. And I feel like that is still around, right? I'd like I'm sure I saw it recently in another project. That's, that's incredible. That Yeah.

Fred Schott 10:30
Oh, it's funny. Yeah, it'll never die. I'm sure it still has millions of weekly downloads. But it's it is like very much deprecated. Like, don't use a like it's not maintained anymore. Oh, really? Big warning, if you find it on. But yeah, I mean, that was like, for many years, that was the package on NPM.

Jack Bridger 10:45
Yeah. Wow. And where did you go from there.

Fred Schott 10:49
Um, it's always, like, it was just always saying I did in my free time, like, I was just one of those, like, nerds who like I like working with software. So it's both my job and my hobby, which, in retrospect, probably isn't super healthy. But I always just loved working on software. So for a long time, it was just the thing I did in my free time, you know, would try my hand at like writing blog posts about it, like, give one or two like meetup talks, but ultimately, just really love working on open source software. So that followed me, I think, throughout my career. And then my kind of my attempts to like running projects mainly started out of the well, I mean, it kind of has its path directly to Astro. But pico was the first project that I really kind of sunk my teeth into. So pica was just like, super just kind of like researchy. Interesting, like, let's throw a bunch of stuff at the wall and see what sticks project focused on ESM. So if you work with JavaScript, that import export syntax, that didn't used to always be there, there was a long time where it didn't exist. And then there was a long time where we were writing it as developers, but then our tools were compiling that down to what node would understand which was require module dot exports, like this kind of older syntax for modules that wasn't native to JavaScript. So that migration, we're kind of on the tail end of it. But for a long time, that was like this huge disconnect, where there was a tonne of we were authoring a format that we never actually ran anywhere. And like the, the attempt of Pico was trying to kind of ask the questions trying to ask us like, what if we actually ran the SM code somewhere? So build new tools that actually shipped that ESM to the browser, and unlocked a tonne of cool stuff? So build tools, there was a CDM called Sky pack that came out of it. Yeah, a build tool called snowpack. It was just kind of like, I want to try a bunch of random ideas and the things that people seem to really connect with, I'm gonna see if I can invest more and more of my time. And and that's really what snowpack and sky pack came out of.

Jack Bridger 12:40
Yeah. And snowpack, you wrote this really great article about the things that you learned building snowpack.

Fred Schott 12:50
That article was like therapy for me, because it was a project that ultimately didn't take off. If no one's ever used snowpack. It's basically what the has become snowpack was like my attempt at that at the exact same time. And then you have the view team was working on that. And, yeah, Ivan's a monster. I mean, he just, there's a tonne of lessons I learned just by watching him and like, compete, quote, unquote, with him trying to build a very similar tool at this exact same time that just, yeah, if you've used V, that is very much what snowpack was a bunch of years ago, but way more buggy. And that is kind of mature as it is today. Ironically, we don't ask on top of snowpack and then move to the because they were just doing such a great job at it. And we couldn't maintain both of these. So yeah, the snowpack, very similar tools. But snowpack, you know, didn't really ever get to where I wanted to be and therefore I kind of eventually had to let it go and wrote this kind of cathartic like things I learned while building snowpack, kind of the good and the bad. And yeah, that was a very cathartic experience getting that out on paper.

Jack Bridger 13:51
Yeah, and I guess this whole episode is gonna be kind of a bit about that. And plus, with some updates from Astro, I imagine.

Fred Schott 14:00
You know, it's so funny. Before we started recording, I went and reread it. And like, half of the article, I'm just trying to pitch people, like, stop creating slack communities for your open source projects, like create a Discord server for the love of God, please. And like, now, I feel like that's very much understood. But it's so funny looking back, like how many people were still like, Oh, I'll create like a Slack or create this, like work focused group chat for my open source project, and just completely having done that for projects before like, yeah, it's just so funny that that is something that's really changed since I wrote that article. I'm sure there's a bunch of stuff that's changed in the last year or two.

Jack Bridger 14:34
Yeah, well, let's dive right into that. So why is it so bad to create a Slack channel for your open source project?

Fred Schott 14:41
I don't even know that. Yeah, if you're still considering it. What's funny is Slack has only become more work focused over the last couple of years. So for a while, I think they were like, maybe do we want to support this use case and then now they're just like, I don't even think they care anymore. Like, there used to be someone. If you knew a guy and knew a guy you could get a free account for your open source project. But like that, as far as I know is completely gone like you would have to pay I think today for it, which is a shame. But yeah, Discord is just like, there's a lot of what I'd say learned the most from snapback was just the importance of community. Like a lot of those lessons were me not taking the community as seriously as I should have, like, I just wanted to build software and I didn't realise like there was these people who were excited to use Astro or snowpack at the time you snowpack. There, these people were excited to use snowpack. But like, that's a really important part of growing a project. So discord becomes this like really fun place where you can almost build a community where people actually want to spend some time even if that's just like bugging you with a feature request or an issue. When you come on Slack. It's like, Dear Sir, or Madam, I have a feature of like, it's a totally different energy than discord, which was like built for, you know, 12 year old gamer kids to like, you know, you have to moderate your community, it turns out the tools they had to build for gamer kids is actually really good for moderating your community of open source, like, the gifts and like the memes and the emojis. Like all that stuff actually contributes to having a really, like, fun experience using discord versus a work experience for slack. And then the other moderation tools are kind of the icing on top. Yeah,

Jack Bridger 16:13
yeah. That makes sense. Yeah. Okay. So that's, that's a real, that's a real good lesson. And when when you were getting started, there were quite a few lessons you had there. So there was like, build for yourself. First, write messy code, your first users are essential. Could you talk a bit about like, what it's like at the beginning, when someone just starting off with an open source project?

Fred Schott 16:38
Yeah, so like, if you're someone who has a project that you're working on, and like you get your first user, I think one of the biggest superpowers you have at that early early size, is when someone comes in with feedback. Like, you're right. They're like, they're the first person who's ever talked to you. Like, it's such an exciting feeling of like, Oh, my God, like you want, you want this thing, you're having this problem that I had to, like, you want to solve this thing you want, you're looking for a tool here, that's awesome. You can take their feedback. And basically, as soon as they give you like, Oh, I wish it did X or Y or Z, you can go and build that, like there's no, if you're just working solar, like there's no review, there's no, no one to kind of run and get feedback from like you just are moving. So you're able, at least to move so fast at that early stage. And again, if you think about like if what you're building alongside your project is a community, like what you're hearing is feedback from the community, and then you're instantly updating and like responding to that feedback. So you're building this really strong connection of like, you can make changes quickly, you can respond to feedback, you can fix bugs for that person who's kind of taking a bet on something really early. That's probably the strongest sign that they're looking for. It's like, Oh, I like had a bug and they fixed it in a day. Like, if a large project did that, you'd be like, Oh, my God, why did they move so quickly, like, this isn't safe, this isn't stable, I like that would almost scare a larger project to move that quickly. Because if you introduced another bug with your fix, but for a small project to be responding that quickly. That's a superpower that, like I missed so much when a project grows, because all of a sudden, there's more moving parts, there's more tests, you need to forget about those early days, you can really move quickly and really respond to feedback quickly. And get that signals like what is this thing, you're almost like listening to the community tell you what they want your thing to be, and then you can kind of grow it into that. Because chances are, you probably didn't get it perfectly right? The first time, there might be feature ideas that you hadn't thought of or use cases that you didn't personally have. But all of a sudden someone else is asking you for a thing. If you can listen to that respond to it quickly. That's such a great signal to them. And it's also just great feedback for you to move in the direction that other people are kind of looking for solutions.

Jack Bridger 18:37
Yeah, yeah, this is true. It makes me sense like he when when someone feels like it's kind of tailored to you this whole project in a way. Yeah, that you matter. So when you talk about this, like kind of moving fast and responding to people, there was also something that you said that kind of resonated with me that I think you're one of the first projects was like a kind of you you fought to another project. Or you at least reused a lot of code. And I thought that was kind of a really interesting point. Because when I have tried to do stuff, I often feel like I should, I shouldn't like, steal, I don't know, like, it sounds silly, but like steal someone's stuff or like, kind of, you know, pass it off, which it just sounds unbelievable. When you reflect that it's open source, but that always appeared in my head anyway. So just wonder how you like, I think it was a really cool way that you did it.

Fred Schott 19:36
Yeah, I think what you're referring to is that the first version of Astro because we have our own templating language. So we have this idea of like a component that's server based versus client base. So it's it's not shipping JavaScript. And to build that we basically forked the salt compiler, like we wanted something that felt very stealthy. So instead of building from scratch, we could take what they built, kind of cheap, make changes and then as we go, we can kind of You know, a lot less of a left to build your own compiler versus taking one off the shelf. Yeah, I stand by that. I think that is very much in the spirit of open source. I think there's like really been this big push of like, you stole this from me or I want credit like, this is totally out of nowhere for me as someone who's worked in this for a while, but like, all of a sudden, you have people complaining about this on Twitter, which just feels so alien to me, I think part of it is maybe people don't understand like how much that's in the spirit of open source. And then are also your people I think, maybe don't understand the importance of licencing the same degree. So if you take someone's code, and just call it your own, like that, actually is pretty bad form. Like that is not a good look. It's also just not right, like the spirit of open source is that we can share all this great code together, you can use my remix my ideas, all these great things, but like, give me the credit, right, just like call out that you did this. Like, the way you do that is with the MIT licence. A lot of people don't know that you have to if you're going to take their code, it's there for you to borrow. You just need to bring the licence along to so have somewhere in your code base that says this code is licenced by this person, it came from this repo like a copy paste some some legalese, and you're good to go like, no other industry that I know has that ability to kind of, yeah, like, like, instead of like, steal from each other. But it's literally like the licence that we all give our software, it's just this one thing you need to do so that when you don't do it, it kind of does feel like a slight. That's my best guess at where this comes from. But yeah, I think that's one of the best things you can do is take someone something that someone else built, make changes to it, and take in a different direction, and then give them credit, like, we're all standing on the shoulders of giants, you know, stole the shoulders of other people who came before us acknowledging that, calling it out and and building something new, like, what we're all trying to do is build new things. Keep improving the space for developers, like, we all have the same mission. So I think that's, I love borrowing other people's code, giving it proper attribution. And yeah, I think you can just build great things that way.

Jack Bridger 21:55
Yeah, I love that. I love that. And I think it really goes well with the other point that you made about not writing messy code, not being afraid to write messy code. And it feels like that's on this path of making something that people actually want and not dedicating your time on something that may or may be that no one else needs.

Fred Schott 22:18
Yeah, yeah, I think one thing, this is such a tough balance for me, but like, a lot of people, if anyone's like me, like, I more build something because I really want to see it. And like, it's just like, I have this, like, oh, I want it, I wish I could see what that would look like. And maybe I want to use it even myself, like I'm solving a problem that I have. Versus like that means there's like this kind of like drive to just build it, which means like, just build it like whatever that looks like you should like that's always the number one goal for me is like you should be having fun working on something that's your own free software. Like if there's if you're not having fun doing that I it's, that's like the most important thing for me. But also, I think there's this idea of like, you don't really know what the thing you're building is, I would argue until you've kind of seen it until you've had other people try it and given you feedback, like, I don't know how many times I've refactored prematurely, and built some beautiful system because I wanted to but like, ultimately, then I learned something new from a user for myself. And I then had to go and re like challenges some assumption. And when your code is a mess, it's kind of almost easier to do that. Because you can kind of refactor as you learn more about the project. But if you build these, like incredibly comprehensive and rigid systems that are, you know, beautifully abstracted, but like, you spend a lot of time on that all of a sudden, you need to change a pretty fundamental thing about how your thing works, because you're so early in the process, that can take a lot more time ultimately than if you just kind of hacked it together. And then later on refactored it. So I think there's this idea, this kind of, I think leads in all parts of open source, like one of the biggest learnings for me is like building something in public, and building time for other people to use. Like, there's a little bit of a just You're, you're more of an explorer, or like even like a gardener than you are, like, I have a thing that I must build like you are learning from what people tell you about your thing, the things they want to use it for. If no one likes what you're built, like everyone, like, if no one wants to use it, like that's an interesting lesson. Like, there's all these things that you're going to learn through feedback. And as you even just see it kind of form, you'll start to have different ideas about what it could be. I think honouring like that. And like understanding that relationship should go through all the ways that you develop that thing. Like, if you don't know if that code is going to live the next week when you go and learn something else about it. Why would you spend too much time on it? It's way better to see it happily made, but still see it working because then you'll get so much more insight. So that's a really important thing that I always follow. In building open source software. It's like it's early print. And this could even be like prototyping code at your company or your job or it doesn't have to be open source to take this lesson of just like you're probably not going to know what it is until you prototype and have people use it. So like a hacky prototype. Oh are a well thought out system any day of the week for me?

Jack Bridger 25:04
Yeah, and I think this is really cool as well. Because maybe this is like slightly outside even like growing a big project or doing something useful, but just the psychology of I often, like talk myself out something in a way because I'm like I'll overcomplicate it might be doing something I don't really know how to do. And then I tried to like architect in my head, like, oh, I need to figure out exactly, and then you never end up doing it.

Fred Schott 25:28
Yeah. Which again, if like, if that's if your goal is to just build something because you want to build it and like you don't really care about other people, you don't care about like finalising it turned into like a v1 tool that's totally fine. Like, do like you should understand your goal. And if your goal is just because you want to build something that's awesome. Do whatever you want to do, like don't listen to advice from anyone because it's purely for yourself. Yeah, I think it's more if you're like, are looking to invest in something that might be long term. That's where learning is you're like, is what I would always put your call to be like, learn more about what you're trying to build. What is this thing? That's That's it? That's a process you can't really learn that overnight. You need to feel it out. Learn from other people using it. Yeah, it's it's a it's way more of a just kind of exploration than it is a thing you can kind of brute force.

Jack Bridger 26:13
Yeah. Yeah. Yeah. This like kind of me. Yeah, that makes sense. So that was like when you go on, like, if you cycle across the world or something you don't really need like to train for it. And because it's like you just start out. Like, you'll get fit along the way. And

Fred Schott 26:29
yeah, yeah, it's it's funny. There's like a, there's a way that this thinking kind of infects your brain also. So maybe this is just me like going way too deep down this thinking. But like, you'll start like tailwind I think is a really good example where I think people are like, oh, like I hate to and you should never use tailwind. But like someone wanting to use tailwind is like telling you something really important. Like managing CSS in a React project kind of sucks. Like, I'm ESN importing it. And then I have to manage that class name. And so that class name has to somehow map back to the component but like class names, or underscores, and component names, or uppercase, and, okay, I'm gonna like, somehow just have to know that these two things are the same. But then I renamed my component. How do I rename the class like, as someone who's worked with CSS and like, then people try and solve that with CSS and JS, but now you're adding a bunch of JavaScript to your bundle. So your performance like when when people like tailwind? It's because like, the things that they've been offered before that haven't worked for them, and there's something about tailwind that they like, and so I think it's the wrong thing to say, well, they're wrong. And the best thing you can say is like, Okay, well, why do they think that like, what about this is true to them? There's huge learnings on that. But like, I think people just kind of, it's just so easy to be like, no, they're wrong, like I'm right. Instead, it's like, no, there's something there that they love. And you can learn a lot about the state of Tullio in the state of what people are happy with and what they want to change and working at work. Can you build a tool if you wanted to build a tool for someone to use, like, by seeing what people are doing and really listening to the things they do, no matter what they say, like there's something there that they're looking for?

Jack Bridger 28:01
Yeah, you're right. There's something there. And it's like, if if there wasn't anything that a normal user, and they do, and it's like that I really there that makes sense. It's like a light bulb moment to me where you're saying that like, it's like you explore you put stuff out there, and you can't like theorise whether it's useful or not. All you can do is like, put it out there and see what people think. And if it is useful, people use it. And yeah, totally. Yeah. It's really, it's really cool. And one of the other things that you you spoke about is like, dog fooding projects, for that was kind of an interesting one. Could you talk about the importance of dog fooding?

Fred Schott 28:48
Yeah, this is really hard for me. Or at least it's been hard in the past because so there was a certain point in snowpacks history. I was like, I like love this project, like people respond. This was kind of like in the pika snowpack days, like part of that transition was me being like, I think there's something here that like no one else is doing right now. Like, everyone's on Webpack. And I think there's like a very different Yeah, this is like, exactly what beat is proven out. There's like a new world of tooling that hasn't been explored yet. So at that point, I had actually left my job, because we weren't really using my company anyway. Like, it was totally just an open source project. And I started working on it full time, like contracting on the side, full time open source, otherwise, you know, to pay the bills, and then just open source to see what this thing was and where it would take. But the problem there was like, because my company was never using it, because I was just kind of working on the tool full time. I never had a real use case for it. So all of a sudden, as I'm fixing, like, the basics, like I'm able to build, I know that it's not totally broken. But then someone would come in and like use it for a big use case. Like we're gonna use snow pack at our company, like great. Let me know if you have any trouble. And like, instantly, they'd run into just bug after bug after bug. And that's, you know, I was lucky to have users You wanted to give me feedback. But at certain point, if you like file an issue, even if you're quick to fix that issue, they tried again, the next day hit a different bug, you file it, fix it. Next day they hit like, there's only so much that people, even your best kind of users are most willing to give you feedback are gonna put up with. So one thing I really learned from Evan here was that he instantly, like immediately started working on a project called VT press, which as he was building VT, he also had this, like dock site template, that was kind of all you need to build a dock site that was powered by Vt. So his own dock site for V was also using the in a really like interesting way where it was about building like it was fully self sustaining loop. So he was actually using VT in a really advanced way. versus me, I was like working on snowpack, I'd like to hack together our dock site was snowpack, and I'd like great problem solve and move on. But I was missing the huge class of bugs that show up when you start to build something bigger and more kind of, you know, more feature complete, because I was just using a small sliver of what snowpack would actually do in my day to day.

Transcribed by https://otter.ai