Как бы вы руководили разработкой крупнейшего проекта с открытыми исходниками, в котором порядка 15 тыс. разработчиков и 222 компании вносят более 12 тыс. изменений между релизами или 7 / 8 правок каждый час? Чем пользуются создатель кернела Линус Торвальдс, мейнтейнер стабильной ветки  Грег Кроа-Хартман (GKH) и другие товарищи, чтобы успешно координировать работу проекта и обеспечивать своевременный выход каждой новой версии? Этим чудо-инструментом является текстовый клиент электронной почты: Mutt у GKH и Alpine у Линуса Торвальдса. Третий по рангу разработчик ядра Эндрю Мортон, также вовсю использует электронку для управления mm веткой.  Вспомним, как все начиналось. 25-го августа 1991 г. никому неизвестный финский студент написал письмо в новостную группу comp.os.minix, в котором анонсировал свою работу над свободной операционной системой и скорое ее завершение. В октябре того же года он выложил версию 0.0.2 на ftp в директории Linux, известил об этом комрадов хакеров и понеслось... С самого начала разработка осуществлялась распределенной командой энтузиастов. Первое время Линус Торвальдс проверял каждый патч, переписывал и сам же его устанавливал. Команда росла, патчей становилось все больше, ядро росло и усложнялось. Пришлось патчи ставить на скорую руку, зачастую без всяких изменений. В этой ситуации Линус принял единственно верное решение — делегировать и доверять работу, тем у кого получается. Этот процесс хорошо иллюстрирует письмо известное как Линус не масштабируется, в котором Линус жалуется на перезагрузку перегрузку и предлагает назначить мейнтейнеров различных подсистем ядра.  Тем не менее к 2000 г. стало понятно, что нужна система контроля версий. Народ стал роптать, что разработка тормозится из-за механического способа работы Линуса. Это было сущей правдой, и тогда команда взяла на вооружение BitKeeper, который в то время являлся закрытым программным продуктом, предоставляемым бесплатно разработчикам открытых программ. Прагматичному Линусу это было до лампочки, но в команде были и принципиальные ребята, не глухие к голосу Ричарда Столлмана, готовому без устали гвоздить все то, что содержит хоть байт закрытого кода. Alan Cox — программист написавший первый приличный сетевой стэк для ядра, был одним из них. Какое-то время все шло вроде бы неплохо, BitKeeper значительно облегчил жизнь разработчикам. Им не надо было больше заботиться о том, кто имеет права на какие изменение, каждый из них мог работать в своей ветке древа исходников, возможность распределенных слияний исходного кода давала значительную экономию усилий для всех. Подспудно, назревал кризис, который и привел к созданию Git. Затем автор Самбы Tridge (Andrew Tridgell) захотел сделать то, что умел делать лучше других — осуществить обратную разработку BitKeeper, чего по условиям лицензии деть было нельзя ни в коем случае. Разгорелся конфликт, Линус пытался его погасить, но не преуспел в том. И тогда он взял и за один день написал Git. Что было дальше — всем известно: в таком деликатном и консервативном сегменте ПО как VCS, Git сумел всего за несколько лет опрокинуть конкурентов. Недавно мейнтейнер стабильной ветки Linux ядра Грег Кроа-Хартман, выступая на одной конференции, выложил свои доводы  за текстовую электронную почту и против использования систем совместной разработки, инспекции исходного кода, таких как GitHub или Gerrit.  Перечислив те очевидные достоинства, благодаря которым GitHub обрел огромную популярность среди разработчиков, докладчик несколько раз подчеркнул, что тот отлично работает для небольших проектов, но для крупных не годится, так как плохо масштабируем. В доказательство этого тезиса он привел Kubernetes, с 4600 открытыми заявками и около 600 pull request-ами. В презентации эти цифры были на 10% ниже. 
Другие претензии GKH к Гитхабу: Впрочем, докладчик несколько раз сделал оговорку, что некоторые проблемы постепенно находят решение, сервис постоянно меняется в лучшую сторону. Сам Грег хостит usbutils на Гитхабе. Остальным системам совместной разработки и инспекции исходников и вовсе досталось на орехи: единственным аргументом за использование Gerrit оказался тот факт, что он люб менеджерам проектов. Не удивительно, что больше всего похвал собрала текстовая электронная почта. Тезисы за емайл были таковы. Первые три пункта на самое деле разные грани одного и того же: емайл прост и доступен каждому. Слепому, а по словам GKH в проекте есть ряд классных, но слепых программистов, электронная почта доступна а WWW — нет. Тем, кто сидит за корпоративным файрволом, git недоступен, а с электронкой никаких проблем нет. Мейнтейнеры часто путешествуют, выступают на конфах меняют пароли и явки и им проще дождаться подключения к сети интернет, скачать и отправить письма, нежели найти время и место, чтобы проверить статусы заявок в Gerrit. Кто-то умудрялся подолгу путешествовать на велосипеде по Африке и таки присылать патчи по расписанию. Четвертый пункт тоже очень важен. Каждые недели-две в поле зрения GKH появляется новобранец. Ему стандартно советуют включится в список рассылки и просто побыть недельку в режиме read-only, чтобы составить впечатление о происходящем и вникнуть в детали. Это очень хороший способ отличить важные темы от второстепенных, выявить глубину и детализацию обсуждаемых проблем. В то же время, если отправить новичка почитать форумы где-то там, то это может встретить непонимание и обиду. Остановимся теперь подробнее на некоторых недостатках использования plaintext электронной почты, как основного инструмента управления и разработки Linux. Так называлась запись в блоге Грега, в котором он рассказывает о трудовых буднях с электронной почтой.  
Причем, эти цифры постоянно растут! Судя по всему GKH неплохо масштабируется. О том как должен выглядеть образцовый патч написано в Documentation/SubmittingPatches. Никаких MIME и прочих глупостей, только plaintext. Патч должен содержаться в теле письма, а не быть к нему прикреплен. Как будто не сложно, но на самом деле не все почтовые программы справляются. В числе главных неосиляторов  MS Outlook, Gmail (Web UI) и Lotus Notes.  Компании, которые их используют, всегда имеют выделенную рабочую станцию Linux для отправки патчей. Помимо всего прочего, в числе 16 правил четко определены формат темы и содержания сообщения. Зачастую, с письмами случаются странные казусы. Линус жалуется, что KMail Дмитрия Торохова надо сжечь к чертям, так как он портит пробелы и табуляции, из-за этого копипаста выдает мусор.  Еше могут возникнуть проблемы взаимопонимания между программистом и мейнтейнером. Комментарий на LWN в переводе.  Трудно отделаться от впечатления, что Линус со товарищи канонизировали свои старые привычки 1990-х. Это и есть субъективная фактор, но он же упирается в фактор объективный. Хакеры, создавшие ядро Linux 25 лет назад, благодаря чему сообщество открытого ПО обрело материальную силу и нравственное лидерство, умеют с большой отдачей созидать именно таким способом. Если взять талантливых выпускников  и полностью заменить ими всех мейнтейнеров, то через год-два они сами перейдут на GitHub, или напишут что-то свое и будут на слайдах доказывать, насколько повысилась их продуктивность. Доказательством могут служить наличие сопоставимо крупных проектов, которые спокойно творят без патчей в теле текстовых писем. Также Гугл использует Gerrit, для разработки Android. В качестве резюме, предлагаю комментарий на LWN.  А что думает по этому поводу Хабр? BigData