GitHub 的“封神”之路！

摘要： 編者按：本文來自微信公眾號 “CSDN”（ID：CSDNnews） ，作者：Hiten Shah，譯者：安翔。36氪經授權轉載。 2008年，在無數人為程式碼協作方式而感到異常頭疼的時候，GitHub 橫空出世，完美契合了市場的迫切需求。自此，它以驚人的速度成長起來並蔓延到全世界...

編者按：本文來自微信公眾號 ofollow,noindex">“CSDN”（ID：CSDNnews） ，作者：Hiten Shah，譯者：安翔。36氪經授權轉載。

2008年，在無數人為程式碼協作方式而感到異常頭疼的時候，GitHub 橫空出世，完美契合了市場的迫切需求。自此，它以驚人的速度成長起來並蔓延到全世界，徹底融入開發程式設計的日常之中。僅僅十年，現在的 GitHub 已經成為開源的事實標準，左右著無數開發者的程式設計命脈。本文就從最開始的地方，一起來追溯 GitHub 的“封神”之路。

2008年，Tom Preston-Werner、Chris Wanstrath 和 PJ Hyett 三位摯友聚在一起，準備合作開發一個週末小專案。但是沒過多久，他們便意識到這個想法可能比他們預想的要大得多。他們的想法遠不止一個週末小專案那麼簡單，它將徹底改變人們編寫程式碼和分享程式碼的方式。

這個想法就是 GitHub。

在短短10年間，GitHub 便徹底改變了人們的編碼方式。GitHub 不僅讓編碼變得容易，它還改變了軟體開發人員對程式設計的看法和理解。

世界範圍內，無數的人都在為程式碼協作方式感到頭疼，GitHub 橫空出世，解決了這個疑難問題，並設計出了市場迫切需要的優雅解決方案。以此，它得以驚人的速度發展壯大，取得了巨大的成功。通過圍繞開源專案 Git 構建 SaaS 服務，GitHub 能夠為開源生態系統提供價值並從中獲利。GitHub 對微軟來說充滿吸引力，儘管微軟曾經在開源社群並不顯眼，但它在2018年6月初對 GitHub 進行了收購。

我們一起來看看下列問題：

• GitHub 如何從一個版本控制系統發展為程式員的社交工具，並最終成為線上存放和管理程式碼的重要場所？

• 為什麼 GitHub 的免費增值模式執行良好，並且能夠如此有效地引領時代？

• GitHub 如何抓住了廣闊的潛在市場需求，並圍繞這種需求創造了一種剛需產品？

為了更好地理解 GitHub 的重要性，我們需要回到2008，瞭解當時的軟體開發現狀，以及是什麼造就了偉大的 GitHub。

2007-2011：程式碼協作與軟體社交

比爾蓋茨和史蒂夫喬布斯從根本上重塑了個人計算機，他們成為家喻戶曉的名人，但我們也完全無法忽視芬蘭軟體工程師 Linus Torvalds 對科技領域的巨大貢獻，他創造了 Linux 作業系統。當時的 Windows 和 Mac 幾乎統治了整個作業系統領域，Linux 作業系統於1991年釋出，它是一個非常靈活、輕量級和安全的開源作業系統，面世之後，很快就受到了想要對系統進行深入控制的極客以及技術人員的青睞。

發明一個全新的作業系統這樣的成就可能對大多數程式設計師來說都應該感到知足了，但 Torvalds 卻並不滿足，他沒有停下創新的腳步。2005年，Torvalds 推出了他的最新專案：一個名為 Git 的新的版本控制系統。版本控制對程式設計協作來說至關重要，它需要跟蹤計算機中隨時間變化的檔案。它與計算機備份系統用作還原點的“快照”類似，版本控制系統讓程式設計師能夠通過“fork”或者“分支”來管理專案程式碼，程式設計師在同一個專案工作，但不會影響其他人編寫的程式碼。程式設計師可以在自己的分支上進行開發，之後將新的程式碼合併到主專案（也就是程式碼倉庫）中。

在 Git 誕生之前，程式設計師之間進行程式設計協作的方式很少。其中 Subversion 比較受歡迎，它是一個開源的版本控制系統。它存在著與其他版本控制系統類似的缺點，當然這些缺點是當時的協作程式設計概念所無法避免的。即使使用了Subversion，與開源團隊合作通常也需要獲得專案管理員的許可才能 fork 專案的一個分支，否則便無法編輯程式碼。在許多情況下，批准過程比編寫程式碼花費的時間更長。許多開源專案都受到許可權問題以及其它一些低效率事情的困擾。

當 Git 於2005年釋出時，開源領域正在經歷一場文藝復興。那時的開發者對 Linux 充滿濃烈的興趣。第一個 Web 2.0 應用程式已經開始出現。許多公司正在將他們的專案遷移到開源伺服器。儘管 Git 通過引入 fork 概念使得開源專案的合作變得容易，但 Git 依然有其侷限：它無法幫助開發人員尋找開源專案。許多程式員開發了大量的優秀開源專案，但卻很難讓他人知道這些專案。

GitHub 改變了這一切。

PJ Hyett 和 Chris Wanstrath 在2007年開始討論 GitHub 專案，當時這兩人都是科技網站 CNET 的程式設計師。他們都支援 Ruby on Rails 開發框架。當他們在 CNET 工作時，Hyett 和 Wanstrath 還為 Rails 的程式碼庫提出了一些改進和建議。但是，讓其他人真正檢視他們的程式碼是另一回事。

正如當時大多數開源專案的典型情況一樣，Rails 的程式碼庫由一個小型的、緊密結合的程式設計師管理，他們手動管理對程式碼庫的貢獻。這些程式設計師扮演者管理員的角色。Hyett 和 Wanstrath 不僅要請求這些管理員檢視他們的程式碼，還要讓他們相信自己提交的程式碼對 Rails 專案是有價值的。即使其中一個專案管理員認為提交的程式碼有用，但是補丁的合併也不會很容易。

從本質上講，想要為 Rails 專案貢獻程式碼，熟人的爛程式碼比陌生人的好程式碼更容易通過。

Git 試圖解決其中的一些問題。Linus Torvalds 的版本控制系統與他幾年前單槍匹馬打造的作業系統一樣出色。Git 使得程式設計師無需管理員開通訪問許可權，即可進行編碼協作。Git 是編碼最終民主化的關鍵第一步，特別是在開源社群。但是，儘管 Git 解決了很多問題，但它缺乏協作工具，並且兩個程式設計師之間共享程式碼仍然很笨拙和困難。現在可能很難想象，當時軟體開發人員需要通過電子郵件不斷來回傳送補丁，這就很容易理解為什麼迫切需要 GitHub。

遺憾的是，這不是 Git 唯一需要的東西。起初 Git 主要依賴於命令列介面，好在 Git 釋出後很快就推出了圖形介面。對於那些多年來一直在編寫 bash 指令碼和正則表示式的系統管理員和其他高階使用者來說，這是個好訊息。對於其他人來說感覺倒並不明顯。

“人們開始在 Ruby 會議上談論 Git。主要討論它的好處，但有時也談到缺點。Git 會以分散式方式處理程式碼，但是如何保證共享私有程式碼的安全性呢？唯一的選擇是在 Unix 計算機上設定使用者帳戶並將其用作臨時解決方案。這個解決方案並不理想。” — Tom Preston-Werner

儘管存在這些缺點，但 Git 依然充滿潛力，它給來自灣區的 Ruby 程式設計師 Tom Preston-Werner 來了一些想法。當時 Preston-Werner 正在開發一個名為 Grit 的專案，這個工具讓程式設計師能夠使用 Ruby on Rails 以面向物件的方式訪問 Git 儲存庫。Preston-Werner 在舊金山一家名為 zeke's 的體育酒吧內舉辦的 Ruby 會議上認識了 Chris Wanstrath，Preston-Werner 把 Grit 告訴了 Wanstrath。

Preston-Werner 的願景是建立一個可以託管整個程式碼庫的地方，程式設計師可以協同工作程式碼專案，並瞭解如何充分利用 Git。用 Preston-Werner 的話說，它將是一個“ Git hub（中心）”。

Preston-Werner 和 Wanstrath 於2007年10月1日正式開始製作 GitHub 的第一個版本。在舊金山體育酒吧相識的幾周之後，Chris Wanstrath 提交了第一個 GitHub 版本，從此便徹底改變了程式設計方式。

當 Preston-Werner 和 Wanstrath 在2007年開始合作時，他們的想法不是將 GitHub 作為商業工具開發並圍繞它開展業務。Wanstrath 和 Preston-Werner 需要 GitHub 來完成他們自己的工作，所以他們開發這個工具是為了滿足自己的剛需。他們很快就發現了他們工作中的一個主要問題：他們需要 fork 程式碼分支和協作程式設計，並設計出滿足他們需求的解決方案。對於這個 Wanstrath 和 Preston-Werner遇到的問題，無論使用哪種程式語言或者作業系統，幾乎所有軟體開發人員都會遇到。這代表了他們的產品在未來擁有巨大的市場潛力。

在接下來的幾周裡，Wanstrath 在週末與 Preston-Werner 會面，共同完成了 GitHub 的第一次迭代。Preston-Werner 主要負責設計，Wanstrath 專注於實現 Preston-Werner 提出的功能。

“在接下來的三個月裡，Chris 和我花了很多時間來規劃和編寫 GitHub。平時我繼續為 Grit 設計 UI。Chris 構建 Rails 應用程式。我們每個星期六都會見面討論設計，並規劃這個產品的藍圖。” — Tom Preston-Werner

2008年1月，經過三個月利用週末時間編寫程式碼，GitHub 有點像模像樣了，Wanstrath 和 Preston-Werner 準備向全世界推出 GitHub。正如 Spotify 在其關鍵的早期開發階段所做的那樣，GitHub 首次以私有測試版的形式推出。Wanstrath 和 Preston-Werner 通過向他們在灣區及其他地區的初創公司的朋友傳送電子郵件，邀請他們使用他們構建的工具，之後便立即得到了積極的迴應。接下來的一個月，他們將 Logical Awesome 改名為 GitHub，Inc，並作為公司正式成立。

雖然這兩個人還沒有開始創業，但他們的想法蘊含巨大的商業潛力。2008年4月，就在 GitHub 推出私有測試版並在同月推出其官方網站的三個月後，Chris Wanstrath 收到了來自線上學習網站 PeepCode 的創始人 Geoffrey Grosenbach 的訊息，該網站剛剛將其程式碼遷移到了 GitHub。Grosenbach 告訴 Wanstrath 他不習慣使用 GitHub 免費託管他公司的程式碼庫，他願意付費。來自活躍的 GitHub 使用者的這類訊息展現了 GitHub 的價值。即使 GitHub 沒有向用戶收費，有些人也願意為此付費。

“我使用 GitHub 免費託管我公司的程式碼，我對此感到有些不好意思。我可以發一張支票給你們嗎？” - PeepCode 的創始人 Geoffrey Grosenbach

GitHub 發展中最重要的一個因素是其商業模式的簡潔和優雅。如果你想公開託管你的程式碼，GitHub 可以永久免費使用。如果你想使用私有儲存庫或專有程式碼，你需要付費。這兩個用例完全不同，這消除了 GitHub 使用免費增值產品蠶食其受眾的風險。

GitHub 公司完全可以將 GitHub 置於付費模式，並且可以通過收費來賺很多錢，但事實上 GitHub 並沒有這麼做。GitHub 商業模式的另一個特點就是無縫從免費增值產品過渡到私人付費儲存庫。如果程式設計師在 GitHub 上託管他們的開源個人專案並定期使用該產品，他們很有可能會建議他們在日常工作中使用 GitHub。

與 GitHub 的商業模式一樣簡單和合乎邏輯，它是 GitHub 以其實現方式有效商業化開源軟體開發的唯一可能方式。如果 GitHub 從一開始就試圖從所有儲存庫中獲利，那麼 GitHub 可能永遠不會被開源社群所喜愛。如果沒有這種基層支援，該公司將無法生存。

另一個需要採用智慧方法定價結構的因素是將 GitHub 作為 Web 服務運營。作為開原始碼在網路上存放的地方這聽起來很棒，但有人必須為頻寬付費。對於 GitHub 來說幸運的是，Geoffrey Grosenbach 並不是唯一一個想要給 GitHub 捐款的熱心使用者。一些公司還提出願意花錢使用 GitHub 來託管他們的程式碼，這讓公司的創始人意識到該公司作為營利性企業的潛力非常巨大。

“我們意識到 GitHub 可能不僅僅是能夠收回成本，它可能成為一項真正的商業。我們決定繼續免費提供無限制的公共儲存庫，但我們會向私有儲存庫收取費用。換句話說，我們會向該付錢的人收錢。” - Chris Wanstrath

PJ Hyett 於2008年1月正式加入 GitHub，成為其第三位聯合創始人。僅僅幾個月後，即2008年4月10日，GitHub 正式推出。

到2009年，GitHub 的增長十分迅猛。Preston-Werner 在2009年2月的雅虎開發者大會上發表講話時說，GitHub 上有超過46,000個公共儲存庫，其中約有17,000個在上個月才加入。當 Preston-Werner 在2009年7月發表他的下一個雅虎開發者大會演講時，GitHub 已經擁有超過10萬用戶，並且託管了超過90,000個公共儲存庫，僅僅5個月就增加了95%。

GitHub 這一時期的增長最令人矚目的是，這家新興公司在短短一年多的時間裡通過軟體開發社群的口碑吸引了其首批100,000名使用者。GitHub 作為一種產品已經造就了很好的使用者粘性，這純粹是因為它確實解決了開發者的疑難問題。這有別於其它基於 Git 的協作工具。GitHub 通過在新興的、難以使用的技術之上構建了新服務，成功地開闢了自己的市場。

GitHub 的業務模型和程式設計社群的流行確實幫助公司取得了快速的發展。然而，許多人忽略了 GitHub 早期的一個方面，即如何解決所有軟體開發人員遇到的問題，這些問題的解決也推動了 GitHub 作為產品的開發。協作是關鍵，訪問是增長的載體。GitHub 允許使用者在未經許可的情況下 fork 儲存庫，從而減少了衝突。GitHub 解決一個棘手的技術問題，即 fork 程式碼分支和相關的許可權問題，此外，GitHub 還解決了如何與其他程式設計師有效協作的問題。

市場對 GitHub 這類產品的迫切需求以及產品本身的粘性並不是 GitHub 早期取得快速增長的唯一因素。GitHub 的社交功能也是增長的強大動力。在 GitHub 之前，除了在技術訪談中回答白板假設之外，程式設計師幾乎沒有辦法證明他們的程式設計方法。現在，編碼人員可以公開維護他們專案的程式碼庫，向未來的僱主展示他們的程式碼，並參與更廣泛的軟體開發社群。GitHub 不僅使程式設計師受益。招聘人員可以通過 GitHub 瀏覽公共儲存庫和使用者檔案，以確定潛在的候選人，看看候選人一直在做什麼樣的專案，這使得 GitHub 成為了一個頗有價值的招聘工具。

2010年6月29日，GitHub 推出了其組織功能，該功能允許企業使用者從單個集中式儀表盤管理其擁有的儲存庫。雖然組織的引入一定程度上是對那些吵著要嘗試 GitHub 的公司的迴應，但它也揭示了公司未來的抱負。到2010年，創始人很清楚，收入增長的最重要的一個原因是更多企業和組織採用 GitHub。這發生在 GitHub 推出 GitHub Enterprise 一年以前，組織功能清楚地表明瞭公司的意圖。

GitHub 繼續以令人難以置信的速度不斷吸引新的使用者。截至2011年底，GitHub 正在託管超過200萬個儲存庫，並且在使用者和提交方面都超過了 SourceForge、Google Code 以及微軟的 CodePlex。與之前的組織功能一樣，GitHub Enterprise 的釋出表明 GitHub 意圖成為大型科技公司和個人開發者不可或缺的平臺，這是 GitHub 在2012年至2015年間的主要目標。

令人驚訝的是，GitHub 沒有藉助一分錢的外部投資就成功壯大。這將在2012年發生變化，當時 GitHub 終於迎來了它的第一個投資者 Andreessen Horowitz。

2012-2015：從快速增長到無處不在

到2012年，GitHub 已經變得非常受歡迎。對於許多程式設計師來說，問題不在於他們在何處使用 GitHub，而是用它來做什麼。GitHub 不僅穩定地吸引了強大的使用者群，幾乎沒有廣告、促銷或者風險投資資金，但使用 GitHub 託管私有程式碼和私有儲存庫的公司團隊數量劇增。GitHub 現在需要做的是通過進一步滲透到企業來擴大收入。GitHub 實現這一目標的第一件事就是僱用 Brian Doll，他於2012年2月成為 GitHub 的市場營銷和戰略副總裁。第二件事是由 Andreessen Horowitz 領導的 A 輪融資籌集1億美元。

“具體來說，有一個名為'GitHub Everywhere'的策略。我們希望軟體領域的所有人都使用 GitHub。個人、小團隊、學生以及大型企業。” — Tom Preston-Werner

GitHub 的A輪融資讓這家成長中的公司更加積極地追求“GitHub Everywhere”的願景。當 GitHub 獲得A輪融資時，它已經擁有超過170萬用戶並且託管了超過300萬的儲存庫。此外，該公司的收入自2008年以來每年以300%的速度增長。憑藉其新的資金，GitHub 可以在這種有機增長的基礎上繼續發展，並瞄準財富500強公司，這將推動 GitHub 收入的進一步增長。

雖然許多企業家和投資者對 GitHub 與 Andreessen Horowitz 的新合作關係表示讚賞，但一些人對 GitHub 突然湧入的現金表示懷疑。開源社群的一個小而有聲的隊伍覺得 GitHub 接受風險投資資金是對公司自我激勵的風格的背叛，並可能危及未來的開源開發。GitHub 的開源起源及其未來作為企業工具之間的緊張關係需要公司進行仔細平衡。

獲得歷史上最大的A輪融資給了 GitHub 更大的自由，但它也給公司施加了更大的壓力。

到2012年，GitHub 的成長速度令人矚目。GitHub 已經建立了一個可以解決緊急問題的可靠產品，並圍繞一項新興技術建立了一個完整的公司。但很明顯，GitHub 自給自足的方式只能將它帶到目前的高度。為了保持公司的成長速度並實現更大的目標，它需要資金。於是 GitHub 在2012年7月獲得了 Andreessen Horowitz 1億美元的A輪融資，Andreessen Horowitz 是唯一的投資者。GitHub 將利用這筆資金聘請更優秀的工程師並開發新的產品。

值得注意的是，雖然 GitHub 在A輪融資中完全被 Andreessen Horowitz 引導，但這並不是意識形態衝突的問題。有些人認為 GitHub 起源於開源社群，這與投資者青睞的創業方式不太一致。但實際情況並非如此。GitHub 沒有原則上拒絕風險投資，它拒絕的原因確實是因為它不需要投資。當 GitHub 開始尋找外部投資時，該產品已經擁有了龐大的使用者群。最重要的是，GitHub 幾乎從第1天開始就實現了盈利。這種自由使得 GitHub 不僅能夠有意識地塑造其產品，還能夠塑造整個組織的文化，完全不受投資者的影響。

“我們始終認為過早地獲得投資對公司來說是壞事。太多的外界影響可能是危險的。我們已經誕生四年半了，所以我們能夠真正定義自己。我們從來沒有拒絕 VC，我們只是排斥人們因為錯誤的因素委屈自己的產品。” — Tom Preston-Werner

從這一點來看，GitHub 的巨集圖大志愈發明顯。GitHub 已經取得了顯著的增長並積累了大批忠實的程式設計師粉絲，因此它希望擴大其影響力及其潛在收入。GitHub A 輪融資的關鍵並不是拿到了投資者的大筆資金，GitHub 在接受風險資金之前已經盈利了多年。其關鍵在於 Preston-Werner 的下面這段話：

“我們公司多年來一直盈利，增長迅速，我們並不需要錢。那為什麼我們接受了投資呢？因為我們想要更好，我們想要打造最好的產品，我們想要解決更難的問題，我們希望讓更多人的生活變得更加輕鬆。Andreessen Horowitz 的經驗和資源可以幫助我們做到這一點。” — Tom Preston-Werner

Preston-Werner 提到了很多目標，但歸根結底都是想要讓 GitHub 解決核心技術問題。這是許多人對 GitHub 作為公司和產品的最根本的誤解之一。GitHub 讓程式設計師的生活更加輕鬆，這一點毋庸置疑，但這並不是創始人的唯一願景。他們不僅想讓程式設計師更容易編碼，他們還希望讓整個程式設計領域都變得更加容易和輕鬆。

在許多情況下，GitHub 已經解決了程式設計本身的疑難問題。GitHub 的特別之處在於它通過創造一種解決了這些問題的產品來實現這一目標，這些問題也為該產品創造了巨大的潛在市場。Wanstrath 和他的朋友可以專注於較小的、特定的技術問題。相反，他們追求的是當時程式設計所帶來的大問題和根本固有的問題，解決這些問題為他們的產品創造了巨大的潛在市場。

這種吸引力遠遠超出了開源愛好者的預期，它對大型企業也具有強大的吸引力。到2013年，矽谷的大多數科技公司都在使用 GitHub，大大小小的專案都在用。Adobe、Dropbox、Facebook、Google、Twitter 等等，它們都在 GitHub 上擁有私有儲存庫。一些公司，比如 Mozilla，甚至擁有幾百個程式碼倉庫，幾乎所有東西都託管在 GitHub 上。其它的公司，比如 Facebook，擁有的儲存庫相對少一些（與 Mozilla 的687只相比只有102個），但參與度確更高，Facebook 的102個儲存庫中的分支超過15,000個。

GitHub 的受歡迎程度和市場滲透率讓它獲得了難以置信的增長。截至2015年底，GitHub 擁有280萬用戶，並擁有460萬個儲存庫。然而，雖然 GitHub 現在已經與編碼文化密不可分，但該公司的目標設定得更高。下一階段 GitHub 的目標是成為全球最大的開源軟體中心，並積極尋求國際擴張，立志成為“面向開發者的 Facebook”。

GitHub 不僅在慢慢吞噬矽谷，它甚至和美國政府有些交集。2013年5月9日，白宮在 GitHub 上起草併發布了美國官方開放資料政策。這是美國第一次以這種方式分享聯邦立法政策。雖然這與 GitHub 的數百萬個儲存庫中託管的程式碼專案相比，立法檔案本身的實用性有限，但其象徵性非常重要。在私營公司的伺服器上託管政府政策檔案是前所未見的，允許公眾 fork 和合並政策檔案也是前無古人的。

今天的新聞標誌著政府首次將法律作為一份生動的協作檔案釋出。我們很高興看到開放資料政策隨著社群的投入而發展，我們希望這是一個良好的開始。“ - GitHub 產品經理 Ben Balter

該公告對於 GitHub 而言是一個令人難以置信的 PR，並且還暗示了 GitHub 的其他潛在用例，開放資料擁護者和精通技術的政策多年來一直在談論，即使這些用例最終將永遠不會實現。

2015年至今：GitHub 全球擴張

到2015年，GitHub 是許多程式設計師的版本控制工具。但它並不僅限於此，它還是一個社交中心，程式設計師可以從中互相學習。它是程式設計師交流網站、社交網路和專業網路中心。這是世界上大部分程式碼的存放處，既有個人開發者的小專案，也有科技巨頭的大型專案。 

當然，樹大招風。2015年3月28日，GitHub 經歷了自發布以來最大規模的網路攻擊——這種DDoS（分散式拒絕服務攻擊）攻擊被認為源於中國。但這次襲擊並非企圖使一家美國公司癱瘓，以造福亞洲競爭對手。相反，據稱該攻擊僅針對兩個 GitHub 專案。第一個是 GreatFire，一個致力於幫助中國網際網路使用者規避國家所謂的“中國防火牆”的組織；第二個是“紐約時報”網站中文映象的 GitHub 頁面，它也幫助中國使用者訪問這張報紙。儘管攻擊最終受到了挫敗，但人們發現在一個地方託管如此多程式碼的危險性，特別是旨在顛覆國家監視裝置的程式碼。

中國 DDoS 攻擊發生四個月後，GitHub 獲得了以紅杉資本為首的2.5億美元B輪融資。這使得 GitHub 的估值超過了20億美元。談到資金問題，Chris Wanstrath 告訴記者，該公司計劃利用其B輪資金開發新產品，並進行國際化擴張。

GitHub 的第一個海外辦事處設在東京。GitHub 選擇日本作為其首個海外地點具有高度的戰略性。日本不僅是 GDP 排名世界第三的經濟體，而且其技術創新舉世聞名，這使其成為旨在託管世界程式碼的網站的合理的目的地。包括日立系統和日本媒體集團 CyberAgent 在內的公司都是日本 GitHub 的首批客戶。

GitHub 繼續擴大。截至2015年7月，GitHub 擁有超過900萬用戶，並託管了超過2100萬個儲存庫，這正式使 GitHub 成為世界上最大的程式碼儲存庫。儘管使用者增長穩定，該公司的繼續擴張推動了該組織在此期間的大部分收入增長。GitHub 被美國一半以上最大、最富有的公司所使用，這是很好地體現了 Tom Preston-Werner 多年前“ GitHub Everywhere” 的先見之明。

然而，儘管 GitHub 仍在增長，到2015 年9月每個工作日新增使用者數達到10,000，但增長速度在放緩。GitHub 面臨來自 Bitbucket 和 GitLab 的激烈競爭，導致使用者增長受到影響。另一方面，收入則增長迅速。2015年9月，GitHub 的年度收入約為9000萬美元。截至2016年8月，這一數字已上升至1.4億美元。在2014年9月至2016年8月的23個月期間，GitHub 個人計劃的收入停滯不前，但其組織計劃的收入幾乎翻了一番。GitHub Enterprise 的收入增長了兩倍。2014年9月，GitHub 的收入中約有35%來自 GitHub Enterprise。截至2016年8月，GitHub Enterprise 佔GitHub 收入的一半。

到2017年，GitHub 的未來將主要受其在企業應用程式的影響。曾有人談論過首次公開募股，有關不太可能收購的傳聞，以及合併等等。每個人都有關於 GitHub下一步行動的猜測，但很少有人料到接下來發生的事情。在2018年6月4日上午， 微軟以75億美元的價格收購了 GitHub ，這一重磅訊息震驚了科技界。 

“從最大的公司到最小的初創公司，GitHub 是開發人員學習、分享和共同建立軟體的目的地。它也是微軟的目的地。我們是 GitHub 上最活躍的組織，為專案提供了超過200萬次“提交”或更新。

幾個小時之內，黑客新聞、Reddit 和 TechDirt 充斥著憤怒的使用者，他們感到被 GitHub 的收購所背叛，許多抗議會離開 GitHub。一些使用者將他們的儲存庫從 GitHub 遷移到競爭服務 GitLab 或 Bitbucket。人們對他們的程式碼的安全性開玩笑。其他人明智地瞭解了 Clippy 將如何幫助開發人員將他們的專案部署到Azure。還有一些人認為這筆交易與甲骨文收購 Sun 有相似之處。

在諷刺和憤怒之下，有一種非常真實的感覺，GitHub 的未來不再像以前那樣光明。然而，許多人沒有意識到的是，在這一點上，微軟收購 GitHub 對 GitHub 產品的負面影響非常小。GitHub 十年來一直是協作軟體開發的行業標準。Bitbucket和 GitLab 將不可避免地獲得一些逃離微軟 GitHub 的使用者，但 GitHub 在行業中的地位以及 GitHub 作為產品本身的功能實際上保證了 GitHub 的持續相關性、生存和增長。

此外，微軟豐富的企業經驗可以使 GitHub 成為微軟的高度戰略資產，特別是因為該公司將自己定位為開發人員的平臺和市場。對於微軟而言，收購 GitHub 並不是要將 GitHub 作為一種產品獲取，而是要獲得 GitHub 帶來的開發者生態系統。

網上喋喋不休的大部分內容似乎都圍繞著微軟收購 GitHub 是否聰明，真正的問題應該是微軟是否會巧妙地使用 GitHub。正如微軟收購 LinkedIn 和 Minecraft 開發商 Mojang 所表明的那樣，微軟可能不一定會徹底改變 GitHub 所做的事情，至少，不會馬上改變。

GitHub 未來何去何從？

現在微軟是全球最大和最受歡迎的程式碼庫的新擁有者，GitHub 的未來發展軌跡將完全取決於微軟如何將 GitHub 視為其長期增長戰略的一部分。

1. 與 Visual Studio 整合

雖然微軟可以做出許多潛在的舉動，但現在它擁有 GitHub，GitHub 與微軟極受歡迎的開發工具套件 Visual Studio 的整合幾乎是不可避免的。這符合微軟的長期計劃，即從 Windows 的銷售業務轉向其不斷髮展的基於雲的服務生態系統。

2. 更多開發者工具

即便在現在，程式設計仍然存在效率低下的問題。GitHub 可以採取的最合理的舉措之一就是開發其他工具來幫助開發人員專注於解決諸如錯誤跟蹤和將應用程式部署到 Microsoft Azure 等問題，甚至可以用 AI 驅動的應用程式替換當前的 QA 工作流程。GitHub 幾乎沒有觸及可能的表面，微軟重新關注其基於雲的開發者生態系統似乎與 GitHub 作為產品的潛力完全一致。

3. 吸引開發者的產品和服務

除了軟體工程師之外，GitHub 已經吸引了大量的專業人士，例如產品經理。GitHub 的另一個潛在舉措可能是引入了對這些專業人士有吸引力的其他特性和功能，例如整合的專案管理工具。鑑於微軟希望大力發展企業應用程式和基於團隊的協作工具，這使得可能性大增。

GitHub 的啟示

GitHub 如今已經找到了一個新家，但它仍然有大量的經驗值得我們學習。

1. 找到一個需要解決的大問題

讓 Git 更容易使用是 GitHub 的目標，但這並不是最終目標。GitHub 真正的願景是使協作和編寫軟體更容易。世界上每個軟體開發人員都在努力解決 GitHub 試圖解決的問題。這創造了一個巨大的潛在市場，GitHub 對自己的定位非常準確。

看看你當前的產品並問自己以下問題：

• 你的產品是否解決了一小群人遇到的非常具體的問題？或者它是否解決了很多人遇到的大而廣泛的問題？專業化可以成為一個強大的差異化因素，但解決大型問題可以為你的產品提供更大的潛在市場。

• 你是否或者願意在日常工作中使用自己的產品嗎？

• 如果你不使用自己的產品，那麼原因是什麼呢？你的產品是否存在問題，或者你的產品聲稱要解決的問題是否會與自己相關？這兩種情況都是嚴重的問題。在內部不使用你自己的產品會引發產品是否真正被使用者需要的疑問。如果你沒有親身體驗過你的產品所解決的問題，那麼是什麼讓你成為解決問題的合適公司？

2. 不斷解決使用者痛點

GitHub 推動這種令人難以置信的增長的部分原因是該公司不僅致力於解決疑難問題，而且還致力於解決所有軟體開發人員遇到的痛苦問題。這為 GitHub 創造了巨大的潛在使用者群，並使公司從根本上重塑了我們所知道的軟體開發方式。

想想你的產品及其在公司運營範圍更廣的領域，然後問問自己：

• 如果你能夠以某種方式為現有產品新增全新的功能，那麼該功能將會是什麼，以及它將解決哪些問題？

• 為什麼你的產品或開發中沒有此功能？這太難了還是太寬泛？你怎麼能克服這些障礙來實現這個功能？

• 你試圖解決的問題的痛點所在？這是技術問題還是人為問題？

GitHub 之所以成功，是因為它解決了一個技術問題：開發者需要一個更好、更直觀的版本控制系統，它具有解決人類問題的巨大潛力，即輕鬆、安全和遠端協作軟體專案。專注於技術問題也讓 GitHub 解決了人類問題，這是 GitHub 成功的一個非常重要的因素。

3. 儘早培養企業文化

即使在早期，GitHub 也認識到了企業文化的重要性。公司刻意並積極地創造自己的文化，而不是讓文化自由生長。與傳統觀念相反，文化不僅僅是行為的偶然副產品，它是經過深思熟慮、有意識的行動和有目的的決策的結果。文化是任何公司成長的關鍵因素。

看看你自己的公司，並考慮以下問題：

• 你公司的文化如何反應價值觀？即使在早期，GitHub 也非常高興地從傳統的企業成功概念中汲取樂趣，採用相對扁平的管理結構。公司的文化對你有什麼價值和品牌屬性？

• 你的員工在多大程度上塑造了公司的文化？換句話說，公司的政策有多少是由自上而下決定的，而且隨著時間的推移，由於你的僱傭而有機地出現了多少？

• 你的競爭對手如何看待你的公司和產品？這種看法有多少會基於你組織的文化？

後記

GitHub 通過做兩件事來取得了難以置信的成功：解決一個巨大的使用者痛點；並建立一個流行的、具有粘性的產品，使人們更容易一起工作和共享程式碼。GitHub 現在面臨的最大挑戰是設計一種方法來進一步將程式設計融入其它技術學科，同時吸引軟體開發人員以外的專業人士。

鑑於微軟曾對開源社群的敵意，它可能不是 GitHub 最合理的歸宿。但是微軟具有相當大的企業專業知識和前瞻思維的領導力，這對於 GitHub 來說有些許安慰。現在大家關心的問題是，微軟將如何利用 GitHub 這個利器，讓它變得更加閃耀。

相關連結：https://medium.com/@hnshah/how-github-democratized-coding-built-a-2-billion-business-and-found-a-new-home-at-microsoft-bd94d2dea2a9 ，作者：Hiten Shah，他建立了多個 SaaS 專案，比如 Crazy Egg、KISSmetrics 和FYI。 譯者安翔，責編郭芮。