This post is #2 in a series about “what is core.”

One of the OpenStack Foundation’s most fundamental responsibilities is to define “what is core” for the OpenStack project.  A simple yet urgent question with profound implications for the project’s success; consequently, it’s no surprise that finding a consensus answer has been a thorny problem.   In fact, the answer (it’s 42, of course) is so convoluted that we had to step back establish common ground before we could proceed. I’m proud to say that we’ve made substantial progress towards establishing a framework for the discussion.   

This post (#2) is about the process we followed.  My next post (#3) is about what we learned.  Next, we want to engage the community in discussing the baseline positions (post #4) that make up the framework.   The challenge in discussion was that the Board (and Community) lacked common baseline.  When one person talked about commercial extensions to core another would insist that core always be open.  There are compatible statements; yet, we’d often talk past each other because the question was simply too big and fuzzy.

Alan Clark, Foundation Board Chairman, and I took on the task of breaking the logjam by decomposing the problem.  We used a multilayered mind map that I called the “spider” chart (yes, it’s a misnomer).  In constructing the spider, we first flagged out issue areas (the nodes) and added goals (red text) for each issue area.  Next we linked connected nodes together to form a graph.  We added blue text on connections where goals were opposed or in tension and green text where goals were aligned.

Note: Some of our text is controversial – it was our objective to find the tension.  If you are looking at the image, we also created some grid and flow charts to test the map.

We did not time capture the spider so it’s impossible to sweep back and see how the ideas progressed.  In general, we started at the center from “IncUp Discussion” which was the TC and Board’s collaboration, led by Alan, to define the process by which projects are promoted from incubation to integrated projects.

Some topics were easy like “API vs Implementation” and “Trademark” while “Implementation Led” and “Plug-ins” were more difficult.  Some clarification on those two items is worthwhile:

Implementation Led describes the OpenStack community for starting from working implementations rather than designing an API.  In my experience, this pattern serves the community well as long as we accept that APIs and implementations in incubated projects will take time to mature.   Using this approach gets us out of prolonged design by committee spirals.  It has serious pitfalls also – there’s no milk and honey approach. Plug-ins represented a big pot of politics in the community that was part of the challenge in defining what is core.  The obvious issue is that not all core projects use plug-ins and the ones that do take different approaches.  Even so, we felt that the concept of multiple implementations with a single API was a significant part of the opportunity (and challenge) for OpenStack core.

Ultimately, we decomposed the spider graph into the following table that shows some of our thoughts in raw form.  I’ll discuss the actual insights in my next post (#3) Continue reading →