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

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

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、 Facebook、 谷歌、 Twitter ——他們都在 GitHub 上有私人儲存庫。一些公司，比如 Mozilla，擁有數百個儲存庫，幾乎所有的東西都在GitHub上託管。其他公司，比如 Facebook，擁有的儲存庫要少得多(只有102個，相比之下，Mozilla有687個) ，但參與度卻要高得多，Facebook 102個儲存庫中有超過15000個分叉。

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

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來說，可能是一個好機會。現在大家都在關注，微軟會如何把它閃亮的“新玩具”發揮作用呢？