 But, first of all, it's time for us to get into our first headline keynote. And our first keynote speaker is someone who's spoken at OpenStack summits before. He's been involved in OpenStack for quite a while. He is on the OpenStack board of directors. And he's had many titles, but I just heard one that I think might be my favorite, which was the spiritual leader of OpenStack at Rackspace. So please help me welcome to the stage from Rackspace Troy Tillman. Wow, look at this room. It's an amazing sight to see. We have a lot to celebrate as a Rebel Alliance. We have more members. We have more active contributors. We still need more reviewers, but we've got a lot more capability. And most important, we've got more users. It's an amazing progress for four years. But unfortunately, we're really just at the first stage of this journey. Or as Han Solo said, that's no moon. We may not be facing the Death Star, but we're far from being able to declare victory on what we're trying to do here. We really just won the right to compete. And we know some large proprietary cloud vendors have earned that right too. And they're pushing their version of the future, and it doesn't include open source. The top three proprietary cloud vendors have committed to spend $25 billion on cloud in 2014 alone. And they've got money from their established revenue streams to fund that investment. They've also got thousands of developers. So we may have our thousands, but they're bringing them too. And they don't worry about trying to achieve consensus. They execute relentlessly. So we've got some pretty stiff headwinds. But I think that the battle's far from over. You know, it reminds me, I guess it's good to reflect back to the 90s. This was not my first software job, but I was at Sun Microsystems. Working on Solaris when I first heard of something called Linux. It sounded like a really interesting science project. But I mean, it was obvious that Solaris was dominating the Unix space, Windows was rising on the server side, everybody just wanted stability. Nobody needed to innovate. It was an operating system. They'd been around forever. But you know what? The internet was emerging, and it was changing everything. And the next thing we know, Linux is crucial to the ecosystem that we all depend on. I think OpenStack is in one of those moments right now. People are saying we don't need to innovate, but the world is changing again. You just heard it from Jonathan. We're moving to a software-defined world that is going to change things in ways we can't imagine, so we're certainly not done. And that's why I think OpenStack can be something much more. I've used a term as I start thinking about this called the planet scale cloud operating system. This is really a vision that is much bigger than one single cloud that battles it out feature by feature with everybody else. What we're really talking about here is the future of the concept of cloud computing itself, how we evolve and deliver that. This is a cloud that needs to open the door to the internet of things, and I believe what we're really building here is the backbone for that architecture of the future. And I'm really excited about what it does for both the users as well as the providers in terms of what it gives them. Hopefully we end up with users that get code and solutions that are bullet-proof at scale, that provide real interoperability, and probably most fundamentally a choice. As a provider, we get a platform to build on, to innovate on, and differentiate on as we try to explore the boundaries of where this goes. And we're going to start to see new kinds of specialized clouds emerge from all of this. You can think about the dimensions of things that you might do to tailor a cloud in this environment. Now, obviously, users want the ability to have some knobs and dials on this, but we can't always provide it in one single solution. But the customers I talk to really envision having this choice and having the flexibility to move back and forth in their own way. From the service provider perspective, looking at it from rack space, obviously we're going to optimize a managed cloud, provides fanatical support to all the users that need that type of interaction. But you can see an environment where somebody else might focus on usability, making it simple, making it cheap. Maybe you've got some really cool GPU high-performance hardware for Bitcoin mining. There could be all kinds of specialized clouds in this environment. But where we lose out is if I think we think that that's one cloud. Because in the PlanetScale cloud, I think what we're talking about is not separate isolated clouds, but a lot of clouds that are running OpenStack. And if we do it right, that means they're interoperable. They come together. And I'm not just talking about between public clouds, talking about private clouds and public clouds, talking about metal and virtualized clouds, and all of these things starting to integrate together that the users have choice in the ultimate flexibility. They get the best fit for the workloads they need. Now I'm not the only one with this idea. We see this catching on. Just listen to what some of the world's leading researchers are saying about their vision of the PlanetScale cloud. OpenStack's momentum is impressive. I think that the momentum is huge. OpenStack, as a phenomena, has really taken hold. OpenStack has changed the way we think about what we do and how we do it. So at CERN, we see the need for OpenStack because we are looking to provide flexible computing facilities for 11,000 physicists around the world. OpenStack is the clear leader in the infrastructure of the service space. And so if you want to configure a cloud in any kind of serious way, you're going to use it. Notre Dame selected OpenStack for our cloud and for our infrastructure environment for the research computing requirements because we really need to be able to be dynamically flexible. OpenStack needs interoperability because users are expecting to be able to talk to OpenStack clouds in the same way regardless of where those clouds are based. They want to be able to just choose a different OpenStack cloud and run the same program and be able to use that code portably across the world. For scientists to collaborate at Notre Dame, at universities around the United States, at universities around the world to collaborate with commercial entities and other non-profit organizations, we have to have a language we can speak. And having that common language in a computing sense means having a common API like OpenStack provides. Let's say we have a private cloud at our gun and we want to go out and use a commercial cloud. If we can do it with minimum fuss, that's much better for the user. That's much easier for the user. OpenStack can become a worldwide cloud if we use the facilities that are part of the Icehouse release called Federation. Federation allows users to authenticate against one cloud and then use resources in another. This has been developed as part of an industry CERN collaboration with Rackspace under the Open Lab environment and is available as part of the Open Source release. In today's world, research and collaboration is global. If we're going to have planet scale, if we're going to be able to capture an internet of billions and billions of devices that are interoperating, that are communicating, that are transferring data between each other, to do that on a planet scale, we have to have big compute possibilities. We have to have big data resources and we have to have the ability for big instruments and big devices and many devices. What OpenStack provides is a platform that as those new devices come on, we can add new modules, we can add new capabilities for OpenStack such that it can talk to those devices, it can come with new APIs so that our compute and our data and those devices that are coming and developing every single day over new networking infrastructure, we can get that planet scale, we can bring all of those into the fold and we can make sure that as we go to devices and numbers that are far beyond values we're at today, we can still make sure that it interoperates and we can have a way to collaborate. Interoperability. I can't talk to a customer today who doesn't tell me that the planet scale cloud needs interoperability. But I tell you, building an OpenStack cloud that's interoperable today is guesswork. It's guesswork for me as a service provider. It's guesswork for some of the users. For me it feels a little bit like Luke Skywalker trying to train with the lightsaber. You never know where the next hit's coming from, which feature you're supposed to support in your release, which new extension or OpenStack module people are gonna expect you to have in your cloud and if you think it's hard for us as service providers, think about the operators and the users that want some base standard. And we need to give our customers and our OpenStack user audience a higher degree of confidence. That's what Def Core is all about. Def Core is a process driven by the OpenStack board. It's a committee run by Josh McKenzie and Rob Herschfeld that I'm a part of. And it is a process by which we are defining the capabilities, the code, and the must pass tests that are the minimum standards for all products that use an OpenStack label. This really becomes the basis for interoperability. It's not gonna solve all of our issues, but it is an absolutely essential first step. Now the way that we're determining what goes in these is based on four categories of criteria. First, this has gotta be used. It's gotta be widely deployed in public and private clouds for us to consider it to fall into the core definition. Second, it has to align with the direction that has been set and established for the future by the technical committee and the PTLs that run our project. We also need to make sure it plays well with others, that it's well documented, that it's easily understood and consumed by the people that ultimately pull this together. And then finally, we're taking a system wide view, looking at all the components and the dependencies and how these things fit together to make sure that we understand the interactions and how to put this in place. Now it may sound complicated to have all of these criteria and tests and pieces and put stuff that goes together, so we're not stopping there. We're not just writing a document or putting out a definition. We've begun the RefStack project. And the RefStack project is designed to put together a set of tools and a website and reports that make it very easy for you to take Tempest and run it in a container. Run the test, produce the reports and understand where your cloud sits or where the clouds that you're potentially investigating for use are in this spectrum of support for core. This will have a feedback cycle where you can upload results to a website where we can track utilization, who's using what, what new features are becoming popular and on the rise. This effort is designed to be easy to use, public and community driven. And we've been working on this for about 18 months in various pieces, but we've got six months to really tune and lock this down and get it right. So we need all of you to help us refine the criteria and the tests that we're selecting in this process. We need you to get involved now so that all of this is cemented by Paris. Because I think it is absolutely essential that we have a definition of OpenStack Core by the end of 2014. Now there's gonna be sessions here at the conference given by Rob and Josh they're a blog post by myself and Rob and a number of other people. The information is starting to get out there, so grab it and where you don't understand it, grab one of us, ask questions and get involved. And again, the basis of this is we want it quantitative. We want it data driven. We want it easy to use, transparent and most of all responsive to the community. But that requires you to get involved. So that gives us the solid core. Now if you listen to the press and even some of the conversations that we have inside the community, a lot of people would say, you know what? OpenStack should just stop right there. All we need is a solid IaaS. You know, it used to be one of those people. You heard me talk at San Diego. I had a lot of caution about new projects and about locking down the core projects that we had inside of OpenStack. But you know, history both inside of OpenStack and outside have convinced me that's the wrong point of view. Linux didn't survive just because of Linux. Linux survived because of an ecosystem that included the LAMP stack. And all these tools that went around it to make it usable and accessible. It innovated along the way. IP tables wasn't started in core in the Linux kernel. It earned its way in there through a competitive environment. We can learn those lessons in OpenStack. So I think we need both the stable, well-defined core and a very rich ecosystem that populates around it. It's gonna take that kind of innovation and extensibility and broadening of the community if we're really gonna build the PlanetScale Cloud. So this ecosystem is gonna be composed of core OpenStack, certainly, and a lot of other interesting OpenStack projects. It's gonna include other open source projects that don't exist inside of OpenStack. We have to be sophisticated enough to understand this wide range of things. We can't take every project that matters to the PlanetScale Cloud and cram it in to OpenStack core. And not every one of these things actually should be in an OpenStack integrated release. We need to get comfortable with the fact that there are valuable, important projects that are not gonna be integrated, that are not even, in some cases, gonna be an OpenStack, but nonetheless are important to this evolution and this path that we are on. I need to know that this is a community that is able to make sure that both a cloud foundry and a solemn can run well on an OpenStack Cloud and we leave it to the market to figure out the long-term answer. So how does this work for us at Rackspace? So about two years ago, we launched our version of an OpenStack Cloud that built on some of the most stable projects in the system. And I'm happy to say we have benefited a lot from the success and momentum that's happened inside of OpenStack. To date, we have processed more than 2.4 billion API queries through our cloud servers offering a loan, all going through a nova front end. We managed more than 100 private clouds for customers built on OpenStack. And most of those customers are adding capacity and growing their use cases on a daily basis. So for that OpenStack community, I want to say thanks. This has been a great start for us at Rackspace. But we're not stopping at that core IaaS either. We are continuing to grow our portfolio, taking advantage of the innovation that's happening in this environment. We have the first public cloud availability of heat in a production basis. So you can use Rackspace cloud orchestration today, and it is running the heat code from less than seven days ago. We've also exposed Glantz endpoints with our cloud images offering so that you can begin to use the Glantz APIs directly within our cloud. And we've started deploying Neutron in all of our data centers and we'll be exposing that endpoint to you as well for networking purposes. And finally, I'm committing that before the end of 2014, we will be running the Keystone code in production and not just supporting Keystone APIs so that that vision of federated identity can become a reality. And this is all part of this demonstration of our commitment to Defcore and to aligning with what the community is doing and how we build our cloud at Rackspace. So that's a lot of the what about what needs to be done to get us to the planet scale cloud. I want to shift gears a little bit and I want to talk about how we get there as a community. So this is actually a community that has really cared passionately about the how. Ever since we got together and started figuring out our processes and building our sort of representative democracy, it's been essential that we don't just copy what other people do. And I like to think the basis of this community is around trust and contribution. But as we're expanding our mission, as we're embracing new types of use cases, as we're embracing contributors that don't just submit code patches, we are gonna have to change and evolve the way we think about these elements within our environment. But before we think about change, I need to remind every one of you that we've started out with an ability for all of you to have a voice and what happens inside of OpenStack. Every single member of the OpenStack Foundation has a vote in the elections of who gets on the board as well as any bylaws changes that we are to make as we go forward. And we are gonna need to make some changes. But we can't do those without you. So take advantage of the privilege of your vote and make sure that you pay attention to these changes that are coming and the elections in the future and take an active role in helping us evolve as we go. Now I wanna dive into the topic of trust. This is gonna be a tough one. We started out as a small close-knit community where we all knew each other. Now we've got over 16,000 members of the Foundation and I'm standing in a room of over 4,000 people talking about where we're going in the future. There are a lot of new faces coming in. We all come from different companies and we all know the fact that most of those companies have a commercial interest in OpenStack. So we could start to batten down the hatches. We could start to take a defensive posture and make sure that all those people earn their way into our community. That they earn the trust that we give them and the respect and the ability to listen to their opinions. I've got a different suggestion. I think we take a different path and we go back to what got us here and what got us here is the ability to trust and that people's motivation to make OpenStack succeed is more important than any individual or corporate agenda. We have to stay focused on the long-term goal because this is a long-term fight. Now, this is related to another common and foundational element of the OpenStack community. We like to argue. Everybody nods their head knowingly. It's an essential part of how we get the conflict in the organization to sort out the right answer, to sort through the confusion and to figure out how to move forward as a group. In fact, that conflict and that argument is the exact reason we don't need a dictator in OpenStack. But I want you to remember something as we move through that process and as you reflect on my words about trust. As Patrick Lenzioni likes to say, conflict without trust, that's just politics. But conflict with trust, that's a search for the truth. So trust without contribution doesn't deliver the amazing stuff we've had today. So we need to focus on this as well. We have built an incredible system and ecosystem around developers that has attracted an absolutely phenomenal number of incredibly talented people to write code and build these products and keep maintaining and evolving them. We would not be where we are without the ability to recognize and incorporate these people's contributions into our culture. But as Jonathan talked about today, that's not gonna be enough. We need to broaden our definition of contribution in OpenStack. We need to embrace operators and users as a part of our community. Now, we've done some great things. This is not a new initiative, but we have to continue going. There was an operator mini-summit in California back in March. We brought a whole group of operators into a room and they came up with a list of the things that they need our developers to focus on to make their lives better. We got good interaction among the operators and a good starting list of things to work on. That spawned the operator tracks that Jonathan's already talked about that are here happening this week. And there are design summit sessions this week where we're actually gonna do something as crazy as put developers and operators in the same room and talk together. So we're making momentum here. We're starting to embrace users and developers with common SDK initiatives. The win the enterprise committee that the board is working on to go dive into requirements. So I think we're making good progress and we recognize this as a necessary and logical evolution of the community. But there's a trap if we're not careful. The danger is we just set this up so that users and operators throw requirements over the wall, they landed developers feet and we hope that things get implemented the right way. We're sure we've never worked on software projects where that's happened. But I'd argue if that's what we do we're missing an amazing opportunity. We need to coalesce these groups. We need to bring them together. We need to share information and understanding and ultimately we need to create an environment of empathy and understanding within our community. We need developers that understand the pain of dealing with an operational issue at three in the morning. We need users that understand how hard it is to put code changes in to a rapidly evolving code base in a new space. We need that information sharing that goes beyond just fork lifting requirements back and forth between groups. And so just to echo Jonathan's words, find users, find operators and let's bring this whole thing together so that we are truly co-creating the planet scale cloud. So look, today OpenStack is awesome. It's real and we are absolutely on track. We are not done. The pressure's on. Other people have other ideas and they are moving ahead quickly. And in some cases they're coming after us. But I think we'll be able to claim victory. I am confident that I will get to stand up here one day where we can celebrate getting to where we wanted to go. We're gonna do that because we are gonna continue our environment of trust. We are gonna value and expand what we think about when we talk about contribution. We're gonna expand the community from which we get those ideas and those insights and we'll have created this environment of empathy that is absolutely critical to getting to the next stage. That's what's gonna get us there. And that's how we're gonna win. We got a lot of hard work ahead of us but I really look forward to the day where we can throw the last party. Thank you. There's tons of benefits to getting involved with OpenStack and with the community. The nice thing we have with OpenStack now is there's a community in almost every city. So go meet your friends, get an understanding of what they're living through. The power of the open source community is you can talk to somebody else that's been through it. There's always somebody somewhere in the OpenStack community that has done the thing that you're trying to do. One of the things that attracted us to OpenStack in the first place was as an open, flexible, loosely coupled system, it was possible for the community to add all of these things. I didn't rely on a particular vendor to provide a particular feature that they did in their own way, in their own time. What's awesome to see now is that when we go to these kinds of things when there was the Operator Summit that they had in March, that there's lots of actual operators involved now. So there's lots of companies that are using it and it's taken off quite a bit. And so just having this wide range of skill sets and talented people writing software and testing software and implementing it and giving feedback and building it up, I think is a huge competitive advantage. Being a super user means improving myself every day with the help of the OpenStack community. I now have the opportunity to work with other people that faces the same challenges as me as a cloud operator. The people who are contributing to it, either as users or as people running the cloud, get great feedback from the OpenStack community. They do blogs, they help out on the mailing lists, and they give other users help when they have problems through things like ask.openstack.org. So our participation in the communities, I'm gonna call it in our enlightened best interest, by ensuring that I'm staying connected to the community and what they're producing. The rising tide lifts all boats kind of metaphor where everybody is kind of contributing to something that's growing this more than some of its parts to some degree. The ability to be connected with the community is pretty big and just being able to be very specific and no marketing, no PowerPoints, but this is where we're going with the code and the connection across the community has been pretty passionate and vibrant. So for me, as being a super user, it's being able to connect really and drive technology forward.