10 лет на GitHub
В этом декабре исполняется ровно 10 лет с тех пор, как я зарегистрировался на GitHub! Хороший повод рассказать о своем опыте работы с платформой, порассуждать о системах контроля версий и, в целом, о том, как они повлияли на современное состояние IT.
GitHub появился в 2008 году. Вопреки распространенному мифу, Git != GitHub. Сама система на несколько лет старше и была разработана совсем другими людьми, а именно – Линусом Торвальдсом и его коллегами-разработчиками ядра Linux. Git очень быстро завоевал признание всех хакеров и вытеснил популярный в то время Subversion. Многие также считают, что СПО = GitHub, но и это заблуждение. Репозитории и архивы свободного кода появились в Интернете очень давно, и далеко не всегда их авторы вообще использовали какие-либо системы контроля версий, так как попросту не всем были доступны серверы, на которых их можно было настроить. Я еще помню, как пересылали diff-файлы по почте! До того, как весь мир пересел на Git, я пользовался SVN и репозитории хранил в Google Code. SVN был довольно медленный и не слишком удобный, а интерфейс Google Code – так себе даже по меркам того времени, но это все же было лучше, чем ничего.
Поводом зарегистрироваться на GitHub стал переезд туда всех активных свободных проектов в сообществе D. До этого основной площадкой для D-шников был dsource.org, и я начал пользоваться языком аккурат в этот перестроечный промежуток – время D1 и dsource.org уходило, а GitHub-проекты на D2 еще можно было пересчитать по пальцам. Моя библиотека dlib – один из самых старых живых проектов родом из той эпохи.
В конце нулевых о сложности Git ходили легенды и анекдоты – была шутка, что никто в мире по-настоящему не понимает rebase (по аналогии с известным изречением Фейнмана по поводу квантовой механики). На самом деле, овладеть Git на базовом уровне очень легко, и абсолютное большинство взаимодействий с ним сводятся к простым add, commit и push. И даже конфликты слияния – не бог весть что. За все эти годы самое головоломное, что я делал – это принятие pull-реквеста, отправленого в master, в другую ветку репозитория.
В сущности, для СПО контроль версий – не есть что-то обязательное даже в наше время. Можно просто выкладывать архивы с кодом на сервер и ни о чем не беспокоиться. Но именно благодаря Git и GitHub произошла революция, которой мы обязаны бумом IT в 2010-х годах. С самого начала фишкой GitHub было удобное создание форков и наличие интерфейса для того, чтобы предлагать изменения из форка в апстрим. Это позволило участвовать в развитии свободных проектов огромному числу новых людей. До того, как этот процесс был стандартизирован, каждый проект использовал свой порядок приема патчей, и человеку “с улицы” войти в этот мир было непросто – кроме того, было затруднено взаимодействие проектов друг с другом. Благодаря GitHub в полной мере реализовалась концепция “базара” Эрика Реймонда, описанная им еще в 90-х – разработка СПО в открытом режиме, когда код со всеми свежими изменениями доступен публично (в противовес “соборной” модели, когда исходники публикуются в виде релизов, но доступ к нестабильному коду есть лишь у ограниченного круга разработчиков). Преимуществом “базарной” модели является так называемый “закон Линуса”: “При достаточном количестве наблюдателей ошибки выплывают на поверхность”, то есть, доступность исходников всем желающим приводит к тому, что софт гораздо лучше тестируется на баги и уязвимости.
Все это сделало свободный софт более качественным и привлекательным для массового пользователя, чем когда-либо, а также привело к стихийному улучшению стандартов программирования – ведь если вы размещаете свой код публично, отдавая его на суд неограниченного круга лиц, вы постараетесь не допускать очевидных ляпов, будете использовать хорошие практики, сделаете его более читаемым и эстетичным, снабдите комментариями и т.д. GitHub стал вселенским центром притяжения, вокруг которого завращались небесные тела IT-инфраструктуры: появились универсальные CI-сервисы, инструменты измерения покрытия кода, интеграции с менеджерами пакетов – все, что внедрял GitHub и другие код-хостинги, быстро становилось стандартом, и вскоре корпоративный сектор и OpenSource стали взаимосвязанными частями единой инфосферы. И уже не корпорации задают планку свободному софту, а наоборот.
В 2018 году состоялось знаковое событие – покупка GitHub компанией Microsoft за $7,5 миллиардов. Поначалу смысл этой сделки был не совсем ясен – откуда у MS такой интерес к свободному коду? Очередная попытка руководства улучшить репутацию компании в глазах хакеров и хипстеров? Но через несколько лет стало понятно, в чем тут заключается коммерческая целесообразность: MS запустили сервис GitHub Copilot – платный инструмент автозаполнения кода с использованием нейросети, натренированной на исходных текстах тысяч свободных проектов. Появление Copilot поднимает множество вопросов этического характера – MS, по сути, зарабатывает на бесплатном труде миллионов разработчиков. Использование СПО для машинного обучения – юридически серая зона: можно ли считать это созданием производной работы? Если да, то MS будет обязана открыть исходный код своего сервиса, поскольку в нем задействованы в том числе проекты с копилефт-лицензиями. При этом сама компания пытается это оспорить, заявляя, что обучение нейросетей на общедоступных данных – это добросовестное использование, не влекущее обязанности соблюдать условия лицензий.
Что же будет дальше? GitHub стал критически важным сайтом для функционирования всего IT, а значит – вообще всей современной экономики. Осознание этого факта немного пугает. Если по какой-то причине GitHub со всеми пользовательскими репозиториями исчезнет, это будет непоправимой катастрофой. Дело даже не в риске безвозвратно потерять код (думаю, что у разработчиков сохранятся резервные копии всего важного), а в том, что перестанут работать механизмы, сервисы и технологические решения, априорно полагающие, что GitHub существует и работает – например, многие менеджеры пакетов. Без рабочего NPM встанет вся фронтенд-разработка, и все негативные последствия этого даже сложно вообразить.
