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)

• Directed SPIDER Graph:`

  Topic	Objective	Tension w/	Harmony w/
  Incubation	New Technology	Extensions – wants to fast track Core – new undermines stability Plug-ins – can bypass incubation	Project entry process Implementation lead Trademarks
  Plug-Ins Required	Control # of projects while maximizing innovation	Incubation – can bypass process Implementation – requires APIs Core – which plug-ins are required?	Ecosystem
  Project entry requirements	Level playing field	Implementation – slows APIs	Incubation Implementation
  Implementation lead (vs. design by committee)	Fast pace of delivery	Plug-ins – requires APIs API –hard to converge quickly Interoperability – no specification Anti-Forking – hard to specialize	Incubation
  Defined API	Standards	Incubation – slows working models	Trademarks Ecosystem Interoperability
  Ecosystem	Brand strength	Core – vendors want differentiation	Anti-Forking Trademark Extensions Interop
  What is core?	Stability	Incubation – new undermines stability Plug-ins – which are required? Trademark – perceived value Testing – big core is harder to test	Future Extensions
  Anti-Forking Culture	Shared effort	Implementation – hard to specialize	Interop Ecosystem
  Interoperability	TAM / Portability	Implementation – no specification Extensions – hard to test vendor specific additions	Anti-Forking Test Suites API
  Preparing for the Future	Durability	Growth vs. Stability balance	API Stable Core Test Suites Trademark

  READ POST IS #3: WHY PLUGGABILITY IS IMPORTANT