20
cz.
2014
palikowski

Open Source jest tylko dla odważnych? Czyli jak wybieramy system dla siebie

(źródło paska - dilbert.com)

Mam czasem wrażenie, że marketingowcy sprzedający gotowe, pudełkowe, komercyjne produkty starają się "ustrzec" swoich klientów przed Open Source. Bo przecież płacąc za komercyjny produkt dostajesz:

a) wsparcie producenta lub dealera,
b) nowe funkcje, poprawki do błędów, łatki bezpieczeństwa
c) lata pracy doświadczonego zespołu, który skroił produkt gotowy do użycia, idealnie dopasowany, niemal bezobsługowy...

Decydując się na Open Source masz za to same problemy:

a) wsparcie i tak musisz wykupić na rynku, jako polisę ubezpieczeniową w razie awarii, która może zatrzymać Twój biznes,

b) nowe funkcje, poprawki i łatki są - o ile akurat ktoś będzie miał czas i chęć je napisać (czytaj - jedna wielka loteria i brak gwarancji),

c) lata pracy zespołu - może nawet większego i pracującego (sumarycznie) dłużej, ale zupełnie nieskoordynowanego, więc czasem ciągnącego wóz w 2 albo 3 (albo 5) różne kierunki, walczącego ze sobą. Czytaj - produkt jest pełen śmieciowego kodu, nie ma w nim za grosz konsekwencji i tak dalej...

Prawda jest jednak taka, że... nie ma idealnych rozwiązań i wszystkie powyższe stwierdzenia zawierają ziarenka prawdy. Te ziarenka, kiedy je rozsypiesz na stole i postarasz się poukładać w jakąś sensowną całość (np. podczas analizy jaki produkt wybrać) potrafią stworzyć fascynującą, ale niesamowicie skomplikowaną macierz kosztów, wymagań, zagrożeń, znanych problemów, ryzyk i szans - nie do ogarnięcia przez typowego decydenta, który szuka rozwiązania klasy CRM, CMS/WCM, ECM czy innego (o ERP nawet nie wspominam, bo to nie moja liga i tylko sobie wyobrażam jak tam musi być hardkorowo :P).

Koniec końców, kiedy zespół próbuje dokonać wyboru jakiegoś systemu, zwykle powstają gigantyczne tabele, w których cechy, wagi, procenty, koszt, czas i priorytety mieszają się, mnożą, dzielą i pączkują w excelowe formuły, które pewnie przyprawiłyby o ból głowy miłośników matematyki... Po iluś tam iteracjach, zrezygnowani i wyczerpani decydenci zaczynają myśleć o rzuceniu tego wszystkiego w cholerę i:

a) wybraniu systemu na podstawie interfejsu użytkownika ("o, ten mi się podoba, bierzemy")
b) rzutach kostką ("przecież nie chcielibyśmy wybrać dostawcy, który ma pecha, prawda?")

Odbiegliśmy jednak od tematu, którym miało być "Open Source czy komercyjny, zamknięty produkt... a może SaaS?"

Proces wyboru rozwiązania (spośród kilku możliwości, wśród których są różne modele licencyjne), pokazuje nam, że ilość czynników wpływających na decyzję, nawet w średnio skomplikowanym produkcie, może być ogromna. Wystarczy sobie przypomnieć, jak ostatnio kupowaliśmy laptop, aparat cyfrowy czy nawet głupi odkurzacz.

O ile jesteśmy w stanie łatwo policzyć koszt licencji czy utrzymania to trudniej zmierzyć jaki będzie koszt konsultacji, analizy, wdrożenia, zmian organizacyjnych itd. Zdarza się też, że trudno obronić kupno droższego, ale ewidentnie lepszego produktu. Mimo, że "czujemy pod skórą", że zaoszczędzi on nam dodatkowych prac (bo np. zawiera już funkcje i integracje, które w innych przypadkach musielibyśmy dopisać czy dokupić), to musimy to udowodnić przygotowując jakiś szacunkowy TCO, w którym udowodnimy, że lepiej jest na początku zapłacić więcej, aby summa summarum wydać mniej.

Poza tym jakbyśmy nie wybrali to i tak skazujemy się na męczarnie związane z wdrożeniem, integracją, omijaniem słabości i niedomagań wybranej platformy, szukaniem rozwiązań znanych błędów. Na koniec i tak użytkownicy nas wyklną od najgorszych (bo wprowadzamy ZMIANĘ) a management przetrąci premię (bo miało być lepiej a jest gorzej, bo nie osiągnięto zakładanego ROI, bo departament IT znowu jest na językach w całej korporacji, ...).

Statystycznie na nasza niekorzyść przemawia:
- % projektów z problemami,
- przekrój społeczny i ilość negatywnie i roszczeniowo nastawionych osobników w dowolnej populacji,
- ilość błędów w skomplikowanych produktach,
- ilość systemów, które już są i trzeba je zintegrować z nowym,
- ilość regulacji zewnętrznych i wewnętrznych, które trzeba uwzględnić we wdrożeniu,
- i tak dalej...

Może więc pora pogodzić się z faktem, że co byśmy nie wybrali - Open Source czy komercyjne produkty - zawsze będzie ciężko.

Popatrzmy jednak co możemy zyskać wybierając Open Source (wiedzieliście, że jednak będę was do tego namawiał, prawda? :P)

- możliwość wynajęcia developera, który przystosuje produkt do Waszych potrzeb. Jeśli macie kasę i zechcecie, żeby Wasz Drupal miał funkcję X to ją dostaniecie bez łaski producenta i właściciela Drupala, bo tacy właściwie w przyrodzie nie występują.

- Co więcej, jeśli już za coś płacicie to zazwyczaj Wasze pieniądze napędzają lokalną gospodarkę (idą do developera, wdrożeniowca, osób gotowych Was wspierać) a nie płyną do kraju producenta (który sprzedaje Wam licencję na użytkowanie). Ten argument ostatnio padł na jednym z Drupalconów i jest naprawdę diabelsko działający na wyobraźnię, szczególnie lokalnych patriotów :),

- nie płacąc za licencję i prawo do aktualizacji macie więcej kasy dla analityka, wdrożeniowca, programisty, którzy zrobią z niej stosowny użytek (dopasowując system i pisząc kod dla Was),

- zarywając noce nad jakimś problemem ("to gówno znowu się rozkraczyło!") możecie pocieszać się przynajmniej tym, że nie zapłaciliście za licencję na "to gówno" ani grosza, i że gdybyście kupili produkt znanej firmy X to problemy i tak by Was nie ominęły,

- kiedy ktoś odkryje lukę w bezpieczeństwie systemu/produktu, który używacie, nie musicie bać się tego, że producent będzie ja ukrywał przez pół roku zanim triumfalnie ogłosi, że właśnie ją załatał. Masz informację zaraz po odkryciu luki i możesz szybko podejmować decyzję co z tym fantem robisz. Czasem lepiej wyłączyć system na tydzień niż ponieść koszt ewentualnej kompromitacji danych (np. Twoich klientów).

Tyle ode mnie na dziś. Jeśli macie jakieś ciekawe uwagi to piszcie śmiało :).

Długi tekst ... A można by

Wpisał Jacek (niezweryfikowany) 21 June 2014 - 9:33am.

Długi tekst ...

A można by jeszcze iść w rozważanie wewnątrz opensource

A jakby zlecić wykonanie takiego oprogramowania jakiemuś programiście?
Udostępnić światu i rozwijać taki system w modelu opensource?

Ale jaki wtedy model wybrać model tworzenia oprogramowania?
Katedralny czy bazarowy?

https://plus.google.com/...

Tekst długi bo... nie mam

Wpisał palikowski 21 June 2014 - 10:47am.

Tekst długi bo... nie mam czasu pisać na bieżąco swoich codziennych spostrzeżeń. Zatem jak już usiądę do klawiatury to "wylewam żale" z kilku tygodni :) wiem, że cierpi na tym czytelnik ale trudno, przynajmniej ja trochę się "wypłaczę" i oczyszczę :)

Niezły tekst - szczerze to po

Wpisał greg (niezweryfikowany) 21 July 2014 - 1:45pm.

Niezły tekst - szczerze to po wielu akcjach z enterprajsami spod znaku kapelusza czerwonego czy ze stajni Larrego Ellisona zdecydowanie polecam opensource. Developerzy opensource reagują na bugi szybciej niż komercyjne odpowiedniki - przykład : heartbleed. Oprócz tego mamy całe comunity związane z projektem np. Debiana - które w 90 % pomaga szybko rozwiązać problemy z np. konfiguracją.