 Wow. So it's really an honor to get to speak with you today and it's always exciting to see the Apache Software Foundation grow in ways that we never even imagined when we started it. And you know this is one of the really exciting projects within the foundation. I want to talk with you briefly about the Apache Software Foundation which of course Mesaus is a part of. And there are things that happen within your project that may seem a little bit arbitrary. And so understanding a bit about the foundation and its history is can be really informative as you see those things happen. The Apache way that we call you know this thing that we call the Apache way is a number of things. It's a governance method. It's a way of running communities. It's a belief that your community is more important than your code. And so these sorts of gatherings are so important to bring your community together. So looking back 20 years, a group of people gathered around a piece of source code and created this foundation. And so here's this picture from our very first Apache Con in 1998. And they were specifically scratching their own itch. They were trying to get something working that was broken. Brian Bellendorf brought this group of people together because his website was running on an abandoned piece of software and he wanted that to work. So he got several of his friends together to ensure that they could fix the problems. But one of the things that was very critical to him is that whatever software they came up with, he wanted to be able to use that if he moved to another employer. He didn't want it to be locked in. He wanted this to be something that was independent from any one organization. So here's that same group of people 20 years later at our reunion party in Austin. And most of these people are no longer involved in the project but those principles that they put in place govern how we do things within the foundation. One of the things that is in our roots is this notion of bottom-up leadership that we lead by example rather than passing down edicts from the board. The web server project has grown a little bit but what's grown even more is the Apache Software Foundation as a whole. We've grown from one project on day one to now 315 projects as of last week's board meeting. Our project, the project that I started with, has grown from those eight initial contributors to 118 contributors. Probably a dozen or two that are active on any given month. And we add new members every year just as your project adds new members every year. The principles by which we operate are, these are the three most important ones in that squinty font up there. I wonder, yeah I need to fix that. Anyway, so collaborative decision making is very critical. Having a flat organization so that everyone has an equal voice and being able to resolve conflicts without destroying relationships. Pierre Giorgio gave a great talk yesterday about how our governance model allows people to disagree violently in public while not destroying their personal relationships. You know there's a lot of other governance models in open source that are perfectly valid but we've chosen a model that reflects Brian's initial desires that things were done by collaborative decision making. Now at the foundation level we have this this mission statement which I imagine that you've seen and I am not going to read to you, we have our vision statement, but the the core parts of this are consensus-based decision making and ensuring that we from the beginning our desire was to create reference implementations of important technology and lead the world by example. Mesos is one of the great examples of how that's actually happened. You people here have created and led an industry that didn't exist before you came along. The legal structure of the foundation is that we have a board of directors and the membership elects other members and the board of governors, the board of directors is responsible for the legal aspects of the foundation, but you know the ASF exists as a legal entity so that we can raise money to do events like this and ApacheCon and handle the infrastructure needs of our projects, but we've created a management structure that tries to completely separate technical decision making from organizational governance and so the the board of directors and the membership, the membership elects the board of directors to handle the governance aspects of the foundation but the board stays completely out of the way when it comes to technical decision making on projects that's left entirely up to the project. Every once in a while the board will step in when a project goes seriously off the rails. Fortunately, on 20 years we've only had to do that twice and you know it's not something that we take lightly. From the project's perspective, the project should see the foundation primarily as a service provider. We provide infrastructure support, legal support, financial support where necessary and as a as mentoring so that those of us that that have been around for 20 some years and have seen projects that are healthy as well as projects that are unhealthy can maybe offer some advice, some guidance, but not not direction by edict. Projects are responsible for their own code. They're responsible for their internal governance structures so Ben mentioned a moment ago that within the MESOS project when someone is made a committer they are also made a PMC member at the same time. That's something that varies greatly from one project to another. Some projects will select committers and then not make them part of the project management committee until possibly years later and this is something that's left up to the projects. Another core principle that we have at Apache that some people can see as being old-fashioned is the notion that everything has to happen on the mailing list, but there's some very specific reasons why we have done this. One is to ensure that there are no private conversations around important project decisions. It's all in the open, complete transparency so that you don't have decisions about your project happening in the boardroom at MESOSphere. That's not allowed and because we have companies like MESOSphere that understand this, your project can be healthy and community-led. It's also to ensure that people who are not in your time zone and don't speak your language can participate as equal people on your mailing list out of band. They can translate, they can participate in another time zone, it doesn't have to be synchronous. We chose open source at the very beginning of the project because we wanted to ensure that there was no vendor lock-in, that projects controlled their own destiny and were not controlled by a corporation, and that there was direct user input that you don't tend to get when decisions are made in closed source projects. Out of that came the Apache license which codified some of these things. It was based directly on the MIT and BSD licenses and this also further ensured that not only were projects independent, but that companies could then take that code and build their businesses on top of it. We've tried to be very business friendly from the very early days. As a result of this, you see Apache code in absolutely everything. If you look where that red line is, you'll see Apache. This is the load screen of Minecraft. I just picked something randomly here, but every time you run Minecraft, you'll see that it's using Apache Commons libraries under the hood. That's because we've used this licensing model that allows this to be used absolutely everywhere. The Apache way works because we believe very strongly in individual merit. Individuals come to our project as individuals. They grow in the community's trust and appreciation and then they're given the reins. Transparency allows our projects to be developed completely in the open, ensuring that everyone can contribute on an equal playing field. We believe that great software is an emergent property of great communities and therefore we place community health even over the software's health. When we evaluate a project as the board, we're concerned primarily about the health of the community and less so about the code quality because that's up to the project themselves. We believe that the results of this are vendor neutrality, increased diversity of projects, which is something that we continue to strive towards, that the software that's produced can be trusted and safe. The best ideas are what wins rather than the people with the loudest voice. You can propose your ideas, you can turn them into code, and you can vote with your commits. The concept of merit has also been very core to the way that our communities evolve over the years and this is another place where projects determine independently what merit means, whether it means number of commits or code quality or the value, the quality of your ideas, but it's important to remember that it's not just code that matters within projects. It's people that write documentation, it's people that put on conferences, people that design your logos and your websites, and all of these things are equally important to the health and longevity of projects. Community over code is one of our sayings and it's shorthand for saying that the community matters more than the code. A sustainable community leads to code that you can depend on, but good code all by itself isn't sustainable because the world changes every day. Collaborative development is another way that ensures that projects are sustainable and are not simply the work of one person that could decide to go work on something else tomorrow. Now, I mentioned earlier that there are some things in the governance of your project that may seem a little bit weird when you first come to it. I hope that showing you some of the history of where the foundation came from will explain some of those things. People that come to Apache projects from elsewhere in the open source world have this notion that Apache has way too many rules, too many restrictions, and we hear this from a lot of projects, particularly as they go through the incubator. Once again, I hope that I've helped explain some of those things. We have very few actual rules. We have rules around how you use our trademarks because that's really all the foundation owns is our trademarks. We hold on to those and we protect the value of those, not just to have something, but so that we can be trusted, so that when people see the Apache mark on a project, they know that that stands for something, they know that that stands for quality and trust. That's very important to us to protect correct usage of our trademarks. That is a place where we have quite a few rules. Beyond that, we really don't like to, and we, the board, don't like to interfere on the way that projects manage themselves. We do, as I said, require that all projects conduct their business on mailing lists. Most projects have at least a user and developer mailing list. There's also a private mailing list that the project management committee can talk on about issues that are sensitive, such as electing new members to the project. However, the board keeps a look out on these private lists and tends to scold projects that have discussions on the private list that should really be public and transparent. So what do we control? We control our trademarks. We ensure that projects operate in a vendor-neutral way and are not being controlled by a particular company or organization. And we protect the provenance of our code, which is a fancy way of saying that we try to ensure that we don't have code in our releases that you're going to get sued for. We do have a number of non-coding teams within the Apache Software Foundation, and these can be thought of as services that we as the foundation offer to projects. We do offer infrastructure for all of our projects. We don't require that projects use our infrastructure, but it's available there when projects want it. We offer public relations and travel assistance to events. If you want to bring people to Mesa's Con and they can't afford to get there, you contact the travel assistance committee and we have funds to help that happen. We provide legal and trademark services, and we provide fundraising. And we have a table out here in the foyer where we've got community development people that can help do community-type activities. Nearly everybody that works at the foundation does so as a volunteer. We have many of us have very generous employers that let us spend our time speaking at events, traveling to events, and working on Apache code. We do have a few paid people. We have paid infrastructure support. We have a paid marketing department. Now, when you all came to the foundation, you came through the Apache incubator. So this is the main way that projects enter the foundation. At the moment, we have 60 projects that are in the incubator. And these projects are projects that have come from somewhere else and want to participate in what we have to offer at the foundation. They are learning how to run as an Apache project. And also during that process, we ensure that their code can in fact be released under the terms of the Apache software license legally. There are many, many ways that people can contribute to the foundation. And here's just a short list of them. Of course, most of the people that participate in projects are writing source code. But all of these other activities are equally important and ensure that projects keep moving along. One of the things that's built into the DNA of the foundation is mentorship. So this attractive gentleman here is Ken Core. He's the person that mentored me into the foundation all those years ago by encouraging me to do things that I didn't think I had the ability to do, like public speaking, for example. Mentoring is built into how the incubator works. And it's also built into the committer and PMC and project relationship as more implicitly that the existing members of a community bring on new contributors and teach them the ways of the project. Finally, I want to mention how organizations can contribute to the Apache Software Foundation. You all represent a large number of companies that owe your existence to the Mesaus code base. And there are many ways that your organization can help the health and success of Mesaus as well as the larger Apache Software Foundation. Your companies have generously sent you here and they pay for your time to work on the code. Companies can also sponsor the foundation if your company is interested in any way in sponsoring the Apache Software Foundation, come see me afterwards. And I can give you the details of how that actually operates. These are some of the organizations that sponsor the Apache Software Foundation. These are our platinum sponsors and each one of these organizations sponsors the foundation at $100,000 a year. There are also other levels of sponsorship all the way down to sponsoring us by giving 5% of your Amazon.com purchases to the foundation. So there's a variety of ways to sponsor. There are many reasons that companies sponsor the Apache Software Foundation and other open source foundations. And motivations vary greatly. People want to sponsor the foundation for altruistic reasons because they see that we're doing good things in the world, that we have projects that make the life better for people. And so they want to give back a little bit of what they're using, the value that they get from that software they want to give back. So there's altruism. There's also the practical and forward thinking aspects of companies that understand that their business model depends on the health of these projects. And so they sponsor the foundation to ensure that their business model will continue into the coming years. And these are the kinds of sponsors that we're particularly interested in because they understand that if they don't contribute to the health of this organization that a couple years from now these projects are no longer going to be around. And then of course we also have people that sponsor us because we link to them on our sponsorship page, which is an ongoing debate within the fundraising team at this time. The majority of funds that we take into the foundation go directly to infrastructure support. This is to run the source repositories, the mailing lists, the CI infrastructure, the web infrastructure, and on and on and on the various infrastructure needs. And the next biggest piece of the pie is publicity and marketing followed by legal services like brand management and various other administrative costs. So that's your lightning overview of the Apache Software Foundation. I know many of you already knew all of this. For those of you that are involved in MESOS but weren't aware of the larger foundation, please do come by the Apache booth out in the foyer here. If you have other questions, these are the places to go for that. Apache.org is of course our main website. And projects.apache.org will let you see the vast scope of projects ranging all the way from what you guys are doing on the infrastructure end to projects like Cordova that is used for creating mobile applications. Also, follow us on Twitter at the ASF to hear the news of our other projects when they do releases, when we're doing events, and so on. Thank you very much for listening. I hope you have a marvelous event. And it's really exciting to see this vibrant community that we never really even imagined when we started this whole journey 20 years ago. Thank you.