Matt Klein: I thought that maybe some small companies would use it, right? Not in my wildest dreams did I think that Amazon or Microsoft or Google or Apple would end up actually using it, because I just figured, well, they would have some solution in-house, and why would they actually bother? Eric Anderson: This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Eric Anderson: Matt Klein is with us here today. Matt Klein is the creator of the Envoy proxy project, and we're going to go into details on that. Matt, maybe to kick us off, could you tell us how Envoy proxy got started? What's the impetus for the project? Where did this all begin? Matt Klein: Sure. That's a fun thing to think about at this point. So yeah, so I've been working in networking and distributed systems for probably about the last ten years now. In that ten-year span, I worked on EC2 within Amazon, on networking. From there, I went to Twitter. I spent a fair amount of time working on Twitter's front proxy. So I built Twitter's proxy that, at that time, was terminating Speedy H2, H1. So at Twitter, I was exposed a lot to different edge proxy concepts, but, at the same time, I was also present for a lot of the work that was going on in the service to service networking space. So, obviously, Twitter has a very powerful library called Finagle. So I was definitely aware of the different work that was going on there. Matt Klein: So when I left Twitter and I came to Lyft, Lyft at that time had a large monolithic application written in PHP. At the time that I joined, there were probably 20 or 30 different Python microservices. I have obviously talked about this a lot, but Lyft was having very common problems with their microservice deployment. They were having problems around understanding where different things were actually happening, so where the problem's happening within the network, within the application, and we were in a situation where we had developers who we were basically telling to deploy microservices, but those developers did not trust the microservices deployment. Matt Klein: So we were in a pretty bad situation, where we had a bunch of microservices. We had this monolith. We had developers who didn't want to write microservices, because they didn't trust the network. They didn't understand how to observe it. They didn't understand how to fix problems. So then they wanted to write their features back in the monolithic application. So we were in this split world, which was not great. Matt Klein: So just having experienced what happened at Twitter and obviously seeing what other people were doing at different companies, I think we knew at Lyft that we needed to head in a direction such as having an edge proxy to do routing. Then we obviously had to start figuring out how to do service to service communication, and we had to do that in a consistent way. Matt Klein: At that time, we already had PHP at Lyft. We got obviously have Python. I think there already might have been a Java service. Even very early on, we were starting to think about, "Are we going to write more services in a language like Go or Java or something else?" Matt Klein: So that brings us back to the second common problem that most people have, which is once you go in and start to try to solve some of these problems, you're faced with two different solutions. You can figure out an out-of-process proxy solution, or you could start writing libraries. I think just having seen the pros and cons of the library-based approach both at Twitter as well as other companies, I pretty strongly did not want to go with the library-based approach, and that was really mostly around, one, having to support it in every different language, which becomes a huge maintenance burden, and two, for those of you out there that have tried to upgrade libraries, that can be a very painful thing when you have lots of different services. It can take months and months and months. Matt Klein: So I think that there's some pretty big downsides to the library-based approach. So that led us to thinking, "Well, okay, so we're going to do an out-of-process proxy approach." Obviously, once you go down that path, there's lots of different options. You could build something on top of an existing library, such as Finagle or Netflix's Hystrix, or you can take an existing proxy, like HAProxy or Nginx. Matt Klein: I think lots of people have asked me, "Well, why did you go and build this thing from scratch? Why didn't you use an existing proxy?" I think the answer to that is I had been doing this networking stuff for quite some time. I had a lot of exposure to HAProxy, as well as Nginx. I was pretty convinced that it was important that we went for a very high performance, low latency solution. So that meant that we didn't want to do something in any language like Java. So that led us, at that time, in 2015, with a native code solution. So that pretty much was, "Should we use Nginx, should be used HAProxy, Or should we build something ourselves?" Matt Klein: I'm going to be honest in saying that at Lyft in 2015, definitely had some conversations that went along the lines of, "Well, let's just build something in Python. We can do it in Python, and then if it becomes a problem later, we can swap it out." So there are definitely conversations around did it make sense to do a very high performance solution, or, given where Lyft was at the time, should we do something a little bit faster, with possibly lower perf? Matt Klein: So, at the time, this was myself and, obviously ... I mean, the company when I joined I want to say probably had only 70 or 80 developers. So it was a pretty small organization, and of that 70 or 80 people, they were probably the only, at that time, I'm guessing 10 or 15 people working in what we would now call dev ops or infra. So the set of people that were making decisions back then was quite small. Matt Klein: So we had a lot of conversations around, obviously, do we use an existing system that we can build on? Do we do something in Python, or do we do what ended up actually happening, which was to build our own proxy? To be totally honest with you, in hindsight, I think it's fairly incredible that Envoy actually came to be in that environment. I think that Lyft was willing to give me a large piece of rope with which to hang myself, and that was a great experience. I think that it definitely could have gone different ways. I think people could have been very adamant that we're not going to build something from scratch. We should like do it with Nginx or HAProxy and build some Lua plugins, or we should build it in Python and then swap it out or something like that. Matt Klein: I think primarily based on my prior experience, the fact that I had built something at Twitter that was kind of like this, so this was a little bit of a V2, I was fairly confident that I could do it relatively quickly, and just having dealt with those other solutions, I was fairly confident that there was a need within the industry for a more modern proxy solution, something that was built more for I guess now what we would call the, quote, "cloud-native space" or will be call now the service mesh space. But those things didn't really exist that much at that time in early 2015. Matt Klein: So I was definitely given a lot of rope to hang myself with, as I said, and we went off in and essentially started coding. Of course, it wasn't entirely from scratch, right? I mean, it's like I was building on knowledge from what I had done at Twitter. So it was empty files, but I knew what I'd done wrong there. I knew what libraries to use and what libraries not to use, and we were able to get something into production in only about three or four months. Of course, that first version was a very simple thing compared to what we have today, but I'm a huge believer in not doing big banks. I think it's very important to build something small and then essentially take it from there. Matt Klein: So we started with a very small feature set within Envoy. We actually rolled out from an edge proxy perspective first. So that was replacing our existing edge proxy, which was the Amazon Elastic Load Balancer, and immediately just the observability that we had from sticking Envoy there at that time, and that was only an H1 solution. We weren't even terminating TLS. It was a very simple thing back then. But even the basic version, just getting out different timing data, different dynamic response code data, different types of logs, that was very, very valuable. Matt Klein: Then from there, it just grew organically. We were having a bunch of issues with MongoDB at the time, and so we decided, well, we were running HAProxy next to our monolith to help talking to MongoDB, but there were issues. So we swapped that out with Envoy. We ended up writing a protocol parser for MongoDB to get really interesting stats, and that was the beginning of our service mesh. We had our edge proxy talking to our monolith with Envoy running as a sidecar. Matt Klein: Then the rest is pretty much history, in the sense that we just kept adding features. Then we rolled out Envoy everywhere. Of course, I'm greatly simplifying what actually happened, but that's pretty much it. Eric Anderson: This is awesome. So from the beginning, it sounded like you had some ambition or belief that this could be bigger than Lyft. For example, you mentioned kind of the cloud-native community. Was the intent that this would be an open source project and that there may be users outside of Lyft fairly soon after launch, or what were you thinking around that? Matt Klein: Yeah. I mean, having built something like this back at Twitter that wasn't open source, and, to be honest, I'm very happy it's not open source, because it's not very good, but I think I was definitely aware that there was a desire to use something like this. Matt Klein: Now, what I will say is that I vastly underestimated the overall desire for this type of solution. So we had always planned on open-sourcing it. I think even from the beginning, Lyft had had the perspective that if we were going to invest this many resources into building something like this, we should open source it. Matt Klein: So we started development, I want to say, in May of 2015, and we opened-sourced in, I think, September of 2016, so a year and a couple months, and before we went to open source in 2016, we started doing a little bit of a road show. So I went and I talked to a couple of companies that were like Lyft, so similar type of size. I actually forget now who I talked to. So maybe like Yelp or Stripe or Slack, companies in that type of growth period. Matt Klein: It was a very interesting conversation, because I think every company that I talked to, and this was probably in July or August of 2016, every company that I talked to, they were very happy. They were very receptive. They thought that what we had built was quite cool. But what's very interesting about a solution like Envoy versus some type of product that you can just try out, you can't just try out Envoy. It's not something that you can just bolt on. It's a fundamental change to how you run your infra. Matt Klein: So from a smaller company perspective, I think lots of companies were growing interested. They were very fascinated, but, not surprisingly, now they said, "Well, this is great, but our existing solution kind of works. We would love to do this, but we just don't have the resources right now." So when we open-sourced in September of 2016, I was a little sad, right? I was like, "Oh, it would it be so great if we had gotten someone excited and if someone launched with us or something like that." Matt Klein: So when we opened-sourced in 2016, like I said, we hadn't had any real uptake or traction before open-sourcing. So it was a very organic thing. I didn't really know what would happen. My dream at the time was, "Wow. If one of Lyft's peer companies, like Slack or Stripe or something like that, if we could just get one or two of those companies to use Envoy, that would be an incredible success." Matt Klein: Within weeks of open-sourcing, and I can't go into deep detail, but I was talking to tens of engineers at Google within weeks of open-sourcing. I was talking to people at Apple, and I was talking to people at Microsoft. I was talking to people over at eBay. It was incredible to me how quickly some of these larger companies showed up. At that point, I really realized that I had underestimated the desire within the industry for a more modern proxy, so a proxy built like Envoy from multiple angles, so built in a modern programming style, built from an API first aspects, built from an accessibility perspective. Matt Klein: I think people, especially at the larger companies, they had been trying to do various things bolted on top of HAProxy and Nginx. I think just seeing this new solution and seeing that it was already running in production at Lyft, so it had some basic level of testing, of course, I think that really excited these companies, and that was really the beginning, I would say, towards the end of '16 and early 2017, when things really started blowing up. Google just became super involved, and that's been a fantastic relationship. Matt Klein: Then as these larger companies that had deeper needs for this type of solution came about, it was clear that they had the resources to actually put into developing it, to actually deploying it. Then throughout 2017 and into this year, at this point, all of Lyft's peer companies, like Stripe and Slack and Yelp and everyone, right, I mean, they're all basically using Envoy now or they're in final testing before production deployment. Matt Klein: So everyone at this point is pretty much either using Envoy or is planning on using Envoy. But it's been an interesting evolution for me to see ... It did not happen how I thought it would happen. I thought that maybe some small companies would use it, right? Not in my wildest dreams did I think that Amazon or Microsoft or Google or Apple would end up actually using it, because I just figured, well, they wouldn't have some solution in house, and why would they actually bother? Matt Klein: But it has turned out that Envoy has been very compelling for companies of pretty much every size. It was the large companies first, then the medium companies. Now we have probably over ten or more startups, right, that are building products on top of Envoy. I think that that's how Envoy will really go to the masses, if you will, and I think for smaller companies, I think a lot of people are going to end up using Envoy, but they're going to use it via other products. They're probably not even going to be aware that they're actually using Envoy. They'll buy some other product, and that product will be built on top. So it's been a pretty amazing journey. Eric Anderson: Super amazing journey. It sounds like the launch, of course, was kind of an inflection point for you. What are the mechanics of the launch? I mean, in order to get the attention of Google and others, was there fanfare, or was this kind of just released on GitHub? I imagine there was a blog post. Matt Klein: Yeah. It's funny to actually think back through this. I've said this to many people recently. If I look at the last, say, two years of my life or two years plus a couple of months, I feel like I have not learned a single thing technically, but I have learned so much about just what it takes to build a vibrant open source community, and it is not easy. Matt Klein: The best way that I can describe it is it's like starting your own company, and you're doing all of the roles, right? You're like the chief marketing officer. You're the PR person. So yeah, you're sitting there, figuring out how to use Twitter, blog post, conferences. On top of that, there's smaller things that are super important that I think a lot of projects don't spend enough time working on, but end up being critical, for example, documentation. Matt Klein: Before we opened-sourced Envoy, I remember I actually took an entire week where I stayed home. I called it a docucation, and I spent like 50 hours just writing documentation. I think that's one of the things that caught people's eye very early on, and that's kind of what I'm saying, is that there's a lot of marketing to building a larger community like this. I think when you make an announcement, the first thing people do is they're going to go to your webpage. Does the webpage look professional, or does it look bad? Then they're going to click on your documentation. Is there documentation? Does it look like it's well-written? Is it comprehensive? Matt Klein: So although I had never done this before, just from seeing other projects, I had a pretty good idea of what would be required to actually, hopefully, make it successful. So before launch, we spent a lot of time doing documentation, got someone to make a logo, actually made a webpage, got set up to do Twitter, started to think about speaking at different conferences and meetups. Matt Klein: So a big part, again, of that late 2017 period was me being a cheerleader, just helping whoever came along. There's lots of interesting stories just around particularly in late 2016, when Google was very, very interested in Envoy. At that time, it was almost what I would envision ... I've never gone through the process, but it was almost like, I think, going through an acquisition. You just had tons of Google people just asking me questions around, "Why does it work this way? Why does it do that?" or doing performance testing and load testing and then asking me, "Why is it this way?" and coming to me with bugs and saying, "Well, I tried this, and it's broken." Then I would turn around and fix in four hours or something like that. Matt Klein: So it was very much, at that time ... and I think if you really go back, it could have gone either way. I think at the time, Google was evaluating whether to build Istio. I think they had planned on probably using Nginx. I think Envoy came about, and there was a bunch of pros for that. So I think that sparked a very interesting conversation within Google around which technology to actually build on. That's when that whole kind of, "Should we use this random technology from Lyft that's mostly written by this one random person?", right? That was a very interesting and stressful time in my life. It was fun, also. Matt Klein: So that's a long-winded answer to your question, but I think that, again, there hasn't been a lot of technical stuff since we open-sourced, but I think we have gotten a lot of feedback that we have built a very welcoming and a very vibrant community, and that's been very important to me. I will say that that takes a tremendous amount of effort, just setting the right tone for the overall community, making sure that people treat each other with respect, that people are nice during code reviews, that people have very civil discussions when they're actually designing features. These are things that take effort, but I think that that partly comes from the top, and I think that setting that type of tone, it has percolated throughout the community. Honestly, it blows my mind sometimes now to just see people that step in and help people answer questions and fix bugs. It's been a pretty amazing journey. Eric Anderson: Certainly. I love the image of that, Google feeling like an acquisition situation. At this point, I imagine Envoy proxy feels like your baby, in a sense. Although Google is not actually trying to acquire your baby, were there any anxieties around, "What's going to happen? Is this going to get derailed in some way?", or was it mostly positive vibes throughout the whole thing? Matt Klein: Well, so very early on ... So, again, this is in early fall of 2016. I'll be honest. I was definitely concerned just about if Google came on in force, would they force changes in product direction? Would we get mired in lots of discussion and then not be able to move fast? I'm going to be honest. All of the people that I have worked with at Google on Envoy have just been absolutely fantastic. They're incredible engineers. They're super pragmatic. The project is absolutely better for having them join. Matt Klein: So I think I was definitely fearful, but it's worked out so well. If we go back again to that time, it was obviously amazing to get resources from a company like Google, but now, right, it's like we have people from Apple who are maintainers. I mean, we're getting commits all the time from tons of different companies. So, at this point, of course, I think if you went and you go through the commits, I'm sure the majority of commits are probably for me, still, but the folks at Google have done incredible work. But I guess my larger point is that now we get very sophisticated PRs, not just bug fixes from lots of different companies. So it's a true multi-company effort now. Matt Klein: I think, again, that's just what has been so amazing about this, is to see it grow from a Lyft thing to a Lyft and a Google thing to a Lyft and a Google and an Apple thing to now you could just go through the different commits. Again, I don't even know. I mean, we're getting very sophisticated stuff from Square, VMware, just all types of companies. So that's just fantastic. Eric Anderson: You wonder in a project, there may be one motivation to just get everyone to use it. It sounded like at the beginning, you just were excited if a company wanted to use Envoy, and then there's this other kind of goal maybe around the project to get contributors. Was that ever something that you were excited to bring in, more contributors, people who could add this feature or that feature, or did that kind of just happen organically? Matt Klein: It's a combination of organic, but it's what I was talking about before, is building a larger community, it just takes a lot of work, right? So cultivating maintainers or encouraging people to keep fixing bugs and helping them grow and learn the code base, that all takes effort. But I learned very early on, particularly in late 2016 and early 2017, that was probably the most stressed that I've ever been in my entire life. I mean, just the project just blew up, and just the influx of people that were coming in with either questions or PRs or all of these things and the stress of getting everyone on the same page of what does the code quality look like and are we all aligned, and that takes a lot of time and a lot of effort. Matt Klein: So if I look into the spring of 2017, there's all this community stuff going on, and fantastic experience, super stressful. That's when all of the venture capitalist start showing up. I obviously wrote an entire blog post on this, but that time was made more stressful because there's all of this community building. The project is blowing up, and then I don't want to say harassed, but, I mean, I'm getting a lot of inbound from VCs. So trying to balance all of these different competing forces, particularly in the first half of 2017, was very, very difficult. Matt Klein: So that was a very stressful time in my life, and it was hard to, obviously, think through all of the different competing ways that I could spend my time, all of the different types of outcomes, but, ultimately, if I look back to early 2017, in which I was still intimately involved in almost every PR that went in, because people weren't familiar with the code, I just had be there to help, whereas today, we as a group have cultivated a set of maintainers and a set of contributors who make changes to the most complicated parts of the code base. Matt Klein: So I went on leave for a month a couple weeks ago, and so this is in August of this year, and the first time in a long time where I literally ... I did not open GitHub. I did not check a single email. I did not open Slack. I didn't do anything for one month, and I had just had zero concerns, because I feel like we have built that larger community. We have that base of maintainers. Everyone generally sees eye-to-eye on design and code quality and all of those things, that, again, I don't want to say that I've totally made myself useless, but I feel like the project is now self-sustaining. Matt Klein: I think that's something that I've worked really, really hard for, and I think a lot of people out there, when they look at open source or when they think about what a job like mine is, I think a lot of people think that it's this super glorious thing, right? Like, "Oh, Matt, you started this open source project and it's fantastically successful. This is great all the time." It's really hard work, really, really, really hard work, doing code reviews for seven or eight hours per day, or just, again, cultivating that larger community, trying to make sure that we have enough maintainers, that we have enough people doing support. It's like building a company, but it's like building a company in which none of the people actually work for you, right? So it's like open source is, in some ways, total controlled anarchy. So trying to make all of that work is very complicated. Eric Anderson: I imagine you're getting inundated with people who ... Some are just asking for help or answer a question or "Here's a bug," and then you have others that maybe look like they could be potential maintainers in the future. They're offering guidance and sending you lots of PRs. How do those maintainers emerge? I imagine you're eager to find people you trust, that understand and can share the vision, and you can offload work and components to in a super busy time. Matt Klein: It's definitely an evolving process. So when I was initially trying to build the larger community around the project, anyone that asked any question, right, whether it be in GitHub or email or Slack, I would just be sitting there, answering any question that anyone asked. That was important during the early phases, because that's how you build one of these things, but that's not scalable. It's not scalable from a stress level for me. It's not scalable from a larger project perspective. Matt Klein: So I don't have a firm answer for you, and, honestly, one day, I may end up writing an entire book on this, because it has been such a journey, but it's trying to find the right balance. So it's trying to look for people that, maybe just out of fun, were doing a couple of PRs here and there, and I'll just see these PRs and look at them and say, "Wow, this person is fantastic. They just did all this work, and they didn't ask any questions about it." Then I'll do a little Internet stalking and try to find out how to contact them or who they are, and some of that doesn't lead anywhere, because some people just do a PR because they need it for their job or they're just doing it for a hobby. Sometimes it does lead somewhere. Matt Klein: So there's actually this one guy named D who ... He lives in Indonesia, and I don't even remember now. He started, I think, just doing Envoy PRs for fun, probably six, seven, or eight months ago. I think maybe he was working with some Indonesian tech companies, but he also owned a bakery. It's a pretty crazy story. So he had been doing all this work, it was really fantastic, and then I just reached out. I was like, "Are you interested in potentially being a maintainer?" Fast forward now, not only is he a maintainer, but he actually works for an Envoy startup. Matt Klein: So it just shows you that that's what is so amazing to me about some of this open source stuff. It doesn't always work this way, but you do have these incredible stories of just people around the world who would just hop in out of interest, and then it leads to a full-time job, right? That's so amazing to me. Eric Anderson: Amazing. Take us now to where we're at today. It sounds like these maintainers kind of play a governance role with the project. How does kind of the project operate today in terms of governance? Then we'll shift gears eventually to where you want to see this thing go. Matt Klein: As part of joining CNCF and partly because I wanted to get ahead of any governance issues, we have set up a governance system. So we have a concept of senior maintainers and maintainers. If we have a dispute, there's a documented voting process. To be honest, we have never yet had to invoke this voting process. In general, we're very careful of who we let become a maintainer. I think we take it slow, try to make sure that everyone sees eye-to-eye. I'm not naive. I'm sure that, eventually, something's going to happen, and we are going to have to vote, but that's there. Matt Klein: I think I'm still probably looked at as the project lead. So at least from a design discussion perspective, sometimes I will weigh in my opinion, but I don't really like the benevolent dictator title, because that's not what we're going for here. I think we're trying to build a community of people that can make technical decisions, and, hopefully, we should be mostly aligned. That's what's happened so far. Matt Klein: But, like I was saying before, it's hard to cultivate that. You have to do it very carefully. To me, it's no different than building a company. You have to be very careful with who you hire. Once you hire people, firing people is very difficult, right? So I think when you build these larger communities, particularly around maintainers, the people that have commit access, it takes a lot of thought to make sure that people see eye-to-eye and have compatible personalities. Matt Klein: What is interesting is almost all of the existing Envoy maintainers have very little previous experience doing open source. Most of us are all proprietary, mercenary type developers. So maybe that's part of it, is that none of us, I don't think, really had any preconceived notions. We didn't really know what we were doing. So I think we've just kind of figured it out. But I think it's just going slow and just trying to make sure that we have the right people and, like I say, always be scaling, right? It's like trying to find people that are into it, and I will reach out to them and see if they want to become maintainers. So it's a never-ending process. Eric Anderson: Awesome. Where do you go from here? So is there a backlog of features and things you want to do on the project? Is it mostly fully baked and this is kind of maintenance and bugs? I'm curious. Are there other kind of ecosystem things you're navigating? Where is Envoy's place in the world? Matt Klein: Right. I mean, this is probably even the subject of a different podcast, but from an open source economics perspective, it's quite interesting just in the sense that one of the reasons that Envoy has been so successful is that we are a community first project. We don't have to reconcile whether, if we take a feature patch from someone, that it's going to break our underlying business model, because there is no business model for Envoy itself. That is a powerful thing. Matt Klein: With that said, the reason that Envoy is funded so highly by different companies is that companies are building products on top, right? So that's going to be control systems. That's going to be observability systems. There's no end to the number of things that can end up being built on top. Matt Klein: So what's interesting is that there's a delicate balance here where I think there's a ton that can be done within the Envoy project itself that we haven't even touched on yet, like different protocol support, more types of dynamic load balancing, adoptive load balancing. There's just tons of different things. But we don't necessarily want to go into higher level control systems or UIs or stuff like that in the project itself, because that's where it becomes complicated, because that's where some of the people that are funding Envoy development are making money. Then I think you can get into the situation of now there's portions of the project that might be competing with some of the paid offerings. Matt Klein: So that's a balance that we will have to kind of find in the future of how to keep the project community-driven, how to keep it running for all the people that actually want to use it as a foundational part of their system, but have to be careful to not spin up some part of the project that might directly compete with some of the companies that end up funding it. Again, I don't have a firm answer for you there. That's something that we're just going to have to look at as we go. But that's a very interesting balance that I think will be there. Matt Klein: But from a roadmap perspective, I think there's a lot of stuff that can be done and built in that just hasn't been funded. For myself, I've obviously written about this. I would love to see CNCF and other foundations offer full-time fellowships for people to actually work on something like Envoy full-time so that they can focus on community-driven development, but not have to work for a particular company. So that's something that I think will end up being discussed more and more over the next couple of years. Matt Klein: But right now, I think because we're just moving forward and development is really being driven by all the companies that are using Envoy for their own products, it's hard to have a roadmap. Everyone's always asking, "What is Envoy's roadmap?" Well, for a community-driven project, it's pretty hard to have a roadmap, because I don't know what people are going to end up implementing. So that's actually pretty interesting. Eric Anderson: Yeah, this is great. It's wonderful to hear your story and the story of Envoy. As we wrap up here, Matt, it'd be great if you have any kind of requests for the community or if people, after hearing this, are interested about the project, things that they can do to get involved. Any suggestions there? Matt Klein: Yeah. I think I would just say to folks out there that we have tried very hard to have a very welcoming community. So we have GitHub. We have Slack. We have all of our email addresses. We have a new developer guide. Our GitHub is up to date in terms of help wanted. We have easy issues marked as beginner. C++ is less scary than I think the Internet would like people to believe. Matt Klein: So there are lots of options for getting involved, and even apart from coding, as in every project, we're desperate for people to help with documentation, with tutorials, with blog posts. So there are so many ways to get involved. I see myself mostly as a facilitator. So people can always reach out to me. My contact info is pretty easy to find, or reach out one of the project aliases, but always happy to have people get involved. Eric Anderson: Thanks so much, man. Congrats on an amazing project, and best to you going forward. Matt Klein: Thank you. Thank you very much for having me. Eric Anderson: You can find today's show notes and past episodes at contributor.fyi. Until next time, I'm Eric Anderson, and this has been Contributor.