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:

Rackspace

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

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

Governance

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 wiki.openstack.org

• 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.

What People Are Saying About OpenStack and What They Should Be Saying

I am a bit irritated at some of the criticism and, to be honest, some of the praise the OpenStack project has received.

Lets deal with the criticism first:

Vaporware: I have seen the project called vaporware in several forums.  This doesn’t seem to be an appropriate use of the term, and smacks of FUD, but may just be ignorance or unfamiliarity with Launchpad, where we host our code.  Some links to help you get to things.

• OpenStack Compute source branch
• OpenStack Objectstore source branch
• How to create a branch
• Source tarball for OpenStack Objectstore v1.0.2

Nothing is usable: I’ve seen this too, usually followed by a statement implying that it might take years, for it to be production ready.  The OpenStack Objectstore is already in production at Rackspace holding many dozens of petabytes across multiple data centers.  Please try to install it and give us feedback.  Now, the compute side is a slightly different story.  I believe that NASA has a version of this runnig in production, but development is moving so quickly, unless you want to help us develop or test it, I recommend that you wait until our first release in October.  Some examples of the quick development of OpenStack Compute’s first two weeks:

• 20 active branches owned by 9 people, 1180 commits by 22 people in the last month
• 9 active reviews or unmerged proposal

This is just a marketing/PR move: I can say that this is not true for Rackspace.  I can’t know the motivations of everyone involved, but I was a part of the team that convinced Rackspace to do it and none of the technical or business people involved mentioned PR or marketing as a reason to do this. This was not an easy decision and needed to be explained to the organization from top to bottom.  We told them the same thing we are telling everyone else.  “It is the right thing to do”.  Then we made the following guarantee: Rackspace will sell just as much software next year as it sold last year: None.

OpenStack will not kill open core: OpenStack is a project, not an idea or a philosophy.  We have no plans to take on any way of thinking.  We only got involved in this debate because I feel very strongly about it and wanted to make sure that OpenStack’s position was understood.  We are strong supporters of open source and the ideals it stands for. We feel like open core, as it is most commonly implemented, is a bastardization of those ideals, however, OpenStack is not Don Quixote and we don’t feel like charging at windmills.  Our real goal is to level the playing field in the IaaS ecosystem and no longer allow people to act like creating a IaaS fabric is some kind of super secret magic.  Let’s do it once, give it to everyone, and move on to more interesting things.

Now the Praise:

OpenStack will kill open core: Please see above.  Killing or not killing open core is not one of our goals, however, not being open core is one of our goals.

OpenStack takes on Vmware/MS/Amazon: We are not doing this as a tactical move against any specific company, but because it should be done and there is no reason not to do it.  Our mission statement from the wiki:

The OpenStack Open Source Cloud Mission: to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.

This is as big as the beginning of Linux or Apache: We are all excited, but please don’t set us up to disappoint.  I really hope we do something great, and both of these projects inspire me, but let’s remember how long it took for these projects to become the giants that they are.  I don’t want to down play what we are trying to do, but let’s do it first and let the results speak for themselves.

What would I like for people to say?

Well the truth, good and bad and with out hype or malice. Here are some examples:

The bad (well not so bad, but do you blame me?):

OpenStack needs to organize quickly: We are getting a huge response and we need to make sure we can handle the influx of developers and code.  The most important things to me is that we maintain quality and that we deliver when we promise.  If we can do those things we will be successful.

OpenStack needs to  publish it’s governance: We do.  This is valid criticism.  We are working on it based on feedback from the community. Once it is done, it needs to be approved by quite a few parties.

OpenStack sucks because it should have feature a,b, and c: Should we?  Well write it if you can or pop into #openstack on freenode and ask us to write it.

The good (or what we would like to hear):

Wow this is great code: Thanks.  We do the best we can.

We really like the open way you are running OpenStack: Thanks, we feel that to be successful we need to have an open collaborative process.

I want to help: We would love your help.  Can’t code?  Come help with community or write documentation.

Next Stop UDS

All the Canonical folks are meeting this week prior to UDS.  We’ve already had some great discussions including:

Canonical Plan for World Domination

— text redacted —

(Sorry, if I told you, I’d have to kill you.)

Actually, it is a great time to see all our co-workers from across the globe.  However, I can’t wait for next week, when UDS starts.  UDS is a great time to see all of you, the people that make Ubuntu great.  Please come up to me and talk to me, even if I seem busy.  We are randomizing the tracks this UDS, so each track will move to a new room after each session.  There is no more hiding in a room and not meeting new people.  Please take advantage of it.  The F/OSS world is a weird diverse and interesting place, don’t let yourself miss any of it.

UDS Barcelona Has Incredible Potential

This UDS each track will have two session rooms, plus a breakout room. That means we will have, at least, twice as many sessions. We should some out of it with twice as many specs for new features. My question is, how will we handle twice the data?

In previous UDS’ the server track was very well documented, thanks to Adam Sommer from the documentation team.  Adam was able to attend all sessions, and the documentation was uniform, because one person was responsible for the format. I think that because of Adam’s excellent work, we had some of the best documented sessions at UDS.  This was good, because I am usually suffering from information overload by the end, and unable to remember my name, let alone the critical details of the discussions.  We will have to come up with another solution in Barcelona.  Adam will only be in some of the sessions, so the rest of us will have to pick up the slack.

If we take good uniform notes, we could come out of this UDS with more data from more discussions than ever before. This will ultimately result in a better Ubuntu.  All we have to do process all the data in a usable way.  So, you will probably hear me start every session with a reminder about note taking and a quick review of the format we want them in.

Free as in beer:
As usual, Server Team community members find me at UDS and I will buy you a beer.

I’ll be at the Free Software & Technology Expo in St Louis, MO on Saturday

I’ll be speaking at the Free Software & Technology Expo tomorrow May 9th.
My talk will cover:
* What’s new in Jaunty, including the Ubuntu Enterprise cloud
* Hints of what might come in Karmic, and a UDS preview
* Observations from the front line (or What it’s like to work for Canonical, and the furious pace of our 6 month release cycle

If you are in or around St Louis, stop by and say hello. I’d love to talk to you!

Exchange Proxy Anyone?

At UDS, there was talk (mostly from Dan Shearer) about using Openchange to provide a mapi proxy to MS Exchange.  I find this interesting.  If Dovecot/Postfix could use it, it would allow *NIX clients to talk to Exchange without turning on OWA.  This would delight sys admins on both sides of the fence.  Of course, Outlook clients could also talk straight mapi to the proxy as well.

I like the idea of abstracting MS Exchange, because once we have all the clients talking to us instead of MS Exchange, it makes it much easier to replace exchange.

The Openchange folks have made an announcement.

UDS Intrepid

With UDS over it’s time to start the difficult job of deciding what we can actually accomplish for Intrepid.  A partial list of things that might make it in to the Server Edition:

• J2EE App Server (Full stack or just servlet container remains in question)
• OpenLDAP based AD proxy
• Enterprise Management integration
• Easy LDAP server setup
• Improved community testing

Some pictures: