Wady i zalety open source

plusyminusy

Rynek eCommerce jest szybko rozwijającym się obszarem. Dla firm rozumiejących potencjał sprzedaży internetowej staje się ważnym źródłem dochodów. Warunkiem sprawnie funkcjonującego sklepu internetowego jest stałe dopasowywanie się do potrzeb współczesnego, coraz bardziej mobilnego klienta, który pragnie sprawnie i komfortowo kupować online.

Przy tworzeniu sklepu internetowego podstawą jest wybór odpowiedniego dla potrzeb biznesu oprogramowania – dedykowanego lub open source. Śledząc portale internetowe trudno nie oprzeć się wrażeniu, że istnieje spora dezinformacja na temat wad i zalet otwartego oprogramowania.

Bezsprzecznie, ma one ogromny wkład w popularyzację i rozwój eCommerce. Jednak znając zarówno walory jak i mankamenty tego rodzaju oprogramowania, można dopasować system sprzedaży online do specyfiki prowadzonego biznesu, a przede wszystkim wymagań obecnych i przyszłych klientów sklepu internetowego.

Oprogramowanie otwarte w kraju i na świecie

Wśród 10 000 największych na świecie sklepów internetowych, najpopularniejszym silnikiem open source, jest Magento. Według danych z portalu Built With, na silniku Magento działa ponad 14% wszystkich sklepów, a kolejne 8% to sklepy na Magento Enterprise.

Stworzony przez i-systems na podstawie: Global eCommerce Technology Distribution http://trends.builtwith.com/shop. The shopping cart technologies used by online stores globally. Last updated Jan 20th 2016.

Stworzony przez i-systems na podstawie: Global eCommerce Technology Distribution http://trends.builtwith.com/shop. The shopping cart technologies used by online stores globally. Last updated Jan 20th 2016.

Biorąc pod uwagę Polskę, Magento znacznie traci rynek na rzecz innych rozwiązań. To oprogramowanie obsługuje tylko 4% polskich sklepów internetowych. Liderem na tym poziomie, jest PrestaShop które wybierane jest przez 25% rynku. Popularnym oprogramowaniem jest również WooCommerce, który zajmuje 19% rynku.

Stworzony przez i-systems na podstawie: Top in Ecommerce usage in Poland. Week beginning Jan 25th 2016.

Stworzony przez i-systems na podstawie: Top in Ecommerce usage in Poland. Week beginning Jan 25th 2016.

Open source, koszty wdrożenia i rozwoju

Słowo open nie oznacza darmowego oprogramowania – określa otwarty kod źródłowy. W związku z tym, osoby posiadające odpowiednie umiejętności programistyczne oraz czas, mogą swobodnie modyfikować silnik sklepu pod własne potrzeby. Stworzenie na tej podstawie sklepu jest możliwe,  jednak nie należy oczekiwać, że powstanie on zupełnie za darmo. Jeśli nie posiadamy umiejętności programistycznych, brakuje nam czasu lub chcemy skupić się na działaniach sprzedażowych – musimy za takie usługi zapłacić.

Ze względu na duże zapotrzebowanie, stawki specjalistów Magento należą do jednych z najwyższych wśród programistów eCommerce. W open source licencja podstawowa jak np. Magento Community, jest bezpłatna. Jednak, gdy chcemy, aby nasz system posiadał wsparcie techniczne oraz moduły marketingowe, musimy wykupić wersję Magento Enterprise z roczną opłatą licencyjną w kwocie ponad 22 000 $.

Bezpieczeństwo przy wyborze oprogramowania otwartego

Otwartość kodu to rozwiązanie, które posiada swoje mocne i słabe strony. Może oznaczać lepszą wykrywalność błędów i szybsze ich naprawianie, z drugiej większe ryzyko ataku. Sprawdzenie kodu przed dużą społeczność to również rozmyta odpowiedzialność za błędy. Przykładem może być OpenSSL i luka “hearbleed”. Przez ponad dwa lata luka znajdowała się w przeglądarkach i na serwerach sieciowych. Nikt tego nie zauważył, myśląc, że zostało to już wcześniej sprawdzone.

Trudności z aktualizacjami i kompatybilnością z następnymi wersjami open source

Open source rzadko jest kompatybilny z następnymi wersjami. Problemy związane z aktualizacjami często poruszane są na forach. Gdy pojawia się nowa wersja Magento i sklepy próbują migrować, bardzo często integracje i dedykowane rozszerzenia sklepu przestaną działać prawidłowo. Zdarza się również, że nawet oficjalne moduły odmawiają posłuszeństwa. Wtedy trzeba stawiać sklep praktycznie od nowa. Komplikacje z aktualizacją spowodowały, że znaczny odsetek sklepów internetowych nadal pracuje na silnikach Magento w wersji 1.7.

Open source a zmiana firmy wdrażającej sklep internetowy

Otwarte oprogramowanie pozwala na zmianę agencji tworzącej internetowy system sprzedaży.  Należy jednak pamiętać, że agencja, która ma świadomość chwilowej umowy z klientem, nie zawsze w pełni angażuje się w powierzone zadania. Zdarza się, że sklepy powstające na open source są pisane w pośpiechu, bez spójnych zasad, dbałości o komentarze, specyfikację i kulturę kodu. Oznacza to, że nowa agencja w początkowej fazie ma ogromny problem, musi bowiem zrozumieć co programista miał na myśli. W konsekwencji metodą prób i błędów wprowadzane zostają zmiany lub pewne części sklepu pisane są od podstaw. Powstaje przez to tak zwany “efekt długu technologicznego” oznaczający w przyszłości większy koszt modyfikacji i rozwoju oprogramowania.

Komercjalizacja open source

Każde oprogramowanie przemija i jest wypierane przez nowsze rozwiązania. Przykładem może być oprogramowanie OsCommerce, które długo było najpopularniejszym systemem dla sklepów internetowych. Obecnie jest jednak stopniowo wypierane z rynku na rzecz innych systemów.

Wykres popularności oprogramowania open source, stworzony przez i-systems na podstawie: http://www.slideshare.net/AuroraCreation/szkolenia-magento-dekalog-bezpieczestwa-magento

Wykres popularności oprogramowania open source, stworzony przez i-systems na podstawie: http://www.slideshare.net/AuroraCreation/szkolenia-magento-dekalog-bezpieczestwa-magento

Obecnie siłą napędową Magento 2, którego premiera została ogłoszona ponad 3 lata temu jest ebay. W trakcie trwania prac projekt opuścił CEO firmy Varien i twórca oprogramowania Magento. Przyznał on nieoficjalnie, że miał sprzeczne z ebay definicje słowa open source. Kierunek rozwoju tego oprogramowania widać wyraźnie poprzez porównanie tego, co zostało zabrane z wersji Community na rzecz Enterprise. Komercjalizacja oprogramowania open source jest standardową praktyką. Lista darmowych modułów, liczba użytkowników oraz produktów jest stopniowo ograniczana, aby firmy chcące rozwijać swoje działania online, przechodziły na model płatny.

Koszt utrzymania oprogramowania otwartego

Największymi kosztami stałymi w utrzymaniu sklepu internetowego są hosting i czas programistów. Open source to system często nadmiernie rozbudowany. Z tego powodu, wymaga kilkukrotnie większych zasobów, niż tej samej wielkości system dedykowany. Optymalizacja jest kłopotliwa, a wzrost ruchu oznacza konieczność dołożenia mocy obliczeniowej.

Open souce tworzone przez samoedukującą się społeczność

Open source dużą popularność zawdzięcza społeczności, która samodzielnie się edukuje. Bezpośrednio wpływa na to coraz większą liczbę nowo powstających agencji wdrażających sklepy w oparciu o otwarte oprogramowanie. Oprogramowanie open source będzie zawsze popularniejsze, dlatego że wyraźnie skraca drogę każdej agencji interaktywnej do możliwości tworzenia sklepów internetowych. Jednak tego typu sklepy internetowe cechują się niskim poziomem bezpieczeństwa – często padają ofiarą ataków oraz kradzieży danych. Jest to również najczęściej wykorzystywane rozwiązanie do tworzenia fikcyjnych sklepów.

Open source a nowe rozwiązania

Współczesne systemy sprzedaży już dawno wykroczyły poza ramy standardowego zbierania i obsługi zamówień. Obecny rynek eCommerce zmienia się bardzo dynamicznie. Open source zawsze jest kilka kroków za rozwiązaniami, które wypracowywane są przez firmy komercyjne w zamkniętych zespołach. Tak było w przypadku Responsive Web Desing, czy OmniChannel. Czekanie na moment, w którym powstanie gotowy moduł może spowodować utratę klientów sklepu internetowego, ponieważ będą oni zainteresowani dokonywaniem zakupów zgodnie z obowiązującymi w danym momencie standardami.

Oprogramowanie open source takie jak Magento, WooCommerce czy Presta jest bardzo dobrym uzupełnieniem rynku eCommerce. Odpowiada na potrzeby małych i średnich firm, które mają doświadczenie i zasoby na samodzielne rozwijanie standardowego sklepu. Jednak w sytuacji, gdy firma pragnie skoncentrować swoje działania na wzroście sprzedaży oferowanych produktów, a support, hosting i sprawy techniczne woli zlecać zewnętrznej firmie, warto zastanowić się nad dedykowanym oprogramowaniem. Koszty wdrożenia i dalszego rozwoju mogą okazać się znacznie niższe, niż w przypadku open source. Wdrożenie dedykowanych rozwiązań warto rozważyć szczególnie wtedy, gdy funkcjonalności sklepu wychodzą poza te standardowe i zakładają integracje wymagające stałej kontroli i szybkiej reakcji na błędy.

Tagi

sprzedaż detaliczna B2C rozwiązania eCommerce omnichannel


Zobacz również artykuły o podobnej tematyce

B2E, czyli skuteczne wsparcie organizacji pracy
B2E banner

Jak sprawić, by organizacja efektywnie funkcjonowała na współczesnym rynku? Każdy kto prowadzi firmę wie, że kwestia ta potrafi spędzać sen...

Aplikacja mobilna brakującym ogniwem omnichannel?
aplikacja mobilna

W 2018 r. strategia omnichannel wydaje się standardem. Wszystkie liczące się marki posiadające sieć sklepów stacjonarnych połączyły w większym lub...

Czy człowiek może być kolorem? Kapitał ludzki, jako największa wartość w organizacji
ludzie-1

Chcąc prowadzić innowacyjną i ponadczasową firmę należy bacznie obserwować indywidualne predyspozycje pracowników. Nie każdy z nich nadaje się do pracy...

Zobacz więcej wpisów
  • http://oferownik.pl Robert Marketingowiec

    Nie da się być mocnym we wszystkich kanałach komunikacji, trzeba sobie wypracować te które najbardziej się wybijają i się ich trzymać.

  • Marcin

    „Dawno temu skupialiśmy się na ważnych rzeczach, czyli rozwiązywaniu problemów i logice biznesowej. Dzisiaj jesteśmy prawie całkowicie skoncentrowani na abstrakcji i generalizacji.” – i to wszystko wina frameworków? Czy to wina cegieł i zaprawy że murarze krzywo wybudowali mur, czy jednak problemem było nieprofesjonalne podejście fachowców, którzy ubzdryngoleni przyszli do pracy? Nie możemy zrzucać winy na narzędzia, za to że źle tworzymy aplikacje. Powinniśmy raczej starać się dostrzec fakt, że problem leży w nas samych i spróbować go zrozumieć… oraz coś z nim zrobić. I na pewno nie jest metodą na ów problem podejście, że „powinniśmy używać PHP, a nie architektury do budowania aplikacji” – taki tok rozumowania jest idealnym dowodem na to jak wiele osób nie rozumie czym jest architektura. Architektura to nie framework! Posłużę się kolejnym odwołaniem do budownictwa: czy patrząc na kościół pierwsze co widzimy to to, z czego jest on zbudowany czy raczej jakie jest jego przeznaczenie. Albo: czy widząc bramę pierwszą naszą myślą jest „użyli cegieł z Castoramy i wkrętarki boscha” czy raczej „to jest brama – służy do tego by gdzieś wejść lub skądś wyjść”?
    To prawda – we współczesnym programowaniu zapominamy o logice biznesowej, ale nie jest to wina architektury, tylko raczej braku dyscypliny w nas samych – nie interesuje nas to, nas jara głównie fakt że piszemy np. w kotlinie bo to jest teraz modne. „Zrobię to na symfony, zapytania puszczę doctrinem a obiekty będę serializować jms’em” – to nie jest opis architektury, to lista zakupów – jakich narzędzi potrzebuję by zrealizować cel. Szkoda tylko, że przez to cel ląduje na drugim (albo i nawet dziesiątym) miejscu – a celem jest np. zbudowanie aplikacji do przechowywania dokumentów. Ale to nie decyzja twórców bibliotek/frameworków, że cel staje się dla nas mało istotny. To nie Fabien Potencier każe nam całą logikę wrzucać do akcji w kontrolerze, to nie Jonathan Wage podpowiada nam, by nasze biznesowe obiekty bezpośrednio wywoływały doctrine’a! To my, my programiści sami doprowadzamy do tego, że nasze aplikacje przypominają niestrawione resztki pokarmu które codziennie zostawiamy w porcelanowym ekspresie. I póki nie nauczymy się odseparowywać logiki biznesowej od narzędzi to dalej będziemy tworzyć legacy code.
    Co do argumentu, że niektóre z zależności mogą zostać po kilku latach porzucone i nie będą dalej rozwijane… serio? I proponujesz phpti jako alternatywę do twiga albo smarty? Wszystko może zostać po kilku latach porzucone, to do obowiązków programisty należy m.in. nie pozwolić na to, by moduły/komponenty nie były sprzężone z innymi elementami czy zewnętrznymi bibliotekami.
    A co do bogactwa wiedzy i tego co się dzieje pod maską – ogólnie nie powinno się używać narzędzi, których się nie rozumie: jak działają, dlaczego tak działają itp. By potem nie było sytuacji w stylu senior piszący od 5 lat w laravelu nie potrafi odpowiedzieć na rozmowie kwalifikacyjnej na pytanie „Co robi funkcja die()?”…

    TL;DR: nie zgadzam się 😉