 So, what I want to talk about today is the maintainer's paradox, and I'm going to start by referring back to a paper that was written by Eric Raymond called The Cathedral in Bazaar. And if you haven't read this, you really should. It contains some really interesting ideas, but one of the things that it introduces is a core principle, I think, that undergirds open source and how it works. And it's actually a mathematical principle in a way, although it's expressed kind of differently. He referred to it as Linus's law, and what it is is this, that he said in the paper that with enough eyeballs, all bugs are shallow. Another way to put that is that if you have a large enough community, the more people you have in the community, the more likely you are that there's going to be someone in that community that can look at something and kind of decode it easily, debug it easily. And he put it in the context of software quality. When I do training at Sony, I actually change this a little bit and use a light bulb metaphor. And so how I explain it is if you have five or ten light bulbs that are kind of similar to each other, you turn them on, there's going to be, you're going to have some good ideas in those light bulbs. Ever since Edison, the light bulb has been used as a metaphor for a good idea. But if you have a thousand light bulbs of different shapes and sizes, it's much more likely, when you turn those on, that there's going to be some really great ideas in there. And so it's really kind of a thing about probabilities. But there's more than just numbers involved. So it's the diversity that is important and that is helpful. It's diversity of thought. It's diversity of experience. And so diversity has a big upside because as you get this diverse range of ideas and opinions, you're more likely to stumble onto something or think of something that is valuable and that can move a project forward. Of course, diversity also has extra costs. It takes time to assimilate new and different ideas and to kind of change them and integrate them into the existing code path. So one of the things that I've learned just over the last little bit, I became the maintainer of a project called the Fuego test system. And over my 25 years career in open source, I've always been a user and a contributor, but not really a maintainer. And it was eye-opening. I learned some things becoming a maintainer that gave me a different perspective on the open source process. And that's what I want to talk about today is what I refer to as the maintainer's paradox. And it really kind of boils down to this, that a maintainer is really excited to see new contributions to the project. And we appreciate when new ideas come in, when new users join the project, there's always a bit of excitement. But there's also a bit of fear and trepidation that comes along with that. I have to admit, and I got to say this carefully because there are Fuego contributors I believe in the audience this morning. But when I see a patch set on the mailing list, sometimes I go, oh no, another patch set. I just don't have time today to look at that. And I look at my schedules like, when am I going to be able to fit in the time to look at that? And because you want to do a good job. You want to review the patches carefully. You want to give appropriate feedback. But I found that being a maintainer can sometimes be overwhelming. And it's a more difficult job than I experienced. And so I have to kind of go back and think about the times when I kind of got annoyed at maintainers in the community. They didn't do things that I was expecting. They didn't respond as fast as I expected. I kind of set my own goal in the Fuego project to try to respond to every patch in 24 hours. Well, that's a great ideal, but it is so unrealistic I can't even tell you. In fact, this conference, there's like four patch sets queued up that I haven't gotten to at all. I apologize. But so that's the thing. We strive for the ideals. One of the things that you may not realize. This is a metaphor I saw, I think last year, the year before. A patch contribution is a lot like a puppy, that a puppy is a cute thing. Who wouldn't want to receive a puppy? Well, it depends on your circumstances. You may or may not want to get a puppy to every patch that's contributed, especially if it's a feature patch, a new branch of functionality. That's something that has to be cared for indefinitely. And so as a maintainer, your incentive is to not take too many of these things because it gets overwhelming. And the other thing about being a maintainer is, despite our aspirations to have everything be based on meritocracy, the truth of the matter is there is a social element to working in the open source community. There's a social element to working in just about every situation in life. But although we strive to only review the code and look at it pure on its merits, a lot of times there are personalities involved. Because of the rushed nature and the busy schedules of maintainers, sometimes there are answers that are curt, sometimes they're snippy. People can get frustrated. There can be miscommunications. And sometimes there's negative things happen. So you can argue whether or not the, well, let me preface this with a bit of a story. There's at a conference, another conference recently, just earlier this year, there was a talk given by one of the maintainers, the Linux kernel. And he talked about some negative behaviors that he observed. And I won't go into details. I don't agree with everything that he said in the talk. But he saw some stuff that concerned him. And I applaud that he brought it forward and discussed it. Now, you can argue whether or not the kernel environment is kind of a benign kind of danger like the one on the left. Or if it's really a hostile environment like the one on the right, that's a wood chipper. I've never seen so many warning notices on a device in my life. But in any event, I think whatever the current status is, we can always improve our communication in the community. And so I want to give just a couple of quick tips for what I think will be helpful to improve the positivity and the level of communication in the community. So I tried to do the keynote thing where you only have pictures. But I decided I'd fall back on words. So I think tip number one is call out negative communication when you see it. And this is hard. If you've been the subject of some negative comment, it's kind of hard to respond. And so I encourage you, I don't want to deputize you all as kind of thought police or anything. But if you see a kind of a snarky comment or something that's negative. If you're a third party impartial observer, it'll say something. It can be in private. If it's kind of a severe thing, it's sometimes useful to say it in public. And we can elevate the tone of the conversation. And I think that's a valuable thing to do. Even if people disagree with kind of the severity of the negative comment, we can have a discussion and we can help start establishing some more positive norms in the community. Another thing that you can do is as a contributor, route around the offender. One thing that we've been doing recently in the Linux kernel community is establishing maintainer groups. So there's more than one person we're hoping that you can go to. So if a particular individual rubs you the wrong way, you can go to someone else in the maintainer group. This is something that's evolving. Not every subsystem has a maintainer group right now. But we're hoping that we can improve that. This actually also relieves a lot of stress on the maintainers, which I think is a source of some of the snippiness. And if you're in a situation where you don't see an avenue out, send your patch to Andrew Morton. Andrew Morton has kind of been designated as the ombudsman for stray patches. He handles stuff where there's no maintainer, because there are sections of the kernel like that. Or if you have a maintainer that you'd rather not work with, communicate with Andrew and see what you can do. Another thing not having to do with negative communication, well, a little bit, but just listen carefully and actively clarify what the intended message is and act on the feedback. A lot of frustration comes on the mailing list because of miscommunication. And again, the communication can be somewhat curt. I saw one exchange where a developer said, go read this and that. And the guy read it, changed the patch, submitted again. And then the response was, you still got this wrong. And it was because the communication wasn't specific about the particular problem that the original maintainer had noted. And so that type of thing can happen. We're all humans. But try to actively clarify. If you get kind of ambiguous directions from your maintainer, ask for clarification. That's not gonna hurt. And then another thing that will relieve the stress on your maintainer is, if you actually go out and actively assist. So don't just contribute patches, but go out and help with some of the things that the maintainer does by assisting people, answering questions. I'm the maintainer of the Fuego project. And each time I get on the mailing list and answer questions, it takes some of my time. And I really appreciate it when other people can answer questions for me. And especially if they get the answer right. That's really helpful. But no, it saves me time. And it really is. It's like a weight off my shoulders when I see other people helping. The final thing, if you really want to make an impact, become a maintainer yourself. You too can enjoy all of this overwhelming feeling. There are opportunities. Now, I need to be careful here. The truth of the matter is not everyone has the time or the inclination or quite frankly the capacity to be a kernel maintainer. There are areas of the kernel that are very difficult to change in a beneficial way. The Linux kernel has now thousands of manures of development in it. There are sections of the Linux kernel and it's used in thousands of industries and literally billions of devices. And so the chance that if you're just coming out of college and you have a new theory about scheduling that you're gonna be able to get that in and it's not gonna break the workload on some device out there. Chance is just really, really low. I'm not saying it's impossible. But there are areas of the kernel that are quite mature and you kind of need to build your way up in order to work on them. Having said that, there is a role for everyone. One of the things that I think is important is that no matter what your level of expertise, no matter what your level of experience with the community, you can do something to contribute. And so my last plea, I guess, is to find something to do. Even if you're super busy, you don't have time to contribute code, you can work on documentation. And that's actually a really good place to start. Before I became the Fuego maintainer, I spent a bunch of time reading through the documentation and actually writing new documentation, which required that I researched the code. But there are other activities, testing and triage of bugs. Those are all really important. Sometimes we get caught up in the code contributions and we miss out on other opportunities that actually take less time and that we can do in kind of a different level of urgency to contribute. Anyway, those are just some ideas that I thought I'd share with you. Over the last 25 years, that's how long I've been doing this, it has been my extreme pleasure to work with the Linux kernel, the Linux kernel community. I think in terms of the world history, I think that there is nothing quite like this new economic system, open source, that people can contribute to. Anyone in the world literally can contribute to the Linux kernel, to an open source project, and create value for the rest of humanity. So if we all get to work together, we can create a new paradise. It's a great stuff. But really, just go out and find your place that you can contribute. And with that, I'll just leave it at that and thank you for your time.