Archive for the 'OpenStack' Category

Rackspace/Openstack Addendum

Since this seems to have spun out of control a bit, I’d like to add a little clarification to my views:


I am a fan of Rackspace. They are a good company full of good people trying to do what they think is right for their business.  Rackspace has a set of core values that most companies would do well to emulate.


Openstack is a large healthy project, any one person or even group of people leaving would not hurt it too much.  Rackspace is integral to the success of Openstack.  Rackspace gives the project credibility, that it wouldn’t otherwise have


I don’t have any major problems with the governance. It is an incremental improvement over what we had.  I have a problem with the process that was used make the governance change.   I feel that changes like this should be open and transparent.


I don’t think there was any ill intent on Rackspace’s part in making these changes. They just thought they could.  That is the crux of my issue.  I want Rackspace to realize that there are expectations of transparency in open source projects and that it is a technical undertaking and involving the technical community in decisions is critical to long term success.

Rackspace is run by reasonable people.  If this were not the case, I would not have wasted my time writing a blog post.  I want to lobby Rackspace to do what I think is the right thing, because I know Rackspace wants to do the right thing! My purpose was not to forecast the doom of Openstack or brand Rackspace as a bad player.


Why I Left Rackspace and What About Openstack

Since people seem to be reading whatever they want into my blog post, I wrote an addendum.

I want to start this out by saying that Rackspace is primarily full of good people trying to do the right thing.  I don’t see evil intentions anywhere.  Even though I left, I still want Rackspace and openstack to succeed.  In fact, I think the industry needs them to succeed.

I think that Rackspace needs to make some changes to ensure that success.  I left because I had a great opportunity at Cisco, and because  I was not able to effectively lobby for those changes from the inside.  So, I will try to do so from the outside.

Here are the issues:

Influence over Control

“In my experience, attempting to retain control of a project you’re starting or hosting leads to mistrust, contention and a rules-based focus that diminishes your reputation. Relaxing control will lead to the community innovating and growing in ways you’ve not anticipated, as well as enhancing your reputation. As I’ve frequently said (although less frequently been heeded): trade control for influence, because in a meshed society control gets marginalised while influence delivers success.”Simon Phipps

I think that Rackspace is trying to control Openstack rather than influence it.  A perfect example is the recent change in governance.  I responded at the time here.

Basically, Rackspace made governance changes without talking to the development community or the sitting governance board.  This is extremely problematic for the health of the project.  If Rackspace can make this kind of unilateral move now, what is to stop them from doing it again, if the governance does not suit them.  There should be no change in governance without the current governance board approving it. This is necessary for the governance to have any validity.  The sad thing here, is that the governing body would have probably approved it with only minor changes.  The changes are for the most part good, but the process shows a serious flaw in Rackspace’s thinking.

Rackspace has a choice to make; they can try to control the project and eventually fail, or they choose to influence it and succeed.

Openness matters

At the beginning of the project I wrote a promise of openness.  I promised that all project meetings would be done in the open and recorded.  To use the governance changes as an example again, where are the open discussions?  One can only assume that private meetings were held to discuss and decide these changes, before they were released on the community.  As a project we have to live up to the promises we make.  Everything that involves the community should be publicly discussed and debated.

Technology not marketing

In my opinion, one of the things that led to the poor process used for the governance changes was that they were overreacting to negative blogs about Rackspace’s purchase of Anso Labs.  This is indicative of what I see as a problem of focus.  Rackspace seems to view this as a marketing and PR property, when in fact, it is a technological endeavor.   That the people “in charge” of the project, from the Rackspace side, are marketing and business development folks reinforces this idea.

I think that the PR effort around Openstack has had a tremendous effect on its success thus far, but it is adjunct to the project and not the meat of the project.  The one actual problem that I have with the substance of the governance changes, is that I think it creates many weak technical leaders with very short terms.  Unless Openstack is lead by a strong technical team, it will ultimately fail.

Community means participation

One thing that I think has been wrong from the start of Openstack is the definition of community.  Community is not a list of partners.  In fact, the participation of most of the companies listed on the openstack community webpage started and ended with a press release.  I do hope that they will all start participating, though.  If there is anything I can do to help anyone contribute, please contact me.

The community is composed of two sub-communities:

  • The user community,  made up of people and organizations that are implementing some part of Openstack
  • The developer community, made up of developers, testers and documenters

To become part of the community it is not necessary to “partner” with anyone.  You just need to participate.  Participation can come in many forms, bug reports, documentation, development, even just attending an IRC meeting and voicing your opinions.  There are good reasons to partner with Rackspace and their new Cloud Builders group, but it is not necessary to participate in the project.

Foundation, Foundation, Foundation

Rackspace, please put the code into a non-profit foundation.  Putting the code in a foundation similar to the Linux Foundation, is good for everyone.  IANAL, but I believe it protects Rackspace from some types of legal liability, spreads out the cost of running the project,  it shows that Rackspace understands that it doesn’t actually own the project, and it protects the project from management changes and changes of priorities at any one company.  Most important of all, it encourages an ecosystem to develop, by placing everyone on fair and equal footing.  This article says it better than I can, and is written by someone that understands it more.

There has been a push to expand the project by letting other projects join. I don’t think any should yet. Until the project is a foundation, joining Openstack is akin to giving your project to Rackspace.  What happens if Rackspace is under new management, say Oracle, for example? A foundation fixes that.

I’m still going to work on Openstack

I plan on sticking around and working on Openstack.  My level of involvement depends on what the community wants.  I have been nominated for the new governance board and the nova project lead.  Whether or not  I am elected to either, I will push the agenda I have outlined in here to the best of my ability.

A question about Openstack

At the openstack design summit, I had the opportunity to talk to many people about the project. I got some good feedback, but as a rule people that attended the summit were biased towards positive comments. So, I would like to ask a broader audience.

What are we doing right and what are we doing wrong?  If you like it, why?  Are you attracted to the openness of the project, the fact that so many companies are involved, …?  If you don’t like it, have you looked closely, and what did you find that you didn’t like?  What would it take to win you over?

Please leave comments.

Next Steps for Openstack; Goodbye Austin, Hello Bexar

So, we’ve kicked Austin,  the first official release of OpenStack, out the door. What now?  If you were hoping for a little rest and relaxation, you joined the wrong project.

In two short weeks we have the OpenStack Design Summit (ODS).  ODS is not a conference, where people lull you to sleep with presentations.  ODS is a working summit.  We have to plan, discuss, and write specifications for the next two releases of OpenStack.

So how does this work, you ask? The entire process is documented on

  • Submit blueprints. It all starts with blueprints.  Blueprints are short descriptions of features, or parts of features.  Landscape has a good description of blueprints, if you want to learn more.
  • The team of Openstack architects then reviews the blueprints and , if needed, asks for more information from the filer.
  • We then choose the blueprints we think are the highest priority and schedule discussions about them at ODS.
  • After the Summit, the full specifications are written, I will approve and prioritize them.
  • As you you start developing, please update the status of your blueprints
  • Don’t forget to link your development branch to the blueprint using the ”Link a related branch” link on the right hand side of the blueprint page.