Build on Standards, Not Products: Lessons from the Terraform Fork

The Terraform Wake-Up Call

In August 2023, HashiCorp changed Terraform's license from Mozilla Public License 2.0 (MPL) to Business Source License 1.1 (BSL). For many organisations—including ours—this was clarifying. We'd invested heavily in Terraform. It felt like a standard. But it was a product controlled by a single company, and products can change direction.

The BSL isn't open source—it's source-available with restrictions. Organisations providing services competitive with HashiCorp could no longer use Terraform freely. The license change was retroactive to all future releases.

The Community Response

August 15, 2023: The OpenTF Manifesto was released, asking HashiCorp to reverse the license change. Over 100 companies, 10 projects, and 400 individuals pledged support.

August 25, 2023: OpenTF announced an open source fork of Terraform.

September 20, 2023: The Linux Foundation accepted the project as OpenTofu.

Within weeks of the license change, the community had forked the project and established it under foundation governance. This speed demonstrates the value the community placed on truly open licensing.

Our Migration to OpenTofu

We migrated to OpenTofu immediately. The transition was straightforward—OpenTofu maintains API compatibility with Terraform. Our configuration files worked unchanged:

terraform {
  required_providers {
    scaleway = {
      source  = "scaleway/scaleway"
      version = "~> 2.0"
    }
  }
}

Simply changing the binary from terraform to tofu was sufficient. State files migrated cleanly. Provider plugins worked identically.

The lesson: There's a difference between "widely adopted" and "truly open." Terraform was the former; Kubernetes is the latter. For foundational infrastructure, this distinction matters.

What Makes Kubernetes Different

Kubernetes is governed by the Cloud Native Computing Foundation, itself part of the Linux Foundation. This provides structural independence from any single vendor.

Key differences:

Governance: CNCF Technical Oversight Committee makes decisions. Members represent diverse organisations—Google, Red Hat, Microsoft, Huawei, independent contributors. No single company controls direction.

License: Apache 2.0—a true open source license with no restrictions on use, modification, or commercial deployment.

Multiple implementations: Kubernetes isn't one product. It's a specification with implementations from Google, Amazon, Microsoft, Red Hat, Rancher, and dozens more. If one implementation becomes problematic, alternatives exist.

Contribution model: Over 88,000 contributors from 8,000+ companies. The project isn't dependent on any single organization's continued participation.

Cannot be relicensed: Apache 2.0 contributions cannot be relicensed without contributor consent. The project cannot be "BSL-ed" by a corporate owner.

This is what genuine openness looks like: distributed governance, true open source license, multiple implementations, broad participation.

Why Kubernetes Enables Independence

Kubernetes provides a consistent API across every major cloud provider and on-premises environment. When you deploy a workload on Kubernetes, you're writing to a standard governed by the CNCF, not a single vendor.

This matters practically. We run production on Scaleway Kapsule. Our development environment uses Kind (Kubernetes in Docker). The same manifests work in both places. If we needed to move to OVHcloud, Hetzner Cloud, or even AWS EKS, our application definitions wouldn't change.

What to watch for: Provider-specific features create hidden dependencies. Every custom annotation, every proprietary storage class, every cloud-specific load balancer integration is something you'll need to address during migration.

Example of portable Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    spec:
      containers:
      - name: app
        image: myapp:v1
        ports:
        - containerPort: 8080

This manifest works identically on every Kubernetes implementation. That's portability through standards.

Example of non-portable Kubernetes:

apiVersion: v1
kind: Service
metadata:
  name: app
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
spec:
  type: LoadBalancer

These AWS-specific annotations break portability. When you move to another provider, you'll need to rewrite this configuration.

Stick to vanilla Kubernetes APIs where possible. Provider-specific features should be explicitly chosen tradeoffs, not accidental dependencies.

A Checklist for Evaluating Technology Choices

Before adopting any technology for your infrastructure, ask:

1. Who controls it?

Foundation governance (CNCF, Linux Foundation, Apache) ✓
Multi-company consortium (debatable, depends on structure)
Single company (product, not standard) ✗

2. What license?

Apache 2.0, MIT, MPL 2.0 (truly open) ✓
BSL, SSPL, proprietary (restricted use) ✗

3. How many implementations?

Multiple independent implementations (real standard) ✓
Single implementation (single point of control) ✗

4. Can it be relicensed?

Foundation-owned, irrevocable license ✓
Company-owned, license can change (risk) ✗

5. What's the exit path?

Clear migration path to alternatives ✓
Locked in, migration extremely costly ✗

For foundational infrastructure—the stuff that's expensive to change—prefer technologies that score well on all five criteria. For higher-level tooling, commercial products can be acceptable if you understand the tradeoffs.

Beyond Kubernetes

Other examples of truly open standards:

PostgreSQL: Open source database with PostgreSQL Global Development Group governance. Implementations include AWS RDS, Azure Database, Google Cloud SQL, self-hosted. License: PostgreSQL License (BSD-like).

Prometheus: CNCF-graduated monitoring project. Implementations include self-hosted, Grafana Cloud, AWS Managed Prometheus. License: Apache 2.0.

Envoy Proxy: CNCF-graduated proxy. Implementations include standalone, Istio, AWS App Mesh, Envoy Gateway. License: Apache 2.0.

These are genuine standards: foundation governance, truly open licenses, multiple implementations.

The Pattern

Build your infrastructure on standards, not products. Products can change direction, relicense, or disappear. Standards—especially those governed by foundations with diverse participation—provide stability.

This doesn't mean never use commercial products. It means: understand what's a standard and what's a product, and choose deliberately.

For the core infrastructure that everything depends on, standards provide the independence that makes everything else possible.

Sources:

#opentofu #kubernetes #standards #opensource #portability