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 oprogramowania dla każdego i pozwala na wspólne budowanie jeszcze lepszych rozwiązań dostępnych dla wszystkich. 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 większość 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 pełnią ważną rolę przy podejmowaniu kluczowych decyzji biznesowych. Jednakże we wspomnianych publikacjach wielokrotnie powtarzają się te same mity, które postanowiliśmy obalić.

Osoby, które piszą, że rozwiązanie open source jest tańsze bądź 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. Koszty licencyjne stanowią tylko niewielką część całkowitych kosztów, ponieważ dla klienta liczy się wartość końcowa (również długoterminowe koszty utrzymania oprogramowania).

Jeżeli firma szuka rozwiązania jak najtańszego, wówczas powinna wysłać dobrze opisany dokument zapytania ofertowego (RFP) do potencjalnych dostawców - zarówno tych oferujących oprogramowanie zamknięte, jak i rozwiązania otwarte. 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.

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 do niego dostępu, 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. Oznacza to, że rozwiązanie, do którego pozornie nie mamy dostępu - ponieważ jest zamknięte - poprzez inżynierię 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ć.

Aby rozwiązanie było bezpieczne, przede wszystkim należy zadbać o jakość i porządek w kodzie źródłowym. To, czy rozwiązanie jest otwarte czy zamknięte, w żaden sposób nie określa jego jakości.

Rozwiązania o kodzie zamkniętym nie dają nam prostej możliwości oceny jakości kodu źródłowego, co jest dużą zaletą open source, ponieważ dostęp do kodu źródłowego daje możliwość analizy. Nie oznacza to jednak, że każde otwarte rozwiązanie jest dobrej jakości, oznacza to tylko tyle, że można je ocenić i zweryfikować.

Do analizy jakości kodu służy wiele narzędzi, jednym z nich jest SensioLabs Insight. Obecnie narzędzie to ocenia ponad 110 elementów w kodzie, na ich stronie można odnaleźć pełną listę z opisami. W internecie dostępne jest wiele innych projektów, a więc bez problemu można dopasować je do testowanej aplikacji. Zobaczmy jednak jak wygląda jakość poszczególnych projektów open source klasy CRM.

Na obrazku obok 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ć. SuiteCRM v. 7.7.5

SuiteCRM to niezależnie rozwijany fork SugarCRM. Jak widać, 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.

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. Ten system zawiera jednak najwięcej linii kodu (ponad 700 tys.). Powyższe projekty powinny wdrożyć procedury naprawcze związane z jakością wytwarzanego kodu i zacząć przestrzegać standardów (m.in. PHP Standards Recommendations). 

YetiForce to fork Vtiger. 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ć. Jest to istotna przewaga nad rozwiązaniami zamkniętymi, gdzie ocenić jakość jest o wiele trudniej (a czasem jest to niemożliwe).

Niestety producenci oprogramowania open source nie są w stanie niejednokrotnie podać rzeczywistej liczby 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.

Wiele osób ocenia popularność poprzez pryzmat liczbę pobrań systemu i w ten sposób ocenia wiele innych cech, takich jak bezpieczeństwo, jakość, rozwój itd. Jak intensywnie rozwijane są projekty open source? 

Vtiger 6.5.0

W przypadku systemu Vtiger widzimy tylko 17 zmian wprowadzonych na przestrzeni miesiąca przez dwie osoby. Niestety nie mamy tu liczby “polubień” przez programistów (obecnie mają 31 polubień na stronie z kodem Vtigera) oraz liczby otwartych/zamkniętych zgłoszeń (168 otwartych z 304). To, co można wywnioskować z liczby, 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. 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 zajmuje się tylko 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. 

Biorąc pod uwagę powyższestatystyki, 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. 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ść i 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 i 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 bądź producent szacuje, czy będzie w stanie (a jeśli tak, to 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ń.