So what did we learn from the spider map exercise? Above all else, the spider confirmed that to me that OpenStack is a world of paradox. The perfect definition of core may be elusive, but I believe we can find one that is sufficient.
The goal was understanding not philosophical truth. In a diverse and vibrant community with many objectives, understanding leads to consensus while being “right” can become very lonely.
Since our goal was not to answer the question, what did we want to accomplish? Spider success was defined as creating a framework, really a list of agreed positions (post #4), that narrows the scope of the “what is core” dialog.
Too vague a framework leads to uncertainty about what’s included, stable and working while too rigid a baseline could drive away innovation and lead to forking. Being too aggressively open could discourage commercial investment yet too proprietary an approach contradicts our collaboration and community values.
Having a workable framework that accommodates these diverse positions allows us to move forward.
So what did Alan and I learn from the spider to help the discussion?
- “Plug-ins” are essential to the definition of core because they create safe places for innovation [note: there has been much refinement of what “plug-in” means here]
- It is possible to balance between stability and innovation if we have a way to allow implementations to evolve
- OpenStack has a significant commercial ecosystem that needs to be accommodated in core
- We need an approach that allows extension and improvement without having to incubate new projects
- We need to ensure that we use brand and culture to combat forking
- Interoperability is a worthy goal
- Everyone thinks testing is good, but it’s still a sidebar
- There are multiple distinct audiences with conflicting goals: some want stability and durability while others want innovation and flexibility.
Of these insights, the need to discuss how OpenStack promotes a plug-in architecture seemed address the most points of tension. [update: in the course of discussion, we’ve defining plug-in more generally to be something like “a designated section of implementation code that can be altered without negatively changing the base function of the project.”]
This is not the only item worth discussing, but it was the one that made the most sense to cover first based on the spider map. Our idea was that having the community find agreement on how we approach plug-ins would lead us closer to a common ground for the “what is core” discussion.
Finding a common thread shrinks the problem space so the Board, TC and Community can advance in discussion. So far, that assessment has proven accurate enough to move the dialog forward.
READ POST IS #4: TWELVE POSITIONS
It’s time to move to the what from the how and why. In my experience discussing the framework, it’s important to understand the context at this point because our objective is to define the common ground. If you mistake the intent then it’s much harder to understand the details, but here they are…
Rob Hirschfeld 