Bringing “OpenStack Futures” to the OpenStack Foundation Board in 2017

The Board will be asking hard questions in 2017 about the direction and charter of the project and I’m uniquely positioned to help find answers to those questions due to my extensive involvement with different initiatives in the community. I also have experience with creating open source strategy at organizations, a good network with other open source communities and help with product strategy at IBM. As co-chair of the OpenStack Product working group, I will ensure that we leverage the skill-sets and aggregated feedback from the working group.

I believe that the OpenStack Product working group should also be involved with the “OpenStack Futures”1 topic since we have product managers from multiple organizations and we help facilitate the aggregation of user/market needs in the OpenStack community.  This context will be valuable in the upcoming conversations.

As a member of both the Board and Product Working Group, I am ideally suited to participate actively in this topic.  

If I am elected, I will raise/address the following topics:

  •      Fostering collaboration between adjacent open-source projects (see my previous blog post)
  •       Ensuring that we are able to be responsive to the needs of our user community (some of which may not have upstream developers) as OpenStack clouds gain further adoption
  •      Developing a strong ecosystem of services that run on, or support, OpenStack clouds and to also make them feel welcome in the community even if they are outside of the project itself
  •      Re-evaluating the criteria for Big Tent membership beyond the technology and four opens to also include strategic fit

Overall, there are a number of fantastic candidates this year and you can familiarize yourself with their positions by reading their answers to the candidate questionnaire. Rob Hirschfeld is one candidate I’d like to highlight since he is a startup CEO and very active in the Kubernetes community… please consider reading his post on why he is running too.

I hope that I adequately highlighted what I want to accomplish as an Individual Director and earned your vote.  This is a defining year for OpenStack and I want to participate in shaping its future.   Elections are open from January 9th (00:00 UTC) to 13th, 2017 (22:00 UTC).

1 Additional background: In 2016, several organizations that are key contributors to the OpenStack community had layoffs and re-orgs and the overall number of core contributors in the OpenStack community was reduced. This, along with other events, prompted the Board to start discussing a topic called “OpenStack Futures” which includes framing questions that should be considered by the Board regarding the future of the project. Mark McLoughin (OpenStack Board Member) did a great job of summarizing the board meeting on his blog.

Detangling the wires

Cloud and related technologies have seen a lot of entrants in the last 2-3 years and because these technologies are gaining momentum it seems that the pace of innovation has taken precedence over defining ‘who are we building this for?’  This post offers  my perspective on how things like cloud, containers, resource poolers and platforms as a service fit together to build a supply chain.  

It is important to define what we are building first before we can discuss how the supply chain might look.  The product in our scenario is an end-user facing application (e.g. mobile app, intranet widget, LOB system, etc.) whose purpose is to provide value (benefits > cost) to the end-user.   With this product definition in mind, let’s look at the ‘possible suppliers’*.

  •      Configuration Management tools
  •      Cloud
  •      Container Orchestration Systems
  •      Platform as a Service
* This is a simplified list of suppliers, as it does not include infrastructure, continuous Integration tools, service registries, and other suppliers in the full chain.

The ‘application’ will be built, staged, and deployed before it can serve its purpose of providing value to the end-user.  In order to accommodate the lifecycle… we will need to provide infrastructure resources, deploy the necessary dependencies and runtimes, conduct tests to validate functionality, ensure connectivity and let users know how to find it.

Many of the suppliers are pursuing vertical integration strategies in terms of trying to provide a single tool that does too much and it becomes hard to select the right supplier since they are all stronger in certain areas while weaker in others.  Ideally, we should be able to understand the strengths of suppliers and ensure that their relationship and delegation to the next player in the supply chain is seamless.

Here’s how I believe some tools are being positioned:

verticalintgeration

Here’s how I believe they ideally provide value in the supply chain:

idealdemarcation

Cloud should focus primarily on the operators and platform developers experience to provide a solid foundation of services/APIs that can be leveraged by the other suppliers in the chain to minimize scope creep. Container orchestration systems and PaaS should focus on delivering/deploying code as efficiently as possible.  They should not have to recreate the lower-level services provided by the cloud, the primary audience here should be the teams responsible for providing the development platform for the organization.  The application developer should only be interfacing with the container orchestration system or PaaS while focusing on the end-user application.  The user themselves should be unaware (as much as possible) of the underlying systems.  It is also important to note that, while not depicted in the diagram, resource pooling systems should also focus on the operator experience.

 
If this supply chain view holds then it would make sense for adjacent suppliers to work closely with each other to provide as much integration as possible while having clear demarcation points. This is simply my take and I understand that it may not be right but hopefully it will spark a good discussion.