Introducing the OpenStack Spider Graph: untangling our web of interdependencies

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

peaceOne 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.

spider boardAlan 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

7 thoughts on “Introducing the OpenStack Spider Graph: untangling our web of interdependencies

  1. Pingback: Kicking off discussion about OpenStack Core | Rob Hirschfeld

  2. Pingback: My insights from OpenStack “what is core” Spider > we need pluggable architectures | Rob Hirschfeld

  3. Pingback: OpenStack and AWS APIs: Getting to the core of the matter | Speaking of Clouds - Distributed applications and virtual infrastructures

  4. Pingback: Twelve straw man positions to frame OpenStack “what is core” discussion | Rob Hirschfeld

  5. Pingback: What makes OpenStack meaningful to the market? | Rob Hirschfeld

  6. Pingback: Spinning up OpenStack “DefCore” Committee by spotting elephants | Rob Hirschfeld

  7. Pingback: OpenStack Core Definition (DefCore) Progress in 6 key areas | Rob Hirschfeld

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s