 I had the privilege of building the AWS CDK at Amazon. And as I said, you know, we weren't super intentional about creating the open source community around it. But in hindsight, I feel like we were able to distill some lessons. The first one, we called it build an open team. And what I mean by that is that you ideally want your core team to be the core of the open source community. So there's this continuous move between the core team and how they work and how they communicate and the tools that are using and the workflows that you're using and the open source collaborators and the community that's involved. And so for example, one thing that worked out really well for the CDK almost coincidentally and more intentionally in Winglang is that we have a distributed team. Like we have people from around the world within the core team from day one. And the fact that there's a distributed team forces us to use distributed team, distributed development methodologies, right? Like so we use GitHub and we use pull requests and we use RFCs and we use Slack and we use asynchronous communication. And those things really enable contributors to have equal opportunity to contribute, right? Like when a contributor submits a pull request, it's the same way, it's the same thing as a core member submitting a pull request. There's no difference in how we work with core members and with contributors. So that was, that's something that was very effective both in the CDK and this in Winglang right now. And again, I think those methodologies are also really good practices from a software engineering perspective. So it's well aligned in that sense. So that's one lesson. The second lesson was to be explicit about what do you expect? Publish design tenants, publish code of conduct, publish culture documents, right? Like what are the values that we have as a community? Publish expectations about how you want pull requests to look like, how you want issues to be created. And sometimes it's neglected to just be explicit about those things really helps elevate the bar on the quality of your open source project. And people really are looking, contributors are really looking for this information and it's really making it easier for them to contribute if they have that information when they come and contribute to the project. So that was the second lesson. The third lesson was about understanding why people come to contribute to open source projects. And it's actually not that trivial, to be honest. I think a lot of people are misunderstanding something. What's the motivation of someone spending some of their own time or private time contributing to open source? And what I've learned is that the primary reason people come to contribute to open source, the reward that they're looking for is the contribution. And that's not, it almost sounds weird, but people don't come to get swag, right? And they don't come to get fame, right? Like they come because they wanna contribute, they wanna learn, they wanna, it grows an engineer. And the more you understand that, the more you're able to give them what they want. Because for example, that could be, that's something that I've ran into a lot is like, when you get a pull request from a contributor, sometimes your initial reaction is like, oh my God, this person's actually contributed some time for my project. I'm just gonna prove this pull request and I'll fix all of the things later. Maybe I don't agree with some of those things, but I just wanna get that contribution and encourage this person to contribute. But I found that it's actually the opposite. Opposite in the sense that I found out that actually if I insist on quality and I send comments and I say, you know what, maybe this design needs to work, you need to work a little bit on that design or maybe add some more testing or document more what you're, like if you're actually insisting on higher quality bar for this pull request, then not only you'll get a pull request that's better and you're gonna keep your code quality high, you're gonna get a better contributor eventually. And contributors really, really appreciate you helping them improve their coding skills, right? Like because that's why they're there, they're here to learn and grow. And then obviously their next contribution is gonna be at a higher quality, right? And so you create these long-term relationships with contributors and you have to think about them this way and it really changes how everything, right? Like it changes the dynamic of the project. And last thing, it's gonna be short, I promise, is to lead with love and understand that people are people, are humans and they need to feel a sense of belonging and a sense of identity. And if you create that environment in your open source project, then you create strong communities. You create a foundation of people who really come from an emotional connection to the project and more than just from a functional connection.