开源并非免费。它只是自由的。
当有人试图剥夺这种自由时，社区会以分叉（fork）回应。
🎯 本文涵盖内容
- Terraform如何成为IaC（Infrastructure as Code）的标准
- HashiCorp改变许可证的原因和社区的反应
- OpenTofu诞生的背景以及加入CNCF的原因
- OpenTofu与Terraform，现在有哪些区别
- OpenTofu的未来以及我们应该做出何种选择
📌 引言 — “我们信任的工具突然变了”
将基础设施作为代码管理的概念，即IaC（Infrastructure as Code）。在这个领域，长期以来事实上的标准工具就是Terraform。
无论是AWS、Azure还是GCP，只需几行.tf文件就能轻松创建云基础设施的Terraform。这个被数百万工程师日常使用的工具，在2023年8月突然改变了许可证。
反应是即时的。社区感到愤怒，企业感到困惑，最终，一个名为OpenTofu的新项目诞生了。短短几个月内，它就成为了CNCF（Cloud Native Computing Foundation）的官方项目。
本文将从头到尾梳理整个事件。从Terraform的历史，到OpenTofu为何必须诞生，以及未来将如何发展。
🔍 Terraform的历史 — 如何登上IaC的宝座
诞生 (2014年)
Terraform是HashiCorp于2014年创建的开源IaC工具。HashiCorp以Vagrant、Consul、Vault、Nomad等基础设施相关工具而闻名。
当时的问题是这样的：随着云计算的爆炸式增长，通过控制台（GUI）点击创建基础设施资源的方式遇到了瓶颈。手动管理数百台服务器、几十个网络设置？这不可能。错误多，无法重现，协作也困难。
Terraform的解决方案既简单又强大。
# main.tf — 声明一个AWS EC2实例的示例
provider "aws" {
region = "ap-northeast-2" # 首尔区域
}
resource "aws_instance" "web" {
ami = "ami-0c9c942bd7bf113a2"
instance_type = "t3.micro"
tags = {
Name = "my-web-server"
}
}只需这一个文件，一个`terraform apply`就能创建一个EC2实例。`terraform destroy`则能干净地删除它。因为是代码，所以可以用Git进行版本控制，也可以与团队成员共享。
成长 (2015~2020年)
Terraform的核心设计理念是声明式（Declarative）方法。它不是说“请这样创建”，而是“最终状态是这样的”，然后Terraform会与当前状态进行比较，自动执行所需的操作。
此外，Provider生态系统也爆炸式增长。从AWS、Azure、GCP到GitHub、Datadog、Cloudflare、Kubernetes——数千个Provider被上传到Registry。实际上，“云世界的一切”都可以通过Terraform进行管理。
# 同时管理多个云的示例
provider "aws" {
region = "ap-northeast-2"
}
provider "azurerm" {
features {}
subscription_id = var.azure_subscription_id
}
# AWS上的S3存储桶
resource "aws_s3_bucket" "backup" {
bucket = "my-backup-bucket-2024"
}
# Azure上的存储账户
resource "azurerm_storage_account" "backup" {
name = "mybackupstorage2024"
resource_group_name = var.resource_group
location = "koreacentral"
account_tier = "Standard"
account_replication_type = "LRS"
}对于采用多云战略的企业来说，Terraform不再是选择，而是必需品。
鼎盛时期 (2020~2023年)
2021年，HashiCorp在纳斯达克上市。企业价值数十亿美元。Terraform成为了DevOps/云工程师必须掌握的工具，相关的认证（HashiCorp Certified: Terraform Associate）也应运而生。
然而，成为上市公司也意味着要向股东和投资者而非社区负责。2023年，这种裂痕显现出来。
💥 许可证变更 — 那一天的冲击
2023年8月10日
HashiCorp宣布将其主要产品（包括Terraform）的许可证从原有的MPL 2.0（Mozilla Public License 2.0）更改为BSL 1.1（Business Source License 1.1）。
这为什么是个问题呢？我们来比较一下差异。
| 项目 | MPL 2.0 (原有) | BSL 1.1 (变更后) |
| 个人使用 | ✅ 自由 | ✅ 自由 |
| 企业内部使用 | ✅ 自由 | ✅ 自由 |
| 开源项目 | ✅ 自由 | ✅ 自由 |
| 构建与HashiCorp竞争的产品/服务 | ✅ 可能 | ❌ 不可能 |
| OSI官方开源认证 | ✅ 已认证 | ❌ 未认证 |
核心只有一点：“HashiCorp的竞争对手不能利用Terraform构建商业服务。”
HashiCorp的逻辑是这样的：“一些企业利用我们的开源赚钱却不贡献。我们也需要可持续的业务。”这话并非全无道理。
但社区的反应却不同。
我们10年来贡献并发展生态系统，正是因为它是开源的。
现在突然改变规则，这不是背叛吗？
Spacelift、Env0、Scalr等基于Terraform构建服务的企业受到了直接冲击。因为它们与HashiCorp的Terraform Cloud存在竞争关系。
🍀 OpenTofu的诞生 — 社区的分叉（Fork）
OpenTF宣言 (2023年8月)
许可证变更宣布后，社区迅速行动。数十家企业和数千名开发者签署了OpenTF宣言。要点很简单。
- 请求HashiCorp恢复到MPL 2.0
- 如果HashiCorp不恢复，我们将直接创建一个真正的开源Terraform分叉
参与签署的企业包括Gruntwork、Spacelift、Env0、Terragrunt的开发商等重量级公司。HashiCorp没有回应。
OpenTofu诞生 (2023年9月)
于是，OpenTofu诞生了。它是基于Terraform最后一个MPL 2.0版本（1.5.x）的官方分叉。
名字的由来很有趣。🍀 采用三叶草表情符号作为吉祥物，以及Tofu（豆腐）。豆腐可以搭配任何菜肴，可以自由改变形状，就像开源一样，任何人都可以制作。这是一个巧妙地通过食物表达开源哲学的命名。
OpenTofu 초기 참여 기업/프로젝트:
- Gruntwork (Terragrunt 개발사)
- Spacelift
- Env0
- Scalr
- Digger
- Terramate
- ... 수십 개 기업加入CNCF (2023年9月)
OpenTofu以惊人的速度加入了CNCF（Cloud Native Computing Foundation）Sandbox项目。这距离宣布仅几周时间。
☁️ 什么是CNCF，OpenTofu为何加入它？
CNCF介绍
CNCF是Linux基金会旗下的一个非营利组织。它囊括了Kubernetes、Prometheus、Envoy、Argo CD、Helm等云原生生态系统的核心项目。简而言之，它是“云原生世界的官方之家”。
成为CNCF项目意味着：
- 🔒 中立性保障: 独立于特定企业的利益
- 💰 财政支持: 基础设施、市场营销、法律支持
- 🏛️ 治理: 透明的决策结构
- 🌍 社区: 全球贡献者网络
OpenTofu选择CNCF的原因
OpenTofu最大的风险是成为“另一个HashiCorp”。因为最初以开源开始，后来因商业利益而改变许可证的情况可能会重演。
加入CNCF从结构上杜绝了这种风险。
- 任何单一企业都不能“拥有”OpenTofu
- 未经整个社区的共识，许可证变更是不可能的
- MPL 2.0许可证将永久保留
就像Kubernetes从Google移交给CNCF一样，OpenTofu也走上了同样的道路。
🔄 OpenTofu vs Terraform — 现在有哪些区别？
最初，它们几乎完全相同。Terraform代码可以直接在OpenTofu中使用。但随着时间的推移，差异正在产生。
当前（2024~2025年）主要区别
功能 Terraform OpenTofu
| 许可证 | BSL 1.1 (非开源) | MPL 2.0 (开源) |
| 状态加密 | ❌ 不支持 | ✅ 原生支持 |
| Provider函数 | 受限 | 扩展支持 |
| 开发透明度 | HashiCorp主导 | 社区主导 |
| GitHub Stars增长趋势 | 放缓 | 急剧上升 |
特别是状态文件加密是OpenTofu的杀手级功能。Terraform的状态文件经常以明文形式存储敏感信息（密码、API密钥等），存在安全隐患，而OpenTofu原生支持此功能。
# OpenTofu — 状态加密配置示例
terraform {
# 在OpenTofu中，'terraform'块保持不变
encryption {
key_provider "pbkdf2" "my_passphrase" {
passphrase = var.state_passphrase
}
method "aes_gcm" "my_method" {
keys = key_provider.pbkdf2.my_passphrase
}
state {
method = method.aes_gcm.my_method
}
}
}迁移有多容易？
对于现有的Terraform用户，在大多数情况下，只需这样做：
# macOS (Homebrew)
brew install opentofu
# 将现有Terraform命令替换为tofu
terraform init → tofu init
terraform plan → tofu plan
terraform apply → tofu apply
terraform destroy → tofu destroy
# .tf文件无需修改即可使用（大多数情况下）.tf文件内部的代码几乎不需要修改。因为HCL语法本身是相同的。
⚠️ 注意事项 — OpenTofu引入清单
1. 检查Provider兼容性 大多数Provider是兼容的，但某些企业专用Provider可能仅针对HashiCorp Terraform进行了优化。引入前务必确认。
2. 如果您正在使用Terraform Cloud/Enterprise 与HashiCorp的托管服务（Terraform Cloud、Terraform Enterprise）的集成当然是Terraform专用的。切换到OpenTofu时，应考虑Spacelift、Env0、Scalr、Atlantis等替代方案。
3. 状态文件管理 现有的Terraform状态文件可以被OpenTofu直接读取。但是，如果启用OpenTofu的状态加密功能，可能难以再回到Terraform。
4. 团队内版本统一 在团队内部混用Terraform和OpenTofu可能会导致混乱。建议在切换时，整个团队同时进行切换。
🔭 OpenTofu的未来 — 乐观的理由
IBM收购HashiCorp (2024年)
2024年，IBM以约64亿美元收购了HashiCorp。这一消息反而对OpenTofu社区起到了积极作用。我们已经无数次看到，大型企业收购后开源政策变得更加受限的案例。这成为了那些考虑转向OpenTofu的企业下定决心的契机。
快速增长势头
- GitHub Star数量：突破数万（快速增长中）
- 贡献者数量：数百名全球开发者
- 企业赞助：数十家主要科技公司
- 晋升为CNCF孵化阶段
社区驱动的优势
OpenTofu正在迅速添加Terraform尚未解决的功能。这些是社区多年来一直要求但HashiCorp未优先处理的功能。状态加密就是其中一个典型例子。
仍然需要使用Terraform的情况
尽管OpenTofu非常出色，但仍有一些情况需要选择Terraform。
- 如果需要HashiCorp的官方企业支持
- 如果正在使用与Terraform Cloud深度集成的S工作流
- 如果组织规定需要CNCF项目之外的特定供应商官方支持
✅ 总结 — 开源的自由由分叉守护
| 时间点 | 事件 |
| 2014年 | HashiCorp以MPL 2.0发布Terraform开源版本 |
| 2021年 | HashiCorp在纳斯达克上市 |
| 2023年8月 | Terraform宣布将许可证更改为BSL 1.1 |
| 2023年8月 | OpenTF宣言发布，数千人签署 |
| 2023年9月 | OpenTofu正式启动，加入CNCF Sandbox |
| 2024年 | IBM完成对HashiCorp的收购 |
| 2024~2025年 | OpenTofu晋升为CNCF孵化项目并添加独有功能 |
Terraform无疑是一个伟大的工具，现在依然如此。但OpenTofu再次证明，开源的力量不在于特定企业，而在于社区。
推荐的下一步学习方向：
- OpenTofu官方文档: opentofu.org
- 理解CNCF项目生态系统
- 基于OpenTofu的工作流工具，如Terragrunt、Atlantis
- 状态加密实践
如果您是IaC的初学者，现在建议从OpenTofu开始。📦
发表回复