Отностно дизайнът и юзабилитито на оупън сорс продуктите също не съм съвсем съгласен. Тук е може би правилният момент да вметна, че и от двете страни на барикадата имаме примери за безобразен дизайн и кошмарно юзабилити.Вземете за пример SAP Business Suite. Ужасен дизайн, юзабилити…. ниенте. А са водещи на пазара. Но все пак става въпрос за ентърпрайз софтуер, при който има доста по важни параметри от това колко мъчително би било да се работи с тези решения. Все пак компаниите производителки трябва да печелят нещо и от курсовете за обучение нали .

Развитието на даден продукт зависи от конкретната политика на проекта и ръководителите му. Без значение дали е оупън сорс или не. При оупън сорс продуктите съвсем не се търси само фийдбек от дивелъпъри и продуктът не се тества само от такива. Може би доста хора остават с впечатлението, че двигателят на промените е дивелъпърът но не е така. Дивелъпърът от страна на интегратора в крайна сметка работи по задание изготвено от клиента с или без помощта на консултанти. При липса на дадена функционалност дивелъпъра има възможност да я постне като фючър рикуест и тя да бъде обсъдена от къмюнитито или да я разработи сам имайки достъп до кода. В следствие на това компанията, която интегрира решението може да реши да сподели кода на новата функционалност в проекта.

Release Cycles при оупън сорс продуктите по принцип са доста по начесто и по гъвкави отколкото при proprietary решенията, в резултат на което на фирмите не им се налага да чакат дълго докато нужна нова функционалност се появи.

В крайна сметка, когато се сравняват open source и closed source решения генерализацията, т.е. слагането под обща шапка на всички OS и CS случаи е подход, който може да доведе до неправилни управленски решения и грешни изводи за крайните потребители. Всяко сравнение трябва да се прави за конкретен Use Case и за конкретни продукти.

Вероятно мога да продължа да пиша с часове по темата но горният абзац обобщава накратко мнението ми по въпроса.

Колкото до разликата между free и open-source софт, едва ли има нужда да коментираме

Та, поне при нас:

1. Подобрен продукт
2. Реклама (+нови поръчки, респективно)
3. Клиенти за консултантска дейност

В някои случаи това е достатъчно. Разбира се, зависи от сферата – бизнес софтуер, eRP платформи, може да е уеб програмиране, може да е телекомуникационно обслужване… Може да е и някакъв стрийминг – има прекалено много области и в някои от тях е полезно да пишеш open-source. Да кажем ICQ – не е отворен протокол, но е ‘кракнат’ и съществуват множество алтернативи на клиента. Това е в противовес на политиката на компанията да се ползва техния клиент, но същевременно протоколът им се ползва от многократно повече потребители…

Напълно си прав колко е важна документацията, но това не означава, че (1) другите програмисти го осъзнават това и (2) че документациите в OS проектите стават за четене.

Същото се отнася и за дизайна. Не съм казал, че интерфейсът трябва да е претрупан. Но когато става въпрос за използваемост (usability), интерфейсите на OS продуктите са далеч зад комерсиалните по простата причина, че няма такива специалисти в техните екипи, а това е особено важен фактор за избора на продукт от страна на клиента.

Тук идеята беше да насочим фокуса не върху това колко е гот да програмираш в OS проект, защото на практика в самото програмиране няма разлика, а къде е бизнес модела. Авторът на статията, която цитирам, отстоява позицията, че като производител на комерсиален софтуер има възможността да предложи по-добър продукт и да спечели повече клиенти, които да са съгласни да платят цената, която той иска, при положение, че продуктът решава техните проблеми. С други думи, OS моделът, въпреки че предлага безплатни продукти, което дава възможност за голяма клиентска база, не носи съществена полза за производителя.

Ето, ти също казваш, че сте правили някои отворени проекти, но какво сте спечелили от това? Каква е била бизнес ползата за фирмата? Това е интересния въпрос, към който се опитвам да ви насоча.

Относно публикацията…

Години наред мигрирам почти изцяло на решения с отворен код, като се старая да пиша и с отворени библиотеки и 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 модул, макар и мои познати да се изхранват от такива неща.

“програмисти [...] не обичат да тестват”
Идеята е, че повечето тестване се прави от потребителите докато ползват софтуера, защото (поне в началото) го получават недоизтестван. Да, това може да е недостатък.

“държат потребителя в плен”
“Говорим за малки производители”
Малките също могат. Един краен пример: http://blog.fireeye.com/research/2009/03/a-new-method-to-monetize-scareware.html

“комерсиалните фирми точно за това съществуват – да ми решат проблемите срещу заплащане”
Свободен софтуер с комерсиална поддръжка е ок. Това са различни аспекти на софтуера. Разликата е, че ако нямаш кода, имаш само един избор за това кой да ти помогне.