满心欢喜入职 Gitpod 一年后失望离开：垃圾邮件当 OKR、天天造势但就不兑现承诺

作者 | Geoffrey Huntley

译者| 核子可乐

策划 | 褚杏娟

去年，选择了房车露营生活的 Geoffrey Huntley 受邀请加入了 Gitpod，远程办公、充满才华横溢的人、开源等因素都让他选择加入 Gitpod。Gitpod 是一个开源的开发者平台，可以自动配置现成代码的开发者环境。Gitpod 公司则是在 2020 年成立，目前重点放在了云上的自动化开发环境。

当时的 Huntley 在文章中称赞道：过去几年，Gitpod 一直是我工具包中一个有意义且关键的软件，因为 Gitpod 让我能够在任何地方在任何设备上进行开发。“我可以连续几个小时谈论 Gitpod 所做的工作多么有意义，以及它如何让开源维护者更容易为自己的项目吸引新的贡献者。”

不过在 Gitpod 任职一年多后，Huntley 便选择了离职，并写了博文来讲述自己离开的原因。他表示自己离开的原因很复杂，但促使其下定决心的是那封“让人恶心”的内部邮件，“它打碎了我的归属感，让我迫不及待想要逃离……”

我们对 Huntley 叙述的内容进行了整理，也希望借此机会一窥 Gitpod 现在面临的内外部挑战。

Gitpod 内部问题

两年过去，管理面板仍直接向网络开放

在刚刚加入公司的时候，我不安地发现 https://gitpod.io/admin 就那么直接地向网络开放，并在内部员工间传来传去。而差不多两年过去，全体员工仍然可以通过个人 GitHub 账户下载客户的源代码和环境变量。

“可真「刑」：Gitpod 可以直接下载用户工作区的数据压缩包”

早在 2021 年 3 月，曾经发生过一起安全事件。当时公司在生产环境中部署了管理面板访问通道，而且默认完全开放、不经任何身份验证，也从未对客户发出过提醒。事件之后，Gitpod 已经筹集到 3600 万美元风险投资，所以至少该请位安全工程师了吧……但是并没有。

客户们怨声载道

Gitpod 嘴上把服务客户喊得山响，但实际行动却始终跟不上。

别用 @gitpod——他们礼拜五宕机，导致我三天做不了开发，还有一整天的代码彻底丢失。他们的客户支持啥帮也忙不上，连帮我查找邮件地址都做不到……

— Ryan George (@RyanGGeorge) 2022 年 9 月 19 日

当产品质量和服务可用性的大问题得不到解决时，拼命吸引客户有意义吗？没有，只会招来更多骂声。

天天为 DevX 造势，但迟迟无法兑现

Gitpod 把大量精力花在了宣传“开发者体验至上”的理念上。但纵观整个工作经历，我发现公司连内部开发员工的体验都不关心。

根据最新统计，Gitpod 有 11 名员工全职从事软件开发。大家顶着 300 毫秒的延迟用亚太及日本（JAPAC）的 Gitpod 服务操作欧洲或北美的集群。于是问题来了：

“当这帮员工每天受到糟糕开发体验的折磨，同时看到公司随时强调 DevX 开发体验的重要性时，内心会作何感想？”

已关闭、未解决的问题包括：

Gitpod 新加坡区，问题 #5534：https://github.com/gitpod-io/gitpod/issues/5534

Gitpod 孟买区，问题 #6139：https://github.com/gitpod-io/gitpod/issues/6139

亚太数据中心，问题 #4526：https://github.com/gitpod-io/gitpod/issues/4526

用垃圾邮件当 OKR 推动增长策略

这里先向大家“科普”一个新词儿，Gitpod 化。所谓 Gitpod 化，就是往流行的开源 repo 中发送垃圾邮件，把相应的 PR 设计成广告展示。

公司甚至专门定了 OKR，要求员工宣传 Gitpod 的优点。因为种种行为太过火，很多项目的维护者甚至在自述文件里专门强调，不会接收 / 合并.gitpod.yml 和“在 Gitpod 中打开”选项。

有开发者在推特上讽刺道：笑死 http://github.com/gitpod-for-os 看起来还是在人工发小广告，“有幸”成为第一个收到小广告的人。

情况已经显而易见。我曾多次向领导层建言，提醒他们在开源项目里发垃圾邮件的营销策略实在是败人缘。但结果嘛……“问题已关闭，未解决”。

垃圾领导

如果大家身为新晋领导，看着身边的老员工一个个离开，你会怎么想？反正咱们这位老大想得很开：都是别人的错。

你们这些资深老员工离职的时候，真的应该好好做一番自我反省。

— Mike Nikles (@mikenikles) 2022 年 8 月 24 日

说了半天都是白说，谁离职谁错就完事了……

面临的外部挑战

微软正在战略性驱逐 Gitpod

自由竞争的破坏者微软又出手了，这次的战场是在 Visual Studio Code 生态系统之内。面向全体 VSCode 用户，微软先后推出了 GitHub Codespaces 和 Visual Studio Codespaces 两款与 Gitpod 高度重合的服务。更要命的是，人家的产品没有讨厌的弹窗广告。

其实微软的作法也不能说有多过分，毕竟从事语言工具开发的工程师身份不菲。根据粗略计算，Gitpod 每年至少要再额外砸下 900 万美元的薪酬成本才能跟 GitHub Visual Studio Codespaces 正面竞争。另外有博文披露，后续 Gitpod 将不能合法使用微软维护的 VSCode 语言服务器。

跟微软竞争向来不是什么好主意。微软最擅长的就是把自家方案设置成默认值，Octopus Deploy 公司创始人兼 CEO Paul Stovell 在 2016 年就亲身经历过这家软件巨头的“毒打”。

一夜之间，微软的产品就成了设置选项。我们在 Build 2016 大会上展示了自己的方案，但总有人跑到我们展台问：微软也有同类产品，我们为什么要用你们家的？问题是“微软同类产品”才刚刚公布，我们哪里知道呢……

可重现开发者环境是一波浪潮，而非特定产品功能

可重现的开发者环境长期不受重视，直到最近才开始逐渐普及。也许再过几年，这类环境将成为开发流程中的标配。但我觉得整个行业正走向跟 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”的作法。

Gitpod 工作流很快就将不再独特

看看下面的内容，我的意思不言而喻了。

Kubernetes 不是那个正确的抽象层

Gitpod 的开发环境立足于 Kubernetes pod。虽然后者非常简洁，但经过认真考量，我觉得 Kubernetes 并不是适合 Gitpod 的正确抽象层。原因有以下几点：

• 围绕 Kubernetes 进行产品设计，会把受众群体限制在使用容器的开发者之内。在糟糕的整体经济环境下，企业需要一款能够面向所有软件开发场景的统一工具——包括 Windows 桌面开发、macOS 移动开发和数据科学（能够访问强大的 GPU）。

• Kubernetes 太复杂了。企业在 Kubernetes 方面本身就缺乏丰富的经验，因此以本地产品的形式推广 / 销售 / 支持 Gitpod 将极为困难，而且需要辅以相应的文化转型。

一线老员工的真实想法

我认为对于远程代码执行即服务这类业务（即运行不受信的公共工作负载）来说，容器的环境隔离技术还不够安全。Gitpod 确实利用 Linux 命名空间实现了不少酷炫的功能，但这样既不够安全，也要承担相应的代价。

由于上述原因，之前两年我们一直无法在 Gitpod 上原生运行 Kubernetes。客户之所以愿意把开发环境从本地许配电脑转移至云端，最关键的动机之一就是想要运行云原生工作流和应用程序。但 Gitpod 做不到这一点，那还折腾什么劲。

结束语

Huntley 表示自己很珍惜在 Gitpod 工作的时光，同事们既亲切又聪明。但他认为，要让产品真正发光发热，Gitpod 还需要解决结构、战略和领导等层面的诸多问题。“我是等不到那天了，所以就此别过吧。”

离开 Gitpod 后，Huntley 目前投身到了 NFT 行业，创建了 thenftbay.org。Huntley 称自己将以太链和 SOL 链上所有 NFT 文件打包成一个 17.76TB 的压缩文件，并将 BT 种子放在该网站上供任何人下载。

在该网站上可以找到很多热门 NFT，但无论点击哪个 NFT，都会指向那个巨大的压缩包，无法单独下载。Geoffrey Huntley 表示，他想用盗版让人们意识到自己买的 NFT 究竟是什么，真正关注 NFT 的价值，进而不会被卖家当成韭菜。

参考链接：

https://ghuntley.com/tea/

https://technews.tw/2021/12/01/nft-the-pirate-bay/

今日好文推荐

 活动推荐

企业数据库如何满足高弹性、易伸缩等业务需求？

9 月 26 日 19:00，作业帮、微盟技术专家直播间为你解答！

预约本期技术公开课，Get 敏态场景下的数据库落地实践经验

扫码或点击【阅读原文】，立即预约直播~~