Как вы эффективно конкурируете с проектом с открытым исходным кодом?

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

Я прочитал эту статью, в которой автор излагает этот сценарий:

Предположим, можно разделить рынок программного обеспечения - скажем, управление сетью - между двумя продуктами. Один делал все возможное и стоил 1 миллион долларов, а другой только на 10% больше, но был бесплатным и открытым.

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

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

Занимает 76К дискового пространства. Это "К", как в "килобайтах".

Сравните это с Microsoft Word. Я думаю, что в прошлый раз, когда я установил только Word, он был размером около 30 МБ, во много раз больше, чем MacWrite, но я использую его не намного больше, чем MacWrite. Как и я, многие пользователи довольны базовым функционалом. Им не нужны все навороты.

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

Однако, если этот проект является здоровым и устойчивым, то через год или около того, возможно, он сделает 15-20% от того, что делает коммерческий продукт. Это должно отбросить еще несколько пользователей из их бизнеса, и, возможно, теперь они начнут обращать внимание.

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

Проходит еще год или два, и теперь в проекте реализовано до 50% функциональности коммерческого продукта. Люди начинают присоединяться к проекту группами. Коммерческая компания теперь должна что-то сделать. Что они делают? Они добавляют больше возможностей.

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

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

Надуманным? Я так не думаю. Есть только два основных требования:

Во-первых, найдите рынок, где открытый исходный код предоставляет убедительную альтернативу, такую ​​как управление сетью.

Во-вторых, создать устойчивое сообщество вокруг проекта с открытым исходным кодом.

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

Поскольку вы не можете конкурировать по цене, тогда конкурируйте по всем остальным пунктам продажи, которые имеет программное обеспечение:

• функции
• качественный
• эффективность
• интеграция с другим программным обеспечением
• оказание услуг
• поддержка
• прямая продажа

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

Делая ваш продукт лучше, чем предложение с открытым исходным кодом. Вот так Photoshop может конкурировать с GIMP.

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

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

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

Ничто из следующего не относится к проектам OSS, таким как Linux, Firefox, MySQL или PostgreSQL. Это нетипично, поскольку они поддерживаются компаниями и / или опытными программистами.

В любом случае, по причинам, по которым клиент будет платить за программное обеспечение:

OSS склонен к ползучести / Клиенты будут платить за более простое программное обеспечение

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

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

Конечные пользователи хотят простые инструменты. Они должны выполнять свою работу без обучения или суеты. Они хотят, чтобы их инструменты принимали за них правильные решения; не варианты. Если вы можете предоставить что-то более простое, чем автономная реализация OSS, вы получите платных клиентов.

OSS, как правило, низкого качества / клиенты будут платить за более высокое качество

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

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

WordPress, например, был разветвлен из B2 (сам разработанный студентом) студентом. Несколько версий и неисчислимое количество клейкой ленты позже, это делает работу. Но под капотом, это поток ошибок с небольшим, если вообще какой-либо контроль качества. (Последнее, что я пробовал, он не прошел свой собственный набор тестов.)

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

У OSS, как правило, слишком короткий цикл разработки / клиенты будут платить, чтобы избежать хлопот

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

Однако в долгосрочной перспективе компании предпочитают длительные циклы выпуска; чем дольше, тем лучше. Это меньше планирования и меньше работы для ИТ-отдела. Нет ничего страшного, если конечные пользователи обновляют свой браузер каждые три месяца или около того. Это совершенно другая история, если вы обновляете критически важные приложения.

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

Сравните с WordPress, который время от времени обсуждает трехмесячный цикл выпуска, несмотря на уже слишком короткий цикл. (Их бета-версии - это, по сути, версия xy0 каждого выпуска.)

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

OSS имеет тенденцию бездумно принимать открытые стандарты.

HTML5 видео тег является показательным примером здесь.

Mozilla отказывается от h.264 в том, что им нужен кодек с открытым исходным кодом. И в этом смысле они абсолютно правы: последнее, что они хотят, - это попасть в список хитовых патентов; поэтому они настаивают на Ogg.

В отличие от Apple, случай использования h.264 практичен: он уже широко поддерживается, и для него предусмотрено аппаратное ускорение (что позволяет продлить время автономной работы iPhone); для Ogg такого нет.

Миллионы устройств iOS были проданы позже, сайты, которые беспокоятся о том, чтобы доставить видео этим пользователям iOS, поддерживают html5 / h.264. Иными словами, клиенты говорят: им нет дела до открытых форматов.

Единственная компания, которая довольна результатом этой ядовитой битвы за кодеки, - это Adobe: пользователям Firefox де-факто по-прежнему будет нужна Flash, если они захотят воспроизводить видео. Если основной сайт переключается на видео html5 / h.264, кодер быстро найдет расширение или плагин для преобразования необходимых тегов видео в проигрыватели флэш-видео. (Это может даже существовать.) Во имя поддержки открытых стандартов (которых, кстати, нет).

Никто никогда не был уволен за выбор IBM

Это старая индустриальная шутка, но в этом есть доля правды: при использовании ИТ-бюджета вас не уволят за выбор того, что сверстники считают лучшим в своем классе.

Крупные корпоративные покупатели, которые не хотят рисковать, будут продолжать покупать настольные ПК на базе Microsoft, Office, SAP, а что нет; даже если есть альтернативы с открытым исходным кодом. Как дерьмо случается .

Когда OSS попадает в крупные корпоративные среды, обычно это происходит не потому, что технический директор увидел свет и решил использовать бесплатные инструменты; скорее это направляется третьей стороной, которая предлагает (дорогие) услуги на вершине.

Я думаю, что суть аргумента в том, что «коммерческий продукт уже сделал 100% того, что нужно людям», заключается в том, где аргумент разваливается. Ни один продукт не может претендовать на то, чтобы сделать 100% того, что нужно людям, и, конечно, не самым эффективным (с точки зрения эффективности оператора), простым в использовании и общепризнанным «лучшим» способом.

Если бы такое было возможно, то, конечно, единственное, на что можно было бы конкурировать, это цена. Но поскольку объективное «лучшее» и универсально «наиболее эффективное» приложение невозможно, всегда будет больше вещей, чем просто цена, чтобы конкурировать.

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

1. Linux против Windows
2. PHP против ASP.NET
3. [что-то или другое] против Visual Studio
4. GIMP vs. Photoshop (до меня ответили, но мне действительно нужен пример не MS :))
5. vBulletin против 30+ других пакетов досок объявлений

Проблема с открытым исходным кодом в том, что он открыт. Если у вас есть этот код, вы получаете продукт A. Все ваши конкуренты имеют одинаковый код. Таким образом, вы тратите все это время на написание программного обеспечения, если его часть может быть сделана другими участниками, но если вы управляете компанией, вы тратите ресурсы, и все же любой может прийти и начать продавать то же самое, что вы потратили годы разработки. Поэтому самой большой угрозой для компании с открытым исходным кодом может быть необязательно компания с закрытым исходным кодом, а остальные 5 компаний с открытым исходным кодом.

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

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

В конце концов, это формула вашего успеха: [инженерные инновации] x [маркетинг] = прибыль. Вы можете иметь лучший продукт, но если никто не знает об этом, никто не использует его. И ясно, что если вы создаете что-то дерьмовое, никакое количество рекламы не спасет его. Я считаю, что многие проекты с открытым исходным кодом всегда имели проблемы с [маркетингом], когда дело доходит до проникновения на общие потребительские рынки.

Одна область, где большинство программного обеспечения с открытым исходным кодом не может конкурировать с проприетарным программным обеспечением, - это кривая обучения.

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

Я не уверен, почему это так. Однако я могу сказать, что я более чем готов платить за программное обеспечение, которое выполняет работу с минимальными усилиями с моей стороны. Это цель программного обеспечения в конце концов.

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

Удобство и возможности - единственное, что есть у коммерческого проекта с закрытым исходным кодом, которого нет у большинства проектов с открытым исходным кодом, - это способность контролировать четкое видение того, каким должен быть продукт.

Все зависит от размера / сложности, но меньший программный продукт для одной команды сможет сосредоточиться на рынке, к которому они пытаются обратиться. (Другой пример - как BBEdit и TextMate могут обратиться к группе людей, готовых заплатить за текстовый редактор, учитывая наличие jEdit, gEdit и т. Д. Что предлагает TextMate, достаточно привлекательный, чтобы заставить людей раскошелиться на 20 долларов? - $ 30)?

Сосредоточив внимание на конкретных проблемах клиентов. Много раз я видел, как организации тратят тысячи долларов на «эту особенность».

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

Как уже упоминалось @SnOrfus, сервис и поддержка имеют решающее значение. Я видел миллионы раз, когда организации предпочитали закрытый исходный код над открытым исходным кодом (и даже доплачивали), чтобы получить комфортную возможность приобрести какой-то один just_in_case!

(это может быть немного ориентировано на корпоративных клиентов)

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

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

Используйте это в ваших интересах. Пусть бесплатный продукт тоже будет на рынке, не будь враждебным. Во всяком случае, это расширяет рынок - в какой-то момент пользователи бесплатного продукта, возможно, захотят испытать навороты вашего коммерческого решения.

Для простоты давайте сведем факторы успеха программного обеспечения к трем «инвестициям»:

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

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

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

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

Теперь вернемся к вопросу ОП: есть ли у компании с закрытым исходным кодом стратегия выживания?

Статья, цитируемая OP, кажется самоограничивающей, потому что она рассматривает только две крайности:

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

Как насчет середины?

• Несколько компаний-разработчиков программного обеспечения подписывают соглашения о кросс-лицензировании для совместного использования части исходного кода и / или API? (В которой одна из сторон ориентирована на услуги.)
• Компании, которые эффективно используют лицензированные компоненты или библиотеки с открытым исходным кодом в стиле BSD (и делают взносы в натуральной форме), не открывая исходный код основного продукта?
• Компании, которые предоставляют исходный код текущего программного обеспечения в рамках ограниченного по времени соглашения «предварительного просмотра сообщества»?
• «Доступный источник»: компании, которые предоставляют исходный код платящим клиентам?

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

Однако есть предостережение: если программное обеспечение является бесплатным, будут ли клиенты выбирать его среди альтернатив, даже если программное обеспечение плохо работает по некоторым показателям?

• Продажи и маркетинг: можете ли вы продвигать продукт практически бесплатно с помощью вирусного маркетинга?
• разработка: может ли проект с открытым исходным кодом получить большую часть своего проекта / разработки / документации от неоплачиваемых добровольцев? Может ли компания извлечь выгоду из такого проекта?
• услуги: может ли программный проект революционизировать свою программную область, чтобы сделать его очень простым, чтобы каждый мог стать мгновенным экспертом, снижая входной барьер до нуля?

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

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

Корпорация может попытаться привить производителя к блокировке, но это только замедляет убытки; это не приносит вам никаких клиентов.

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

В долгосрочной перспективе вы, вероятно, облажаетесь, но это может сделать «краткосрочный» в «обозримое будущее».

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

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

Это не обязательно открытый исходный код или закрытый исходный код - почти все плохо документировано. Возможно, ваш конкурент в этом 1% проектов хорошо документирует, но это маловероятно;)

Проще говоря, уловка состоит в том, чтобы продолжать переопределять 100%. FOSS просто не имеет такого же масштаба и рабочей силы, как коммерческий проект, и существуют пределы того, насколько тесно вы можете конкурировать с существующим продуктом. Компания с закрытым исходным кодом использует хуки пользовательского интерфейса, поэтому использование конкурирующего продукта кажется невозможным из-за различных, например, сочетаний клавиш. Кроме того, они продолжают добавлять основные функции, которые конкурент FOSS просто не мог рассмотреть. Например, рассмотрим Visual Studio. Это была просто C ++ IDE, но затем они начали объединять совершенно новые языки и фреймворки, такие как .NET. Или Visual Studio 2010, которая упаковывает библиотеку потоков коммерческого уровня (например, Intel продаёт эквивалентную автономную) для C ++. FOSS просто не может идти в ногу с таким развитием, а зачастую и надёжностью.

Ориентируйтесь на традиционные корпоративные рынки и станьте популярными.

Для многих крупных традиционных компаний это сводится к трем вещам:

• поставщик, с которым они могут заключить обязывающий контракт для (возможности и надежность)
• поставщик, с которым они могут на контрактной основе обеспечить соблюдение определенного соглашения об уровне обслуживания (быстрое качество поддержки)
• обзоры gartner (это современный эквивалент «никто не уволен за выбор IBM)

Все трое бездумно соблюдаются и не особенно актуальны. Проблемы с возможностями всегда перепроданы, у SLA всегда есть оправдание, а gartner опрашивает только тех людей, которые слушают gartner, но когда вы являетесь менеджером среднего звена в корпорации, в которой есть много менеджеров высшего среднего звена, которые сталкиваются с проблемами высшего руководства когда высшее руководство наконец узнает, что было принято решение, которое стоило огромной кучи денег, вам понадобится некоторая документация от третьей стороны, которая поддержит вашу должность, если вы хотите сохранить свою работу. Даже если вы прекрасно знаете, что с технической точки зрения вы сбрасываете большие унитазы в унитаз, не стоит рисковать, пытаясь поступить правильно.

Сколько плохих применений SAP или SharePoint вы видели в промышленности? Сколько из них было бы лучше, если бы они были сделаны на чем-то другом, что лучше подходило бы, но не было именем большой индустрии?

Я использую много инструментов Microsoft, и у меня есть учетная запись MSDN, но я, честно говоря, получаю лучшую помощь от MS в Твиттере, чем через телефонный центр MSDN. Я не могу себе представить, что я получу худшую помощь от людей, стоящих за проектом с открытым исходным кодом, чем от людей, не поддерживающих поддержку, пишущих в твиттере в свое свободное время, но это не входит в уравнение ответственности / Гартнера.

Как сказал SnOrfus, продавайте функции, которые мы делаем.

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

Это поможет вам представить ваш продукт массовым людям, то есть сила с открытым исходным кодом и людей.