Dlaczego Open Source to zło?
Zagrożenia przy stosowaniu technologii
Open Source w projektach komercyjnych
Tomasz Wesołowski
Empathy Interactive

O czym NIE będę mówił
O systemach operacyjnych Open Source
O serwerach baz danych, WWW i innych
O programach „pudełkowych” Open Source
(ale z drobnym wyjątkiem – na końcu :)
O technicznych aspektach rozwiązań Open Source
O komercyjnych projektach, które publikują kod
na licencji Open Source
www.empathy.pl

O czym w takim razie będę mówił?
O wdrażaniu aplikacji opartych na rozwiązaniach
Open Source w projektach komercyjnych
O ryzyku związanym z niezrozumieniem licencji
O utrzymywaniu aplikacji opartych na OS
O biznesowych aspektach rozwiązań Open Source
www.empathy.pl

Empathy Interactive
Internet Software House
Łączymy kompetencje firmy tworzącej
2000 dedykowane aplikacje internetowe oraz agencji
interaktywnej.
rok założenia
20 osób
zatrudnienie
www.empathy.pl

Filary projektów Open Source
 Ludzie posiadający duuużo wolnego czasu
 Dobrowolność udziału w projekcie
 Brak szczegółowych wymagań dla uczestników
Bo liczą się dobre chęci, a nie wiedza i doświadczenie
 Praca bez wynagrodzenia po szkole lub pracy
 Praca zdalna
W różnych strefach czasowych/kulturowych/językowych
 Niesformalizowany rozwój
Duży wpływ jednostek na kierunki rozwoju projektu
 Brak odpowiedzialności
Developerzy nie ponoszą odpowiedzialności za swój kod
www.empathy.pl

Typowy projekt Open Source
(z przymrużeniem oka ;)
Początki Programista ma pomysł na fajny program
…oraz bliżej nie określonych znajomych „z Internetu”
pomagających mu dobrowolnie w wolnych chwilach przy
rozwoju projektu.
www.empathy.pl

Typowy projekt Open Source
Problemy Brak kierownika projektów, decyzje istotne dla projektu
podejmowane są w trybie „bo tak” lub kolektywnie przez
wszystkich uczestników projektu „przez głosowanie”, słabe
zarządzanie projektem.
www.empathy.pl

Typowy projekt Open Source
Sukces Projekt zyskuje na popularności, pojawia się coraz więcej
użytkowników i chętnych do pomocy.
Projekt z małego przeradza się w duży.
www.empathy.pl

Typowy projekt Open Source
Problemy Projekt zaczyna cierpieć z powodu braku organizacji i
czynione są próby jego formalizacji.
Często powstaje fundacja mająca na celu finansowanie :)
www.empathy.pl

Typowy projekt Open Source
Co dalej Fundacja finansuje działalność ze sprzedaży koszulek ;)
(i/lub udzielania wsparcia użytkownikom)
Zespół programistów w większości nadal pracuje za darmo.
www.empathy.pl

Typowy projekt Open Source
Następnie Może pojawić się konflikt w zespole.
Ryzyko związane z porzuceniem projektu przez developerów.
Pojawiają się rozbieżności co do dalszego kierunku rozwoju
www.empathy.pl

Typowy projekt Open Source
Na koniec Architektura „zaplanowana” dla niewielkiego projektu
zaczyna stanowić poważny problem w dalszym rozwoju
systemu.
Rozwiązanie problemów z architekturą wymaga modyfikacji
architektury co często prowadzi do braku kompatybilności
wstecznej.
www.empathy.pl

Słowo o licencjach Open Source
Licencje restrykcyjne Licencje liberalne
 GNU GPL  BSD
oprogramowanie wykorzystujące kod na ( np. FreeBSD, NetBSD, OpenBSD)
licencji GNU GPL musi także być wydane na  MIT
licencji GNU GPL
(Massachusetts Institute of Technology)
 Apache
 GNU LGPL
(Apache Software Fundation)
umożliwia wykorzystywanie w innych
 PHP
projektach jako biblioteki
(PHP i część projektów opartych na PHP)
 MPL (Mozilla Public License)
mniej restrykcyjna niż licencje GNU  Microsoft Public License
www.empathy.pl

Komercyjne wdrożenia
„Darowanemu koniowi nie patrzy się w zęby”
Ale w przypadku komercyjnych wdrożeń trzeba zajrzeć :)
www.empathy.pl

Wdrożenie rozwiązania OS
Wybór odpowiedniego rozwiązania - wymaga czasochłonnych analiz
analiza licencjonowania projektu
ocena wiarygodności
analiza możliwości projektu względem naszych wymagań
analizy architektury rozwiązania
analiza jakości kodu
analiza kompatybilności wstecznej
analizy jakości dokumentacji oraz jej kompletności
analizy stabilności projektu (cykl, wersje rozwojowe, stabilne, itd.)
www.empathy.pl

Wdrożenie rozwiązania OS
Wdrożenie agencji interaktywnej w projekt OS - wymaga dużo czasu
konieczność zrozumienia architektury aplikacji
konieczność nabycia doświadczenia w pracy z projektem OS
…a może zatrudnić developerów tworzących dany projekt?
To właściwie wymusza nam pracę w systemie zdalnym, co nie jest
najszczęśliwszym rozwiązaniem, dodatkowo rodzi problemy
związane z poufnością projektu
www.empathy.pl

Wdrożenie rozwiązania OS
Dopiero po rozwiązaniu tych problemów możemy przystąpić do pracy
Modyfikacja rozwiązania Open Source do wymagań Klienta
Dopisanie modułów wg wymagań Klienta
Testy zmodyfikowanego rozwiązania
(a może okazać się, że jest już nowa wersja projektu, która wymagać będzie
ponownych prac programistycznych i testów)
www.empathy.pl

Utrzymanie projektu
Nie tak prosto (i tanio :)
Nieznane ryzyko występowania błędów
Konieczność częstej aktualizacji
Każdorazowa aktualizacja wymaga gruntownego testowania całości
oraz dostosowania modułów stworzonych na potrzeby wdrożenia
Szereg ryzyk związanych z projektem (fork projektu, porzucenie)
Konieczność udostępnienia całości kodu w przypadku licencji GPL
www.empathy.pl

Biznesowe aspekty Open Source
Cele Projekty Open Source posiadają inne cele niż
projekty komercyjne:
Open Source Projekty komercyjne
 Idee  Zysk
 Technologie  Jakość (odpowiedzialność)
 Poznawanie ludzi  Stabilność
 Systematyczny rozwój
www.empathy.pl

Biznesowe aspekty Open Source
Rozwój Brak kontroli nad projektem, kierunkiem rozwoju
oraz sposobem zarządzania, a także nad kodem
źródłowym.
Brak strategii biznesowej projektu OS – bliżej
nieokreślone kierunki rozwoju projektu.
www.empathy.pl

Biznesowe aspekty Open Source
Wsparcie Brak gwarancji projektu OS – konieczność
świadczenia gwarancji na cudzy kod.
Brak wiarygodnego i szybkiego wsparcia projektu.
Brak dochodów projektu OS zwiększa ryzyko
braku stabilności projektu.
www.empathy.pl

Biznesowe aspekty Open Source
Security Potencjalne ryzyko naruszenia cudzych patentów
oraz praw autorskich – ze względu na brak
jakiegokolwiek wpływu na zespół projektu OS i
brak gwarancji prawnych (uczestnicy projektu
naruszając prawo narażają cały zespół).
Potencjalne ryzyko celowego wstrzyknięcia błędu
bezpieczeństwa do kodu projektu OS przez
„podstawionego” developera OS.
www.empathy.pl

Z życia wzięte
Rok 2000 – powstaje komercyjny CMS Mambo
Rok 2001 – wprowadzenie podwójnego licencjonowania
kod na licencji GNU GPL – dalszy rozwój przez społeczność
Mambo zdobywa dużą popularność i wiele prestiżowych
nagród środowiska Open Source – m.in. „Best Free
Software Project of the Year”, „ Best Open Source
Solution”
Rok 2005 – konflikt wśród developerów– powstaje fork
projektu pod nazwą Joomla!
Rok 2008 – Joomla w wersji 1.5 – brak kompatybilności
wstecznej zarówno pod względem contentu, jak i wtyczek do
Joomla, większość wtyczek wymaga przepisania
www.empathy.pl

Na koniec - do dyskusji przy piwie :)
Open Source
„niższy koszt wdrożenia, wyższy koszt utrzymania”
Czy Microsoft ma rację? ;)
Mozilla Firefox - fakty i mity o security
(na podstawie raportu firmy Secunia)
W 2008 roku wykryto w Mozilla Firefox dwa razy więcej
błędów bezpieczeństwa niż w IE i Safari razem wziętymi
Błędy w Firefox były szybciej usuwane niż w IE, jednakże
dużo istotniejsza jest ilość błędów – przeglądarka jest
podatna na błąd od momentu jego wystąpienia w kodzie
www.empathy.pl

Pytania?
t.wesolowski@empathy.pl
www.empathy.pl