В сентябре на сайте Гарвардской школы бизнеса (HBS) появилась статья о важности open source. Её авторы заявляют, что ИТ-компании, участвующие в open source проектах и делающие свое проприетарное ПО открытым, получают конкурентное преимущество на рынке. Мы решили обсудить эту тему и поговорить о плюсах и минусах такой стратегии.
/ Pexels / Syed Abdullah / PD
Когда руководство компании позволяет разработчикам участвовать в развитии открытых проектов, сотрудники приобретают новый практический опыт и знания. При этом разработчиков не нужно отправлять на дополнительные тренинги или курсы. Это экономит деньги компании, а программисты обучаются за счет решения нескучных и полезных для ИТ-сообщества задач.
Большую часть кода — 85% — ядра Linux пишут сотрудники крупных ИТ-компаний. Среди них числятся: Intel, Red Hat, IBM и др. Разработчики первой внесли 13% изменений в последние версии ядра, специалисты второй «ответственны» за 7%, а IBM — за 4%.
Программисты из этих корпораций отмечают, что работа над ядром позволяет им изучить Linux изнутри, разобраться во «внутренностях» подсистем и внести личный вклад в развитие самого крупного open source проекта. Полученные практические навыки они впоследствии применяют для решения корпоративных задач.
Когда корпоративный продукт становится частью open source (при условии, что на этот продукт в ИТ-сообществе есть спрос), вокруг него начинает постепенно форматироваться комьюнити.
Когда в 2005 году разработчик Люк Канис (Luke Kanies) создавал клиент-серверное приложение Puppet, он изначально планировал привлекать пользователей за счет свободного распространения ПО. В итоге так и получилось — теперь его инструмент для автоматизации управления ОС используют 40 тысяч компаний, 75 из которых входят в рейтинг Fortune 100.
Здесь действует простое правило: чем больше человек участвуют в разработке, тем выше скорость релизов. Взять, к примеру, Linux — новые версии ядра этой ОС выходят каждые два месяца, а обновлений других операционных систем иногда приходится ждать несколько лет.
Еще пример: Google используют внутри компании открытый фреймворк Angular и вкладывают ресурсы в его развитие. Когда к проекту подключились сторонние веб-разработчики, Angular быстро обзавелся новыми инструментами и расширениями. От этого выиграли все.
Растущее комьюнити позволяет не только быстрее выпускать новые версии приложений, но и помогает фиксить баги. Из-за того, что исходный код открытого ПО на наличие уязвимостей может просмотреть кто угодно (включая экспертов по ИБ), он считается более безопасным. И эта идея все чаще находит «отклик в сердцах» различных компаний.
/ Flickr / Henri Bergius / CC BY-SA
В августе этого года Илон Маск опубликовал в Twitter запись о намерении сделать программное обеспечение, отвечающее за безопасность автомобилей Tesla, открытым.
Критики считают, что подобные заявления выглядят как маркетинговый ход, якобы так Илон пытается навязать другим производителям беспилотных машин свой стандарт безопасности. Но есть и те, кто думает, что такое решение поможет повысить защищенность систем Tesla. Свежий взгляд сторонних разработчиков позволит внести в код правки и улучшения. Значит, конечный продукт будет надежнее защищать владельцев авто.
Не все компании готовы выкладывать свое проприетарные решения на GitHub. Они убеждены, что, если передать проект в open source, можно потерять конкурентное преимущество. Есть шанс, что появятся аналоги, и проект больше не будет уникальным. Например, в Cisco отказываются делать свои решения открытыми, потому что не хотят, чтобы «секретный ингредиент» их продуктов стал общедоступным.
Если же компания принимает риски и все равно желает вывести программное обеспечение в open source, просто сделать софт открытым и наблюдать за его развитием не получится.
Мнения о том, стоит ли компаниям заниматься проектами с открытым исходным кодом разнятся. Одни видят в этом только плюсы: возможность «прокачать» навыки сотрудников, ускорить рост популярности продукта, помочь ИТ-сообществу и индустрии. Другие пока не торопятся вкладывать ресурсы в open source из-за страха «затеряться» на рынке.
Доля правды есть в обоих утверждениях, но большая часть ИТ-сообщества убеждена, что польза от поддержки открытых проектов перевешивает недостатки. Однако компаниям нужно точно понимать причины того, почему они хотят стать частью open source комьюнити.
/ Pexels / Syed Abdullah / PD
Прокачка навыков
Когда руководство компании позволяет разработчикам участвовать в развитии открытых проектов, сотрудники приобретают новый практический опыт и знания. При этом разработчиков не нужно отправлять на дополнительные тренинги или курсы. Это экономит деньги компании, а программисты обучаются за счет решения нескучных и полезных для ИТ-сообщества задач.
Большую часть кода — 85% — ядра Linux пишут сотрудники крупных ИТ-компаний. Среди них числятся: Intel, Red Hat, IBM и др. Разработчики первой внесли 13% изменений в последние версии ядра, специалисты второй «ответственны» за 7%, а IBM — за 4%.
Программисты из этих корпораций отмечают, что работа над ядром позволяет им изучить Linux изнутри, разобраться во «внутренностях» подсистем и внести личный вклад в развитие самого крупного open source проекта. Полученные практические навыки они впоследствии применяют для решения корпоративных задач.
Ускорение разработки
Когда корпоративный продукт становится частью open source (при условии, что на этот продукт в ИТ-сообществе есть спрос), вокруг него начинает постепенно форматироваться комьюнити.
Когда в 2005 году разработчик Люк Канис (Luke Kanies) создавал клиент-серверное приложение Puppet, он изначально планировал привлекать пользователей за счет свободного распространения ПО. В итоге так и получилось — теперь его инструмент для автоматизации управления ОС используют 40 тысяч компаний, 75 из которых входят в рейтинг Fortune 100.
Здесь действует простое правило: чем больше человек участвуют в разработке, тем выше скорость релизов. Взять, к примеру, Linux — новые версии ядра этой ОС выходят каждые два месяца, а обновлений других операционных систем иногда приходится ждать несколько лет.
Еще пример: Google используют внутри компании открытый фреймворк Angular и вкладывают ресурсы в его развитие. Когда к проекту подключились сторонние веб-разработчики, Angular быстро обзавелся новыми инструментами и расширениями. От этого выиграли все.
Выявление багов
Растущее комьюнити позволяет не только быстрее выпускать новые версии приложений, но и помогает фиксить баги. Из-за того, что исходный код открытого ПО на наличие уязвимостей может просмотреть кто угодно (включая экспертов по ИБ), он считается более безопасным. И эта идея все чаще находит «отклик в сердцах» различных компаний.
/ Flickr / Henri Bergius / CC BY-SA
В августе этого года Илон Маск опубликовал в Twitter запись о намерении сделать программное обеспечение, отвечающее за безопасность автомобилей Tesla, открытым.
Критики считают, что подобные заявления выглядят как маркетинговый ход, якобы так Илон пытается навязать другим производителям беспилотных машин свой стандарт безопасности. Но есть и те, кто думает, что такое решение поможет повысить защищенность систем Tesla. Свежий взгляд сторонних разработчиков позволит внести в код правки и улучшения. Значит, конечный продукт будет надежнее защищать владельцев авто.
Ложка дегтя
Не все компании готовы выкладывать свое проприетарные решения на GitHub. Они убеждены, что, если передать проект в open source, можно потерять конкурентное преимущество. Есть шанс, что появятся аналоги, и проект больше не будет уникальным. Например, в Cisco отказываются делать свои решения открытыми, потому что не хотят, чтобы «секретный ингредиент» их продуктов стал общедоступным.
Если же компания принимает риски и все равно желает вывести программное обеспечение в open source, просто сделать софт открытым и наблюдать за его развитием не получится.
«Если организация хочет вывести в open source свое решение просто так, то толку будет мало, — рассказывает начальник отдела развития сервиса аренды инфраструктуры в облаке 1cloud.ru Сергей Белкин. — Чтобы вокруг нового решения сформировалось комьюнити, придется сделать все то же самое, что и для коммерческих продуктов.
В первую очередь понять, зачем это нужно вашей компании, а затем составить дорожную карту и проработать стратегию развития программного решения».
Что в итоге
Мнения о том, стоит ли компаниям заниматься проектами с открытым исходным кодом разнятся. Одни видят в этом только плюсы: возможность «прокачать» навыки сотрудников, ускорить рост популярности продукта, помочь ИТ-сообществу и индустрии. Другие пока не торопятся вкладывать ресурсы в open source из-за страха «затеряться» на рынке.
Доля правды есть в обоих утверждениях, но большая часть ИТ-сообщества убеждена, что польза от поддержки открытых проектов перевешивает недостатки. Однако компаниям нужно точно понимать причины того, почему они хотят стать частью open source комьюнити.
О чем мы пишем в корпоративном блоге:
Комментарии (11)
Tiendil
29.11.2018 14:29Ускорение разработки
У 1 из 100 ускоряется, у 99 замедляется из-за того, что включаться в разработку никто не хочет (по 100500 причинам), а поддержка проекта пригодным для open source разработки требует существенных усилий.
Здесь действует простое правило: чем больше человек участвуют в разработке, тем выше скорость релизов. Взять, к примеру, Linux — новые версии ядра этой ОС выходят каждые два месяца, а обновлений других операционных систем иногда приходится ждать несколько лет.
А 9 женщин выносят ребёнка за месяц. Ядро Linux релизится часто, потому что его разрабатывают профессионалы, в том числе и на зарплате. Дай боги, чтобы в ваш проект начали хотя бы студенты коммитить.
VolCh
30.11.2018 23:20Вопрос для обсуждения: в случае аутсорсинга кому выгоднее опенсорс продукта (предполагаем, что хоть кому-то): заказчику или аутсорсеру?
sshikov
Простите, но Гарвардская школа бизнеса — это не IT компания. А автор — вообще фрилансер, но в области, скорее близкой к журналистике:
>Kristen Senz is a freelance writer and social media content creator.
Так что ее мнение, конечно же, очень важно для нас…
mediaman
Если вы думаете, что на Хабре обсуждение ведут только инженеры и только про сети, ПО и код, то у меня для вас плохие новости. Посмотрите тематические хабы. Во-вторых, это не перевод источника, а пост в корп блоге иаас-хостера. Причём помимо имхов самой компании есть и другие мнения, как можно заметить из текста.
sshikov
Вы похоже не поняли моего посыла вообще. Мне не жалко, что конкретный человек пишет на любую тему, я лишь имел в виду, что мнение писателя в этом вопросе мало что значит.
Мнение писателя в социальных медиа очень важно для IT компаний. Вам самому-то не смешно?
Вот я работаю в IT компании. Причем всю жизнь фактически. И я могу совершенно определенно сказать — я бы с радостью вкладывался в open source, только это мешают очень многие вещи. И первая из них состоит в том, что в это нужно вкладывать слишком много, и большинство бизнесов меньше некоторого очень высокого уровня не готовы столько позволять своим сотрудникам (хотя на словах могут быть и сто раз за).
Вы бы хоть на размеры упомянутых посмотрели. Intel, IBM, Red Hat (а эти тут вообще при чем — их бизнес и есть тот самый open source, они одни из немногих, которые на нем научились зарабатывать).
Вот я в своей работе использую или недавно использовал, из совсем крупного:
* Linux
* Hadoop
* Spark
* Camel
* ActiveMQ
* Spring
* Maven
Сделать реальный вклад в любой из этих продуктов — это очень сложно, потому что большинство из них по размеру вполне сопоставимы с теми проектами, которые я делаю для работодателя, а многие значительно крупнее. Этот вклад — такая же работа, причем основная.
>иаас-хостера
А по вашему, хостер — он софт пишет?
mediaman
Вот только этот материал написала компания – облачный провайдер. Если воспользоваться не только скиллом чтения поста, но и открыть блог хостера, то можно найти и материалы про разработку ПО: про архитектуры или стандарты аутентификации.
Что до HBR, то мне вполне норм почитать обоснованное обсуждение темы, когда есть разные точки зрения.
sshikov
>Что до HBR, то мне вполне норм почитать обоснованное обсуждение темы, когда есть разные точки зрения.
Елы-палы… Да мне тоже вполне норм. Я лишь очень низко оцениваю полезность любых сделанных тут выводов. Писать про вклад в OpenSource, и вкладывать в него — это две разные вещи. Моя точка зрения чем-то хуже? Тем, что она другая?
olartamonov
Я вас не хочу сильно расстраивать, но в 9 компаниях из 10, ведущих тут корпоративный блог, за него отвечает отдел маркетинга, заказывающий тексты внешним фрилансерам с основным KPI «не меньше трёх материалов в месяц».
Очень, очень редко эти тексты пишут штатные сотрудники компании, тем более — её штатные разработчики или пиэмы.
roscomtheend
> Вот только этот материал написала компания – облачный провайдер.
Мнение водителя (или, скорее, продавца билетов на автобус) крайне важно в деле разработки автомобилей. Он, конечно, может до некоторой доли интересоваться, но не является профессионалом, знающим индустрию изнутри.
olartamonov
Техническая сложность — это лишь одна сторона проблемы. Дальше начинаются взаимоотношения с мейнтейнерами, у которых, особенно в небольших проектах, часто свои голоса в голове, бесконечные дискуссии о том, нужен ли проекту этот вклад вообще, его дальнейшая поддержка… При этом мы понимаем, что если от наших фич в проект после трёх месяцев дискуссий приняли треть, то никакой особой выгоды мы не получим, потому что оставшиеся две трети всё равно тянем сами, и часто на этих двух третях продолжают нарастать наши новые фичи, которые в основной проект тоже никогда уже не примут, потому что не приняли их базу. Ну и про то, что комьюнити возьмёт и найдёт у нас все баги, сделает наш код лучше и т.п. — миф, это работает только в совсем крупных и хорошо организованных проектах.
В общем случае, для этого всего нужны люди на зарплате, у которых основной трудовой обязанностью будет безвозмездное внесение вклада в опенсорс.
В итоге, поддержание своего форка по ресурсным затратам может быть тупо сильно выгоднее, и никакая «боязнь открыть секреты и затеряться на рынке» к этому не относятся — чистая экономика, не более.
sshikov
Это вы еще не описали веселого времяпровождения с безопасниками… Своими, ясное дело :)