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:`
Extensions – wants to fast track
Core – new undermines stability
Plug-ins – can bypass incubation
Project entry process
Control # of projects while maximizing innovation
Incubation – can bypass process
Implementation – requires APIs
Core – which plug-ins are required?
Project entry requirements
Level playing field
Implementation – slows APIs
(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 – slows working models
Core – vendors want differentiation
What is core?
Incubation – new undermines stability
Plug-ins – which are required?
Trademark – perceived value
Testing – big core is harder to test
Implementation – hard to specialize
TAM / Portability
Implementation – no specification
Extensions – hard to test vendor specific additions
Preparing for the Future
Growth vs. Stability balance
READ POST IS #3: WHY PLUGGABILITY IS IMPORTANT