Оценка способов организации взаимодействия компаний с открытыми проектами
Один из основных вопросов, который задают себе люди, это - "как реализовать то, что нужно реализовать, как можно дешевле и быстрее?" Допустим, есть некоторая программа, которая на 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 и набора специфичных драйверов.
Источник: http://www.opennet.ru/opennews/art.shtml?num=31663
|
|
0 | Tweet | Нравится |
|
