滿心歡喜入職 Gitpod 一年後失望離開:垃圾郵件當 OKR、天天造勢但就不兌現承諾

語言: CN / TW / HK

去年,選擇了房車露營生活的 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 的開發環境立足於 Kubernetres 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/