 Live from Mountain View, California, it's The Cube at OpenStack Silicon Valley, brought to you by headline sponsor, Mirantis. Here are your hosts, John Furrier and Jeff Frick. Okay, welcome back to the morning, we are live, this is The Cube Live in Silicon Valley for OpenStack SV, that's the hashtag OpenStack SV. Go to crowdchat.net slash OpenStack SV and join the Randy Bias Show, we are here. My co is Jeff Frick, our next guest, Cube alum, Randy Bias, we've known you, Randy, when the Clouderati, before the Clouderati was called the Clouderati, there was like three of us and four of us and six of us and all the crew, now it's huge, now it's OpenStack, so welcome to The Cube. Thanks, Jeff. We've been around the block, I want to ask you about, just to take you, what's your presentation? What are you doing? How's it all going down? So I got here a little late and the traffic wasn't great on 101, never is. That's a good sign for the economy, I guess, but the presentations before me were really good, fairly technical, I think I got on stage and kind of shook things up a little bit because I wanted to talk about the overall direction of OpenStack, I wanted to talk about how we can make OpenStack more successful and make the community a better place and I wanted to really sort of draw out what I thought was a glaring problem that need to be discussed that I think is people are sort of glossing over. So what specifically were you critical of? So OpenStack has a clear mission, there's a vision for the overarching OpenStack community and for the people in OpenStack and what they all want to accomplish. There's a mission on the OpenStack Foundation website and so on, but there's not really product leadership within OpenStack, there's sort of this big gap between the board of directors and the foundation which see themselves as responsible for the strategic business direction and the technical committee with the PTLs in it that see themselves as responsible for the six month integrated release for basically the software development lifecycle. And so the problem is that there's nobody who's really responsible, there's no ownership for what is the long-term product vision on a project by project or program by program component within OpenStack. So there's a PTL for, say, Neutron but there's not a product manager or some people that support the PTL and help them with sort of long-term prioritization goals. So talk about the importance of this issue and some of the consequences if it's not addressed from your perspective. You know, one of the things that's gotten very challenging is that when OpenStack started it was only two projects. It is now nine projects that are integrated. I think in another year we may have double that number. We'll have close to 20 projects in integration and as it gets bigger and bigger and bigger the challenges become more and more and more to make sure that we have success in each of those. So one of the things that may start happening is that it may cause a breakdown and may cause failures to get to that six month integrated release. We may have bugs where one project can't talk to the other and so on. And it also means that we will continue to have these ongoing arguments about is OpenStack the code? Is it the APIs? What kind of hypervisors do we support? What does object storage mean? What does block storage mean and so on? There's not really anybody who kind of owns creating alignment around kind of shared vision for each of these projects. So we're seeing a lot of commentary around the usual things here. I want to get your take on it. Maranth has had a presentation. There are a number one thing on what to do is to focus on the APIs as the key to adoption. I mean, it's something that's been, you've been discussing for a while going back to the API debate, the great API debate that we've broadcasted. What's your take on that? The APIs are important, but they're not the only thing that's important. The code is also important. Probably most important is that we have some kind of understanding of what each of these things is. Let me give you a concrete example which I'll kind of try to identify where problems arise. So some people would like to bring in SEF as a competing alternative to say SWIFT, which is fine. SWIFT has a view of the world about object storage. It says object storage is what they call eventually consistent, right? One of those cloud technical terms. And SEF has a vision of object storage where it's strongly consistent much more like block storage. So there's nobody there to really have a conversation with about like our SWIFT and SEF really competitive. Maybe SEF is really more in the block storage project. It's really part of the Cinder project, not our Cinder program rather than part of the SWIFT program. Because it doesn't meet certain guidelines. There's no vision about what is object storage so you can have a measuring stick against it, right? At the same time, maybe it does fit. And then there's a question of like can SWIFT and SEF coexist? And if they can coexist, how would they coexist? Is there one PTL on top of the object storage program? And then there's different product managers for SWIFT and for SEF and so on. And I think that that stuff suggests unfortunately the issues come up and we butt heads about them but we have no way to actually resolve them. So we're getting commentary from the crowd here. Tim Crawford, I agree there are many issues and not many solutions yet. Concern with that? Happy about that? Good thing? Bad thing? But I don't know how much of this is a committee versus a leader because a lot of big tech companies are very fortunate when they have a really strong willed person that can drive that vision rightly or wrongly with Larry at Oracle or with Jeff at Amazon or obviously with Jobs at Apple versus you know everyone always jokes that a camel is a horse by committee. And is that just part of the structure of the community? How do you assign or how does someone take the leadership role around some of these specific objectives? Well, I mean... Those are best practices or kind of what's your ideal state? So the important thing to recognize is that there's no single model. People have solved and resolved these kinds of problems in the past in a variety of different ways. Sometimes it's the single strong leader, sometimes it's a smaller group. The thing it never is is grassroots. It's never grassroots because there's too many people like you said the camel is a horse by committee. There's too many people who have kind of like widely differing opinions about what it needs to be. That will never work. It doesn't necessarily need to be the benevolent dictator. It can be something else, but it's not going to be all the developers in aggregate making decisions and you get some kind of emergent vision. That's not what you get. That's when you get the camel. Right, what we need is we actually need a smaller groups of people who are focused on tighter, more controlled missions who can actually help to drive alignment and raise problems like the one I said between Swift and Seth out to the community so that they can eventually be resolved. And do you think those will be driven by expertise, by passion, by position, by a vote of the group to assign that responsibility to get behind or what's kind of your hope or as you said what are some of the other examples that opens that can learn from to execute this? A great product leadership, and if you look at any kind of startup, a great product leadership comes from a combination of two things, ruthless prioritization and saying no. And so I think- And those are the biggest startup challenges, right? That's right. And so I think that we need to have the same. One of the greatest things that Linus ever did for Linux is he would say no when people wanted to put things in and he had, he could veto things. We don't say no much at all right now. An open stack, if you write the code and you follow the rules and you make sure it gets upstream, then it just gets upstream. And part of that's because it's clear that the PTLs don't feel that it's, to a certain degree that it's in their remit to make decisions about that kind of stuff. And a lot of the time the PTLs are working for some of these companies too. So if they did say no, they would be perceived as being biased and so on. Part of the reason for having a separate product leadership function as I proposed is that we want to make sure that that is not owned by any company. It should be owned by the foundation even though it's a little bit non-traditional kind of model for the foundation so that those people can be relatively independent. I alluded to somebody on Twitter mis-understood me. They thought I said that Linus Torvalds was a product manager. That's not what I said. I said that he does do the product management function. He does say no. He acts as that strong leader, the product leader who's got a sense and a vision of what needs to happen which is what a product manager does. And so we need that inside OpenStack in order to be more successful. And it cannot be an interest that's beholden to any corporate entity and to a certain degree the PTLs are 100% in max just making sure that the six month integrator release happens and that's going to get worse as we go from nine integrated projects to maybe as many as 20. So I got to take on obviously eucalyptus selling to HP. CloudStack is kind of taking its course. OpenStack clearly there. Do you remember the old debates? CloudStack, OpenStack, eucalyptus now kind of all kind of naturally taking its course. What's your commentary on where it's ending up? Yeah, I mean, OpenStack sucked all the oxygen out of the room for CloudStack and eucalyptus a long time ago and now we're just seeing kind of the mood to sort of the final chapter. And I'm not sure I really should make any comments there on eucalyptus or CloudStack and both were good products. They had good teams behind them. And I am in particular a big fan of Martin Miko's and I think he's going to help HP really get their proverbial stuff together. And so I think that's great. But the reality is that when we decided to bet on OpenStack in summer of 2010 we decided to do that because we saw two things. One, it was going to have a lot of momentum. And two, it was focused on community and eucalyptus and CloudStack had been open source in license only. They hadn't really focused on community. And I've been working in the valley since 1990 and I've seen the worst technology that's more broadly adopted win time and time and time and time again. Which isn't to say OpenStack is the worst technology. It's simply to say that the determination of what wins has little or nothing to do with the quality of the technology and it more frequently has more to do with does it solve a problem? Can I get it up and running? It are other people using it. And OpenStack today has so much momentum. It has so many people behind it at all levels. It's a who's who of enterprise software vendors that really there's not any room for anybody else. And that being said, I think it becomes even more critical to make sure that we've resolved the product leadership issues within OpenStack because it is not going to get better until we do that. It is not going to be able to grow and blossom into the kind of project that we want it to be until we resolve that. And that's really comes down to leadership but also some tactical execution. Some will argue that decentralization free for all actually is an innovative strategy. Well, I mean this is the thing, right? You're talking about, you know, I was trying to talk about, you know, sort of like, you know, what's important about recognizing that we're not a dictatorship. We don't need a benevolent dictator where democratic meritocracy, democracies work and they're messy. Democracies are always messy and they work. And they still are one of the best governance models that we know of. And the reason that they work is because they're messy. People get in the room and they argue and they fight and then at some point we come to a conclusion, right? And then that conclusion gets codified in some way. So for example, in the United States, right? Women can vote, slavery is illegal. These are things that at one point in time were not true. And through the democratic process we came to a group agreement about it and then that got codified. That is the way that OpenStack is gonna work. It's gonna inherently be a slower process. It's inherently gonna be a messier process. People with a lot of emotion and angst and concerns and everybody's passionate about it. But the goal is to get to those conclusions and to then put them behind us. Right now, unfortunately, what's happening is there's a lot more spinning in circles than anything else. They get constant, you know, recreations of the same arguments on the mailing list and the meetings between the board and TC and so on because there's no resolution happening in certain key areas and we have to break that law jam in order to move to the future. Okay, so the last couple of minutes I want to just get your take on state of the customers. Right? We're always looking for the meat on the bone. Where is the meat on the bone right now at OpenStack? Obviously putting all the other commentary aside and critical eye to the organizational opportunities challenges. What's going on with the customer base? We stalled. Are we still slowly inch by inch handoff and we yard at a time? First and 10 move the chains. It's happening. I mean, it's happening. It really is happening. I think that the thing that is causing the most problems is that the community and the foundation in the first several years of operation really presented to you the potential customer base that OpenStack was a simple do-it-yourself project where you just downloaded from their website and go turn on your data center and you would magically have a private cloud. And the reality of the situation is that enterprises are going to consume OpenStack in the same way that they consume the most open source, which is through a commercial entity that has a product that's based off of OpenStack where that commercial entity is fully productized, OpenStack, and is delivering more of a turnkey solution to that enterprise. And that's just the reality. So still right now, the vast majority of early adopters are folks who can invest into DIY projects like Symantec and so on. But like I alluded to the fact that we've got a Fortune 15 company with a 20-rack deployment, that is a product-based deployment that companies very large. They want an OpenStack-based product. They don't want OpenStack raw. And they've had their own problems with OpenStack raw. And I think that what we need to do is we need to continue to educate enterprises that they're going to consume via one of the OpenStack corporate entities that is productizing it and not via the DIY open source itself. It's kind of like the whole Hadoop story, right? And the distributions around Hadoop and the commercialization around those distributions and the enterprise support of those distributions and even though the foundation is built on an open source project, really, people want to solve solutions and that's the best way to do it and really leverage the OpenStackness for innovation and growth and product development. Yeah, very similar. Randy, thanks for coming on theCUBE. Great commentary. We'll see you on Twitter. Thanks for coming on theCUBE, sharing your perspective. This is theCUBE live at OpenStack in Silicon Valley. Again, there's so much demand. They have to have great events in between Paris and the first week in November. Again, a lot of great stuff here in the OpenStack Foundation. Again, it's not about the technology, it's about the people and it's about the momentum. So, great quote. Certainly people want the technology fixed. So, let's hope stuff will be fixed. Randy, thanks for sharing. This is theCUBE. We'll be right back after this short break.