深度復盤GitHub發展史：如何在短短10年內改變了人們的編程方式？

前不久，微軟以 75 億美元的價格收購 GitHub，引發了科技行業的關注。在短短的 10 年內，GitHub 改變了人們的編程方式。 不僅讓編程變得更簡單，還改變了軟件開發者對編程的看法。GitHub 是如何做到的呢？我們能從中學到什么？日前，ProductHabits 發表了一篇文章，深入研究了 Slack 的發展史，呈現了 Slack 獲取成功的種種因素。

2008 年，當湯姆·普雷斯頓-沃納(Tom Preston-Werner)、克里斯·萬斯特拉斯(Chris Wanstrath)和 PJ·海伊特(PJ Hyett)合作完成一個項目的時候，他們只是把它當做一個周末項目，僅此而已。 但沒過多久，他們就意識到，他們的想法可能比自己所設想的要大得多，將遠遠超過一個周末項目的范疇: 它將改變人們編寫和分享代碼的方式。

這個想法就是 GitHub。

在短短的 10 年里，GitHub 改變了人們的編程方式。 不僅讓編程變得更簡單，還改變了軟件開發者對編程的看法。

GitHub 找到了全世界數百萬人正在努力解決的一個大問題——如何在代碼上協作——并設計出了市場急需的、優雅的解決方案，實現了令人難以置信的增長和成功。通過圍繞開源項目 Git 構建 SaaS 服務，GitHub 為開源生態系統提供價值并從中獲利。

讓我們來深入了解：

• GitHub 是如何增長和發展的，它是如何從版本控制系統到程序員的效率工具，最后到代碼托管的地方的？

• 為什么 GitHub 的免費增值模型如此有效，能夠有效地驅動免費用戶轉化付費用戶？

• GitHub 如何在一個巨大的潛在市場中找到一個迫切的需求，并圍繞這個需求創造出了一個幾乎不可或缺的產品？

想要理解為什么 GitHub 如此重要，我們必須要回顧一下 2008 年的時候軟件開發環境是什么樣的，以及是什么讓 GitHub 的想法在當時和現在都非常出色。

2007-2011 年：代碼能夠協作，軟件能夠社會化

比爾·蓋茨（Bill Gates）和史蒂夫·喬布斯（Steve Jobs）通過從根本上重塑個人計算機而成為家喻戶曉的人物，但如果沒有創建 Linux 操作系統的芬蘭軟件工程師林納斯·托瓦茲（Linus Torvalds）的貢獻，很難想象現在的技術會發展成什么樣子。1991 年，Linux 發布的時候，挑戰了 Windows / Mac“二分天下”的格局，為用戶提供了一種非常靈活、輕量級、并且安全的開源操作系統，很快就受到了那些想對系統進行更多控制的硬核極客和技術人員的青睞。

對于一些人來說，發明一種全新的操作系統可能就已經足夠了，但對托瓦茲來說卻不是這樣。2005 年，托瓦茲公布了他的最新項目——一個名為 Git 的新的版本控制系統。版本控制對于協作編程的概念至關重要。版本控制系統能跟蹤隨著時間推移計算機文件發生的更改。與計算機備份系統用作還原點的“快照”類似，版本控制系統允許程序員通過“分叉”將項目的版本分成不同的“分支”，來跟蹤項目的每個分支的變化，從而實現多人在同一項目上工作，而不會相互影響。一旦有人對分支進行了更改，它們就可以上傳回原始項目并與原始項目合并，這一過程稱為“提交”。這個系統允許程序員在將他們的文件合并回被稱為存儲庫的主項目之前，在他們自己的分支上獨立工作。

GitHub 的分叉是如何工作的。

在 Git 出現之前，想要與其他程序員協作的程序員根本沒有多少選擇。他們通常會使用一個開源的版本控制系統 Subversion。雖然 Subversion 過去和現在都很流行，但和其他特定的版本控制系統一樣，Subversion 也有缺點。可以說，這些缺點是當時的協作編程概念所固有的。即使使用 Subversion，與開源團隊一起工作也往往需要獲得項目管理員的許可，才能對項目進行分叉，而不是處理代碼本身。在許多情況下，這個批準過程比編寫代碼花費的時間都要長。許多開源項目都會受到權限問題、網關問題和其他低效問題的困擾。

2005 年，在 Git 發布的時候，開源正經歷著一場復興。人們對 Linux 的興趣非常強烈。第一個 Web 2.0 應用程序已經出現。許多公司將其技術堆棧遷移到開源服務器上。盡管 Git 通過引入分叉的概念使得在開源項目上的協作基本上不會耗費力氣，但 Git 做不到的是：幫助程序員找到那些開源項目。很多程序員都在研究大量令人興奮的開源項目，但很難找到它們。

GitHub 將會改變這一切。

當 PJ·海伊特和克里斯·萬斯特拉斯在 2007 年開始談論最終成為 GitHub 的事情時，兩人都是技術網站 CNET 的程序員。他們都支持 Ruby on Rails 開發框架。在 CNET 工作的時候，海伊特和萬斯特拉斯對 Rails 本身的代碼庫提出了一些改進和建議。但是，讓任何人都能查看到他們的代碼是另一回事。

與當時大多數開源項目的情況一樣，Rails 的代碼庫由一個小型、組織緊密的代碼編寫團隊管理，他們手動管理對代碼庫的貢獻。這些程序員實際上是看守門人。海伊特和萬斯特拉斯不僅要請求這些守門人查看他們的代碼，還要讓他們相信這是值得加入到 Rails 項目的。即使其中一個項目守門人發現代碼建議很有用，實際上合并補丁也不是那么簡單。

從本質上講，對 Rails 項目的貢獻在于你認識誰，而不是你知道什么。

Git 試圖解決其中的一些問題。林納斯·托瓦茲的版本控制系統與他幾年前獨自構建的操作系統一樣出色。Git 允許程序員在不需要請求網關訪問的情況下進行協作。Git 是最終實現編碼民主化的關鍵，也是第一步，尤其是在開源社區。但是，盡管使用 Git 看上去很輕松，但它缺乏協作工具，兩個程序員之間共享代碼仍然很困難。現在可能很難想象，但在當時，圖片軟件開發者需要通過電子郵件來來回回發送補丁，這就能更容易地理解為什么程序員迫切需要一個 GitHub 了。

不幸的是，這并不是 Git 唯一需要的東西。Git 發布后不久，第一個圖形用戶界面就出現了，但 Git 主要依賴命令行界面。對于系統管理員和其他多年來一直在編寫 bash 腳本和正則表達式的高級用戶來說，這是一個好消息。對于其他人呢？好處并沒有那么多。

“人們開始在 Ruby 聚會上談論 Git。說它多么優秀。 但是，有些地方不太對勁。 Git 本應該是以分布式的方式處理代碼的方式，但是安全共享私人代碼的機制是什么呢？ 你唯一的選擇就是在 Unix 計算機上設置用戶賬戶，并把它作為一個臨時的解決方案。 這并不太理想。”

——湯姆·普雷斯頓-沃納

盡管有這些缺點，Git 的潛力還是給了海灣地區的 Ruby 程序員湯姆·普雷斯頓-沃納一個想法。當時，普雷斯頓-沃納正在進行一個名為 Grit 的項目，這是一個允許程序員使用 Ruby on Rails 以面向對象的方式訪問 Git 存儲庫的工具。普雷斯頓-沃納第一次見到克里斯·萬斯特拉斯是在舊金山的一家體育酒吧 Zeke，當時那里舉辦了一個“I Can Has Ruby”的程序員聚會。萬斯特拉斯和普雷斯頓-沃納經過熟人介紹相互認識，普雷斯頓-沃納跟萬斯特拉斯分享了有關 Grit 的事情。

普雷斯頓-沃納的愿景是創建一個可以托管整個代碼庫的地方，程序員可以在那里合作開發代碼項目，并了解如何最大限度地利用 Git。 用普雷斯頓-沃納的話來說，這將是一個“Git hub”。

2007 年 10 月 1 日，普雷斯頓-沃納和萬斯特拉斯開始正式開發 GitHub 的第一個版本。他們永遠改變了編程。

普雷斯頓-沃納和萬斯特拉斯在 2007 年開始合作時，并沒有打算把 GitHub 發展成一種商業工具，也沒有打算圍繞它開展業務。普雷斯頓-沃納和萬斯特拉斯需要 GitHub 來完成他們自己的工作，他們開發這個工具是出于必要。很快，他們就發現了工作中的一個主要問題——將代碼分叉和在編程項目上協作——并設計了一個滿足他們需求的解決方案。普雷斯頓-沃納和萬斯特拉斯解決方案的亮點在于，每個軟件開發者，無論他們使用什么樣的編程語言、什么樣的操作系統以及從事什么樣的“工種”，都會遇到這些重大問題。這代表了，他們的產品具有一個巨大的潛在市場。

在接下來的幾個星期里，萬斯特拉斯周末的時候都會與普雷斯頓-沃納碰面。共同完成了 GitHub 的第一個迭代。普雷斯頓-沃納負責設計，萬斯特拉斯則專注于實現普雷斯頓-沃納提出的功能。

“在接下來的三個月時間里，克里斯和我花了大量的時間設計和開發 GitHub。我一直堅持設計了用戶界面。克里斯開發了 Rails 應用程序。我們每個星期六都會碰面，做出設計決定，試圖弄清楚我們的計劃到底是什么樣子。”

——湯姆·普雷斯頓-沃納

2008 年 1 月，經過長達三個月的周末編程沖刺、在餐巾上畫線框圖和通宵工作，萬斯特拉提和普雷斯頓沃納準備向世界揭開 GitHub 的面紗。正如 Spotify 在早期開發階段所做的那樣，GitHub 最初是作為一個私人測試版發布的。萬斯特拉斯和普雷斯頓-沃納通過電子郵件向他們在海灣地區之外的創業公司的朋友們發送了郵件，邀請他們嘗試他們一直在開發的工具。得到的反應非常積極。接下來的一個月，GitHub 誕生，此前公司的名稱是 Logical Awesome。

雖然兩人并沒有開始創業，但他們這個想法的商業潛力很早就出現了。2008 年 4 月，就在 GitHub 在私人試用版上推出 3 個月后，也就是在 GitHub 推出官方網站的同一個月，克里斯·萬斯特拉斯收到了在線學習網站 PeepCode 創始人杰弗里·格羅森巴赫（Geoffrey Grosenbach）發來的一條消息，他剛剛將代碼遷移到了 GitHub。格羅森巴赫告訴萬斯特拉斯，他不太愿意用 GitHub 免費托管公司的代碼庫。活躍的 GitHub 用戶發出這樣的消息表明了公司所提供的價值。盡管公司沒有向他們收費，但人們還是想付錢。

“我在這里托管我們公司的代碼。不付錢給你們我不舒服。我可以寄張支票過來嗎？”

——杰弗里·格羅森巴赫，PeepCode 創始人

GitHub 增長的最重要因素之一就是它的商業模式的非常簡潔和優雅。如果你想公開托管你的代碼，你可以一直免費地使用 GitHub。如果你想使用私有存儲庫或專有的代碼托管服務，你需要付費。這兩個用例完全不同，這消除了 GitHub 用免費增值產品蠶食其受眾的風險。

他們本來可以很容易將 GitHub 隔離在付費墻或者訂閱模式后面，并可能在這個過程中賺不少錢，但他們沒有。GitHub 的商業模式中另一個非常出色的元素是，從免費增值產品到私人付費存儲庫的過渡是無障礙的。如果程序員在 GitHub 上托管他們個人的開源項目，并定期使用該產品，那么他們很有可能會在日常工作中推薦使用 GitHub。

和 GitHub 簡單而合理的商業模型一樣，這是 GitHub 能夠有效地將開源軟件開發商業化的唯一方式。如果 GitHub 從一開始就試圖將所有存儲庫商業化，那么 GitHub 可能永遠不會受到開源社區的喜愛。沒有這種基層的支持，公司就無法生存下去。

另一個需要對定價結構采取明智做法的因素是將 GitHub 作為 Web 服務運行的現實。作為開源代碼在 Web 上托管的地方，聽起來很棒——但總得有人為帶寬買單。幸運的是，杰弗里·格羅森巴赫并不是唯一一個熱心的 GitHub 早期采用者。還有幾家公司還提出向 GitHub 付費來托管代碼，這使得公司創始人對公司的盈利潛力有了進一步的推測。

“在這個時候，我們意識到，GitHub 可能不僅僅是收回成本。這可能是一個真正的生意。我們決定繼續免費提供無限量的公共存儲庫，但我們會對私人存儲庫收費。換句話說，我們會向要求收費的人收費。”

——克里斯·萬斯特拉斯

PJ·海伊特于 2008 年 1 月正式加入 GitHub，成為其第三位聯合創始人。僅僅幾個月后，也就是 2008 年 4 月 10 日，GitHub 正式推出。

到 2009 年，GitHub 的增長速度越來越快。普雷斯頓-沃納在 2009 年 2 月雅虎開發者大會上發言時告訴與會者，GitHub 上有超過 46000 個公共儲存庫，其中僅前一個月就增加了大約 17000 個儲存庫。普雷斯頓-沃納在參加 2009 年 7 月舉行的雅虎開發者大會時，GitHub 已經擁有 10 多萬用戶，托管了 9 萬多個公共存儲庫——僅在 5 個月內就增長了 95 %。

GitHub 這段成長時期最引人注目的是，這家新生的公司在短短一年多的時間里，通過軟件開發社區的口碑，就成功吸引了首批的 10 萬用戶。GitHub 作為一個產品已經非常具有黏性，純粹是因為它解決了問題。并不像是有其他基于 Git 的協作工具。GitHub 通過在一種新興的、難以使用的技術上建立一種新的服務，有效地創造了自己的市場。

GitHub 的“二進制”商業模式和在編程社區中的受歡迎程度，肯定有助于公司的快速成長。然而，GitHub 早期被許多人忽視的一個方面是，如何解決所有軟件開發人員遇到的重大問題，也推動了 GitHub 作為一種產品的開發。協作是關鍵，獲取用戶是增長的載體。通過解決一個困難的技術問題——代碼分叉和相關的權限問題——GitHub 也解決了同樣困難但令人沮喪的問題，即如何與其他程序員有效協作。

市場對 GitHub 這樣的產品的迫切需求，和產品本身的粘性并不是 GitHub 早期快速增長的唯一因素。GitHub 在社交方面的影響，也是其增長的強大推動力。在 GitHub 之前，程序員除了在技術訪談中回答白板假設之外，沒有什么方法能證明他們的編程能力。現在，程序員可以公開托管他們項目的代碼庫，實際上向潛在雇主展示他們的代碼，并參與更廣泛的軟件開發社區，所有的這些都在一個地方。GitHub 不只是讓個別程序員受益。招聘人員可以瀏覽公共資料庫和用戶檔案，以確定潛在的招聘人員，并查看求職者正在從事的項目類型，從而使 GitHub 成為一個有價值的招聘工具。

2010 年 6 月 29 日，GitHub 推出了 Organizations 功能，這是一個允許企業用戶集中管理組織擁有的存儲庫的工具。雖然引入企業組織在一定程度上是為了響應那些要求嘗試 GitHub 的公司，并使其盡可能無障礙地采用 GitHub，但它也揭示了公司未來的雄心。到 2010 年，創始人清楚地看到，收入增長最重要的載體，將是推動企業和組織層面采用 GitHub。GitHub 將在一年多后推出 GitHub Enterprise，但 Organizations 清楚地表明了公司的意圖。

GitHub 繼續吸引著大量的用戶加入。截至 2011 年底，GitHub 已經托管了 200 多萬個存儲庫，在用戶和提交方面都超過了 SourceForge、Google Code 和微軟的 CodePlex。與之前的 Organizations 一樣，GitHub Enterprise 的發布也傳達了該公司的意圖，即成為大型科技公司和個人程序員不可或缺的地方，這是該公司在 2012 年至 2015 年間積極推進的戰略方向。

令人驚訝的是，GitHub 是在沒有獲得外部投資的情況下，快速地擴大了規模。這將在 2012 年發生改變，GitHub 屆時將迎來它的第一個投資者安德雷森·霍洛維茨（Andreessen Horowitz）。

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

到 2012 年，GitHub 已經變得非常受歡迎。對于許多程序員來說，問題不是他們是否使用 GitHub，而是他們使用 GitHub 來干什么。GitHub 不僅在幾乎沒有廣告、促銷或進行風險投資的情況下吸引了強大的用戶群體，而且還增加了使用 GitHub 托管私有代碼庫的公司團隊的數量。GitHub 現在需要做的是通過進一步吸引企業客戶來擴大收入。GitHub 做到這一點的第一件事是聘請布萊恩·多爾（Brian Doll），他于 2012 年 2 月成為 GitHub 的營銷和戰略副總裁。第二件事是完成了安德雷森·霍洛維茨領投的 1 億美元A輪融資。

具體來說，我們有一個“GitHub 無處不在”的戰略。 我們希望軟件開發過程中的每個人都會使用 GitHub。不論是個人、小團隊、學生，還是大型企業。

——湯姆·普雷斯頓-沃納

GitHub 的A輪融資，讓這家仍在成長中的公司能夠更積極地追求“GitHub 無處不在”的愿景。截至 GitHub 進行A輪融資的時候，它擁有超過 170 萬用戶，托管了超過 300 萬個存儲庫。此外，自 2008 年以來，該公司的收入一直以每年 300% 的速度增長。有了新的資金，GitHub 可以在這種有機增長的基礎上再接再厲，瞄準財富 500 強公司，這將推動 GitHub 的收入繼續增長。

盡管許多企業家和投資者對 GitHub 與安德雷森·霍洛維茨的新伙伴關系表示稱贊，但一些人對 GitHub 突然注入資金表示懷疑。開放源碼社區中一個小規模但直言不諱的團隊認為，GitHub 接受風險投資資金是對公司自力更生精神的背叛，并會危及未來開源代碼的開發。GitHub 作為開源代碼的源地與它作為企業工具的未來之間的關系很緊張，長期以來都是這家成長中的公司需要平衡的地方。

雖然 GitHub 在接受了A輪融資之后，有了更多的自由，但它也給這家尋求雙重身份平衡的公司帶來了更大的壓力。

到 2012 年，GitHub 的增長令人矚目。該公司創造了一個解決緊迫問題的堅實產品，并圍繞一項新興技術建立了一個完整的公司。但很明顯，GitHub 的自發式增長方式只能幫它走到現在這個位置。為了保持公司的發展勢頭，實現更大膽的目標，它需要資金。這筆資金來自于安德雷森·霍洛維茨，GitHub 在 2012 年 7 月進行了 1 億美元的A輪融資，安德雷森·霍洛維茨是唯一的投資者。GitHub 將利用這筆資金雇用更多的工程人才并開發新產品。

值得注意的是，盡管在安德雷森·霍洛維茨進行投資之前，GitHub 已經完全啟動，但這并不是觀念沖突的問題。一些人認為，GitHub 起源于開源社區，這使得該公司與投資者青睞的專有的圍墻花園模式格格不入。事實并非如此。GitHub 并沒有在原則上拒絕風險投資融資；它在啟動的時候拒絕風險投資基金，是因為它不需要。當 GitHub 開始尋找外部投資時，產品已經有了很大的用戶群體。最重要的是，GitHub 從第一天就開始盈利了。這種自由使 GitHub 不僅可以有意地塑造產品，還可以完全不受投資者的影響，塑造整個組織的文化。

“我們仍然認為，過早拿太多錢對一家公司的發展來說是不好的。過多的外部影響可能是危險的。我們現在已經成立四年半了，所以我們有機會真正地定義自己。我們從來沒有反對過風險投資，我們只是（反對）人們因為錯誤的原因而損害他們的產品。”

——湯姆·普雷斯頓-沃納

此時，GitHub 的增長雄心正變得越來越清晰。GitHub 已經實現了顯著的增長，并積累了大量忠誠的程序員“福音”傳播者，它希望擴大它的覆蓋面和潛在的收入。GitHub 完成A輪融資的有趣之處不在于投資者或籌集的資金總額，也不是 GitHub 作為一個已經盈利的業務，等了四年才接受風險投資。最有趣的是在 GitHub 的A輪融資聲明中普雷斯頓-沃納使用的語言。

“我們公司多年來一直盈利，發展迅速，不需要錢。那為什么還要融資呢？因為我們想變得更好。我們要打造最好的產品。我們想解決更棘手的問題。我們希望讓更多人的生活更輕松。安德雷森·霍洛維茨的經驗和資源可以幫助我們做到這一點。”

——湯姆·普雷斯頓-沃納

普雷斯頓-沃納的聲明中使用了很多連接詞，但他真正想要傳達的是 GitHub 正在努力解決的編碼技術問題。這是許多人對 GitHub 作為公司和產品的最基本誤解之一。毫無疑問，GitHub 讓程序員的生活變得更輕松，但這不是創始人的意圖。他們不只是想讓程序員的編碼變得更容易——他們想讓編碼本身變得更容易。

在許多情況下，GitHub 已經解決了編程本身所面臨的一些大而雄心勃勃的問題。GitHub 最大的亮點在于，它創造了一個解決這些問題的產品，同時也為該產品創造了巨大的潛在市場。萬斯特拉斯和他的朋友們本可以專注于更小、更具體的技術問題。相反，他們解決的是當時編程所固有的非常重大且非常基礎的問題，以至于解決這些問題為他們的產品創造了巨大的潛在市場。

這種吸引力遠遠超出了開源愛好者和腳本小孩在他們臥室里的黑客行為。 它對大公司也具有強大的吸引力。 到 2013 年，硅谷大部分大型科技公司都在使用 GitHub，從小型的 skunkworks 項目到主要的專有系統。 Adobe、 Dropbox、 非死book、 谷歌、 推ter ——他們都在 GitHub 上有私人存儲庫。 一些公司，比如 Mozilla，擁有數百個存儲庫，幾乎所有的東西都在 GitHub 上托管。 其他公司，比如 非死book，擁有的存儲庫要少得多(只有 102 個，相比之下，Mozilla 有 687 個) ，但參與度卻要高得多，非死book 102 個存儲庫中有超過 15000 個分叉。

GitHub 的知名度和市場滲透率推動著公司快速增長。截至 2015 年底，GitHub 擁有 280 萬用戶，托管著 460 萬個存儲庫。然而，盡管 GitHub 現在已經與編碼文化密不可分地交織在一起，但公司的目標更高了。在 GitHub 下一個發展階段，它將把自己定位為世界上最大的開源軟件中心，積極尋求國際擴張，并尋求成為“開發者的 非死book”。

GitHub 不僅僅在慢慢吞噬硅谷，它也蔓延到了華盛頓的政府領域。2013 年 5 月 9 日，白宮在 GitHub 上發布了美國官方的“公開數據政策”（Open Data Policy）草案。與 GitHub 上百萬個存儲庫中托管的代碼項目相比，文件本身的效用有限，但它具有非常重要的象征意義。在私人公司的服務器上對外托管政府政策文件是聞所未聞的。

“今天的新聞標志著一個政府實體首次將法律作為一個活生生的合作文件發布。我們很高興看到開放數據政策是如何隨著社區的投入而演變的，我們希望這只是眾多政策中的第一個。”

——本·巴爾特（Ben Balter），GitHub 產品經理

這對 GitHub 來說，是一次令人難以置信的免費公關，它還暗示了開放數據倡導者和精通技術的政策專家多年來一直在談論的 GitHub 的其他潛在用例——哪怕這些用例永遠不會實現。

2015 年至今: 全球擴張，GitHub 被微軟收購

到 2015 年，GitHub 成為許多程序員進行版本控制的首選項。不僅如此：它還是一個社交中心，程序員可以相互學習。它是程序員聚集的網站、社交網絡和專業網絡中心。世界上大部分代碼都托管在這里，從獨立程序員運行的零碎開源項目到為世界上一些最先進的技術公司提供動力的龐大的代碼庫。

當然，你的規模越大，你的目標也就越大。2015 年 3 月 28 日，GitHub 經受了自推出以來最大規模的網絡攻擊。

在遭受 DDoS 攻擊四個月后，GitHub 完成了由紅杉資本領投的 2.5 億美元B輪融資。這使得 GitHub 的估值超過了 20 億美元。談到資金問題，克里斯·萬斯特拉斯告訴記者，公司計劃利用B輪融資獲得資金進行重大投資，開發新產品，最重要的是拓展國際市場。

GitHub 的第一個海外辦事處設立在了東京。GitHub 選擇日本作為其第一個海外地點具有高度的戰略意義。以 GDP 計算，日本不僅是全球第三大經濟體，而且以技術創新聞名。包括日立系統(Hitachi Systems)和日本綜合媒體 CyberAgent 在內的許多公司都是 GitHub 日本第一批客戶。

GitHub 繼續擴張。截至 2015 年 7 月，GitHub 擁有 900 多萬用戶，托管了 2100 多萬個存儲庫，GitHub 成為世界上最大的代碼存儲庫。盡管用戶增長趨于穩定，但公司持續拓展企業業務，使公司的收入獲得了增長。在美國，超過一半的最大、最富有的公司都在使用 GitHub，這體現了湯姆·普雷斯頓-沃納多年前提出“GitHub 無處不在”戰略的先見之明。

不過，盡管 GitHub 仍在增長——截至 2015 年 9 月，每個工作日新增 1 萬個用戶——但增長速度正在放緩。GitHub 面臨來自 Bitbucket 和 GitLab 的激烈競爭，用戶增長受到影響。但另一方面，收入正在迅速增長。2015 年 9 月，GitHub 的年度經常性收入( ARR )約為 9000 萬美元。截至 2016 年 8 月，這一數字已增至 1.4 億美元。在 2014 年 9 月至 2016 年 8 月的 23 個月期間，GitHub 個人計劃的收入停滯不前，但其企業計劃的收入幾乎翻了一番。來自 GitHub Enterprise 的收入增加了兩倍。2014 年 9 月，GitHub 的 ARR 約有 35 %來自 GitHub Enterprise。截至 2016 年 8 月，GitHub Enterprise 已占 GitHub ARR 的一半。

很顯然，到 2017 年，GitHub 的未來將由它在企業中的應用決定。關于公司 IPO、被收購、合并的傳言四起。每個人都對 GitHub 下一步的行動有自己的看法——但很少有人能夠看到接下來會發生什么。2018 年 6 月 4 日上午，科技領域對微軟以 75 億美元收購 GitHub 的消息震驚了。

“從大型企業到小的創業公司，GitHub 是開發者學習、分享和合作創建軟件的首選地。它也是微軟的首選地。我們是 GitHub 上最活躍的組織，對項目進行了 200 多萬次‘提交’或更新。”

幾個小時之內，Hacker News、 Reddit 以及 TechDirt 上充斥著憤怒的用戶，他們覺得 GitHub 被收購背叛了他們。 許多人表示要離開 GitHub 以示抗議。 一些用戶表示，他們已經開始從 GitHub 遷移到 GitLab 或 Bitbucket 等競爭性的服務上了。 人們對他們代碼的安全性開了一些玩笑。 其他人則對 Clippy 將如何幫助開發人員將他們的項目部署到 Azure 進行了明智的分析。 還有一些人將這筆交易與 2009 年甲骨文收購 MySQL 的交易進行了比較。

在諷刺和憤怒的背后，有一種非常真實的感覺，GitHub 的未來不再像以前那么光明了。但是，很多人沒有意識到的是，在這個時候，微軟收購 GitHub，對 GitHub 作為一個產品來說，并不會有什么明顯的負面影響。GitHub 十年來一直是協作軟件開發的行業標準。Bitbucket 和 GitLab 不可避免地會獲得一些逃離微軟 GitHub 的用戶，但是 GitHub 在行業中的地位以及 GitHub 作為產品本身的功能實際上保證了 GitHub 的相關性、生存和增長。

此外，微軟豐富的企業經驗可能會使 GitHub 成為微軟的一項極具戰略意義的資產，特別是微軟將自己定位為開發者的平臺，并專注于開發者市場的時候。對微軟來說，收購 GitHub 并不是要把 GitHub 作為一種產品，而是要收購 GitHub 帶來的開發者生態系統。

網上的大部分討論基本上都是圍繞微軟收購 GitHub 是否明智而展開的。真正的問題是，微軟是否會巧妙地使用 GitHub。正如微軟收購 LinkedIn 和《我的世界》開發者 Mojang 所顯示的那樣，微軟可能不會徹底改變 GitHub 所做的事情——至少不會立即改變。

Github 后續發展預測

既然微軟已經是全球最大、最受歡迎的代碼庫的新的擁有者，那么 GitHub 的未來軌跡將完全取決于微軟如何將 GitHub 視為其長期增長戰略的一部分。

1、與 Visual Studio 整合

現在微軟擁有 GitHub，可以做出很多潛在的行動，GitHub 與 Visual Studio 的整合幾乎是不可避免的，Visual Studio 是微軟最受歡迎的開發工具套件。 這與微軟的更廣泛計劃一致，即放棄對 Windows 的專有銷售，轉向其不斷增長的基于云服務的生態系統。

2、開發更多的開發者工具

即便是現在，編碼作為一門學科也存在著各種問題，使得其效率低下。GitHub 可以采取的最合理的行動之一是開發額外的工具，幫助開發者集中精力解決諸如錯誤追蹤和將應用程序部署到微軟 Azure 等問題，甚至可以用人工智能驅動的應用程序取代當前的 QA 工作流。GitHub 幾乎沒有觸及這些可能性，微軟重新關注基于云的開發者生態系統，與 GitHub 的潛力完全一致。

3、用外圍產品/服務吸引開發者以外的專業人士

GitHub 已經在吸引軟件工程師以外的專業人士方面取得了進展，比如產品經理。GitHub 的另一個潛在舉措可能是開發吸引這些專業人士的附加‘功能，例如綜合項目管理工具。考慮到微軟非常希望加倍推進企業應用程序和基于團隊的協作工具，這似乎特別有可能。

從 GitHub 身上學到的 3 個關鍵經驗：

1、找一個大問題去解決

讓 Git 更容易使用是 GitHub 的目標，但它從來不是 GitHub 的最終目標。GitHub 的真正目標是讓協作和編寫軟件變得更容易。世界上每一個軟件開發者都在努力解決 GitHub 試圖解決的問題。 這創造了一個巨大的潛在市場。

看看你目前開發的產品，問自己以下的問題：

• 你的產品是為了解決一小部分人遇到的非常特殊的問題，還是為了解決了很多人遇到的大問題？專業化可以成為一個強大產品區分點，但是解決大的、雄心勃勃的問題會給你的產品帶來更大的潛在市場。

• 你會在日常工作中使用你自己的產品嗎？很多公司說“吃自己的狗糧”是一個很好的規則，但實際上很少有公司能做到這一點。

• 如果你不使用自己的產品，為什么不呢？你的產品有問題嗎？還是你個人沒有受到產品要解決的問題的影響？這兩種情況都是非常嚴重的問題。不使用你自己的產品會引發人們是否真的需要你的產品的問題。如果你沒有親身經歷你的產品所解決的問題，是什么讓你們公司成為解決這個問題最合適的公司呢？

2、不斷解決令人痛苦的問題，并提供越來越好的解決方案

推動 GitHub 如此令人難以置信的增長的部分原因，是該公司不遺余力地致力于解決所有軟件開發人員都經歷過的重大問題以及痛苦的問題。這為 GitHub 吸引了巨大的潛在用戶群體，并使公司從根本上重塑了我們所知道的軟件開發。

想想你的產品和它所在的垂直領域中的位置，然后問問自己：

• 如果你能在你現有的產品中添加一個全新的功能，這個功能會是什么，它會解決什么問題？

• 為什么你的產品沒有這個功能？是野心太大了？還是太難了？還是太寬泛了？如何克服這些障礙來實現這一功能？

• 是什么讓你試圖解決的問題如此痛苦？是技術的問題還是人的問題？

GitHub 之所以成功，是因為它解決了一個技術問題——需要一個更好、更直觀的版本控制系統——這在解決人的問題上也具有巨大潛力，即在軟件項目上進行輕松、安全和遠程的協作。關注技術問題也使 GitHub 能夠解決人的問題，這是 GitHub 獲得成功的一個非常重要的因素。

3、盡早培養公司的文化

即使在早期，GitHub 就認識到了文化的重要性。公司有意識地主動創造自己的文化，而不是任由文化發展。與傳統的觀念相反，文化不僅僅是一種偶然的行為副產品——它是深思熟慮、有意行動和有目的決策的結果。對于任何公司來說，文化都是成長的關鍵因素。

看看你的公司，想想以下的問題：

• 你公司的文化如何反映組織的價值觀？即使在早期，GitHub 也非常喜歡調侃傳統的企業成功觀念，從相對扁平的等級結構到公司模擬會議室的人造木板和白蘭地酒瓶。你公司的文化對你有什么價值，有什么品牌屬性？

• 你的員工在多大程度上塑造了你公司的文化？換句話說，你公司的個性有多少是自上而下決定的，隨著時間的推移，你所雇用的員工有多少是符合這個個性的？

• 你認為你的競爭對手會如何看待你的公司和產品？這種看法在多大程度上是基于組織的文化？

結語：準備好，設置，Git

GitHub 通過做兩件事獲得了令人難以置信的成功：發現一個巨大而讓人痛苦的問題來解決；并且創造了一種流行的、具備黏性的產品，使人們更容易在一起工作和分享代碼。GitHub 現在面臨的最大挑戰是想出一種方法來進一步迎合編碼這一技術學科，同時吸引軟件開發者之外的專業人士。

從邏輯上來說，微軟可能不是 GitHub 最好的歸宿，因為該公司在歷史上對開源社區懷有敵意。不過，微軟在企業服務領域豐富的專業知識和前瞻性的領導能力，對于從舊金山北上的 Githubbers 來說，可能是一個好機會。現在大家都在關注，微軟會如何把它閃亮的“新玩具”發揮作用呢？

原文鏈接：https://producthabits.com/github/

來自: 36氪