January 2012 Download this article as a PDFAbstract

Open source программное обеспечение теперь является «бизнес как обычно» в мобильной индустрии. Хотя большое внимание уделяется важности лицензий, мы утверждаем в этой статье, что модель управления может быть по мере необходимости для успеха проекта и что проекты различаются в модели управления - будь то открытые или закрытые - что они используют. Модели управления открытым исходным кодом описывают контрольные точки, которые используются для влияния проектов с открытым кодом в отношении доступа к исходному коду, как исходный код разработан, как создаются производные и структуру сообщества проекта. Управление определяет, кто имеет контроль над проектом за то, что считается юридически необходимым, через открытые лицензии для этого проекта. Цель наших исследований для определения и оценки управления проектов с открытым кодом, другими словами, степень, в которой процесс принятия решений в проект с открытым исходным кодом «открыто» или «закрыто». Мы проанализировали восемь проектов с открытым кодом с использованием 13 конкретных управленческих критериев во всех четырех областях управления: доступ, развитие, производные и сообщества.

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

Введение

Много было написано и обсуждается в отношении лицензий – с первых дней GPL лицензии до наших дней Android открытой платформы источника. Тем не менее мы считаем, что один очень важный аспект проектов с открытым кодом, игнорировалась: открыть модели управления источником. В то время как лицензии определяют права на использование, копирование и изменение, Управление определяет права на видимость, влияние и создание производных (таблица 1). И хотя лицензии применяются к исходному коду, управление относится к проекту или платформы. Более того модель управления описывает контрольные точки, используемые в проект с открытым кодом – таких как Android, Qt или WebKit- и является ключевым фактором, определяющим успех или провал платформы.

Модель управления, используется проект с открытым кодом инкапсулирует все трудные вопросы о проекте. Кто принимает решение о дорожной карты проекта? Насколько прозрачным процессы принятия решений? Может ли кто-нибудь следовать дискуссии и встречи проходят в сообществе? Может ли кто-нибудь создать дериватами, на основе этого проекта? Какие существуют требования соответствия, и как они применяются? Управление определяет, кто имеет влияние и контроль над проектом или платформы – за то, что юридически считается открытым исходным кодом лицензии. В сегодняшнем мире коммерчески водить мобильных open source проектов это не достаточно, чтобы понять, открытым исходным кодом лицензии, используемые в проекте. Это модель управления, которая определяет ли принятия решений в рамках проекта с открытым кодом является открытым, доступным и прозрачным для всех пользователей, или же сконцентрированы среди определенного набора пользователей.

Пизано и Verganti (2008) характеризуются открытым исходным кодом проекты в качестве примеров «модель открытого сотрудничества» и открыто (членство) и плоский (управление). Исходя из этого, ожидается, что проекты с открытым кодом, также будут регулироваться открыто. Однако наши результаты показывают, что некоторые проекты с открытым кодом – такие, как Android, Qt и Symbian – использовать закрытые модели (иерархический) управления и что управление, которое модели могут меняться с течением времени. В то время как Пизано и Verganti характеризуют модели управления являются плоскими или иерархических, мы используем термин «open» со ссылкой на степени открыты для сообщества проекта процессы принятия решений. Например определение лиц, принимающих решения, в рамках открытых проектов (прозрачность) и доступ к информации вокруг фактического процесса принятия решений (специальные возможности) критерии управления, которые легко не учитываются в описании моделей управления как плоский или иерархический.

 

Таблица 1. Основные дифференциаторы лицензий и управления

 

Лицензия

Управление

Права

Использование, копирование, изменение

Видимость, влияние и создание производных

Использование

70% проектов используют одну из семи лицензий

Согласованное определение управления

Примеры

GPL, LGPL

Никаких формальных примеров

Правовые

Юридически обязательные

Без обязательств

 

В этой статье мы сначала объяснить ключевые управления критерии, которые мы использовали для анализа восьми различных мобильных open source проектов и результаты этого анализа. Затем мы рассмотрим, почему Android был настолько успешным, учитывая, что мы находим, что это также наименее открытый проект мобильных открытым исходным кодом. Исходя из этого, мы выявления наилучшей практики, используемые наиболее успешных проектов с открытым кодом по четырем областям управления доступа, развития, производные и сообщества. И наконец мы предлагаем для будущего исследования и представить некоторые выводы в отношении наших исследований на сегодняшний день.

Анализ моделей управления

Мы поставили амбициозную цель: оценить открытость – степень к которой open source проект «открыто» или «закрыто» – в пути, которые редко обсуждались публично или в его лицензии. Мы отправились для определения и оценки управления проектов с открытым кодом в транспарентной и всеобъемлющей основе-подобно как открытым исходным кодом лицензии определены и классифицированы в «copyleft», «разрешительный» и так далее. В отличие от лицензий модель управления состоит из менее заметными условия и контрольные точки, которые определяют доступ, влияние, решения и производные этого проекта.

Мы исследовали восемь мобильных open source проектов: Мужской, MeeGo, Linux, Qt, WebKit, Mozilla, Eclipse и Symbian. Мы выбрали эти проекты, основанные на широте охвата; Мы выбрали как успешный (Android) и неудачных проектов (Symbian); один спонсор (Qt) и нескольких спонсоров проектов (Eclipse); и оба проекта на основе меритократии (Linux) и статус членства (Eclipse).

Наши исследования, более шести месяцев, включали анализ этих популярных open source проектов и бесед с лидерами общин, представителями проекта, ученых и ученых открытым исходным кодом. Запад и о ' Махони (2008) определил три аспекта проектов с открытым кодом: производство (из исходного кода), управления (открытым исходным кодом проекта) и интеллектуальной собственности (из исходного кода производства проекта). Мы строим на эту работу, также изучает, как пользователей (разработчиков) исходный код проекта может влиять на направление и содержание открытым исходным кодом проекта благодаря доступности и прозрачности процессов принятия решений и управления открытым исходным кодом проекта. Например мы покажем, как управление исходным кодом взносов является критической контрольной точки для управления проекта с открытым кодом. Кроме того, мы сосредоточены на как производные исходного кода (то есть приложения, которые могут работать на open source проект платформы) находится под контролем; Это важное значение управления контрольная точка, которая используется коммерческими организациями, поддержки проектов с открытым исходным кодом. Таким образом наше внимание было очень много на использовании моделей управления как дескриптор открытым исходным кодом контрольных точек.

На основе нашего анализа мы опубликовали доклад, в котором мы предложили открыть управления индекс (ОГИ), мера открытого проекта «открытость» (VisionMobile, 2011). OGI состоит из 13 метрик (Вставка 1) во всех четырех областях управления:

  1. Доступ: наличие последней версии исходного кода, разработчик поддержки механизмов, общественный план и прозрачность принятия решений
  2. Развитие: способность разработчиков влиять на содержание и направленность проекта
  3. Производные: возможность разработчикам создавать и распространять производные исходного кода
  4. Сообщество: структура сообщества, которая не проводит различия между разработчиками

OGI позволяет измерить как открыть проект с точки зрения транспарентности, принятия решений, повторного использования и структуры сообществ. Мы месте проектов по каждому параметру управления и по шкале от одного до четырех по каждому вопросу коробке 1. Чем выше оценка, тем более открыть проект. Подробнее о как вычисляется Оги, включая отдельные баллы для каждого проекта с 13 критериев управления, доступны в полном докладе (VisionMobile, 2011). Также, обратите внимание, что наша оценка Qt было сделано до того, как модель управления проекта был пересмотрен в октябре 2011 года.

 

Вставка 1. Критерии управления Оги

Доступ

  1. Это исходный код свободно доступен всем разработчикам, в то же время?
  2. Исходный код доступен под неограничительной лицензией утвержденных OSI?
  3. Механизмы поддержки разработчиков – являются списки рассылки проекта, форумы, базы данных отслеживания ошибок, репозитории исходного кода, документация для разработчиков и средства разработчика доступны для всех разработчиков?
  4. Это дорожная карта проекта доступна публично?
  5. Прозрачность механизмов решения являются проекта встречи минут/обсуждения публично доступны таким образом, что можно понять, почему и каким образом принимаются решения, касающиеся проекта?

Развитие

  1. Прозрачность взносов и процесс принятия – это вклад код и процесс принятия ясно, прогресс обновления вклада (через Bugzilla или аналогичный)?
  2. Прозрачность взносов в проект-вы можете определить из которого исходный код взносов возникла?
  3. Доступность, чтобы стать коммиттером – требования и процесс, чтобы стать коммиттером документально и это справедливого процесса (то есть, все разработчики потенциально могут стать коммиттеры?). Обратите внимание, что «коммиттеров» разработчик, который может совершить код проекта с открытым кодом. Термины «сопровождающий» и «рецензент» также используются в качестве альтернатив по некоторым проектам.
  4. Прозрачность коммиттеры – можете ли вы определить коммиттеры к проекту?
  5. Требуется ли лицензия на сайте уступки авторского права, лицензии или патента?

Производные

  1. Товарные знаки используются для управления и где платформа используется посредством обеспечения соблюдения процесса до распространения?
  2. Ограничены ли каналы выхода на рынок для производных приложений проекта с точки зрения утверждения, распространения или открытие?

Структура сообществ

  1. Это структура сообщества плоский или иерархический (то есть, существуют ли многоуровневые права в зависимости от статуса членства?)

 

«Открытые» проекты являются более успешным?

Успешный открытый проект демонстрирует долгосрочное вовлечение пользователей и разработчиков, а также значительное число производных, и проект постоянно развивается, взрослеет и развивается с течением времени. Наши исследования показывают, что платформы, которые являются наиболее открытыми будет наиболее успешным в долгосрочной перспективе. Eclipse, Linux, WebKit и Mozilla, каждый подтвердить это через их высокой Оги оценки (таблица 2). С точки зрения открытости Eclipse является наиболее открытой платформой через access, развития, производные и сообщества атрибуты управления. Он внимательно следит за Linux и WebKit, а затем Mozilla, MeeGo, Symbian и Qt. Семь из восьми платформ, рассмотрели упал в течение 30 процентных пунктов друг от друга в Оги.

 

Таблица 2. Открыть индекс управления результаты

Проект

Открытость

Андроид

23%

Qt

58%

Symbian

58%

MeeGo

61%

Mozilla

65%

WebKit

68%

Linux

71%

Затмение

84%

 

Наши исследования выявили некоторые атрибуты успешного open source проектов. Эти атрибуты являются: своевременный доступ к исходному коду, средства для сильных разработчиков, прозрачности, доступности для содействия кода и доступности, чтобы стать коммиттером. Равное и справедливое отношение разработчиков (например, «меритократии») стала нормой и ожидается от разработчиков в том, что касается их участия в открытых проектах.

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

Андроид парадокс

Android является наиболее закрытый проект, который мы рассмотрели с Оги 23%. Тем не менее в то же время, это один из наиболее успешных проектов в истории открытым исходным кодом. Является ли Android доказательство того, что открытого управления не требуется для успеха в проект с открытым исходным кодом?

Успех Android имеет мало общего с открытым исходным кодом лицензирования государственной базы кода. Android не достигли бы его нынешних ubiquity бы не финансовые мышцы и знаменитой инженерной команды Google. Разработка Android платформы происходит без необходимости внешних разработчиков или участие коммерческого сообщества.

Google представил Android на «меньше нуля» стоимости, поскольку его основной деятельности не является программное обеспечение или поиск, но вождение объявления глазного яблока. Как теперь хорошо понимает, стратегия Google была субсидировать Android таким образом, что он может доставить дешевых телефонов и недорогой беспроводной доступ в Интернет для того, чтобы управлять более глазного яблока к Google объявлений.

Что более важно, Android не достигли бы если бы не миллиарды долларов, которые ПВТ и операторов сетей выливают в Android для того, чтобы конкурировать с Apple в знаковых устройств. Стивен Элоп, Генеральный директор Nokia, сказал на Open Mobile саммите в июне 2011 года, «Apple создала условия необходимые для Android».

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

Рекомендации

Исходя из наших исследований крупных мобильных open source проектов, мы разработали рекомендации для моделей управления. Эти методы перечислены в четырех ключевых областях управления: доступ, развитие, производные и сообщества.

Доступ

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

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

Развитие

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

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

Разработчикам часто нужно знать, где возглавлял проект, как он будет получать там, и почему он возглавлял в этом направлении. Они также часто хотят возможность влиять на проект для удовлетворения своих собственных потребностей (например, «почесать свои собственные зуд»). Основным средством, помощью которого разработчики могут достичь этого влияния является возможность совершить код проекта. Таким образом должно быть возможным для всех разработчиков, чтобы взять код в проект, после того, как они показали достаточные знания кода. Это где меритократии вступает в игру: те, что «делать» должны быть вознаграждены соответственно. Кроме того, проект должен предоставить прозрачный проект метрики в отношении которых взносы поступают из и кто их совершил.

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

Производные

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

Сообщество

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

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

Эволюция индекс открытого управления

Мы стремимся продолжить дискуссию по вопросам управления, уточнить наши критерии еще дальше и сделать Оги меру как значимый, насколько это возможно для сообщества open source. Одним из первых предложений был в отношении имеющих измерение времени к критериям (например, делает открытость изменения с течением времени). Зрелые проекты как Eclipse, Linux и WebKit с открытым кодом, которые выдержали испытание временем, оценка достаточно высоко в том, что касается открытости управления. Но это всегда не так. Например, рассмотрим следующее. Apple раздвоенной KHTML для создания WebKit в начале 2000-х, выпустив первый проект с открытым кодом WebKit в 2005 году, но с оппонентом и фиксации прав, ограничены только специалистами Apple, которая эффективно лазарете сообщества KDE. В 2007 году однако Apple отменил это решение позволяет разрешить разработчикам не Apple иметь полный фиксации доступ к WebKit версии системы управления исходным кодом. Это показывает, что открытость может измениться в течение жизненного цикла проекта.

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

Заключение

Сегодня открытое программное обеспечение является «бизнес как обычно» в мобильной индустрии. Это доказано, что открытыми исходным кодом платформы, такие как Android может быть столь же успешными, как несвободные платформы с точки зрения принятия платформы, устройств продаж и разработки приложений. И хотя открытым исходным кодом играет ключевую роль в привлечении разработчика, это не предопределяет успех. Мобильный открытым исходным кодом проекта пространства находится в процессе консолидации в той мере, в какой:

  1. Symbian больше не является активный проект, был закрыт компанией Nokia и принес в доме в то время как Nokia изменит свои усилия с помощью платформы Windows Mobile.
  2. Nokia продал коммерческие права лицензирования для Qt Digia в марте 2011 года и в ноябре 2011 года сообщил, что они будут «abnegate собственности» от Qt сосредоточиться на время сопровождающих только.
  3. MeeGo больше не поддерживается активно Nokia или Intel как проект с открытым исходным, хотя части проекта MeeGo используются в недавно Tizen открытым исходным кодом платформы, которая была начата в сентябре 2011 года.

Эта консолидация не умаляет того факта, что мобильный открытым исходным кодом платформы может быть очень успешным – свидетель Linux, Eclipse и Android- но он вновь подчеркнуть важность организационной поддержки для успеха любого открытого проекта и сообщества. Чтобы стать успешным открывает исходный проект мы находим, что есть лучшие практики, как мы подробно в этой статье, которая должна использоваться для обеспечения наилучших вероятности для успеха.

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

 

 

Исследования, описанные в этой статье частично финансировалась webinos, финансируемый ЕС проект в рамках ЕС программы FP7 ИКТ (#257103). Для дальнейшей справочной информации и деталей анализа каждого проекта смотрите полный отчет, на котором основана эта статья: «Открыть индекс управления: Измерение истинной открытостью Open Source проектов с Android WebKit» (VisionMobile, 2011).

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
Нет голосов были поданы еще. Скажи свое слово!

Ключевые слова: Android, управление, открытым исходным кодом, откройте лицензии

Добавить новый комментарий

Обычный текст

  • Теги HTML не разрешены.
  • Адреса электронной почты и адреса страниц включите в ссылки автоматически.
  • Строки и параграфы переносятся автоматически.