 Good morning. Hope everybody was enjoying Miami last night. It looks like we have a good crowd. It looks like everybody's awake, which is great, because sometimes later in the conference we're not quite as awake. I'm here to introduce both my talk as well as an entire track of talks in this room all day today about the Apache way, which has a lot of different meanings, but really what it means to you is effective open source project management. It's not just part of the ASF, it's a good way of doing things. Really, there have been a lot of Apache way talks in the past, and I was trying to think of what you want to learn about the Apache way that makes Apache projects so successful and so long lived. And it's really the behaviors that a community has and works with together to produce a result. It's how they do it that helps our communities be successful, be welcoming, be long lived, encourage new contributors, because really our point is to have long live projects. And bringing in new contributors is the most important thing you can possibly have, because then they will help you continue the project. And for those of you who are committers on an Apache project, these are required behaviors. This is part of what the board expects projects to do. In some cases, some projects have a specific way that's different. If they can explain how that works better, okay, then the board will be fine with that. But you need to explain why you're doing something better and different so that we can evaluate it. And maybe we'll add it to what the ASF considers the Apache way. So today is a whole track of curated talks about the Apache way from different perspectives. In a lot of conferences in the past, we've had a single talk on it, which doesn't, it kind of gives you a little bit of all the pieces, but it doesn't answer your questions about how projects work. And it doesn't answer your questions about how new contributors should do this. And it doesn't really help. So today we have this, right after this will be a coffee break, which I'm looking forward to myself. At 1015 in this room, we have a tale of two developers, which will be a formal dialogue between two employees at a large company that I'm not going to name, one of whom is an experienced Apache contributor, and one of whom is an employee told to go join this project. And the teaching process of how a corporate contributor as an employee can learn how to work with Apache projects. At 1115, we have from dev to user to the Apache way, with Steve Blackman who's here in the room right now. And he's going to tell a story about how an existing project community outside of Apache came to Apache, came to the incubator, and changed how they work together as a community to better work with Apache, and to find ways to draw in new people. Some simple things and some harder things. And of course we save the tough stuff for before lunch. At 1215, we have a panel discussion on software is easy, but people are hard. So all the great coders on GitHub who think the latest technical challenges, like that's the hardest thing I'm going to solve. No, the hardest thing you're always going to solve in an interesting situation is how to get people to work together on that technical challenge, or that voting campaign, or anything really. Lunch is on your own today. And then after lunch, come back please, because we have another panel discussion, the Apache Way for Business with Nick Birch, who's a very engaging speaker, so he will keep you awake after lunch, I guarantee. How your company, who might want to have a project that you want to bring to Apache, how your company needs to think about structuring the project. Not just your employees, but your marketing department, your product manager, how you're going to transfer control and gain the benefits of coming to Apache. And at 330, we have Sharon Foga, who will be talking about how contributions at Apache are not just code. Everything else is important too, documentation. Answering user questions on the user list, or providing helpful bug reports, are all things that are valued. And ways that you as an individual, whether you're an employee, or whether you're working on your own, or you're a college student, the little ways you can get started and get some recognition in our projects. And of course this evening we have a couple of keynotes. Some talks about IoT from the Apache IoT conference here, some machine learning, and then a great talk about the last keynotes related to this, how Comcast and their developers and some of their projects that were donated to the ASF got some efficiencies from working in our way. And of course at 5.50, after the keynote, stay tuned for the lightning talks that Jim and I will be hosting, which will be guaranteed fun five minutes. You can talk about whatever you want, but no slides. And we time you. So let's talk about our topic here, the Apache way. And I think the important thing is defining the behaviors. But first let's take one pause for Apache way history. I've reviewed most of the past probably ten years of presentations about the Apache way, and they all start with how the ASF was created as a corporation, how PMCs were organized, and we sort of thought through the rules, or we grew the rules as we did things, and the history of the organization or projects in the way. But that's not what I want to talk about. Because what is history matter now? When you come here to learn what you can do, how you can make your project better, how you can get involved. And I think what's important here is learning what the behaviors are, learning the actual actionable information, as we'd say in a corporate speak slide deck. What can I do to help my project gain new contributors, to make it more friendly, to answer the board's question, because they were upset with us for something. So I don't want to talk about the history. I don't want to talk about the past or the rationale here. Now, I do have a question. We're just skipping all that history and all the past information. Do you think that's a completely good thing, or do you think we're missing something if we just skip that? Do you just want the actionable information, or do you want the history, too? So that's something I'm just going to leave you to think about. Throughout the day, I think a lot of our talks later in the day will answer those questions for the points they bring up. Like Steve will talk about, we had a great project community, we came to Apache, and we needed to change things. And after we did it, oh, that's why this is better. We got more people interested because he learned the history. But the history doesn't help you unless you've seen the actual example. So let's move on. And we have a menu of services today. So what behaviors do we want to talk about? So you can call me lazy if you want, but I'm going to make you do the work because Apache is participatory. So I have five topics, and then questions to answer is not really a topic, that's just Q&A at the end. Community is a topic over code, which we say we believe in. Merit, recognizing an individual's work, and what comes from that. Open development, which the ASF requires for everything, that's just how we do any of our work. Decision making, how we get consensus and how we use votes. And communication. So today we're lucky because we can communicate in person, we can talk to each other, but usually we write at each other or type at each other. So that's a different aspect. So I'm not going to do this slide, you guys are going to do this slide. What topic do you want to talk about first? So is there something that somebody has a particular question for one of their projects, or you're just dying to hear first, or don't make me pick a random topic, because I do some... Decision making. Okay, I should have thought of that. I should have thought that that would be... Good, nice, I like that. Decision making, how do we make decisions for our Apache projects? So one important thing is consensus. We talk about how we want to have consensus-based decision making. There is no perfection in software. Things are never finished. But things can get better step by step. So fundamentally, at Apache Projects, our goal is to serve the public good with software that does stuff. So any new features from you over there or you over there or you in the back, they're probably good things. So we don't all have to agree on some new addition as long as it's good enough, or as long as it doesn't make our tests fail. Because what you might think is really important, I might not care, I might not... Who cares? But okay, you can still add it, because you care. It's valuable to someone. So that's why we want to get consensus enough, like okay, this is good enough, but we really should think about changing the API that way, because this would be better. Okay, we'll discuss it a little bit. So that does make you take a little bit longer to develop things, but you end up with a better product in the end. Or sometimes you end up with a bunch of things that are put together that some I care about and some you care about, and that's okay. So when we do need to have votes, we do have them. So they're here two quotes about voting in the Apache way. So the first one is voting is a shortcut. So sorry, let me pause. Voting is the plus one, minus one, sometimes plus or minus zero, where plus one means yes, that's a good idea, and I'll help you do it. Minus one means no, I don't agree, and here's why I don't agree. You have to say why, and there has to be a reason that people can recognize, not just because you don't like it, or because it doesn't help you. So voting is a shortcut to move consensus forward in a timely manner. So that's one aspect of voting, when we're deciding things. Another aspect is voting is a way to record an official consensus. So one of these quotes is what is good, and we want to see it. In fact, we have to see it. It's required. And the other quote is okay, but it's not really the best way to proceed. Anybody know the obvious answer? Which one is definitely right? Which one is important? So the second one, recording official consensus, that's required. That is a good way of using votes. When a PMC makes a release, we have a formal vote, and that is the PMC as part of the foundation saying as their role of people working for the foundation, this release is appropriate, and it's a good thing to put out to the public. And that, or deciding on new committers or PMC members, you specifically gain a recorded vote that says okay, this is done. That means those actions, you're not doing those as yourself. You're doing those actions on behalf of the ASF, which hopefully will never matter, but if there ever is a lawsuit, that is how we provide a legal shield for everyone. It's also how the board can provide oversight to say, yes, the PMC has decided on this. That's what we're doing. Okay, we can see the list. We can see the vote. You're done. You might change your mind later, but you'll record how you do that. So the first quote, voting is a shortcut. If you really can't decide, then sometimes you need to have a vote to say, okay, do we really have enough people who will agree, and maybe you'll get a lot of plus ones, and you'll get a bunch of plus or minus zeros, people who aren't really happy, but they don't have a veto, they don't have a reason to stop the new action. And there are some projects, let me say, there are some projects that happily use votes for a lot of different things on the new roadmap and a new feature set, and they like using votes. It works for their community, it's documented, and it's expected. And that's okay. That works for your community, great. But if your community can't get consensus repeatedly and turn, falls back to using a vote to force something through, that's not healthy. So we want to speed up the decision-making process with vote sometimes. Well, in the Apache way, there is a timeline for decisions. And our timeline is not, it must be done by the end of the quarter, like in a company. Our timeline is, you can't finish this decision until at least 72 hours have passed. So we all come from around the world. I don't know if there's anybody actually from Australia or down under or the Far East in the room right now who lives there, but we have several little Metapachicon. Ensuring that any vote is open for at least 72 hours means that people can see their vote, have time to respond, even if it's over a weekend or something. Yes? Yes, you should be cautious of major holidays in different geographies that your community has. And it's certainly always good to wait longer than 72 hours if it's a big decision. It's also a good reason why you have a discussion thread. If you want to have this crazy new architecture, well, discuss it for a while. And then once people have kind of said, okay, that's good. We've solidified some things. It's not completely done, but it's close. And people have had time to talk about it. Then have a vote thread, right? Because people have had time to digest. And the people we're talking about are from around the world, from different backgrounds. So this is a complete opposite from the corporate world many of us work in. There are no deadlines, or there are very few deadlines at Apache. Because we as a project don't have any deadlines to get something done by, except those that we agree to do together. So we all volunteer from the Apache perspective. You're all volunteering. You're all being super nice to give us all this great code. We can't ask you to do something on time. So if the community decides, yes, we want to get this release out by X, because our users want it, and we're going to put the effort in, great. But that's up to the community to decide together. So that brings us on to back to the venue. So we've done decision making. So where do we want to go today? I'm not sure if I should use that phrase here, but communication. Okay, communication. How are we right? So as I said, we're lucky today to be able to talk in person, and there's a lot of richness, but almost all the time we're typing, and we're typing from our little offices or our beachside patio if we're here in Miami, or from our bed at night after everybody else has gone to sleep. So it's important to remember that when everybody else is reading their little screen, they're in a very different world. So don't be a jerk. That's, you know, the really cheap way to say it, and this is the way that many of the early Apache wayslides said it. Avoid the poisonous people. Now we can't always avoid them. We, like I can't, and you maybe can't because they send mails and they're in your list, but we as a community can work to mitigate the damage they can do. We can not feed the trolls, all those things. It's still a good, it's a little bit long, but it's still a good talk by Brian Fitzpatrick and I can't remember his name. How open source projects survive poisonous people, but that is still a talk worth listening to. Whether you're in a Apache project or anywhere else where it's, you know, people choosing to gather together rather than at a company where you're told what to do. So we can't emphasize this one enough. We have a code of conduct at the ASF. Thank you to the CouchDB project that originally drafted one in a very thoughtful way as a community focused on the behaviors, not on the people or the whatever. So it's a good thing. It's not something we want to use. It's not something we want to say, this is a code of conduct violation. It's something we hope that communities can, you know, surface as an expected way that they communicate and that when you communicate, remember to hold that in yourself, even if someone else is not, try to respond politely. I know that's hard, but... And the other one is when someone is regularly abusing or what you feel might be abusing, but you're not sure, in a project community, work with the rest of the project community to address it and ask the question. Whether that happens, that's one of the few things that if you're really not comfortable having it happen on the public development list, ask a few people you know in private. And the great majority of the time, even if you're worried about the feedback, if you ask in private, you'll find, yes, other people are exactly in the same situation you are. They have exactly the same thought and they're like, I just don't have the energy to call on this. And once you find that there are three other people who are like, I don't have the energy. I'm like, that's exactly what I thought. Then one of you can bring it up and you know there are people who are agreeing with you, who are saying we need to be polite and respectful of everyone else and we need to focus on the project work, not on whatever else in the world there is. And language for communication. This is not a slide I'm happy about in terms of what we do, but I think this is the reality. The at Apache, the Apache way the methods can be applied elsewhere, but at Apache, as we practice it at the ASF, the core development activity in a project must be in English. And at the current time there's no way around that. And we've had a couple of real questions where we've had projects in other languages with primary developers there and we can't bring them in for incubation because translation software isn't social. You can't just read a mailing list and put it through Google Translate or Bing Translate and then expect to be able to evaluate what's happening. And the most important thing for a community is that the PMC can provide oversight to the community. That the PMC as a whole knows what's happening, can give feedback on crazy ideas from committers, can make a decision to make a release or wait, can make a decision to add a new committer who's been contributing code. If the PMC as a whole can't understand the process by which that work happens, they can't make an informed decision. And in particular, the board needs to be able to provide oversight for all of our projects. So when we have a project report, projects report quarterly to the board and the board reads all the reports. We have a board meeting today later, actually. When the board, when the director has a question about a project report, we will go into your lists, we'll go into your private list and we'll review the past several months of traffic to see, you know, you said something kind of funny in the report, I want to see if you're going off the rails or if maybe there's a reason for it. And if the board can't provide that oversight, we can't operate. And the board currently, we all share English as a common language. So in terms of development activity, we can certainly support user lists, answering questions for multiple languages. And of course, developing software that has language packs and so on is fine. But the way the project moves its activity forward must be in English. So that was communication. Communication was kind of simple because that's sort of just working online and working in email. And remembering everybody else is looking at a screen like this, right? So we're doing the last two. We've got the first three. Where do we go next? Community. Oh, okay. Well, that's pretty obvious, I suppose. There we go. Well, so that's a really good word, community. So we all have many communities. It's like a gigantic Venn diagram of millions of overlapping circles. So what do we mean by community? So we don't live together. Most of us don't work together. Many of us don't know each other until we've met today. Hi, I'm Shane, by the way. Nice to meet you all. Glad to see you. Except through our project. So this is a different... open source development is in some ways a different human activity than virtually any other activity in human history. And that we can all work constructively in a very, very rich way on realistic tasks completely anonymously online from anywhere in the world at any time in the world. And it's hard to remember that the project community, all the members of it, all have their own communities of communities and that we're coming together for this one software thing. So it's through our projects that we know each other. And that's the community when we're talking about an Apache Way community. And that includes the developers, writers for documentation testers, sysadmins, devops, and users. So the people who are not always obvious in an Apache community are the users who are using it and who might be frustrated but haven't gotten around yet to reporting a bug or who are gonna try and sell their boss on using this for everything. So those are great projects like some of the ones we have really engage users and make it easier for users to get help, have forums, you know, have an ecosystem of developers or consultants who can provide other services to you around the project separately. But we need to think about that whole community and that's what the goal is to serve that whole community with the best software we can. So, yeah, this comes back. But this is a different message than no jerks allowed earlier in that Apache communities value group contributors, not lone wolves. So Apache is different than a number of other foundations or common or popular open source projects in that BDFLs, benevolent dictators, are not allowed. We will not accept projects who act that way. And the board is here to backstop PMCs who, you know, if you're a PMC for some strange reason, find somebody who looks like they're trying to crown themselves king. The board will prevent that because that is not, in our view, a healthy, long-lived community because it doesn't allow, it doesn't make it welcoming for new contributors. If you perceive that this, this is one person you won't be accepted. It's the same way with companies. If it's perceived that one company runs a project, then why would other companies ever have their engineers contribute? Why would they consider using this? Because the other company has a lot of luck. So that's why we need a diverse community. And your primary goal for the really big picture is attract new contributors. That's how you have a long-lived project. So, in the immortal words of Bill and Ted, be excellent to each other. That's... I don't know how to say it. And it's being respectful of everyone else. And it's also focusing on the work of the project. So other discussions, some projects have a social community, too. But that's not necessarily part of how we need to build software. So the other question sometimes is keeping the discussion focused on what the project really needs. So for a community, we all wear different hats. So for those who aren't aware, hats are sort of the symbol for who you're speaking on behalf of. Are you Shane, the Hawaiian shirt guy? Are you Shane, the currently unemployed house husband and father? Are you Dan, who works for Big Company? Or are you a director of the ASF who is telling a project they shouldn't be doing something? What role are you taking when you are speaking or typing on a list? So that's doubly important for anyone in a corporate setting because Apache does not recognize corporate contributions. We have a sponsorship program with money. That's separate. We recognize actions. You are all you when you're coming to an Apache list and contributing and we recognize you as an individual. So for corporate teams, which we have many of, a side effect is that if your corporation wants to work on a project, each of your individual engineers or managers or product development people, we don't see them as a team. Apache sees them as a bunch of different people. They each need to do their own work to gain merit, which is one thing. And a side effect is that your actions reflect on you throughout your personal career, not just when you're at one company. So it's important, sometimes you do need to speak for your company. You need to say, my company has this really serious bug and we have other customers and we, you know, I'm going to work on this in the project and I hope other people will. But the rest of the time we expect you to be speaking for the benefit of the project as a whole. Which is, I sort of got these slides backwards perhaps, check your affiliations at the door. So when we make decisions at an Apache project, there's not a hierarchy within a project. It's not the chair of the PMC and then the senior members of the PMC and the rest of the PMC and then committers. It's the PMC and it's the committers. That's the decision level of the project. That's the final vote. And every project has a completely separate way of doing things. So the other aspect of this is that your fellow PMC members, when you're interacting on the project list about the project, we don't care what company you work for usually. We don't care what role you have at your company. So we actually have airline pilots and major financial company CTOs and directors who are committers on Apache projects. That doesn't matter on the project. What matters is how they act in the project space and what job they do there. So the upshot of the hats and affiliation and having a flat PMC is that part of the Apache way that is required of all projects is that the project is governed independently of undue commercial influence. The way that we enforce this is that the ASF owns all trademarks on behalf of the projects. And the board of Apache will ensure that if a PMC goes off the rails, or if some company tries to subvert a project, the board can step in unilaterally and fix that. Now, that is not a pretty sight and you don't want it to happen, but it rarely happens. So hopefully we won't have to talk about it. But your project, you own your brand and your how you interact with the world and your code and you own your own governance as long as you are independent, as long as when new contributors to your project show up and do valuable work that they're recognized on their contributions and not on their corporate affiliation. So there are some times where it's easier when you, you know, one of your teammates happens to be a new contributor and it's, oh, you know them and you want to vote them in as a committer quickly because you can explain all the good things about them. The project hasn't seen that. The project hasn't seen the things that you've seen as being a co-worker of theirs. So that's one thing to look out for. And the other one is where great committers from this consultancy and this other competitor of the major company in the area put in a lot of work to the project but never get recognized by the PMC. Nobody in the PMC chooses to vote them in as committers. And it's, it's rarely ever planned but there clearly have been cases where many of the PMC members who work for the dominant vendor simply choose not to recognize them. And that is not good because that will then discourage anyone else from contributing. And that is something the board pays attention to. It's not a hierarchy. It's a community. In the context of this project community. Separate from your employers and the rest of the world. So that's what I have on community. So we have Merit and Open Development next. Open Development. Okay. She's been paying attention. Wants to speed things up here. Open Development. So just one quick reminder when you're thinking of this. We all kind of know what open source is. We have an esoteric debate on the legality of the term perhaps. We're talking about Open Development where in the process of creating the software is explicitly open. It's also open source but that's the point here. So yes, we use mailing lists to Apache. And sometimes they're annoying but that's how we do it. Because mailing lists are asynchronous communication. So we're a community about a project. We're a community in this room. And we come from all around the world. We come from day jobs that are nine to five. We come from DevOps people who work on shift off shift. We come from college students and people who are unemployed and do this as a hobby. So ensuring that we don't make decisions today. We're not going to decide a new aspect of the Apache way here in the room. We might talk about one but then we bring it back to the list and let the broader community think about it. So when we only know each other through the project we need to make sure everyone else has a chance to respond to our great new idea. So archiving everything is another big thing in Apache. If it didn't happen on the list then it didn't happen. That's an old adage at the ASF wherein in the big picture if something wasn't surfaced on the list then we don't consider it a proper action of the project. Because the board can't provide oversight or your PMC can't provide oversight if it was a group of committers. Newcomers to your list or newcomers to your project can't learn about what happened. They can't suddenly a bunch of code showed up. They don't know where it came from or why. They never had a chance to participate in the development of that thing. So having everything in a public list in particular is important because that allows everyone else to everyone else to see both today as it's happening and in the future when people can come by and say to themselves well I don't want to ask about this stupid question. But if they look in the list archives they can see how you've got some place. So making sure that we have an archive of everything is important for bringing in newcomers and it's important for community members because we have arguments in a year from today about what happened and somebody will say oh, here's what we decided on the list. Or you have a clear reference of what the group decided. So a key part of this is both motivations and decisions. So we need to have transparent decision making. So we each have our own motivations for being here. I'm here because I love Apache. Some of you are here because you work for your employer and it's important to play with Apache projects. Some of you are here because you work on five Apache projects and you want to learn. All those motivations are invisible to the rest of us. I mean even more so than when you're at work, when you're at a company you and all your coworkers and your bosses you all understand the company direction. We all are completely separate individuals. We only see the work through the project. So it's doubly important to make sure that we telegraph what we're thinking about for the project. So I was just talking yesterday and I want to figure out a better way to write this list. A really concise list that we can just post someplace. The best way to work in an Apache project is telegraph your intent. I've got a great new idea. Maybe if we switch from Json to YAML we could make it faster. I don't know. Put that on the list. Crazy idea. Then, wait a little while. Draft a design. Say, hey, here's how the API would work. I'd use this parser. Put that on the list. Let people see the process. Because you're part of a community. Other people are going to have feedback. Sometimes other people are going to say, oh, I've already done that. Just copy this. When you're working on your code check in early. Check in often. Submit work in chunks. Submit. Here's the API level. It's all the thing. It's a basic test, but there's no code in it. Now I'm going to code all the file modules so people can see, oh, here's how you're actually using the format. Doing a giant code dump is not helpful because no one can review 50 code modules that are brand new as a code review. Which some projects do. Some projects don't. That's fine. Doing each of those steps on the list gives the rest of the community time for feedback. Time for new ideas. Time to help you with your work. So that is important for all Apache projects. And this is what we mean by open development. That the process is done on the public dev list. And I wasn't quite sure where to put the license. But I think it kind of falls under open development as Apache is pragmatic about licenses. So we use the Apache license in 2.0. That's period. We have a very specific list of other licenses that are allowed as subsidiary bits, but everything that comes from Apache is under the Apache license. The point of doing that, which sometimes we've, you know, every couple of months we have a project saying, oh, we really want to use this library. It's the best one out there, but it's GPL or it's this or that. No, sorry. And they're like, but it's easier. I'm like, yes, but it does not meet our goals as a foundation, as the ASF, as the Apache brand does not meet our goals of maximum user freedom. When we give out software, we give it out for the public good. And when it push comes to shove, that's a key way to decide things in Apache is does it help the public good? So the benefit of that is that people can then use our software any way they want. And the real benefit is using the Apache license on everything makes it super easy to consume us anywhere, and encourages the maximum inbound contributions. Because that's what we want for a long-lived project, is new contributors. And this makes it easy. Anyone can contribute to us. I suppose if you only use the GPL then you can't, but we want anyone to contribute because then they can simply take the code back. Right? Share it. And part of the reason that the foundation is important is that people have trust in the brand and the they know what to expect from Apache projects. Because we always use this license, we always provide the code, we always do open development. Even one of the things longevity of software projects, we may not care about struts or Wicked anymore, because they're kind of old, there's so many new JavaScript frameworks, whatever. People still run them. People still want them. Even if they serve a need for them. Even if the struts PMC goes away and we move the project to the attic, because they can't actively oversee the project. The ASF will always provide the complete history, all the source code, all the past releases, all the development discussions, all the lists, as long as the ASF is around. Another key part about Apache is that we will always be here. If you compare that to something on GitHub, who knows if some developer is going to disappear or in the left pad case, if some developer is going to get annoyed and simply take their code away. Apache will never take the code away. That is what I have for open decisions. Open development. And merit. We're going to have to do merit quickly, which is kind of funny because we are close to the end, right? Ten minutes. So merit is about recognizing your work. And some communities some people don't like Apache because they think meritocracy and then they think some sort of strange social construct that is inappropriate. Which is not what we really do in Apache. For us, merit is really it's defined by the value that you as an individual bring to a specific project. And it's defined in the context of that project by the rest of the project community. So it doesn't matter if you're an architect or if you're a GWIS developer and it doesn't matter if you're a suit. That's not part of your merit. And it doesn't matter what you talk about what you blog about, what you've done in the past what you've done in other projects. What matters is what you've done in this project community that defines your merit. And it's defined by the peers of that community, not by anyone else. Every project has their own merit structure. So recognition in one project doesn't matter for other projects. Now obviously if you're a long-term Apache commuter on some project you can see your history clearly and they can see you acted well with the project you fit in. That helps, but it doesn't give you merit to change code changes in their project. A growth in merit is users and contributors who give us stuff. We love them. Thank you. You get voted in as a committer. A committer means that for that project you get voted in by the PMC you have commit rights to that project's repositories. Now they may have a commit then review or review then commit, but you have right access. That's the first important step. The second important step is the PMC may elect you as a PMC member. As a PMC member you can vote on releases and you can propose and vote on new committers or PMC members. Excuse me. There's sort of another level of merit that's really that important is a PMC chair or the vice president of the project. They're not... I made them not bold because they're really sort of a secretary. Their job is to communicate between the PMC as a whole and the board and ensure that the board report is submitted, but they're not meant to be a leader of the project. Everyone helps lead the project. Some people are elected to membership in the ASF corporation. That's nice and it's a good honor, big honor, but it has nothing to do with projects really. It's recognizing your work in many projects, but it doesn't give you any abilities there. And then we have directors who are elected by the membership to serve on the board of the corporation and that provides oversight for the PMCs. So we're still part of a community that's very flat. We're not a hierarchy. So everyone with a commit bit on your project has some say in the code on that project and can add their own new code to it. Everyone with PMC membership can vote on that project's issues. So merit is not authority. You can't say this is what we're going to do. You still need some consensus. But merit does get you privileges. It lets you take actions in the project and it lets you have a binding vote or binding say in some things within a project. So one problem area and I'm just about done is umbrella projects. Which I put in merit because we have several examples. One is Jakarta which is long back in history. Jakarta was an early project at the ASF that had a lot of different Java technologies and then kept growing. It was great because Java was cool beans and it was going to run the world everywhere, right once, run well, hopefully. There were so many different components and modules and sub-projects within Jakarta that the communities of people working on each of them diverge. And that's a problem because the PMC needs to provide oversight and governance for the project. So if the PMC as a whole can't evaluate is this project is this sub-project, this part acting appropriately? Are there any great new committers? Like a release. If the PMC as a whole can't evaluate each of the different bits of software they're making that's too big. They're becoming a board above several projects. And that's just, it's not efficient. It's also difficult to ensure that the Apache way and the corporate responsibilities we have are being held to the same standard. So that is why we tend not to have umbrella projects because each community needs to be focused on a set of tasks that in general the community members, the PMC members and committers all can have some effect on. Or at least can evaluate the work of on going forward. And that way they can provide feedback on things. And when projects get bigger than that we tend to simply say, well, you know, why don't you split up into two projects? No big deal. And that is merit. So if we take a different way we will do a lovely beach scene. And we will go to questions. So these slides are online. I'll tweet them out again later. And indeed the whole of the Apache.org website is online and is open to all committers. Of course only members can actually publish the top of a website. But this is an area where we need you to help out. So anytime that you are reading a piece of documentation on any Apache project that doesn't make sense, please ask about it. And if you can, if you get an answer submit a change for that documentation. That's one thing I think sometimes we fall back whether we're in a hurry or whatever to simply asking a question somebody gives us the answer like, oh, okay, great. And we go off and do our thing. Any time that we can change that and say, great, here's the patch to add that FAQ. Or, hey, I know this step of the install instructions are wrong. Submit the patch. That's just something that we, some projects do a great job of. A lot of projects not as much. The foundation website itself I'm not going to say anything there. And separately I have the Apache website that I've written. It's my perspective on all this kind of thing. That goes into a lot of the history and rationale of all these behaviors. So that also is open source and I'm happy to take full requests. So, questions. So we have, it's the end of the session. Okay. So I'm happy for a quick question and I'm also going to be here for the rest of the conference obviously. So, thank you.