Crusty Blaa

The OpenStack Foundation Board of Directors met for a two hour conference call last week. This was the first meeting of the board since the recent Individual and Gold member director elections.

As usual, this my informal recollection of the meeting. It’s not an official record, etc.

Your trusty reporter had just arrived in Brussels for FOSDEM and got to stay in his hotel room for this meeting rather than sampling Belgian's fine beers. Oh, the sacrifices we make! :-P

Preliminaries

As usual, calling the meeting to order was a challenge and it was at least 15 minutes after the scheduled start before we completed the roll call.

Next, Alan welcomed our new directors:

• Yujie Du
• Alex Freedland
• Vish Ishaya
• Imad Sousou

and thanked our outgoing directors:

• Nick Barcet
• Hui Cheng
• Joseph George
• Lauren Sell

as well as thanking those directors who served on the board for part of 2013:

• Devin Carlen
• Jim Curry
• John Igoe
• Kyle MacDonald
• Jon Mittelhauser

Policies, Communication Channels and Meetings Schedule

Since it's a new year, we took the opportunity to review the various policies which apply to board members.

Josh went over our transparency policy mentioning that the board endeavours to be as transparent as possible, with board meetings open to the public, a summary of meetings posted to the foundation list and directors encouraged to use the foundation mailing list for discussions. Sub-committees of the board are expected to be similarly transparent, with wiki pages and public mailing lists. Some caveats to this policy are that board members are not allowed to make public comments about the board meeting until after Jonathan has posted his summary (or 72 hours have passed), members should not discuss executive sessions and the distribution of some non-public documents may have to be limited to directors.

Alan also mentioned our Code of Conduct and encouraged directors to read it carefully. Finally, Jeff from DLA Piper walked us through our antitrust policy where he emphasised the importance of avoiding even the perception that board members are coming together to advance the interests of some companies over others. Members should restrict themselves to pro-competitive collaboration.

Next, we quickly reviewed the various channels for communication that directors need to be aware of - webex for conf calls, the foundation and foundation-board mailing lists, the #openstack-board and #openstack-foundation IRC channels, informal etherpads that we use during board meetings and the various committee mailing lists.

Finally, we discussed the upcoming board meetings - an all-day face-to-face meeting in Palo Alto on March 4, a 2 hour conference call on April 3, an all-day face-to-face meeting in Atlanta on May 11 in advance of the Atlanta summit and another face-to-face on July 21 at OSCON.

The subject of the timing of the Atlanta face-to-face was raised again. May 11 is also Mother's Day (in the US and some other countries) which is a nasty conflict for many board members. However, a poll amongst board members had already established that no better time around the summit could be found, so we are proceeding with the meeting on May 11. The question was raised about whether future board meetings should be scheduled to not align with our summits, but the objection to this idea was that it puts too much of a time and budget strain on those members who have to travel a long distance for the meetings.

Status Reports From Committees

Finally, time to move on to some more meaty topics! A member of each committee of the board was asked to provide a status update and plans for the year ahead.

Alan first described the work of the compensation committee who are responsible for defining and evaluating the goals and performance of the Executive Director. In summary, the committee concluded that Jonathan met his 2013 goals and new goals have been set for 2014.

Next up, Sean Roberts talked about the finance committee. This committee works with the foundation staff on financial budgeting and accounting. Sean described the foundation's IRS filing and that the foundation's 2012 financial audit has been completed and deemed clean (with a note that the foundation is "operating on a cash basis"). The foundation's application for 501(c)(6) is progressing with the IRS asking for some clarifications which were returned to them in December. The committee meets monthly to review any discrepancies above 10%, but there have been no such issues so far. Essentially, everything is in excellent shape.

Tim Bell talked through the latest from the user committee. Tim mentioned the user survey that was published at the Hong Kong summit and how the committee has asked the TC for input on the kind of feedback that would be useful for developers. The committee is preparing to run another survey in advance of the Atlanta summit. Tim also mentioned that the user committee is running a couple of small, focused "operator mini-summits" over the next few months to bring operators together to share their feedback. Tim described the challenge running the committee with a small number of core volunteer members so as to ensure the privacy of survey results while also encouraging volunteers to help with tasks like turning survey feedback into blueprints for new features.

Van Lindberg gave an update on the legal affairs committee. He emphasised that the committee is not counsel for the foundation or the board, but rather a group which makes recommendations to the board on IP policy. He recapped on some of the patent policy recommendations from last year, for example that the foundation should join OIN. There was a brief mention of the fact that all the committee members are currently lawyers and the by-laws limits the number of members to five. He also mentioned that the DefCore committee has a related sub-committee examining possible by-laws changes.

Todd described the elections committee, that is was formed in February 2013 with 8 members and the goal to consider possible changes to the individual member election process. The committee is currently considering proposing a change to either Condorcet or STV and held a town-hall meeting in Hong Kong on the subject. Todd noted that the meeting was lightly attended and there generally has been rather low participation in the process. The main hurdle to getting such a change passed is that a majority of at least 25% of our individual members would need to vote for the by-laws change and the turnout for the previous election was only 17%. However, in July we will be able to begin making inactive members ineligible for voting and this should help us achieve the required turnout.

Rob gave an update from the DefCore committee[5] which is considering changes to the requirements for commercial implementations of OpenStack who wish to use the OpenStack trademark. The committee is currently working to identify a set of must-pass tests and the functional capabilities which these correspond to. Rob mentioned that some projects currently have no or minimal test coverage and, as a result, their capabilities could not be considered for inclusion in the requirements. Rob also mentioned a "programs vs projects" issue which had been identified during the committee discussions and that a meeting with the TC would be required to resolve the issue. I proposed that Rob and Josh could join the TC's IRC meeting to discuss the issue.

Finally, Simon gave a brief overview of the work of the gold member application committee. This committee helps prospective gold members prepare their application such that it fully anticipates all the questions and concerns the board may have about the application.

Wrapping Up

While there were some small number of other items on the agenda, we had run out of time at this point. In the short time available, we had covered a broad range of topics but hadn't really covered new ground. This meeting was mostly about rebooting the board for 2014.

These days, any time I reach for the word "meritocracy" when I want to explain something about OpenStack's technical community and its governance, I give pause.

Clearly, in some circles, the concept of "meritocracy" has been seriously discredited and represents a system whereby elites perpetuate their power by tilting the rules in favour of themselves.

I'm not much of a political thinker and my understanding of internal American politics is pretty limited (think watching The West Wing and vaguely following the spectacle of a presidential election) so the first time I really encountered the term was in the context of the GNOME project. From the GNOME Foundation Charter:

GNOME is a Meritocracy

A corporation, organization or individual should not be granted a place in the foundation unless its presence is justified by the merits of its contribution. Money cannot buy influence in the GNOME project: show us the code (or documentation, or translations, or leadership, or webmastering...).

and, subsequently, other projects like the ASF. From How The ASF Works:

When the group felt that the person had "earned" the merit to be part of the development community, they granted direct access to the code repository, thus increasing the group and increasing the ability of the group to develop the program, and to maintain and develop it more effectively.

We call this basic principle "meritocracy": literally, government by merit.

What is interesting to note is that the process scaled very well without creating friction, because unlike in other situations where power is a scarce and conservative resource, in the apache group newcomers were seen as volunteers that wanted to help, rather than people that wanted to steal a position.

Being no conservative resource at stake (money, energy, time), the group was happy to have new people coming in and help, they were only filtering the people that they believed committed enough for the task and matched the human attitudes required to work well with others, especially in disagreement.

To me, the "power" we're talking about here is the ability, permission or empowerment to get stuff done which advances the project. In some projects that means commit access, but ultimately it means building up the respect and trust of the other contributors to the project such that you can more easily influence and drive the direction of the project. You achieve that "power" by getting useful stuff done (defined broadly - code, documentation, translations, leadership, marketing, advocacy, etc.) and all it grants you is the ability to get more useful stuff done. In a healthy project, we want to give that power to more and more people rather than concentrating it in a small elite.

This is what we mean when we say "OpenStack is a technical meritocracy". I hate to think of those well-meaning principles of project governance being sullied by "meritocracy" being used to explain away the social inequities in U.S. politics. I also don't like to think of us seeing these principles as some sort of platonic ideal that don't require us to constantly evaluate how we empower people to help advance OpenStack.

One hint that all is not perfect is the level of diversity within the project. Yes, we have diversity of opinions and a diversity of sponsoring organizations, but we don't have an impressive level of gender, race or cultural geography.

My good friend from GNOME days, Daniel Veillard, asked this question of the Technical Committee in Hong Kong:

We are in China. There is no Asian on the podium. What can you do to actually try to improve the situation?

Yes, we have a meritocracy and anyone can advance to leadership positions within the project, but we need to recognize that there are extremely difficult language and cultural hurdles in front of many.

An example of these barriers is how we often conduct our Design Summit sessions. Quite regularly - especially when you get a large number of the more established contributors in the room together, folks who are good friends who understand each other well - the discussion can often devolve into a punchy flow of casual in-joke ridden sound-bites. I'm as much to blame for that as anyone, but sometimes I think back and shudder at how hard it must be for someone outside of the "in group" to join that discussion.

I've seen a number of examples where a new non-native English speaker has paired with an existing contributor to lead a design summit session about their work. What can work really well is that the existing contributor can help to engage the attendees, slow down the conversation and ensure the new contributor understands the feedback being given ... without attempting to take credit for the work of the new contributor. This is just one technique we could use to empower new contributors.

Anyway, in summary - I think OpenStack's "meritocracy" is a well-meaning model for empowering contributors (and celebrating their contributions) but we should all be on the lookout for ways that we can make a special effort to empower contributors from groups which are not already well represented in the leadership of the project.

tl;dr - the affiliation limit means that at most one of the two Red Hat affiliated candidates can be elected. The cumulative voting system makes it likely that both of us running seriously damages both of our chances of being elected. A preferential voting system like Condorcet or STV would not have this problem.

--

At Red Hat, those of us who contribute to OpenStack take very seriously our responsibility to put what's good for the project first and foremost in our minds - to wear our "upstream hat", as we like to say. That's especially true for me and Russell Bryant.

However, now that the candidate list for the 2014 OpenStack Individual Member Director Elections has been finalized, we find ourselves wrestling with the fact that Russell and I are both running as candidates. Two aspects of our election system make this a problem. First, the cumulative voting system means that those who would be happy to vote for either me or Russell are forced to choose between us - essentially, we are damaging each others' chances of being elected. Secondly, the affiliation limit means that even if we were both lucky enough to receive enough votes to be elected, one of us would be eliminated by the limit.

The combination of these two issues means that we have to factor our affiliation into our decision. The rules place affiliation front and centre in election system, even though Individual Member Directors are not elected to represent their employer.

Now, I'm personally guilty of not pushing this election system issue hard enough over this past year. At one point I favoured experimenting with a tweak to the cumulative system over a more dramatic change because I found the prospect of getting a majority of over 25% of our enormous electorate to vote in favour of a change so daunting. I want to be completely open about this decision we now face because I want to help raise awareness about how important an issue it is.

Given that Red Hat is a Platinum Member and has a automatic seat on the board, the options we're weighing up are:

1. Continue with both Russell and me on the ballot, accepting the risk that we're damaging each others chances.
2. I or Russell remove ourselves from the ballot, giving the other of us the best possible chance of being elected.
3. Brian Stevens steps down from the board and I or Russell takes his place, giving whichever of us remains on the ballot the best possible chance of being elected.

It's not an easy decision. We both feel we have something to offer on the board. Both of us would be very proud to be elected to represent the Individual Members. Both of us feel that Brian Stevens (our CTO who we greatly respect) is the best possible representative for Red Hat on the board.

We will make a decision on this before the election, but right now we don't see any of the options as being particularly better than the others. But, at the very least, I hope everyone will find this useful as a concrete example of why our election system needs to change.

I've been following the "what is core?" conversation since the "Incubation Update" committee completed its work some time ago. I'm really happy to see Rob, Alan and others put so much work into moving this along, but each time I try to catch up on progress I find myself a little bewildered.

Since it's going to be a big topic during next week's board meeting, I figured I'd try to get my thoughts together here.

What's it all About?

Even the question bothers me - "what is core?". Why is that an important question?

One reason for its importance is that the bylaws say:

The Core OpenStack Project means the software modules [...] for which an OpenStack trademark may be used

In other words, Heat can't call itself "OpenStack Orchestration" unless the Board of Directors approve Heat as part of "The Core OpenStack Project". If that was all this was about, I'd be like "hell yes! Heat should be known as OpenStack Orchestration!". But, it's clearly not just about this, so I tend to ignore this aspect. I don't actually think much of what is being discussed is all that relevant to this particular issue.

So, what else is this all about? Well, one clue is the emphasis on testing in Rob's list of "10 core positions".

OpenStack Core means passing all “must-pass” tests

This is an example of where I get really confused. Maybe I'm just getting hung up on language. I think we're talking about cloud providers, distributions, vendors, deployers, etc. self-certifying themselves using a test suite in order that they can use the OpenStack trademark. But are we talking about labelling these self-certified clouds as "Core"? Aren't we making this all very confusing by using the term "Core" both to describe the self-certified clouds/products and also to describe the subset of OpenStack they are required to include? I'd phrase this as:

The OpenStack Core definition includes a list of tests which certified clouds must pass

Anyway, I'm not going to nitpick my way through all of this. I think I understand the intent here, but I like to approach this from an entirely different angle.

A Market of Interoperable OpenStack Providers

(Yes, that is Simon Wardley's terminology)

We all know that one of the basic goals of OpenStack is for there to be a bunch of public clouds available to users around the world and that interoperability between these public OpenStack clouds will make it easier for users to switch cloud providers and encourage competition between these providers.

To my mind, that's what this whole "what is core?" conversation is really about. We want to use an OpenStack trademark program to help build this marketplace by enforcing interoperability between clouds which use the OpenStack trademark.

(And yes, I understand that the "what is core?" discussion is also related to questions like what is required of an OpenStack distribution. I'm focusing on the question of public cloud interoperability because I think it's the most important. IMHO, the whole conversation is pointless unless it moves this particular topic along quickly.)

To do that, we need to define which APIs these clouds must expose, or as Rob puts it - which use cases these clouds must support. To take a simple example, should these clouds be required to expose the Glance API for uploading images?

And here's where I get confused again. Why are we talking about "what is core?" when we could simply say "which APIs are required to be exposed by certified OpenStack clouds?". Again, I'm trying not to be a pedant, but the way the question is framed leaves me unsure whether we're really all talking about the same thing.

I think the focus should be on immediate baby-steps towards kick-starting this marketplace. One simple question - if and when we certify the first batch of interoperable clouds, would we rather have a smaller number of big clouds included or a large number of smaller clouds? In terms of resource capacity provided by this marketplace, I guess it's more-or-less the same thing.

Let's assume we absolutely want (at least) a small number of the bigger providers included in the program at launch. Let's say "small number" equals "Rackspace and HP". And let's assume both of these providers are very keen to help get this program started. Isn't the obvious next baby-step to get representatives of those two providers to figure out exactly what level of interoperability they already have and also what improvements to that they can make in the short term?

If we had that report, we could next do a quick "sniff test" comparing this to many of the other OpenStack clouds out there to make sure we haven't just picked two clouds with an unusual set of compatible APIs. Then the board could make a call on whether this represents a reasonable starting point for the requirements of OpenStack clouds.

No, this isn't perfect. But it would be a genuine step forward towards being able to certify some clouds. We would have some data on commonalities and have made a policy decision on what commonalities are required. It would be a starting point.

OpenStack Compatible?

The next big decision for the board is whether a cloud which uses the OpenStack trademark must actually be a deployment of OpenStack's code. Is this a question of "OpenStack clouds" or "OpenStack compatible clouds"?

I do think it would be damaging to OpenStack if this marketplace took off and was dominated by providers which don't use or contribute to OpenStack. But, as Rob says, the trademark isn't the only way of avoiding this situation - there's also our "velocity and culture".

I struggle to see how trademark requirements around the use of OpenStack code would work. How do you define which code must be used? Must that code be used unmodified? If not, how much can you change? What does it even mean to "use" a piece of code? That user requests must be executed using that code? Maybe this would just be a "yes, we use and contribute to OpenStack" good faith statement which the Foundation would make a judgment call on? If so, how do we ensure transparency and fairness around how that call is made?

If this question proves to be a stumbling block, I'd prefer to see an "OpenStack compatible cloud" trademark program established quickly. Getting these interoperability guarantees in place for our users takes priority over ensuring that certified providers actually use and contribute to OpenStack.

Conclusion of Sorts

I think our immediate concern should be kicking off a trademark program for certifying interoperability between OpenStack clouds. I'm frustrated whenever I think this "what is core?" discussion is tackling questions which aren't immediate blockers to making progress on this program.

The board has to make (or oversee the making of) some policy questions.

Firstly, what APIs are required in OpenStack™ clouds? I'd favour starting to answer this by first looking at the current interoperability levels between existing clouds.

Secondly, whether and how we insist on the use of OpenStack code in OpenStack™ clouds. If this turns out to be a difficult problem, then I think we should just start with an "OpenStack™ compatible cloud" program.

The results of the OpenStack Technical Committee have just been announced. I'm very grateful to everyone who voted for me. Thanks!

This is going to be a very different committee than previously. For the first time, PTLs of integrated projects do not have an automatic seat. I think this will be a positive change and see TC members generally take more of an interest in cross-project issues. That said, we need to be careful to explicitly include PTLs in decision making which affect their projects.

One thing I'm curious about is how this new TC makeup will affect discussions about the increase in OpenStack's technical scope. I went through each of candidate's nomination emails and pulled out some quotes below. To me, this represents a high level of consensus towards a continued cautious and measured growth in the project's scope ... but make your own mind up! I'm actually quite surprised how many candidates felt it was important to give their views on this.

Monty Taylor

I have an expansive view of the scope of OpenStack. I do not think that 'pure IaaS' as a limiting factor in the definition serves or will serve any of our users. I think that instead of trying to come up with random or theoretical labels and then keeping ourselves inside of the pre-defined label, we should focus on writing software that solves problems for users.

Russell Bryant

One of the most exciting things for me over the last year has been helping to expand OpenStack by including a number of new projects. I think this growth is important for OpenStack's success. I would like to continue to help guide this growth and to help figure out how OpenStack can scale as an organization and still be effective.

Anne Gentle

My goal is to provide an inclusive and supportive environment for projects while making OpenStack better for users and admins all the time. We are so fortunate to have the explosive growth and interest in OpenStack, and I want it to continue. We have built upon incredible ideas and I want us to be empowered to innovate.

Mark McLoughlin

We welcomed Heat, Ceilometer, Trove, Savannah, Marconi into the OpenStack family either as integrated or incubating projects. The TC carefully considered each of these applications and my own rule of thumb was "does it have a healthy contributor community and is it a sensible growth of OpenStack's scope?". I love to see this sustainable growth in our project and community.

Doug Hellmann

I share the view of many of the other candidates that OpenStack should not limit itself to today's definition of IaaS. The history of computing is a progression of different levels of abstraction, and what we consider "platform" today may become "infrastructure" tomorrow.

Sean Dague

I'm incredibly excited by OpenStack's growth (in people, code, scope), which I attribute to an incredibly welcoming and constructive community, and the velocity we get out of our preemptive integration system. As a TC member I'd do my best to ensure those conditions remain. I think we've only just begun to see what OpenStack will become [..]

James E. Blair

As a significant OpenStack user, I'm excited about the direction that OpenStack is heading. I'm glad that we're accepting new programs that expand the scope of our project to make it more useful for everyone. I believe a major function of the Technical Committee is to curate and shepherd new programs through the incubation process. However, I believe that it should be more involved than it has been. We have been very quick to promote out of integration some exciting new projects that may not have been fully integrated. As a member of the TC, I support our continued growth, and I want to make sure that the ties that hold our collection of projects together are strong, and more than just a marketing umbrella.

Michael Still

First off, the TC has incubated a number of projects in the Havana release, and I'd like to see that continue. I think its important that we build a platform that includes the services that a deployer would
need to build a cloud and that those platform elements work well together. Now, its clear that not everyone will deploy all of the projects we are incubating, but I think its still important that they play well together and have a consistent look and feel.

John Griffith

New projects and growth are important to OpenStack however I don't think that uncontrolled and disjointed growth in the form of new projects is a good thing, in fact I think it's detrimental to OpenStack as a whole. I personally would like to see the TC have more involvement in terms of recommending/investigating new projects before they're proposed or started by others. By the same token, I'd also like to see the TC take a more active role in the projects we currently have and how they all tie
together. I personally believe that having 10 or so individual projects operating in their own silos is not the right direction. My opinion here does NOT equate to "more control", but instead should equate to being more helpful. With the continued growth of OpenStack I believe it's critical to have some sort of vision and some resources that have a deep understanding of the entire eco-system.

Mark McClain

The issue of scope was a recurring theme during my recent term on the TC. As the OpenStack ecosystem grows beyond Infrastructure as a Service, the committee needs to more clearly define the criteria used to determine the kind of projects and programs that fit within the scope of integrated releases and how they move through the progression of incubation to graduation. In addition to defining the criteria, the Technical Committee should to work develop policies and procedures to provide some guidance to projects which are outside of the scope an integrated release, but valuable to our community.

Robert Collins

(I don't see a directly relevant quote from Robert)