Дейв Нири (Dave Neary), в прошлом входивший в совет директоров организации GNOME Foundation, продолжил поднятую Джимом Землиным тему о целесообразности участия коммерческих компаний в разработке открытых проектов, и опубликовал заметку, посвящённую работе с upstream-проектами и оценке затрат на модификацию и поддержку свободного ПО в автономном режиме, без отдачи изменений сообществу разработчиков открытого ПО. Ниже представлен перевод некоторых интересных рассуждений. Один из основных вопросов, который задают себе люди, это - "как реализовать то, что нужно реализовать, как можно дешевле и быстрее?" Допустим, есть некоторая программа, которая на 80% отвечает нуждам компании, и её нужно только немного переделать. Каков же наилучший путь для этого? В 90% случаев берётся релиз, на основе которого будет делаться работа, и переделывается. Добавляется функциональность, которая нужна для проекта, над которым осуществляется работа здесь и сейчас, и никогда не говорится upstream-разработчикам о том, что было изменено и почему. Цена такого подхода - в дальнейшем компания никогда уже не увидит в своём обособленном проекте тех изменений, которые будут добавлены другими людьми, после создания ответвления кода. Компании придётся своими силами дублировать как минимум некоторые из более поздних функций, исправлений ошибок и патчей безопасности в своей работе. Чтобы этого избежать, рекомендуем регулярно синхронизировать изменения из upstream-кода в локальный проект. Но такие слияния как правило требуют больших затрат, и кроме того чем значительнее изменения, внесённые в обособленное ответвление, тем больше вероятность возникновения серьёзных конфликтов между кодом из первичного проекта и локальной копией. Также не надо забывать о регрессивном тестировании и проверке после проведения слияний кода. И самое главное - всё это необходимо проделывать почти каждый раз, забирая код из первичного проекта. Чтобы уменьшить до минимума различия между локальным кодом и первичным проектом, необходимо делать слияния регулярно, и нудно стремиться к тому, чтобы поддерживать вне основного дерева только патчи, нужные лично клиентам компании или локальному проекту, а всё остальное, что может пригодиться кому-то ещё, отсылать в главный проект, чтобы код поддерживался их силами. И вот на этом этапе разработчики упираются в потолок сообщества. Чтобы код внешнего разработчика попал в основной проект, ему нужно преодолеть различные препятствия, заботливо расставляемые на его пути основными разработчиками проекта. Большинство разработчиков проекта попросят переоформить патчи согласно принятым в проекте нормам, предоставлять только те патчи, которые без проблем применяются к development-ветке, и могут предложить альтернативные подходы для того, как следует писать патчи в будущем. Что же происходит, когда компания вносит некоторые изменения в проект, от которого зависит? Эти изменения применяются к стабильной версии. Если продукт компании будет выпущен через несколько месяцев, скорей всего апстрим-код продвинется за это время вперёд. Поэтому ожидается, что патчи будут рассчитаны на разрабатываемые ветви, а не на стабильный код. Поэтому, перед там, как попасть в основной код, проделанную работу нужно применить к экспериментальной ветви. У стороннего разработчика есть несколько вариантов, и у каждого из них есть свой риск:
- Совершенно игнорировать апстрим, поливать только свою грядку и продавать обновления конечному клиенту, чтобы возместить расходы на поддержание кода, что отнимает у разработчика время и никак не способствует развитию основного проекта, не говоря о том, что обособленный код будет уязвим для возникающих проблем безопасности и ошибок, которые выявляются и исправляются в основном проекте.
- Сделать форк стабильного релиза основного проекта, и "когда доделаем свой проект" приложить усилия к том, чтобы слить его снова с основной ветвью. Но к тому времени подоспеют другие проекты, а момент, "когда появится для этого время" в реальной жизни наступает не так часто. Одним из решений тут может быть - нанять кого-то из разработчиков основного проекта чтобы он "позаботился" о помещении производного кода в апстрим, а это может стоить огромных финансовых и временных затрат. Но это почти гарантирует, что код попадёт в апстрим.
- Идеальная ситуация - работать с нестабильной веткой апстрима в которой идет развитие функциональности (feature branch) и делать бекпорты в "медленную" стабильную ветвь, а затем предоставить законченную работу для включения в апстрим. У работы с "feature branch" есть свои проблемы, но они не сравнятся с решением проблем при слиянии огромного количества кода. В этом случае издержки связаны с проведением частых небольших слияний плюс необходимостью постоянно держать две ветки синхронизированными. Кроме того, существует значительная вероятность того, что после добавления всего кода в апстрим, результат всё равно будет отвергнут разработчиками проекта.
Источник: http://www.opennet.ru/opennews/art.shtml?num=31663
оригинал на opennet.ru