Blockchain and Climate Change

Disclaimer: Relative to my expertise in something like OpenStack, or relative to the expertise of folks who are working daily on driving advancements in the fundamentals of Blockchain and related technologies, I know next to nothing about Blockchain. However, relative to the average member of the public, I believe I have enough understanding as a technologist to help demystify the subject for other non-experts.

The context for this post is that I attended the recent Climate Innovation Summit in Dublin, which primarily focused on the challenge of financing solutions in the area of Climate Change mitigation and adaptation. To my surprise, the subject of Blockchain seemed to be the main pure technology topic that came up again and again.

Before this event, and without exploring the area too deeply, I had a suspicion that Blockchain is all too often "a solution in search of a problem". This all too common tendency of technologists makes me grumble at the best of times, but when the subject is a technology that is impenetrable to many people, and the problem space is what I believe to be an existential threat to our way of life ... I have grave reservations, to put it mildly.

Much credit goes to EIT Climate-KIC for publishing a report titled Distributed Ledger Technology for Climate Action Assessment which I will refer to heavily below. In large part, my goal here is to highlight the key points and conclusions I took away from that report.

What Problem Does Blockchain Solve?

Blockchain is designed to be an alternative to centralized systems. What does that mean? Well imagine:

  • A database with no central administrator
  • A currency with no central bank
  • A contract that is enforceable without recourse to a judiciary

and you start to get a sense of this problem space. This is quite appealing, on the face of it. A decentralized system should be more fault tolerant and attack resistant because there is no single point of failure, and it should also be more trustworthy and resistant to abuses of power because of the transparency it offers.

And then there's the idea of "social scalability", as researcher Nick Szabo is quoted in the Climate-KIC report:

Scaling human traditional institutions in a reliable and secure manner requires increasing [the number of] accountants, lawyers, regulators, and police, along with the increase in bureaucracy, risk, and stress that such institutions entail."

Solving problems without needing any more lawyers? Hurrah!

Why is Decentralization a Hard Problem?

The Climate-KIC report does a nice job of explaining the 5 components of this solution to the decentralization challenge:

  1. Cryptography - public key encryption and hashing functions allows protecting the privacy, integrity, and even the anonymity of data in the system. This is familiar technology used in secure websites with HTTPS, for example.
  2. Hash tree - this is simply a list of records whose integrity is protected by a cryptographic hash on each record which combines the hash of the previous record, a timestamp, and the transaction data. This is a well-understood concept that is used to good effect in systems like the Git Version Control System (VCS).
  3. Peer-to-peer networks - this is allows you to build resilient storage by having peers in a network replicate data to other peers. Heard of Napster and Bittorrent?
  4. Consensus mechanism - how can you authenticate and validate a transaction in a peer-to-peer network without appealing to a central authority? Take a look at the Byzantine General's Problem. It's difficult.
  5. Sybil control mechanism - how do you protect against an actor in the system generating a large number of fake identities, known as a Sybil attack. This too is hard. Bitcoin's answer is to make it prohibitively expense to abuse the system this way, with its "Proof of Work" system known as mining.

The first three components - cryptography, hash trees, and peer-to-peer networks - are well established, and it would be possible to use them to build an effective, highly-distributed database with the aid of a central authority (to e.g. decide who can be trusted to write to the database).

However, to make that database fully decentralized - especially with anonymous actors writing to the database - some really difficult challenges are introduced, and that's where the consensus and Sybil control mechanisms come in. These are much more challenging problems, and Blockchain is one relatively recent foray into this area.

Note - in the report, the "Do you need a Blockchain?" flowchart highlights the idea of a "Permissioned Blockchain" suitable for a case where all actors are known but untrusted. That does eliminate some of the difficult problems in this space, but catering for untrusted writers is where much of the complexity remains.

Note also - the report also references an excellent article called The Truth About Smart Contracts by Jimmy Song which highlights the challenge with attempting to specify and enforce the rules of a contract using (potentially buggy) computer code without allowing for appeals to a central authority to interpret the "spirit" of the contract. And also the challenges of attempting to link such decentralized contracts with the physical world.

Blockchain Inefficiency

Given the challenges that full decentralization brings, it's not surprising that Blockchain has some drawbacks. To quote some of the points that jumped out at me in the Climate-KIC report:

DLT is a highly inefficient database technology that is up to 1 million times less efficient than a centralised database, which in turn leads to much higher energy consumption and GHG emissions.

Given that we're talking about Blockchain in the context of Climate Change mitigation, that seems important to consider!

the trade-off between low energy efficiency and higher levels of decentralisation is the key question in the DLT for climate action ecosystem and needs to be addressed for each potential DLT solution

Blockchain's inefficiency and higher emissions should be weighed up against a need for decentralization.

To determine whether DLT is the right tool to solve a given problem, it should be validated that DLT is the only solution to the given problem. If DLT is not the only solution, also a more efficient centralised database can solve the problem.

In other words, you should only consider Blockchain if you've already eliminated the possibility that a centralized system could be sufficient.

A more entertaining take on whether Blockchain is a good fit for your application, from James Mickens:

How Important is Decentralization To Addressing Climate Change?

This is the key point. As Kirsten Dunlop said in her keynote at the Climate Innovation Summit:

We have 12 years to set in place profound structural change in almost every system of cause and effect in our society

Some of "Climate Action" use cases and examples for Blockchain listed in the Climate-KIC report includes:

  1. Energy - peer-to-peer energy trading
  2. Supply chain management - reduce paperwork, fraud, and errors
  3. Carbon trading - a more transparent carbon marketplace
  4. Transportation - decentralized ride sharing
  5. Open government - increased transparency and accountability in government
  6. Measurement Reporting and Verification (MRV) - more transparency in carbon tracking
  7. Finance - new ways of financing climate projects

More or less implied here is that the problems associated with centralized systems are on the critical path to effectively addressing these use cases.

The Climate-KIC report says:

While climate change is a truly global problem, it is well recognised that it requires a decentralised, multi-stakeholder, bottom-up approach to be solved

And that's hard to argue with! I'm a big proponent of bottom-up innovation guided by a unifying mission, and certainly such a huge problem space can't be tackled top-down. Mariana Mazzucato's report on Mission-oriented research & innovation in the European Union looks like an excellent framework. And when it comes to Climate Change, we are all stakeholders.

But ... does that really imply that the technology platforms we use must be decentralized? For example, a crowd-funding platform hosted by a single legal entity can still be effective, without itself being decentralized. Can a sufficiently high level of trust and transparency be achieved without fully decentralizing the platform? I believe that is often the case.

To quote the Climate-KIC report again:

DLT’s main power lies in decentralisation. It currently is unclear how the physical centralised world can be decentralised. [...] As many climate action solutions are more valuable when synchronised with the physical world, this barrier is a key barrier to overcome.

Decentralization and anonymity brings up some pretty fundamental questions about how human society is organized. And undoubtedly, tackling Climate Change effectively is going to require fundamental changes in our society. As Naomi Klein put it, This Changes Everything.

But are the problems that Blockchain claims to solve really the key problems getting in the way of effective Climate Change mitigation and adaptation efforts? Even if they are, are there other "good enough" solutions without the drawbacks of Blockchain that can be deployed more rapidly?

What I really worry about here is the danger that Climate Change will be perceived by some as a smokescreen for people pushing pre-existing agendas that aren't strictly related to the challenges posed by Climate Change. To take a more extreme example, how likely are we to mobilize the sort of action needed if people sense they are also being asked to buy into Anarchism as a political philosophy?

Conclusion

There is no doubt that Blockchain is a super interesting technology, and it has opened the door to exciting advances in some truly difficult computer science problems.

If you are motivated to explore how technology can be used to move towards a more decentralized society, by all means you should go down the Blockchain rabbit hole!

However, if you are primarily motivated to rapidly implement Climate Change mitigation and adaptation solutions in the real world, I would suggest that you can safely focus your limited resources on technologies other than Blockchain.

September 10th OpenStack Foundation Board Meeting

The OpenStack Foundation met in Denver on September 10th for a Joint Leadership Meeting involving the foundation Board of Directors, the Technical Committee, and the User Committee.

The usual disclaimer applies - this my informal recollection of the meeting. It’s not an official record.

Foundation Events Update

We began with an update from Lauren, Jonathan, and Mark on the events that have happened so far this year, the Project Teams Gathering (PTG) in Denver this week, and the coming OpenStack Summit in Sydney.

Lauren outlined some details of the recent Pike release, emphasizing the positive media coverage of the release, with the "composable infrastructure services" messaging resonating.

Jonathan talked about the many OpenStack Days events that happened over the summer, including Melbourne, Tel Aviv, Budapest, Korea, Taiwan, Japan, and China. Jonathan has attended all of these, covering 13 countries since the OpenStack Summit in Boston and he spoke about the many new users and new use cases that he learned about over the course of these events. More OpenStack Days are coming this year including Benelux, UK, Italy, Turkey, Nordic, Canada, France, and Germany.

Mark spoke about the OpenDev event held the previous week in San Francisco. The goal was to bring in people who are experts in different domains, and the important and emerging use case of "Edge Computing" was chosen for this first event. The keynote from Dr Satya of Carnegie Mellon University was mentioned as one particularly inspiring contribution.

An particularly interesting conclusion from one of the sessions was a simple definition of what Edge Computing actually is:

Edge is the furthest boundary that separates application-agnostic scheduled computing workloads within the same operator's domain of control, from applications or devices that can't schedule workloads, and are outside the same operator's control.

(Thanks to Dan Sneddon for pointing this out!)

Another interesting development is the collection of edge use cases which will be published to Edge Computing mini-site on openstack.org.

The PTG was touched on next - more than 400 contributors in attendance from 35 project teams, with the first two days focused on the strategic goals of simplification, adjacent technologies, onboarding new contributors, etc.

Jonathan also talked about the coming OpenStack Summit in Sydney. We are aiming for 2500+ attendees, and the amazing work by the program committee to work the 1100 speaking submissions into an awesome three day schedule has been completed. There will be Hackathon focused on Cloud Applications the weekend before the event.

Finally, we looked forward to the OpenStack Summits in Vancouver in May, and Berlin the following November.

The Strategic Focus Areas

Back in March, at the Strategic Planning Workshop in Boston, we developed a set of 5 strategic focus areas and formed working groups around each of these. For each of those focus areas, the working group presented their findings and progress, followed by some discussion.

Better communicate about OpenStack

Thierry Carrez and Lauren Sell lead the discussion of this topic with a set of slides.

We began by discussing progresson developing a map of OpenStack deliverables. The idea is for the map to make it easy for users of the software to make sense of what OpenStack has to offer, and one key part of this mapping effort is to categorize deliverables into buckets:

  • openstack-user: Things an end user installs to consume the IaaS stack
  • openstack-iaas: Primary compute, storage & networking services
  • openstack-operations: Things an operator uses to manage an openstack cloud once installed
  • openstack-lifecyclemanagement: Things that help deploy/upgrade OpenStack or standalone components
  • openstack-adjacentenablers: Things that other infrastructure stacks can use to leverage individual OpenStack components

Some of the outstanding questions include how to represent projects which are coming down the line, where various types of plugins should live, and whether Glance is tied to Compute or should be represented as a Shared Service.

After the meeting, Lauren sent out a request for everyone to contribute their feedback on the draft of the map. Please do join in!

Next, we discussed at some length how OpenStack has been affected by "Big Tent" concept where we welcome collaboration, experimentation, and innovation on "infrastructure things" beyond the core OpenStack technology. We've know that users have found it difficult to make sense of the breadth of project teams, and we have created further confusion around "what is OpenStack".

Our discussion on this revolved around the idea of separating the technologies directly related to the deliverables map above (which we could call "OpenStack IaaS and friends"), the "software forge" infrastructure project, and the free-for-all project hosting area previously known as Stackforge. There was broad consensus that we should give each of those its own identity, which is particularly exciting when you think of the potential for "Infra" to have an identity that isn't so closely tied with OpenStack. We also discussed the potential to extend this model to other projects in the future, but also our desire to not become a "Foundation of Foundations" or a collection of entirely unrelated projects.

Requirements: Close the feedback loop

Melvin Hillsman and Thierry Carrez talked us through the unanswered requirements strategic focus area.

The focus of this discussion was on the creation of OpenStack Special Interest Groups (SIGs) as a mechanism to have cross-community collaboration on a given topic, without the work being under the umbrella of any one governance body.

The SIGs created so far are:

  • a Meta SIG to discuss how to improve SIG processes
  • an API SIG, which is an evolution of the API Working Group already formed, and
  • a still-forming Ansible SIG, with the goal of facilitating collaboration between Ansible and OpenStack projects.

Community Health

On this topic, Steve Dake talked us through some efforts to help grow the next generation of leaders in the OpenStack community, supporting people who wish to become a core contributor or PTL. Steve particularly highlighted efforts along these lines within the Kolla project.

Increase complementary with adjacent technologies

Steve Dake again took the lead on presenting this topic, focusing on success stories of collaboration between OpenStack and other communities - Ansible and Helm, in particular.

For Ansible, it was observed that OpenStack has built upon Ansible's highly reusable technology in many ways, and OpenStack members have contributed significantly to the Ansible modules for OpenStack based on Shade. The conclusion was that the success was down to (a) building releationships between the communities, (b) leadership endorsement, and (c) the simplified collaboration process adopted by Ansible.

For Helm, the collaboration has been focused in areas where Helm is being used to deploy OpenStack services on Kubernetes.

Finally, Dims gave a read-out on collaboration on OpenStack within the Kubernetes community, mostly with work in the OpenStack SIG focused on the OpenStack cloud provider.

Technology changes: Simplify OpenStack

For our final strategic focus area, Mike Perez gave an update on progress. He described projects which have recently been retired, the OpenStack manuals project migration, and the status of a number of projects who are seeing low levels of contribution activity.

Clarifying and communicating where help is needed

Next up, Thierry walked us through the TC's mechanism for exposing areas where help is needed in the community. We talked through this "top 5 help wanted list" and had a good discussion on the two items currently on the list - Documentation and Glance.

Interoperability Working Group

As our final topic, Egle Sigler gave an update from Interoperability Working Group.

The first item of business was to approve the 2017.09 guideline. Both the compute and object components gained some new capabilities in this update.

As discussed in the previous meeting, the working group proposed the creation of "add-on" programs which would focus on interoperability between different implementations of a given service, without having to add that service as a requirement in the core OpenStack Powered programs. As a starting point, it was proposed to create advisory add-ons for DNS (Designate) and Orchestration (Heat). After some discussions on the implications of these additions, they were formally approved by the board.

Next Meeting

The board's next meeting is a 2 hour conference call on Tuesday, October 10. Our next in-person meeting will be in Sydney on Sunday, November 5.

June 20th OpenStack Foundation Board Meeting

The OpenStack Foundation Board of Directors met for a two hour conference call on Tuesday. The usual disclaimer applies - this my informal recollection of the meeting. It’s not an official record. Jonathan Bryce has posted an official summary of the meeting.

Interoperability Working Group Update

After the usual formalities of a roll call and approving the previous meeting minutes, the board heard from Egle Sigler, Mark Voelker, and Chris Hoge of the Interoperability Working Group.

The topics of the discussion are laid out in the working group's board report with Egle covering the upcoming 2017.08 guideline, Mark covering the proposal for extension programs, and Chris covering version 2.0 of the interop schema.

The extension programs proposal resulted in the most discussion. Mark described how the proposal explains how the OpenStack Powered trademark programs work today, the history of those programs, and how the additional programs would work.

The first type of program is a "vertical" program - examples given include "OpenStack Powered for NFV" or "OpenStack Powered for Containers". These would add requirements for additional capabilities specific to these use cases, provided those capabilities are already widely deployed in the context of those use cases.

The second type of program is an "add-on" program - for example, "OpenStack Powered DNS". This would require capabilities specific to that service, and ensure interoperability between implementations of a given service. It is anticipated that individual project teams would be responsible for definining the interop requirements.

Anni asked how these programs would relate to the idea of "constellations" as a way of describing OpenStack components, but the working group didn't see any immediate overlap with that idea.

I raised a concern that if obscure projects are free to define add-on programs of their own, it could dilute the value of the OpenStack Powered programs overall. However, it was clarified that, while the individual project teams could define interop requirements, each individual new program would require board approval.

Anni also raised a concern that vertical programs should not be exclusive - i.e. it should be possible for a single product to qualify for all vertical programs at once, so these programs need to not have conflicting requirements. The working group agreed with this, and explained that they had already taken this feedback into account.

Finally, the working group explained that their goal is for the board to approve this framework at our Fall meeting.

Membership Changes

The last topic for the board to consider was some membership changes and applications. Put simply, Canonical wished to move from being a Platinum member to being a Gold member, and Ericsson wished to apply for Canonical's Platinum member slot.

Chris Price presented Ericsson's case for Platinum membership. Interestingly, this was the second time that Ericsson had applied for Platinum membership in the past year. The previous time, at the March 9 board meeting, Ericsson and Huawei applied for the slot left vacant by HPE. Huawei was successful with their application that time around.

Chris explained Ericsson's vision for OpenStack, and how they plan to continue developing and driving forward the OpenStack ecosystem. He also explained Ericsson's role in working with adjacent communities like OpenDaylight and OPNFV, as well as their role in related standard's bodies.

Next up, Mark Baker described how Canonical felt that with several "industry giants" looking to take up Platinum membership, that the right thing for a smaller entity like Canonical to do from a community perspective, was to take a step back and allow others with greater resources to take their Platinum member slot. However, he also emphasized how OpenStack remains at the core of Canonical's business.

After some brief questions, the board went into executive session and, on return, both applications were approved.

Next Meeting

The board's next meeting is a 2 hour conference call on Tuesday, August 22. Our next in-person meeting will be in Denver on Sunday, September 10.

March 9, 2017 OpenStack Foundation Board Meeting

The OpenStack Foundation Board of Directors met in-person for two days in Boston last week.

The first day was a strategic planning workshop and the second day was a regular board meeting.

Executive Director Update

After a roll call and approving the minutes of the previous meeting, Jonathan gave a presentation outlining his perspective on where OpenStack is at.

He talked about perception challenges that the Foundation is working to address, emphasizing the messages of "costs less, does more" and "all apps need Open Infrastructure".

He described how the Foundation has been iterating on a "pitch deck" and had completed twenty or so interviews with journalists where they presented this deck in a concerted effort to "change the narrative". This begins by talking about some recent industry trends, including a slowdown in the rate of public cloud growth and the coverage of Snap's significant spending on public cloud services compared to their revenues.

It goes on to compare "Gen 1" and "Gen 2" private clouds, with the challenges moving from technology and people to culture and processes. The advantage of a multi-cloud strategy, with sophisticated workload placement was discussed as well as some detailed information backing up the claim that companies are achieving cost savings with OpenStack.

Jonathan described how this presentation had been very well received, and had resulted in some very positive coverage.

Jonathan briefly touched on key improvements in Ocata and information about the profile of our contributors. This resulted in some debate about the value of "vanity metrics" and there was general agreement that while there continues to be demand for this information, we we should all be cautious in over-emphasizing it.

Finally, Jonathan reflected on feedback from the Project Team Gathering in Atlanta. Attendance was strong and attendees reported feeling less distractions and a greater ability to have important discussions because of the smaller venue and attendee count. While it was mostly seen as a great success, there are areas for improvement including the approach to choosing hotels and committing to hotel room bookings, how scheduling is organized, the size of some rooms, etc. Jonathan mentioned the success of the Forum and the OpenStack Summit in Boston will be key.

User Committee and Compensation Committee

The board spent a fairly short time discussing two matters from its committees.

Firstly, a proposal from the User Committee Product Working Group for facilitating the organization of the schedule for The Forum in Boston was well received, but since the board encouraged all interested parties to work with the Foundation staff who are coordinating the planning, particularly Tom Fifield and Thierry Carrez.

Secondly, the board approved Jonathan's goals for 2017, which had been prepared by the Compensation Committee and sent to board members earlier for review. The board only sets Jonathan's goals, and empower him to set the goals for the rest of the staff. Related to Jonathan's goals, the board also had some discussion later around documenting the goals of the board itself.

Membership Applications

Significant time during the day was given over to considering some corporate membership applications.

With HPE resigning its Platinum membership, we had invited applications to take over its slot and received applications from Ericsson and Huawei. Both companies had previously applied in November, 2014 at the OpenStack Summit in Paris to replace Nebula as Platinum member, but Intel had been successful that time.

Anni Lai presented for Huawei and Chris Price presented for Ericsson. Both described their employer's vision for OpenStack, and their wide range of contributions to date. Both also talked about their position in the market, their key customers, and how they are growing the OpenStack ecosystem. The presentations were well received and, after an executive session, the board voted to approve Huawei as a Platinum member. The board expressed their gratitude for Ericsson's interest and preparation, observing that having multiple companies interested in Platinum membership opportunities is a sign of the strength of our community.

Representatives from H3C also presented their application for Gold membership. H3C is a prominent IT vendor in China's enterprise IT market, distributes an OpenStack based cloud product, has several very large reference customers, and is establishing itself as a technical contributor to the project. After executive session, the board voted to approve H3C as a Gold member.

Wrapping Up

One piece of good news wasn't public during the meeting, but has since been announced by Jonathan:

The Board also approved the promotion of Thierry Carrez to VP of Engineering for the OpenStack Foundation. Thierry has been a leader in the technical community since the beginning of OpenStack and has also built a team within the Foundation focused on upstream collaboration.

I think it's safe to say the board were warmly supportive of this change, wished Thierry every success in this new role, and looked forward to working more closely with Thierry than ever before.

And, with that, the board dispersed feeling pretty fried after an intense couple of days of discussions!

March 8, 2017 OpenStack Foundation Strategic Planning Workshop

The OpenStack Foundation Board of Directors met in-person for two days in Boston last week.

The first day was a joint workshop with the Technical Committee, User Committee, and Foundation staff. The workshop was planned in response to the "OpenStack Futures" discussion at our three previous board conference calls in November, December, and January.

Introductions

We began the workshop with very brief personal introductions, followed by Alan, Thierry, and Edgar giving an overview of the roles and responsibilities of the Board of Directors, the Technical Committee, and the User Committee.

State of the Union

Next, Mark Collier presented his view of the state of OpenSack, with a particular emphasis on the four areas planned for discussion during the day. Mark began by talking about the exciting opportunity we had by having such breadth and depth of expertise in the room, and appealed to everyone to put aside their particular roles and work together as a single leadership team to talk about the work.

Evolving The Architecture

Mark spent some time trying to demystify the Big Tent change, describing how the previous Stackforge/Incubation/Integrated stages have been replaced by almost any project being welcome to use OpenStack infrastructure with the TC responsible for reviewing applications to join the set of official OpenStack projects known as "The Big Tent".

Mark then described one of the key changes happening in OpenStack right now as the containerization of the control plane, with projects like Kolla, openstack-helm, and TripleO all tackling this area. He also talked about the work happening around running containers on OpenStack itself with projects like Kuryr, Fuxi, Magnum, and Zun, but he also wondered aloud whether we're addressing all the right integration points. He also described some of the ongoing debates about the scope of OpenStack and our technology choices, with topics like the use of golang, the Gluon project, whether we welcome competition within the Big Tent, and community-wide goals.

Finally, Mark gave us a preview of the work happening around version 2 of the OpenStack Project Navigator and talked about how this will play a key role in helping people understand what OpenStack provides and how it can be used.

Unanswered Requirements

Mark talked briefly about the working groups under the User Committee and the transition from Design Summit to Project Team Gathering and Forum formats. These concepts are all important in understanding how OpenStack thinks about our requirements gathering, strategic long-term planning, and implementation planning.

Mark also gave a preview of some detractor quotes from our user survey, and emphasized a common theme - the perceived and actual complexity of OpenStack, both in terms of understanding and operating the software.

Adjacent Communities

Mark classified the various sets of adjacent communities that we are particularly interested in developing strong relationships with. Container technologies like Kubernetes, Docker, and Mesos. PaaS technologies like CloudFoundry and OpenShift. NFV projects like OPNFV and Cloudify. Provisioning technologies like Terraform, Puppet, and Saltstack. And specific ecosystem relationships, with companies like CoreOS.

Mark described the change in the Foundation's event strategy, targeting events like KubeCon, DockerCon, CoreOS Fest, etc. as key events where we should be positioning the OpenStack brand and developing relationships.

He also described particular focus areas of individual staff members which are relevant to the topic - Chris Hoge working with upstream Kubernetes and running OpenStack SIG meetings, David Flanders working on a report around the gaps when running platforms on OpenStack (like Cloud Foundry, OpenShift, Kubernetes, and Terraform), and how Ildiko Vancsa and Kathy Cacciatore are both working closely with OPNFV.

Finally, Mark talked about the Open Source Days event at the OpenStack Summit in Boston, as well as some very early stage discussions for an OpenDev event which would be a small, focused event around improving the integration between applications frameworks and open infrastructure.

Community Health

The final area of discussion was the subject of community health, and Mark first put out some statistics that he felt painted a very reassuring picture of the community's health. In 2016, we had 3,500 unique contributors, 1,850 of which were retained from 2015. In Ocata, we had fewer developers than Newton, most likely because it was a shorter cycle.

Mark contrasted challenges with projects like Trove and Designate losing contributors, while projects like Kuryr, Kolla, and Zun seeing the greatest number of new contributors.

Similarly, Mark talked about HPE laying off upstream developers, Cisco killing off intercloud, a small slowdown in Summit sponsorships, while we have also added 7 more Gold members, and many first-time corportate members and Summit sponsors.

Strategic Planning Exercise

The rest of the day was given over to a multi-stage strategic planning exercise prepared by Allison and Alan. The idea was to discuss these focus areas, gather everyone's ideas for improvement, summarize and categorize these ideas, vote on ideas in each focus area, and finally agree on how to proceed with concrete goals for the next 6-9 months.

Discussion

The initial discussion covered a lot of ground. Allison introduced each focus area by describing the input we gathered via the etherpads and input she gathered through 1:1 interviews with a variety of people.

One topic of discussion related to how OpenStack can simplify how we describe OpenStack, particularly to reduce confusion introduced with the Big Tent change. Various ideas around categorization, tagging, vertical definitions, a concept of constellations, maturity ratings, and much more, were discussed.

We talked about the promise for the future that OpenStack provides. That there will be evolution over time, that we deliver the cloud solutions of today and will deliver the solutions of tomorrow. That the challenge of smooth upgrades is part of our challenge in delivering "future proof infrastructure".

We talked about the challenges of scalability, manageability, and complexity. The theme of containerized deployments, the need for vertically focused views of OpenStack, for example for Telco users. We discussed the need for OpenStack to be able to evolve over time, with refactoring or rewriting components being only one of the possible approaches we may see over time.

We talked at great length about how OpenStack could work more closely with adjacent communities. How the relationship with these communities should bring value to both communities. We particularly emphasized the need for a closer relationship with the CNCF and the Kubernetes community.

Gathering Ideas

Over lunch, everyone wrote their concrete, actionable ideas for improvement on sticky notes and put them on flipcharts for each of the areas of discussion. Later, Jonathan volunteered to group the ideas into themes, and summarized these themes for the group, facilitating further discussion before voting on which theme in each area we should particularly focus on.

On the subject of communicating about "what is OpenStack", the main themese were marketing activities, various categorization ideas, and idea Allison talk about earlier referred to as "constellations". We later voted to focus on the categorization area and formed a group of interested parties:

Communicate about OpenStack: Categorize (objective data) and map (subjective approach) OpenStack projects as base versus optional (within a specific use case), integrated versus independent release, emerging versus mature, stability, adoption metrics, what works together, services versus consumption (operational tools/client libraries), and other criteria

Names: Thierry Carrez [lead], Alan Clark, Allison Randal, Jon Proulx, Melvin Hillsman, Lauren Sell, Tim Bell, Mark Baker, Kenji Kaneshige

For unanswered requirements, we discussed how to prioritize, ideas around a solution focus, scalability challenges, and a list of specific features that people felt were important. A counter-point was made that rather than focusing on any of these ideas, perhaps the focus should be on working with adjacent communities. Later, we discussed the need to grow the connection between the Product Working Group, the TC, and individual projects. The outcome and group for this was:

Requirements: Bring different groups (UC/technical/etc) together at Forum to collaborate/communicate aroud user stories, gap analysis, what fits in the current state of tech, prioritize what would have the greatest impact in reducing pain for users.

Names: Melvin Hillsman [lead], Yih Leong Sun, Jon Proulx, Rob Esker, Emilien Macchi, Doug Hellmann, Tim Bell, Shamail Tahir

On the topic of adjacent communities, we observed that by far the most dominant area of discussion was the need to create better connection with the Kubernetes community. The themes were community engagement, technical engagement, OpenStack consuming technology from the Kubernetes and containers world, and making OpenStack technology more consumable by Kubernetes. In the end, there was strong consensus to focus on the consumability of OpenStack technologies:

Adjacent Technologies: Make our technology more consumable (independently) by other communities/projects.

Names: Chris Price [lead], Alan Clark, Dims, Rob Esker, Mark Collier, Steven Dake, Mark McLoughlin, Shamail Tahir

For changes to the technology, we discussed simplifications, making containers first class citizens, recording tribal knowlede, culling failed efforts, converging deployment tools, and welcoming emerging or competing projects. The theme we voted to focus on was:

Changes to the Technology: Workstream to simplify existing projects, reduce dependency options, reduce config options.

Names: Mike Perez [lead], --> TC project

Finally, on the subject of community health, we talked about onboarding contributors, reworking our processes, community tools, growing leaders, corporate involvement in the project, and recognizing work with adjacent communities. We voted to focus on the leadership theme:

Community Health: Grow next generation of leadership/experts/cross-project devs within the community

Names: Steven Dake [lead], Chris Price, Jeremy Stanley, Dims, AlanClark, Joseph Wang

Next Steps

For each of these focus areas, the lead person in the group committed to organizing a kick-off meeting by March 22nd. The real work will begin there!