The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Оценка способов организации взаимодействия компаний с открытыми проектами

05.09.2011 12:18

Дейв Нири (Dave Neary), в прошлом входивший в совет директоров организации GNOME Foundation, продолжил поднятую Джимом Землиным тему о целесообразности участия коммерческих компаний в разработке открытых проектов, и опубликовал заметку, посвящённую работе с upstream-проектами и оценке затрат на модификацию и поддержку свободного ПО в автономном режиме, без отдачи изменений сообществу разработчиков открытого ПО. Ниже представлен перевод некоторых интересных рассуждений.

Один из основных вопросов, который задают себе люди, это - "как реализовать то, что нужно реализовать, как можно дешевле и быстрее?" Допустим, есть некоторая программа, которая на 80% отвечает нуждам компании, и её нужно только немного переделать. Каков же наилучший путь для этого?

В 90% случаев берётся релиз, на основе которого будет делаться работа, и переделывается. Добавляется функциональность, которая нужна для проекта, над которым осуществляется работа здесь и сейчас, и никогда не говорится upstream-разработчикам о том, что было изменено и почему. Цена такого подхода - в дальнейшем компания никогда уже не увидит в своём обособленном проекте тех изменений, которые будут добавлены другими людьми, после создания ответвления кода. Компании придётся своими силами дублировать как минимум некоторые из более поздних функций, исправлений ошибок и патчей безопасности в своей работе.

Чтобы этого избежать, рекомендуем регулярно синхронизировать изменения из upstream-кода в локальный проект. Но такие слияния как правило требуют больших затрат, и кроме того чем значительнее изменения, внесённые в обособленное ответвление, тем больше вероятность возникновения серьёзных конфликтов между кодом из первичного проекта и локальной копией. Также не надо забывать о регрессивном тестировании и проверке после проведения слияний кода. И самое главное - всё это необходимо проделывать почти каждый раз, забирая код из первичного проекта.

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

Чтобы код внешнего разработчика попал в основной проект, ему нужно преодолеть различные препятствия, заботливо расставляемые на его пути основными разработчиками проекта. Большинство разработчиков проекта попросят переоформить патчи согласно принятым в проекте нормам, предоставлять только те патчи, которые без проблем применяются к development-ветке, и могут предложить альтернативные подходы для того, как следует писать патчи в будущем. Что же происходит, когда компания вносит некоторые изменения в проект, от которого зависит? Эти изменения применяются к стабильной версии. Если продукт компании будет выпущен через несколько месяцев, скорей всего апстрим-код продвинется за это время вперёд. Поэтому ожидается, что патчи будут рассчитаны на разрабатываемые ветви, а не на стабильный код. Поэтому, перед там, как попасть в основной код, проделанную работу нужно применить к экспериментальной ветви. У стороннего разработчика есть несколько вариантов, и у каждого из них есть свой риск:

  • Совершенно игнорировать апстрим, поливать только свою грядку и продавать обновления конечному клиенту, чтобы возместить расходы на поддержание кода, что отнимает у разработчика время и никак не способствует развитию основного проекта, не говоря о том, что обособленный код будет уязвим для возникающих проблем безопасности и ошибок, которые выявляются и исправляются в основном проекте.
  • Сделать форк стабильного релиза основного проекта, и "когда доделаем свой проект" приложить усилия к тому, чтобы слить его снова с основной ветвью. Но к тому времени подоспеют другие проекты, а момент, "когда появится для этого время" в реальной жизни наступает не так часто. Одним из решений тут может быть - нанять кого-то из разработчиков основного проекта чтобы он "позаботился" о помещении производного кода в апстрим, а это может стоить огромных финансовых и временных затрат. Но это почти гарантирует, что код попадёт в апстрим.
  • Идеальная ситуация - работать с нестабильной веткой апстрима в которой идет развитие функциональности (feature branch) и делать бекпорты в "медленную" стабильную ветвь, а затем предоставить законченную работу для включения в апстрим. У работы с "feature branch" есть свои проблемы, но они не сравнятся с решением проблем при слиянии огромного количества кода. В этом случае издержки связаны с проведением частых небольших слияний плюс необходимостью постоянно держать две ветки синхронизированными. Кроме того, существует значительная вероятность того, что после добавления всего кода в апстрим, результат всё равно будет отвергнут разработчиками проекта.

Итак, когда наступает необходимость в привлечении апстрима? И более важный вопрос - что разработчики апстрима могут сделать, чтобы снизить планку новым компаниям для возможности работы с апстримом? Если компания приносит только маленькие патчи, то у неё уйдёт времени больше на то, чтобы добиться включения патчей, чем на поддержку их в течение долгого времени.

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

Так в своё время поступила компания Softway, нанявшая для переработки и продвижения своих патчей в GCC компанию Ada Core, поддерживающую Ada-фронтэнд для GCC. Но так или иначе, как только расхождения в коде преодолевают определённый порог, значительный объём времени будет тратиться на поддержание кода и регрессивное тестирование. Постоянные долговременные издержки на разрешение конфликтов и тестирование при каждом слиянии кода перевесят затраты на включение кода в апстрим. И если какое-то ПО играет стратегическую роль в портфолио продуктов, и в это ПО вносятся значительные изменения, то невозможно себе представить чтобы компания не наняла мейнтейнера или высококвалифицированного программиста из проекта, разрабатывающего это ПО. Но нанимая такого программиста, компания должна понимать, что в первую очередь он остаётся "верен" своему проекту, а не корпоративному. Ну и кроме того, деятельность хорошего программиста включает в себя гораздо больше, чем написание кода. 20-30% его времени уходит на просмотр патчей, упаковку релизов, написание документации, на обсуждения в списке рассылки.

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

В качестве одного из примеров приводится разработка платформы Maemo компанией Nokia, на начальном этапе развития которой поддерживалось собственное ответвление от библиотеки GTK+. В конце концов, Nokia приняла решение о поставке в составе Maemo оригинального GTK+, но число изменений в созданном силами Nokia ответвлении GTK+ уже составило порядка 50 тыс. строк кода. Для выполнения работы по слиянию была нанята компания Imendio, которой потребовалось 4 года, чтобы обеспечить возможность использования оригинальной версии GTK+ в Maemo. При этом кроме интеграции изменений в апстрим, для обеспечения работы функций, которые не были приняты в апстрим пришлось переписать некоторые части Maemo. Другим поучительным примером являются трудности, которые встали на пути компании Google при попытке добиться передачи из платформы Android в состав основного ядра Linux подсистемы Wakelocks и набора специфичных драйверов.

  1. Главная ссылка к новости (http://blogs.gnome.org/bolsh/2...)
  2. OpenNews: Google намерен вернуть в Linux-ядро код, разработанный для платформы Android
  3. OpenNews: Компания Google наймет двух разработчиков для работы над поддержкой Android в Linux-ядре
  4. OpenNews: Попытка унификации соглашений с разработчиками открытого ПО вскрыла много проблем
  5. OpenNews: Шаттлворт и Нири рассуждают о конкуренции и взаимодействии между проектами Ubuntu и GNOME
  6. OpenNews: Руководитель Linux Foundation рассуждает о смысле участия компаний в разработке СПО
Автор новости: JT
Тип: Обобщение
Короткая ссылка: https://opennet.ru/31663-opensource
Ключевые слова: opensource, upstream
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (23) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, white_raven (?), 12:28, 05/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    "20-30% его времени уходит на просмотр патчей, упаковку релизов, написание документации, на обсуждения в списке рассылки"

    20-30% от 1% времени оставшегося от отладки написанного кода. :)

     
     
  • 2.16, Michael Shigorin (ok), 22:18, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    IMHO в проектах, о которых речь, 20--30% времени уходит скорее на код...
     
  • 2.18, Аноним (-), 22:38, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 20-30% от 1% времени оставшегося от отладки написанного кода. :)

    Вы как-то слишком хорошего мнения о программистах :P. Если б они настолько злобно дебажили, багов не было бы вообще. Ну почти.

     

  • 1.5, hummermania (ok), 13:37, 05/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Самое интересное что идеальный компромисс между интересами любой компании, использующей открытый продукт и интересами сообщества очень редко достижим, и перспектив пока не видно. Разве что в уставе сообщества, разрабатывающего продукт, будет конкретно указаны условия работы с отдельными независимыми компаниями. Тогда члены сообщества лояльнее будут относиться к патчам от одной или множества различных компаний с разными интересами, и стратегиями развития. Один плюс всегда - сообщество поддерживается бизнесом, и от этого продукту всегда только лучше.
     
     
  • 2.6, Аноним (-), 15:12, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Тут некоторые экстремисты предлагают пересмотреть роль денег в истории и перейти к натуральному обмену. В рамках концепций СПО.
     
     
  • 3.10, anonymous (??), 19:44, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Тут некоторые экстремисты предлагают пересмотреть роль денег в истории

    в истории — не надо. а вот в современном мире — надо. потому что деньги сейчас стали товаром сами по себе, а это нонсенс и дикость.

     
     
  • 4.14, M (?), 21:33, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    причем произвoдитель монoполист, в лице чaстных лиц
     
  • 4.20, Аноним (-), 09:31, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > потому что деньги сейчас стали товаром сами по себе, а это
    > нонсенс и дикость.

    Это намек на то, что их стоит снова привязать к золоту/серебру/smth по жесткому курсу?

     
     
  • 5.21, anonymous (??), 09:35, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> потому что деньги сейчас стали товаром сами по себе, а это
    >> нонсенс и дикость.
    > Это намек на то, что их стоит снова привязать к золоту/серебру/smth по
    > жесткому курсу?

    это намёк на то, что их не надо ни к чему «привязвать», потому что это не стимулирует пускать деньги в оборот. для начала см., например, концепцию «свободных денег».

     
  • 2.22, Аноним (-), 09:37, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Самое интересное что идеальный компромисс между интересами любой компании, использующей
    > открытый продукт и интересами сообщества очень редко достижим, и перспектив пока
    > не видно.

    Это решается очень легко. Нужно, чтобы ключевые лидеры и идеологи проекта исходили из интересов корпорации, а не своего сообщества. Обычно это достигается выделением грантов по определенным схемам и с некоторыми неофициально обговоренными условиями (не стоит считать любовь к распилу уникальной чертой российских чиновников). И что характерно, такие модели действуют уже сейчас и доказали свою жизнеспособность.

     

  • 1.7, Wormik (ok), 15:12, 05/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мой способ взаимодействия между дистрибутивами. Как сделать совместимость между rpm или deb. Допустим, раз в год выходит новая версия дистрибутива. Там все программы новые. Но вдруг хочется старую. А ведь не поставишь: хочет libgnutls.so.27, а у нас 31. И так еще 2 библиотеки. Решение: посмотреть состав дефолтной установки двух версий, конкретно /usr/lib, и разницу разместить в отдельный пакет, old-stable.rpm. Ура, старая работает. Так же и для старого дистрибутива выпустить new-stable.rpm.

    Как сделать совместимость между дистрибутивами. Несовместимости на самом деле нет, просто из-за разницы в месяцах выпуска одна программа зависит от libopenssl.so.0.9.8 в одном дистрибутиве, в другом та же от libopenssl.so.1. Решение: пакет с основными библиотеками федоры, суси, центоэса, мандривы и так далее. Либо выпускать релизы в один месяц, например к рождеству. Несовместимости на бинарном уровне у пакетов вообще нет: да, патчи разные накладываются на библиотеки, но из-за этого еще ни разу одна библиотека в двух дистрибутивах по-разному себя не вела (допустим libicu.so.8).

     
     
  • 2.9, vayerx (ok), 16:42, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    есть еще gentoo-way. проблема с версиями полностью не исчезает, но диапазон версий ощутимо расширяется. минусы, впрочем, очевидны
     
  • 2.11, anonymous (??), 19:45, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    (пожимает плечами) собрать из исходников что надо, да и всё.
     
     
  • 3.13, umbr (ok), 21:05, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В XXI веке живем - все хотят "из коробки".
     
     
  • 4.19, Аноним (-), 09:29, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >В XXI веке живем

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

     
  • 2.26, Eugeni Dodonov (ok), 07:28, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Несовместимости на бинарном уровне у пакетов вообще нет: да, патчи разные накладываются на библиотеки, но из-за этого еще ни разу одна библиотека в двух дистрибутивах по-разному себя не вела (допустим libicu.so.8)

    Счастливый вы человек раз не сталкивались с такими проблемами :).

    То, что попадает в библиотеку, кроме патчей, зависит еще и от того, как эта библиотека собиралась, с какими флагами итд. То есть, например, если какая-та программа была собрана вместе с библиотекой libX.so.0.0.0, которая была пропатчина (или настроена) на то, чтобы включить поддержку фич и функций A() и B(), и захочется ее запустить на другом дистрибутиве, где тоже есть libX.so.0.0.0, но собранная без этих фич, то все (гуглим по "unresolved symbols" для иллюстрации).

    Причем даже для одной и той-же библиотеки похожие проблемы могут встречаться, особенно когда меняется ABI либо API. Особенно когда это происходит - а major версия библиотеки не меняется.

    В общем, если бы все было бы так просто, то проблем бы не было. На практике все не так легко.

     

  • 1.8, umbr (ok), 15:14, 05/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >Один из основных вопросов ... как можно дешевле и быстрее...

    А Балда приговаривал с укоризной:
    "Не гонялся бы ты, поп, за дешевизной".
    (с) А.С. Пушкин

     
     
  • 2.23, Аноним (-), 09:39, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А Балда приговаривал с укоризной:
    > "Не гонялся бы ты, поп, за дешевизной".
    > (с) А.С. Пушкин

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

     
     
  • 3.24, anonymous (??), 09:41, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Рынок - это и есть вечная погоня за дешевизной в ущерб всему
    > остальному.
    > Вы можете предложить что-то лучше?

    конечно: перевод цивилизации на неконкурентную основу. впрочем, для квазиразумной агрессивной расы типа человечества это нереально.

     
  • 3.25, umbr (ok), 15:26, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Причем здесь рынок? Главный лозунг FOSS-движения - "свобода", а не "халява".
     

  • 1.12, robux (ok), 20:36, 05/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В двух словах, о чем новость?
    (влом читать эту воду)
     
     
  • 2.15, iZEN (ok), 21:50, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В двух словах, о чем новость?

    Предлагаются решения по механизму синхронизации исходников между мейнстримом и частными компаниями-соразработчиками.


     
  • 2.17, Michael Shigorin (ok), 22:20, 05/09/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > В двух словах, о чем новость?

    О терпении.


     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру