Thierry Carrez, VP of engineering at the OpenStack Foundation & OpenStack Technical Committee member, outlines the past, present and future.


Last year, at the OpenStack Summit in Sydney, the OpenStack Foundation (OSF) unveiled a new strategy. Realizing the variety of open infrastructure use cases and recognizing that integration is the largest barrier to its further adoption, we shifted our focus from being solely about the production of the OpenStack software, to more broadly helping organizations embrace open infrastructure: using and combining open source solutions to fill their needs in terms of IT infrastructure. This strategy involves finding common use cases, collaborating across communities, supporting the creation of missing technology pieces and testing everything end to end.

Since open infrastructure use cases are pretty broad, we defined four strategic focus areas that the OSF should help with: Datacenter cloud, which is the traditional OpenStack use case, container infrastructure, edge computing and CI/CD. Beyond OpenStack (which helps directly or indirectly with all those areas), we supported the emergence of new open collaborations around missing technology pieces helping in those strategic focus areas.

In December 2017, we launched Kata Containers, our first pilot project. In May 2018, we established Zuul, the engine behind our project infrastructure CI systems, as a standalone project. More recently, we started piloting two additional projects: Airship and StarlingX. All those pilot projects were set up with their own independent branding and separate technical governance.

These four pilot projects allowed us to learn a lot and over the past five months we have worked with the OSF Board and the community to put more structure around the future of our work with additional open infrastructure projects. The proposed structure was presented and refined at Board meetings, community meetings, on mailing lists and at in-person events over the past months.  It was finally approved during the Board meeting held at the OpenStack Summit in Berlin.

The Four Opens

The Four Opens were created in 2010, as the base principles to sustain the creation and growth of the OpenStack project. We believe that in order to create a successful piece of infrastructure technology, open source is not enough: you need open collaboration across all stakeholders on a level playing field to reach the levels of contribution and adoption necessary to success.

The Four Opens are:

  • Open source: Everything is licensed under an OSI-compliant license, we do not support the open core model
  • Open design: Design does not happen behind closed doors between a selected few and involves users directly
  • Open development: Everything happening in development is transparent and accessible
  • Open community: Anyone can join and be elected to project leadership positions, no appointed seats

Over the past eight years, the Four Opens have proved a great model to enable this open collaboration mindset and their application has expanded well beyond the realm of software development.  They’re now the OSF way: An integral part of how we do things at the Foundation and within the open source projects that we support. In order to better document the OSF way, we’ve recently started an effort to write a community book on the Four Opens. More on that in this post by Chris Hoge.

Strategic focus areas (SFA)

Open infrastructure is an ever-evolving construct, changing as the computing needs of organizations evolve with the technology. As mentioned above, SFAs are driven by usage scenarios and help direct the OSF action to specific segments of the open infrastructure market.

As such, defining SFAs will be part of the regular strategic planning activities of the OSF Board of Directors. Focus areas may be proposed, discussed, approved or abandoned during strategic reviews. Those strategic reviews should happen as-needed, but at least annually.


To build open infrastructure solutions, we look forward to integrating existing open source projects produced by adjacent open source communities. However some gaps may persist and extra technology pieces may be necessary to fill the goals of our strategic focus areas. The OSF enables those projects to be successfully set up as open collaborations, by providing IP management, a set of base collaboration rules (the Four Opens) and upstream and downstream community support services. Projects are not tied to a specific SFA: they should ideally help with multiple SFAs. The idea here is not to bring on dozens of projects, but to curate a set of strong projects that help solve real-world problems for our users.

All projects supported by the OSF follow the Four Opens. Open source projects that do not wish to be set up as open collaborations can still be included and integrated in open infrastructure solutions. However, they’ll see little benefit in being hosted by the OSF. Projects may be composed of several components or deliverables, as long as they are under a common defined scope and governance.

Projects go through two stages, which define the level of engagement of OSF resources:

Pilot projects

As part of meeting the goals of our strategic focus areas, the OSF staff will encourage the formation of new openly developed projects. It will also evaluate and engage with existing projects that fill gaps in open infrastructure adoption and could be interested in being set up as an open collaboration following the Four Opens.

The OSF staff (as represented by its officers) can create or select pilot projects where it identifies such promising new technology pieces and a potential for open collaboration. It then helps the pilot projects by establishing initial branding, setting up project websites, guiding them to set up proper governance, and understanding and adopting the Four Opens.

Confirmed projects

This initial bootstrapping phase is completed once the project operates under an open community governance and has produced at least one release under that model. At that point, pilot projects shall be reviewed by the Board, in order to decide on further investment of OSF resources to support it over the long-term.

With the input of other OSF leadership bodies, the Board will review the strategic alignment of the project with the Foundation’s SFAs, but also their progress in setting up an effective open collaboration following the Four Opens. It may then decide to confirm the project as a long-term OSF investment, abandon the pilot or defer its decision.

Practical implications

The first practical implication of this OSF project governance structure is the need to adapt the OSF bylaws. In order to allow the OSF to support open infrastructure projects beyond just OpenStack, the Foundation bylaws needed a number of additions. Those changes were approved by the Board during the meeting held at the OpenStack Summit in Berlin and will appear in the ballot for individual members to vote on during the January Foundation election cycle. You can read this post by Jonathan Bryce to learn more about it.

Another practical implication is around our project infrastructure: the massive, openly operated set of open-source services that our community infrastructure team runs to support the development of our software. While it always supported more than just OpenStack, it was always called the “OpenStack project infrastructure” and used the OpenStack name throughout. In order to more easily reuse it for other projects and promote its open development model beyond OpenStack in the future, a rebranding was in order. The current plan is to call it OpenDev and over the coming year to gradually move it to the domain. You can read this post by Clark Boylan to learn more.

There will be a lot of other changes over the coming year as we put this model into place. If you have questions or comments, please feel free to reach out on the Foundation mailing-list, or in person at events.

If you’re at the OpenStack Summit in Berlin, the Foundation leadership team will hold a Ask Me Anything session at 3:20 p.m. on Wednesday. Join us!

Thierry Carrez
Latest posts by Thierry Carrez (see all)