Як ви ефективно конкуруєте з проектом з відкритим кодом?


36

Компанію з надійним проектом з відкритим кодом, що конкурує проти традиційного продукту із закритим кодом, начебто неможливо перемогти.

Я читав цю статтю, де автор викладає такий сценарій:

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

Цінник комерційного рішення автоматично відфільтрує велику кількість користувачів, і цим людям доведеться звернутися до відкритого коду. Але деякі користувачі будуть задоволені 10-відсотковим функціоналом і виберуть його прямо.

Наприклад, у мене на столі оригінальний комп’ютер Macintosh. Він запускає текстовий процесор під назвою MacWrite. Це робить усе, за винятком перевірки орфографії, що мені потрібен текстовий процесор. Я можу форматувати абзаци, вибирати шрифти, робити текст жирним або курсивом і навіть вставляти зображення та графіки. Все в користувальницькому інтерфейсі "те, що ти бачиш, те, що ти отримуєш".

Він займає 76K місця на диску. Це "K", як у "кілобайт".

Порівняйте це з Microsoft Word. Я думаю, що останній раз, коли я встановив лише Word, він становив близько 30 Мб, у багато разів більший за MacWrite, але я не використовую його набагато більше, ніж я використовую MacWrite. Як і я, багато користувачів задоволені базовим функціоналом. Їм не потрібні всі дзвіночки.

Але повернемось до моєї аналогії. На початку комерційна компанія, ймовірно, ігнорувала проект з відкритим кодом. Це не представляє загрози для їх потоку доходів, тож чому вони повинні звертати увагу на швидкість?

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

Швидше за все, ця увага взяла б форму маркетингу проти проекту. Вони стверджують, що це занадто мало або занадто недооцінене, щоб сприймати серйозно. І в короткому періоді це, мабуть, спрацює. Але сам факт визнання проекту викликав би інтерес. Деякі люди визначали б для себе, що це не було ні занадто мало, ні надто малопотужно, і почали би його використовувати.

Ще рік-два проходить і зараз проект складає до 50% функціональності комерційного продукту. Люди починають приєднуватися до проекту у сукупності. Зараз комерційна компанія повинна щось робити. Що вони роблять? Вони додають більше функцій.

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

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

Надуманий? Я не думаю, що так. Є лише дві основні вимоги:

По-перше, знайдіть ринок, де відкритий код пропонує переконливу альтернативу, таку як мережеве управління.

По-друге, створити стійку громаду навколо проекту з відкритим кодом.

Це здається дуже правдоподібним. Якби ви були компанією із закритим кодом, як би ви змагалися ??


2
Коментатори : коментарі призначені для пошуку роз'яснень, а не для розширеного обговорення. Якщо у вас є рішення, залиште відповідь. Якщо ваше рішення вже розміщено, будь ласка, підкажіть його. Якщо ви хочете обговорити це питання з іншими, скористайтеся чатом . Див . FAQ для отримання додаткової інформації.

8
У такому суб’єктивному відповіді, якнайкраща інформація, є у коментарях.
Річард

подати позов до користувачів продукту з відкритим кодом en.wikipedia.org/wiki/SCO/Linux_controversies
Еван

Відповіді:


42

Оскільки ви не можете конкурувати за ціною, то змагайтеся за всі інші точки продажу, які має програмне забезпечення:

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

В основному, ви робите те, що робить будь-яка інша компанія, коли вони перебувають у ціновій конкуренції: йдіть в ногу або змінюйте гру.


2
+1 для "Змінити гру", якщо ви не можете перемогти опонента за його умовами, тоді вам просто потрібно знайти терміни, які вам більше підійдуть.
Матьє М.

1
Після того, як ви починаєте мати конкурента з відкритим кодом, на який насправді варто звернути увагу, хороший спосіб продумати ділові стратегії, щоб скористатися, - зробити вигляд, що ви збираєтесь також відкривати свій проект. Змініть свій бізнес, щоб він залишався вигідним при цій умові, і вам зрозуміло, чи ви насправді відкрили його, чи ні
blueberryfields

Я додам: Запитайте "хто керує притулком"? Не дозволяйте товаришам управляти притулком. Якщо це програмісти, то ув'язнені є.
mattnz

Я думаю, що зміна гри зробила це для мене. Я думаю, що це все, що ти маєш, врешті-решт.
Річард

1
Звичайно, вам потрібно розставити пріоритет у своїх зусиллях, і я думаю, що вони спинилися в цьому списку. Відкритий код, ймовірно, може конкурувати за функціями, якістю та ефективністю, а іноді й за інтеграцію з іншим програмним забезпеченням, але сервіс, підтримка та продажі є слабкими місцями у відкритому коді та важливими для ринків Big Co.
Кевін Вермер

34

Роблячи ваш продукт кращим, ніж пропонують відкритий код. Ось так Photoshop може конкурувати з GIMP.


2
Так це чисте панування ресурсів?
Річард

11
Ні - ресурси не обов'язково роблять кращий продукт.
Стівен С

5
@TheLQ: Такі програми, як Notepad ++, EditPad Pro, навіть Emacs / Vim, показують, наскільки далеко ви можете піти, щоб диференціювати свій "текстовий редактор" на ринку.
Дін Хардінг

9
Photoshop - хороший приклад збереження клонів у страху, просто завдяки дуже хорошому продукту.

4
Немає такого вичерпання всіх можливих речей, які ти можеш зробити.
Kyralessa

33

Я думаю, що згадуваний вами твір сильно вводить в оману тим, що він повністю ігнорує якість пропозиції з відкритим кодом. Задайте собі трохи інше, але пов'язане з цим питання:

Як компанія може вижити, продаючи програмне забезпечення з відкритим кодом?

Будучи самим частим учасником декількох проектів з відкритим кодом, я відчуваю, що я маю рацію скинути кілька грязей, де це заслуговує.

Нічого з наступного не стосується зіркових проектів OSS, таких як Linux, Firefox, MySQL або PostgreSQL. Це нетипово, оскільки вони підтримуються компаніями та / або досвідченими кодерами.

У будь-якому разі, з причин, за якими клієнт заплатить за програмне забезпечення:

OSS схильний до повзучості / Клієнти платять за більш просте програмне забезпечення

Усі учасники OSS мають свою особливість домашніх тварин. Згодом вони знайдуть свій шлях до кодової бази. Потрібно надзвичайно досвідчене, тверде і харизматичне керівництво, щоб уникнути проблеми, і, як і будь-який інший хлопець, багатьом основним розробникам ОСС не вистачає хоча б однієї з цих рис.

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

Кінцеві користувачі хочуть простих інструментів. Їм потрібно робити свою роботу без кривої навчання чи суєти. Вони хочуть, щоб їх інструменти прийняли правильні рішення для них; не варіанти. Якщо ви зможете доставити щось простіше, ніж автономна реалізація ОС, ви отримаєте платні клієнти.

OSS, як правило, низької якості / Клієнти платять за більш високу якість

Немає нічого поганого в тому, щоб навчитися кодувати, роблячи внесок у ОС, зауважте.

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

Наприклад, WordPress був роздвоєний студентом від B2 (сам його розробив студент). Пізніше декілька версій і незрозуміла кількість клейкої стрічки, вона виконує роботу. Але під кришкою - це помилка клопів з невеликим, якщо якісь, контролем якості. (Востаннє я спробував, він не вдало пройшов власний тестовий набір.)

Клієнти платитимуть за доглянуте та добре перевірене програмне забезпечення. Вони майже всі спробують безкоштовні речі, зауважте, і багато хто навіть буде терпіти помилки до певного моменту. Але якщо від цього залежатиме їх дохід, вони зрештою шукатимуть програмне забезпечення вищої якості та платять за нього.

OSS, як правило, має занадто короткий цикл розробки / Клієнти платять, щоб уникнути зайвих проблем

Це властиво процесу розвитку. Особливості домашніх тварин, які потрапляють у базу коду, повинні бути випущені за розумну часову шкалу. Якщо їх немає, ризик полягає в тому, що проект OSS втратить частину своїх учасників.

Однак у довгостроковій перспективі компанії віддають перевагу тривалим циклам випуску; чим довше, тим краще. Це менше планування та менше роботи для ІТ-відділу. Не важливо, якщо кінцеві користувачі оновлюють свій браузер кожні три місяці або близько того. Це зовсім інша історія, якщо ви оновлюєте критичні для місії додатки.

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

На відміну від WordPress, який час від часу обговорює тримісячний цикл випуску, незважаючи на занадто короткий цикл. (Їх бета-версія - це, для всіх намірів і цілей, версія xy0 кожного випуску.)

Маючи декількох клієнтів, які використовують WordPress, я можу запевнити вас, що вони більш ніж раді, що я доглядаю за ними, щоб їх сайти не підірвалися в обличчя під час оновлення. Клієнти заплатять за те, що не потрібно турбуватися про подібні клопоти.

OSS прагне безтурботно приймати відкриті стандарти / Клієнтам просто потрібні речі для роботи

Тут викладений відеотег HTML5.

Справа Mozilla щодо відхилення h.264 полягає в тому, що вони хочуть кодек з відкритим кодом. І в цьому сенсі вони абсолютно коректні: останнє, чого вони хочуть, - це потрапити до списку хітів патентних тролів; тому вони підштовхують до Огг.

Справа Apple щодо використання h.264, навпаки, практична: вона вже широко підтримується, і для неї є прискорене обладнання (тим самим дозволяючи продовжити термін служби акумулятора iPhone); у Огга такого немає.

Мільйони пристроїв iOS, проданих пізніше, сайти, стурбовані доставкою відео цим користувачам iOS, підтримують html5 / h.264. По-іншому, клієнти говорили: вони не переймаються відкритими форматами.

Єдиною компанією, яка задоволена результатами цієї отруйної битви за кодеки, є Adobe: Користувачам Firefox де-факто, як і раніше, потрібен Flash, якщо вони захочуть відтворювати відео. Якщо основний сайт перейде на відео, призначені лише для html5 / h.264, кодер там швидко знайде розширення або плагін для перетворення потрібних відеотегів у флеш-відеоплеєри. (Можливо, це вже існує.) В ім'я підтримки відкритих стандартів (яких, до речі, немає).

Ніхто ніколи не звільнявся за вибір IBM

Це старий жарт у галузі, але в цьому є правда: коли ви володієте ІТ-бюджетом, вас не звільнять за вибір того, що однолітки вважають найкращим у породі.

Великі корпоративні покупці, які не хочуть ризикувати, продовжуватимуть купувати настільні комп'ютери на базі Microsoft, Office, SAP і що ні; навіть якщо є альтернативи з відкритим кодом. Наче подібне лайно трапляється .

Коли OSS пробивається у великі корпоративні середовища, зазвичай це не тому, що CTO побачив світло і вирішив використати інструменти без витрат; скоріше, він спрямовується третьою стороною, яка пропонує (дорогі) послуги зверху.


3
"OSS, як правило, має занадто короткий цикл розробки", але якщо ви використовуєте OSS, вам не потрібно йти в ногу з останньою розробкою, у вас є вибір використовувати стару версію нескінченно та оновити лише тоді, коли це має сенс для вашого бізнесу. . З програмним забезпеченням із закритим джерелом, залежно від терміну ліцензування, це іноді складніше. Крім того, якщо програмне забезпечення з відкритим кодом перестає підтримувати стару версію, у вас є вибір розблокувати стару версію та самостійно виправити помилки / проблеми безпеки. З закритим джерелом у вас немає такого вибору, тому ви або оновите або невдало залишитеся з помилкою.
Лежать Раян

5
"Ніхто ніколи не звільнявся за вибір IBM" Але що робити, якщо найкращим програмним забезпеченням цієї галузі є відкритий код, скажімо, Apache? або, можливо, через кілька років, якщо Android має перемогти Nokia?
Лежати Райан

2
Ви не маєте великого вибору, щоб обирати старі версії на невизначений термін, коли у них є безпечні отвори. Спробуйте встановити WP 2.3 на веб-сервер і подивіться, як це, перш ніж бот знайде його і зламає. І ні, клейка стрічка (тобто виправлення безпеки назад) не є розумним варіантом для Джо Середнього. За допомогою OSS ви змушені оновитись або назавжди зациклюватися на помилках.
Дені де Бернарді

2
@Denis: Joe Average теоретично міг найняти розробника Джека для підтримки необхідних виправлень безпеки; це може бути не найкращим бізнес-рішенням, але він може (і це важливо). З закритим джерелом, коли підтримка припиняється, програма назавжди заморожена (можна стверджувати, що це іноді краще, оскільки у вас просто простий вибір оновлення, тому вам не потрібно давати шансу зловмиснику використовувати вашу програму, поки ви 'замислюємось про те, чи потрібно модернізувати чи ні)
Lie Ryan

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

19

Я думаю, що суть аргументу в тому, що "комерційний продукт вже зробив 100% того, що потрібно люди", - це те, де аргумент розпадається. Жоден продукт не може претендувати на те, щоб робити 100% того, що потрібно людям, і, звичайно, не абсолютно ефективним (з точки зору ефективності оператора), простим у користуванні та загальновизнаним "найкращим" способом.

Якщо таке було можливо, то, звичайно, єдиною рештою, на яку можна змагатись, є ціна. Але оскільки об'єктивне "найкраще" та загально "найефективніше" застосування неможливо, завжди буде більше речей, ніж просто ціна.


Дякую, що трохи розірвав міхур. Це має сенс. :-)
Річард

8

У цій статті є кілька хороших моментів, але, знову ж таки, реальний світ здається безліччю прикладів, коли компанії, що працюють з близьким кодом, роблять просто чудово. Ось лише кілька

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

Проблема з відкритим кодом полягає в тому, що він відкритий. Якщо у вас є цей код, випускаєте продукт A. У вашій конкуренції є той самий код. Таким чином, ви витрачаєте весь цей час на написання програмного забезпечення, його частина може бути зроблена іншими учасниками, але якщо ви керуєте компанією, ви витрачаєте ресурси, і все-таки кожен може прийти і почати продавати саме те, що ви витратили роки розвивається. Таким чином, найбільшою загрозою для компанії з відкритим кодом може бути необхідна не компанія з близьким кодом, а інші 5 компаній з відкритим кодом.

З іншого боку, якщо я розробляю програмне забезпечення із закритим кодом, так, ви можете скопіювати мої ідеї, але я все-таки можу бути на багато років попереду вас у розробці програмного забезпечення, і до моменту виходу на ринок я вже міг би володіти 90% його.

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

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


1
Більшість текстових редакторів та VS є на окремих ринках.
альтернатива

@ alternative Більшість IDE та VS знаходяться на окремих ринках.
Енді,

6

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

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

Я не впевнений, чому це так. Я можу сказати, однак, що я більше ніж готовий платити за програмне забезпечення, яке виконує роботу з мінімальними зусиллями з мого боку. Це все -таки програмне забезпечення .

Зробити це простіше, ніж конкуренція з відкритим кодом, і люди будуть платити.


різні анекдоти, у мене зазвичай менше проблем з навчанням програмним забезпеченням з відкритим кодом, оскільки вони часто мають більше інструкцій / документації та більше дискусійних форумів, які можна отримати від Google. Хоча не все програмне забезпечення з відкритим кодом має чудову документацію або форуми для обговорень післяпродажного обслуговування, з тими, з якими, як правило, працювати легше, ніж із альтернативою із закритим кодом. Наприклад, я виявив, що Python набагато простіше вивчити, ніж Visual Basic .NET. Я знайшов більше порад та підказок щодо налаштування / виправлення системи Linux, ніж раніше, коли я використовував Windows.
Лежати Райан

4

Можливість використання та функції - одне, що має комерційний проект із закритим кодом, що більшість проектів з відкритим кодом не має, це можливість контролювати чітке бачення того, яким продуктом має бути і робити.

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


Щоб відповісти на ваше запитання - Ціла купа мак-фанбоїв! Я жодного разу не бачив у цьому редакторі чогось, що справді мене вразило.
альтернатива

3

Орієнтуючись на конкретні проблеми клієнта. Багато разів я бачив, як організації витрачають тисячі доларів на "ту єдину особливість".

Як продукт з відкритим кодом, вони повинні зосередитись на масі (на жаль, маси не купують ці 10K + програмне забезпечення), як близький джерело для організації прибутку, якщо ви зможете задовольнити потреби своїх ключових / критичних клієнтів.

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

(це може бути трохи орієнтовано на корпоративного клієнта)


1

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

Якщо ваш клієнт потребує певної функції, у вас є фінансовий потенціал, щоб доставити його вчасно. Ви маєте можливість надати підтримку 24x7 (і за неї платити), гарантовано вирішувати критичні проблеми рівня 0, доступ до технології нового покоління набагато раніше, ніж спільнота з відкритим кодом, якщо ви працюєте з OEM-виробниками.

Використовуйте їх на вашу користь. Нехай безкоштовний товар теж буде на ринку, не будьте ворожими. Якщо що, це розширює ринок - в якийсь момент користувачі безкоштовного товару можуть захотіти спробувати дзвіночки вашого комерційного рішення.


1

Для простоти давайте зведемо фактори успіху програмного забезпечення на три "інвестиції":

(Тут "інвестиція" - це збірний термін для діяльності, за яку вам зараз доведеться платити, щоб пізніше отримувати доходи.)

  • Продажі та маркетинг
  • розробка (включає вихідний код, дизайн продукту / інтерфейс користувача, документацію та навчальні матеріали. Кількість, помножена на якість. Будь-який робочий продукт, що випускається тут, може бути реплікуваний з низькою вартістю необмеженій кількості користувачів)
  • послуги (досвід у галузі програмного забезпечення та домену, а також можливість забезпечити покращення доданої вартості на основі клієнта)

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

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


Тепер повернемось до питання ОП: чи має компанія із закритим кодом стратегію виживання?

Стаття, цитувана ОП, здається, обмежує себе, оскільки вона враховує лише дві крайності:

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

Як щодо середніх підстав?

  • Кілька програмних компаній підписують перехресні ліцензійні угоди на поділ частини вихідного коду та / або API? (В якій одна із партій орієнтована на послуги.)
  • Компанії, які добре використовують ліцензовані компоненти BSD з відкритим кодом або бібліотеки (і роблять натуральні внески), не відкриваючи вихідний код основного продукту?
  • Компанії, які надають вихідний код незавершеного програмного забезпечення за допомогою обмеженого у часі домовленості про попередній перегляд спільноти?
  • "Доступний джерело": компанії, які надають вихідний код платним клієнтам?

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


Однак є застереження: якщо програмне забезпечення буде безкоштовним, чи вибиратимуть його клієнти за допомогою альтернативних варіантів, навіть якщо програмне забезпечення погано впливає на деякі показники?

  • продаж та маркетинг: чи можете ви просувати продукт майже без витрат за допомогою вірусного маркетингу?
  • розвиток: чи може проект з відкритим кодом отримати більшу частину свого дизайну / розробки / документації від неоплачених добровольців? Чи може компанія отримати вигоду від такого проекту?
  • послуги: чи може проект програмного забезпечення зробити революційну область свого програмного домену, щоб зробити його дуже простим, щоб кожен міг стати миттєвим експертом, знизивши вхідний бар'єр до нуля?

1

Проект з відкритим кодом переслідує комерційний проект з точки зору особливостей. Це залишає своєрідний арбітраж для комерційної компанії конкурувати за функціями. Їм доводиться постійно змагатись із впровадженням функцій, щоб зберегти перевагу перед компанією з відкритим кодом. Це дорого, але може працювати.

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

Корпорація може спробувати встановити блокування постачальників, але це лише уповільнює втрати; це не приносить вам жодних клієнтів.

Це залишає два основні способи зберегти частку ринку: підтримка та використання недовіри менеджерів до програмного забезпечення з відкритим кодом. На жаль, останній доставить вас далеко. Підтримка продажу буде працювати, хоча навіть коли проект з відкритим кодом набереться достатньо, щоб отримати компанію, яка продає підтримку, комерційне рішення матиме перевагу, будучи діючим та мати більший досвід, а також від враження, що вони є більш знайомий з їх продуктом.

У довгостроковій перспективі ви, швидше за все, будете накручені, але це може перетворити "короткий термін" у "передбачуване майбутнє".


Я погоджуюсь з тобою. Я дійсно думаю, що в перспективі немає зупинки з відкритим кодом. Це так само, як музика та кіноіндустрія ... ви можете зупинити маси, і що вимагають маси, отримують маси. Що стосується відкритого та закритого коду, відкритий код (я думаю, що в перспективі) надасть функції з кращою ціною та підтримкою.
Річард

1

Ще одне, про що ніхто не згадував, - це документація. Багатьом програмам насправді не потрібно багато для використання (Firefox, Openoffice), але якщо ви пишете бібліотеку, якийсь сервер, мову програмування або просто дуже складну програму, документація може зробити вашу.

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

Це не обов'язково з відкритим кодом проти закритого джерела - Досить багато всього погано зафіксовано. Можливо, ваш конкурент є в тому, що 1% проектів, які добре документують речі, але навряд чи;)


1

Простіше кажучи, фокус полягає в тому, щоб продовжувати визначати 100%. FOSS просто не має однакового масштабу та кількості комерційного проекту, і є обмеження щодо того, наскільки тісно ви можете конкурувати з існуючим продуктом. Компанія із закритим кодом використовує гачки інтерфейсу, так що використання конкуруючого продукту буде неможливим через різні, наприклад, комбінації клавіш. Крім того, вони продовжують додавати основні функції, про які FOSS-конкурент просто ніколи не міг розглянути. Наприклад, розглянемо Visual Studio. Це був просто C ++ IDE, але потім вони почали поєднувати абсолютно нові мови та рамки, як-от .NET. Або Visual Studio 2010, який пакує комерційну оцінку (як, наприклад, Intel продають еквівалентну окрему) бібліотеку для нарізки для C ++. FOSS просто не може йти в ногу з таким розвитком, а часто і надійністю.


0

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

Для багатьох великих традиційних компаній це зводиться до трьох речей:

  • постачальник, з яким вони можуть укласти обов'язковий контракт на (можливості та надійність)
  • постачальник, за яким він може за контрактом застосувати конкретну угоду про рівень обслуговування (швидкість якості підтримки)
  • огляди gartner (це сучасний еквівалент "ніхто не звільняється за вибір IBM)

Усі троє бездумно стежать і не мають особливої ​​ваги. Проблеми з можливістю завжди перепродаються, угоди про угоду завжди мають виправдання, і gartner лише опитує тих людей, які слухають gartner, але коли ви середнє керівництво у корпусі, який має цілу безліч керівних кадрів із середнього та середнього рівня, які потрапляють у проблеми з верхнім керівництвом коли, нарешті, керівництво вислуховує, що було прийнято неминуче рішення, яке коштувало великої купи грошей, вам потрібна документація від третьої сторони, яка підтримує вашу посаду, якщо ви хочете зберегти свою роботу. Навіть якщо ви добре знаєте, що з технічної точки зору ви збиваєте великі купи грошей у туалет, не варто ризикувати, намагаючись зробити правильно.

Скільки випадків поганого використання SAP або SharePoint ви бачили в галузі? Скільки з них було б краще, якби вони були зроблені на чомусь іншому, що було б краще, але не було великим ім'ям галузі?

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


-2

Як сказав SnOrfus, продаємо функції, які ми робимо.

Наприклад: ми розробляємо плагіни з деякими загальними особливостями і робимо їх безкоштовними для завантаження на сайті Wordpress. При цьому у нас є плагін платної версії, який має профі функції.

Це допомагає вам представити свій продукт масовим людям, тобто силі з відкритим кодом та людьми.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.