January 2013 Download this article as a PDFAbstract

В этой статье мы кратко пять лет США Национальный научный фонд финансируется исследование, предназначенных для изучения факторов, которые способствуют совместные успехи некоторых проектов с открытым кодом, в то время как многие другие становятся заброшены. Наш основной интерес было провести исследование, которое близко отражает населения проекты программного обеспечения с открытым кодом в мире, вместо того, чтобы сосредоточиться на более часто изучали, громких успешных. После создания большой базы данных проектов (n = 174, 333) и крупномасштабный обзор разработчиков открытого исходного кода (n = 1403), мы смогли провести статистический анализ для изучения более сорока теоретически на основе testable гипотез. Наши данные твердо поддерживают, что мы называем традиционной теории открытого программного обеспечения, показывающие, что проекты начать с малого и в успешных случаях, растут немного больше, с точки зрения размера команды. Мы описываем «добродетельный круг» поддерживает обычные мудрость открытого сотрудничества, что выходит из этого анализа, и мы обсудим два других интересных выводов, касающихся мотивации разработчиков и как члены команды находят друг друга. Каждый из этих выводов касается устойчивости этих проектов.

Введение

Этот Специальный выпуск обзора Тим посвящено вопросы, связанные с идеей «устойчивости» по отношению к открытым исходным кодом программного обеспечения. Призыв к документы попросил авторов для подключения некоторые работы Элинор остром (1990; 2005; 2010), относящиеся к устойчивости, коллективных действий и общин и применять его с открытым исходным кодом. За последние семь лет моя исследовательская группа и я делаю это. В этой статье я кратко, как мы связаны с остром подход к изучению общин и сообщить некоторые важные выводы, касающиеся вопросов устойчивости в открытым исходным кодом программного обеспечения общин. В статье рассказывается о практических последствиях результатов исследований.

Наши перспективы исследований

Всеобъемлющих исследований вопрос вождения нашего исследования является: Какие факторы приводят некоторые открытым исходным кодом программного обеспечения общин к успеху и другие к отказу?

В основе этого вопроса является устойчивость открытого программного обеспечения, с точки зрения сотрудничества. Почему некоторые программисты остаются с проектом, в то время как другие оставить? Здесь мы сосредоточены не только на открытым исходным кодом добровольцев программистов – Центральной темой многих предыдущих исследований открытым исходным кодом- но платных программистов, а также. Кроме того главной целью нашей работы было исследовать истории успеха не просто громких, крупномасштабных (например, Linux, Web-сервер Apache), как и с большей частью ранних исследований по открытым исходным кодом, но получить лучшую ручку на неизвестного населения проекты программного обеспечения с открытым кодом, который в то время, мы начали нашу работу (~ 2005) был безусловно более 100 000 человек в номер.

Для начала нашего исследования, мы построили на Элинор остром и коллеги институционального анализа и развития (IAD) рамки (Остромирове, 2005; Рис. 1). В этом контексте как он применяется для открытия исходного программного обеспечения commons, Центральный блок анализа является отдельным открытым исходным кодом разработчика (алмаз на рис. 1), мы предполагаем, boundedly рациональный актер и который периодически отражает ли они по-прежнему способствовать проект. Эта логика, в любой момент времени, частично основывается на трех группах переменных или влиятельных факторов, которые могли бы повлиять на решение разработчика, изображен на левой стороне рисунка 1: i) технологические, ii) сообщества и iii) институциональные атрибуты открытого программного проекта. В Швейк и английский (2012), мы просматриваем значительный объем теоретической и эмпирической литературы в целях выявления важных факторов, которые, как полагают, влияют на другие виды общин (например, общих природных ресурсов) или мысли влиять на устойчивость проектов программного обеспечения. Это включало литературу на открытым исходным кодом, но также разработки программного обеспечения, виртуальный коллективный труд и экологического достояния или общей собственности (например, леса, рыболовство, ирригационные системы). Три группы атрибута на левой части рисунка 1 перечислены некоторые из факторов, – но не все-мы определили через эту работу. Чтобы дать читателю представление об этих трех атрибутов групп, рассмотрим пример каждого из них.

Технологический атрибут мысли влиять на разработчика решение остаться с проектом или отпуск может быть связан с «гранулярности задач», как Йохай Benkler (2006); Если задача разработки является слишком большим или «грубой зернистый», разработчик может решить, это требует слишком много усилий для волонтеров (или платные) времени он или она может выделить на него и может решить оставить проект.

Сообщества атрибут мысли влиять на разработчика решение остаться или оставить могут быть атрибуты лидер(ы) проекта. Лидерство – это сложная переменной или переменных, но один аспект относится к идее ведущих к примеру; лидеры мотивировать других на команде для работы, внося значительную работу сами.

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

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

Рисунок 1

Рисунок 1. Упрощенного институционального анализа и разработки рамок для поддержки анализа устойчивости в открытых исходного программного обеспечения commons. Адаптировано из Остромирове (2005) и Швейк & Английский (2012).

Методы

Чтобы начать нашу эмпирическую работу, мы сначала искали набора данных на открытым исходным кодом программных проектов, которые уже собраны, вместо того, чтобы построить с нуля. К счастью группа под названием FLOSSMole, базирующейся в Сиракузском университете активно соскоб доминирующим открытым исходным кодом проекта хостинг сайта SourceForge и создание базы данных по этим проектам для других исследователей использовать (Howison соавт., 2006). Их база данных содержит метаданные об этих проектах, наиболее связанные с технологическим или атрибуты, связанные с сообществом, но хотя бы одной институциональной переменной (лицензия используется). Нашей первоначальной базы данных SourceForge, собрались в летом 2006 года, содержал 107,747 проекты. В 2009 году мы собрали второй раз кусочек из другого хранилища под названием Архив данных исследований SourceForge.net, который находится в Университете Нотр-Дам. Этот второй набор данных, представляющий SourceForge проекты в 2009 году, содержал 174,333 проекты.

Наш следующий шаг заключается в разработке меру успеха и оставления для проектов программного обеспечения с открытым кодом. Это было сложной деятельности, который взял нас за полтора года до завершения. Сначала мы определили два разных продольных этапах, которые проходят проекты с открытым исходным кодом: i) этап посвящения и ii) стадии роста. Этап инициирования описывает период времени от начала проекта первый публичный релиз программного обеспечения. На хостинг сайта SourceForge легко найти новые проекты, которые еще не сделать код доступным для общественности, но активно разрабатываются на. Мы используем стадии роста для описания периода после проекта первый общедоступный выпуск кода. Одно можно концептуализировать «прекращение» или «оставление этапа», но в нашей концептуализации, что конкретное событие может произойти в любом стадии инициации (до первого выпуска) или в стадии роста (после первого выпуска).

С этими двумя этапами определены мы затем решили тщательно определить, теоретически и эмпирически, метод для определения, является ли проект успешным или брошенных на этих двух этапах. Мы определили шесть категорий успеха и оставления: Успех в инициации (SI); Отказ в инициации (AI); Успех роста (SG); Отказ в росте (AG); Неопределенный в инициации (II); и не определен в росте (IG). Подробности этого первоначального этапа нашего исследования можно найти на английском и Швейк (2007). Наша система классификации была позже реплицирована независимо друг от друга Wiggins и Crowston (2010). В таблице 1 представлены наши определения и результаты для набора данных SourceForge 2006; результаты наших данных SourceForge 2009, смотрите Швейк и английский (2012).

Таблица 1. Успех и отказ категорий для открытых программных проектов в базе данных SourceForge 2006

Класс

Определение

Число проектов

СИ: Успех в инициации

Разработчики подготовили первый релиз.

AI: Отказ в инициации

Не первый релиз подготовлен, и проект, как представляется, следует отказаться.

37,320 (35%)

SG: Успех в росте

Проект достиг 3 значимых выпусков программного обеспечения, и программное обеспечение является полезным для пользователей, хотя бы несколько.

15,782 (15%)

AG: Брошенный в рост

Проект представляется, брошенных до производства 3-релизы полезного продукта, или подготовила 3 или больше релизов в менее чем за 6 месяцев и отказались.

30,592 (28%)

II: Неопределенный в начало

Проект еще не раскрыть первый публичный релиз, но показывает активность значительных разработчиков.

13,342 (12%)

IG: Неопределенный в росте

Проект пока еще не принесли три релиза, но показывает развитие деятельности, или производит три релиза или более в менее чем за шесть месяцев и показывает деятельность в области развития.

10,711 (10%)

Всего по проектам

 

107,747

* Успешное начало (SI) цифры не перечислены, поскольку эти успехи являются стадии роста проектов; включая категории SI будет двойной граф проектов.

 

Эти наборы данных предоставляет отличный старт, но наши картирование SourceForge проектов определенных теоретических переменных (рис. 1) привело к выводу, что многие общины и институциональных переменных, которые мы хотели бы исследовать не были захвачены в этих наборах данных. Следовательно в 2009 году, мы осуществили дополнительные онлайн-опрос для разработчиков SourceForge для захвата этих недостающих переменных. Проблема заключается, что, если мы связались с случайной выборке администраторов проекта SourceForge, мы ожидали, что мы хотели бы получить значительный уклон в сторону успешного сотрудничества, которые были активны. Чтобы обеспечить достаточное количество ответов от заброшенных проектов, нам нужно попробовать гораздо большее число проектов SourceForge. Летом 2009 года мы стратифицированной наш 2009 dataset, используя наш успех/оставление классификации и произвольно отобранных 50 000 проектов для обследования. С помощью SourceForge Организации мы по электронной почте опрос администраторов проекта SourceForge для каждого из этих проектов. Результат: 1403 опросы вернулся.

С онлайн опроса мы смогли создать базу данных этих проектов 1403 и объединить его с SourceForge метаданных из dataset 2009 Нотр-Дам. Мы имели полный набор данных, захват нашей зависимой переменной успеха и оставления для инициации стадии и стадии проектов, а также меры для наших независимых переменных, связанных с технологическим, сообщества или институциональные атрибуты. Набор данных захватили более 40 независимых переменных, небольшой образец которого перечислены на рис. 1.

Мы использовали три статистические методы для анализа данных. Чтобы исследовать взаимоотношения отдельных переменных, мы использовали таблицы непредвиденных расходов для расследования различий в распределении для проектов, поскольку они относятся к успеху и оставления. Мы также использовали два различных многомерных аналитических методов: i) классификации и регрессии деревьев и ii) логистической регрессии. Полное объяснение этих методов, а также сводные таблицы и результаты доступны в Швейк и английский (2012).

Отдельные выводы

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

Во-первых у нас эмпирической поддержки для обычного мышления как open source программное обеспечение проектов действуют. Подавляющее большинство проектов с открытым кодом не имеют больших команд, но скорее очень небольшие команды разработчиков одного до трех. На основе тщательного анализа данных инициации стадии и стадии роста, мы обнаружили, что большинство этих проектов, как правило, начинаются с очень небольшой разработчиков из одного-двух разработчиков и очень мало или нет сообщества пользователей. Затем по мере продвижения работы, и после первого релиза, сообщество пользователей устанавливается и растет с течением времени. Основатель (ы) ведут через делать и путем разработки продукта, что они часто нуждаются (поддержка фон Хиппель [2005] идея «управляемые пользователем необходимости»), построить что-то можно использовать и в то же время начала для создания сообщества пользователей. Через регулярные открытые каналы связи (например, IRB сессий, списки адресов электронной почты, веб-сайты и системы отслеживания ошибок), они строят Социальный капитал между собой и их базу пользователей и постепенно растут их пользователей базы и добродетельный цикл начинается. На базе кода, приводит к (потенциально) больше пользователей и приводит к (возможно) добавлен разработчик больше прогресса. Однако, наше исследование может быть некоторые из первых эмпирических результатов, которые действительно захватывают это обычного мышления как открытого сотрудничества работает.

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

На основании того, что мы нашли, относящиеся к идее устойчивости проекта открытым исходным кодом, советы, у нас для руководителей проектов в стадии инициации:

  1. Будьте готовы положить в часы. Упорно работать в направлении создания первого выпуска программного обеспечения.
  2. Продемонстрировать, и сигнал хорошее руководство при администрировании проекта хорошо и четко шарнирное ваше видение и цели по каналам связи проекта (например, веб-сайт, система отслеживания ошибок). Создавать и поддерживать хорошую документацию для потенциальных новых разработчиков и сообщества пользователей через эти каналы.
  3. Рекламировать и рынок вашего проекта и общаться планы и цели, особенно если вы ищете новых разработчиков для продвижения проекта вперед в более долгосрочной перспективе.
  4. Осознать, что, в наших данных, успешные проекты находятся в GPL-совместимой или открытым исходным кодом бесплатно/libre non совместимой с GPL лицензии.
  5. При запуске проекта, рассмотреть его потенциал, чтобы быть полезным для значительного числа пользователей. Больше потенциальных пользователей у вас есть, тем выше вероятность того, что один или несколько из этих пользователей будут иметь соответствующие навыки и интересы, чтобы рассмотреть вопрос о присоединении и ваш проект вниз по дороге.

Наши советы для руководителей проектов в стадии роста (после первого выпуска) включает в себя:

  1. Сосредоточиться на идее создания и поддержания «добродетельный круг», где хорошие первоначальные продукты привлекают пользователей, которые потенциально привлечь нового разработчика, что приводит к больше улучшений. Наше исследование ясно показывает, что успешные проекты сообщества потенциально важных пользователей и что это сообщество пользователей диски непрерывности проекта.
  2. Убедитесь, что задачи различных размеров или требует усилий, которые люди могут. Успешные проекты в стадии роста, как правило, имеют задачи для людей, чтобы работать, вписываются в их доступные расписания. Напомним читателям концепции детализации задач по Benkler (2006), упоминалось ранее.
  3. Удивительно наши данные свидетельствуют о том, что конкуренция, как представляется, выступает за успех, вместо того, чтобы помешать его. Другими словами не сдавайтесь, если некоторые конкуренции появляется на горизонте.
  4. Финансирование помогает.
  5. Насколько это возможно Держите правила, регулирующие сотрудничество проекта и управления проектом, худой и неформальных. В значительной степени оперативные правила, которые существуют в open source программное обеспечение проектов часто встраивается в системах контроля версий, которые поддерживают проекты (например, CVS, Subversion), или просто создана группа социальных норм. Мы обнаружили, что подавляющее большинство проектов, которые мы изучали очень мало формализованы управления и в структурах управления типа «Великодушный диктатор». Другими словами они, как правило, поддерживают наши открытия цитатой Эрик Реймонд (2001). Наше чувство из нашего исследования, что простые, согласованные нормы, как правило, диск этих проектов является отчасти потому, что подавляющее большинство проектов, которые мы изучали очень небольшие команды, которые нуждаются в очень мало с точки зрения формальной координации. Однако, у нас было доказательства того, что, как команды увеличения размера, проект управления движется к более формализованы систем. Наши доказательства является довольно ограниченным, поскольку, в нашем наборе данных, очень небольшая доля проектов, изучали большие команды с 10 или более разработчиков. Но, это говорит о том, что, если проектная группа, команда должна не колеблясь, двигаться в сторону более формализованы систем при необходимости.

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

1. разработчик мотивы

Что касается вопросов о почему разработчики участвуют в открытых проектах наши результаты поддерживают большую часть существующей эмпирической работы, проделанной ранее. Брошенных и успешных проектов основным стимулом для участия был фон Хиппель (2005) ориентированных на пользователя необходимость. Разработчики участвуют, потому что они сами пользователи программного обеспечения, или потому, что Организации, в которой они работают, зависит от него. Другие разработчики участвуют потому, что они учатся в процессе чтения других кода и затем разработки новых функций продукта. Другие участвуют как «серьезный отдых», где они используют свои навыки программирования, что они используют для их трудоустройства и применить его к чему-то вне их работы домена для их удовольствия. Одной мотивации, что важно, последние исследования показывают,-мы обнаружили, что не важно, – это идея сигнализации навыков программирования для других, часто в попытке найти возможности трудоустройства. В нашем обзоре данных, это не было сообщено как важный фактор и, по нашему мнению, это потому, что подавляющее большинство команд достаточно мал (например, 1-3 человек). Но возможно наиболее интересные и новые найти относительно мотивации для участия в наших исследованиях наш вывод, что проекты с разработчиками, которые имеют несколько мотивации, вождения их участие будет более успешным, чем проекты с разработчиками с только одной мотивацией. Другими словами, проекты с открытым исходным кодом будет более устойчивым, если отдельные члены команды имеют несколько причин (например, «учиться и выплачиваются участвовать», или «я потому, что я содействие общественным благом, и потому, что мне нравится работать над проектом») вождения их интересы для содействия.

2. Sourceforge и Google как интеллектуальные сваты

Некоторые из наших наиболее тщательной работы в этом исследовании, показало, что успешный open source программное обеспечение проектов получить разработчик и что довольно часто этот новый разработчик не является физически рядом с пропускным (ы), который основал проект, а скорее являются географически удаленными и часто на другом континенте. Это дает некоторые убедительные доказательства, предполагая, известные сайты для открытого программного обеспечения, таких как SourceForge, в сочетании с веб поисковых систем как Google, создать интеллектуальные сваха сортов через «степенной закон типологии» (Karpf, 2010). Эти центры власти права являются места на Интернете, которые обеспечивают для своих пользователей, отчасти из-за сетевых эффектов создана потому, что они имеют большие толпы подобных пользователей. Независимо от того, где программист живет в мире люди могут найти программное обеспечение проекты, которые имеют отношение к этой потребности и, с течением времени социального капитала с разработчиками и в конечном итоге присоединиться к команде, если они говорят на одном языке и демонстрируют желание и навыки, необходимые для совместной работы.

Заключение

В этой статье мы описали пятилетний Национальный научный фонд США исследование по факторам, которые ведут некоторые проекты с открытым кодом для постоянного сотрудничества и других к отказу. Таким образом, мы находим твердую эмпирическую поддержку для обычных мудрость проектов как открытого программного обеспечения (см выше добродетельный круг обсуждения) и доклад двух наиболее интересных результатов исследования: i) что проекты будут более устойчивым, если разработчики имеют несколько стимулов, вождения их участия; и ii) успешные проекты получить разработчик и это скорее всего пропущенного через интеллектуальные сватовство, созданные поисковыми системами, такие, как Google в сочетании с центрами власти закона как SourceForge. Более подробно об исследованиях, сообщили здесь, см. Швейк и английский (2012).

Выражение признательности

Это исследование было поддержано Национальный научный фонд США под номером гранта 0447623. Выводы, рекомендации и мнения, высказанные здесь, однако, являются мои собственные и не обязательно отражают взгляды NSF. Я также очень благодарна моей исследовательской группы: Роберт английский, Сэнди Хейр, Менг-Shiou Shieh и другие, без которых эта работа будет не достигнуто.

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

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

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

Ключевые слова: общие, институциональный анализ совместной работы Интернет, открытое программное обеспечение, SourceForge

Комментарии

Привет

Можете ли вы поделиться 40 переменных, которые вы использовали для этого исследования? Это будет полезно для моей исследовательской работы.

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

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

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