Краткое руководство по выходу в opensource: кому это нужно, для чего и как
На прошлой внутренней конференции разработчиков Контура я выступал с докладом. В моей презентации был слайд, на котором были перечислены известные российские ИТ-компании, разделенные на два столбца. Между компаниями в правом и левом столбцах было одно весомое различие.
Я попросил зал ответить на вопрос, с какими компаниями вы себя больше ассоциируете? В каких, по вашему мнению, работают крутые инженеры, там интересно развиваться и туда интересно пойти работать, сотрудники этих компаний могут чему-то научить других, поделиться опытом?
На конференции коллеги почти единогласно проголосовали за компании из правого столбца.
Отличие их состояло в том, что они активно распространяют свои технологии и знания — делятся с профессиональным сообществом открытым кодом и понятными мануалами, выступают на конференциях. Они осознанно вкладываются в развитие своих opensource-проектов. Технологии и описания многих из них лежат в открытом доступе на специально созданных сайтах tech.yandex.ru, opensource.mail.ru, techno.2gis.ru/opensource, и известны многим разработчикам за пределами компаний.
Если вы вдруг решили заняться благотворительностью (почти) и сделать что-то подобное в своей компании, надеюсь, мой текст поможет ответить на вопросы: нужно ли это вам, сколько ресурсов потребуется и что в итоге получится. У нас вышел такой сайт: tech.skbkontur.ru.
У меня давно была идея сделать такой сайт для Контура. Многие наши команды успели обзавестись своими opensource-проектами, но широко их не распространяли по нескольким причинам: прямой прибыли не принесет, зато прибавит проблем и отнимет время. Нужна была мотивация, понимание того, нужно ли это делать вообще.
Для себя мы четко определили три «зачем», записали в гуглдоке и дополнили файлик некоторыми подробностями — так появился своеобразный регламент. Он может пригодиться тем, у кого есть желание выложить свой проект в opensource, но нет плана действий.
Зачем:
- Общее благо: обмен знаниями и навыками с внешним сообществом разработчиков; мы можем безвозмездно взять, доработать и использовать любой чужой opensource-код — пусть любой сможет взять код нашей открытой программы.
- Личный интерес: возможно, кто-то проникнется нашим opensource-проектом и придет работать в команду, которая его создала.
- Имидж технологической компании: рассказать о внутренних задачах, о том, как разработчики двигают вперед сами технологии и индустрию.
Набитые шишки и следующие из них правила
Проектом (о его подробностях читайте на Хабре), который мы первым выложили в opensource, стал самый большой и качественный из тех, которые у нас были. Мы тщательно подошли к его подготовке к самостоятельной жизни: написали документацию, вычистили специфические контуровские штуки и проверили на соответствие всем пунктам нашего регламента. Но у него оказалась достаточно узкая аудитория и специфичное применение, хотя в качестве исполнения нас было не в чем упрекнуть.
Первое, что мы быстро уяснили: opensource-проект, даже если он появился как побочный коммерческому, существует на тех же условиях, что основной. Нужно убедиться в том, что он будет кому-то полезен, его требуется протестировать, лицензировать и написать сопроводительную документацию. После выхода добавить маркетинговые и pr-мероприятия, сопровождение, популяризацию, выступления на конференциях и несколько статей об адаптации и особенностях применения. Затем реагировать на bug-репорты и pull-реквесты. Но не забывайте, что это opensource, а не коммерческий продукт. Значит, заниматься им придется параллельно с основной деятельностью и выделять время будет нужно часто по остаточному принципу или в ущерб личному времени (еще можно убедить руководителя и коллег в важности затеи — нам удалось, но сильно легче от этого не стало) :).
Второе: без качественной реализации проект обречен. Мы сформулировали набор правил и перед публикацией проекта прогоняем его на соответствие. Советуем вам начать с того же.
- Безопасность. Отдел информационной безопасности должен быть в курсе, что мы выкладываем, из проекта удаляем все куски кода, которые раскрывают особенности работы коммерческих сервисов компании.
- Качество. Публикация плохого кода только навредит имиджу компании и авторов. Мы привлекаем к code review проекта нескольких опытных разработчиков, чтобы найти и исправить недочеты. При этом придерживаемся общепринятых мировых opensource-стандартов (english language, readme.txt, code style, changelog.txt и т. д.), их соблюдение снижает порог входа для новых участников сообщества, значит, расширяет аудиторию.
- Маштабируемость. В идеале — проект должен быть модульным и легко маштабируемым. То есть должен легко расширяться. Чем легче расширять продукт, тем ниже порог входа для новых участников сообщества.
- Тестирование. Перед выкладкой проверяем код на работоспособность, мы в этом случае используем автотесты и опираемся на открытые инструменты тестирования, включающие интеграцию с репозиторием (например, GitHub & Travis CI).
- Лицензирование. Выкладывание кода должно быть законным, лицензия согласована с юридическим подразделением. Тут важно помнить, что код обычно публикуется под одной из распространенных opensource-лицензий (MIT, GPL, BSD и т. д.). Мы, как правило, используем MIT, но если внутри проекта есть куски кода, лицензированные под GPL, то и весь проект приходится тоже лицензировать под GPL.
Документация. Если продукт слишком большой, чтобы описать его в одном тексте README, мы сопровождаем продукт документацией, отвечающей на вопросы:
- как начать пользоваться (quickstart)
- как скомпилировать и установить (building & installing)
- как запустить (running)
- как протестировать свои правки (testing)
- как настроить (configuration)
- какие есть примеры использования (examples)
Третье. Один проект с открытым кодом ничего не даст компании. Даже если вы очень круто его сделали, выложили, выступили на конференции, написали на Хабре и приготовились ждать обратной связи… это не означает, что поток страждущих снесет все на своем пути, чтобы скачать ваш код и использовать в своем сервисе.
Сейчас на нашем сайте десять проектов с открытым кодом. Все они — сопутствующие продукты, которые появились во время работы над коммерческими сервисами Контура, или переработанные для своих нужд продукты из открытых источников. И в этом вся суть opensource«a — продукт или сервис никогда нельзя считать законченным; то, что мы получаем на определенном этапе, — результат коллективной работы, дополнений ребят из разных компаний, городов и даже стран.
Надо признать, что в opensource мы пока среди догоняющих: не так много проектов, они только начинают распространяться. Но для нас было важно начать выкладывать разработки, не отступать от задуманного. Если, прочитав этот текст, вы решите, что вашей компании есть чем поделиться в opensource-пространстве и не жаль потратить на это свои силы и время, — значит, я не зря писал эту статью.
