Mity dotyczące systemów open source klasy CRM

on wtorek, 04 październik 2016. Posted in Open source

Otwarte oprogramowanie (ang. open source movement, dosł. ruch otwartych źródeł) – odłam ruchu wolnego oprogramowania (ang. free software), który proponuje nazwę open source software jako alternatywną dla free software, głównie z przyczyn praktycznych, a nie filozoficznych (źródło: https://www.wikipedia.org).

Open source to pewnego rodzaju idea, która w sposób znaczący wpłynęła na rozwój technologiczny firm na całym świecie. Otwartość oznacza publiczną dostępność kodu dla każdego i pozwala na wspólne budowanie jeszcze lepszych rozwiązań dostępnych dla wszystkich, a największe firmy na świecie często dzięki otwartości w sposób dynamiczny budowały przewagę nad konkurencją.

Obecnie każda firma na świecie korzysta z open source, wynika to z tego, że bardzo duża ilość urządzeń i aplikacji w mniejszym lub większym stopniu wykorzystuje w całości, lub w części otwarte rozwiązania.

W internecie można znaleźć wiele profesjonalnych publikacji oraz popularnych artykułów, które dla wielu osób i firm stały się wyrocznią przy podejmowaniu kluczowych decyzji biznesowych, jednakże we wspomnianych publikacjach wielokrotnie powtarzają się te same błędy.

Open source jest [lub nie jest] tańszy

Osoby, które piszą, że rozwiązanie open source jest tańsze/droższe, bez rozpisania poszczególnych kosztów i ryzyka, nie rozumieją na czym polega wdrożenie systemów klasy enterprise w firmie. Fakt, że rozwiązanie open source nie wymaga opłat licencyjnych nie jest żadnym wyznacznikiem rzeczywistych kosztów wdrożenia.

W przypadku wdrażania rozwiązań open source na dużą skalę, koszt określa się na podstawie bardzo wielu czynników, z których koszty licencyjne stanowią tylko niewielką część całkowitych kosztów, ponieważ dla klienta końcowego liczy się wartość końcowa [również wartość końcowa utrzymania rozwiązania z perspektywy długoterminowej]. Poniżej kilka podstawowych cech, które są brane pod uwagę przy obliczaniu kosztów wdrożenia:

  • Infrastruktura
  • Wspólna analiza wymagań
  • Implementacja
  • Testy [w tym: funkcjonalne, wydajnościowe i akceptacyjne]
  • Wdrożenie produkcyjne
  • Licencje [w tym wdrożeniowe i utrzymaniowe]
  • Gwarancja [w tym SLA]
  • Wytworzenie dokumentacji końcowej
  • Szkolenia
  • Rozwój dodatkowych funkcjonalności

Jeżeli firma szuka rozwiązania najtańszego, wówczas powinna wysłać dobrze opisany dokument zapytania ofertowego [RFP] do potencjalnych dostawców [zarówno do dostawców oferujących oprogramowanie zamknięte, jak również rozwiązanie otwarte], ponieważ tylko w ten sposób możemy ocenić, czy w przypadku tego konkretnego zapytania rozwiązanie open source będzie tańsze, czy też droższe.

Open source jest [lub nie jest] bezpieczniejszy

Panuje popularne przekonanie, że open source jest bezpieczniejszy, ponieważ kod źródłowy jest dostępny dla każdego i każdy może zgłosić lub poprawić w nim błąd. Patrząc z drugiej strony można napotkać artykuły, mówiące o tym, że rozwiązania o kodzie zamkniętym są bardziej bezpieczne, ponieważ nikt nie ma dostępu do kodu, również hakerzy. Oczywiście oba podejścia są błędne.

Rozważmy dwa skrajne przypadki:

  1. Przypadek A: Czy rozwiązanie napisane przez “młodszego” programistę, które zostanie opublikowane na otwartej licencji, a z którego nikt nie korzysta, jest bezpieczniejsze od aplikacji zamkniętej i wdrożonej w dużych firmach oczekujących najwyższego poziomu bezpieczeństwa? Oczywiście rozwiązanie drugie będzie bezpieczniejsze [co nie oznacza, że nie ma w nim błędów bezpieczeństwa].
  2. Przypadek B. Czy rozwiązanie napisane przez dużą firmę, wdrożone w wielu dużych firmach i opublikowane na otwartej licencji jest bezpieczniejsze od zamkniętego rozwiązania napisanego przez “młodszego” programistę, z którego nikt nie korzysta? Oczywiście rozwiązanie pierwsze będzie bezpieczniejsze [co nie oznacza, że nie ma w nim błędów bezpieczeństwa].

Aby jeszcze bardziej zatrzeć różnice pomiędzy otwartym i zamkniętym kodem należy zapoznać się z zagadnieniem tzw. inżynierii odwrotnej, która powoduje, że rozwiązanie do którego pozornie nie mamy dostępu - ponieważ jest zamknięte - poprzez inżynierie odwrotną staje się równie otwarte jak rozwiązania o otwartym kodzie. Dostęp do kodu źródłowego nie określa poziomu bezpieczeństwa, lecz tylko to w jaki sposób to bezpieczeństwo będziemy analizować i weryfikować.

Jakość kodu źródłowego

Aby rozwiązanie było bezpieczne, to przede wszystkim należy zadbać o jakość i porządek w kodzie źródłowym. Nie będę rozpisywał się nad tym dlaczego jest to ważne, ponieważ możemy znaleźć na ten temat wiele dobrych publikacji. To czy rozwiązanie jest otwarte, czy zamknięte w żaden sposób nie określa jego jakości, moglibyśmy się posłużyć podobnymi przypadkami jak w punkcie “Dostęp do kodu źródłowego”, ale nie wniosłyby to nic nowego.

Rozwiązania o kodzie zamkniętym nie dają nam prostej możliwości oceny jakości kodu źródłowego i według mnie jest to duża zaleta open source, ponieważ tą jakość możemy analizować. Nie oznacza to jednak, że każde otwarte rozwiązanie jest dobrej jakości, oznacza to tylko tyle, że możesz je ocenić i zweryfikować.

Do analizy jakości kodu służy wiele narzędzi, jednym z nich jest https://insight.sensiolabs.com/. Obecnie narzędzie to ocenia ponad 110 elementów w kodzie, pełną listę z opisami możemy znaleźć tutaj: https://insight.sensiolabs.com/what-we-analyse. W internecie możemy znaleźć wiele innych projektów, a więc bez problemu dopasujemy je do testowanej aplikacji. Zobaczmy jednak jak wygląda jakość poszczególnych projektów open source klasy CRM:

 

SugarCRM v. 6.5.24

Na obrazku powyżej widzimy podsumowanie dla projektu SugarCRM w wersji 6.5.24, SensioLabs znalazł ponad 25 tysięcy nieprawidłowości, które należałoby poprawić. Sprawdźmy jak wygląda inny projekt, który jest forkiem SugarCRM stworzonym 3 lata temu i niezależnie rozwijanym:

 

SuiteCRM v. 7.7.5

SuiteCRM ma o wiele więcej błędów [ponad 31 tysięcy], ale jednocześnie ma więcej plików i funkcjonalności w porównaniu do SugarCRM. Można z tego wnioskować, że jakość kodu tych dwóch projektów jest porównywalna. Zobaczmy jak wygląda jakość kodu w przypadku innego projektu:

 

VtigerCRM v. 6.5.0

W przypadku projektu Vtiger 6.5 sytuacja jest podobna do dwóch projektów powyżej i ilość znalezionych błędów to ponad 42 tysiące przy czym projekt zawiera najwięcej linii kodu [ponad 700 tys.]. Projekty te powinny wdrożyć procedury naprawcze związane z jakością wytwarzanego kodu i zacząć przestrzegać standardów [m.in. http://www.php-fig.org/psr/].

Tak jak w przypadku SugarCRM powstał fork SuiteCRM, tak również w przypadku VtigerCRM powstał fork YetiForce, sprawdźmy jak wygląda jakość kodu tego projektu:

 

YetiForce 3.3.78

W przypadku YetiForce mamy do czynienia z usunięciem ponad 37 tysięcy błędów, które były w VtigerCRM oraz znaczną rozbudową funkcjonalności, która nie wpłynęła negatywnie na jakość. Oznacza to, że to producent decyduje o tym, czy dane rozwiązanie jest wysokiej klasy, czy też odbiega od obecnych standardów wytwarzania oprogramowania. Przy obecnym tempie rozwoju, już za kilkanaście tygodni projekt ten nie będzie posiadał żadnego błędu, który wpływałby negatywnie na jakość kodu źródłowego.

Systemów klasy CRM o otwartym kodzie możemy znaleźć wiele i każdy z tych systemów możemy zweryfikować i ocenić, dlatego jest to istotna przewaga nad rozwiązaniami zamkniętymi, gdzie ocenić jakość jest o wiele trudniej [a czasem jest to niemożliwe].

Popularność systemu

Niestety producenci oprogramowania open source nie są w stanie niejednokrotnie podać rzeczywistej ilości firm, która używa ich rozwiązania. W przypadku oprogramowania zamkniętego jest to możliwe, lecz wówczas nie można tego zweryfikować na ile te liczby są zgodne z tym co publikuje producent. Patrząc na ogólnie dostępne statystyki [SourceForge, GitHub, Softaculous, itd] można uporządkować otwarte projekty w następujący sposób:

  1. VtigerCRM [około 5.000 pobrań tygodniowo]
  2. SugarCRM [około 2.800 pobrań tygodniowo]
  3. SuiteCRM [około 900 pobrań tygodniowo]
  4. YetiForce [około 600 pobrań tygodniowo]

W punkcie “Jakość kodu źródłowego” poddaliśmy weryfikacji jakość kodu, która prezentuje się w sposób następujący:

  1. YetiForce
  2. SugarCRM
  3. SuiteCRM
  4. VtigerCRM

Oznacza to, że popularność nie ma bezpośredniego przełożenia na jakość, a to znaczy, że rozwiązanie popularniejsze nie oznacza, że jest bezpieczniejsze.

Rozwój a popularność

Wiele osób ocenia popularność poprzez pryzmat ilości pobrań systemu i w ten sposób oceniają wiele innych cech takich jak bezpieczeństwo, jakość, rozwój itd. O ile omówiliśmy jakość i rozwój, o tyle warto wiedzieć na ile poszczególne projekty rozwijają się:

 

Vtiger 6.5.0

W przypadku systemu Vtiger widzimy tylko 17 zmian wprowadzonych na przestrzeni miesiąca przez dwie osoby. Niestety nie mamy tu ilości “polubień” przez programistów [obecnie mają 31 polubień na stronie http://code.vtiger.com/vtiger/vtigercrm] oraz ilości otwartych/zamknięty zgłoszeń [168 otwartych z 304]. To co można wywnioskować z ilości zmian to fakt, że projekt ten praktycznie się nie rozwija, a stan ten jest utrzymywany od dwóch lat.

 

SugarCRM 6.5.24

W przypadku SugarCRM jest jeszcze gorzej, ponieważ projekt ten nie jest rozwijany przez producenta od kilku lat, a obecnie jeżeli zostanie opublikowana jakaś poprawka to tylko związana z bezpieczeństwem. Sam producent oficjalnie podał do wiadomości, że wersja community nie będzie w żaden znaczący sposób rozwijana [dlatego powstał SuiteCRM].

 

SuiteCRM 7.7.5

SuiteCRM od 3 lat rozwija się w sposób umiarkowany [są lepsze i gorsze okresy], ale w porównaniu do systemów VtigerCRM i SugarCRM mamy tutaj do czynienia z postępem i lepszą perspektywą na przyszłość. 95 zmian w ciągu jednego miesiąca można porównać do jednego programisty, który pracuje na ¾ etatu i tylko zajmuje się rozwojem produktu.

 

YetiForce 3.3.78

W przypadku YetiForce mamy do czynienia z prawie 500 zmianami, które dają około 3 pełnych etatów zajmujących się rozwojem oprogramowania. W takim przypadku rozwój poszczególnych projektów można by podsumować w następujący sposób:

  1. YetiForce
  2. SuiteCRM
  3. VtigerCRM
  4. SugarCRM

Jeżeli ktoś w swojej publikacji pisze, że dane rozwiązanie jest bezpieczne, ponieważ pobrano je 2 miliony razy, to powinien zrozumieć, że bezpieczeństwo jest procesem i wymaga ciągłej pracy grupy ekspertów i coś co było bezpieczne rok temu, dzisiaj może być przestarzałe i posiadać wiele krytycznych błędów.

Popularność produktu nie wpływa na jakość, bezpieczeństwo, a tym bardziej nie wpływa na jego rozwój [przynajmniej w sposób bezpośredni]. To czy projekt jest otwarty, czy też zamknięty nie zmienia niczego dla samego produktu.

Open source zapewnia lepsze/gorsze wsparcie

Takie teorie snują najczęściej osoby, które nie wiedzą jak wygląda profesjonalne wdrożenie rozwiązania tej klasy. To na jakim poziomie jest świadczone wsparcie produktu jest kompromisem pomiędzy ceną, oczekiwanym wsparciem, a poziomem ryzyka, który jesteśmy w stanie zaakceptować.

Jeżeli dostawca otrzyma zapytanie ofertowe, w którym jasno zostaną określone warunki świadczenia wsparcia, to nie ma znaczenia czy rozwiązanie jest otwarte czy też zamknięte, dostawca/producent szacuje czy będzie w stanie i na jakich warunkach świadczyć odpowiedni model wsparcia i przedstawia to w ofercie.

Podsumowanie

Licencja oprogramowania nie zmienia niczego w zakresie bezpieczeństwa, jakości, wsparcia czy też tempa rozwoju. To jak wygląda system dzisiaj i jutro zależy tylko i wyłącznie od producenta programu i społeczności, która skupiła się wokół projektu. Najważniejsza jest ciążka praca i zespół, który wzniesie projekt ponad to co możemy mieć na co dzień.

Copyright 2015 YetiForce.com All rights reserved.