На прошлой внутренней конференции разработчиков Контура я выступал с докладом. В моей презентации был слайд, на котором были перечислены известные российские ИТ-компании, разделенные на два столбца. Между компаниями в правом и левом столбцах было одно весомое различие.
Я попросил зал ответить на вопрос, с какими компаниями вы себя больше ассоциируете? В каких, по вашему мнению, работают крутые инженеры, там интересно развиваться и туда интересно пойти работать, сотрудники этих компаний могут чему-то научить других, поделиться опытом?
На конференции коллеги почти единогласно проголосовали за компании из правого столбца.
Отличие их состояло в том, что они активно распространяют свои технологии и знания — делятся с профессиональным сообществом открытым кодом и понятными мануалами, выступают на конференциях. Они осознанно вкладываются в развитие своих 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-пространстве и не жаль потратить на это свои силы и время, — значит, я не зря писал эту статью.
mav5555
Вы меня извините, но первое всё-таки, это конкретный идейный вдохновитель, ну или пару вдохновителей, т.е. реальный человек или группа единомышленников, которые четко понимают и разделяют философию свободного ПО (кстати open source не всегда бывает свободным). Втрое — это что-то вроде манифеста, в котором кратко формулируются принципы и намерения этой инициативы/движения/сообщества. И третье, самое главное, — это само сообщество. Без сообщества не бывает совместной продуктивной разработки.
Без этих пунктов ни о какой open source причастности говорить не имеет смысла.
Все ваши пункты, которые вы привели; безопасность, качество кода и т.п. — это уже техника вопроса, которая несомненно важна, но является следствием.
Я перечислил фразы из текста, которые лично мне резанули слух и говорят о том, что вы, к сожалению, так и не поняли сути open source и свободного ПО:
— Они осознанно вкладываются в развитие своих opensource-проектов.
— … но широко их не распространяли по нескольким причинам: прямой прибыли не принесет…
— Личный интерес: возможно, кто-то проникнется нашим opensource-проектом и придет работать в команду, которая его создала.
— Но не забывайте, что это opensource, а не коммерческий продукт.
— Один проект с открытым кодом ничего не даст компании.
— И в этом вся суть opensource’a — продукт или сервис никогда нельзя считать законченным.
Не буду пересказывать известные постулаты про то, что такое open source, кому и зачем он нужен, мотивацию участников, почему он доказал свою состоятельность как идеология и почему некоторые крупные «закрытые» компании вдруг спохватились и начали вскакивать на подножку уходящего поезда.
Скажу только, что манифест, к примеру, был у проекта Debian, одного из самого стабильного и долгоиграющего linux проекта до сих пор. Разработчики поверили основателю, разделили саму идею и пошли; не за Яном Мёрдеком, а за проектом! Это надо понимать. Open source — это не значит без прибыли с точки зрения коммерции (тому успешный опыт Red Hat тогда и Nginx Inc сейчас). А CMS Drupal, к примеру, это результат совместного творчества и работы огромного международного сообщества — десятков тысяч разработчиков и сотен тысяч сайт-билдеров (не просто пользователей, хочу заметить, тех ещё больше), управлять которым приходится специально созданной для этих целей Ассоциацией. Попробуйте спросить их — зачем им это всё нужно? Вы застанете их врасплох. :) А ответ уже давно дал Линус Торвальдс, правда тогда над ним посмеялись, и если очень кратко, то он имел ввиду синергию и обратную связь в open source сообществе. И если упомянуть всё тот-же Drupal, то знаете какой у них слоган? “Come for the software, stay for the community”. Гениальный слоган-призыв! Всё прямо по старине Линусу:) Сейчас, когда интернет стирает границы и совершенно не важно где ты находишься физически, когда начали во всю использоваться системы контроля версий и совместной удаленной разработки — его предсказание сбылось. Ни одна «закрытая» коммерческая структура не в состоянии угнаться по количеству строк кода в единицу времени, по его качеству за открытыми сообществами и их продуктами!
И то, что вы начали выкладывать свои разработки — это правильно и возможно приносит пользу вашим партнерам. И если не до конца разобрались со стратегией входа в open source, тоже не проблема — акцентируйтесь на спонсировании докладчиков/разработчиков/конференций или сообществ, продуктами которых вы пользуетесь. А там дальше сами сообразите как быть.
Ещё раз прошу прощения за сей назидательный тон и критику, с уважением к вашей компании.
BeeVee
Спасибо за развернутый комментарий — это сейчас редкость в интернете :)
Согласен со многими вашими аргументами. Прежде всего с тем, что в компании должен быть идейный вдохновитель или команда энтузиастов. Моя статья — про то, с какими задачами и препятствиями столкнется этот идейный вдохновитель внутри средней или большой компании, которая раньше не уделяла никакого внимания opensource. Я не пытался написать манифест о великом благе opensource — есть люди, которые уже сделали это, и сделали гораздо лучше, чем я когда-либо смогу. Многие из этих манифестов вы упомянули — спасибо за хорошее дополнение к статье.
В качестве энтузиаста opensource в Контуре выступаю я сам. В статье я хотел поделиться внутренними задачами/проблемами/препятствиями, которые ждали меня на этом пути, и, вероятно, будут ждать других энтузиастов в больших компаниях.
Реальность такова, что о вкладе компании в opensource придется поговорить как минимум с одним нетехническим топ-менеджером. Успех этого разговора во многом зависит от того, умеете ли вы объяснять пользу от opensource для компании — простую, меркантильную пользу, помимо высшего блага для людей во всем мире.
А еще нельзя просто взять и выложить код, не поговорив об авторских правах с юристами. Даже если они будут не против — возможно, они захотят поучаствовать в выборе лицензии или заключить какие-то дополнительные соглашения с разработчиками по поводу авторских прав (у нас так было). Ну и далее по тексту статьи. Об этом необходимо позаботиться не то чтобы для успеха затеи — а для того чтобы не облажаться в самом начале. Мы ведь сейчас в самом начале пути.
Спасибо еще раз за замечания и советы.
mav5555
Я не это имел ввиду. В вашем случае, мне кажется, в роли манифеста должен быть всего лишь один вступительный абзац на сайте tech.skbkontur.ru, подписанный конкретным человеком, пробежав который стало бы понятно зачем вы выкладываете наработки и каковы ваши намерения в будущем (да, я прочитал kontur.ru/press/news/company/2016/12/5789 — но это не то). А так сейчас ну выложили и выложили… Дальше то что? Где правила, принципы, права участников? Кто мне, как гипотетическому разработчику, даст гарантии, что мой вклад в какой нибудь из этих проектов будет принят или не удален впоследствии? Почему я должен вам верить? Кому конкретно? Вам, Алексей, может быть я и поверю. Но у вас есть шеф, а над ним есть ещё акционеры — они-то что говорят по вашей инициативе? Где почитать? Где посмотреть? Негде? Тогда извините…
Но я не разработчик, хотя и имею к этому некоторое отношение. Я просто стал на место разработчика и задал вам только часть вопросов. А на самом деле их гораздо больше.
Теперь с позиции владельца компании-разработчика. Какие могут быть у него вопросы.
Верно. Если владелец компании или топ-менеджер не понимает основных тенденций в сфере разработки и в частности open source, то лучше и не начинать, иначе внутренний конфликт неизбежен. Если понимает, то тут всё зависит от вас — нужно ли вам это в принципе и удастся ли вам ответить ему:
— будет ли и каким образом решён кадровый дефицит в компании или, к примеру, качество кадров если проблемы с кадровым голодом нет;
Да, я обратил внимание, что вы участвуете в различного рода образовательных программах при ВУЗ-ах, но это только очевидная деятельность. Но на ряду с этим есть и другие менее очевидные законные, но очень эффективные меры привлечения высококвалифицированных кадров, но я не могу с полной уверенностью сказать, что вы их применяете. Не встречал пока внешних признаков у вас.
— будет ли материальный эффект и как его оценить, если компания начнет спонсировать открытые сообщества разработчиков каких-нибудь родственных вам проектов? Ну как к примеру делает Microsoft -> Canonical -> Ubuntu или IBM -> GNU/Linux. И таких примеров в последнее время всё больше и больше.
Как оценить финансовый эффект, какие формы контрибуции выбрать (по возрастающей затрат) в первом приближении расчитать можно, но тут нужно иметь доступ к коммерческой информации в компании (ФОТ, налоговые отчисления, затраты на рекламу, фин модель бюджетирования). И если такого доступа у вас нет — следовательно ответить владельцу по части окупаемости open source инициативы вы не сможете. «Сроки окупаемости», если так можно выразиться, естественно — это не год и не два, если вообще можно использовать этот термин в разрезе open source :)
— какие формы контрибуции будут в рамках бизнес-плана компании, а какие нет?
К примеру, вы решили спонсировать разработчиков некой open source CRM и интегрировать её в своё SaaS решение, ну к примеру в туже Эльбу. Понятно, что тут нужно для начала посмотреть на цифры: разработать CRM своими силами и потом её поддерживать, или влиться в сторонний открытый проект и тем самым решить ряд своих задач и в тоже время потребостей стороннего сообщества? Продвинутый владелец бизнеса будет склоняться ко второму варианту, даже если очевидной материальной выгоды на первом этапе он не увидит. Думаю, что не нужно объяснять, какие другие выгоды он получит взамен.
Теперь с позиции потребителя.
Я владелец небольшой приземленной компании. И как пользователь онлайн бухгалтерии (не скрою — от вашего прямого конкурента) вообще не вижу пользы для своей компании от инициативы tech.skbkontur.ru. Там какая-то магия для меня — ничего не понять. Нет, я конечно понимаю, что там и кому это нужно, но сейчас я в роли обычного предпринимателя далекого от разработки. Я расчитывал увидеть что-то вроде свободного электронного документооборота или финансовой аналитики, которую можно скачать, установить на свой сервер и использовать. И да, я готов доплачивать за расширенную поддержку (установить на сервер или востановить после аппаратного сбоя) или за дополнительный функционал. Но этого я у вас не нашёл (может плохо смотрел?).
Понятно, что изобретать очередной ownCloud или Seafile уже поздно, но ведь всегда можно подключиться к этим сообществам и заявить о себе в том или ином качестве. Как? Вариантов опять же масса.
Лично я по работе сейчас использую Linux, как основную ОС на рабочих местах, Drupal как систему управления контентом (проще — сайт компании), Seafile как аналог дропбокса, LibreOffice (электронные таблицы) для финансового моделирования. И всё это работает, не глючит и апдейтится чаще, чем проприетарные продукты. Не сочтите за пропаганду, это уже просто факт. В свою очередь даю обратную связь разработчикам, получаю от них оперативные ответы, иногда пишу багрепорты, спонсирую по мере сил или времени в знак благодарности за продукт. Это уже просто другой уровень бизнес-отношений.
И возвращаясь к вам, в целом, для каждого конкретного бизнеса должен быть свой конкретный подход по части открытости или участия в open source инициативах. Тут нет одного проверенного рецепта. Нужно всё взвешивать и оценивать в комплексе.
Emelian
Я бы лично в качестве манифеста опенсорса выдвинул был идею Цифрового Коммунизма Сергея Хапрова. Можно было бы говорить даже о победе Цифрового Коммунизма (ЦК) над отдельно взятой коммерческой программой, это когда проприентарный код выкладывается в открытый доступ. А также над ползучей победой ЦК во всем мире :).
Более того, со стороны государства я бы даже спонсировал, явно или неявно, некоторые общественно-полезные программные продукты вроде ReactOS и бесконечное множество других. Критерием успешности проектов могла бы быть интенсивность их использования пользователями и программистами. А государства могли бы иметь на это средства в т.ч. и за счет относительно небольшого цифрового налога взимаемого со всех, кто получает какой-либо доход.