創始人深度複盤：GitHub為什麼能夠做成？

本文作者是 GitHub 聯合創始人 Scott Chacon。因為網絡上有很多分析 GitHub 成功的文章，他認為有些分析不太對，所以寫了這篇文章，從內部人的視角分析了 GitHub 崛起與成功的原因。我們一起來看看他是怎麼說的。

如果你想馬上知道 GitHub 為何如此成功，以及你為何一直在使用它。我這兒有個精簡版答案。

我將 GitHub 的成功歸因於兩個關鍵因素的完美結合。

• GitHub 的推出時機堪稱完美

• GitHub 很有品位

GitHub 的四位聯合創始人都有過失敗的經歷，無論是在 GitHub 之前還是之後。Chris 和 PJ 在 GitHub 之前沒能讓 FamSpam 成功，而 Tom 和我在 GitHub 之後也沒能讓 Chatterbug 火起來。我認為這兩個項目都很有品味，並且是很棒的產品，但它們都沒能像 GitHub 那樣成功。這可能是推出的時機不對，也可能是市場條件不成熟，或者還有其他原因。

GitHub 剛起步的時候，分佈式開源版本控制工具開始變得既實用又穩定，逐漸被人們採納，但在當時，幾乎沒有人（更不用說商業領域）真正認真地去託管這些工具。大公司看不上，小公司又因為不夠專業搆不著。

而那些後來注意到 Git 和 GitHub 崛起的競爭對手（比如 Sourceforge、Google Code 等）卻缺乏那種獨特的品味。他們似乎永遠無法與一個以產品為中心的開源軟件開發團隊相抗衡。

我們非常注重開發者的體驗，並且擁有足夠的創造力，敢於打破常規，按照我們自己的理念去構建產品。而其他人則只是在構建他們認為能夠吸引廣告商或 CTO 的產品。

這就是 GitHub 能夠勝出的原因。

原因已經說清楚了，如果你對具體細節感興趣的話，請看下面內容。

一、環境

讓我們從開始一點一點地講起。

我將站在 2005 年的一名軟件開發人員的角度，來深入探討 「GitHub 的誕生時機恰到好處」 這個主題。當時 Linus 提交了 Git 的第一個 commit，Olivia 提交了 Mercurial 的第一個 commit。

20 年前軟件開發是什麼樣的？又是怎樣的環境讓 Git 贏得了人心，並促使 GitHub 誕生的呢？

Mac OS Tiger，2005 年發佈。如果你使用的是 Mac，它看起來像這樣。

如果你是 2005 年時的軟件開發人員，你可能（希望）用的是 Subversion 這樣的集中式版本控制系統。在 Git 出現之前，我用過 RCS、CVS、Subversion，還有 Perforce。記得我待過的一家公司，甚至直接用 FTP 把 PHP 文件傳到服務器上。那時候，我們就是這麼幹的。

如果你當時在做商業專有軟件開發，用 SVN 這樣的集中式版本控制系統其實還算過得去。檢出、修改、提交這些操作都很簡單。雖然分支和合併做得不怎麼樣，但很多時候我們都能繞過去（說實話，我不確定自己是否真的在 Subversion 或 Perforce 里用過分支）。

說實話，現在人們抱怨 Git 的次數可能比當年抱怨 SVN 的還要多——畢竟，SVN 的用戶界面和操作邏輯比 Git 要簡單直觀。

我覺得當時最大的問題並不在於那些封閉、團隊之間相互信任的專業開發環境。真正的挑戰在於那個不斷壯大的開源世界。

你可能不知道，開源在那時候毫不起眼，尤其是跟今天比起來。現在的人們可能都不記得開源項目還沒那麼多的時候，「開源」 這個詞直到 1998 年才被正式提出來。

為了讓大家有直觀感受，2008 年，Dirk Riehle 發表了一篇論文，分析了全球開源項目的趨勢。他估計那時候全球大概有 18 000 個活躍的開源項目。想想看，2005 年的時候，這個數字肯定還要更小。

開源項目總數。摘自 2008 年 Amit Deshpande 和 Dirk Riehle 出版的《The Total Growth of Open Source》

比較一下，現在光是 GitHub 上就有超過 2.8 億個公共代碼庫。

那麼，為什麼開源的興起會推動 Git 和 GitHub 的流行呢？

主要是因為開源社區在快速擴張，而集中式版本控制系統在處理開放貢獻方面表現得很糟糕。簡單來說，就是它們不擅長公開分享項目，也不擅長輕鬆地把外部的貢獻整合進來。這對於開源項目來說，是個大問題。

1. 2005年的開源貢獻  

真的有那麼糟糕嗎？

通常是這樣的，你可以讓你的 Subversion 服務器對未認證用戶設置為只讀，這通常是託管開源項目的方式（或者你會偶爾把一個壓縮包放在某個地方）。

如果你想要貢獻代碼，基本流程是這樣的：

• 拉取最新版本

• 進行修改

• 通過 GNU diff 工具生成補丁文件

• 將該補丁文件上傳到項目使用的工單系統或郵件列表中

接著，維護者需要：

• 下載補丁文件

• 應用到項目上，看看是否應用成功/工作正常

• 然後提供反饋、做出修改，或者提交更改

現在網絡上仍然可以看到這種流程的遺留痕跡。我曾在某個項目中使用 Trac 系統，你依然可以找到他們的 「提交補丁」 指南以及建議更改的示例。

這簡直就是一場噩夢。

Rails 項目和我的那幫朋友們——也就是後來的 GitHub 聯合創始人們——在 Err 公司用了一個叫做 Lighthouse 的工單系統，讓人驚訝的是，它居然還在運行。我早期的一個開源項目是一個命令行工具，叫做 git-lighthouse，它的功能是簡化從工單中下載和應用補丁的過程。

這個過程實在是太糟糕了，所以當有個工具能夠簡化這個過程時，大家都迫不及待地用上了。這個工具就是 GitHub。不過，在這之前，我們得先有 Git。

2. Git的崛起  

Git 的誕生其實有點戲劇性，Linux 內核大佬 Linus Torvalds 當時特別喜歡一個商業的版本控制系統，叫做 BitKeeper。這個系統本來是為了簡化內核開發流程設計的。

如果 BitKeeper 是開源的，或者它的許可條款更友好一些，可能就不會有 Git 或者 GitHub 了。

但事情就這麼巧。有個 Linux 開發者違反了許可條款，反向工程破解了 BitKeeper 的協議。這搞得 BitKeeper 和 Linus 都很不爽，最後決定分道揚鑣。

於是，Linus 就結合了 BitKeeper 的一些好想法，自己搞了個工具，他覺得這個工具能解決問題。他還開玩笑地叫它 「來自地獄的信息管理器」，並將這個項目命名為 Git。

Git 很快就在 Linux 社區里火了起來，有幾個人覺得這個項目不錯，慢慢地，Git 就發展成了一個真正的版本控制系統。

當時 Git 之所以受到歡迎，有這幾個原因：

• 分支和合併不再是噩夢，而是夢想

• 它速度飛快

• 權限管理變得非常簡單

Git 剛出來那會兒，我做過一些現場演示，就是那種一邊講一邊操作的。我會現場創建幾個分支，提交一些更改，然後在這些分支之間切換，最後再合併。整個過程一氣嗬成，60 秒搞掂。我還記得，當時真的有人看得目瞪口呆，甚至有人懷疑我是不是作假了。

想想看，2006 年的時候，能這麼快、這麼輕鬆地切換和合併代碼，真的就像魔術一樣。相比之下，在 Subversion 里做這些，簡直就是一場噩夢。

不用跟中央服務器來回協商就能提交代碼，這感覺就像是在開火箭，一切都快得飛起。

可能最關鍵的是，你可以輕鬆地 fork 代碼庫，這意味著你可以自己託管一個副本，擁有寫的權限，在自己的分支里提交更改，別人也可以輕鬆地把這些更改拉到他們的 fork 里。Linux 項目很早就開始這麼做了——對於較大的更改，他們可以請求 Linus 從他們託管的分支里拉取更改，而 Linus 做起來也是輕而易舉。

實際上，如果你好奇 「拉取請求（Pull Request）」 這個詞是怎麼來的，答案就在這裏。Git 里有個 git request-pull 命令，它會幫你格式化一封郵件，發送到郵件列表，簡化這個過程。當 GitHub 加上這個功能後，我們決定就叫它 「拉取請求」。

有些人覺得開發者喜歡 Git 是因為它分佈式的特性，複製時能拿到整個歷史記錄，這樣你就可以在本地做各種操作等。但我不這麼認為。分佈式之所以酷，主要是因為操作快，你可以輕鬆地託管自己的完整可寫 fork，權限管理變得超級簡單。

確實，這種變化讓貢獻變得更簡單了。不再是 「誰有權限推送」，而是 「誰有有趣的內容可以拉取」，這種轉變直接推動了 GitHub 的誕生。

3. GitHub的崛起  

去年年底，我與我的 GitHub 合夥人 Tom 進行了詳談。我們聊了好多，他講述了他最初是如何萌生開發 GitHub 的想法的。

當時他在 Powerset 工作，團隊開始用 Git。但是，因為 Git 主要用 SSH 協議，給每個人設置 SSH 權限太麻煩了。大多數人覺得這事情不值得費心。這個痛點讓 Tom 有了靈感：得讓這事情變得簡單點。

Git 是挺棒的，但託管 Git 卻很麻煩。這就是 Tom 開始開發 GitHub 的原因。

我翻了翻舊郵件，想看看我第一次聽說 Tom 的 「GitHub」 項目是什麼時候。發現是 Chris 在 2007 年底回覆我 Git 影片教程的郵件。

那時候，GitHub 還是 Tom 和 Chris 的秘密項目（還有 Chris…… 為什麼 「h」 是小寫？），我開始和 Chris、Tom 聊 Git/Ruby 庫和網站的事，慢慢也就參與進來了，最後加入了公司。

這個項目有幾件有趣的事情。

首先，他們把 GitHub 和當時唯一一個真正的公共 Git 託管站 repo.or.cz 作了比較。但 GitHub 做了個關鍵的創新，就是它以用戶為中心，而不是以項目為中心。以前在 Sourceforge 之類的地方託管項目，你得搶注名字。而在 GitHub，你可以隨便給項目起名字，因為它是按用戶命名空間劃分的。

其次，他們關注的是 「拉取」 模型，而不是 「推送」 模型（這跟我之前說的權限問題有關）。

第三，「不醜」 也是一大賣點。GitHub 的設計很有品味。

二、Git的勝利

Git 一開始之所以受歡迎，是因為它的設計理念和功能都很強大，而 GitHub 的創建則是為了讓 Git 更加易於使用。但問題是，為什麼 Git 最終能在眾多分佈式版本控制系統（DVCS）中脫穎而出呢？當時有很多類似的工具，比如 Mercurial，在很多方面和 Git 很像，甚至在某些方面做得更好。那麼，為什麼在這場 DVCS 的競爭中，Git 笑到了最後？

我認為答案是 「PR」。

在 「為什麼 Git 勝出」 這個問題上，有兩個非常強大的公關力量在起作用。首先是 Linux，可以說是 Linus 本人。其次是 GitHub，尤其是 Rails 社區。

1. 也許是Linus/Linux  

Linux 項目選擇了 Git，而且還是 Linus 發起的，這直接給了 Git 一個權威背書。

大家都知道 Linux，也都知道 Linus。如果他能搞出一個幾乎人人都在用的優秀操作系統（至少在服務器領域是這樣，而且每年都有人說明年就是桌面 Linux 的時代），那他肯定也能開發出一個頂尖的版本控制系統。就算 Git 一開始用著有點難，那也只能說明他比我們聰明，我們得多花點功夫學學，對吧？

2007 年的時候，有一個關於 Git 的在線講座，當時 Linus 在 Google 園區里講 Git 和 DVCS，那時候這還是個全新的概念。

影片發佈的時候，正好是我剛開始用 Git（2005 年底）和我加入 GitHub（2008 年中）之間的那段時間。我看了好幾遍，肯定還有幾百萬人也看過。誰不想聽 Linux 的大神在 Google 說 「CVS 是有史以來最傻的東西，不同意的人都是又醜又蠢」 呢？

這是一個很棒的公關活動。

而且，如果你把 Linux 和 Linus 等同起來（大多數人確實這麼認為），那可以說，Linux 通過 Android 間接地也推動了 Git 的普及。

在推動 Git 普及這方面，有時候真的很難說，是我或者 GitHub 的努力，還是 Android 成為趨勢背後的這種巨大而低調的幕後推動力，二者哪個影響更大。畢竟，我自己多年來也一直在做 Git 的演講和企業培訓。

2008 年 9 月初，就在 Android 1.0 發佈前夕（大約是這封郵件發出兩週後，也是在我做培訓之前），Git 生態系統的早期英雄之一 Shawn Pearce 給我發了封郵件，邀請我幫忙培訓 Google Android 團隊使用 Git。

雖然很難精確衡量 Android 在推動企業採用 Git 方面的作用，但它的影響肯定不是零。Google/Android 團隊是我以 GitHub 名義做的第一個企業培訓對象，後來我還為電單車羅拉、高通、愛立信和博通等電信公司的工程團隊做了 Git 培訓。這還是在我們雇了全職團隊專門來做這些培訓之前的事。

Linus 用他那廣泛的超級極客公關效應推動了 Git，這種影響力是 Mercurial 從未獲得過的。而 Android 通過它對 Linux 內核的依賴，進一步獨特地推動了 Git 的傳播，讓它進入了大量企業，這些企業原本可能至少在十年內都不會採用 Git。

2. 也許是GitHub

帶著一點謙虛和希望，我得說，GitHub 很可能是讓 Git 最終戰勝 Mercurial 的關鍵。

GitHub 真的很幸運，因為我們有一個非常支持我們、也很中場的社區——Ruby 社區。從一開始，Ruby 社區就全力支持我們。沒幾個月，Ruby 社區的每個人都把他們的項目搬到了 GitHub 上。那時候，Rails 是非常火的技術，比 PHP 更酷，JS 框架還沒出現，也沒有 Node 這些技術。

所以，大家都在關注 Ruby 社區那些潮流開發者的動態，因為他們是軟件世界里最前沿的開發者，而他們都在用 GitHub。

不只是我這麼看，Linus 最近也說，從他的角度來看，Ruby 社區讓 Git 一夜之間意外地火了。他雖然沒有直接提到 GitHub，但我覺得沒人能否認，Ruby 社區沒有採用 Git，很大程度上是因為 GitHub 的存在。

通過一些推測和推理，我敢大膽地說，Linus 實際上認為 GitHub 是讓 Git 取勝的原因。

當然，Ruby 社區的採用 GitHub 並非偶然。

我記得我們幾個——Chris、Tom、PJ 和我——在 Ruby 會議上和 Ruby 社區的早期成員們坐在一起，向他們展示 GitHub，介紹 Git，做演講。我們一起演講，之後還會在舊金山的 Ruby 聚會上一起喝啤酒。這些人是 Rails、Heroku、Twitter、jQuery 等項目的創始人。

我們並不是在 「推銷」 GitHub，而是在分享我們真正熱愛的東西。這個社區非常信任彼此，GitHub 的創始人也是這個社區的深度且真誠的成員，我們都在嘗試彼此的項目並互相支持。

Ruby 社區使用 GitHub 意味著每場會議的演講都會提到 GitHub。這種免費宣傳無處不在。隨著越來越多的項目遷移到 GitHub 或者直接在 GitHub 上啟動，即使是那些喜歡 Mercurial 的人也沒有太多選擇，最終他們不得不轉向 Git。一段時間後，繼續使用 Mercurial 就變得不太值得了。GitHub 在託管領域的主導地位在短短幾年內就超越了 Mercurial。

在 Mercurial 那邊，有 BitBucket，它是專門為 Mercurial 託管設計的，是用 Django 框架寫的。但我覺得我們起步早，優勢大，而且它們也沒做出足夠的差異化。Python 社區也沒有像 Ruby 社區那樣積極地採用它。

早在 2008 年 12 月，GitHub 就已經託管了大約 27 000 個公共倉庫，而 BitBucket 只有 1 000 多一點。要追上我們確實挺難的。

你可能會好奇我怎麼記得這些數字。其實，我當時建了個網站叫 whygitisbetterthanx.com，有個叫 Jesper 的人給我發郵件，說我網站上有個錯誤——我當時的論點是，Git 有 GitHub，而 Mercurial 和 Bazaar 沒有類似的託管平台。我當時挺傲慢地回他說，它們根本不是一個量級的。

很高興 Jesper 並沒有因為我的回應而生氣，現在想起來我那時候語氣確實有點衝。但最後證明，Jesper 其實是 BitBucket 的創始人。這真的很尷尬。

大概一年後，我們在阿姆斯特丹見了面，一起喝了幾杯威士忌，從那以後我們就一直保持著友好的關係。

3. 競爭對手的消失  

最後，不管是 GitHub 幫了 Git 一把，還是 Git 幫了 GitHub 一把，這場競爭很快就有了結果。

2006年到2007 年的時候，大家開始認識到分佈式版本控制系統的好處，Git 和 Mercurial 也開始了正面交鋒。

2008 年，GitHub 正式登場。

到了 2011 年，Google Code 和 BitBucket 都開始支持 Git，我覺得這差不多就是給 Mercurial 敲響了喪鍾。Git 贏得了這場戰爭，GitHub 也變得幾乎無人能敵。

僅僅 4 年後，2015 年，Google Code 徹底退出了歷史舞台，關閉了服務。他們甚至在郵件里建議大家直接轉移到 GitHub。如果我沒記錯的話，他們還聯繫了我們，尋求幫助進行遷移服務。

三、那麼，為什麼不是 Google Code 勝出呢？

這是個好問題。儘管 BitBucket 是在我們之後啟動的，我們有一些正選優勢。不過，在我們之前也有其他託管網站。那麼，為什麼它們沒有勝出呢？

2009 年初，Google Code 增加了 Mercurial 支持，Sourceforge 也增加了 Git 和 Mercurial 支持。因此，如果這些行業巨頭擁有用戶群優勢，並在我們上線幾個月後就支持了 DVCS，為什麼他們沒有擊敗我們這些小公司？

2009 年初，Google Code 開始支持 Mercurial，Sourceforge 也開始支持 Git 和 Mercurial。這些行業巨頭擁有用戶群優勢，而且我們剛上線沒幾個月他們就支持 DVCS 了，怎麼就沒把我們這個小團隊比下去呢？

我們不僅小，還沒什麼錢。Chris 當時拿出了一點錢來啟動公司（如果我沒記錯的話），其他人包括我都是兩手空空，我們也沒有籌集到任何外部資金。

Google Code 增加 Mercurial 支持時，我們四個開發者還在南海灘的咖啡館里敲代碼呢，連風險投資都沒有。我們與 Engine Yard 的夥伴達成了協議（2008 年 5 月），他們幫我們支付託管費，因為我們是真的沒錢。

那我們這個又小又沒錢的團隊是怎麼在幾年內讓 Google Code 這樣的大團隊倒下的呢？

1. GitHub 有品味  

上面提到了，其他託管平台關注的是分發和賺錢。我們關注的是開發者。問題不在於他們什麼時候支持 Git，那不重要。他們不懂什麼是品味，也不關心開發者的工作流程。他們可以加 Git 支持，但我覺得即使加了，最後也會失敗。

這不僅僅是功能或 「增值服務」 的問題，對於今天的初創公司來說，真正有價值的核心經驗比活動提要或個人頁面這些功能更根本。我覺得我們做的最根本的事情是：我們為自己而構建。我們有品味，我們在乎用戶體驗。

我們都是開發者，我們做的是我們自己想要的工具，支持我們理想中的工作方式。我們是唯一一個為開發者而不是為賺錢優化的工具，沒有產品經理、會計師或 CEO 在那兒想著怎麼利潤最大化，我們真正關心的是開發者體驗。

最後我們贏了，因為開源社區開始轉向分佈式版本控制系統，而我們是唯一真正關心開發者工作方式的託管平台。我們是唯一質疑現狀、從第一性原理出發、嘗試整體改進體驗的平台，而不是僅僅在現有基礎上加更多功能來銷售。

四、總結

總結一下，我們之所以能贏，是因為我們抓住了時機，而且我們的產品有品味。我們站在了新範式的前沿，並且我們是以開發者體驗為核心來幫助大家接受這個新範式的，這點別人都沒做到。

那麼問題來了，下一個改變開發者工作流的大變革會是什麼？誰又會有那種品味，讓它能像 GitHub 那樣一炮而紅呢？

本文來自微信公眾號：AI大模型實驗室，作者：李木子