Seeking OpenStack Foundation Board Seat for 2013 (please nominate me)

I am seeking another term on the OpenStack Foundation Board.  Please consider nominating me for this position.
The following is the profile information I provided as part of the nomination process.  If you are looking for insights into where OpenStack is going then these question (especially the later ones) will be interesting.

Provide Brief Biography of Yourself

I have been involved in Cloud for over 12 years and launch some of the earliest Cloud companies.  My educational background (Duke and LSU) is in computer science and systems engineering (Mechanical/Industrial) with a focus on distributed systems.  I have always found deployment to be vitally important in development – that lead me to found a SaaS start-up in 1999 and had made me a DevOps advocate.  In addition to core cloud technologies, I am an Agile/Lean process evangelist who strongly believes that how you build and deliver is just as important as what you deliver.
Currently, I am a principal engineer at Dell leading our OpenStack Cloud project  and also a founder of the Crowbar project.  In that role, I am in constant contact with OpenStack users, ecosystem developers and vendors world-wide; consequently, I have a very broad perspective on use and technical needs for OpenStack and related Cloud technologies.

What is your relationship to OpenStack, and why is its success important to you? What would you say is your biggest contribution to OpenStack’s success to date?

I have been involved in OpenStack at the earliest stages and was a key influencer in Dell’s decision to be an initial sponsor.  Further, I formulated Dell’s operations/deployment focused Lean strategy that helped create an early focus on OpenStack operations.   This support was a critical catalyst to building market momentum and we continue help drive operations and user focused requirements for OpenStack.  Providing a very open and community driven DevOps focus has been my biggest contribution (see Crowbar).
I also serve the community in many ways.  In addition to being elected to the 2012 Board, I founded the Austin OpenStack User Group (next meeting 12/6!), have been spoken at every Summit, co-Chaired the Operations Track at the Grizzly Summit and create community awareness of OpenStack through my blog, corporate work, and social media activity.
I have invested considerable time in OpenStack and made professional commitments to its success.  It’s not just about software and an awesome community – I am personally invested in OpenStack winning.

Describe your experience with other non profits or serving as a board member. How does your experience prepare you for the role of a board member?

I am currently serving on the OpenStack Foundation Board and have been an active advocate for a collaborative process and open communication (,  I hope continue on the board so that we can stay focused on the critical issues at hand.

I have over four years of serving as Secretary for my city’s public Texas 4-B Commercial Development Corporation which governed by state open meetings standards.  This work has proven directly relevant to the OpenStack foundation because the open governance requirements map very well to our communities transparency expectations.

What do you see as the Board’s role in OpenStack’s success?

The board’s job is to ensure that community and collaboration remain OpenStack’s core strength as an open source project.  As adoption and footprint increases there is enormous pressure on the community to try and serve both general and very specialized interests.  Most critically, we must find ways to balance competing financial interests within the community.
The board must ensure that OpenStack provides commercial opportunity because I believe that incent continued investment; however, we cannot let profit drive the community away from our open source values.
I believe the Board must monitor the community’s progress to ensure we maintain this balance.  It is our responsibility to make adjustments, influence changes and take responsibility for driving an innovative and collaborative culture.

What do you think the top priority of the Board should be in 2013?

There are two inter-related top priorities for the Board: we must help deliver guidelines for which projects are truly “core” OpenStack and help move towards a certifiable API specification for OpenStack (instead of implementation).   While distinct, I believe both items must be solved together.  These changes are essential to foster innovation and adoption of OpenStack.
While these issues will occupy the Board (and Technical/User committees) for 2013, my personal priority for OpenStack in general remains focused on operators and users.  I believe we have to make substantial progress on upgrades, migration and operational readiness.  These issues continue to create a serious barrier to adoption.

Won to End (1..N) Ranking

Or I can buy a new toothbrush in Newark

Our team had a breakthrough moment last week, we changed our MRD* into a prioritized (1 to N, no ties) list and immediately identified some artificial work grouping that would have jeopardized the whole release.  Within 5 minutes, we’d done more to rescue our release than the 4 weeks prior.

Working on a traditional MRD is packing to go on a vacation.  You’ve made great plans, you’ve read all the brochures, and you can visualize yourself on the sparkling white sand surrounded beach chair relaxing next to your partner under gently swaying palms. 

Paradise sounds great, but the cold fact of today is that you’re late for your flight and you have to pack everything into a single suit case. 

Remember the McCallister household in Home Alone?   They were so busy packing and rushing out that they left behind sweet defenseless Macaulay Culkin.  Treating an MRD like a suitcase makes you so focused on the little details and the deadlines that you and your team will likely miss the big picture.  And once you’ve started your team may not react to market changes because they’ve already packed their mental bags:  “honey, we can’t have dinner with the President tonight because you promised that we’d play tennis.”

Another frustration I have with MRDs is that they are classically adversarial.  “Why did you pack that?  If you’re bringing that yoga matt then I’ll need a polo helmet!”  The fault is not in the people, the very nature of the document creates antagonism because the document is considered a monolithic whole.

It does not have to be like this.

Creating product direction should be more like planning a road trip than preparing for a transoceanic flight.  We know where we want to go, the essential things we need and who’s in the car: that’s enough to get started.  We’ll discuss the roadmaps as we go so we can explore the interesting sites (“geysers, cool!”) and toss out the bone headed detritus (“infrared beachcombing metal detector?”) along the way.

It takes trust and discipline to free fall into this type of planning.

When my team ranked our traditional MRD items into a 1 to N list, the conversation immediately became more focused, birds began to sing, and we each lost 5 pounds.  Several things happened when we changed the list. 

First, we looked at the deliverable as a system, not just a collection of features.   “Yeah, mayo is not much good without the bread, keep those together”

Then we started talking about what the customer needed (not what we had to deliver).  “Rob, we know you like sweet hot banana peppers but those are really optional compared to slicing the bread.”

Finally, we found it much easier to compare items against each other (“yeah, the ham feature is more important than tofu move that higher” instead of “we can’t ship this product without both ham and tofu!”)

Once we had the list ranked, it was obvious to everyone which features were required for the release.   Our discussion focused on the top priorities and engineering was able to focus on the most import items first.