I don’t make a habit of inserting myself into OSS wars, they tend to hurt everyone and benefit no one. Far too often (content management OSS projects are a great example) they result in code splitting and users with limited options moving forward.
With that said, I read with some amount of interest the competing posts first by Randy Bias and then by Robert Scoble, and feel that this is an odd conversation to be having, all things considered.
Where do I get my opinion? From the trenches. For the last eight weeks or so, I’ve been, among other things, implementing OpenStack. I’ve been all over the boards, setting up different configurations, testing out different things. I’m talking as a geek that did it. Is doing it.
The focus for OpenStack needs to be on several items, and both Scoble and Bias are right about their pets – innovation and compatibility – but the core that OpenStack needs to be focused on? Usability, simplification, upgrade compatibility.
Let’s face basic facts, OpenStack is a new technology. Perhaps living it day in and out, these worthy gentlemen have forgotten that fact, but to an accomplished geek that sets out to implement, it feels like the early days of Linux all over again.
Yes, you can get it running with sufficient effort, and yes, the more you do with it the more sense it makes, but it is undeniably a highly complex system that relies on several highly complex subsystems. Error reporting is weak in many areas – yes, it’s seen improvement in the last couple of releases, but it needs to stay a focus – and there is not an easy way to implement it. Because it is still in its infancy. And most enterprises do not want to configure a private cloud that depends upon a single geek that has spent time learning all the ins and outs, we’ve been down that road before, and CIOs want to be able to train a team intelligently, not have one weak link in the internal cloud chain. As well they should.
That ignores the fact that the OpenStack system is highly modular. Just as Neutron (formerly Quantum) has a plug-in architecture, so too could public cloud. Mr. Bias alludes to this, when he says there could be separate pieces to link to the different cloud platforms. I’d be in favor of that… But his solution involves a re-architecting along the lines that the network component underwent moving from Essex. That’s a lot of change, even for a system so young. It would be nice if existing architecture remained unchanged, and translation was put in place between Nova and public cloud offerings.
Showing merged DevStack and OpenStack changes is heartening to those of us who found DevStack lagging behind, and again, is something that focus should stay on. The ability to quickly get a demo up and running allows tech folks to show management how the system could help for internal cloud.
What do I think the priorities should be? Well, I’m sure everyone has an opinion on this topic, but if it were up to me they would be:
Usability (from a technician perspective – primarily on install and debug).
Interoperability with public cloud offerings (Mr. Bias is indeed correct, hybrid wins).
Since it is indeed an open source project, those who find innovation is inhibited on the core team can certainly contribute new ideas/code without impacting the core team – in fact for an OSS model aimed at enterprise users, that should be the preferred model if there is enough interest. It keeps the core team free to make the system rock-solid and focus on putting support in for major OS’s, equipment vendors, and cloud providers.
But like the authors I started this post mentioning, I have an employer who is interested in the space, while I try to stay unbiased, it is indeed worth mentioning, make of it what you will.
What I do not want to see is this turn into the type of fragmentation that many OSS projects go through when fundamental differences occur at this level. We’re all pulling for the same thing, I hope we’re all smart enough to pull together, since if there is one thing OpenStack has going for it, it is a ton of really very smart people.