可重现开发者环境是一波浪潮，而非特定产品功能
可重现的开发者环境长期不受重视，直到最近才开始逐渐普及。也许再过几年，这类环境将成为开发流程中的标配。但我觉得整个行业正走向跟 Gitpod（即. workspace-images 和 .gitpod.yml）不同的方向。
workspace-images 的问题在于，除非 Gitpod 员工能在每一个 Docker 镜像中单独更新，否则客户根本得不到安全修复。
至于.gitpod.yml，它的问题是规定了一种特定的开发者环境重现方式，这种方式会造成供应商锁定，而与之竞争的 devcontainer.json 开放标准则是微软 VSCode 和 GitHubVisual Studio Codespaces 中的默认选项。
如果问我从业这 40 年来总结出的核心经验是什么，那就是无论微软把什么东西当成默认选项发布，最终都能赢得市场。
**但无论是 Gitpod 还是微软，我觉得他们都忽略了行业正在超越 Docker、转向 Nix（或 Guix）等新兴工具的整体趋势。**这些工具不仅能提供可重现的开发者环境，同时也包含更加灵活自主的软件供应链工具（可通过源代码 / 二进制文件替换）和软件物料清单。
Nix 唯一的缺点就是让人们迅速与现实脱节。如果各位已经忘了依赖项版本维护起来有多痛苦，请马上使用 Nix。
— Mitchell Hashimoto (@mitchellh) 2022 年 2 月 8 日
我可以大方承认，我自己就是 Nix 的铁粉。四年之前，这款由学术界酝酿出的构建工具占据了我的心，并迅速发展为市场主流。通过 Cachix 和 nix 这类工具，用户能够以独立于供应商之外的姿态获得与 Gitpod 相同的预构建 + 可重现环境功能集。
这当然很好，只不过面对糟糕的经济环境，大家的心态都变得更加保守持重，所以我觉得没有哪款产品（包括 nix）能够在短时间内成为可重现开发环境的客观标准。
所以，谁能更好地融入企业的现有工作方式，最大限度减少相应的人员 / 流程变更，谁就能降低产品普及的成本风险，从而真正在市场上获得认可。
也正因为如此，我很难相信人们会愿意在自己的每个 git repo 中添加 .gitpod.yml。在 Gitpod 工作时，我也多次在内部讨论中提到过这个问题，毕竟开源维护者一直强烈反对“再加个 yml”的作法。
