Go 部落格

Go，開放原始碼，社群

Russ Cox
2015 年 7 月 8 日

歡迎

[這是我在 2015 年 Gophercon 的開幕主題演講的文字記錄。此處有提供影片。]

感謝大家特地來到丹佛參加這個活動，也感謝所有透過影片觀看的觀眾。如果你是第一次參加 Gophercon，歡迎你。如果你去年也在場，歡迎你再次蒞臨。謝謝主辦單位為舉辦這樣的會議所付出的辛勞。我很高興能來到這裡，並有機會與大家暢談。

我是 Google 的 Go 專案和 Go 團隊技術負責人。我和 Rob Pike 共同擔任這個職位。在這個位置上，我會花很多時間思考整個 Go 開放原始碼專案，特別是它如何執行、成為開放原始碼的意義，還有 Google 內外貢獻者之間的互動。今天我想與你分享我如何看待整個 Go 專案，然後根據此說明我如何看待 Go 開放原始碼專案的演進。

為什麼選擇 Go？

要開始進行這個專案，我們必須回溯到最初。我們開始從事 Go 專案的原因是什麼？

Go 旨在讓程式設計師提高生產力。我們希望改善 Google 中的軟體開發程序，但 Google 遇到的問題並非 Google 獨有。

我們有兩個整體目標。

第一個目標是製作出一種能因應可擴充並行挑戰的更好語言。所謂的可擴充並行，是指同時處理大量問題的軟體，例如透過發送網路流量來協調上千個後端伺服器。

現在，這類軟體有了更簡短的名稱：我們稱之為雲端軟體。有理由說，Go 是在雲端執行軟體之前就已設計好的。

更大的目標是創造一個更理想的環境來因應可擴充軟體開發的挑戰，這種軟體由許多人製作且使用，彼此之間的協調有限，且維護年限長達好幾年。在 Google，我們有數千名工程師彼此寫作並分享程式碼，試著完成自己的工作，盡可能地重複使用他人的工作，並在一個具有超過 10 年歷史的程式碼庫中工作。工程師經常處理，或至少查看最初由其他人撰寫的程式碼，或者是由他們自己好幾年前撰寫的，這兩者經常是同一件事。

Google 內部的這種情況與在 GitHub 等網站上執行的現代大規模開放原始碼開發有許多共同點。因此，Go 非常適合開放原始碼專案，協助它們接受和管理來自龐大社群的貢獻，並持續一段很長的時間。

我相信 Go 會如此成功，很大一部份原因在於 Go 非常適合雲端軟體，Go 非常適合開放原始碼專案，而這兩者都很巧合地在軟體產業中越來越受到歡迎及重視。

其他人也做出了類似的觀察。以下列出兩個。去年，Donnie Berkholz 在 RedMonk.com 上寫了一篇關於「Go 成為雲端基礎架構的新興語言」的文章，文中觀察到「[Go 的] 招牌專案…是以雲端為中心或用於處理分散式系統或暫時性環境。」

今年，Texlution.com 上的作者寫了一篇標題為「為何 Go 注定會成功」的文章，指出專注於大規模開發或許比 Google 本身更適合開放原始碼：「這就是為何我覺得你即將看到更多 Go 的原因，因為它適合開放原始碼…。」

Go 的平衡

Go 如何達成這些目標？

Go 如何讓可擴充並行和可擴充軟體開發變得更簡單？

大多數人回答這個問題時，都會談到通道和 goroutine、介面、快速的編譯、go 指令，以及完善的工具支援。這些都是解答中很重要的部分，但我認為背後有一個更廣泛的想法。

我覺得這個想法就是 Go 的平衡。在任何軟體設計中都會有相互競爭的問題，而且會非常自然地想要嘗試解決所有可預見的問題。在 Go 中，我們明確地嘗試了不解決所有問題。反之，我們嘗試只做到足以讓你可以輕鬆建立自己的自訂解決方案。

我摘要 Go 所選擇的平衡，即：簡化功能，增進效能。

簡化功能，增進效能。

Go 無法做到所有事情。我們不應該嘗試。但是，如果我們努力去做，Go 可能可以做好幾件事。如果我們仔細選擇這些事情，我們可以建立一個基礎，讓開發人員可以輕鬆建立他們需要的解決方案和工具，並理想上可以與其他人建立的解決方案和工具互操作。

範例

讓我透過一些範例來說明這一點。

首先，Go 語言本身的規模。我們努力盡量加入少量的概念，以避免在一個大型開發人員社群的不同部分中，形成無法相互理解的方言問題。在一個想法加入到 Go 之前，我們會一直簡化成該想法的精髓，然後清楚了解其好處以證明加入的複雜度是合理的。

一般來說，如果我們有 100 件事想要讓 Go 做得好，我們無法進行 100 項個別變更。反之，我們會盡量研究和了解設計空間，然後找出幾項可以互相協作的變更，並且可以用於其中的 90 件事。我們願意放棄剩下的 10 件，以避免讓語言膨脹，並避免只為了因應特定用途案例而增加複雜度，這些用途案例看似今日很重要，但明天可能就不存在了。

保持語言的精簡可以達成更重要的目標。因為精簡，所以 Go 更容易學習、更容易理解、更容易實作、更容易重新實作、更容易除錯、更容易調整和更容易演進。簡化功能可以增進效能。

我必須指出，這表示我們必須對許多其他人的想法說不，但我可以向你保證，我們對自己更多的想法說了不。

接下來，是通道與 goroutine。我們應如何安排和協調非同步和並行運算？互斥鎖和條件變數非常普遍，但層級很低，難以正確使用。像 OpenMP 這類的平行執行架構層級太高，只用於解決範圍較狹小的問題。通道與 goroutine 位於這兩個極端之間。單獨來看，它們不是許多問題的解答。不過，它們夠強大，可以輕鬆安排在許多常見的非同步軟體問題的解決方案中。少做一點，確實只做足夠的事，這樣才能成就更多。

接下來，類型與介面。有靜態類型可以進行有用的編譯時檢查，這是動態類型語言（如 Python 或 Ruby）所欠缺的。同時，Go 的靜態類型避免了傳統靜態類型語言的許多重複，給人的感覺更輕巧，更像是動態類型語言。這是人們最早注意到的其中一件事，很多 Go 的早期採用者都是來自動態類型語言。

Go 的介面是其中的關鍵。特別是，省略了 Java 或其他具有靜態層級的語言的「implements」宣告，讓介面更輕巧更靈活。沒有這種嚴格的層級，就能夠採用各種習慣做法，例如描述現有、不相關的製程實作的測試介面。少做一點，才能成就更多。

接下來，測試及基準測試。在多數語言裡，會缺少測試及基準測試架構嗎？它們之間是否一致？

Go 的測試套件並非要針對這些主題的每一個面向。而是提供這些主題中，大多數較高層級工具所需要的一些基本觀念。 套件有測試案例，這些案例會通過、失敗或略過。套件有基準測試，這會執行並且可以使用各種指標來量測。

此處少做一點，是為了嘗試將這些觀念簡化為重點，並建立一個共同的詞彙，以便更豐富的工具可以相互操作。這種一致性讓較高層級的測試軟體可以運作，例如 Miki Tebeka 的 go2xunit converter，或 benchcmp 及 benchstat 基準測試分析工具。

由於對於基本觀念的表達方式達成一致，因此這些較高層級的工具適用於所有 Go 套件，不只套件內努力選擇加入的套件，而且它們可以相互操作，例如，使用 go2xunit 這個工具，並不表示不能同時使用 benchstat 這個工具，如果這些工具是競爭測試架構的 plug-in，也還是可以這樣使用。少做一點，才能成就更多。

接著，重構和程式分析。由於 Go 用於大型程式庫，我們知道它需要支援自動維護和更新原始碼。我們也知道這個主題太大，無法直接建構進去。但我們知道我們必須做的一件事是什麼。在嘗試其他設定中的自動程式變更時，我們最大的障礙實際上是以開發人員可以接受的格式寫出修改後的程式。

在其他程式語言中，不同的團隊會使用不同的格式設定慣例。如果程式進行編輯時使用錯誤的慣例，它可能會寫出看起來與其餘檔案一點都不像的原始碼檔案區段，或重新格式設定整個檔案，導致不必要且不需要的差異。

Go 則沒有這個問題。我們設計了這個程式語言，讓 gofmt 成為可能，我們努力使 gofmt 的格式設定為所有 Go 程式所接受，並且我們從原始公開發行的第一天就確保有 gofmt。Gofmt 強制執行對應的統一性，以自動化變更與其餘檔案融為一體。你無法得知特定變更是由人為或電腦執行。我們並未建構明確的重構支援功能。建立一個約定俗成的格式設定演算法作為獨立工具開發和交互操作的共同基礎已足夠。Gofmt 促使 gofix、goimports、eg 和其他工具執行。我相信這項工作才剛開始。還有更多事情可以做。

最後，建立和共用軟體。在 Go 1 上線之前，我們建置了 goinstall，它成為我們所說的「go get」。這個工具定義了一個標準的零組態方法，用於解析像 github.com 等網站上的匯入路徑，稍後也透過發出 HTTP 要求解析其他網站上的路徑。這個約定俗成的解析演算法促使其他工具使用這些路徑，其中最著名的是 Gary Burd 建構的 godoc.org。如果你尚未使用的話，你可以針對任何有效的「go get」匯入路徑前往 godoc.org/匯入路徑，而這個網站會擷取程式碼並顯示其文件。這項工作的額外好處是 godoc.org 能夠作為公開可用的 Go 套件的粗略主清單。我們所做的一切就是賦予匯入路徑明確的意義。減少執行，促使更多事項發生。

您會注意到，這些工具範例有許多是關於建立共用公約。有時人們稱之為 Go 具「主見」，但背後還有更深入的意涵。同意共用公約的限制是可以讓廣泛類別的工具相互操作的方法，因為它們都使用相同的基礎語言。這是用更少的做法達成更多效果的有效方式。特別是在許多情況下，我們可以採取必要步驟來確立對特定概念的共識，例如遠端匯入，或原始檔的格式化，並依此建立套件和工具，因為它們都同意這些核心細節。

我稍後會再回到這個想法。

Go 為何是開放原始碼？

但首先，正如我先前所說的，我想說明我如何看待「用更少的做法達成更多效果」平衡我們在更廣泛的 Go 開放原始碼專案上的工作。為此，我必須從 Go 為何會是開放原始碼開始說起。

Google 出錢讓我和其他開發人員從事 Go 的開發工作，因為如果 Google 的程式設計人員的生產力提升，Google 便能更快速地打造產品，更輕鬆地維護產品，以及種種的好處。但何必要讓 Go 開放原始碼？Google 何必將這些好處與全世界分享？

當然，我們之中有許多人在 Go 問世前就從事開放原始碼專案，所以我們自然希望 Go 成為開放原始碼世界的一部分。但我們的偏好並非商業上的依據。商業上的依據是，Go 開放原始碼是因為這是 Go 成功唯一的途徑。身為在 Google 內建構 Go 的團隊，我們從第一天便已了解這一點。我們知道 Go 必須向盡可能多的人開放，才能成功。

封閉式語言終將衰敗。

語言需要廣大而多元的社群。

語言需要大量人員編寫大量軟體，這樣當您需要特定工具或函式庫時，便很有可能已經有人撰寫，而且撰寫者比您更了解主題，並花費比您更多的時間把它做好。

語言需要大量人員回報錯誤，這樣才能快速找出問題並加以修正。由於使用者數量龐大，Go 編譯器比其大致根據的 Plan 9 C 編譯器更加健全且符合規格。

語言需要大量人員使用它做各種不同的用途，這樣語言才不會過度適合特定用途，並在科技環境變動時變得不堪用。

語言需要大量想要學習它的使用者，這樣市面上才有需求讓人員編寫書籍、開設課程，或舉辦像本場這樣的研討會。

如果 Go 只能留在 Google 內部，這些情況都不可能發生。Go 會在 Google 或任何單一公司或封閉環境中窒息而死。

從根本上來說，Go 必須是開放的，而 Go 需要你。缺少你們所有人，缺少全世界各式專案所使用的 Go，Go 將無法成功。

而 Google 的 Go 團隊永遠都不夠龐大，無法支援整個 Go 社群。為了持續擴充，我們需要在不增加付出的情況下，達成更多「更多」。開放原始碼很大一部分就是如此。

Go 的開放原始碼

開放原始碼是什麼意思？最低要求是公開原始碼、以開放原始碼授權條款提供，而我們已經做到了。

但我們也公開了我們的開發流程：自從宣布 Go 以來，我們就已在公開場合以所有人可存取的公開郵寄清單處理所有開發事宜。我們接受並審閱來自任何人的原始碼貢獻。流程和你是否為 Google 工作無關。我們公開維護我們的臭蟲追蹤器，在公開場合討論並開發變更提案，並在公開場合推動版本發布。公開原始碼樹是具有公信力的複本。變更會先在這裡進行。之後才會導入 Google 的內部原始碼樹。對於 Go 來說，成為開放原始碼表示這是一項不限於 Google 的集體努力，對所有人士開放。

任何開放原始碼專案都是從極少數人開始的，通常只有一個，但 Go 有三位：Robert Griesemer、Rob Pike 和 Ken Thompson。他們設想 Go 的願景與他們認為 Go 相較現有語言可以表現得更好的地方，而 Robert 將在明天早上進一步說明。我是加入團隊的下一位成員，接著是 Ian Taylor，然後，逐一加入，成就了我們今天的規模，擁有數百位貢獻者。

感謝到目前為止已為 Go 專案貢獻程式碼、點子或臭蟲回報的眾多人士。我們盡力在今日計畫的場域清單上所有人都列出來。如果你的名字沒有在上面，我深感抱歉，但仍然要感謝你。

我相信到目前為止的數百位貢獻者朝著 Go 可以發揮作用的願景共同努力。要以言語形容這些是很困難的，但我盡力在前面說明願景的一部分：少做一點，成就更多。

Google 的角色

一個自然而然的問題是：與其他貢獻者相比，Google 的 Go 團隊角色是什麼？我相信這個角色會隨著時間而改變，而且持續改變中。總體趨勢是：隨著時間推移，Google 的 Go 團隊應該減少付出，並促進更多成果。

在過去，在 Go 還未對大眾所知時，Google 內部的 Go 團隊顯然是以獨立的方式運作。我們寫下了所有內容的第一份草稿：規格、編譯器、執行時期和標準函式庫。

然而，在 Go 成為開源軟體後，我們的角色便開始轉變。我們最需要做的事情是傳達我們對 Go 的願景，這很困難，而且我們仍在努力中。最初實作是傳達願景的重要方式，就像我們領導的開發工作最後造就了 Go 1，以及我們發布的各種部落格文章、文章和演講。

但就像 Rob 去年在 Gophercon 所說的：「語言已完成。」現在，我們需要了解它的運作方式，了解人們如何使用它，以及人們如何開發。現在的重點在於擴展 Go 可以支援的各種工作。

Google 的主要角色現在是賦能社群、協調，以確保變更能良好地整合，並讓 Go 符合最初的願景。

Google 的主要角色是：少做一些。多做一些。

我之前提過，我們寧願只有少數的功能，用以支援針對 90% 目標使用案例，並避免多出數量級的更多功能，才能達到 99 或 100%。我們成功地將此策略應用於我們熟悉的軟體範疇。但如果 Go 要在許多新的領域裡變得有用，我們需要這些領域的專家帶他們的專業知識來參與討論，這樣我們才能共同設計微小的調整，以支援 Go 的許多新應用。

這種轉變不只適用於設計，也適用於開發。Google 的 Go 團隊的角色持續轉變，更趨向於引導，而非純粹的開發。我現在花更多時間在審閱程式碼，而非撰寫程式碼，且花更多時間處理錯誤報告，而非自己提出錯誤報告。我們需要少做一些，但多做一些。

隨著設計和開發轉移到更廣泛的 Go 社群，我們這些 Go 的原始作者最能提供最重要的其中一項，就是願景一致性，以協助維持 Go 的特質。我們必須取得的平衡肯定帶有主觀性。例如，可擴充語法的機制將是一種支援撰寫 Go 程式碼的更多方法，但這會違背我們的目標，即擁有一門沒有各種方言的一致性語言。

我們有時必須說不，或許比其他語言社群還要更常說，但當我們這樣做的時候，我們的目標是建設性地、有禮貌地執行，並將此視為釐清 Go 願景的機會。

當然，這不都是協調和願景。 Google 仍資助 Go 開發工作。 Рик·哈德森稍後會深入探討他在減少垃圾收集器延遲上的工作，而 Hana Kim 明天將會深入探討她在將 Go 帶到行動裝置上的工作。但我想明確表示，在能力所及範圍內，我們旨在將由 Google 資助的開發視為與其他公司資助的開發或個人利用空餘時間所貢獻的開發同等。我們這麼做的原因在於我們不知道下一個偉大想法將從何而來。每位為 Go 做出貢獻的人士都應該有表達意見的機會。

範例

我想分享一些關於此說法的證據，歷經時間的考驗，Google 上的 Go 原始團隊更注重協調，而非直接開發。

首先，Go 開發資金來源正在擴大。在開放原始碼釋出之前，顯然 Google 支付了所有 Go 開發費用。在開放原始碼釋出後，許多個人開始貢獻他們的時間，而且我們已經逐漸且穩健地增加受其他公司支持的開發人員人數，這些開發人員會投入至少部分時間參與 Go 的開發，尤其是在與讓 Go 對這些公司更有用的部分相關的工作方面。時至今日，此名單包括 Canonical、Dropbox、英特爾、Oracle 等公司。當然，Gophercon 與其他區域性 Go 會議都是由 Google 以外的人士所組織，而他們擁有許多 Google 以外的公司贊助商。

其次，原始團隊以外所執行的 Go 開發中概念的深度正在擴展。

在開放原始碼釋出後，第一批重大貢獻之一便是移植到 Microsoft Windows，由 Hector Chu 發起，由 Alex Brainman 等人完成。更多貢獻者將 Go 移植到其他作業系統。更多的貢獻者重新編寫大部分數字程式碼，使其更快、更精確，或同時具備這兩個特色。這些都是重要的貢獻，而且備受讚譽，但在大部分情況下，它們並未包含新的設計。

最近，由 Aram Hăvărneanu 領導的一群貢獻者將 Go 移植到 ARM 64 架構。這是 Google 以外的貢獻者第一次執行架構移植。這意義重大，因為一般來說，支援新架構所需的設計工作比支援新作業系統的設計工作還多。架構之間的差異比作業系統之間的差異更多。

另一個範例是在過去幾個版本中導入，初步支援使用共用函式庫建置 Go 程式。此功能對許多 Linux 來說很重要，但對 Google 來說不怎麼重要，因為我們部署的是靜態二進位檔。我們一直在協助指導整體策略，但大部分的設計及幾乎所有的實作，都是由 Google 外的協力廠商完成，特別是 Michael Hudson-Doyle。

我的最後一個範例是 go 指令處理協力廠商的方式。我定義協力廠商為將外部相依性原始程式碼複製到樹狀結構，以確保它們不會消失或在不知不覺中改變。

協力廠商不是 Google 會遇到的問題，至少對世界其他地區並非如此。我們將要使用的開源函式庫複製到我們的共用原始碼樹狀結構中，記錄我們的複製版本，並只在有需要時更新複製檔。我們有一個規則，一個特定的函式庫在原始程式碼樹狀結構中只能有一個版本，而升級那個函式庫的責任在於無論它讓它持續運作，都能達到相依的 Google 程式碼預期。這種情形並不常發生，這是懶惰的協力廠商方式。

相較之下，Google 以外的大部分專案採取比較熱切的方式，使用自動化工具匯入並更新程式碼並確保它們總是使用最新版本。

因為 Google 對此協力廠商問題的經驗相對較少，我們讓 Google 以外的使用者開發解決方案。在過去五年中，人們已經建置了一系列工具。當今主要使用的工具包括 Keith Rarick 的 godep、Owen Ou 的 nut，以及 Dave Cheney 的 gb 的 gb-vendor 外掛程式。

目前的狀況有兩個問題。第一個是這些工具在開箱時與 go 指令的「go get」不相容。第二個是這些工具甚至互不相容。這兩個問題都按工具分割開發人員社群。

去年秋天，我們開始公開設計討論，試圖建立有關這些工具如何操作的某些基礎共識，以搭配「go get」和彼此順利運作。

我們的基本提案是所有工具都同意在協力廠商處理過程中重新編寫匯入路徑的做法，以配合「go get」的模型，而所有工具也必須針對描述複製程式碼的來源和版本的檔案格式達成共識，以便即使是單一專案，不同的協力廠商工具也能一起使用。如果您今天使用了一個工具，您明天仍然可以使用另一個工具。

用這種方式找到共識完全符合「少做點，才能做得更多」的精神。如果我們可以在這些基本語義層面取得共識，就能讓「go get」以及所有這些工具都能夠交互操作，還可以像使用文字檔案儲存 Go 程式，並使用 Go 編譯器和所有文字編輯器就能夠交互操作的方式在不同工具之間切換。所以，我們發布了我們的共識提案。

發生了兩件事。

首先，丹尼爾·西奧費尼斯在 GitHub 上啟動了一個供應商規範專案，其中提出了新的提案，並接手管理和設計供應商元資料規範。

其次，社群基本上異口同聲地表示，在供應過程中改寫輸入路徑並不可行。如果可以將程式碼複製，而不用變更，供應運作會更順暢。

凱斯·瑞瑞克發表了一項替代提案，內容是對 go 指令進行最小的變更，以支援供應，卻無須改寫輸入路徑。凱斯的提案免除設定，而且與 go 指令的其餘方式很契合。此提案將作為實驗性功能，包含在 Go 1.5 中，而且有可能預設出現在 Go 1.6 中。我相信供應工具作者都已經同意，只要丹尼爾的規範完成定稿，就會採用。

結果，在下一次的 Gophercon 中，供應工具和 go 指令之間應該會有廣泛的交互操作性，而實現此目標的設計完全是由 Go 團隊以外的協力廠商所完成的。

不僅如此，Go 團隊關於如何執行此動作的提案基本上完全錯誤。Go 社群很明確地告訴了我們這一點。我們接受了這項建議，現在已經有了供應支援計畫，我相信所有參與其中的人都很滿意。

這也是我們設計一般方針的一個好範例。我們會盡量不要在 Go 中做任何變更，除非我們覺得針對一個理解良好的解決方案有了廣泛的共識。對於供應，來自 Go 社群的意見回饋和設計對達成共識至關重要。

程式碼和設計都來自較廣泛的 Go 社群，這種一般趨勢對 Go 來說很重要。各位，也就是廣泛的 Go 社群，知道在你們使用 Go 的環境中，什麼有效，什麼沒有效。我們在 Google 卻不知道。我們會越來越依賴你們的專業知識，並會盡量協助你們開發設計和程式碼，讓 Go 能夠在更多情況下發揮作用，並與 Go 的原始願景契合。同時，我們會持續等待針對理解良好的解決方案達成的廣泛共識。

這讓我想到我的最後一點。

行為守則

我主張 Go 必須是開放的，而且 Go 需要你們的協助。

但事實上，Go 需要每個人的協助。而並非所有人都來到了這裡。

Go 需要盡可能多人的點子。

為了讓此事成真，Go 社群必須要讓所有人盡可能都能參與、歡迎、願意互相幫忙，而且尊重彼此。

現在這個 Go 社群很龐大，我以及其他人不再假設社群中的每個人都知道期望事項，而是認為把這些期望寫下來才是合理的。很像 Go 規範對所有 Go 編譯器設定的期望，我們可以撰寫一份規範，設定對我們在線上討論及類似本活動的實體會議的行為期望。

明確說明和任何好規範一樣，它必須夠通用才能允許多種實作，但又必須具體到能找出重要問題。當我們的行為不符合規範時，其他人就能指出我們的問題，然後我們才能修正問題。同時，重要的是要了解，這種規範不可能像程式語言規範一樣精確。我們必須從假設我們所有人都會合理地運用規範這個假設開始。

這種規範通常被稱為行為準則。Gophercon 有一份行為準則，我們所有人既然參加了這次活動，就同意遵守這份行為準則，但 Go 社群並沒有行為準則。我以及其他人認為 Go 社群需要一份行為準則。

但是這份行為準則該說什麼呢？

我相信我們可以做出的最重要的總體聲明是，如果您想使用或討論 Go，那麼在我們的社群，我們歡迎您的到來。我相信這是我們希望能達到的標準。

話雖如此（而且講清楚一點，還有其他很好的原因），Go 需要一個盡可能龐大的社群。就行為會限制社群規模的程度而言，行為會阻礙 Go 的發展。行為很容易就會限制社群的規模。

科技社群，特別是 Go 社群，傾向於言詞生硬的人群。我不認為這點很根本。我不認為這是必要的。但是在線上討論中，比如電子郵件和 IRC，由於純文字沒有 дополнения補充的線索和信號，這一點特別容易做到。

舉例來說，我發現當我時間緊迫時，我寫的字比較少，結果就是我的電子郵件看起來不只匆促，還很生硬、沒耐心，甚至是輕蔑的。我不是這種感受，但別人可能這樣看我，而這種印象有可能讓人猶豫是否要使用 Go 或為 Go 做出貢獻。當一些 Go 貢獻者寄私人電子郵件給我，告訴我我做了哪些事時，我意識到我的行為。現在，當我時間緊迫時，我會特別注意我寫的內容，而且我常寫比平常更多的內容，以確保我傳達的是我想要傳達的訊息。

我相信更正我們日常互動中讓潛在使用者和貢獻者卻步的部分，無論這些部分是刻意或無意造成的，是我們所有人可以實行最重要的措施之一，以確保 Go 社群持續成長。一份完善的行為準則能夠協助我們達成這個目標。

我們沒有撰寫行為準則的經驗，所以我們已經閱讀了現有的準則，而我們很可能會採用現有的準則，也許會做些微調整。我最喜歡的是 Django 行為準則，它源自另一個稱為 SpeakUp! 的專案。它以日常互動提醒清單的說明方式來建構。

「保持友善和耐心。樂於歡迎。體貼他人。保持尊重。慎選用字。當我們意見不合時，試著了解原因。」

我相信這抓住了我們想要設定的基調、想要傳達的訊息，以及我們想要為新的貢獻者創造的環境。我當然想要友善、耐心、樂於歡迎、體貼和尊重。我不會永遠都做得一絲不苟，如果我做不到，我樂於收到有用的注意事項。我相信我們大多數人都有相同的感覺。

我還沒提到基於或過度影響種族、性別、身心障礙或其他個人特質的積極排斥，我也沒有提到騷擾。對我來說，這源自於我剛剛說過的，排斥行為或明目張膽的騷擾絕對不可接受，無論是在線上或線下。每一套行為準則都明確說明了這一點，而且我預期我們的準則也會如此。但我相信 SpeakUp! 關於日常互動的提醒也同樣重要。我相信為這些日常互動設定高標準，可以讓極端的行為更明顯且更容易處理。

我毫不懷疑 Go 社群可能是科技業中其中一個最友善、最歡迎人、最體貼和最尊重的社群。我們可以讓它成真，這將會對我們所有人都有好處和信譽。

Andrew Gerrand 一直領導採用適用行為準則來推廣 Go 社群的這項努力。如果你有建議、疑慮，或與行為準則相關的經驗，或想要參與其中，請在這個大型研討會議期間找到 Andrew 或我。如果你星期五還待在這裡，Andrew 和我將會在 Hack Day 活動期間抽出一些時間來討論行為準則。

再說一次，我們不知道下一個偉大的點子將從何而來。我們需要我們能獲得的所有協助。我們需要一個大型、多元的 Go 社群。

謝謝

我將許多使用「go get」釋出可供下載軟體、透過部落格文章分享見解，或在郵件清單或 IRC 上協助他人的人視為此項廣大的開放原始碼計畫的一部分，也是 Go 社群的一份子。今天在這裡的每一個人也都是這個社群的一份子。

在此預先感謝接下來幾天會撥出時間分享他們使用和擴充 Go 的經驗的報告者們。

首先感謝各位撥冗蒞臨會場、提問，並讓我們知道 Go 對您是否有用。當您返家後，請持續分享您所學到的知識。即使您沒有將 Go 運用在日常工作中，我們仍樂見 Go 被用於其他內容，就像我們時常期待著能將好的想法帶回 Go 一樣。

再次感謝您們參與 Go 社群，並花費時間與精力蒞臨會場。

在今後幾天，請各位告訴我們哪些地方做得好，哪些地方做不好，並協助我們共同合作，讓 Go 變得更美好。

請謹記要友善、耐心、歡迎、體貼與尊重。

最重要的是，盡情享受此次大會。