Na stronie jednej z firm IT znajdziemy opis zalet stosowania oprogramowania [[Open Source]]. Nie będzie to absolutnie krytyka strony czy samej firmy. Nie jest to także ani krytyka ani pochwała idei open source, bo dla mnie nie ma to większego znaczenia. Będzie to dyskusja z opublikowanymi tam argumentami “za”. Ten artykuł to próba obiektywizacji wielu, nie zawsze moim zdaniem prawdziwych, opinii. Ale po kolei.
Open Source ma wiele do zaoferowania światowi biznesu. Jego główne zalety to:
Niezawodność
Otwarte oprogramowanie oznacza zwiększone bezpieczeństwo – ponieważ kod źródłowy jest wystawiany na widok publiczny, jego użytkownicy sprawdzają go z ekstremalną dokładnością. Błędy są natychmiastowo wykrywane i poprawiane. Z tego powodu niezawodność aplikacji Open Source jest bardzo wysoka w porównaniu do zamkniętych, własnościowych programów. Obala to mit rzekomego braku profesjonalizmu otwartego oprogramowania.
Upublicznienie kodu programu może ale nie musi oznaczać tego, że jest rygorystycznie sprawdzany, pewnie mógłby ale to tylko deklaracja “potencjalnej możliwości”. O brak profesjonalizmu nie posądzam autorów dobrych programów, także tych open source, jednak czy mając samochód i możliwość zaglądania do silnika codziennie, sprawdzacie i testujecie go, zgłaszacie pomysły producentowi? Czy raczej reagujecie wyjazdem do serwisu w razie wykrycia usterki? O jakości kodu świadczy nie to czy jest otwarty, a to ilu ma użytkowników bo to oni tak na prawdę testują system.
Szybkość rozwoju oprogramowania
Podstawowa idea Open Source jest bardzo prosta – jeśli za pomocą Internetu programiści z całego świata mogą razem uczestniczyć w procesie ulepszania oprogramowania (poprawa błędów, rozbudowa funkcjonalności), gwarantuje to błyskawiczny rozwój aplikacji. Z tego powodu wytwarzany produkt jest w efekcie lepszy niż tradycyjny zamknięty model, gdzie tylko kilku programistów ma wgląd w kod źródłowy, a wszyscy inni muszą korzystać z gotowych, zamkniętych oraz uniemożliwiających wszelką modyfikację aplikacji.
To już chyba jednak mit. Cykl życia każdego produktu, to szereg iteracji w pewnych odstępach czasu, a duża częstość nowych emisji raczej świadczy o zbyt krótkim testowaniu a więc gorszej jakości. Możliwość zgłaszania pomysłów na nowe możliwości nie oznacza ich automatycznego uwzględniania i szybkiej implementacji. Nawet społeczności zarządzają swoimi produktami, ilość mało kiedy oznacza jakość, także pomysłów. Praktyka pokazuje, że każdy kawałek dobrze zarządzanego kodu po stronie jego twórcy, jest zarządzany przez jedną osobę lub mały mały zespół. To czy dany produkt jest lepszy to efekt subiektywnej oceny funkcjonalności. Składa się na to jednak nie tylko sam “kod” ale także jego przydatność w konkretnym zastosowaniu.
Zmniejszenie kosztów ogólnych
Brak jakichkolwiek opłat licencyjnych sprawia, że całkowity koszt jest zdecydowanie niższy niż w przypadku komercyjnych rozwiązań. Praktycznie każdy może pobrać i użytkować wybraną aplikację. Opłacie podlega jedynie wdrożenie, szkolenie personelu oraz rozbudowa systemu. W konsekwencji wykorzystanie rozwiązań typu Open Source znacznie zmniejszy Twoje wydatki.
Oprogramowanie biznesowe, jego zakup i wykorzystywanie to projekt trwający kilka lat od zainstalowania do wycofania z użytkowania. Koszt nabycia licencji na kod, nawet kosztownych komercyjnych produktów, ginie na tle kosztów utrzymania i rozwoju. Te zaś zalezą od tego jak oprogramowanie zaprojektowano, w jakim środowisku (java, .NET, PHP, inne) zaimplementowano oraz jak wdrożono, a to w 100% zależy od projektanta a nie od tego na jakiej licencji udostępniany jest sam program. Do tego warto pamiętać, że rzadko autorzy udostępniają wartościowe pomysły ot tak za darmo (z czegoś musza się utrzymać), bywa że te są częściej chronione patentami, wystarczy obserwować co pojawiające się regularnie pozwy sądowe o prawa autorskie do fragmentów kodów.
Niezależność od usługodawcy
Dzięki otwartości kodu nie będziesz już uzależniony od dostawcy Twojego oprogramowania. Praktycznie każdy programista czy też firma wdrożeniowa specjalizująca się w technologii, w której stworzona jest dana aplikacja, może świadczyć dalsze usługi dla Twojego przedsiębiorstwa.
Tu natomiast zwrócono uwagę na ważną rzecz, faktycznie uzależnienie od jednego dostawcy, autora systemu, może być ryzykowne. Jednak to samo, możliwość wymiany usługodawcy na innego, można powiedzieć np. o każdym produkcie Microsoft…
Darmowa aktualizacja
W przypadku zamkniętych komercyjnych rozwiązań, oprogramowanie z czasem przestaje spełniać wymogi rynku. W takich sytuacjach wydawane są nowe wersje lub dodatki, za które klient musi zapłacić. Open Source gwarantuje stały, darmowy dostęp do najnowszych aktualizacji.
To już zależy od modelu biznesowego dostawcy (twórcy) oprogramowania. Opłaty za upgrade są “ponoszone” na różne sposoby. Jeżeli jakaś firma, tu np. dostawca produktu open source, pobiera od nas coroczne opłaty za wsparcie zainstalowanego u nas produktu, który wdrożyła, to składniki tej kwoty mają znaczenie drugorzędne. Tym składnikiem raz jest faktycznie wprost, faktura od twórcy komercyjnego oprogramowania, innym razem opłaty takie ponosi firma wdrażająca, która nas fakturuje raz za swoje usługi. Dobre firmy na różne sposoby wspierają (np. donacje) społeczności, których produktów używają, to koszt prowadzenia działalności (także płacę). Tak więc użytkownik oprogramowania open source pośrednio także płaci, za to czego używa, twórcom. To z czym można się zgodzić to brak kosztów “korporacyjnych” twórców oprogramowania open source, ale to w masie kosztów całego projektu nie wpływa zbytnio istotnie na całość tych kosztów.
Cytaty zaczerpnięto ze strony Open Source ? Definicja ? Zastosowanie ? Zalety firmy eVolpe. To co można na pewno powiedzieć, to to, że warto wybrać rozwiązanie wspierane wysokiej jakości usługami. Jednak najpierw rozwiązanie, produkt, a potem jego dostawca.
Sam jestem użytkownikiem oprogramowania open source, ten blog to oprogramowanie rodem z http://wordpress.org/, jednak ja mam wsparcie i płacę. Ja produkty open source porównał bym do produktów dużych międzynarodowych korporacji, całkowity koszt dla ostatecznego ich użytkownika zawsze będzie sumą kosztów utrzymania twórców oprogramowania oraz tych, który je wdrożyli i potem wspierają to wdrożenie. Podział i jawność poszczególnych pozycji tych kosztów to w moich oczach tylko marketingowe zabiegi. Jedno jest pewne, produkty “słabo” finansowane kończą albo jako “zaprzestano rozwoju” albo, jeśli są na prawdę dobre, są przejmowane i komercjalizowane. Czasem ma miejsce coś co ja nazywam “autokomercjalizacją” czyli społeczność twórców po prostu przekształca się w podmiot rynkowy oferujący swój produkt. Pewnym wariantem jest przykład bardzo popularnego systemu CRM open source jakim jest SugarCRM, tu cennik :): https://www.sugarcrm.com/sugarshop/
Ciekaw jestem Państwa odczucia w tej kwestii… a dyrektorowi firmy eVolpe dziękuje za merytoryczne i wartościowe dyskusje.
Witam,
Myślę, że przytoczone przez wspomnianą firmę zalety OS to w większości taki trochę “bełkot marketingowy”, który posiada w sobie sporo prawdy, lecz brakuje w nim … analogii. Zanim przytoczę przykłady proszę zwrócić uwagę, że :
1. Oprogramowanie tworzą ludzie
2. Oprogramowanie zamknięte jest sprzedawane w systemie pudełkowo-licencyjnym i bez gwarancji, czyli widziały gały co brały
3. Mówimy o oprogramowania Open Source (OS) vs Closed Source (CS), a nie darmowe i komercyjne
“Niezawodność” (to nie to samo co bezpieczeństwo, ale niech tam :)) –
a. działa tu efekt psychologiczny: człowiek stara się by jego kod wyglądał porządnie i był dobry, bo będą go oglądały dziesiątki/setki/tysiące oczu
b. co do serwisu: to czy jedziemy do drogiego, nie-wiadomo-kiedy reagującego serwisu, albo do siedziby producenta, czy też do znajomego mechanika/serwisu na naszej ulicy? – kwestia wyboru. Szacuję, że conajmniej 80% usterek to pierdółki dla sprawnego fachowca. Pozostaje kwestia na ile aplikacja jest dla nas ważna.
c. Close Source to taki samochód w którym otwarcie maski można przeprowadzić jedynie u producenta samochodu 🙂
“Szybkość rozwoju oprogramowania” –
Przygotowanie jednej funkcji (poprawienie jednego błedu) jest szybsze niż czekanie na cały nowy release. Możliwość rozgałęziania kodu. Nie trzeba czekać na Iterację. Każdy klient może mieć własną wersję kodu, np. którą sam pielęgnuje.
“Koszt”
a. Model CS: jest nowsza wersja, znowu płacimy. Nawet jak stara nam pasuje, ponieważ tracimy na starą support. Jak potrzebujemy 1 funkcję z 1000 nowych to płacimy za wszystko. model OS: płacimy za wykonanie jednej funkcji, chyba, że nie płacimy, a i tak ją dostajemy 🙂
b. Producenci CS nie dają gwarancji, za każdą naprawę błędu należy zapłacić (przeważnie jako umowa serwisowa) lub czekać, aż się naprawi lub się nie doczekać lub kupić nowszą wersję – istna ruletka.
“Niezależność od usługodawcy”
Czy mogę zmienić Microsoft na inną firmę, która będzie supportować MS SQL (usuwać w nim błędy, dodawać nowe funkcje)? Chyba nie 🙂
“Darmowa aktualizacja”
Za OS też płacimy, ale nikt nie wymusza na nas tych opłat za nowsze wersje. Płacimy nie za nowsze wersje, ale np. za bezpieczeństwo naszego biznesu. W CS płacimy za nowsze wersje i oddzielnie za bezpieczeństwo (wsparcie producenta + firmy wdrożeniowej), które BARDZO CZĘSTO sprowadza się do starego stwierdzenia “Jeszcze nikogo nie wyrzucono z pracy za to, że kupił ORALCE” :).
Trochę się rozpisałem, ale można by jeszcze sporo napisać :). Na koniec: moim zdaniem główną zaletą OS jest to, że aplikacje mogą być dostarczane w modelu usługi, czyli zapewnienia gwarancji działania aplikacji dla klientów, czego w modelu CS nie ma.
Bardzo cenne uwagi, przyznam, że czytałem i przytakiwałem głową. Nasuwa się tu inna refleksja: na ile gotowe produkty, szczególnie te duże (potrzebujemy 1 funkcję z tysiąca) mają przewagę nad projektem dedykowanym wykonanym ba bazie dobranego frameworka i czy faktycznie mają przewagę?
@Jarek Żeliński
Oczywiście przypadków jest wiele. Np. trudno jest by firma zamówiła sobie kompletny ERM, po prostu będzie za drogo dla jednej firmy. W takich wypadkach lepiej zamówić modyfikację jakiegoś ERP OS. Będzie taniej i bezpieczniej finansowo niż CS. Jeśli potrzebujemy względnie mały produkt – np. web aplikację do rejestracji użytkowników, to zapewne lepiej będzie zamówić napisanie dedykowanej – oczywiście wraz z prawami autorskimi do kodu. W takim wypadku co zrobimy z kodem to nasza sprawa, chyba, że użyto np. framework OS z “infekcją” GPL wtedy staje się on OS. Decyzję podejmuje klient we współpracy z dostawcą do którego ma zaufanie i którego technologia mieści się w wizji i polityce klienta – np. używamy tylko MS Windows.
Podsumowując: współpraca dostawcy z klientem, jasność i świadomość wad, zalet, kosztów – to podstawy pracy z OS. Np. klient musi wiedzieć, że będzie go to kosztować 100 tyś mniej, ale kod będzie musiał być dostępny dla wszystkich. Nie ma co się oszukiwać, że OS nic nie kosztuje, ale może kosztować znacznie mniej niż CS i dać znacznie więcej. Są też klienci, którzy myślą kupię dobre, drogie CS i będę miał problem z głowy, a co z wdrożeniem, utrzymaniem, zmianami (biznes zmiennym jest :))? I licznik z wydatkami zaczyna coraz szybciej się kręcić.
CS to często vendorlock, teksty małym druczkiem w umowie, brak gwarancji. Dość często pojawia się też motyw: “nie da się w tym produkcie” – związany z brakiem budżetu po stronie dostawcy lub rzeczywistym poważnym ograniczeniem bazowego produktu.
Dodam, że OS coraz bardziej pasuje mi do podejścia agile w produkcji oprogramowania. I to agile bardzo extremalnie pojętego 🙂
Ja zaś dodam, że coraz częściej zaczynam widzieć korzyści z traktowania jakiegokolwiek “gotowego do użycia” programu bez względu czy to OS czy CS, ważne by była dobra dokumentacja i API. Wtedy pytam o cenę wdrożenia i np. 3 lat utrzymania, a te funkcjonalności, których nie mają gotowe produkty są wytwarzane niezależnie i integrowane przez API, tu ma znaczenie to czy gotowiec jest produktem totalnie zamkniętym czy na bazie jakiegoś możliwego do użycia frameworka (dostępny framework to lepiej nią samo API). Wtedy nawet jeśli dodane funkcje są “poufne” z uwagi na specyfikę pomysłu klienta, nie muszę ich upubliczniać.
Tak to ma sens, ale nadal brakuje gwarancji no to, że produkt zachowuje się zgodnie z dokumentacją do API i że nie natrafimy na błąd, który rozłoży całe nasze wdrożenie i zacznie się wstawianie “workaroundów”.
Dlatego model sprzedaży usług – np. obecny trend SaaS i pochodnych – uważam za właściwy kierunek z punktu widzenia korzyści dla klienta. Jest to odejście od sloganu handlowca: “widziały gały co brały” 🙂 Ten model łączy w jedno producenta i dostawcę. Mocno wiąże producenta z klientem i daje gwarancję w postaci umowy podpartej konkretną kasą. Moje ostatnie doświadczenia z SaaS są jak najbardziej pozytywne. Zgłaszałem błąd, szybkość i jakość reakcji na błąd rewelacyjna i wszystko via mail i na końcu przeprosimy, że tak długo trwało 🙂 A tak naprawdę produkt nie krytyczny i kasa nieduża 🙂 Oczywiście jest tu ryzyko vendor lock-in, dlatego sprawdziłem, czy jest API do migracji 🙂
Zastanawiam się, czy systemy ERP osiągną taki stan jak np. WordPress czy SugarCRM… możńa pobrać kod, można używać wersje hostowaną, można zapłacić za wsparcie i można grzebać w kodzie a jak ktoś mam swoje prywatne pomysły pisze własny plug-in… standardowe funkcje jako plug-in’y można znaleźć na rynku i w wersji płatnej i otwartej i licencjonowanej, a co ciekawe nikt przy zdrowych zmysłach nie kastomizuje wersji bazowej …
?Niezależność od usługodawcy?
Czy mogę zmienić Microsoft na inną firmę, która będzie supportować MS SQL (usuwać w nim błędy, dodawać nowe funkcje)? Chyba nie 🙂
Oczywiście że nie. Natomiast tu jest mowa o oprogramowaniu biznesowym, czyli możesz zmienić usługodawcę supportującego Microsoft Navision np. z firmy Solid Solution na Columbus (partnerzy, którzy mają możliwość customizacji NAV).
@mwi4wp
Jeśli chodzi o produkty Dynamics (jeszcze w starej wersji GP) to miałem z nimi styczność. Niby mają środowisko do budowania własnych interfejsów i jest ono dość elastyczne, ale kosztowne. Mimo to trzeba nieźle się nakombinować by zrobić proste dostosowywania – np. przeszkodą był amerykański sposób księgowania. Potem okazuje się, że niby transakcyjny produkt, w ogóle nie korzysta z transakcji SQL – bez dostępu do kodu nie można było tego stwierdzić bo dostawca o tym milczał. Co powodowało ciągłe kłopoty z danymi. Jedno z wdrożeń skończyło nieustannym grzebaniem na czuja (brak dokumentacji) w procedurach SQL. Szczęście całe, że procedury SQL nie są CS bo są niekompilowane 🙂 Taniej było wynająć zatrudnić na full etat jednego lub dwóch programistów niż wynajmować firmę. Czyli firmę przed wysokimi nieplanowymi kosztami uratowała OTWARTOŚĆ KODU procedur SQL.
Teraz zastanówmy się nad scenariuszem, gdyby się nie udało zatrudnić programisty, gdyby firma wykupiła support w innej firmie. Nie dość, że zapłaciła drogo za produkt i wdrożenie (wdrożenie nie było jakoś szczególnie drogie :)) to jeszcze potem musi płacić innej firmie za opiekę. Pomijając bardzo często przypadki naliczania opłat za support od kwoty wdrożenia procentowo, np. 1mln soft(500tyś) +wdrożenie (500tyś) = support rocznie 10% => 100tyś :); to po co płacić milion? Nie lepiej – w wariancie OS – zapłacić 500 tyś za wdrożenie i potem 50tyś rocznie za support 🙂
Oczywiście support może mieć różne oblicza: w razie awarii, rozwój, helpdesk itd. i w związku z tym może być różne rozliczany np. od zdarzenia lub wyceniany od funkcjonalności.
@jacek2v “Mimo to trzeba nieźle się nakombinować by zrobić proste dostosowywania” – z tego powodu jestem “wrogiem” dostosowań gotowych produktów, lepiej jest wybrać produkt mający standardowe funkcjonalności takie jak w wymaganiach (zrobić analizę gap/fit), zaś zamiast dostosować produkt bezpieczniej i taniej jest dopisać dedykowany moduł i zintegrować go. Zresztą takie podejście jest obecnie zalecane w metodologii Microsoft dla Dynamix AX (jest zbudowany na bazie frameworka MVC/.NET). To pozwala także na upgrade systemu bez niszczenia dokonanych kastomizacji…
@Jarek Żeliński
Kierunek dobry, ale … 🙂 jest ryzyko, że wejdzie się w zbyt duży poziom skomplikowania. Co do technologii MS (.NET i frameworki) to mam wrażenie, że MS się w tym zgubił i zbyt skomplikował w miarę proste rzeczy. Zbyt dużo warstw pośrednich co utrudnia programowanie, naprawianie błędów, debugowanie itd. Nie wiem jak to teraz jest w AX, ale jestem lekko przerażony na myśl jak takim kodem będącym nadbudową .NET, da się zarządzać, jak debugować… Same .NET sprawia często problemy.
Co będzie jak natrafimy na błąd i MS się na niego wypnie i powie : in next version. Ok, można kupić Software Assurance, ale czy to nie jest umowa na usługę, a nie kupno softu :)? Summa summarum, czy to nie za drogo, płacić za soft i za SA? Może lepiej zapłacić tylko za usługę :)?
Te podejście przypomniało mi, że kiedyś (10-15 lat temu) był trend na repozytoria obiektów, re-używalność i takie tam :). W MS na biznesowe obiekty COM. Dlaczego się nie przyjęło? Moim zdaniem zbyt duża ilość warstw, zbyt duża ilość narzędzi, zbyt daleko od debugera i kodu źródłowego do obiektu biznesowego i wymagań.
Trzeba pamiętać o dwóch sprawach:
1. Firma nawet tak wielka jak MS nie zagwarantuje, że naprawi każdy błąd (nawet jak będzie chciała) jeśli programista w niej pracujący nie będzie tego potrafił.
2. Liczba programistów nie zapewnia, że będą dobrzy w swym fachu.
Podsumowując: Moim zdaniem jakość produktowi zapewni technologia jak najprostsza i najłatwiejsza do zrozumienia, z najmniejszą ilością warstw pośrednich.
PS: Sorry, że trochę pojechałem w bok od tematu 🙂
Microsoft przytoczyłem jako przykład, inni producenci relatywnie złożonego oprogramowania postępują podobnie. Obserwuję trend zmierzający w stronę stosowania frameworków opartych na wzorcu MVC lub jego odmianach. Raz jest to tylko framework a raz kompletny system ERP stworzony na bazie jakiegoś frameworka. Co do stopnia komplikacji to uniwersalny, łatwy do rozbudowy system nie może mieć prostej architektury, wystarczy popatrzeć na typowe wzorce projektowe…
Ja bym jeszcze dodał, że Dynamics został przeze mnie przywołany ze względu na odwołanie do Microsoftu. W praktyce chodziło mi o dowolny system w którym wdrożeniowcem jest nie producent, tylko autoryzowana firma. Chodzi o to, że procedury jądra mogą być w pewien sposób swobodny sklejane w pożądaną aplikację a w zależności od poziomu autoryzacji można sięgać głębiej do funkcjonalności programu. I tak jak mówisz (to już do Jarka) – im mniej trzeba modyfikować oprogramowanie by osiągnąć oczekiwany rezultat tym lepiej.
@Jarek Żeliński
Co do wzorców, to uważam, że wręcz przeciwnie 🙂 Wzorce są proste (nie znaczy, że są zawsze łatwe do zrozumienia :)), a jak pojawi się jakiś bardziej skomplikowany, to idzie do kosza, poprzez “nieużywanie” :). Łatwy test: weźmy np. listę wzorców z wikipedii http://pl.wikipedia.org/wiki/Wzorzec_projektowy_(informatyka) i zapytajmy siebie lub jakiegoś programistę aplikacji biznesowych z ilu wzorców z tej listy świadomie korzysta – nie tylko używa bo jest użyty w API i nie ma wyjścia 🙂 Stawiam, że ze 4-5, reszta nieznana i nieużywana lub używana przez specyficzne grupy, np. programistów systemowych.
PS: Chyba skończyła się możliwość odpowiadania na post :)?
Co do wzorców racja :), co do odpowiadania…. hm… nie wiem, może trzeba na końcu znowu napisać… 😉
@Jarek Żeliński i @mwi4wp
Żeby jakoś tak podsumować swoje stanowisko :), przyszła mi do głowy myśl, że tak naprawdę problem tkwi – oprócz braku gwarancji producenta frameworku (nazwijmy go) biznesowego – w efekcie skali.
Jeśli framework biznesowy posiada duże i skomplikowane API to łatwiej i szybciej (taniej) często będzie stworzyć coś nowego “na boku”. W przypadku OS, “doklejenie” tego “na boku” w “niestandardowy” sposób (brak API) jest łatwiejsze i szybsze (tańsze). W CS musi zostać “na boku” i albo trzeba z tym żyć, albo czekać na upgrade 🙂
Mówiąc krótko liczy się koszt pracy analityka, programisty, testera i wdrożeniowca. Czym zajmuje to im mniej pracy, stawka jest niższa i przejście pomiędzy nimi jest bardziej gładkie (np. poprzez próby wprowadzenia UML do analizy) – tym szybciej, lepiej i taniej.
Pozostaje tylko rozwaga, czy tanie i szybkie metody dodania czegoś nowego dadzą tanie wprowadzanie przyszłych zmian…
Warto mieć świadomość, że:
White Source says that 85% of all software projects loaded to its lifecycle management service by new customers had some out-of-date open source components. The firm says that in response to this it proactively alerts whenever new versions are available, patching bugs and security issues. Altogether, 14% of all libraries in use are out of date.
(źr.