Григорий Петров: Open source или не open source?

«Open Source» — очень размытый термин. Я хочу рассказать про пользу open source в понимании Wikipedia: софт, исходники которого лежат в открытом доступе. Не важно, под какой лицензией софт — главное, что автор выложил исходники в открытый доступ и на них можно посмотреть. Обычно лицензия разрешает использовать исходники тем или иным способом и пользоваться софтом, скомпилированным из таких исходников. Но это все нам не интересно. Нам интересно, что исходники можно выкладывать, чтобы на них могли смотреть другие разработчики. И в этом я вижу огромную пользу.

Дисциплина

Один из самых простых трюков для дисциплинирования разработчиков: выделить их код в open source — пусть выкладывают на GitHub. И совершенно неважно, будет ли этим кодом пользоваться кто-то, кроме сотрудников вашей компании! Человеческий мозг работает ситуационно. Поставленный в ситуацию, где код потенциально могут прочитать миллионы людей, разработчик сразу же начинает его тестировать, комментировать и писать вменяемые сообщения к коммитам. Никто не хочет публично облажаться.

Эмоциональная вовлеченность

Выкладывание части своих наработок в open source добавляет эмоций. Психологически для человека огромная разница — пилить внутреннюю библиотеку для внутренней системы автоматизации, или же — крутую open source либу! Даже если последней никто, кроме компании, не будет пользоваться. Небольшая юридическая нагрузка для обеспечения корректности использования open source усиливает HR позиции компании. При умелом пиаре это привлекает крутых разработчиков, которым уже не так важны деньги, но очень важно заниматься тем, что нравится.

Коридор для лучших практик

Создать и поддерживать коридор — непросто. Человеческий мозг будет постоянно искать путь наименьшего сопротивления, и если какую-то работу можно не делать — ее не будут делать. Open source — хороший материал для строительства коридоров. Наличие кода в публичном доступе подключает наши социальные инстинкты. Становится проще продвигать best practices, тесты, документацию и все прочее, что борется со сложностью и поддерживает жизнь в софте. Достаточно магической фразы «ну мы же не хотим позориться перед сообществом!» — и всем участником сразу становится понятно на уровне «здравого смысла» — конечно не хотим! Это ведь в нашей природе.

Борьба со сложностью мясницким тесаком

Бороться со сложностью — тяжело. Контринтуитивно. Есть гипотеза, что наш мозг не очень хорошо приспособлен отслеживать небольшие изменения. Мы не замечаем, как стареют наши близкие, как по сантиметру в год поднимается уровень воды, вот это всё. Мы не замечаем накапливающейся сложности, пока «неожиданно» не оказывается, что сами уже не можем понять собственные 20 мегабайт исходного кода. Боязнь сложности приходит, когда несколько раз сталкиваешься с такими проблемами лично. Обычно это через 10-15 лет командной работы. Но мы же хотим привлекать в проекты и новых разработчиков, а не только убеленных сединами ветеранов?

И тут на помощь приходит open source. Публикуя небольшие части проекта, мы тем самым создаем удобный «коридор» для декомпозиции. У разработчиков не будет возможности намертво приварить друг к другу код разных модулей, если часть этих модулей open source, а часть — нет. Декомпозиция будет получаться естественным образом и не придется ее обсуждать на каждом первом совещании по архитектуре.

YAGNI, HIH и другие зверушки

Популярные когнитивные искажения в разработке: «давайте решим общий случай, вдруг пригодится» и «готовое решение не наш случай, давайте перепишем с нуля сами». С этим open source тоже помогает бороться. Чем больше наработок выложено в открытый доступ, тем меньше у разработчиков желания что-то делать про запас и поддаться YAGNI. Сложный психологический феномен — я еще не разобрался, почему это так (и так ли это). Но факт остается фактом: разработчик может годами пилить «общую шину данных» себе в стол. Но как только ему предлагают выкладывать наработки в общий доступ, он резко начинает писать только то, что нужно для дела. Подозреваю, это как-то связано с механизмами «социальной награды» и «социального порицания». Автор понимает, что код «про запас» не нужен никому, кроме него самого. И не хочет, чтобы такую «слабость» видели окружающие.

С NIH все несколько иначе. Выкладывание наработок в общий доступ просто приучает команду к мысли, что open source можно использоваться. Они уже им пользуются. Это сильно упрощает борьбу с «давайте все сами с нуля напишем».

А если вдруг придут люди…

… и посмотрят. Такое тоже иногда бывает! Выложишь в open source что-нибудь внутреннее, раскидывающее сайты по nginx или разворачивающее redis для юнит тестов. И буквально через неделю приходят совершенно незнакомые люди и рассказывают, что ты изобрел велосипед. И показывают, как все то же самое можно сделать уже существующим софтом.

Open source позволят команде «посмотреть со стороны» на свои разработки, пропиарить их в Facebook, рассказать на Hacker news или на Хабре. Недорогой способ провести исследование лучших практик без собственных исследований. Способ выявить фундаментальные недостатки, на которые «замылен» взгляд внутри команды.

… и людям понравится

Шансы того, что выложенное вами в open source обретет популярность, очень малы. Тем не менее, при должной настойчивости и минимальном пиаре, вы можете получить не только критику, но и заинтересованных разработчиков! Которые будут совершенно бесплатно тестировать ваши наработки, предлагать улучшения и рассказывать об использовании в реальных задачах. Такое редко, но бывает. И приносит огромную пользу, если вдруг «выстрелит». А какой лучший способ получить нужный результат среди случайных? Чаще кидать кубики.

Коридоры — это хорошо

Многие романтизируют open source, считая его социальным движением, возможностью сделать мир лучше и т.д. Но кроме фыр-фыр-фыр, open source еще и замечательный инструмент для построения коридоров в разработке. Которые позволяют команде уменьшить боль от создания софта. Применять лучшие практики «естественным» образом. Компенсировать недостатки человеческие природы. Сделать софт лучше.