January 2014 Download this article as a PDFAbstract

Эта статья предназначена как грунт для тех, кто заинтересован в получении базового понимания бизнеса открытого программного обеспечения. Таким образом, мы рассмотрим четыре основных направления: i) что мотивирует предприятия принять участие в open source; II) Общие открытые лицензии и как они связаны с сообществом и корпоративных интересов; III) вопросы, касающиеся монетизации открытым исходным кодом программы; и iv) открыть источник бизнес-моделей, используемых в настоящее время. Эта статья особенно подходит для людей, которые хотят общее понимание бизнеса открытого программного обеспечения; люди, которые хотят понять существенные вопросы, связанные с открытым исходным кодом программы потенциал для получения дохода; и предприниматели, которые хотят создать компанию вокруг открытого исходного кода.

Введение

В мире, построенный на открытости, в которой лицензирование диктует, что продукт не только бесплатно, но можно свободно копировать, изменен и перераспределяться энтузиастов и конкурентов, так, как может кто-нибудь возможно заработать деньги на открытым исходным кодом? Вопрос как один можно монетизировать open source программное обеспечение является значительным. Поиск и распространение его ответ был искра, которая началась, что должно было стать обзор управления инновационной технологии (Lavigne, 2007; Макфи, 2011).

Хотя многое было изучено за годы со времени появления open source и бизнес, который вырос до его окружают, есть еще несколько статей, которые пытаются обобщить его динамику. Возможно, наиболее известным из этих усилий является Хекер в «Настройка up магазин» (1998), которая в основном на какие стратегии могут быть использованы использования open source. Теперь, открытым исходным кодом является гораздо более зрелой области, чем это было тогда, мы можем сосредоточиться на документировании, что предприниматели сделали, а не могли бы сделать.

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

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

Справочная информация: Корпоративные мотивы

Принятие открытого исходного кода позволяет предприятиям использовать творческий потенциал и труда своих работников и их клиентов так, что не для фирм, используя только лицензии несвободных программ. Действительно, где разработчик мотивы включают многие социальные мотивы, фирмы имеют тенденцию подчеркивать экономические и технологические причины для ввода и содействия с открытым исходным кодом (Bonaccorsi и Росси, 2003). В дополнение к возможности время укороченные разработки (например, Dahlander, 2007) проекты с открытым исходным кодом обычно сообщают более широкого принятия их кода (например, "Запад", 2003) и получить более высокое качество обратной связи и Бугом докладов, чем проекты с закрытым исходным кодом (см. Шиндлер [2007] для сравнения). Также открытым исходным кодом лицензирование позволяет быстрее среднее время от обнаружения до решения (Шиндлер, 2007). Действительно с открытым исходным кодом, что продукты были часто показано, быть выше их собственных аналогов (например, Уилер, 2007). Кроме того компании могут увидеть, что развитие их продукта в направлениях, которые они не понимают важное значение для их пользователей, а также разработки функций, которые находятся слишком далеко от основной деятельности фирмы для получения внутреннего финансирования в целях развития. В качестве примера лишь два из более чем 20 языков разъемы для MySQL были запрограммированы в доме; остальные были разработаны и представлены сообществом.

Путем объединения усилий в области развития открытым исходным кодом, корпорации могут также влиять на направление его развития. Кроме того, открыть источник была определена в качестве стратегии для реализации долгосрочных устойчивых программных систем (например, Lundell и Gamalielsson, 2011). Открытым исходным кодом также может быть принят в качестве конкурентной стратегии, например путем функциональность конкурента продукт свободно (Fitzgerald, 2006). Открытым исходным кодом может также иметь значение для компаний, которые предлагают продукты за исключением программного обеспечения, например путем содействия открытым исходным кодом в районах, которые облегчают развертывание их оборудования (Fitzgerald, 2006).

Открытые лицензии

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

Одним из наиболее важных элементов и различия между открытым исходным кодом лицензии типов относится к концепции под названием лицензии совместимость. Совместимость лицензий — термин, используемый для описания проблемы, из которых могут быть объединены лицензии. В частности с точки зрения бизнеса, совместимость лицензии считает, какие лицензии могут быть объединены с несвободных программ. А еще вопрос, хотя и один малый интерес, является право на изменение лицензии, в частности ли одно может изменить лицензии открытого кода к собственной. Для бизнеса это может представлять интерес как источник свободного кода. Вопрос об изменении лицензии разбивает сообщество разработчиков на два лагеря. Те, кто для него обычно хотят обеспечить (или по крайней мере не возражаю) что их код как ценность для корпоративных интересов как это возможно. Те, кто против него обычно хотят обеспечить открытый исходный проект остается свободно доступных сообществу хорошо на неограниченный срок. Вопрос о лицензии объединения (включая внедрение) и изменение лицензии приводится в таблице 1.

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

Права

Разрешительного

LGPL

GPL

Может сочетаться с собственнические программы?

Да

Да

Нет

Позволяет ли это лицензия на лицензии?

Да

Нет

Нет

Гарантирует ли он доступ к исходному коду?

Нет

Да

Да

Разрешительные лицензии

Разрешительной лицензии позволяют высокую степень свободы для использования и повторного использования (или вилка) код. Это не крайняя упрощение для перегонять разрешительной лицензии вплоть до сообщения: «Вот код, делать все, что вы хотите с ним». (Обычно, необходимо распространять копии авторских прав с кодом, но на практике не должно быть более сложным, чем включая файл readme). Другими словами можно разветвить permissively лицензированную программу и сделать источник он закрыт. (Как, например, Apple OS X и iOS операционные системы содержат код, который был скопирован из permissively лицензированных open source проектов, в частности BSD). Вопрос, который устанавливает разрешительной лицензии отдельно от лицензии с авторским левом является, что, если исходный код компилируется, не нужно распространять исходный код с скомпилированный (например, двоичные) версии программы. Среди наиболее распространенных разрешительной лицензии являются лицензии Apache, MIT и BSD.

Слабый копилефт лицензии (LGPL)

Слабый копилефт лицензии, такие как GNU меньшей общественной лицензии (LGPL), могут быть объединены с собственный код, но не может быть перелицензировать под собственной лицензией. Таким образом хотя несвободные программы фирмы могут оставаться собственностью, даже в сочетании с LGPL, LGPL лицензированную программу нельзя сделать собственные. Кроме того любые изменения к программе LGPL, также должны быть лицензированы под LGPL. Общественной лицензии Mozilla (MPL) также является слабой лицензией.

Сильное авторское лево лицензии (GPL)

Многое, как LGPL является синонимом слабой "авторским левом", общей общественной лицензии GNU (GPL) является синонимом с сильным авторским левом. Таким образом мы сосредоточим наше обсуждение сильных copyleft лицензий на GPL. Хотя использование GPL в упадке (Эслетт, 2011), на момент написания этой статьи, это до сих пор наиболее распространенным открытым исходным кодом лицензии общей (черная утка базы знаний). GPL требует никаких изменений в код, также быть лицензированы под лицензией GPL. С точки зрения бизнеса, ключевой вопрос о что объединение или внедрить программу с GPL требует (re) лицензирование всех подключенных программного обеспечения так, чтобы это также под GPL. На практике это означает, открытых источников любых несвободных программ, подключенных к GPL лицензированной программы и поэтому то, что многие фирмы стремятся избежать. Важно отметить, что программы, лицензированы под лицензией GPL не может быть повторно лицензии по более либеральной лицензии (то есть, ни как LGPL или разрешительного).

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

С появлением облачных вычислений вариант лицензии GPL стоит особого упоминания является общая общественная лицензия Афферо (AGPL). AGPL отличается от GPL в онлайн использование программы считается распространение, тем самым вызывая требование соответствия лицензии (например, доступа к исходному коду требуется) Несмотря на то, что физическая копия программы не был распространен. Другими словами используя AGPL лицензированную программу в облаке требует распространения исходного кода.

Выбор лицензии

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

На бизнес открытым исходным кодом

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

Владение кода

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

Местоположение в стек программного обеспечения (и «встроенные» программы)

Большинство программ опирается на другое программное обеспечение для запуска. Эта концепция codependence программного обеспечения является наиболее очевидной в так называемых программного стека. На вершине стека — это приложение: программа обработки текста, редактор фотографий, игры и др. Копаем глубже, можно найти элементы, такие как базы данных, промежуточного по и операционной системы. Это не важно для целей этой статьи, чтобы понять слои или функции стека программного обеспечения; Это просто достаточно, чтобы знать, что такие слои существуют и что расположение программы в стеке имеет важное значение для его общее значение для стека. Программы, расположенные выше в стеке используют программы ниже, вплоть до функции, но не наоборот. В то время как текстовый процессор нуждается в операционную систему для запуска, операционная система не текстовый процессор для его функции. Один из способов для open source программа для получения потенциальной стоимости является наличие других программ полагаются на него: встроенные в стек программного обеспечения и является обязательным компонентом для приложений и других программ для правильной- или даже работать вообще.

Бизнес-модели

Хотя бизнес-модель можно было бы рассматривать как нечто гораздо сложнее, чем просто источником дохода (например, Запад, 2007; Bailetti, 2009), по своей сути является вопрос как фирма может создать значение для клиента, при этом одновременно извлекать некоторые из этого значения для себя (запад, 2005). Для целей этой статьи мы делаем использовать очень широкие мазки в нашей интерпретации, используя термин «бизнес-модель» для указания пути, в котором компания поставляет значение набора клиентов на прибыль (например, Джонсон, 2010). Рекомендуемое чтение для более углубленного анализа вопросов, связанных с бизнес-модели предлагаются в конце статьи.

Бизнес-модели открытым исходным кодом можно разделить на две категории: те, которые требуют полного (или по крайней мере частично) владение код и те, которые не. В таблице 2 описываются критерии для выбора открытым исходным кодом бизнес-модели; Однако следует отметить, что эти бизнес-модели не должны быть взаимоисключающими.

Таблица 2. Критерии выбора бизнес-моделей

Критерии

Поддержка и услуги

Открыть Основные

Бизнес источник

Двойное лицензирование

Можно выбрать этот бизнес модель, даже если код не владею?

Да

Нет *

Нет

Нет

Можно выбрать этот бизнес модель, даже если моя программа не внедрен?

Да

Да

Да

Нет

* Владение требуется для расширений закрытого источника

Контракты на поддержку и услуги

Поддержка и услуги являются тесно взаимосвязанных подходов; в самом деле компании, которые предоставляют один часто также предоставляют другой. Таким образом хотя они могут быть разделены, мы решили сгруппировать их по одной статье. Услуги бизнес-модель является одним в котором доходы, предлагая услуги в виде, например, обучение, консалтинг или разработка расширений вокруг открытым исходным кодом продукта. Компании, которые предлагают услуги будут обычно также предлагают долгосрочную поддержку контрактов, обеспечивая тем самым более стабильный доход, чем просто фокусируясь на разовые услуги. Две из основных проблем при поддержке и услуг подхода, являются отсутствие масштабируемости и что типичная прибыль в 20 – 30% не достаточно, чтобы платить за полный рабочий день разработчиков для проекта.

Наличие поддержки и услуг является важным фактором для клиентов (например, Shanker, 2012) и может считаться необходимым элементом для программного обеспечения, чтобы стать действительно успешным. Имейте в виду, что, хотя следует предложить поддержку, он не должны предоставляться в той же компанией, которая разрабатывает программное обеспечение. Примеры поддержки и услуг поставщиков являются Red Hat и SkySQL. Дополнительные сведения о подходе Red Hat смотрите Suehle (2012).

Открыть основной или коммерческих расширений

Open core является бизнес-модель, в которой ядро программы является открытым исходным кодом, с дополнительным закрытым исходным кодом функции, предоставляемые за отдельную плату. Open core получил много импульс за последние несколько лет. Однако это подход в основном на апеллируя к венчурным капиталистом, вместо того, чтобы конечный пользователь (Прентис, 2010). Экономическое обоснование носят четкий характер, но реакция сообщества и клиенты не могут быть так же легко оценить. Несмотря на прагматичные твердые мотивы принимаются сообществом условии, что они соответствуют правилам сообщества (Bonaccorsi и Росси, 2003), некоторые разработчики видят открытый основной подход нарушение этих норм. Сторонники свободного программного обеспечения критиковать его по идеологическим соображениям, и сторонники открытого программного обеспечения критиковать его по техническим причинам, из-за ограничений для модели развития, вызванных ограниченным доступом к коду. С точки зрения конечного пользователя, откройте основные силы поставщика блокировки и Кроме того сбой с не доставлять и поддержание экономии средств и гибкость открытого программного обеспечения (например, Фиппс, 2012). Потенциальные результаты применения этой модели могут включать проблемы в привлечении и сохранении разработчиков (см. Dahlander и Магнуссон, 2005; 2008), или даже появление конкурирующих вилки (Найман, 2013).

Однако следует отметить, что существуют успешные открытые основные проекты, которые показывают, что подход может работать. Если открыт основной подход, стоит принимая во внимание, что более полезным является основным продуктом, тем больше потенциальный интерес сообщества. Таким образом что делает non критические части программы закрыты будет уменьшить возможное негативное воздействие на разработчиков интерес в проекте. Ограниченное по времени гибрид лицензирование (Спрюэлл, 2010), в котором закрытые исходные компоненты open core стать открытым исходным кодом после задержки 1-5 лет, было предложено помочь удовлетворить требования пользователей и разработчиков. Однако мы поставим, что бизнес-источник подход объясняется ниже может быть более взаимовыгодных средств с этой целью. Примеры открытых ядра не являются легко найти, как частое обсуждение темы за последние несколько лет будет означать. Пожалуй, наиболее известным примером является MySQL, которая предлагает двойное лицензирование идентичных продукта (закрытого источника и версии GPL) под ее предыдущих владельцев, но изменилось на открытый основной подход к своей бесплатной версии после того, как он был куплен Oracle (Янг, 2011).

Бизнес источник

Бизнес-источник является бизнес-модель, которая использует две различные лицензии с задержкой по времени. В этой бизнес-модели исходный код, открыто распределенными и свободно редактировать. Однако, за определенное количество времени, предварительно определенный сегмент пользователей (0,1 – 1% предлагается) должны платить иметь возможность использовать его. После этого первоначального периода (3-х лет предлагается) лицензия автоматически изменяется на лицензии с открытым исходным кодом. Источник бизнес-новый участник в области открытого лицензирования, который мы впервые подробно в июне 2013 года выпуске обзор управления инновационной технологии (Видениус и Найман, 2013). Он был создан, чтобы помочь одновременно удовлетворить потребности сообщества open source и открытым исходным кодом предпринимателя; будучи слишком ограничительным в лицензировании может нанести вред росту сообщества, в то время как слишком ограничивающим может нанести вред росту бизнеса. Хотя недавно введенной концепции, уже есть отчеты компаний, переключение на источник бизнес с разработчиками и владельцы довольны результатами (Видениус, 2013). Для более глубокого представления исходного подхода бизнес, с лицензией образца см. Видениус и Найман (2013).

Двойное лицензирование

Двойное лицензирование является бизнес-модель, в которой предлагается две отдельные лицензии, обычно в одной версии под "авторское лево", GPL-лицензией в стиле, а другой под коммерческим, с закрытым исходным кодом лицензии позволяет для несвободных использования (и в сочетании с другими несвободных программ). Традиционно источник для обеих версий идентичны, за исключением изменений в области авторского права. Двойное лицензирование является лучшим вариантом для программ, внедренных, и для которых один владеет код. Основными заказчиками являются компании, которые хотят включить программное обеспечение в своих собственных пакетов, но которые не хотят выпустить свой код под открытым исходным кодом, как GPL. Отличная масштабируемость делает двойное лицензирование потенциально наиболее прибыльным бизнес-моделей, представленных в настоящем документе. Первый когда-либо программа двойного лицензирования подхода был Ghostscript; MySQL – (до и во время его собственности Sun-была вторая программа для использования этого подхода и первыми использовать GPL как открытым исходным кодом лицензии.

Программное обеспечение как услуга

Программное обеспечение как услуга (SaaS) является довольно новой бизнес-модели, в которой соединители и приложений интерфейсы программирования являются открытым исходным кодом, но недоступен код сервера, который они подключаются к конечному пользователю. Например можно использовать приложение, которое может получить доступ к некоторым данным на сервере, но не сможет получить доступ к фактический исходный код (, например, система управления базами данных) на сервере, который один обращается к. Хотя SaaS напрямую не связаны с открытым исходным кодом, он включен здесь потому, что она может включать компоненты с открытым исходным кодом. Примерами SaaS бизнеса являются Salesforce и веб доверия; в строительстве их службы, они могут использовать open source программное обеспечение на своих серверах, но это программное обеспечение не распространяется их пользователям.

Управленческие последствия

При принятии решения начать проект с открытым исходным кодом или нет, следует рассмотреть следующие управленческие последствия:

  1. BEfore, начиная новый проект открытым исходным кодом, проверьте если аналогичный проект уже существует. Участие в активной программе предпочтительнее начать новую вилку. Если подобные программы, которые были заброшены, сделайте некоторые исследования, чтобы выяснить, почему они были заброшены. Репозитории, такие, как GitHub и SourceForge есть множество заброшенных программ.
  2. Найти компанию или группу пользователей, которые хотят работать с вами, чтобы определить область проекта. С самого начала вы хотите, чтобы пользователи, использующие продукт, в то время как он все еще находится в разработке.
  3. Два из наиболее важных решений будет бизнес-модели и лицензии. Если вы планируете на полагаться на участие общин, помните об их реакции на выбор модели и лицензии как бизнес. Смотрите в конце этой статьи для дальнейшего чтения на сообщества.
  4. При выборе бизнес-модели, рассмотрите эти вопросы: Вы хотите сосредоточиться на услуги или развитие? Планируете ли вы иметь большое сообщество или работать с несколько крупных компаний? Планируете ли вы принять в инвесторов? И, если да, то, что ваш план выхода?
  5. При выборе лицензии, рассмотрите эти вопросы: Какова будет ваша бизнес-модель? Сколько контроля вы хотите использовать (и потенциальные вилки) код? Какие сообщества вы хотите привлечь вокруг продукта?
  6. Если вы планируете полагаться на участие общин, не забудьте использовать создание сообщества инструментов для достижения и общаться с ними: веб-страницы, форум или базы знаний, списки рассылки, ошибка системы, построения систем, репозиторий исходного кода, и др. Вы можете начать хостинг вашего проекта на GitHub, SourceForge или другого репозитория, но вы в конечном итоге хотите разместить его самостоятельно.
  7. Значительные благоприятные факторы для создания успешного бизнеса вокруг открытого источника являются собственностью кода и соответствия (программы местоположение в стек программного обеспечения). Эти же факторы также в значительной степени определить, какие бизнес-модели, можно выбрать из. На рисунке 1 представлена блок-схемы, чтобы помочь выбрать бизнес-модель, на основе владения, соответствия и намерения для дальнейшего развития. Если блок-схема рекомендует начать бизнес, рассмотреть вопрос о партнерстве, либо выпуская код (например, под лицензией Apache или BSD) для кого-то еще, чтобы продолжить разработку программного обеспечения.

Рисунок 1

Рисунок 1. Блок-схема для выбора открытым исходным кодом бизнес-модель

 

Заключение

Через этот грунт мы дали краткий ответ на вопрос: «Как можно сделать деньги на open source?» Для непосвященных финансирование бизнеса, основанного исключительно вокруг разработки открытого исходного кода может возможно показаться несколько загадочным. Хотя сложно, тем не менее это возможно. Наша цель в этой статье было прояснить эту загадку, объясняя некоторые из его наиболее значимых частей.

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

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

 

Таблица 3. Рекомендуемая литература

Тема

Ссылки

Открыть источник лицензирования

Валимаки (2005)

Международный свободный и открытый источник программного обеспечения Law Review

Выбор лицензии открытого источника по отношению к бизнес-модели

Daffara (2011)

Проблемы совместимости, соответствие и законность лицензии

Уилер (2007)

Хаммуда соавт (2010)

Лохман соавт (2013)

Популярность различных лицензий

Чёрная кряква база знаний

Подробнее о конкретных лицензий

Open Source инициатива

Фонд свободного программного обеспечения

Откройте источник и бизнес-моделей

Запад (2007)

Bailetti (2009)

Хекер (1999)

Проуз (2010)

Suehle (2012)

Соответствующие лицензии с бизнес-моделями

Гитаристом соавт (2011)

Бизнес источник

Видениус и Найман (2013)

Стратегии партнерства

Riekki Одле (2010)

Бизнес-модели для компаний, в партнерстве с открытым исходным кодом поставщика

Groganz (2011)

Модели сотрудничества между их общинами и проектов с открытым исходным кодом

Нури и Вайс (2013)

Вайс (2011)

Клиента ценностного предложения для корпоративного открытого программного обеспечения

Shanker (2012)

Поддержка открытых источников и его требований

Петерс (2007)

Создание сообщества

Байрон (2009)

Архитектура участия в корпоративном открытым исходным кодом

Запад и O'Mahoney (2008)

 

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

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

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