 It is after 5pm on a weekday and you are still here, so thank you. This talk is called the social coding contract, but because the talk lengths are a little shorter I had to compress it, so this is the contracted edition. My name is Justin, I live and die on Twitter, so if you'd like to give me any feedback or talk to me or be my friend, that's a great place to do it, it's at Sorrel's, my last name. If you have something longer than 140 characters you want to tell me, hello at testdouble.com is a good way to get a hold of me. Open source is good, right? Companies work with other companies, building things that together, like, you know, they couldn't build separately. Never before have startups ever had, like, you know, they have this mountain of stuff that they can stand on and they just have to lay a little, little, little bit on top and then they can develop entirely new products very quickly and never before has like one person at a desk been able to independently change the world as an open source maintainer. But as a maintainer I often ask, is open source really that good, really? Because, you know, companies love consuming open source but they really hate when you need to like submit an upstream patch or if you want to like extract a library from your product and open source it. And a lot of startups I see hoovering up all this free stuff like a grab bag but then they don't understand the, by using stuff that they don't understand well, they're opening the door to like maintainability nightmares a year or two years down the road. And a lot of maintainers I know are really burnt out, they have a lot of negative interactions with other people on the web and they just want to quit. So today I'm just like going to put a magnifying glass on a handful of issues that are facing open source with the hope that that becomes a thing that people get in the habit of doing so that collectively we can have a sense of action about what we need to do. Only then can I hope that like, you know, people start coming up with creative ideas, maybe leading to some new solutions, services, ways to fix some of these systemic problems and then hopefully, you know, reach some point of relief and then we're done. But like I said, I'm not very ambitious. Our goal today is just to talk about a few problems facing open source that we don't normally discuss. We're going to cover a few different areas. One is the Jenga Tower of Dependencies that we've built for each new project. Another is a little bit about being a maintainer in the lifecycle, the repeated death of projects. Talk a little bit about trust and marketing and open source. And then finally, share some ideas about how we communicate online, as well as where I think open source is headed five, ten years down the road. I like to start talks off with term definitions. So this is a definition of the word ideology. They do not know it, but they are doing it. So ideology is sort of a negative space that explains our actions as opposed to like a political affiliation that we ascribe ourselves to. This is a quote from a dude named Karl Marx. I hear Marx is really popular in Utah, so I figured I'd start with a Marx quote. So Karl Marx's, that quote comes from the book Capital, and the reason it's interesting is it exists at the intersection of philosophy and economics. And so does open source, right? We have this altruistic share, share alike mentality, but meanwhile there's tons of companies making bucket loads of money off of open source, right? So if you view like in Marx terms, capitalistic economic progress over time, in the beginning, every person was out for themselves, but eventually specialization occurred. You could have maybe find vegetables at one vendor, meats at another vendor, and through that efficiency of scale, that opened the door to art and recreation emerging. And that's like the foundation of human culture. As time went on, industrialization just kind of blew the lid off that because now at a single location you could get all the commodities that you needed. Freed people up, had a lot more time. And now from my bed on my iPad, I can order most of the things that I want and get it in two days. Like this is progress. But where does that progress lead? There's a rumor that Amazon is using big data now to actually preemptively ship stuff that it thinks we might order to fulfillment centers near us so that it can get same day and next day delivery. And it's forcing a lot of people to ask questions like, how is the march of progress of technology and economics really changing the dynamic of what human civilization was built on? So that's an example of an unintended consequence. Another unintended consequence of economies is the industrialization of our food system. If you've seen the documentary Food Inc., it has this really aggressive tagline. You'll never look at dinner the same way, but I feel like it would have been more honest if it was like four like at least a month. Because it's not like we're gonna quit eating, right? These are systemic problems. And if you look at progress over time, awfulness just naturally accretes because we're focused in one direction. And then there's a moment where we all freak out. And you might think that's the point where we try to make things better, but nothing stops that train because things are too systemic. The best we can hope to do is maybe bend the curve after things get a little bit worse. So that's a little bit about economic progress. Let's talk about dependencies, dependency tooling, because that's really been the story of the last 15 years of open source. If you chart open source's progress over time, in the beginning, we just had a bunch of files out there. Like in C, we had headers and C files. And if I was writing an application, I'd have my headers, my C files, and if I needed somebody else's code, I would literally have to go fetch it somehow, pull it in, check it in, depend on it directly. And then it lived on from that moment forth as part of my application. It was my job to maintain it. And that was a hedge from pulling in too much because if I didn't understand it, I couldn't take care of it. Makefiles were a great innovation because now I could have my application up there with logical dependencies. I could say depend on libxml, and it lived in this other directory, and I would build and link against it. And it would live on as its own version thing apart from my logical application. Java was another big step forward because you could have compile ones run on multiple platforms. So I could build my stuff, but then go out to a website, download a jar, throw it on my class path, and depend on it very conveniently. It was so convenient that a new meme emerged that's been dubbed transitive dependencies. A transitive dependency is the dependency of our dependency. So I go download a jar, and it says, hey, I depend on Apache Commons. And so I can go and suck that down too. And it not only helped us focus like libraries to be significantly smaller, but new entire stacks of productivity emerged within a language ecosystem for the first time. Ruby took all that and then automated it with Bundler. So now I have my code on top with its dependencies on a handful of gems. And then all of the version resolution necessary between themselves and also with their transitive dependencies is handled for me at install time. And so now I can have transitive dependency graphs of arbitrary depth without necessarily having to think below the explicit dependencies. NPM just takes us even further still, right? Because in Node.js, there's no rule that says we can't load the same library at multiple different versions. So a trivial implementation of NPM would just be able to say, hey, here's your dependencies. And then just grab, like a tree, all of the recursive dependencies underneath it. And if you've ever dug into your node modules directory, you can see it goes really, really deep down. In fact, as a library maintainer on every single major node module that I've ever maintained, I've gotten the issue eventually from some Windows user saying, hey, this exceeds Windows Max file path limit of 256 characters. I can't install your thing. Sorry. All of this is short-term progress. That's attainable for every new project that we do. And it's available to us for the low, low price of long-term fragility. Louis C.K. talked about this on his TV show. It's true. Everything that makes you happy is going to end at some point. And nothing good ends well. It's like if you buy a puppy, you're bringing it home to your family saying, hey, look everyone. We're all going to cry soon. Look at what I brought home. I brought home us crying in a few years. Here we go. Count down to sorrow with a puppy. The Louis C.K. of open source, Gary Bernhardt, he had this great quote. He said, build a small but non-trivial Rails app. An empty app has 50 gem dependencies. Yours will have 75 to 100. Go away for six months. Update all your dependencies. Your app no longer works. It's absolutely true. But it's easy to start a Jekyll blog. It's easy to install SAS. It's easy to generate a Rails app. It's always easy right now, never in a year. When we think about our application, we tend to only think about the code that we write as being our app, because it's what we're directly responsible for. But of course, whatever we ship into production is really what our application is. And I encourage us to shift our mindset to think more along those lines when we think about what our overall responsibility is as developers. Because while it's never been easier to ship something into production, the stuff that we're shipping has never been more net complex. Taking examples from just like a node in particular, let's say that I have a module here as a library maintainer and I depend on orange triangle at version C. There is nothing stopping one of my dependencies from depending on version B of orange triangle, maybe one of its dependencies depending on version A. Now admittedly, this is foolish, but it happens in some cases that I might call orange triangle to when I depend on and get a domain object back that's as of version C. And if I pass that into the other dependency which passes it into version B, what happens? Will it blow up? Will it work? As a library maintainer, I'm never thinking about this. I don't have any automated tests for this. If it's working, it's by total happenstance. And yet this is like how node works. Another thing that sucks is that libraries can explicitly declare like I'm specifically this version at C of orange triangle, but I can't prevent that from having maybe a very loose specifier or some other dependency. And so at install time, what the end user is gonna get is just the latest and greatest of whatever red square is. So one day on our project Lineman.js, every new install started failing like from March 3rd on, it's got inundated with emails. What turned out to be happening was that that particular dependency blew up because red square became too new and it became incompatible and some post install script was exploding. And so what we had to do is we actually had to fork it, create our own, push that up to NPM by fixing that red square to the last maintainable version or last compatible version. And that resolved our issue, but now we have this other thing on GitHub and NPM that we don't care about, that we don't understand, that's not gonna get new updates just to resolve this quirk in this otherwise very convenient dependency management system. So it's easy to freak out with edge cases, but I wanna convey the message that like, obviously the code we write is the code that our application needs and I think that we understand that the code that we depend on is there because it's convenient, it helps us do our job. And I think we're even willing to give the fact that the first layer of transit dependencies, yes, that confers some complexity but it's probably necessary, but we go much deeper and it just starts to feel risky and like how often does your team discuss your transit dependencies, transit dependencies? You don't, it's just mysterious. And that's why I think a lot of people have been lampooning the phrase full stack developer lately because I think we've all gotten to the point where nobody can really claim to know everything that they stand on top of. So yes, make files are really painful. See build stuff really is awful, but maybe that was a healthy pain because it was a guard against pulling in too much that we didn't understand. Talking about things being awful, let's talk about life as a maintainer of open source. So I wanna convey the message like, open source maintainers are not these rock stars, they're not super humans, they're just people. In fact, the way I think of it is maintainers are just extra early adopters. So life as a maintainer usually starts off with searching for a thing you need and then finding that it doesn't exist yet. And so a lot of maintainers get there, start by just scratching their own itch, building something that solves their immediate problem and then a slightly less early adopter searches for the same thing shortly thereafter and finds the thing the maintainer made. And the role of early adopters is special because they'll see that they're one of the first users and then sort of like if you've ever been like hip to a really cool indie rock band, they get excited, they post it to Hacker News and then they start sharing it, right? Talk about how amazing it is, which puts the maintainer on a bit of a pedestal. But of course Hacker News being what it is, people are more than happy to pot shot at it and say it doesn't do X or Y or Z and now the maintainer's all, his ego's all wrapped up in it. To the point, early adopters remember they're not like necessarily any less competent than maintainers so very often they'll send in pull requests to fix those things and now the maintainer's happy again. It's crazy how quickly a maintainer's ego can get wrapped up in their libraries. And if you try to just draw a picture of what a library looks like, when it first starts off it's got all these jagged edges because it only solves the maintainer's problem. But as early adopters come along, they can help round that out with pull requests, issues, a little bit of engagement. What ends up happening is you get a more well rounded, ready to be consumed by the masses dependency and maybe that's your version 1.0. Or if you're like me and you're afraid of the implications of semantic versioning, that's your version 08040. And this is the point where this conversation should happen, let a maintainer talks to an early adopter and says, hey, let's own this together. Let's share this. I'm sure any early adopter would be really excited. I'd even settle for this conversation. Hey, let's make you a committer so you can help out in triage. And I'm sure that most early adopters at that stage would really stay engaged. But because neither of those typically happens at this point, maintainer may as well say, hey, let's never communicate again. Then early adopters say, sounds good, bye forever, and then they're off to the next thing because they're an early adopter. They're gonna find a new shiny bubble to play with. So why is it that maintainers tend not, why are all these solo bands out there of repository owners? I think the reason they don't share control is if you were to chart their happiness over time, it starts off with scratching their own itch, building something, getting some happiness, getting some acclaim for building their own thing. While owning that thing, they get to a releasable product, get some attention. And if they just draw a line and extrapolate, they can only imagine their happiness going up from there. But fear not because late adopters will disabuse them of this happiness every single time. A maintainer, as an early adopter, once it scratches their itch, they might not commit for a week or a month. And because they're like an early adopter, some new shiny thing will come along, distract them, and probably they'll whisk away and go focus on something else. But a late adopter has a very different set of priorities and they might look at all the same data and come to the conclusion like, hey, this is pretty stable because no one's touching it. There's a lot of stars, so that sounds like a safe bet. It's open source, so that sounds free. And a lot of late adopters come in long after the maintainer stopped even caring. So a maintainer's needs starts off with the small jaggy thing, but then the early adopter helps round it out. Eventually you get to something that you can kind of conceive of is what this dependency does. You could layer on every new user after that, like what their needs look like and that shaded area where the two overlap is where it does the job that the user thinks they need. But everything else that's unshaded area becomes a negotiation. Every late adopter at that point has to decide do I work around this, do I write my own code, do I send a pull request, do I fork, do I open an issue? Late adopters tend to be less eager to contribute their own source, so very often it just takes the form of complaining. So literally like two days later after a lot of late adopters tell me they're so glad for my thing, they'll put a stern look on their face and then I'll hear something like, hey, this doesn't enterprise my enterprise thing at all. And how could they miss something that's so obvious and important to me? And this is where entitled GitHub threads come from. Where the title is like, oh, there's missing some obvious important thing. It's supposed to do all this silly nonsense. I have this expectation and I reply and like, I'm sorry I didn't know how to do silly nonsense. And then instead of a nuanced subtle conversation about whether it should do silly nonsense, all of their coworkers just come in with drive by plus ones and I'm left made to feel bad. But if you think about it, it's probably a weekend, I'm probably at the park with my wife having another life, it's like perfectly good day, but now I'm glued to my phone feeling like I just let down these strangers on the internet because my thing wasn't good enough. And so I rush home and I hack, hack, hack and I commit and I implement the feature that they want. I come back and I say, hey, look, I spent all weekend on this, could you review it? Does this suit your needs? And then what happens at this stage every single time? I never hear from them again and that makes me sad. Why does it make me sad? Because I just took a thing I loved and I made it slightly worse by doing work for free for people who don't care, who might not ever use it and now I have the responsibility of maintaining that edge case or that branch of my code forever. So you chat the happiness over time like I was saying. And late adopters tend to have this effect of reducing how much happiness I get out of my projects and the point where I like, if you go on my GitHub profile after this and you find any repo that's more than like a year old and you want to adopt it, please do because I'm more than happy to get rid of it. Another category of people who take away our happiness are trolls, right? Remember, open source maintainers are not rock stars. Sometimes they look like it. And I think the reason that we tend to put them on that pedestal is because like a lot of open source maintainers have tens of thousands of GitHub followers. They seem pretty famous. And sure, I think we'd all admit that like even if you have a lot of followers, you probably have a couple of trolls but it's not that big of a deal. But remember like, almost all of the communication that we engage in online is asymmetric. That means like, we have no idea just from looking at that maintainer whether 60% of the people talking to them are actually people trying to give them a hard time or antagonize them. So when a maintainer quits and it's because of trolls, like often we're all surprised, like I don't get it, everyone loves that person. Seth Vargo actually left Chef, the company and Chef the open source project because of this. He wrote a really beautiful blog post about just like how trolls sapped all of the joy from his working life. And that's really sad. So trolls subsequently, you know, reduce the happiness further. And it's this point where maintainers are usually like the cry for help. Hey, I'm burnt out. Could somebody help me maintain this? Put up a little notice. Hello, is anybody there? But this is so late in the game. All those early adopters who could have been part of a community are long gone. The project's probably hard to maintain at this point. And this is exactly how projects die. So open source projects, I think that they tend to survive when the community that grows around them grows in proportion to their usage and their popularity. But I also am very keen to like worry that if companies are only consuming open source and they're not authorizing their people or encouraging their people to give back, I love this quote that Steve pulled up from Hacker News that many open source projects are a sort of corporate welfare. You know, what I think that we should all be doing is encouraging businesses that like preventing the projects the tools that we're building our businesses on, preventing those from dying is actually a pretty good, you know, risk mitigation strategy. It does make really obvious sense. And it's our job to convince, is it, that maintainers tend, you know, that open source engagement is a good thing. Let's talk a little bit about trust. So open source obviously requires adoption. You know, it's all optimized for it. And adoption requires getting somebody to trust you. So when we talk about open source and trust and dependencies, you probably only really conceive of your dependencies free application as the ones that you declared. That's explicit trust. But everything underneath the surface of that iceberg is implicit trust. We're implicitly just trusting that those dependencies sucked in good dependencies underneath them. And as a library maintainer, often, you know, like we don't even think about this explicitly, but you might ask me, like, how do we get people to trust us? The answer, of course, is marketing. And looking at marketing over time at open source is sort of a worrying trend. First of all, let's like look at Linus Torvalds' announcement of Linux in the early 90s. This is the Linux user group mailing list. And you can see he writes a handful of paragraphs here. But consider it, there's no catchy name. He doesn't name the project. He makes a self-deprecating remark that this is just a hobby. He goes totally off message and says it just supports one little hard disk. Linux, the thing that like most of the servers in the world are running, you know, if he released that today with the same kind of marketing message, you know, it wouldn't have even made the front page of Hacker News. That should make us pause. About a decade later, the AMP project is another good example. This is AMP's homepage still today. So you can see they got a logo. They've got a whole bunch of website stuff that's really neat. They even had a mission statement. And then they had foundation affiliation. Now like foundation affiliation, all this stuff you can see, it's just trying to confer as much trust as possible. Trust me, I'm safe. It's okay to adopt me. So the more dependencies that we have means that we have less time to vet each of them. And as we've gotten through Ruby and now NPM, as we pull in more things, we can't get through all 15 links about each individual project's mission statements. So we have like the canonical GitHub marked down read me, right? And if you look at these, there's a quick intro and then some quick, easy to follow steps and usually some mostly green badges up at the top of like our things passing. And that's what we use to judge whether or not we can adopt something. And it's only gotten worse because now a bunch of companies like Google and Facebook and so forth are sponsoring open source projects. So like this is a Google's Yeoman project. And here you can see that there's like a diverse group of engineers building a rocket. It's got gradients. It's got an authoritative tagline. It's got a one liner and then a walkthrough tutorial thing. It can generate a thousand different types of projects which is terrible, but a separate talk. So all of this is just optimized for making easier and easier for day one of using any dependency with no concern at all for day 1,000, whether that it's like because maybe you follow somebody like a TJ Holloway Chuck, a really prolific author and you're like, I use his modules. And so I know that they're pretty good or maybe you look at how many stars or how many forks a particular project has. Maybe you look at the type, the flow of activity on GitHub or how many times it's been downloaded even though it's totally arbitrary. Even semantic versioning I think plays into this because somehow we as a civilization survived the last 40 years with totally ad hoc versioning. Why is it just in the last few years that we've all become such sticklers about this very specific versioning scheme? It's because we don't have time anymore to learn your silly versioning scheme. We need to know at a glance, is this safe to install and is this safe to upgrade? So all of that was just about explicit, you know, dependencies. We don't really even think about transit dependencies. And I just caution us to say like, the more people you're explicitly trusting, each dependency pull is gonna pull in an average of five other dependencies, you're implicitly trusting a whole bunch more. As we talked about marketing, remember it's not that marketing's good or bad but it's important to recognize when you're being marketed to. So that like, if you just never even conceive of it, you may well be led astray, right? By tempting marketing messages, promising something they can't deliver. Let's talk a little bit about what it's like socially and where I think things are headed. So first of all, all of these stick figures in this slide deck are a lie, right? Because what they intimate is that open source is a thing that happens between humans in real life. Of course, that's not how it works, how we actually communicate is email and GitHub issues and Twitter, all of it asynchronous text. So for most intents and purposes, we're no more than an avatar, a username, some emoji sometimes, and text on a screen. Evie, really this interesting tweet and I wish this didn't resonate with me but it really does, it's effed up that a lot of modern quote unquote discourse is optimized for whoever has the fewest feelings and the most free time. So when you're operating online, whether you're working remotely or on open source specifically, whenever you feel a sense of uncertainty between people or ambiguity or disagreement and especially if that starts to lead towards simmering disdain, email is probably not the best solution. I like to do, my policy is as soon as I feel uncomfortable with any engagement online, I try to pop up to a higher fidelity channel of communication, whether that's real time chat or if that doesn't work, we can always try a voice call or if the things I'm saying are making you cry, I can see you cry on a video chat and then we have this beautiful concophony of conferences everywhere, it's probably not impossible to actually meet up in person. So, the other reason that this strategy is great though is because it's terrific troll repellent, right? Where do trolls get their power, anonymity and a perceived lack of consequence? So if somebody's antagonizing you and you say, hey, let's have a Google hangout about it, suddenly they go away. Pro tip. Another thing I'd like to exist is I would love our tools to push us towards higher fidelity communication. So if what if we're in our GitHub issue thread, what if it actively encouraged us to start a chat? Gitter is a tool for chatting in GitHub projects or build a live example with JS bin in line right from there or start or schedule a pairing session with Screen Hero or something. So many like, I've seen like 30 post issue threads that I've engaged in go on for on and on and on and we can't reproduce and we can't figure it out. And then one of my buddies at test double, Dave Moser will be like, hey, I'll pair with you and then 30 seconds in and you're like, oh, you're just doing this wrong. And then they fix it. I wish that our tools were encouraging this. So this talk is really mostly just like, please make stuff like this guys, thanks. So what's the future hold? Where are we headed? So I kind of, I told you Bill a good saying that awfulness is piling up and that it's gonna get worse. So if we're here and it's gonna get worse, it's only fair to wonder what does this look like? I was stewing on this last year as Gogarucco was happening and I saw this quote come across the wire from Yehuda. Rust, the programming language, enables a whole new generation of high level programmers to write systems level code. And at first I reacted like, oh, good thing of all the instability and the dependency nonsense of our high level code. Why would I want that in systems? But the more I thought about it, I actually thought that this might be a good thing. I wanna talk about that. So if you think of innovation over time, originally of course we had low level, like close to the metal systems before we had high level ones. So most of the innovation and opens were started there but it eventually started creeping up. And then what I think of as like the last 15, 20 years, a lot of that's been focused on web development primarily. So yes, we've had a terrific run whether it's GitHub or all those dependency tool frameworks recently, but very recently you start to see a lot of that get ported back to system stuff with Rust and Go and all of the cool embedded robotics stuff that we saw this weekend. So if this is today's dependency culture and we're building tools, new tools that are like systems level stuff, how is it gonna translate? Are we just gonna cargo cult it? This is the thing that I was pondering when I started talking to some of my like aerospace engineering friends. And they remind me all the time that embedded in real time systems have grave consequences. What's the worst thing that could happen if you build a web app and it blows up? Healthcare.gov is a good example. It blows up and what does that mean in practical terms though? It means like people can't sign up for new health insurance policies that are like three to six months out. It's really awful. What's the worst thing that could happen if you're a systems programmer and it all blows up? People will literally die on the table. So it's just an order of magnitude difference in how we approach fault tolerance. So when I talk to my systems friends, they tend to convey it as adopting any dependency is really outsourcing our understanding of how to do a particular task. So if you think of it that way, layering over our application and any given dependency, yes that dependency in that shaded region is doing a job for us, but anything that it's doing that we don't understand, now we're incurring something I like to call understanding debt. And typically in high level web applications, we're used to understanding debt, but we don't give a name to it because we can pay it down pretty quickly by iterating rapidly. But of course, if you can't iteratively release what you're doing, then basically outsourcing a bunch of your understanding to a bunch of dependencies is probably not a good idea. Because if you compare a hosted system versus an embedded system, hosted systems are centralized, embedded ones are fabricated, shipped, and then gone. Hosted systems tend to have pretty short lives, but embedded ones might be ready to live 30, 40 years. Hosted systems are normally staffed by the engineers who made them over the course of their life. That's not true of embedded systems where they might just be an RMA or support process. Hosted systems usually have more than enough memory and CPU to be able to incur the cost of inefficient dependencies. But very often, embedded systems have to calculate under very, very tight resource constraints. And of course, hosted systems being connected are able to patch themselves readily, continuous delivery, all that. But a lot of embedded systems may have no network connectivity at all and no ability to be patched. Like shell shock, internet of things, that stuff is really more grave in embedded. So naturally, easy to iterate hosted systems, easy to pay understanding debt down. Much harder to iterate embedded systems. Maybe we shouldn't have so much understanding debt. So if systems engineers need a deeper upfront understanding of what gets built, I think it's important for us to visualize it. So if we have a web application on one part and landing gear on another in terms of software projects that we're doing, you really only need to buy on a video chat about how browsers work to build any web application. Your code does a little bit of domain object stuff on top, but it only really needs to understand its context as well as to understand the HTTP lifecycle, I guess. But you might need to know a lot about how planes work, about how very specific conditions and wind and temperature and all sorts of stuff that's specific to that model. So if we just took the design that we're used to of a thin domain layer with a bunch of dependencies underneath us and cargo call that over to systems, that introduces this entire danger zone of stuff that we don't really understand but that we really ought to in order to attain the level of fault tolerance that's appropriate. So what systems engineers typically do is they write a lot more of their own code or they actually have a process called qualified tools where they qualify rigorously and prove that their dependencies do what they're supposed to do. And if we were to try to do that, it would take literally like man years, right? To qualify something like Angular or Ember or React on our own as an individual engineering team. So keeping in mind that most open source tools are just a product of web development and you look back at this chart, sure, if this is today's perspective and this is like where we're developing a lot of similar tools like cargo for Rust and whatever's happening in Go, originally I was worried about cargo calling down but now I'm actually kind of excited about them together introducing like a new and broader perspective and conferring a little bit of that cautiousness and a little bit of that emphasis on understanding back up to the web. And that's my hope of where things are gonna go. So we covered a whole bunch of ground talking about dependencies, what it's like to be a maintainer, a little bit about marketing and trust, a little bit about the social side of things. Covered a lot around today. I talked really quickly, hope you all followed. I want to part on a positive note. I think open source can be way better. I think we can all do a better job encouraging our companies to take responsibility, audit at least what they use, look for bugs, contribute back, help strengthen, audit the security of the stuff that we're using. Startups, I feel like I could often benefit with a little bit of cautious wisdom and say maybe we should try to understand the stuff we're building a little bit better, move a little bit more slowly or if we don't have time for that and you just gotta get something out the door then be willing to burn it all down and rewrite version two from scratch. I like to call that the slow code movement. It's an excuse to use a turtle emoji. And maintainers, this is a two-way street, right? So I think maintainers on one hand need to be much more aggressive about inviting others to join them early on in the life of a project. But it's also our responsibility to kind of engage back. When we have time, when we really like something, offer up, hey, how can I help? Even when there's nothing that somebody could realistically do to help me maintain one of my libraries, I absolutely love to hear that. So if nothing else, you'll make somebody's day. So again, my name's Justin. My contact information, TestDouble is a digital agency. We're all distributed, we're consultants. So if your team might benefit from having some experienced engineers to work alongside you, please give them a touch. We're always looking for new cool project work. Like everybody else in the world, we're also hiring too. So if you're looking for a new gig, just email us at joyan at testdouble.com. I've got a whole bunch of cool TD stickers. If your friends don't know what TD is, it just looks like table cell. But if you're in the know, it's real cool. And then I think I'm gonna check down to Redeguana tonight. Tenderlove made me promise to go eat there. So if you wanna meet up with me and chat, or if you've got any questions or anything, I think I probably went over. So let's do that there. Yeah, thanks again.