This article is based on reporting originally published by TechCrunch on October 9, 2018, covering the Spinnaker Community Summit in Seattle.
What Is Spinnaker?
Spinnaker is an open source continuous delivery (CD) platform originally developed by Netflix and Google. It is designed to help engineering teams reliably release software changes at high velocity across multiple cloud environments. Unlike narrowly scoped deployment tools, Spinnaker is built to target a wide range of deployment destinations — not just Kubernetes clusters, but also virtual machine-based infrastructure and multiple public clouds.
Spinnaker 1.0 launched in July 2017. By late 2018, notable enterprise adopters included Target, Adobe, Daimler, and Capital One, signalling that the platform had moved well beyond its Netflix origins into mainstream enterprise DevOps practice.
Why Spinnaker Matters in the CD Landscape
The continuous delivery tooling space has many established players — Jenkins, GitLab CI/CD, CircleCI, and others — so Spinnaker’s path to dominance is not guaranteed. However, the platform has a meaningful differentiator: it is multi-cloud by design. Where many CD tools are optimized for a single target environment, Spinnaker was architected from the start to deploy to AWS, Google Cloud, Microsoft Azure, and other providers, as well as to Kubernetes clusters and traditional VM infrastructure.
Observers have drawn comparisons to Kubernetes, which became the de facto standard for container orchestration. The argument is that Spinnaker could fill an analogous role for CD pipelines — a common, vendor-neutral substrate that enterprises can standardize on regardless of their cloud footprint.
Formal Governance: A Critical Milestone
Before October 2018, Spinnaker operated essentially as a GitHub project with informal leadership — what is sometimes called a “benevolent dictator” model. Netflix and Google engineers drove nearly all major decisions. While this worked during the project’s early growth phase, the model created uncertainty for enterprises considering long-term investment in the platform.
At the second Spinnaker Community Summit in Seattle, the project announced a formal governance structure, including:
- A Technical Steering Committee to oversee engineering direction and architectural decisions.
- A Steering Committee for broader project governance.
- Documented processes for how external developers can contribute code and gain influence in the project.
Initially, both committees were staffed with Netflix and Google engineers, with a stated plan to open membership to third-party contributors over time.
Andy Glover, Netflix’s Director of Delivery Engineering and the key figure behind Spinnaker’s development, described the shift candidly: “At Netflix, we tend to do a lot of experimentation without worrying too much up front. Let’s just run fast and see what happens. And with respect to Spinnaker, that was very much run the same way. We said we’d cross that bridge when we get to it and obviously, we got to that bridge a little while ago.”
Glover also framed the governance move as a direct response to enterprise concerns: “How do we reduce risk, how do we guard ourselves from Netflix closed-sourcing it or Google deciding to license it or something like that?” Formal governance answers those questions by separating the project’s future from the interests of any single corporate sponsor.
The Question of a Foundation Home
One open question in the Spinnaker community at the time was whether the project would eventually join a major open source foundation such as the Linux Foundation, the Apache Software Foundation, or the OpenStack Foundation. The governance announcement was described as laying the groundwork for such a move, though no foundation affiliation was announced at the summit.
Boris Renski, founder of Mirantis — a company that had made a significant commercial bet on Spinnaker — expressed a preference for the OpenStack Foundation. He also acknowledged that governance was only a first step, and that the project still needed to become more welcoming to the broader community.
Key Technical and Community Challenges
Renski identified several challenges the Spinnaker project needed to address to reach its potential:
1. Kubernetes Overlap
Kubernetes was rapidly building its own CD-adjacent tooling ecosystem. Renski argued that Kubernetes risked an “OpenStack syndrome” — expanding scope into so many adjacent problem spaces that it crowds out more specialized, purpose-built tools. He believed Spinnaker should be Kubernetes-friendly but retain its multi-target flexibility so that enterprises deploying to non-Kubernetes environments are not left behind.
2. Tactical vs. Strategic Contributors
Much of the Spinnaker community in 2018 consisted of users solving immediate, short-term deployment problems. Renski noted that these users typically lacked the time and resources to invest in longer-term community infrastructure work — documentation, plugin systems, integration frameworks — that would make the project sustainable at scale.
3. Extensibility and Pluggability
A recurring theme was the need for better “pluggability” — the ability for third-party vendors and teams to extend Spinnaker and integrate it with external systems without forking the core codebase. This is a prerequisite for building a healthy vendor ecosystem around the project.
Cloud Provider and Vendor Support
By October 2018, Spinnaker had secured backing from the three major public cloud providers — Google Cloud, Microsoft Azure, and AWS — and ran natively on all three. Pivotal also announced increased support around the same time, and a growing number of vendors in the CI/CD ecosystem were building Spinnaker integrations.
The community summit itself attracted approximately 400 participants from 16 countries and 275 companies, according to organizer Pete Erickson. Notably, around 30 percent of attendees were described as new to Spinnaker, attending primarily to evaluate whether it was the right fit for their organizations.
What to Watch
For DevOps engineers evaluating CD platforms, Spinnaker’s trajectory in 2018 offered a useful case study in how open source projects mature. The move from informal GitHub-driven development to structured governance is a well-understood inflection point — it signals that a project intends to compete seriously for enterprise adoption rather than remain an internal tool that happens to be public.
The key indicators to monitor for any CD platform at this stage include:
- Whether governance structures deliver on the promise of third-party representation.
- Growth in the plugin and integration ecosystem.
- Whether the project lands at a neutral foundation, which typically accelerates enterprise trust.
- The balance between Kubernetes-native features and support for heterogeneous deployment targets.
Spinnaker’s multi-cloud, multi-target design remains its strongest differentiator in a CD market that has no shortage of capable tools.