Комерсиален софтуер или open source решения?
Отношенията между потребителите на комерсиален софтуер и open source (OS) са като между заклетите фенове на двата най-големи футболни отбора у нас. Всички са обзети от фанатична вярност към любимия отбор и от неизкоренима омраза към врага. При производителите нещата стоят малко по-разумно. Една голяма част от тях търсят успешни бизнес модели както в комерсиалните, така и в OS продуктите. И може би това в най-голяма степен важи за малките производители, които на запад вече си имат собствен термин – micro ISV (mISV).
Аргументите на Патрик
Един такъв производител е Patrick McKenzie, разработващ софтуер за печатане на карти за Bingo в помощ на учителите. Той е публикувал една интересна статия, в която изтъква предимствата на комерсиалния подход пред open source решенията. В нея прилага интересни аргументи, върху които си струва да се замисли човек.
За да парира всякакви недоброжелателни критики, Патрик категорично декларира почитанията си към OS идеологията, както и факта, че сам той е активен потребител и разработчик на open source продукти. Но, когато е търсил решение какъв подход да избере за своя продукт, Bingo Card Creator, той е търсел аргументи, които да противопостави на онези малки проекти, които “вършат полезни неща за хората, и за които никога не сте чували”. Не забравяйте, казва той,
Не всички open source продукти са Firefox и също така не всички комерсиални продукти са Microsoft Office.
Повечето аргументи на Патрик се базират на отношението към потребителя и в много от тях съм склонен да приема неговата позиция. По-надолу ви предлагам няколко примера.
Маркетинг
Хората, казва Патрик, имат проблеми, а софтуерът може да ги реши. Проблемът на OS продуктите, е, че те се фокусират върху софтуера, а не върху проблема на потребителя.
Вземете който и да е OSS сайт. Ще видите толкова много приказки за софтуера, за имплементацията му, за сорс кода му, как вие бихте могли да допринесете за неговото развитие и пр. Почти никъде няма да видите нещо за предметната област.
Тук съм склонен да се съглася с него. По мои наблюдения повечето OS продукти се правят предимно от програмисти и просто нямат достатъчно специалисти в предметната област. В този смисъл, това е нормално поведение на всеки програмист – да се интересува само от изработването на продукта, а не и от неговото практическо приложение при клиента. Такива проблеми би имало и в една комерсиално работеща компания, ако те се състои само от програмисти. Разликата е, че във фирмите, разработващи комерсиален софтуер, има и маркетинг специалисти (вкл. и бизнес анализатори), докато в повечето open source проекти няма.
Дизайн
Ако повечето програмисти обичат да пишат код заради самото удоволствие и участват в OS проекти доброволно, то добрите дизайнери не изповядват същите алтруистични възгледи, твърди Патрик. С други думи, ако искаш твоят продукт да изглежда добре, трябва да платиш на дизайнер. Но понеже повечето OS проекти нямат бюджет, те не могат да си позволят услугите на дизайнер и са принудени да скалъпят сами каквото могат. Оттук и скапания дизайн на повечето OS продукти. А външния вид и удобството за работа са едни от най-важните фактори за харесването на един софтуерен продукт.
Може би наистина повечето OS проекти разчитат на доброволно участие. Аз лично не съм правил такова проучване, но като знам, че само в SourceForge има над 170 хиляди проекта, дори финансовата подкрепа на някои компании-гиганти като Sun и IBM е просто капка в морето на фона на общия брой проекти. В крайна сметка, моят практически опит също показва, че като резултат, на OS софтуера му липсва както usability, така и естетически вид.
Опита на потребителя
В този раздел, авторът има предвид технологичният праг, който се поставя пред потребителя при сваляне и инсталиране на програмния продукт. Той дава пример с конкретни сайтове, където подходът на производителя е неразбираем и объркващ за обикновения потребител. Такива примери всеки може да намери. Дори и аз, който имам дългогодишен опит като софтуерен разработчик се ядосвам, когато някои OS производители ме карат да мина през няколко страници от сайта им преди да успея да сваля всички нужни компоненти, а след това се налага да мина и през сложна инсталационна процедура, включваща отваряне на определени файлове и записване на специални параметри. А когато се стигне и до прекомпилиране, направо захвърлям този продукт и започвам да търся друг.
Обикновения човек няма нито знанията на един програмист, нито времето и търпението да извършва сложни операции. Той със сигурност ще избере онзи продукт, който му предлага лесна, разбираема и бърза процедура по инсталиране и стартиране на софтуера. А това комерсиалните продукти го правят по-успешно.
Документация и поддръжка
По отношение на документацията, Патрик прилага съкрушителния аргумент с програмисткия жаргон и отново е прав. Повечето OS продукти имат много бедна и лошо написана потребителска документация. И тя е повече насочена към програмисти, отколкото към обикновените потребители. Поради това е изпъстрена с неразбираеми за простия човек съкращения и изрази от технологичния жаргон, които правят текста напълно неразбираем.
Що се отнася до поддръжката, има доста фирми, които са приели тази дейност като основен бизнес носител и предлагат безплатен и OS софтуер срещу платени внедряване и поддръжка. Въпреки това, процентът на фирмите, предлагащи поддръжка на OS софтуер все още е значително по-малък от тези, които продават комерсиални продукти.
Тук целият бизнес модел е, общо взето, обърнат. Комерсиалните фирми искат пари за продукта, а предлагат безплатна поддръжка (поне в рамките на гаранционния период), а OS фирмите не вземат пари са самия софтуер, но пък услугите им по внедряване и поддръжка са платени. Гледайки отстрани, ми се струва, че за момента първият подход е по-печеливш.
Дискусия
Тук му е мястото да ви приканя към дискусия с вашите коментари по темата и по изложените аргументи. Съзнавам, че самата тема е взривоопасна и че за някои привърженици на отворения сорс най-важните неща са далаверката (щото софтуерът е безплатен) и омразата към Майкрософт. Призовавам ви към конструктивен диалог и предупреждавам, че всякакви фанатични и обидни коментари ще бъдат изтривани без колебание.
Ясно е, че като потребители, всички използваме безплатен и open source софтуер. Цената има значение, но значение имат и други фактори. Тук за мен е по-интересно да видим гледната точка на малкия производител на софтуер и неговия бизнес модел. Аз самият доста съм разсъждавал над двата варианта, но все още не мога да открия успешния бизнес модел на отворения и безплатен софтуер. Ще се радвам да видя вашите смислени и аргументирани коментари.
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.
При софтуера с отворен код има конкуренция между тези, които правят поддръжката. При собственическия софтуер може да ти помогне само производителят, ако благоволи.
Отвореният код обикновено е по-добре изтестван, защото много очи го гледат.
Производителите на софтуер със затворен код се изкушават да държат потребителя в плен—лицензи, които ни ограничават и криминализират, DRM, vendor lock-in.
Не е само парите. И не е само възможността да прочетеш кода. Свободата да решаваш сам софтуерните си проблеми (или да платиш на някого да ти ги реши) и да публикуваш съответните промени също е важна.
Цената е лош външен вид и документация на технически жаргон, но в повечето случаи си струва.
ngn, коментарът ти показва, че си само потребител и при това програмист. Вмъкнал си и доста фенски клишета, но предвид добрия тон, го пускам, за да го коментирам пък аз в подробности 🙂
Независимо, че повече очи гледат, не съм съгласен, че отвореният код е по-добре тестван, защото екипът се състои само от програмисти, а те (1) не обичат да тестват и (2) нямат нужният опит и квалификация.
“Производителите на софтуер със затворен код се изкушават да държат потребителя в плен” – хубаво изречение за роман, но не и за бизнес-аргументация. Говорим за малки производители, забрави за момент за Майкрософт 🙂
“Свободата да решаваш сам софтуерните си проблеми (или да платиш на някого да ти ги реши)” – точно тук си вкарваш автогол, защото комерсиалните фирми точно за това съществуват – да ми решат проблемите срещу заплащане.
Ясно е, че значителна част от програмистите ще отговорят в полза на отворения код, защото обичат да се ровят в кода и могат сами да си дописват някои неща. Предполагам, че това е и твоята логика. Точно затова аз наблягам на гледната точка на производителя и на редовия потребител – как фирмата би могла да създаде успешен бизнес модел, така че максимално да задоволи потребностите на обикновения потребител, който няма знания по програмиране (и не му и трябват, защото работата му е друга).
Без да съм програмист, съм съгласна с ngn. И при малките производители го има проблема с това, че единствено те могат да ти решат евентуални проблеми със софтуера. При тях проблемът е дори още по-голям, защото за един малък производител е много по-лесно да фалира, отколкото за Microsoft, а ако разчиташ на неговия продукт, какво правиш тогава?
Отново подчертавам, че не съм програмист, по-скоро съм нещо, което в някои публикации наричат power user – разбирам това-онова, но не достатъчно, за да се ровя в кода или да пиша нов. Преди да пробвам open-source продукти, се страхувах, че няма да ми бъдат удобни или че няма да свикна с тях, но поради аргументите, които и ngn е посочил, реших все пак да пробвам. За ежедневна употреба наистина ми допадат повече и това няма нищо общо с “далаверката”. 😉
Аз съм и оставам фен на затворения код. Използвам доста open source библиотеки и приложения. Но въпреки тов софтуер-ът решаващ реални бизнес проблеми обикновено не е OS.
Относно тестването – стига да има процес и екип нещата са много по-добре при комерсиалния софтуер.
Дуплика, ако позволиш 🙂
“програмисти […] не обичат да тестват”
Идеята е, че повечето тестване се прави от потребителите докато ползват софтуера, защото (поне в началото) го получават недоизтестван. Да, това може да е недостатък.
“държат потребителя в плен”
“Говорим за малки производители”
Малките също могат. Един краен пример: http://blog.fireeye.com/research/2009/03/a-new-method-to-monetize-scareware.html
“комерсиалните фирми точно за това съществуват – да ми решат проблемите срещу заплащане”
Свободен софтуер с комерсиална поддръжка е ок. Това са различни аспекти на софтуера. Разликата е, че ако нямаш кода, имаш само един избор за това кой да ти помогне.
Тук май се разрази дискусия технически лица vs. обикновени потребители (последните, защитавани от Майк, макар и той да е techy тип).
Относно публикацията…
Години наред мигрирам почти изцяло на решения с отворен код, като се старая да пиша и с отворени библиотеки и frameworks. Няма непредубеден програмист, който може да отрече предимствата на това да се пише с отворени библиотеки, вместо да работиш с черна кутия.
@Майк, IBM и Sun не могат да участват във всички проекти, но, първо, те не са единствените спонсори, второ, има и доста по-малки инвеститори (както и много donations) и, трето, както в sourceforge има малки проекти на доброволни начала, така се пишат и доста затворени проекти от 1-2 човека или съвсем малки и бедни фирмички. От големите, нима Oracle е малчо в сравнение с Microsoft? Vendor-ът налива доста пари в софтуера с отворен код. Както и Google (с доста различни инициативи, състезания, спонсорства). Ако Microsoft предлагат затворена операционна система (и са огромен производител, който не е редно да споменаваме), то голяма част от Linux дистрибуциите са поддържани от лидери като RedHat.
Всъщност, докато пишех публикацията, ми хрумна идеята, че комерсиалният и отвореният софтуер са близки по качество и ефективност, като променливите са инвестирани средства, големина на екипа и други величини от съществено значение.
Както и да е, не е това идеята на дискусията, но е важно да се знае, че ако говорим за open-source решения изобщо, то големият пазар има ако не повече, то поне равни сили с най-популярния производител на продукти.
Маркетинг точката, която си описал, разкрива само как комерсиалните продукти са по-добре представени пред клиента от некомерсиалните. Или че фирмите с комерс софтуер имат повече ресурс/възможности да си наемат маркетьори, PR-и и sales мениджъри. Това прави ли автоматично продуктите с отворен код по-лоши? 🙂
От потребителска гледна точка има pro’s and con’s. Наистина, рекламата на платените продукти е много по-голяма (по мое мнение и ужасно дразнеща). Това обаче ги прави по-популярни и хората без много опит се засилват първо там. Потребителите с повече опит пък гледат форуми и usergroup-и, в които се задават въпроси и се пускат коментари от ползвателите на софтуера, които са често от първия тип. И така комерсиалният софтуер става по-използваем сякаш. За функционалността е трудно да се говори – в някои продукти са включени професионални екипи с огромен опит, правят се таргет групи за тестване, огромни testing/QA отдели и прочие. Това в комерсиална среда. Може би това е причината да не съм намерил подходящ заместител на Photoshop/Cubase за обработка на изображения и звукозапис. Gimp може да е решение за доста неща, но не е Фотошоп. От друга страна, има продукти с отворен код, които нямат добра алтернатива под Windows. Доста отворени продукти разчитат и на разрастване чрез плъгини, разширения и прочие. Ако са затворени, то има един единствен създател на такива разширения. В противен случай броят производители (и респективно подпродукти) нараства неимоверно.
Знаеш ли, написал си, че не ти харесва дизайна на OS продуктите. Мнението ми е точно обратното – много ми допада семплият и лек дизайн, който залага на ползваемост, а не изглежда като детска градина или ракетен симулатор. Вероятно е въпрос на лично мнение, но, откакто навърших 16, съм фен на изчистения дизайн и по-малкото шарении.
Документация и support казваш… От една страна, пренебрежимо малките проекти с отворен код нямат нормална документация. Но това важи и за комерсиалните проекти – а и никога не съм търсил документация на продукт, който прави 3 неща ‘на кръст’, както се казва. Съществува много важна особеност обаче – в средно големи проекти участват както dedicated програмисти, така и доброволци – тогава документацията е жизнено важна, в противен случай няма как да се включи 3rd party човек!
По поддръжката, в момента се сещам за няколко огромни корпоративни затворени продукта, които изискват ужасяващи абонаментни такси за поддръжка, но не искам да отварям темата. ngn е казал по-важните неща отгоре: за различните support екипи (избор 1) и за възможността да си оправиш проблемите сам (избор 2).
Тъй като всеки собственик, мениджър или дори старши разработчик във фирма си задава въпроса има ли смисъл да пиша отворен код, мога да споделя малък опит. Пускали сме 2 неща в community – 1 малък проект и 1 полезно разширение/плъгин, което ползвахме за една платформа. Получихме добра реклама и добри отзиви и за двете неща, както и разширена функционалност от други хора, които ползват софтуера. Т.е. изиграхме ролята на производител и същевременно ползваме по-добра версия на това, което представихме като първоначален вариант, надградена от доброволци. Не сме ползвали donation модул, макар и мои познати да се изхранват от такива неща.
Марио, хубав коментар, макар и доста емоционален 🙂
Напълно си прав колко е важна документацията, но това не означава, че (1) другите програмисти го осъзнават това и (2) че документациите в OS проектите стават за четене.
Същото се отнася и за дизайна. Не съм казал, че интерфейсът трябва да е претрупан. Но когато става въпрос за използваемост (usability), интерфейсите на OS продуктите са далеч зад комерсиалните по простата причина, че няма такива специалисти в техните екипи, а това е особено важен фактор за избора на продукт от страна на клиента.
Тук идеята беше да насочим фокуса не върху това колко е гот да програмираш в OS проект, защото на практика в самото програмиране няма разлика, а къде е бизнес модела. Авторът на статията, която цитирам, отстоява позицията, че като производител на комерсиален софтуер има възможността да предложи по-добър продукт и да спечели повече клиенти, които да са съгласни да платят цената, която той иска, при положение, че продуктът решава техните проблеми. С други думи, OS моделът, въпреки че предлага безплатни продукти, което дава възможност за голяма клиентска база, не носи съществена полза за производителя.
Ето, ти също казваш, че сте правили някои отворени проекти, но какво сте спечелили от това? Каква е била бизнес ползата за фирмата? Това е интересния въпрос, към който се опитвам да ви насоча.
Майк, това (за ползата) се опитах да обясня в предния коментар – нашият продукт бе подобрен от доброволци, които го ползват. Същевременно се появи и на други места (с линк към нас), от което спечелихме популярност и повече заинтересовани клиенти. Играехме ролята и на консултанти.
Та, поне при нас:
1. Подобрен продукт
2. Реклама (+нови поръчки, респективно)
3. Клиенти за консултантска дейност
В някои случаи това е достатъчно. Разбира се, зависи от сферата – бизнес софтуер, eRP платформи, може да е уеб програмиране, може да е телекомуникационно обслужване… Може да е и някакъв стрийминг – има прекалено много области и в някои от тях е полезно да пишеш open-source. Да кажем ICQ – не е отворен протокол, но е ‘кракнат’ и съществуват множество алтернативи на клиента. Това е в противовес на политиката на компанията да се ползва техния клиент, но същевременно протоколът им се ползва от многократно повече потребители…
Отворения код има потенциял да завземе пазара, но не е достатъчно организиран и не са много хората които биха написали нещо без пари, не са много дизайнерите, които за без пари да обрисуват софтуера. Иначе всичко е супер. Ако организацията бъде оправена, всичко се обидини в едно и започне активно да се рекламира дори да трябва да се плати известна сума после ще има възнаграждение. Отворен код и свободен софтуер не означава безплатно!!!
Според мен “свободен” (на английски “free”) означава точно “безплатен”, когато говорим за софтуер 🙂
Според доста преводачи ‘безплатен’ е ‘free’, а ‘свободен’ е ‘open-source’. Виждал съм на доста места тези интерпретации и аз също ги ползвам. Впрочем, и в БГУикипедия е дадено такова обяснение (не коментираме достоверността на източника).
Колкото до разликата между free и open-source софт, едва ли има нужда да коментираме 🙂
Не съм съвсем съгласен с цитираният автор. Един основен проблем на решенията със затворен код е жизненият им цикъл, който може да бъде прекъснат или скъсен неочаквано поради загуба на финансова стабилност на вендора. Пресен пример е поглъщането на SUN от Oracle и последващата нужда от миграция на част от клиентите към решения на Oracle или конкурентни на тях продукти. Поради голямото припокриване на продукти, част от инициативите на SUN са обречени на бавна смърт в следващите няколко години.Конретно за SUN множество техни клиенти са мигрирали точно от Oracle или са избрали тях за да нямат вземане даване с Oracle. В крайна сметка се “натрисат” отново на тях. Един от най-големите клиенти на JCAPS например е Карефур- фирма с над 2000 филиала по цял свят и безброй трансакции за ден базирани на SAP системи. JCAPS, като такъв е продукт който няма бъдеще под шапката на ORACLE. Оставям на по-разбиращите да преценят за какви разходи става въпрос при една такава миграция не само като лицензи но и като дивелъпмънт и диплоймънт и колко сериозен е импактът в този случай.
Отностно дизайнът и юзабилитито на оупън сорс продуктите също не съм съвсем съгласен. Тук е може би правилният момент да вметна, че и от двете страни на барикадата имаме примери за безобразен дизайн и кошмарно юзабилити.Вземете за пример SAP Business Suite. Ужасен дизайн, юзабилити…. ниенте. А са водещи на пазара. Но все пак става въпрос за ентърпрайз софтуер, при който има доста по важни параметри от това колко мъчително би било да се работи с тези решения. Все пак компаниите производителки трябва да печелят нещо и от курсовете за обучение нали ;).
Развитието на даден продукт зависи от конкретната политика на проекта и ръководителите му. Без значение дали е оупън сорс или не. При оупън сорс продуктите съвсем не се търси само фийдбек от дивелъпъри и продуктът не се тества само от такива. Може би доста хора остават с впечатлението, че двигателят на промените е дивелъпърът но не е така. Дивелъпърът от страна на интегратора в крайна сметка работи по задание изготвено от клиента с или без помощта на консултанти. При липса на дадена функционалност дивелъпъра има възможност да я постне като фючър рикуест и тя да бъде обсъдена от къмюнитито или да я разработи сам имайки достъп до кода. В следствие на това компанията, която интегрира решението може да реши да сподели кода на новата функционалност в проекта.
Release Cycles при оупън сорс продуктите по принцип са доста по начесто и по гъвкави отколкото при proprietary решенията, в резултат на което на фирмите не им се налага да чакат дълго докато нужна нова функционалност се появи.
В крайна сметка, когато се сравняват open source и closed source решения генерализацията, т.е. слагането под обща шапка на всички OS и CS случаи е подход, който може да доведе до неправилни управленски решения и грешни изводи за крайните потребители. Всяко сравнение трябва да се прави за конкретен Use Case и за конкретни продукти.
Вероятно мога да продължа да пиша с часове по темата но горният абзац обобщава накратко мнението ми по въпроса.