開放原始碼 Thoughtworks Go

Chad： Go 不是持續整合伺服器。它專門用於持續交付 (CD)，而持續整合只是其中的一部分。Go 支援輕鬆建模順序和並行執行、扇入和扇出相依性管理，以及部署管線獨有的其他活動。

你可以拼湊任何東西，但有時你應該避免這麼做。部署管線應該是 CD 工具中的首要概念，以避免頭痛。我見過許多團隊，包括 Thoughtworks 的一些團隊，浪費大量時間和資源使用 CI 工具實作管線。有些基本功能有所欠缺，例如，如果你有超過一個簡單的工作流程，就無法清楚追溯到來源。

不，但我們並未達成將其作為商業產品的目標。Thoughtworks 是一個三支柱組織。其中一個支柱是擁護軟體卓越性並革新 IT。另一個是經營永續事業。很難提倡大幅改變行為、收取高額費用，並與免費的 CI 拼湊解決方案競爭。（我們也是 OSS CI 伺服器的忠實愛好者；我們已經將三個成功的 OSS 化。）換句話說，我們在財務上賺得不夠多，不足以證明沒有革命。可以把它想像成平衡具有明確最小值的滑塊。

我們也開始相信基礎架構軟體需要是 OSS。Go 所涵蓋的生態系統中幾乎所有東西都是 OSS，從源碼控制和建置到部署和組態管理。這些類型的工具需要社群。雖然 OSS 商業模式在某些方面較為困難，但如果我們能幫助讓持續交付普及化，我們願意放棄收益。我們的創辦人 Roy 非常相信創造公共財。

一旦你決定讓某個東西免費提供，就會發生有趣的骨牌效應。你不能再用相同的方式收費，那是沒有道德的。作為回應，你會提供給潛在客戶和客戶大幅折扣，或告訴他們現在不用付費。那會引起懷疑，而且令人驚訝的是，人們堅持要付錢給你。在你安撫了他們的疑慮後，你最終會崩潰並告訴個人你正在開放原始碼。一旦你經歷過很多次這種情況，你必須透過廣泛的公告繼續前進。你無論如何都會公告它。Google 預先公告 Android 為 OSS，而 HP 對 WebOS 也做了同樣的事。我的猜測是，他們都試圖以類似的方式避免洩漏的非公告。

程式碼還沒有準備好。我們正努力讓開發人員體驗變得更棒。我們有一些你預期會做的事，例如清理程式碼註解中的語言並移除舊授權。但是，還有其他複雜性。我們使用 Go 在兩個資料中心的大型 VM 網格上建置、測試和釋出 Go。我們需要建立一個更簡單的公共建置基礎架構。我們正在 OpenStack 上執行這項工作。我們為 Go 編寫的大型自動功能測試套件是用 Twist 編寫的，它不是開放原始碼，所以我們必須想辦法解決它。還有很多事要做。

Go 最初被命名為 Cruise，以向 CruiseControl 致敬。但是，類似的名稱選擇造成了混淆，因此我們在 2010 年 7 月將其重新命名為 Go。這是在 Google 公開展示golang之後不久，但當時這門語言還遠未普及。

是的。考量到讓原始碼可用的所有工作，我們決定一開始不要因為名稱而延誤。然而，名稱將由社群決定。一旦程式碼釋出，如果社群想要更改名稱，我們都支持。

Thoughtworks 在 2001 年建立了第一個持續整合伺服器，CruiseControl，作為一個 OSS 專案。2007 年，我們開始著手現代化，但我們發現 CruiseControl 的架構無法支援我們想要的網格和一流的部署管線。目前，CruiseControl 和 Go 沒有任何共通點。

目前的 Go 團隊不會解散。事實上，如果專案有一個蓬勃發展的社群，我們會增加更多人手。Thoughtworks 也會提供商業附加元件和支援。

Snap 是我們託管的 CD 即服務。它適用於部署需求較簡單的應用程式。我們建立 Go 來解決複雜的 CD 設定。我們設計 Snap，讓 CD 本身對部署到一般雲端服務的團隊和組織來說很簡單。換句話說，Go 的功能廣度著重於複雜的場景，而 Snap 的功能深度則著重於使用慣例來簡化 CD。

我們想要做的事情相當多，順序將在很大程度上由社群決定。我們有意識地決定不讓團隊中擁有「產品經理」角色，而支持更以社群為導向的流程。

增加更多延伸點在清單中非常重要，這樣人們可以更輕鬆地延伸 Go。有一些非常酷的想法，讓價值串流圖 (vsm) 除了可視化之外，還有更多與價值串流相關的功能。許多使用者要求讓入門更簡單的功能。我們希望將 Go 的驗證移到外掛程式，以便人們可以建立自己的驗證。

在 GitHub 問題中，很快就會有更完善的清單，所有人都可以在其中留言並協助將這些問題按順序解決。