 How's everyone doing? Great to see. Oh, I see some great familiar faces. Hey, everyone. How's it going? So I'm going to talk to you a little bit about the bureaucracy in open source. I feel like a finance conference bureaucracy might be interesting, or you might want to leave it at work. So today I'm going to talk a little bit about me. I want to learn a little bit about the folks in the audience and your experience with open source. I want to talk about what we see in open source projects and the type of entropy we see as projects grow and go on, how to make an open source project sustainable, and then how as an individual to get involved. So as many people here, I'm sure I've been doing this for more than 20 years. I've seen the world of people only use proprietary software. We build it here. We don't use it. To the world of everyone uses open source, there isn't a company out there who isn't using open source libraries. Like mentioned before, I work at LinkedIn helping to run the front end infrastructure for LinkedIn.com. I co-founded an organization called Girl Develop It, which was kind of not my personal first entry into open source, but my first open source project that I started from the beginning. And what Girl Develop It does is it teaches adult women how to code. Girl Develop It has taught over 100,000 women how to code in in-person classes here in the US. All of our curriculum is open source. So anything that you want to learn, you can go to Girl Develop It's GitHub. You can see all the curriculum. You can contribute to it. And it's been flourishing for about 10 years now. I've been on the board of the .NET Foundation. And now I am on the board of OpenJS, which we'll talk about a little bit more here. I've also contributed to open source projects. I know a lot of folks that have started open source projects. So I feel like I have a unique view into the industry for a long time. So folks here, who here has, if you use open source in your day job, raise your hand. Is that going to be everyone? OK. I just wanted everyone to raise their hand. That's what I was doing. OK, great. I saw about 80% of you put your hand up. Have you contributed to an open source project? Raise your hand if you contributed. OK, great. That was about 15% of folks I see with their hands up. If you started an open source project, let's see hands. Oh, cool. OK. I'm going to get 7%. None of these are based in science. It's just I'm just eyeballing it. So there's a handful of you who've started your own open source projects. That's neat. Some of this may be not new to you as you think about how to make your open source project sustainable. So one thing that we've seen since the beginning. So the world of open source is wonderful and magical. And the idea is people build things and everyone uses them. And it is great. And people learn from each other. And they can build off of what other people build. And it's completely open. And that was a promise of the beginning of open source, which is something that personally got me really excited. But what we've seen over the past 20 years as projects mature and grow is something that can be a bit of predictable entropy that we see when a project starts. So this is what I've seen every time. So people have an idea. They're so excited. They're getting started. They're home coding. They're spending their nights and weekends. They're like, people are going to love this. This is going to be great. It takes a long time. They're like, oh, man, I thought going to do this in the weekend. It's a holiday. Maybe I'll get this on the holiday. It takes a year and a half after all. And they're like, I can't wait to get there. And then you get to the part where it's 90% done and you have 90% to go. You can't show anyone. You are working hard. And you're like, do I even finish this? A lot of projects die here, to be honest, where people are like, actually, I only did have a couple weekends. I'm not really that into this. And I don't even know if people are going to be using it. But often, people make it through. They release their open source project. Very exciting. That feels good. There's a how you get just from getting it out there in the world and being able to step away from your computer and be like, OK, people are looking at what I built. This feels good. This is nice. Then no one uses it. No one cares. No one thinks what you did is great. No one is really excited about you. No one's going to use it. You could have built the most brilliant thing, but no one knows about it. So it really doesn't matter. And that's sad. Unfortunately, often, when the opposite happens, that is also sad. Because now you have an open source project. People love it. They're using it at their day jobs. All of a sudden, you need to think about security. Oh my gosh, I didn't even think of security for Fortune 500. I was just, this is a weekend. I have no idea what they need. People are adding issues to your GitHub repository. People are adding 20 issues. And you're like, I'm one person. I did this to be nice. I wanted to build something to be nice to the community. And now people are demanding things of me. I don't work for them. This is annoying. Sometimes you find collaborators, which is wonderful. People that work with you. And often, this can be healthy for a while. But what ended up happening to a lot of people that build open source that I've spoken to is after they start to hate their project. They're like, I wish I never built this. This is annoying. People are mad at me. If I spend my weekend with my family, I feel guilty because there's someone in Idaho with a bug that is stopping their business from being productive. And that's really tough. And that's where a lot of project owners get stuck. And when I see them get there, I see a few solutions present themselves. So where does this code go to be sustainable? So you've built something amazing. Someone's built something amazing. People are using it. What happens now? Sometimes it dies. I've seen projects. People just say, listen, I can't do this anymore. I don't know how to move forward. This is the end of my project. Thank you so much. I appreciate it. Feel free to fork my project. Like I built something. I put it out there. Fork it. Use it yourself. But it's going to live on GitHub. I'm not going to maintain it. No longer maintaining this project. And that is a fine response. Some people burn it to the ground. I've seen people say, last year, there was a project where the maintainers started putting ads in the CLI to make money. People did not like that. People say, I'm tired of you making money off me. Send me money. If you haven't sent me money, then don't use this. I'm deleting it. And then all of a sudden, there's code in production that doesn't work. Because a library with millions of users, the owner was like, absolutely forget this. Another model. And often people think of this early. And when I see people think of this early, it's often people that are veterans to the industry because they've seen this happen. People get funded. They go to VCs. They get venture funding. Or they get acquired by a big company. We've seen recently remixes picked up by Shopify. That's really neat. What can happen in these big companies is that they have the revenue. They can pay engineers. Engineers can work on the project. That's great. That's a really good symbiotic relationship. People can have paychecks. That's nice. It's a lot nicer to be helping people with their issues when you're getting paid for it. We've seen Dino and NPM both raise money as bashings in JavaScript. And that helps them keep going. Something that can happen here is anything else. You can run out of money. That happens. And in that case, you have to make a decision. Where do I go with my project from here? Another thing is people try to get sponsorship from individuals. So there are things like Open Collective. GitHub allows you to sponsor projects and then money monthly. If it's a project that you care about, a maintainer that you care about, that's great. This can be hard, because it sounds really good. But how many people need to give you $20 a month in order to leave your day job and focus on your project? And then how many people need to give you $20 a month in order for more than one person to quit their day job and work on their project? So I think this model works. And I absolutely, I support some contributors in GitHub right now, but this is also difficult. And then the fourth option, which I believe is the best one, biased, but is to join a foundation. There's the Cloud Computing Foundation.net, OpenJS, the Apache Foundation. There's a lot out there, a lot of foundations out there that are funded by grants and sponsors that can help you with your project. And there's some reasons why I believe this is the best model. Open Source developers are developers. And I don't know if you've met a developer before, but they're not always the best marketers. Or they're not always very good at sales. Or their legal mind isn't the sharpest. When you are a developer, your skill set is writing code. And that's amazing and incredible. But often when you have a successful project, you need more than just to write code. And what a foundation can offer you is those skill sets and those resources so you don't have to think about it. So for resources, foundations have their own marketing team that can work with you. And marketing is a great way to attract sponsors, to host events, to attract contributors. People will hear about your project. It's exciting. And foundations have their own budget to do that. Legal is huge, especially when it comes to things like security issues, IP, trademark. These are all things that successful open source projects run into you. And when you just want to code on the weekends, this isn't something that you think about. And then someone comes and is suing you. There are people that just like sue open source projects all the time. Someone comes and sues you. And you're like, well, I literally just wanted to do something nice for the community. And now I have a lawsuit on my hands. What do I do? Additionally, recruiting contributors can be difficult, especially folks that are willing to work on the issues that maybe aren't so interesting and exciting. And so being part of a foundation, having that marketing, having that support, foundation leaders can help you identify where your project lacks and support people that come and can help you work on it. As well as getting sponsorships, foundations work directly with big companies that want to put money into open source, that think about we're using all these libraries, how do we support? The foundations come along and they say, great, become a part of this foundation. Here's how much we need from you a year. We'll work with you on the board. And that enables a lot of these projects to get sponsorship from the big companies. And then security audits and things like that. Those are very important. And often something as an open source owner, you can't afford or you don't have time for or isn't your specialty. And foundations can think holistically with the whole community in mind. Code of contact enforcement, things like that. Again, you're not HR. You're not a person that thinks of, how do I have difficult conversations with people that are toxic in my community? And foundations are a great way to help with that. So as a person, how, why, where should you get involved? If this is at all interesting to you, helping open source in ways that might not just be coding, this is how I got started. So there's so many different technologies to work with. Are you a Java developer? Do you like JavaScript, databases, anything that you can think of, there's an open source version of it in technology. And you can get involved in it. There's a project out there. So the projects that you use every day that you love, they need help. I promise you, none of them are turning feet full away. None of them are like, we're good, thanks. Like, people are looking for help. And you can focus on what brings you energy. And that's what really brought me to the bureaucracy of open source. Because for me, I don't love bureaucracy. That's not me as a person. But what I learned, so I've been doing this, like I said, for 20 years. 10 of that has been in an IC. 10 of it has a manager. And what I've learned as an engineering manager is that I love helping to scale people systems. I love enabling engineers to be their best selves at work and helping them be successful. Because that is an amazing system to optimize and be a part of. And thinking about open source, I think about, sure, I can identify one project, get involved, and help them. But what if I was able to help multiple projects and think about the future of open source? And that's how I got involved in things like the board of OpenJS and the dot-not foundation, as well as the other things that I've done. You can get involved in many ways. People are looking for this kind of help. Documentation, sponsorships. If you have friends at lots of companies, they want to talk to them. That's helpful. I feel like the great part of the bureaucracy of open source is how you can affect an entire community and bring value to the things that you love every day, multiple things that you love every day. Open source communities have things like standards boards. How do we write our code? Different working groups to optimize things. Helping them identify needs is super valuable. And helping to think about adjusting governance. If you've worked in engineering leadership, you know how sensitive these conversations can be, how to approach difficult conversations, how to identify needs within an organization. This is something that is needed in all of open source. So how do you get started? So I like to always think about chopwood and carry water. You don't show up. I see leaders all the time that show up on day one and they say, hello, I'm ready to lead you. You're welcome. And people are like, okay, great. Well, that's not what we're looking for. And so I find the best way is to get your hands dirty and get involved. And most projects, they're on GitHub. They will have instructions on how to get involved. They will tell you what different groups there are when they meet, when to show up. And showing up is it. Showing up is free. Go to a meeting. All these groups have periodic meetings. Sometimes they have them on YouTube or Twitch. You can watch and see what you're getting into. It makes it easy. Again, you can help them with coding or documentation. There's all kinds of things these projects need. So, shameless plug. If you're looking to get involved, if this is something that is exciting for you, OpenJS is always looking for partnership. On Tuesdays, we have a cross-project council. We meet on Zoom. There's people from across the world. And the things that we talk about are how do we best support the projects like Node and Electron and jQuery and think about the resources they'll need in the future and help to get the word out about their needs and think about how to support a big community of JavaScript developers. There's also a standards group. We do event planning as well. OpenJS is a big conference every year. It's really easy to get involved. Basically, you just need to show up. And then most of our projects have technical steering committees that don't just go in and code, but they think about the future of the technology, where it needs to go, where's the industry going, and how do we enable our maintainers to think with the future in mind? And then as always, developers are welcome. So thanks all, thanks for coming. I hope this was 20 minutes that got you more interested in open source and being involved in governance. I'm here for a while and have a great conference.