 OK, so we'll get started, because I know lunch is just after this session, so I don't want to stand between you and lunch. First, thank you so much for coming and fighting the elements, and to come on this side, the foreside of the OpenStack Summit. My name is Thierry Carras. I work for the OpenStack Foundation. And today I want to talk to you about what is OpenStack. So that may sound like an easy question, like a question that someone has been around since the beginning of OpenStack should be able to answer quickly and correctly. But it's actually more complicated than you think. There are lots of different ways to consider OpenStack. There are lots of different facets to consider. And we use the word OpenStack for so many different things that a deeper analysis is not superfluous. If people spot an OpenStack t-shirt on me on a random elevator somewhere or on a plane, flying somewhere else, they ask me, well, what is this OpenStack thing? And my usual elevator pitch answer to that question, simple question, is, well, it's an open source project. But it's an open source project. But that doesn't mean a lot, right? Like everyone is doing open source those days. There are lots of different ways to do open source, like some ways that are really, really close to properties of their development. So doesn't answer a lot of questions. And it's actually also not talking about what OpenStack actually is, what can it be using for? Is it something I should install, whatever? So to produce a more complete answer, you have to go deeper to the base motivation around OpenStack. At the bottom, OpenStack is a common goal. It's this idea that we need an open source software stack to build interoperable infrastructure platforms. And that goal is embodied in the OpenStack mission, which is, and I quote, to produce a ubiquitous open source computing platform that is easy to use, simple to implement, interoperable between deployments, works well at all scales, and meets the needs of users and operators of both public and private clouds. I can't remember it. So this mission, a number of organizations will lead behind that common goal. So OpenStack is also a coalition of organizations. If you're an organization that wants to deploy a public or a decently sized private cloud, and you're not Amazon or Google or Microsoft, then you probably don't really want to start from scratch. And there are also a lot of companies that kind of want to help you setting up those complex infrastructure. And so that means we have all those organizations that are interested in helping you getting there. Now it's not natural or easy for those organizations to actually collaborate to build something in common. They're usually competitors in the public marketplace. And so how do you facilitate that collaboration? And that's where the OpenStack Foundation plays in. So OpenStack is also a foundation. It's to federate that effort and to structure how we get things done in OpenStack. Small decoration on open source foundations. We usually talk about upstream and downstream. So I'll explain it a bit. Upstream is what we mean by producing the software, writing the code. And downstream is everything that goes after the production of the code. So users, deployers, packages, like people building product on top of it, those are all the downstream part. Those are two very different segments of open source usage. If you look at an open source foundation, it usually provides three different type of things. An asset lock, sharing downstream, and enabling upstream. On the asset lock side, the idea that it's difficult to get all those organizations to collaborate if one of them is holding the keys to the kingdom. If at any moment one single company has control over an asset that all those various companies rely on and can pull the carpet below their feet, they will not be 100% engaged, and they will always consider switching to something else or even worse. So it's really critical to provide the neutral venue for that neutral asset lock around key assets of the community. And the main asset that the OpenStack Foundation actually holds is the OpenStack trademark. So OpenStack is also a trademark. It controls what you can use the OpenStack name on. So what's allowed to use the OpenStack name, and what's not allowed to use the OpenStack name. And one thing that the OpenStack Foundation uses this trademark for is to foster interoperability. So OpenStack is also an interoperability standard. It's the fact that you should not be able to call yourself or whatever you deploy OpenStack if it doesn't have a basic level of interoperability with other things called OpenStack. And that's all the work that is the interoperability one group is driving in OpenStack was formerly called the DEFCO initiative. And that's an extremely important part of what OpenStack is. Now on the sharing downstream side, it's the idea that all those organizations need a lot of common work to get their things done. And the more you can share that downstream effort, the better it is. So it's the most obvious part of the work of the Foundation. OpenStack is also a set of events. We are here in Barcelona for the OpenStack Summit. So that's pretty visible. We run a conference. We run a design summit at the same time. We also run the OpenStack Academy in this building where you can learn about OpenStack and using OpenStack. So that's the visible part of the iceberg. We also run other events in OpenStack. We encourage the holding of OpenStack days all over the world. We're having them in every country that has significant OpenStack penetration. We also will, starting in 2017, organize a new event called the Project Team Gathering, which will replace the values mid-cycle we had for upstream project teams to get together. And we also hold operators mid-cycle. There is plenty of events that we actually organize at the OpenStack Foundation. Other co-marketing resources that are produced by the OpenStack Foundation include the user survey that is run every six months. It gives you an accurate picture of the state of the OpenStack market, but also white papers to describe specific use cases, the OpenStack certification program, and another type of like the marketplace website where you can reference your solutions, et cetera, et cetera. So those are all sharing downstream power things. Another important component of the downstream effort is that we have a very engaged operator community in OpenStack. I was in New York a few months ago and where the last operator's mid-cycle actually happened. And it's always refreshing to see how much they're ready to share between operators of OpenStack deployments, how much of those best practices emerge from the discussion they're having in a very open forum. And so it's really refreshing to see that grassroots community coming up together to actually help everyone have a better experience operating OpenStack deployments. So the third leg of the OpenStack Foundation work is enabling upstream. It's the idea that you should provide an environment for the open source upstream project to strive a healthy environment. And we do that by enabling an independent upstream. By independent upstream, I mean an open source project where the leadership is completely aligned with the contributors to the project. It's not influenced by appointed members from like sponsor companies or whatever. We felt really from the day zero in OpenStack, we thought to get that very independent technical governance in the project. And the key reason for that is that whenever your technical leadership is not completely aligned with the contributors to your project, you face the risk of a fork. Contributors can, if they are unhappy with the leadership, they will just take the code somewhere else under another governance, it's called a fork, and it happens quite often in the open source space. So by granting that the technical governance of the project is completely aligned with the contributors, we eliminate that risk. It's very healthy for any open source project that want to be long term. So that's a governance model that we're setting up. We are running elections. So contributors elect their project team leaders. All the contributors elect technical committee, which is the body that oversees the role of OpenStack deployment. Of OpenStack project team, sorry. And by running those elections every six months, we make sure that we have strong alignment between the contributors and the leadership of the project. And usually, I mean, it's not the only open source project that runs like this, but usually it takes a few bumps in the road before you realize it's the right thing. It's not that common that projects start from the beginning with this kind of governance model. So OpenStack is also a bit of social experiment. Please, for me, it's trying to prove that you can actually set up an open source project like this from day zero and have it successful in the marketplace. Another property of that governance model is that it places the developers at the very center of the game. Since you can't really influence OpenStack development by throwing money to random companies to get things done, you have to field contributors if you really want to influence the way it's going. And that means the developers are like a gateway to get your priorities into the OpenStack code and that places them at the center of the game in a way that creates a job market around OpenStack for upstream developers. And it's not uncommon for someone that's been involved in OpenStack to be employed by various companies and continue to work on exactly the same thing. Like, I know people that've switched companies five times already and still work on exactly the same piece of the OpenStack project. And I think that's a very healthy relationship because you can basically get employed by the companies that are the most aligned with your interest or location work, location, or that are friendly for working from home or friendly to like employing French people. That happens. And so having this job market around OpenStack is proven like a critical piece of the puzzle. So that speaks to the governance part. But what is OpenStack? Like, can I touch it? OpenStack is a set of projects. It's a lot of different projects. We have 31 service projects in the Newton release. It's a lot of different components. Some of them are pretty central, like Nova or Horizon. You will see them in every demo. Some other are very more optional. We saw VTRAGE in the keynote today, which is a new project we actually added recently. So it's a lot of different projects. But the important thing to remember, it's OpenStack is also a single project. It's a single project under a single governance model. All the projects are overseen by the technical committee. And the reason for that is we have to drive some commonality across those projects. If projects were completely independent, they might get very good at what they do. But the operator experience of running them together, like composing a solution with various components, if all the projects were to go in every direction, the user experience of deploying them together would be pretty poor. So the parallelist job of the technical committee is to try to have as much in common between those projects as you can, like relying on the same message queues and databases have the same log formats or configuration files so that operating them together doesn't become like a complete nightmare. And we do that at the technical committee. We do that by trying to enforce a set of principles. So OpenStack is also a set of principles. Mark Collier touched on those in this morning. I'll just repeat them. They all derive from the four opens. So open source, which means we're licensed and they're an open source license. That's pretty easy. Open development is the fact that all that's happening in the development is transparent. You can see every code change proposed. You can actually participate in reviewing them. You can propose code. You can also see the list of features that people work on. You can access the logs of the meetings. You can participate in the meetings. Everything is just happening in the open. There is no part of OpenStack development. If someone has a hidden meeting, then they are contradicting with the OpenStack principles and the technical committee would probably look at them and either remove them from the set of official OpenStack projects or warn them that they need to fix it really quickly. We also do open design. That's what we do at the design summit here and at the forum at the next OpenStack summit. It's the idea that we need to listen to all the community to set the direction of OpenStack. So we provide a venue for that type of feedback to happen. And finally, Open Community. It's the idea that anyone can rise to leadership positions in OpenStack. You don't have to be like a member of a platinum sponsor of the foundation to actually be part of the technical committee. It's like anyone can run for election and it's more your influence, your past contributions that will decide if you get elected or not. A lot of projects do open source today, like everyone does open source. Not so many of them do open development, but a lot of them do. It's pretty rare that they do open design. Most of the open source projects have some kind of a central group of developers that actually sets the direction and everyone else is there to just fix bugs. And Open Community is also something that we are fighting to keep because the newest open source foundations have a more direct link between the sponsors and the leadership to the project. And I think the way we set it up in OpenStack is the way that is the most long-term and healthy for long-term survival of our project. So in the end, OpenStack ends up being a development community. It's a set of people that are actually following the same principles and that are aligned to solve the same problems with the same mission. And there were always tension in the past about what should not be an OpenStack project. We had lots of projects that were proposed for inclusion in OpenStack and we had trouble saying no or yes to those people because we had to make a very early judgment on whether they're useful or if they're tackling an interesting problem. Are they going to be successful? And that was like a bet. You can't really decide if a project will be successful by just judging at the first code drops. So it was kind of a chicken and egg problem there. We could not really judge the project until they matured and we could not really mature a project unless it's official. So it created all kinds of problems. But if you take the angle of that development community, if you follow the OpenStack principles, you participate in the OpenStack Open development and you're aligned with the problem space you're tackling is aligned with the OpenStack mission, then you're basically part of the OpenStack community and you're basically part of OpenStack. And that's what motivated the project structural reform known as the Big Tent. It's the idea that if what you're working on is aligned with the OpenStack missions helps solving the OpenStack mission and you are following all the OpenStack principles, you are basically part of OpenStack and what you are producing is an OpenStack project. That at the bottom, OpenStack is a bunch of Python code. We originally chose Python because it's easy to learn. It's easy to read. It's operators friendly as well. It's a language that operators can interact with, look into the code, participate in bug fixing, et cetera. Was also very well supported in Linux distributions. So at the start of OpenStack, getting adopted by Linux distributions was pretty key to the early success of OpenStack. So that's why we all standardized on Python originally. Now there are other technologies that are coming up, especially GoLang and a lot of people kind of want to take advantage of those new technologies to produce efficient software in OpenStack. There are a number of things that Python is not optimal for and sometimes using other technologies is the answer at least from the development standpoint. What we need to be very careful about is the cost in terms of community. We got a lot by standardizing on Python because we have all those shared libraries, all this infrastructure that supports Python development. We have a lot of expertise shared across all the project around the Python language and where we need to open to new languages, we need to do it very conservatively so that we replicate what the success we had with Python with other languages. So we need to set up infrastructure that will help us test those GoLang things. We need to set up dependency management so that doesn't end up being free for all for in every direction so that all those Go projects that will come up in OpenStack in the future will share enough so that they don't constantly reinvent the wheel. And so we're open to new languages who just need to do it very conservatively and make sure that we analyze all the impact it may have on our community, not create two sides of the community, try to keep things together, have the infra team support the Go part and the Python part, et cetera, et cetera. So that's a lot of different things. For some of us, it's a completely different thing. OpenStack is none of those things. It's a way to produce software. It's a continuous integration system. It's the fact that we rely heavily on code reviews and get-it-commits and automated tests and cloud-based solution to actually test all those changes in real time that is defining OpenStack. We set up a pretty impressive system to drive to sustain OpenStack development. And I suspect tomorrow in the keynotes you might hear more about what we are doing there. But for some of us, it's really this way to produce software that will outlast OpenStack. Like, if OpenStack is not successful in a market in 10 years, the thing we've set up to support, the project infrastructure we have set up to support OpenStack development will be replicated in other projects because it's extremely efficient and results in a lot of quality in the end because we test all those changes, make sure that you don't introduce regressions. To give you an idea of the scale of the system, we're actually running 23,000 tests every single day in OpenStack. And those tests are not like one-minute tests. They run for 40 minutes and they will use about 1,000 virtual machines in five different OpenStack public clouds. And that means we are... With every single of those tests, we will deploy complete OpenStack clouds. It's a pretty massive continuous integration system that's been set up. And that also testaments to how active OpenStack development is. So OpenStack is also a very active open-source project. It's sometimes easy to forget because all the headlines are about containers, Docker, Kubernetes, and other things. It's difficult to remember how that OpenStack is also a very active open-source project. And if you actually compare the number of commits over the last year, well, the next kernel is the biggest open-source project there is currently and there are single governance, obviously. But if you add up all the project work and you add up all the packaging repositories that are official OpenStack projects plus all the supporting infrastructure, OpenStack activity is actually beyond the Linux kernel activity. Even if you just take the blue part of that graph, which is like the core project and service project, the key code that we are producing, it's actually way bigger than Kubernetes or Docker are currently. And that's number of commits over the last year. So it's sometimes easy to, you know, get lost in the headlines and forget that OpenStack is actually a massive open-source project currently. And it's also easy to forget that OpenStack is a success story. If you're deep into the trenches and I'm like deep into the trenches, like you see all the problems, you see all the paths you have ahead of you, all the difficulties you will face in the future. And it's sometimes easy to forget how much of a success story OpenStack is. I mean, it's running at Walmart, which is the biggest company in the world. It's running at the state grid in China, where it's serving 1.3 billion customers with electricity. It's running at the biggest car makers in the world, at the biggest utility companies, at the biggest telcos in the world. And so that's why it's important for us developers to come to those OpenStack summits and to be reminded that the work we are doing is actually appreciated and used by users. The user survey has NPS scores to try to track how happy people are with OpenStack. It's constantly rising. So obviously OpenStack is not perfect. You can see that it's a pretty chaotic way of producing software, but we are making progress and we should not forget that we have successes with OpenStack. And sometimes it's really easy for us, especially developers to forget that. So what is OpenStack? So it's all those things together, right? It's a common goal. It's a set of companies. It's a foundation. It's a set of principles, a lot of projects, single project, all those things together. It's, to me, it's a well-oiled machine to produce software. It's a way to produce infrastructure software and have it shared across multiple organizations as an open innovation. We are using this machine to produce infrastructure software and that's an integration engine. That means whatever technology comes next, OpenStack will be there to integrate it. Today, I mean, yesterday it was VMs, today it's containers, tomorrow it will be unicornals or something else. The idea is whatever technology comes next, the machine we've built to produce software will be there to integrate it tomorrow. Like, last week I think there was some project that was announced that wants to become an OpenStack project around deep learning because that's the new thing. And yeah, why not? I mean, it helps, there is a need for it. So why shouldn't we facilitate deep learning within an OpenStack infrastructure? So yes, OpenStack is all those things together. It's a well-oiled machine to produce software. It's an integration engine that will be there to integrate technology tomorrow to help you build infrastructure solutions. Thank you.