 All right, let's get started. Today, Alex and I are speaking about the Apache way, but with a twist. So the Apache way was originally developed back when most open source contributors were hobbyists and volunteers. But today, Apache has a very different composition. It's still very community-oriented, but most Apache contributors are no longer volunteers and are instead paid to contribute full-time. That's true for both myself and Alex. We work at Cloudera, a company that is commercializing Apache big-gitter projects. So when business is introduced to a project, the narrative changes. There can be tension between business needs and the needs of the open-source community. And that tension is what we want to address in our talk. However, we also thought, why should education come at the expense of engagement? As a fun device, we have structured our content around three, we're calling them structured, socratic dialogues, featuring fictionalized versions of ourselves. And these sort of conversations actually came out of lunchtime discussions that we had had. I started at Cloudera working on Impala before it was ASF. And then on this other project, so then I switched to HBase. And I was kind of like, wait, so why do we bother with this? What's the deal? So Andrew was going to walk me through. In Act 1, we introduced the value of open source, the ASF, the Tendency of the Apache way. In Act 2, we show how the Apache way applies to some real-life scenarios based on our experiences working in the community. And in Act 3, the conclusion, the student applies the lessons learned in Act 1 and 2 to save the project. So us, you save questions in the end, because some concepts that we introduce, we sort of expand on further. So don't accuse us of screwing stuff up until you've seen the whole thing. Then accuse away. Act 1, Andrew and Alex are both employed at Mistera, a company that provides commercial support for the Apache project Big Dupe, which does analytics and storage on next generation mis-computing infrastructure. Andrew is a grizzled veteran of open source at Apache. Alex is a newcomer to open source, but not to software development. Alex was recently hired to work on a new Big Dupe feature, Rainfall. Hi, Alex. How's your first week going? Great. I really like everyone I've met so far at Mistera. People are very friendly. Thanks for helping me get my laptop set up. I've started poking around the code base and looking at some of the issues you pointed me to. Great to hear. We're glad you joined. As I'm sure you know, this is a fast-moving space, and we really want to get Rainfall in. But I don't want to stress you're out just yet. I said this time so you can get your first patch committed upstream. Before we get started, do you have any questions? Actually, yeah. Big Dupe is my first time working on an open source project, I'll be honest. I don't really get why we do it here. I know that Linux and Firefox and things like that have done well, but we could really get things done faster and easier if we just forked Big Dupe and worked on it ourselves. Asking a big question straight off. We're forced to work at a company where our management believes in the value of open source. From the Mistera viewpoint, the open source community acts as a force multiplier. Big Dupe benefits from features and fixes contributed by people outside the company. We used to be working on cloud computing, not miscomputing. It wasn't for open source. It's cool that we get these improvements for free, but why do we bother to submit our changes back upstream? If we kept them to ourselves, then our project would be better than the open source version. Well, it's all about maintaining a healthy open source community. If everyone only took and never gave back to the upstream project, the project would wither and die. So by being active upstream and welcoming new contributors, we build momentum behind the project. Remember, Mistera is competing mainly against proprietary software vendors, not other Big Dupe distributors. Our first priority is getting Big Dupe out there into the hands of more users. OK, and Big Dupe is part of Apache, right? I guess this is my inexperience in open source showing, but that's different from Eclipse and Firefox? Yeah, it is. Formally, the ASF is a nonprofit that supports the development of the Apache family of open source projects. One distinction is that all Apache software is distributed under the Apache license, which is more permissive than other open source licenses. Another distinction is that the ASF is a volunteer-run organization. Corporations cannot buy influence. How does all that relate to building communities? Well, the ASF is basically a group of developers with a lot of experience in forming healthy open source communities. The Apache license and the governance model of the ASF are all drawn from that experience. For instance, the Apache license allows people to include Apache code in proprietary products. Isn't that the opposite of open source, letting people use open source code in proprietary projects? It sounds counterintuitive, but a more permissive license actually means a more inclusive community. It encourages businesses to make Apache software at the core of their product and allow them to participate in the community and contribute their changes upstream. I guess that's why we're here working on big dupe then. Yep. I also need to add another point on community building. The ASF has a lot of tribal knowledge around how to build open source communities. This is captured in the Apache way, a set of high level principles like community over code and meritocracy, which people refer to when interacting in Apache and making project decisions. OK, I get that. But it still seems like a lot of work to contribute upstream. For instance, as a newcomer, I can't get my changes in since I'm not a big dupe committer. If we forked, I could start committing right now. That's true, and it's a valid concern. There is a ramp up to getting involved in a new project and gets back to those key principles of the Apache way I mentioned. Meritocracy means that new contributors additional rights through demonstrating merit. After that, the PMC might make you a committer. Ah, merit. That sounds like what I need. Yeah, that's the benefit of working at Mystera, having that sweet, sweet merit. What? Well, and I thank you for this. You guys have built up a lot of merit for us. So I guess I can just see why we don't need to fork the project. Maybe I should get a badge next to my name when I post my first patches. So people know that I have merit. A merit badge, so to speak, like a regular Eagle Scout. That's not really how this works. Merit is earned by individuals, not by companies. Well, Mystera has a big investment in big dupe. I know we have a big team supporting this project for our customers. Isn't that worth something? It is. Mystera brings a lot to the Apache community, the most obvious of which is paying full-time developers to work on the project. Also, having customers means we really understand the pain points of big dupe users, which helps us guide the direction of the project. Finally, Mystera also helps evangelize Apache projects by sponsoring conferences and meetups. So as a developer, Mystera, I can earn big dupe merit by contributing patches? Exactly. Just working at Mystera doesn't grant you any special privileges. But Mystera employees can earn merit on an individual basis through their contributions. OK. So the meritocracy thing sounds good in theory. But I still don't get how it works in practice. People know that you work for Mystera. Are they supposed to pretend that you don't? And I know that some Apache projects are like 99% controlled by a single company, or there's a Linux-like situation where the project is controlled by a single person. How does this all work? Hats. Hats? Hats. So people at Apache often talk about hats. When we're working out on a Apache project, we're supposed to wear our Apache hat rather than our company hat. This means acting with the project's best interests in mind. Do people really act altruistically like that? I bet our competitors would block me from being a committer just because I work at Mystera. After all, if they control the project, they can block our changes. I also always see companies publishing press releases bragging about how many big dupe committers they have or how much code they've contributed. So if they control the project, they can make themselves look good. Do you think it's a good idea for our competitors to block our changes? Yeah, obviously. We need to ship this rainfall feature ASAP. If they start messing with us, we'll miss our deadline. But what does that mean from a community perspective? Does blocking our changes make it more or less likely that we'll work with them in the future? You're alluding to the value of open source. If they're being difficult, we might take our ball and go home, and then they won't benefit from our contributions. Yeah, there are always jerks on the internet. But the vast majority of people at Apache just want to make their project better. OK, so hats are a metaphor for thinking about the community first. Exactly. And that's really the essence of the Apache way. Community over code. Now, are you ready to get working on that first patch? I came here to crush code and chew bubblegum. And I'm all out of big league chew. All right. Thank you. OK, so what did we cover in Act 1? The first topic is what is the value of open source from a corporate perspective? So open source acts as a force multiplier. This means that you benefit from the changes and improvements being contributed by other members of the open source community besides yourselves. So you get a lot more work done. You get a lot more push behind your project from a business perspective. Also, a rising tide lifts all boats. We alluded to this in Act 1 when we said that oftentimes your competitor is not another distributor of that same Apache project. It's often some kind of other piece of software entirely, perhaps a proprietary piece of software. So focusing on just growing your Apache community benefits everyone who contributes to that community. Finally, from a customer business point of view, oftentimes customers like open source because it means reduced lock-in. They have alternatives if they want someone else to support this same piece of software for them. And oftentimes, open source also comes hand-in-hand with open standards. So what about for the individual contributors, the employees of the companies? One of the benefits is you get to work with a global community, which is much more than you could say in most companies if you're just working with your coworkers who sit next to you. You'll get a public record of your work, which again is sort of a rare thing. If you're working on some proprietary software, no one will ever see what you did. So you can't really prove that you did anything or go to your job at all. And you get to attend ApacheCon in exciting locales like Miami. So that's a nice benefit. OK, and the next topic we covered is why the ASF in particular and what is the ASF. So the ASF's mission is to support the development of the Apache family of open source projects. And it's different from some other open source foundations in that it is independent. And it's fully not run by corporate interests. This means you cannot pay Apache some amount of money and get control in the ASF. And lastly, one of the biggest contributions of the ASF is that we've been growing open source communities for a very long time. So you have a lot of tribal knowledge about how to do this successfully, which is encoded in the Apache way. So one of the key takeaways of Act 1 in terms of how to interact with the Apache community is community over code. And obviously, we're going to expand on this in the next two acts. But the upstream contributors are your community. So it's very important to build interpersonal relationships with them, the people upstream, not just people who work at your company who happen to be working on the same project. Yeah, next is meritocracy, the idea that individuals, not corporations, can earn merit through their contributions to the project. And by demonstrating merit, you are given increased responsibilities in the project, going from contributor to committer to PMC member, so on and so forth. And we touched on the concept of hats, which is it's important to keep the project's best interest in mind, even when you're dealing with people you may interact with outside of the Apache hat world. In dealing with Apache, you're wearing the Apache hat. Yeah, I remember all of these tenants of the Apache way are drawn from the experience of growing successful, healthy, open source communities. So we'll be going over in more depth why each of these points is important and how they relate to more real world examples in Act 2. Character. OK, Act 2. Four months have passed since Alex started that Mysterio. He's done a lot of bug fixes and has made a lot of progress on his big feature, Rainfall. However, Alex is having upstream issues with his patch and comes to Andrew for advice. Hey, Andrew. Do you have a minute? Sure, what's up? Well, I finally posted my patch for Rainfall upstream. I've been working on this for a long time, and I even got a review by some of our teammates first internally. They said it looked good to go, so the upstream review should have just been a formality. But some clown minus one did, and now I'm stuck. Well, upstream reviews aren't really a formality. Look, Andrew, we need to get this in pronto. Our product manager already promised this to our customers months ago. Just yesterday, Mellon told everyone we'd have it upstream by Friday for the release. Come on. Can you do something? We're all on the same team here. Whoa, whoa, OK. Let's slow this down a little bit. This internal deadline sounds like it's stressing you out, but let's worry about the code first. I haven't even seen your patch yet, but I'm sure we can figure out this veto. I don't know. Can't you just commit it for me? You've been working on Big Dupe for a while. People listen to you. Sorry, Alex. When I interact with the Big Dupe community, I need to wear my Apache hat. Hey, man, no disrespect. I vaguely remember your intro advice from the first day, but I'm not in the mood for this hat BS right now. I'm trying to be a mover and a shaker, not some hippy on a hill with a pile of hats. I admit that the hats are a bit silly, but I meant what I said. I need to think of the project first. It's important to look at the long term here. The long term? I know this is your first big project, so it seems really important to think about your next project and the one after that. We need to build consensus first, not round the change down people's throats. That's not the way to build good relationships with the rest of the Big Dupe community. Yeah, I mean, I know that. But look, this is a one time thing. We were behind the eight ball on rainfall, and everyone up to our VP expects that this is going to be shipped in our next release. I swear I'll do it better next time. Help a co-worker out? Well, even if I wanted to, I can't override a veto. Really? But aren't you a PMC member? This guy upstream is only a committer. You don't outrank him? Well, yes, but no, I'm not a dictator. And even though I'm on the PMC, I can't override a code veto. The influence I have comes primarily from my interpersonal relationships, not from being a PMC member. So what's the point of being on the PMC then? Well, I'm responsible for making project-level decisions and looking after the long-term health of the project. I'll also add that part of being a good PMC member is knowing to pick your battles. Well, so what should I do now? Well, let's look at your patch together. I haven't even seen it yet. 10 minutes later. Dude, that's a lot of histrionics over what is not really a big deal. Yeah, and I guess the code is a little cleaner too. So now that we're done, can you commit it? Well, no, not quite yet. You need to post your patch first and wait for the community to review it. But you just signed off on this. I thought we addressed everyone's concerns and I didn't even ask you to do it as a PMC member. I just came to you as a fellow developer. But we were the only ones here. What, you want me to invite my mother? Funny, but no, what I meant was that this discussion did not happen on a public list. Yeah, I mean, it just seemed easier to come talk to you. You sit nearby and we were able to get it done quickly. And I was happy to help. But we need to first build community consensus. And part of that is having a public record for how the decision was made. This makes it transparent why a decision was made and ensures that everyone in the Big Dude community can make their opinion heard. Yes, that's been made clear. And I guess there are different people in different time zones who might also want a comment. Okay, I'll post my patch with a comment about how I address the code review comments. Thanks for your help. No problem. Oh, and did you see this latest dev thread? They're trying to make Danny the docs writer or committer. What a joke. What, why is that a joke? I'm not even a committer. True, but I mean, you guys are different people. He just writes documentation, right? It's not like he's writing code. Docs people can't even read code. Danny's always asking me questions about how Rainfall works. Didn't Danny overhaul our user guide? Yeah. And didn't he also convert all our docs from XML to Markdown? Yeah. And didn't Danny also write all the docs for Rainfall? So? So why do you feel he shouldn't be a committer? It's just docs. Writing code is way harder than writing docs. I spent months working on Rainfall, and Danny wrote the docs in like a week. Any developer can write docs if they want to. Let's step back for a second. If you were a user and wanted to try out Rainfall, what's the first thing you'd do? You'd probably Google big-dub Rainfall, and the big-dub docs would be the first hit. So docs are the first exposure a user has to our project and their new features. OK. Point to you. I agree that docs are useful, and to be honest, I get annoyed when I'm researching a new technology and there aren't any docs. But still. Danny only has 10 patches. I have 20 patches, and I'm still not a committer. How's that fair? Well, let's read through this email that's proposing Danny as a committer. It says that Danny's been involved with the project for a long time. And you actually got to start by answering questions on the user list. And looking at the archive, she's actually the top poster of all time. That means she's helped a lot of people get started with big-dub. But that's still not code. And it doesn't have to be. Remember, Apache Merit takes many forms. There's no one route to committership. If anything, it's embarrassing that it took us this long to make Danny a committer at all. I mean, I thought all this Merit stuff was built by building the project. Code speaks. So Kathy and Quality can become a committer by writing tests? Sure. And Frank, the program manager, his job is setting target versions for Jeras and doing a release scheduling. He can become a committer. No reason why not. Why does Frank even need a commit bit? Doesn't need to commit to code to do program managing. Well, this is one of the weaknesses of the Apache system. Maybe Frank never needs to commit to the repo, but we certainly like Frank be helping with releases. I'd make Frank a PMC member just so he gets a binding vote on releases. This seems to violate the principle of lease privilege. People shouldn't have permissions that they don't need. Sure. Like I said, this is one of the weaknesses of the Apache governance model. It's very developer centric. But let's think of it this way. Even if Frank doesn't need to commit to the repo, would we still trust him to use his power responsibly? I guess. I mean, I don't think Frank would ever commit any code, which is why I thought it goofy that he would become a committer in the first place. So in practice, it's fine. Something else I've learned is that code is just code. It can always be changed later. So rather we not worry about possible get screw ups and instead focus on growing our community. What should I do then? I've got a lot of patches. Yeah, you've definitely done a lot of heavy lifting on rainfall. The PMC typically looks for someone who has a history of sustained high quality contributions. And I think you meet both of those bars. So what do I need to do to become a committer? Well, again, my advice is to make sustained high quality contributions. Since we're developers, it means making good patches and doing good code reviews. Wait, so even though I'm not a committer, I should still do code reviews? Definitely. The best way to become a committer is to act like a committer. The primary responsibility of a committer is reviewing other people's patches and giving it a plus one. So the best way of showing that everybody for this responsibility is by doing more code review. I guess, ideally, that makes sense. But I'm really busy with rainfall. We're on a tight timeline. I'd rather be writing code than paying virtual dues. It comes to the territory. I mean, becoming a committer is also about building those community relationships. This isn't really that different from starting to work on any new code base. You never just go in and change everything on an active project. First, you need to build credibility with the people who are already there. OK, I'll try reviewing more code. There's this cool Cloudburst feature some other people are working on. Maybe I can review some of those patches. Good. And a silver lining of this veto is that it might actually be a good opportunity to work positively within the community. If you can show that you can work constructively with our upstream reviewer and get him to remove the veto, that's a big step forward. You can also try more actively engaging with people on the mailing list and in your discussions so people can get to know you. OK, I guess I could start a discussion on the dev list about when we want to rebase rainfall. Good idea. And I've been wondering how we're going to get rainfall to work with Cloudburst. I should ping those developers too. Now we're thinking with portals. All right, I can run with this. Sustained, high-quality contributions and positive interactions with the community. Thanks again for all the help. Any time. By the way, do you see this Jira, this guy, John, filed? He's new to the project, but he wants to add some Python to BigDub. Wait, Python and BigDub? I better take a look. OK, so discussion questions for Act 2. What mistakes did Alex make with his first patch? Well, instead of engaging with the community early, I did a giant code dump, which is not good. And as a result, I received the upstream veto, which would have been expected had my character known anything about a patchy. Another mistake was letting internal pressure sort of dictate my reactions. People upstream obviously aren't aware of your company's internal deadlines. They don't care about your company's internal deadlines, and they shouldn't care about your company's internal deadlines. The project sets their own sort of timelines for releases and when they want to get things in. And from the patchy project's perspective, those are the only ones that matter. Right. And so what did we see in terms of conflict resolution strategies in Act 2? So one of the things there, build consensus by pulling in others. In this case, it was sort of easier because I worked alongside a senior member of the project. So Andrew was able to help me through navigating the veto. Right. And next is making sure to keep the discussion about the technical problem. And you can tell that Alex was getting pretty frustrated. He was unhappy with how things are played out. But again, we brought back to the code about the upstream review comments. And it turns out that if you can keep the discussion focused on the technical problem at hand, oftentimes you can come to a compromise solution that overall is better than what you started with. Oftentimes, you can improve the contribution by incorporating everyone's feedback. The next topic we covered is how to become a committer. So this differs from project to project, community to community. So I'm speaking in pretty general terms here. But at least for many of the patches that I've seen, they look for basically these three things. The first is high quality contributions. This means when you post a patch and people trust it, it's going to be good quality. The next is a history of sustained contributions. The idea behind giving someone a commit bit is that you want them to then go on and work in the community to go review other people's patches, pull in more contributors, grow the project. So you want someone who is dedicated to the project, who probably when you give them the commit bit, they'll go on to do these things in the community. And finally, and probably actually most important, is building interpersonal relationships. Apache is a pretty flat model. All said, once you're a committer, you're pretty much fully functional as a member of the project for data operations. So you really have to have some people skills to navigate things like vetoes or other conflicts that happen upstream. Also, becoming a committer is ultimately all about trust. Remember, we had this example of Frank, the program manager, who might still make a committer because of his contributions to the project. Frank doesn't need to commit code to the repository, but we trust him with his power because we trust Frank. And that's the most important thing I think about being committed is the community trusts you with this new responsibility to behave in a good manner. So there's also that gets into who can become a committer. Anyone theoretically could become a committer. It's not just limited to people who write code. On any project, there's more roles in just like straight developers. Obviously, Apache grew from people developing code, but as projects can get mature, more roles expand. And sort of the idea of committer maybe is sort of a course model in terms of how you want to do things. It's something we sort of touched on in the talk. And again, there's no one route to commit a ship. It varies project to project. And it even varies person to person depending on the role. Yeah, I think this is really something that we are still dealing with as a Apache community, how to fit in these non-developer roles and incorporate them, like pull these people in. We actually had this very explicit discussion on this topic on the duplex where we were talking about, like, hey, basically we're all developers. We don't have any docs writers or test people, really. People who are contributing these other roles are actually very important to the success of our project. What can we do to try and pull more of these people in, like bring them into our community and make them feel rewarded? And again, right now in the Apache model, all we have is the committer status or becoming a PMC member. So we actually tried to draft a new set of committer criteria that gives examples for how these different types of roles can become a committer. So an example for if you're a test person, how can you become a committer on Hadoop? If you are a docs person, how can you become a committer on Hadoop? And so on and so forth. Because we really are trying to incorporate these non-developer contributors into our Hadoop community. And I think this actually is also something that becomes more important as a project becomes more commercialized. When starting off, you have pretty sophisticated users who are on the bleeding edge of technology. They're OK if your docs aren't that great. It's a little bit hard to use. There's some sharp edges with your project. But increasingly, as you have a broader audience who's using your project, things like docs, things like testing and quality become much, much more important. Because it's more important to be thinking about these non-developer roles in your project. Sorry about this one. So another thing we touched on is making decisions in a public forum. If you work with a co-worker and you're working on the same project, it's a patch of project. We're not saying don't talk to them about it. That'd be ridiculous. But if you're making any sort of project decisions or responding to code review comments, you should always document that publicly. So you want to make sure everyone can see why the decision was made. And documenting and having the discussion publicly on the lists or in JIRA or in the code review allows everyone to participate and then have ownership of the decision. Even if they don't chime in, they'll see the decision going on. So they can feel like, OK, I saw this. I know this is going on. If I had a problem, I could speak up and say, wait. Why are we doing this? There's also a practicality. Because obviously, everyone's distributed and oftentimes distributed across every time zone. So people are sleeping when you're working and vice versa. So you don't want to wake up and be like, wait, the whole project changed. What's going on? Yeah. This is all about letting the community have ownership over the decisions that are being made and that's achieved through transparency. And one last point is that merit does not buy authority. We talked about how PMC members do not outrank committers. If you're a PMC member, you can't just go in and override a committer's veto. Not how this works. So it's important to remember that, again, this is actually building the healthy open source community. It's important that, even as a very senior member of the community, that every contributor has a voice. Even if you're working on a project for many years, some new person comes in. It doesn't mean that they're necessarily wrong. Everyone has value they can add to the discussion. Just keep that in mind when you're doing interactions. Even though you're a PMC member, you don't outrank a contributor, everyone is part of that same open source community. So for Act 3, we're going to start with the things we're going to cover and then we're going to end on a dramatic flair. Just lead right into questions. So the big takeaway from Act 3 is going to be no jerks allowed. Apache does not allow dictators, but a single jerk can poison a project. And rudeness needs to be addressed at the bud. And this whole Act 3 will be a demonstration of that. This is always a very difficult problem. The problem of bad apples, basically, exploiting the entire barrel. So there are no easy solutions here. But one thing I would say is that it's the responsibility of people who are more senior members of the community to address it. Your job as a PMC member or a committer is to be thinking about the long-term health of the project. So it's on you, if you see rudeness, to call it out and make it clear that it's not tolerated in your project. And do this publicly and try and do it early. And also, let's back to one of our earlier points about keeping the discussion about the technical problem that's at hand. So rudeness and ad hominem tax really have no place in a healthy project. And of course, again, this all gets back to building a healthy open-source community. OK, so Act 3. A year has passed since we last saw our protagonists. Alex successfully completed rainfall and became a big-dupe committer. However, big-dupe is now a shadow of its former self. Community problems have spiraled out of control and the project isn't disarray. Contributions have slowed to a trickle and the rumors of big-dupes demise are circling the Twitterverse. In an attempt to say the project, Alex approaches Andrew with a harsh truth. Hey, Andrew, I need to talk to you about something. Yeah, sure, what's up? I'm concerned about the state of the project. What are you talking about? The project isn't better-shaped than ever. You're still showing your inexperience, man. There are some things that are going on that look kind of problematic. And I'm not so new to this anymore. Like what? Code quality has definitely improved. We used to have so many people committing these half-baked patches. Yeah, up to maybe even six months ago, we had many individual contributors running code for the project. And now look at how clean and precise all of our patches are. We've committed the last six patches. And in fact, other than some commits from Milana and Arun, we've been writing most of the code lately. Yeah, you're right. The patches that have gone recently have been really nice, haven't they? That's not what I'm saying. So what's your point then? Didn't you already know Milana and Arun? What? Milana and Arun. You used to work with them, right, at your previous job? Yeah, they're great developers. Don't you see the problem there? We aren't getting any new contributors. No one wants to write code for BigDoop anymore. That's not the sign of a healthy project. Doesn't matter, right? I mean, people still run it. Well, they do. But I hear a lot of buzz about BigFire. I heard they've gotten a ton of new contributors recently. And many of those people continue to follow the project and contribute code. Who cares? They're just the hot new thing. In the general IT community, we're much better known. And we control this project. You mean, you control the project? Yeah. It's great, isn't it? Andrew, remember that guy John from a few months back? Yeah, John, that Python coder? He sucked. He wasn't a bad developer. Just new to open source. Hey, look, I got senators to maintain here. I'm not trying to teach every Tom, Dick, and Harry head of our for loop. You didn't even review his code. You replied to his email to the dev list saying that you hate Python and that the project wasn't interested in accepting his patch. Let me find the thread. Look at this. John sent an email to the list explaining that he wanted to add Python bindings to our project. Here's your response. Honestly, I don't see why we would need that. Our users are sophisticated computer operators and don't need to use Python as a crutch. Python has no place in our project. Then Milena gave some constructive comments and asked him to file a JIRA. John posted a design doc and a prototype patch. And here's the comment you posted. Python is for mental midgets, and it's not going to be associated with big dupe. Yeah, that was awesome. Python's for mental midgets. That's a sick burn. Dude, what's wrong with you? That was unprofessional and juvenile behavior. Come on, then. Python sucks. Milena Python coders here in big dupe. That's not even the point. John was interested in contributing to big dupe. Then you flamed him, and he stopped participating in our community. He started contributing to big fire, and they love him over there. Wait, how do you know so much about this big fire project? Well, they're doing some cool stuff over there. I've been sending them a few patches here and there, and the people are really helpful. You've been contributing to big fire? But we paid to work on big dupe. I thought you liked big dupe. I've been tinkering in my free time, more like a hobbyist. Really? Yeah, honestly, the big dupe project has really taken a turn for the worse. People noticed how you treated John. They started taking their contributions elsewhere. Huh. When I started at MISTERRA, how many upstream contributors did we have on big dupe? Lots, and that's why I had to clamp down. There's all this bad code being merged, and I couldn't review everything. Yeah, but Andrew, this gets back to one of the first things you taught me, community over code. We need to think about the long-term health of the project. Without contributors, there is no project. Well, we need good contributors. Contributors who sound good patches. Who do you think is gonna be the next big dupe committer? What? I became a committer close to a year ago, and I'm still the newest committer. Yeah, because like I said, there hasn't been anyone good recently. Andrew, let's think back to when I was working on Rainfall. I made plenty of mistakes. Heck, I basically built a feature in a private branch before sending it upstream. Someone vetoed it, and you had to help me rework it to address their feedback. Yeah, but I knew you were cell developer. You had potential. But so did John before you scared him off. Like I said, he's been great over on big fire. I think they just made him a committer. Huh, I guess John might be all right then. Yeah, but you didn't even give him a chance. Andrew, do you remember why you got involved with open source? Well, I enjoyed working with the open source community. I was excited to work on a project like big dupe that was popular and was changing the world. Me too. When I started at Mr. Ara, you taught me about the Apache way, about merit and wearing my Apache hat and community over code. You taught me that the project lives and dies by its community, but I think you've lost sight of that. Big dupe is bigger than any one contributor, even a contributor like you. You're right. Forgotten what made me passionate about open source in the first place. We can still save the project. The community needs to come first. That's something I learned from you. Alex, I can't thank you enough. Building consensus, meritocracy, diversity, community over code. I lost sight of these guiding principles and in the process, I lost my way. But maybe I can rediscover it, the Apache way. So, questions? Are there some of the other Apache way talks when you were writing this or you've just done it? We just did it. Okay, because I'm really impressed, quote, how hilarious this is. And how many of the concepts I just told you if we have it all at other Apache way talks. You have the exact concept in the context of the discussion. And in the, of course, an employee or a geek or a coder is trying to do something and explain the concept and write in the, how they need to explain it here. Thank you. Thank you. Yeah, that was the goal. As I said, it actually came out very organically because I came, basically all these questions were questions that I had. I was like, what is the deal? Yeah. Cool. Well, thank you guys for coming. Yeah.