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 這個利器，讓它變得更加閃耀。