Примечание переводчика: я не застала времена до GitHub и всегда воспринимала его как нечто само собой разумеющееся. Поэтому мне было любопытно узнать, какими инструментами пользовались инженеры нулевых и какие фичи позволили GitHub завоевать рынок. Надеюсь, вам тоже будет интересно погрузиться в историю проекта, которую собрал Грег Фостер. Дальше пойдёт текст автора.

Я пишу код со старших классов. У меня есть смутные воспоминания о том, как мы с другом создавали игру для Android, используя для совместной работы TortoiseSVN. В колледже я научился клонировать репозитории на GitHub, чтобы получить доступ к домашним заданиям по информатике. Позже, во время стажировок, я пополнил ряды тех, кто использует GitHub для ревью и мержа PR. Большинство разработчиков, чья карьера началась в последнее десятилетие, вероятно, пережили похожий опыт. GitHub стал синонимом исходного кода и изменений в коде, будь то открытые или закрытые проекты.

Легко воспринимать повсеместное распространение GitHub как должное, но как мы пришли к этому?

Я спросил своего коллегу Дэвида, как он узнал о GitHub. Дэвид пишет код лет на десять дольше меня и здорово вырос как профессионал. Он рассказал, что в нулевых для контроля версий программисты пользовались SVN. ПО же он скачивал с SourceForge, но считал интерфейс сайта утилитарным и «паршивым». Со временем Дэвид обнаружил, что всё чаще заходит на GitHub, чтобы найти документацию и скачать Open Source-инструменты вроде Rails. Это привело к тому, что Дэвид начал читать о лежащей в основе сервиса системе управления версиями Git и в итоге стал использовать для работы git-to-svn-конвертер. Но многие компании размещали код на SVN вплоть до 2010-го, и только годы спустя большинство частных организаций полностью мигрировали на Git.

История Дэвида только усилила мой интерес. Как GitHub вышел на рынок? Что существовало до него и какую нишу заполнила новая платформа?

Мир до появления GitHub

За четыре года до основания GitHub, в 2004-м, Линус Торвальдс создал Git. Хотя многие по-прежнему пользовались SVN, популярность Git как распределённой системы контроля версий стремительно росла. Она предлагала неоспоримые преимущества. В отличие от предыдущих инструментов для контроля версий, таких как CVS и SVN, пользователи Git могли хранить полные копии исходного кода на своих компьютерах, не обращаясь к централизованному серверу. Код можно было обновлять даже офлайн и делиться копиями друг с другом — не нужно было хранить его централизованно (и тратиться на хостинг единого источника). И если ветвление кода в SVN требовало дублирования всего репозитория, то создание веток в Git было быстрым и дешёвым.

Как можно догадаться, эти улучшения привели к взрывному росту креативной разработки в Open Source-сообществе. Git был создан специально для распределённой демократичной разработки и потому стремительно завирусился. Однако в корпоративные кодовые базы Git проникал крайне неспешно — те были вполне довольны своими приватными централизованно управляемыми SVN-серверами с легаси-процессами.

Переместимся на четыре года вперёд — в 2008-й. Проекты с открытым исходным кодом, такие как Rails, последовали за Linux и начинали внедрять Git. Частные организации продолжали использовать серверы SVN и Perforce для централизованного управления исходным кодом. Открытое ПО распространялось в основном через SourceForge, затем через Google Code или альтернативы вроде персональных серверов (но это встречалось нечасто).

Несмотря на своё доминирующее положение, SourceForge оставлял желать лучшего. Git на нём не поддерживался до 2009-го, хотя к тому моменту от создания GitHub прошёл целый год, а число его пользователей перевалило за 100 тысяч. Но различия были не только в технологиях. 

Сегодня, думая об онлайн-хостинге кода, мы представляем себе сайт, на котором можно беспрепятственно посмотреть сам код, полистать issues, последить за контрибьюторами. В SourceForge таких возможностей не было. Вместе с Google Code они скорее были нацелены на распространение ПО среди конечных пользователей, а не на совместную работу над кодом. Да, они решили часть проблемы, связанной с распространением Open Source-проектов, но мало что предложили в плане комментариев, просмотра исходного кода, ревью изменений и других базовых современных фич.

Дальше — хуже. Создание и управление репозиториями на SourceForge было настоящей пыткой. Например, для создания нового репозитория нужно было заполнить заявку и получить одобрение человека. Более того, частные репозитории в принципе не поддерживались, что делало сайт бесполезным для хостинга проектов с закрытым исходным кодом. 

Оставлять комментарии и открывать issues к проектам было сложно — процесс был крайне неинтуитивным, а форкинг случался крайне редко. Чтобы внести свой вклад в проект, в большинстве случаев приходилось создавать патч и отправлять его через почтовый сервер, вместо того чтобы просто сделать форк и открыть pull request. Впервые узнав о SourceForge, я поразился тому, насколько он похож на сегодняшний Apple App Store. Теперь становится понятно, какая рыночная ниша открылась перед GitHub.

Время SourceForge и Google Code

Зацените лендинг SourceForge 2008 года. Что вы видите? Гордые заявления о том, что это крупнейший сайт, посвящённый Open Source. Статистика загрузок и выделенные проекты. Свежие релизы ПО, даже реклама в правой колонке. Но ни одного упоминания Git, никакого акцента на профили пользователей и полное отсутствие частных репозиториев. В центре внимания — дистрибуция, а не сотрудничество разработчиков.

Google Code был на порядок лучше SourceForge. Сайт был нацелен на то, чтобы упростить бесплатный хостинг кода и документации. Он полагался на крутой поиск от Google и предлагал продуманную документацию для разработчиков, желающих учиться. Однако ему критически не хватало «социальных» функций и возможностей для совместной работы, которые позже оказались столь важными для Open Source-разработчиков. И наконец, хотя сервис и запустился с поддержкой SVN, Google Code добавил поддержку Git только в 2011 году, сопроводив это статьёй в Wired с язвительным названием.

Создание GitHub

Одним вечером 2008 года Том Престон-Вернер и Крис Ванстрат заглянули в спортивный бар в Сан-Франциско после митапа Ruby on Rails. Rails-сообщество всё активнее использовало Git, но единого сайта для размещения Git-репозиториев, подобного SourceForge, не было. Более того, явно набирали обороты социальные сети, а для разработчиков Open Source-проектов такой сети не существовало. Git сильно упростил совместную разработку ПО, а сайты вроде SourceForge помогали распространять новые версии релизов. Но не было «домашней» платформы для полноценного сотрудничества. Что, если бы любой мог хостить исходный код, обсуждать issues и просить мейнтейнеров вносить изменения в форки — и всё это с поддержкой профилей и ленты комментариев, как на Facebook?

Первая версия GitHub развивалась как пет-проект. Авторы работали над базовой функциональностью платформы по выходным (естественно, используя Rails). Наконец она приобрела черты законченного продукта — Крис мог использовать её на основной работе. Постоянно проверяя GitHub на практике, авторы устраняли баги и закрывали критические пробелы в функционале.

«GitHub как компания фактически выросла из этого пет-проекта, поэтому у нас не было какой-то большой стратегии, мечты или амбиций. Мы просто хотели работать над чем-то крутым» (Крис Ванстрат).

Создатель Ruby on Rails был одним из первых пользователей GitHub, что способствовало стремительному росту популярности сайта.

GitHub в 2008 году

Оригинальный логотип GitHub включал фразу «Социальный хостинг кода», а главное обещание бренда гласило: «Хостинг Git-репозиториев больше не заноза в заднице». GitHub чётко определил свои главные конкурентные преимущества при запуске: функции соцсети и возможность размещать Git-репозитории онлайн. Ни один другой сайт не предлагал такого.

Лента новостей проектов и разработчиков. Следите за любимыми проектами и людьми, которые над ними работают:

Просмотр исходного кода. Легко просматривайте код в любой версии, ветке или теге:

Публичные профили разработчиков. Следите, над чем работают другие разработчики и сколько коммитов они сделали:

«Что удивительно в GitHub — это то, как он добавляет социальный аспект в процесс. Крис и Том наглядно показывают нам, как должна работать Git-разработка. Лично я неоднократно поражался такой простой штуке, как пуллинг коммитов из внешних Git-репозиториев» (Рик Олсон).

«Вы, наверное, уже раз сто слышали за последнюю неделю: GitHub — это мощь. У меня никогда не было поводов размещать свой код на подобных хостинг-сервисах, но теперь они есть» (Джош Сассер).

Стремительный рост GitHub

Протестировав MVP, сооснователи GitHub запустили бесплатную бету для друзей, предоставив возможность хостить публичные репозитории.

Рост GitHub в Open Source-сообществе был стремительным — продукт полностью соответствовал ожиданиям рынка. Rails сразу переключился на платформу, так что любой, кто хотел использовать Ruby on Rails, должен был взаимодействовать с GitHub. Так ребята вроде моего коллеги Дэвида впервые узнали о GitHub и Git.

• В первый год GitHub вырос до 46 000 публичных репозиториев. 

• На следующий их число увеличилось до 90 000; платформой пользовались 100 000 человек.

• На третий год количество репозиториев достигло 1 миллиона, и к 2011 году GitHub опередил SourceForge и Google Code.

Но радоваться стремительному росту было рано: основатели продолжали считать каждый доллар и развивать бизнес своими силами. Главная задача, которая стояла перед ними, — начать получать доход. Вместо того чтобы сосредоточиться на рекламе, как SourceForge, или на продажах для корпоративных клиентов, как Perforce, сооснователи GitHub начали продавать индивидуальные подписки на хостинг закрытых репозиториев. Модель была понятной, самообслуживаемой и несколько оригинальной по сравнению с другими хостинг-продуктами и соцсетями. Google Code и SourceForge не только не хостили Git-репозитории, но и не предлагали опций для хостинга закрытого кода. Кроме GitHub, единственным вариантом для размещения закрытых репозиториев был собственный сервер.

Помимо быстрой выручки от подписок, сооснователи GitHub искали другие способы заработка и экономии денег. Они экспериментировали с альтернативными источниками дохода, такими как разовые рекламные размещения, магазин мерча, услуги по обучению Git и доска вакансий. Чтобы максимально сократить бизнес-расходы, GitHub запартнёрился с Engine Yard, а затем с Rackspace, предлагая им рекламу в подвале сайта в обмен на бесплатный хостинг.

В 2009 году GitHub запустил версию для самостоятельного хостинга, которая позволила крупным предприятиям использовать платформу. Вместо SVN-серверов или продуктов вроде Perforce инженеры могли применять новые инструменты Git как для Open Source, так и для проприетарной разработки. Тарифный план GitHub для компаний и команд был запущен в 2010 году, что ещё больше укрепило присутствие платформы на рынке хостинга закрытого кода и совместной разработки. А в 2011 году GitHub:Fi превратился в официальный серверный продукт для корпоративных клиентов. 

«GitHub Enterprise был создан, чтобы помочь распространить GitHub в массы. Неважно, застряли вы за брандмауэром или имеете полный доступ к вебу, мы хотим, чтобы GitHub работал для вас» (Крис Ванстрат).

Поменяв подход к бизнес-модели хостинга кода, GitHub заработал много денег. Теперь можно было масштабировать команду и постепенно улучшать опыт работы с продуктом. Но фокус на доход и самостоятельный рост не были блажью основателей — венчурное финансирование им было недоступно. До 2010 года «компании, создающие инструменты для разработчиков, не могли привлечь значительные инвестиции» (Forbes).

«Даже когда компании, разрабатывающие инструменты, продавали бизнес, как в 2013 году, когда Facebook приобрёл создателя инструментов для мобильных приложений Parse, заявленная сумма в 80 миллионов долларов считалась скромным результатом. Для некоторых инструменты для разработчиков всегда будут оставаться зоной риска для венчурного капитала» (Forbes).

Чтобы расширить рынок, потребовались инвестиции Heroku, Atlassian, Stripe, Twilio и SendGrid. Лишь спустя шесть лет GitHub получил инвестиции фонда Andreessen Horowitz — 100 миллионов долларов в рамках А-раунда, который позиционировался как крупнейший в истории.

Кто не использовал GitHub

Google так и не внедрил GitHub. На протяжении нулевых в компании использовали Perforce, а позже разработали собственную систему контроля версий под названием Piper. Насколько мне известно, помимо уникальных передовых инструментов контроля версий, инженеры Google также изобрели свой веб-интерфейс для код-ревью. Их ранний дашборд для код-ревью, созданный в 2004 году, был вдохновлён интерфейсом Gmail и стал золотым стандартом корпоративных процессов разработки ПО. У них не было непосредственной потребности в Git и GitHub.

Facebook также обошёлся без GitHub во внутренней разработке. Примерно в 2010 году Эван Пристли из Facebook разработал Phabricator — за год до того, как GitHub официально запустил самохостинг для компаний. Даже если бы GitHub предложил это решение раньше, Facebook, вероятно, всё равно предпочел бы собственный инструмент, который лучше бы интегрировался во внутренние системы компании и справлялся с масштабированием монорепозитория (что не всегда удавалось даже Git). Более того, Facebook перешёл с Git на Mercurial, для которого GitHub так и не разработал полноценную поддержку.

Некоторые «единороги», такие как Airbnb, стали использовать GitHub с самого начала. Другие известные компании, такие как Uber и Pinterest, форкнули Phabricator и захостили его на своих серверах. Я не уверен, но подозреваю, что они сделали это, поскольку:

• Phabricator лучше всего подходил для селф-хостинга и контроля открытого кода; 

• в их рядах было много бывших сотрудников Facebook, скучающих по прежнему инструментарию.

Запущенный в 2011 году GitLab пошёл другим путём, сфокусировавшись на полноценной DevOps-платформе, а не на «социальном кодинге». Его создатели воспользовались быстрорастущим DevOps-трендом и сделали ставку на CI/CD, чтобы завоевать долю рынка среди крупных технологических компаний, таких как NVIDIA.

Работая над Graphite в 2024 году, я общаюсь с сотнями, если не тысячами высокотехнологичных инженерных команд. И крайне редко слышу о компаниях, которые не используют GitHub. По данным опроса Stack Overflow за 2022 год, рыночная доля GitHub лишь в два раза превышает долю GitLab. Однако на практике, по моим наблюдениям, примерно 95% современных технологических компаний используют GitHub и лишь немногие из них самостоятельно хостят GitHub Enterprise. Оставшиеся либо используют GitLab, Phabricator или Gerrit, либо разработали собственные платформы для хостинга кода.

Будущее GitHub и хостинга кода

Линус Торвальдс, создатель Git, высоко оценил GitHub, заявив: 

«Хостинг от GitHub великолепен. Они отлично с этим справились. Думаю, GitHub заслуживает огромной похвалы за то, что сделал хостинг проектов с открытым исходным кодом таким простым».

Однако он также резко раскритиковал реализацию интерфейса мержа на GitHub, отметив:

«В Git есть отличный модуль для pull request'ов, но GitHub решил заменить его собственной, совершенно некачественной версией. В результате GitHub стал бесполезным для подобных вещей. Он отлично подходит для хостинга, но pull request'ы и онлайн-редактирование коммитов реализованы отвратительно» (Wired).

Каково будущее хостинга кода? В своей знаменитой книге «Дилемма инноватора» Клейтон Кристенсен утверждает, что первые инновационные продукты часто начинаются как интегрированные решения. Я бы сказал, что GitHub и GitLab являются примерами таких интегрированных предложений, предоставляя «единое окно» командам, желающим управлять исходным кодом.

Кристенсен утверждает, что по мере «созревания» рынка решения становятся специализированными и модульными. Мы уже наблюдаем этот процесс в некоторых областях «социального программирования». Jira и Linear предлагают модульные решения для отслеживания issues, а Jenkins и Buildkite — модульные решения для CI. GitHub был первым хостингом для Git-репозиториев, но со временем BitBucket и AWS CodeCommit предложили аналоги. Сейчас GitHub предлагает интегрированную очередь слияния (merge queue), но на рынке уже существуют более точечные решения, такие как Mergify, Aviator, Trunk и Graphite.

GitHub сохраняет монополию на Open Source-код благодаря сильным нетворк-эффектам и таким фичам, как форкинг, комментарии в стиле форума и модерация, которые как нельзя лучше подходят для разработки открытого кода. В случае репозиториев с закрытым исходным кодом GitHub изначально выбирали из-за его специализации на хостинге Git, но сейчас эта функция стала обычным делом. Социальные функции GitHub практически бесполезны для коммерческих компаний, где обсуждения ведутся через Slack, Notion, Linear и Zoom.

Думаю, в будущем произойдёт разделение между инструментами разработки для Open Source- и закрытых проектов. Для Open Source-коллаборации важны обсуждения, профили, модерация, форки и поиск проектов. Для закрытых проектов критично, чтобы изменения кода проходили ревью за часы, а не дни. Здесь необходимы trunk-based-процессы, мерж-очереди, экстренные процедуры и координация CI/CD. В обеих областях есть точки пересечения, но, на мой взгляд, со временем мир будет ещё сильнее специализироваться на разных решениях для этих отдельных случаев.

Уже есть специализированные решения от Facebook и Google. Развивая свои системы контроля версий независимо от ограничений GitHub для Open Source, они создали мощные паттерны, такие как PR inbox от Google и stacked diffs от Facebook.

Я бы хотел, чтобы модульность дошла до того момента, когда каждый инженер сможет выбрать способ размещения своего исходного кода совершенно независимо от инструментов, которые он использует для изменения этого кода. Эта тенденция уже прослеживается в других аспектах разработки: например, инженеры могут свободно использовать предпочитаемую IDE или облачного хостинг-провайдера. GitHub честно заслужил своё монопольное положение, специализируясь на хостинге кода и социальном программировании, но это ещё не конец истории. Надеюсь, когда-нибудь в будущем у разработчиков будет не один, а пять приемлемых вариантов хостинга кода.

Дисклеймер: я достаточно молод и не занимался программированием профессионально до GitHub. Большая часть информации в этой статье собрана из онлайн-источников, интервью и опыта инженерной работы. Я перелопатил кучу источников, пытаясь понять, как всё было и куда мы идём.

Полная хронология событий

• 1991: SourceForge начинает работу, став первым бесплатным хостинг-провайдером для Open Source-проектов.

• До 2004 года: для контроля версий используют CVS и SVN; SourceForge лидирует в хостинге проектов с открытым исходным кодом.

• 2004: Линус Торвальдс создаёт Git, совершая революцию в контроле версий с помощью распределённой системы.

• 2006: Запущен Google Code, первоначально поддерживающий SVN.

• 2008: Основан GitHub, предлагающий хостинг Git-репозиториев с упором на социальное программирование.

• 2009: SourceForge добавляет поддержку Git; GitHub представляет версию для самостоятельного хостинга, закладывая основу для GitHub Enterprise.

• 2010: Facebook разрабатывает Phabricator, набор веб-инструментов для код-ревью и разработки ПО.

• 2011: Основан GitLab, специализирующийся на создании полноценной DevOps-платформы; в Google Code добавлена поддержка Git.

• 2012: GitHub запускает GitHub Enterprise, удовлетворяющий потребности крупных организаций в частном хостинге.

• 2016: Google Code закрывается, что подчёркивает растущее доминирование GitHub в хостинге кода.

• 2018: GitHub представляет платформу GitHub Actions, автоматизирующую рабочие процессы в сфере разработки ПО.

• 2021: Phabricator перестаёт активно поддерживаться, что приводит к увеличению числа пользователей GitHub.

P. S. 

В оригинальной статье есть милая заметка о том, что Грег уделяет много времени написанию текстов, чтобы распространять информацию о Graphite. В благодарность за интересный контент оставим ссылку на сайт инструмента здесь. 

Читайте также в нашем блоге:

• Как вносить вклад в Open Source — и не только кодом. Инструкции от Linux Foundation, CNCF и Free Software Foundation

• Git для ленивых: обзор консольной утилиты Lazygit

• Вы используете больше Open Source-софта, чем думаете