[Перевод] Открыть исходники (почти) всего08.02.2016 10:33

На этот раз я бы хотел предложить к прочтению [вольный] перевод статьи Тома Престон-Вернера, одного из сооснователей GitHub, в которой он рассуждает о том, какие выгоды компания может извлечь из открытия своих проектов, какие проекты открывать не стоит и какова Единственно Правильная Лицензия. Хочу также отметить, что мнение переводчика не всегда совпадает с мнением автора оригинала. Ссылка на оригинал, как всегда, под текстом перевода.

Когда Крис и я начинали работу над GitHub в конце 2007, мы разделили работу на две части. Крис работал над Rail-приложением, а я работал над Grit, первым в истории адаптером Git для Ruby. После шести месяцев разработки, Grit стал достаточно законченным, чтобы обслуживать GitHub во время нашего публичного запуска сайта и мы встали перед интересным вопросом:

Стоит ли нам открыть исходники Grit или оставить его проприетарным?

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

Почему открыть исходники (почти) всего круто?

Если вы все делаете правильно, то открытые исходники это отличная реклама для вас и вашей компании. В GitHub нам нравится публично обсуждать библиотеки и системы, которые мы разработали и которые ещё закрыты, но обречены стать открытыми. Этот подход имеет несколько преимуществ. Это позволяет определить, что именно открыть и как много внимания надо этому уделить. Недавно, к всеобщему восторгу, мы открыли исходники Hubot, нашего чат-бота. За пару дней он набрал 500 подписчиков на GitHub и 409 голосов на Hacker News. Это выражается в одобрении GitHub и ещё большем количестве фанатов, чем когда либо ранее.

Если ваш код популярен настолько, что привлекает сторонних контрибьюторов, то вы создадите усиливающий эффект, который помогает выполнять больше работы дешевле. Больше пользователей означает что исследуется больше сценариев использования, что означает более надёжный код. Наш проект resque был улучшен 115 разными разработчиками вне компании, и ещё сотнями, предлагающими сторонние плагины, расширяющие функциональность resque. Каждое исправление ошибки, которое вы принимаете в проект, это сэкономленное время и раздражение потребителя, которого удалось избежать.

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

Если вы нанимаете разработчиков, то лучшее техническое собеседование это то, которое вам не нужно проводить, потому что разработчик уже проявил себя в одном из ваших открытых проектов. Как только технические навыки было предъявлены таким способом, всё что остается это убедиться в соответствии корпоративной культуре и убедить этого человека работать на вас. Если они увлечены открытым кодом, который они писали, и вы относитесь к тем компаниям, которые заботятся о качестве кода (а вы, очевидно, заботитесь), это должно быть просто! Мы наняли Висента Марти (Vicent Martí), после того, как мы увидели его яркую работу над libgit2, проектом который мы инициировали для извлечения функциональности Git в отдельную библиотеку на C. Технического собеседования не требовалось, Висент уже продемонстрировал свои навыки с помощью открытого кода.

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

Когда я начинаю новый проект, я предполагаю что он, в конечном счёте, будет открыт (даже если это маловероятно). Такая установка без усилий приводит к модульности. Если вы думаете о том, как другие люди, вне вашей компании, могут использовать ваш код, меньше шансов, что вы станете использовать проприетарные компоненты или жёстко связанные интерфейсы. Это, в свою очередь, приводит к более чистому и более поддерживаемому коду. Даже внутренний код должен притворяться открытым.

Вы когда-нибудь разрабатывали замечательную библиотеку или инструмент на одном месте работы, а затем увольнялись, чтобы присоединиться к другой компании только для того, чтобы переписать этот код или стать несчастными из-за его отсутствия? Я да, и это отстой. Публикация кода позволяет резко сократить дублирование усилий. Меньше дублирования означает больше работы над более важными вещами.

Наконец, это правильно. Сейчас почти невозможно что-то делать без прямого выполнения большого количества открытого кода. Если вы пользуетесь интернетом, то вы пользуетесь открытым кодом. Этот код олицетворяет миллионы человеко-часов, которые были потрачены для всеобщего блага. Мы все получаемы удовольствие от этой выгоды, и я верю, что мы все морально обязаны отплатить этому сообществу. Если программное обеспечение это океан, то открытый код это прилив, снимающий с мели корабли.

Ладно, но что я не должен открывать?

Это просто. Не открывайте ничего, что является основой бизнеса.

Вот несколько примеров того, что мы не отрываем, и почему:

• Основное Rails-приложение (его проще продавать, когда оно закрыто)
• Sinatra-приложение для управления задачами (специально тесно завязано на github.com)

А вот примеры того, что мы открыли, и почему:

• Grit (адаптер для Git общего назначения, полезен для разработки множества инструментов)
• Ernie (RPC-сервер общего назначения для BERT)
• Resque (очереди общего назначения)
• Jekyll (генератор статических сайтов общего назначения)
• Gollum (wiki общего назначения)
• Charlock_Holmes (определитель кодировок символов общего назначения)
• Albino (подсветка синтаксиса общего назначения)
• Linguist (определитель типов файлов общего назначения).

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

Какова Единственно Верная Лицензия?

Я предпочитаю MIT и почти всё, что мы в GitHub открываем, распространяется под этой лицензией.

Я люблю эту лицензию по нескольким причинам:

• Она короткая. Любой может её прочитать и понять что конкретно она означает без необходимости потратить кучу денег на консультации с высокооктановыми юристами.
• Она предоставляет достаточно защиты, чтобы быть уверенным, что вы не засудите меня, если что-то пойдёт не так, когда вы используете мой код.
• Все понимают её правовые последствия. Странные лицензии, вроде WTFPL и Пивной лицензии (Beer license) претендуют на звание «самой свободной лицензии», но совершенно не достигают этой цели. Эти хитрые лицензии слишком расплывчатые и неисполнимые, что быть применимыми для некоторых компаний. С другой стороны, GPL слишком ограничивающая и догматичная, чтобы быть подходящей во многих случаях. Я хочу, чтобы мой код был полезен всем. Всем. Вот что должно значить Открытый, и вот что должно означать Свободный.

Как я могу начать?

Легко, просто сдвиньте этот переключатель на вашем репозитории на GitHub из «закрытый» в «публичный» и расскажите миру о вашем проекте с помощью вашего блога, твиттера или Hacker News и за кружкой пива в местном пабе. Затем откиньтесь на спинку стула, расслабьтесь и наслаждайтесь тем, что вы часть чего-то большего.

P.S. От себя хочу предложить читателям поучаствовать в опросе, чтобы выявить судьбу открытых проектов читателей.

© Habrahabr.ru