Примечание переводчика: недавно мы опубликовали в блоге перевод статьи о том, как GitHub заменил SourceForge в роли доминирующей платформы для хостинга кода. О существовании оригинального текста недавно узнал один из сооснователей GitHub — Скотт Чакон. Он написал ответный лонгрид о контексте времени и двух главных причинах того, почему именно их продукт быстро взлетел и стал успешным. Мы не могли пройти мимо продолжения истории со взглядом изнутри и перевели его тоже. Слово Скотту. 

19 августа Тео Рэнтс (Theo Rants) опубликовал на своём очень популярном YouTube-канале видеоразбор написанной командой Graphite статьи с заголовком «Как GitHub заменил SourceForge в роли доминирующей платформы для хостинга кода». 

Заголовок Тео был немного более лаконичным: «Почему GitHub победил».

Как сооснователь GitHub, я нашёл статью Грега и последующие комментарии Тео забавными, но подумал, что было бы интересно поделиться своим взглядом на причины подъёма и доминирования GitHub. И, возможно, исправить несколько моментов, которые были не совсем верными в стороннем анализе. 

Если вы находитесь в эпицентре подобных явлений, то, конечно, в вашей картине могут быть слепые пятна, но, в отличие от этих молодых людей, я действительно был там. Чёрт, я даже написал книгу.

Итак, вот инсайдерская точка зрения на то, почему GitHub победил.

TLDR

Не хотите тратить много времени на чтение? Вот моя версия того, почему GitHub победил и почему вы, вероятно, используете его по сей день.

Всё можно свести к ровно двум причинам, которые резонируют друг с другом с идеальной частотой:

1. GitHub появился в нужное время.

2. У GitHub был хороший вкус.

У всех четырёх сооснователей GitHub были неудачи как до, так и после него. Крис и ПиДжей провалились с FamSpam до GitHub, а Том и я не смогли заставить Chatterbug взлететь после GitHub. Думаю, что оба проекта могли похвастаться хорошим вкусом и отличным продуктом, но ошиблись с местом, временем, рынком и тому подобным, что и помешало им достичь уровня GitHub.

Когда зарождался GitHub, интерес к распределённым инструментам контроля версий с открытым исходным кодом только начинал расти, и не было никого, кто бы всерьёз (а тем более коммерчески) занимался их хостингом. Крупным хостерам было всё равно, а у мелких не хватало силёнок.

Более того, те игроки (SourceForge, Google Code и т. д.), которым стало не всё равно, когда популярность Git и GitHub стала очевидна, просто не имели вкуса. Они никогда бы не смогли конкурировать с компанией, проектирующей инструменты для разработчиков, сооснователями которой были разработчики с богатым опытом создания Open Source-продуктов.

Мы в первую очередь думали об удобстве разработчиков, и нам хватило креативности, чтобы отбросить все предрассудки и сделать продукт таким, каким он должен быть. Остальные же пытались построить то, что можно было бы продать рекламодателям или CTO.

Вот почему GitHub победил.

Ну а теперь, если вам интересен сторителлинг, позвольте мне поведать внутрянку всей этой истории.

Среда

Вернёмся к началу.

Пара слов о том, почему «GitHub появился в нужное время» с точки зрения разработчика ПО в 2005 году. Именно тогда Git получил свой первый коммит от Линуса, а Mercurial — свой первый коммит от Оливии.

Каково было разрабатывать софт почти 20 лет назад и как в этой среде Git смог завоевать симпатии людей, а GitHub — появиться?

Разработчики ПО в 2005 году обычно использовали централизованную систему контроля версий типа Subversion. Я пользовался RCS, CVS, Subversion и Perforce до появления Git. Чёрт, мы даже PHP-файлы отправляли по FTP прямо на production-сервер.

Если вы работали над проприетарным коммерческим программным обеспечением, централизованные системы контроля версий вроде SVN, честно говоря, были не самой ужасной вещью. Было довольно просто сделать check out, внести изменения, сделать check in. Ветвление и мерж были полным отстоем, но во многих ситуациях их можно было избежать (сомневаюсь, что когда-либо использовал ветвление в Subversion или Perforce). 

Честно говоря, сегодня люди жалуются на Git больше, чем тогда на SVN. Пожалуй, интерфейс и ментальная модель у SVN были проще, чем у Git.

Большая проблема, которая, как мне кажется, стала назревать примерно в это время, возникла не внутри профессиональной разработки в закрытых, доверенных командах. Она была внутри растущего мира Open Source.

Понимаете, до этого времени Open Source практически не существовал, особенно в сравнении с сегодняшним днём. Большинство из вас, вероятно, не помнит времена, когда не было миллионов проектов с открытым исходным кодом, да и само словосочетание появилось только в 1998 году. 

Для понимания масштаба: исследователь Дирк Рили (Dirk Riehle) в 2008 году опубликовал работу, в которой проанализировал глобальные тренды развития Open Source-проектов. По оценкам, на тот момент в мире насчитывалось в общей сложности 18 000 активных проектов с открытым исходным кодом — в 2005 году их, конечно, было гораздо меньше.

Для сравнения: сегодня только на GitHub более 280 миллионов публичных репозиториев.

Так почему же Open Source помог запустить эру Git и GitHub?

Потому что Open Source быстро рос, а централизованные системы контроля версий особенно плохо справлялись со стратегиями «открытого» вклада от сообщества (open contribution). То есть нельзя было просто расшарить проект, а затем просто и удобно вносить правки других инженеров.

Сложности с совместной работой над Open Source: как это было в 2005 году

В самом деле, насколько всё было плохо?

Ниже мое выступление десятилетней давности с AWS Tokyo о том, какой была разработка OSS в то время. Если посмотрите его, то можете пропустить несколько следующих абзацев. Рекомендую включать на скорости х1,5 — говорил медленно из-за переводчиков.

В принципе, можно было сделать свой сервер Subversion доступным только для чтения для неаутентифицированных пользователей, как обычно и хостили Open Source-проекты (или можно было периодически выкладывать архив с исходным кодом).

Чтобы внести вклад в чужой проект, нужно было:

1. скопировать последнюю версию;

2. внести свои изменения;

3. сгенерировать патч с помощью GNU diff;

4. загрузить этот патч в систему тикетов или отправить на электронную почту проекта.

Мейнтейнер должен был:

1. скачать ваш патч;

2. применить его к своему проекту и проверить, что патч:

   • применился чисто;

   • работает корректно;

3. отправить обратную связь, поправить патч или закоммитить его.

Артефакты этого процесса всё ещё можно найти в интернете. В какой-то момент я использовал Trac для такого рода проектов. Вот их руководство по отправке патчей и пример того, как предлагались изменения. 

Сущий ужас, согласны?

Проект Rails, а также мои друзья (и будущие сооснователи GitHub) в Err использовали похожую систему тикетов под названием Lighthouse (которая, как ни странно, до сих пор работает). А одним из моих самых ранних Open Source-проектов был инструмент командной строки git-lighthouse, который упрощал процесс извлечения и применения прикреплённых патчей из тикетов. 

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

Расцвет Git

Git фактически начался с того, что Линусу Торвальдсу очень понравилась (в то время) коммерческая система контроля версий под названием BitKeeper. Она была создана специально для того, чтобы упростить существующий процесс разработки ядра.

Если бы исходный код BitKeeper был открыт или у системы были иные условия лицензирования, возможно, не было бы ни Git, ни GitHub.

Однако вместо этого один из разработчиков Linux сделал реверс-инжиниринг протокола, нарушив условия лицензирования. BitKeeper и Линус предпочли не ругаться, а разойтись подобру-поздорову.

Линус позаимствовал некоторые концепции BitKeeper и собрал простейшую вещь, которая могла бы решить его проблемы. Новый проект он назвал Git, «информационный менеджер из ада».

Git довольно быстро завоевал популярность в сообществе Linux и постепенно превратился в полноценную — своего рода — систему контроля версий.

Git так полюбился всем по трём причинам:

• ветвление и мерж были мечтой, а не кошмаром;

• он был потрясающе быстрым;

• работать с разрешениями было намного проще.

На заре существования Git мне доводилось выступать с докладами. Часто я просто выходил на сцену, создавал несколько веток, коммитил в них изменения, переключался между ветками, а затем мержил их. И всё это за 60 секунд. У народа отпадали челюсти. Некоторые думали, что демо ненастоящее.

Не могу передать, насколько волшебным в 2006 году было ощущение, что можно так быстро и легко переключаться и мержить контексты. В Subversion это было полным кошмаром.

А ещё было невероятно круто, что не нужно было дожидаться разрешения центрального сервера, чтобы сделать коммит. Ты словно летел на ракете — всё было настолько быстро.

И, наверное, самое главное — форкнуть репозиторий стало очень легко. То есть можно было хостить собственную копию репозитория, писать в неё, а также пушить правки, которые другие затем могли скачать в свои форки. Проект Linux сразу воспользовался этой возможностью — для больших изменений часто посылались запросы на подтягивание изменений из форка, и Линус запросто это делал.

Именно отсюда взялся  термин Pull Request. В Git есть команда git request-pull, которая формирует имейл для отправки в список рассылки, чтобы упростить описанный выше процесс. Когда GitHub добавил возможность по сути генерировать такой же тип сообщения, мы решили, что запрос на «извлечение» должен называться Pull Request. (Предыстория в X для тех, кому интересно.)

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

Это было круто — контрибьютинг превратился из проблемы поиска того, у кого есть разрешение на push, в поиск того, у кого есть что-то интересное, что можно взять.

И, конечно, последний пункт напрямую приводит нас к GitHub.

Расцвет GitHub

В конце прошлого года я брал интервью у сооснователя GitHub Тома. Среди прочих тем, которые мы обсуждали, была история о том, как у него возникла первоначальная идея работать над GitHub.

Команда Тома начала использовать Git, когда он трудился в Powerset. Однако членов других команд было не так просто добавить на внутренний сервер, потому что основной протокол Git работал по SSH, то есть на машине должен быть пользователь с SSH-привилегиями. Для каждого. Это было сложно организовать и для большинства членов команды того не стоило. Том решил упростить процесс. 

Git — это круто, но хостинг Git — это заноза в заднице. Именно поэтому Том начал работать над GitHub.

Просмотрел свои старые имейлы, чтобы найти момент, когда впервые прочитал о проекте Тома под названием «GitHub». И это было в ответе Криса на скринкаст Git, который я сделал в конце 2007 года.

Перевод письма Криса Ванстрата

Привет, Скотт.

Потрясающе! У меня есть несколько приложений, которые я развёртываю с помощью Git, но этот скринкаст просто великолепен. Действительно хорошо сделан. Мне нравятся переходы, и здорово, что вы углубляетесь в реальное использование Git — мержи, push’ы, gitk и т. д.

Том Престон-Вернер (известный по Chronic, Gravatar и в целом бог) и я работаем над Git-сайтом. Github.com. Это публичная push-точка, как repo.or.cz, но ориентированная на пользователя, а не на проект.

Идея в том, чтобы легко форкать и вносить вклад в проекты с открытым исходным кодом, реализуя распределённую модель pull (в отличие от модели shared push repo.or.cz и SVN).

Мы думаем брать 10 долларов в год (или около того) и наполнить GitHub полезными функциями. Готовыми хуками post-commit, веб-хуками post-commit, туториалами, вики, интеграцией с pull request и т. д. И чтобы не уродливо.

Не хотите потестить наш сервис, когда мы запустим его в бету? Может быть, появятся какие-нибудь идеи? Мы бы с удовольствием осветили этот скринкаст.

Спасибо, и отличная работа.

- Крис

Тогда это ещё был секретный сайд-проект от них двоих (кстати, Крис... строчная буква «h»?). Именно тогда я начал переписываться с Крисом и Томом о библиотеках Git/Ruby, на которых работает сайт, и в конечном итоге пробился в проект и компанию.

В письме выше есть ряд интересных моментов. 

Во-первых, они сравнили GitHub с единственным другим реальным публичным сайтом для хостинга Git — repo.or.cz (который тоже чудом до сих пор работает, если вы хотите узнать, в каком состоянии был Git-хостинг до появления GitHub). Ключевое отличие — они сделали сайт ориентированным на пользователя, а не на проект. До этого, чтобы разместить что-то на SourceForge или другом подобном сервисе, нужно было занять имя проекта. С GitHub можно создать любой проект с любым именем, потому что он привязан к пользователю.

Во-вторых, фокус на pull-, а не push-модели (в основном это касается штуки с разрешениями, о которой говорилось ранее).

В-третьих, «неуродливость» была ключевой фичей. У GitHub был вкус.

Git побеждает

Вот почему Git был крут и почему был создан GitHub, чтобы облегчить его использование. Но вопрос в том, почему Git победил? В то время появилось множество распредёленных систем. Mercurial во многом был похож на Git и даже превосходил его в отдельных аспектах. Почему Git вышел на первое место в великой войне DVCS?

Думаю, что ответ на этот вопрос — PR. 

Есть две большие PR-гориллы, которые борются за ответ на вопрос «Почему Git победил?». Первая — это Linux и, соответственно, Линус. Вторая — GitHub и, соответственно, Rails-сообщество.

Возможно, это был Линус/Linux

Все знали Linux, все знали Линуса. Если он создал потрясающую операционную систему, которой пользуются все (по крайней мере, на серверах; следующий год — год Linux на десктопах), то, несомненно, способен и создать систему контроля версий нового поколения. Она сложна в использовании? Значит, он умнее нас, и мы должны лучше стараться, верно?

Это видео — одно из первых в Сети выступлений о Git, примерно 2007 год. В нём Линус рассказывает о Git и распределённых системах контроля версий — тогда совершенно новой концепции — в кампусе Google.

Оно вышло в период между тем, когда я начал использовать Git (конец 2005 года), и тем, когда я пошёл работать в GitHub (середина 2008-го). Я сто раз пересматривал его, как и миллионы людей. Согласитесь, забавно слышать, как Линус говорит: «CVS — это самая тупая штука, что я видел, и все, кто не согласен, некрасивы и тупы»? И это — в кампусе самого Google!

Это просто шикарный PR-ход.

Кроме того, если вы ассоциируете Linux и Линуса (что делает большинство), есть аргумент, что сама Linux в лице Android косвенно способствовала популярности Git.

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

В начале сентября 2008 года, как раз во время релиза Android 1.0 (примерно через две недели после письма, но до тренинга), Шон Пирс, один из первых супергероев экосистемы Git, попросил меня обучить команду Google Android работе с Git:

Перевод письма Шона

Тема: Тренинг по Git

Скотт, ты сейчас в районе залива Сан-Франциско?

Google хочет пригласить тебя провести очные тренинги по Git для примерно 200 инженеров. Учитывая твою работу над GitCasts и Git Community Book, думаю, ты сможешь подготовить что-то действительно полезное для наших инженеров. Все они переходят с Perforce на Git и должны освоить его в кратчайшие сроки.

Речь о начале/середине октября. Дай знать, если заинтересован, и мы приступим к планированию.

Думаю, мы также сможем предложить гонорар за выступление/консультации. Точные детали обсудим, как только будет готов план обучения.

Пожалуйста, сохрани эту информацию в тайне. Мы ещё не готовы к тому, чтобы мир узнал, что Google использует Git. Впрочем, скоро все всё равно узнают об этом, когда проект станет Open Source.

Я добавил в адресаты свой рабочий имейл, чтобы вся наша переписка была в одном треде. Просто хотел написать тебе с адреса, который ты знаешь. :-)

- Шон.

Трудно определить, какое влияние оказал Android на принятие Git в корпоративной среде, но оно явно было ненулевым. Команда Google/Android стала первой, для кого я провёл корпоративное обучение под эгидой GitHub, но этим дело не ограничилось — я обучал работе с Git инженерные команды в Motorola, Qualcomm, Ericsson и Broadcom, если называть лишь телеком-компании. И это до того, как у нас появилась команда, которая занималась этим на постоянной основе.

Линус продвигал Git своим широкомасштабным брендом суперзвёздного ботаника, которого никогда не было у Mercurial. Но Android также продвигал Git (учитывая его зависимость от ядра Linux) в огромные компании из чисто практических соображений: в противном случае этого не произошло бы ещё как минимум десятилетие.

Возможно, это был GitHub

Также, и я говорю это с долей скромной надежды, есть вероятность, что именно GitHub стал определяющим фактором в окончательном доминировании Git над Mercurial.

GitHub повезло: с самого начала нас приняло невероятно поддерживающее и «модное» сообщество Ruby. За пару месяцев все Ruby-проекты переехали на GitHub. В то время Rails был хитом, он был круче, чем PHP. JS-фреймворки ещё не были в ходу, не было Node и так далее. Поэтому все следили за тем, что делают продвинутые ребята из Ruby-сообщества: они были на острие крутой разработки в мире программного обеспечения. И они использовали GitHub.

Сам Линус недавно сказал, что, с его точки зрения, именно сообщество Ruby «повинно» во взрывном росте интереса к Git. Он не называет GitHub напрямую, но никто не будет спорить с тем, что Git пришёлся по душе Ruby-сообществу в значительной степени благодаря нам. 

По транзитивности предположу, что Линус на самом деле считает, что именно GitHub стал причиной победы Git. «...Все эти странные Ruby-ребята перешли на Git, и внезапно тот просто взорвался...»

Разумеется, Ruby-сообщество пришло на GitHub не случайно. 

Помню, как мы все — Крис, Том, ПиДжей и я — сидели за столиками на Ruby-конференциях вместе с ребятами из раннего Ruby-сообщества, показывали им GitHub, рассказывали о Git, выступали с докладами и так далее. Все мы участвовали в одних и тех же конференциях, вместе пили пиво после Ruby-митапов в Сан-Франциско. Эти ребята потом основали Rails, Heroku, Twitter, jQuery и кучу других проектов.

Самое главное: мы не пытались что-то продать, а просто делились тем, чем были страстно увлечены. В Ruby-сообществе все верили друг другу, основатели GitHub были его неотъемлемой и искренней частью. Мы пробовали проекты друг друга и поддерживали друг друга.

Использование GitHub Ruby-сообществом означало, что GitHub теперь упоминался на каждой профильной конференции. Бесплатная реклама! То есть по мере того, как проекты всё чаще переходили на GitHub, даже у тех, кто предпочитал Mercurial, не было иного выбора, кроме как использовать Git. Впрочем, не было и особого смысла оставаться на нём (как оказалось): всего за несколько лет GitHub попросту сокрушил Mercurial.

В мире Mercurial существовал BitBucket, который был создан для хостинга Mercurial и написан на фреймворке Django. Но думаю, у нас была слишком большая фора на старте, а сервисы не особо различались. Сообщество Python не поддержало BitBucket так активно, как Ruby-сообщество — нас.

Уже в декабре 2008 года на GitHub насчитывалось около 27 000 публичных репозиториев, в то время как на BitBucket их было чуть больше 1 000.

Откуда взялись столь точные числа, спросите вы? У меня был сайт под названием почему-Git-лучше-чем-Х, и один парень по имени Йеспер написал мне, что пункт, где я утверждал, что у Git есть GitHub, а у Mercurial и Bazaar нет GitHub, ошибочен. Я довольно высокомерно заявил, что они в разных лигах.

Перевод письма Йеспера и ответа Скотта

Входящее письмо:

Привет.

Насчёт GitHub:

«Такое сообщество просто недоступно ни в одной из других

систем контроля версий»

Это не так. У Mercurial есть свой «GitHub» на Bitbucket.org. Возможно, стоит поправить информацию.

У Bzr также есть launchpad.net.

- Йеспер

Ответ:

BitBucket — очень похожий сайт (так как они фактически напрямую скопировали наш сайт страница в страницу), но он даже близко не стоял по уровню сообщества. У BitBucket менее 1 300 публичных репозиториев — скорее всего, примерно столько же зарегистрированных пользователей. Из них, может быть, пара сотен реально активных. У GitHub более 27 000 зарегистрированных проектов и огромное активное сообщество. Никто не переходит на Hg из-за BitBucket, но многие переходят на Git из-за сообщества, которое сложилось на GitHub. Если бы существовало другое сообщество такого же масштаба и влияния, я бы, конечно, добавил его, но BitBucket — просто сайт-копирка, который пока не взлетел.

- Скотт

К его чести стоит отметить, что он ни разу не упрекнул меня за ответ, который теперь кажется чрезмерно задиристым. Оказалось, что Йеспер был основателем BitBucket. Неловко получилось.

Через год или около того мы встретились с ним в Амстердаме, выпили немного хорошего виски и с тех пор дружим.

Конкурентное поле рушится 

В конце концов то ли GitHub помог Git победить, то ли Git помог победить GitHub, но всё быстро закончилось. 

В 2006–2007 годах все впервые узнали о распределённых системах контроля версий, Git и Mercurial начали бороться между собой. 

В 2008 году появился GitHub. 

В 2011 году и Google Code, и BitBucket добавили поддержку Git, и этот момент я отмечу как год, когда был забит последний гвоздь в крышку гроба Mercurial. Git победил, а вместе с ним и GitHub.

Всего 4 года спустя, в 2015-м, Google Code сдался и закрыл свой сервис. В письме, которое они разослали, по сути говорилось: «Просто переходите на GitHub». Если я правильно помню, они даже обратились к нам за помощью с миграцией.

Перевод письма Google Code

Тема: Google Code закрывается

Здравствуйте. 

Сегодня Google объявил о закрытии Google Code Project Hosting. Сервис был запущен в 2006 году как масштабируемый и надёжный хостинг Open Source-проектов. С тех пор миллионы людей внесли свой вклад в проекты с открытым исходным кодом, размещённые на сайте.

Однако многое изменилось с 2006 года. За последние девять лет появились другие варианты хостинга Open Source-проектов, вместе с ними выросли и активные сообщества разработчиков. Пришло время признать, что миссия Google Code по предоставлению дома для Open Source была успешно выполнена другими проектами, такими как GitHub и Bitbucket.

Мы закроем Google Code в течение ближайших месяцев. Начиная с сегодняшнего дня, сайт больше не будет принимать новые проекты, но продолжит работать без изменений до августа 2015 года. После этого проекты будут доступны только для чтения. В начале следующего года сайт будет закрыт, но проекты будут доступны для загрузки в архивном формате.

Как у владельца следующих проектов, у вас есть несколько возможностей для миграции:

• globaleyes;

• tobal;

• subsucka;

• progit-example;

• simplegit.

Самый простой вариант — использовать Google Code Exporter, новый инструмент, который позволит экспортировать проекты напрямую на GitHub. Кроме того, у нас есть документация о том, как мигрировать на другие сервисы — GitHub, Bitbucket и SourceForge — вручную.

Для получения дополнительной информации, пожалуйста, посетите блог Google Open Source или напишите на google-code-shutdown@google.com.

- Команда Google Code

Итак, почему не Google Code?

BitBucket появился после GitHub, и у нас была фора, однако до нас существовали и другие хостинги кода. Так почему же не выиграли они?

В начале 2009 года Google Code добавил поддержку Mercurial, а SourceForge — поддержку Git и Mercurial. Если эти гиганты индустрии имели огромное преимущество по количеству пользователей и добавили поддержку DVCS всего через несколько месяцев после нашего запуска, почему они не утёрли нос нам, малышам? 

Мы не только были малышами, но и сидели без денег. Крис смог вложить в стартап немного денег, но все остальные были на мели. Внешнего финансирования мы не привлекали.

Когда Google Code запустил поддержку Mercurial, наш проект всё ещё состоял из четырёх разработчиков, которые пилили его из кафе на Саут-Бич на одном энтузиазме и без каких-либо венчурных инвестиций. В мае 2008-го мы договорились с приятелями из Engine Yard о помощи в оплате хостинга, потому что у нас не было денег.

Как получилось, что такая крошечная, безденежная команда уделала Google Code всего за несколько лет?

Примечание: финансирование GitHub

О финансировании: Грег в статье пишет что «венчурные инвестиции не были доступны сооснователям». Это чистая неправда. 

С первых же дней мы общались с венчурными инвесторами. В июле 2008 года ПиДжей написал мне, что они хотят, чтобы я присоединился к команде, и что все мы должны отказаться от работы и целиком посвятить себя проекту. Там же он упомянул: «Мы ведём переговоры с одним венчурным фондом, который нам очень нравится, и хотим собрать немного денег, чтобы кое-что сделать». Они планировали открыть офис, нанять пару сотрудников и так далее.

Деньги всегда были в досягаемости, их можно было привлечь буквально в любой момент. Но мы постоянно рассматривали и вдумчиво отвергали эту идею. Нам не нужен был офис. Нам не нужны были сотрудники.

Мало того, мы почти отказались от венчурных денег 4 года спустя, когда думали об А-раунде от Andreessen Horowitz в размере 100 миллионов долларов. Я отчётливо помню апрельский вечер 2012 года, когда мы ужинали в ресторане на Фолсом-стрит и горячо спорили, нужны ли нам вообще венчурные деньги. 

У нас на столе лежали предложения от a16z, Benchmark, Sequoia и Bessemer (практически самых крутых венчурных фирм планеты), а мы, четыре засранца, сидели и спорили о том, не стоит ли нам послать их. Другие технологические предприниматели, вероятно, убили бы за такие предложения.

Но дело было не в том, что мы не могли собрать деньги, а в том, что нам даже не пришлось этого делать, чтобы захватить рынок.

У GitHub был вкус

В статье Грега всё верно: другие хостеры фокусировались на дистрибуции и прибыли. Мы же заботились о разработчиках. Когда другие добавили поддержку Git, это ничего не изменило. У них просто не было вкуса. Их вообще не заботил рабочий процесс разработчиков. Так что с Git или без, они всё равно проиграли бы.

Можно говорить о фичах или «дополнительной ценности». Главная причина нашего успеха гораздо фундаментальнее, нежели лента активности, профили пользователей или что-то ещё. И она сохраняет актуальность для стартапов сегодня.  Дело в том, что мы развивали проект для себя, и это проявлялось во всём, что мы делали У нас был вкус. Нам был нужен хороший пользовательский опыт.

Мы были разработчиками и создавали инструмент, который позволил бы нам работать так, как мы мечтали. Наш проект был единственным, который разработчики создавали для разработчиков. Без PM’ов, бухгалтеров или CEO, пытающихся оптимизировать продукт для получения прибыли, а не для удобства инженеров.

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

Почему GitHub победил

Подведём итог: мы победили, потому что начали в подходящее время и у нас был вкус. 

Мы видели, как зарождалась новая парадигма, и старались помочь всем освоить её, ориентируясь на опыт разработчиков. Остальных игроков на рынке наш подход, похоже, не интересовал.

Думаю, вопрос в том, какие глобальные сдвиги в процессе разработки ПО ожидают нас в будущем и у кого хватит вкуса и смелости сделать их столь же прорывными?

P. S. 

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

• Как GitHub заменил SourceForge в роли доминирующей платформы для хостинга кода

• Настраиваем CI/CD с GitHub Actions и werf: инструкция для новичков

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