Бизнес-модель разработки с открытым кодом отличается от традиционных подходов к созданию программ на предприятиях. Какие преимущества могли бы получить коммерческие программные продукты, адаптируя лучшие практики из открытой разработки [1]? Работают ли какие-либо открытые практики в корпоративном мире? Если да, то какие, и как перенести их в коммерческую среду?

В статье описывается опыт применения в компании SAP практики координации разработки программ, используемой в сообществе Open Source. Как оказалось, эта практика может дополнить традиционную методологию «нисходящей» разработки «восходящими потоками» коллективного разума. «Кузницы кодов», или Forge-центры, могут стать механизмом расширения сферы применимости открытых программных разработок в корпоративной среде. Этот вывод был получен при работе с внутренней «кузницей кодов» SAP Forge, а также в результате анализа сходных проектов в других крупных софтверных компаниях.

Лучшие практики координации разработки

Эрик Рэймонд сравнивал разработку большинства корпоративных программных систем со строительством собора: планирование, управление и филигранное исполнение работы опытными мастерами «сверху вниз», от общего к деталям. А Open Source, напротив, Рэймонд сравнил с базаром (толкучкой) без генерального плана, с разнообразием амбиций и массой излишних усилий [2]. Действительно, многие из лучших практик координации разработок в Open Source прямо противоречат традиционному подходу к выполнению программных проектов [3,4]. В проектах Open Source исходный код не скрывается от пользователей, которые как раз вовлечены в процесс бета-тестирования. Разрабатываемые таким образом системы проходят через множество не полностью готовых выпусков и в общем случае не предполагают, что пользователю требуется законченный «отлакированный» продукт. Вместо этого поощряется активное участие пользователей в доработке системы [5].

Исследование, проведенное Виджаем Гурбани, выявило возможные преимущества, которые принесет компаниям применение практик открытой разработки программ во внутрикорпоративных проектах [6]. Гурбани с коллегами разработали сервер Internet-телефонии в компании Lucent, используя подход Open Source. Пройдя много этапов, исследовательский проект постепенно превратился в основу для множества коммерческих продуктов, каждый из которых работает с одним и тем же сервером. Гурбани превратил этот серверный программный продукт во внутренний нематериальный актив, предоставив совместный доступ всем сотрудникам к его рабочей копии и исходным кодам. Проект следовал модели разработки Linux, в которой выделяются роли «благожелательного диктатора» и «доверенных местоблюстителей». Результатом стал высококачественный продукт с широкой областью применения, соответствующий ожиданиям пользователей и способный легко подстраиваться под различные нужды.

В SAP также решили использовать подход Open Source для того, чтобы зарождающиеся опытные разработки чаще превращались в успешные продукты наподобие сервера, созданного Гурбани.

Принципы открытой координации работ

Говорят, что методология Open Source основана на меритократии [7], при которой проект направляется наиболее способными людьми, независимо от их положения на административной лестнице. Проект, основанный на такой методологии, подразумевает несколько принципов совместной работы.

  • Равенство. Внести свой вклад может каждый, доступ к проектам с открытым кодом осуществляется через Сеть, а в сообщество проекта обычно принимаются все желающие помочь в разработке.
  • Меритократия. Внесенные правки прозрачным образом оцениваются с точки зрения их достоинств, все решения обсуждаются и принимаются в ходе дискуссий в списках почтовой рассылки, а также публикуются с возможностью отсылки к конкретному сообщению.
  • Самоорганизация. Как правило, никакие регламенты извне не привносятся в процесс, сообщество разработчиков самостоятельно решает, как эффективнее развивать проект.

Данные принципы мы называем принципами открытой координации работ. Они резко контрастируют с принятыми во многих корпорациях подходами к управлению процессами в программных разработках:

  • Персональная ответственность исполнителя. Директивное распределение ресурсов по проектам и составляющим их работам (или программным модулям) «сверху вниз».
  • Положение превыше достоинств. Последнее слово в обсуждении решений по архитектуре и технической реализации принадлежит старшему по должности в иерархии разработчиков «специалист – ведущий специалист – архитектор»;
  • Общий регламент. Процесс разработки в каждом из проектов регулируется общим регламентом, который разработан специализированным подразделением компании, отвечающим за регламентацию бизнес-процессов.

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

Преимущества открытой координации внутренних проектов

Нетипичные для традиционно построенных организаций – разработчиков программного обеспечения принципы открытого взаимодействия обладают рядом преимуществ.

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

Все эти преимущества питаются от одного источника – навыков и энергии добровольных участников проекта, но интерес представляют сценарии присоединения новых разработчиков к проектам категории Open Source. Так, Георг фон Крог с соавторами проанализировали проект Freenet [8], а Израиль Герраиц с соавторами провели аналогичный анализ проекта Gnome [9]. Они обнаружили, что новые участники открытой разработки обычно вовлекаются в процесс постепенно, в отличие от оплачиваемых разработчиков, которые входят в проект быстро и с полным погружением.

Программные «кузницы» для открытого сотрудничества

Несколько крупных производителей ПО предприняли ряд шагов к формированию устойчивого канала для адаптации лучших практик Open Source в корпоративные процессы. Например, Джейми Динкелакер с соавторами сформулировали парадигму Progressive Open Source прогрессивной (постепенно возрастающей от открытости в пределах корпорации через совместную работу с партнерами к полной открытости исходных кодов) открытости разработок компании HP [10]. В рамках этой программы Динкелакер с коллегами разработали инициативу «корпоративные исходники», при поддержке которой исследовательские проекты HP Labs были переведены на прин-ципы открытости исходных кодов внутри компании. Ключом к успеху этих проектов стало создание сообществ заинтересованных разработчиков, в которые вошли не только исследователи, но и разработчики из коммерческих подразделений [11].

В корпорации IBM существует аналогичное направление, которое отличается от инициативы HP тем, что использует готовые программные продукты для автоматизации «кузницы кодов», а не собственные разработки [12]. Такой же подход был принят и в SAP.

Опыт Гурбани из Lucent показал, что одной из серьезнейших проблем внутрикорпоративной открытой разработки является тот факт, что многие группы используют различные и часто несовместимые инструменты. Удачный проект «кузницы кодов» объединяет в себе набор инструментов
и полную поддержку жизненного цикла разработки программных средств.

«Кузницы» и CASE-средства

Системы Software Forge во многом сходны с интегрированными CASE-продуктами [13]. В них заложены предопределенные, но расширяемые наборы инструментов, которые совместно помогают разработчикам в работе над проектом. Управление задачами, отслеживание вопросов и проблем и средства документирования можно найти как в CASE-продуктах, так и в системах Software Forge.

Инструментальные наборы разработчиков во многих корпорациях не являются ни интегрированными, ни завершенными, и проектные команды часто устанавливают для разработки специфический для проекта набор инструментов. Как следствие, важная информация о проектах оказывается разбросанной по множеству серверов и зачастую утрачивается при переходе продуктов на очередной этап жизненного цикла. Эта проблема решается либо посредством CASE-пакетов, либо с помощью систем класса Software Forge, которые предоставляют разработчикам определенное место для хранения артефактов и все необходимые инструменты для работы.

Среди прочих преимуществ использования Software Forge нужно отметить централизацию и хранение важной информации и сокращение ресурсных затрат на административные задачи вроде поддержки выделенного под проект Web-сервера и средства отслеживания ошибок.

Критические вопросы проектирования «кузниц»

Разработчики внутреннего программного обеспечения корпораций наряду с людьми, определяющими процессы разработки, являются основными покупателями CASE-систем. Системы Software Forge, напротив, зародились в Сети, и основными их пользователями являются разработчики программ Open Source.

Проекты с открытым кодом, как правило, сильно ограничены в ресурсах, что обусловливает необходимость привлечения добровольцев к большинству проектов. «Кузницы кодов» призваны максимально облегчить процесс нахождения (обнародования) проекта, выяснения его деталей и внесение личного вклада.

Нахождение проектов. Forge-центр, как правило, в первую очередь показывает пользователю имеющийся портфель проектов, а затем позволяет ознакомиться с деталями конкретного проекта. Информация о проектах индексируется, и через общий начальный URL можно легко найти любой из них через механизм поиска. В традиционной разработке корпоративных приложений все наоборот – ограничение сфер ответственности и допуска зачастую приводит к закрытому размещению проектов на множестве отдельных серверов без единой индексации и даже с «зашифрованными», ничего не говорящими, URL-адресами. CASE-средства также часто ориентированы на конкретные проекты и позволяют участвовать в них только заранее определенному руководством кругу разработчиков.

Ознакомление с проектом. Как правило, Forge-центры разработки изначально включают в состав набора инструментов проектные форумы и списки рассылки, что делает обсуждение проектов публичным и доступным соответствующей целевой аудитории, которая по умолчанию включает всех пользователей, имеющих доступ к «кузнице». Такие обсуждения закладываются в основу документирования всех проектных и технических решений разработки программных продуктов по данной методологии. Механизмы индексирования и поиска позволяют пользователям разобраться в том, какие и почему были приняты решения в ходе проекта, облегчают добровольным помощникам ознакомление с проектом и начало участия в разработке. Напротив, в традиционных проектах решения часто принимаются кулуарно, на совещаниях или при обсуждениях по телефону. Документирование решений, если и происходит, то не систематически. В итоге разработчики нередко располагают лишь информацией о том, что решение было принято именно в данной конкретной формулировке. В результате разработчикам сложнее разобраться в хитросплетениях проекта и вписаться в процесс.

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

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

SAP Forge

Процесс разработки ПО в компании SAP поддерживается лучшими в своем классе вспомогательными инструментами, и с 2006 года через «кузницу» SAP Forge для выполнения проектов привлекаются
и аккумулируются ресурсы от добровольных участников, имеющих доступ к корпоративной сети. В основу SAP Forge положена реализация «кузницы» с открытым кодом GForge, которая пользуется успехом в крупных корпорациях, например, у IBM.

SAP Forge представляет собой единую общую платформу разработки, доступную любому сотруднику компании, находящемуся в корпоративной сети. Любой заинтересованный может стать разработчиком в существующем проекте или зарегистрировать новый проект без бумажной волокиты, сопровождающей процессы согласования и утверждения. Если устав проекта не требует обратного, все проекты являются открытыми и доступными для всех.

С момента своего запуска в сентября 2006 года SAP Forge набирает обороты, причем использовать SAP Forge не обязательно – это решение оставлено за руководителем проекта, однако уже через год после основания на SAP Forge были размещены более 100 проектов с 500 зарегистрированными пользователями, что составляет около 5% всех разработчиков компании.

В таблице приводится некоторая статистическая информация о Forge-центрах SAP, IBM, HP и Microsoft. Видно, что у SAP Forge значительно больше малых проектов, чем у IBM и HP, это может быть обусловлено большим количеством малых исследовательских проектов, которые уже были завершены и нуждались только в размещении на легко обнаруживаемом ресурсе. Авторы предполагают также, что разработчики в наши дни проявляют более высокую готовность к раскрытию исходных кодов внутри компании, чем несколько лет назад, что также демонстрируется данными о количестве участников Forge-центра Microsoft, запущенного в 2007 году.

В SAP Forge разработчику в первую очередь предоставляется обзорная информация о всех проектах и разработчиках, участвующих в работе «кузницы». После этого разработчик может перейти к своей «приборной панели», где собрана информация о тех проектах, в которых он участвует (см. рисунок). Переключившись на конкретный проект, разработчик получает доступ к таким инструментам SAP Forge, как отслеживание ошибок, управление конфигурациями, работа с задачами, форумы, списки рассылки и wiki.

Поиск проектов, информация о разработчиках и публичное освещение проектов стали важным подспорьем в продвижении лучших практик открытой разработки в SAP. Пользователи могут найти интересующие их проекты с помощью поиска по их названиям и описаниям, узнать о навыках и опыте работы из личной карточки разработчика в Forge-центре и найти разработчиков с нужным опытом. Эти возможности поддерживают и укрепляют социальную сеть разработчиков, которым известно, кому задать вопрос и к кому обратиться за советом. Наконец, в SAP Forge пользователям доступна различная статистика, например по наиболее активно развивающимся или наиболее массовым проектам. Такая статистика не только информирует, но и служит мотивацией для участия
в проектах, поскольку связана с репутацией проекта и его разработчиков, что обусловливает растущее стремление участников повышать качество своей работы.

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

С точки зрения работодателя, внутренний Forge-центр позволяет сотрудникам работать на специфических проектах и не допускать распыления ресурсов на непрофильную деятельность. Благодаря внедрению корпоративной «кузницы кодов» мы обнаружили, что разработчики-энтузиасты при наличии времени, энергии и мотивации предпочитают работать на благо компании, а не на посторонние проекты.

Литература

  1. W. Scacchi, Free/Open Source Software Development: Recent Research Results and Emerging Opportunities, Proc. 6th Joint Meeting European Software Eng. Conf. and the ACM SIGSOFT Symp. Foundations of Software Eng. (ESEC/FSE 07), ACM Press, 2007, pp. 459–468.
  2. Эрик Реймонд, Собор и базар // Открытые системы. – 1999. – № 9–10. – С. 71–83.
  3. C. DiBona, S. Ockman, M. Stone, Open Sources: Voices from the Open Source Revolution, O’Reilly, 1999.
  4. K. Fogel, Producing Open Source Software, O’Reilly, 2005.
  5. E. von Hippel, Democratizing Innovation, MIT Press, 2005.
  6. V.K. Gurbani, A. Garvert, J.D. Herbsleb, A Case Study of a Corporate Open Source Development Model, Proc. 28th Int’l Conf. Software Eng. (ICSE 06), ACM Press, 2006, pp. 472–481.
  7. K.R. Lakhani, R.G. Wolf, Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects, in Perspectives on Free and Open Source Software, MIT Press, 2005,
    pp. 3–22.
  8. G. von Krogh, S. Spaeth, K.R. Lakhani, Community, Joining, and Specialization in Open Source Software Innovation: A Case Study, Research Policy, vol. 32, 2003, pp. 1217–1241.
  9. I. Herraiz et al., The Processes of Joining in Global Distributed Software Projects, Proc. 2006 Int’l Workshop Global Software Development for the Practitioner, ACM Press, 2006, pp. 27–33.
  10. J. Dinkelacker et al., Progressive Open Source, Proc. 24th Int’l Conf. Software Eng. (ICSE 02), ACM Press, 2002, pp. 177–184.
  11. C. Melian et al., Building Networks of Software Communities in a Large Corporation, tech. report, HP Labs, 2002.
  12. D. Sabbah, The Open Internet—Open Source, Open Standards and the Effects on Collaborative Software Development, presentation at the 2005 High Performance Transaction Systems Workshop, 2005.
  13. S. Jarzabek and Riri Huang, The Case for User-Centered CASE Tools, Comm. ACM, vol. 41, no. 8, 1998, pp. 93–99.

Дирк Риле (dirk@riehle.org) – старший исследователь SAP Labs (Пало Альто); Джон Элленбергер (johne@jellenberger.org) – руководитель исследований подразделения SAP Research (Бостон); Тамир Менахем (tamir.menahem@sap.com) – архитектор процессов разработки израильского подразделения SAP Labs (Раанана); Борис Михайловский (bmikhailovski@sap.com) – главный ИТ-архитектор в израильском подразделении SAP Labs (Раанана); Юрий Начетой (yuri.natechetoi@sap.com) – старший исследователь в подразделении SAP (Монреаль, Канада); Барак Навех (barak@moblica.com) –  технический директор компании Moblica (Израиль); Томас Оденвальд (thomas.odenwald@icw.global.com) – руководитель лаборатории ICW Technology Labs (Калифорния).

Что такое Forge-центр

Software Forge, или «кузница кодов» – это расширяемая Web-платформа, интегрирующая лучшие программные средства для совместной разработки программного обеспечения. Самый известный проект такого рода – SourceForge, содержащий крупнейшую в мире коллекцию проектов категории Open Source. Можно также отметить BerliOS, Codehaus и Tigris.

Две ключевые возможности интерфейса «кузницы кодов»: портфель проектов, в котором можно пролистать и найти интересный проект, и просмотр проекта, в котором разработчику предоставлены средства для работы над конкретным проектом. Разработчики, входя в конкретный проект, получают представление о размещении двух его основных информационных блоков: ссылки на инструменты для работы с проектом и информационный блок выбранного инструмента.

Полноценные Forge-центры поддерживают весь цикл разработки программного обеспечения: сбор идей, определение проекта, управление проектом, управление конфигурациями, поддержка сборки (интеграции) продуктов и отслеживание ошибок. «Кузница» интегрирует все инструменты для перечисленных процессов в едином интерфейсе и облегчает переходы между ними. Во всех проектах используется один и тот же набор инструментов, так что разработчики могут легко переключаться с проекта на проект.

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

Sap Forg