Dlaczego Open Source to zło?
Zagrożenia przy stosowaniu technologiiOpen Source w projektach komercyjnych
Tomasz WesołowskiEmpathy Interactive
www.empathy.pl
O czym NIE będę mówił
O systemach operacyjnych Open SourceO serwerach baz danych, WWW i innychO programach „pudełkowych” Open Source(ale z drobnym wyjątkiem – na końcu :)
O technicznych aspektach rozwiązań Open SourceO 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
Empathy InteractiveInternet Software House
www.empathy.pl
Łączymy kompetencje firmy tworzącej dedykowane aplikacje internetowe oraz agencji interaktywnej.
2000rok założenia
20 osóbzatrudnienie
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
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.
Początki
(z przymrużeniem oka ;)
www.empathy.pl
Typowy projekt Open Source
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.
Problemy
www.empathy.pl
Typowy projekt Open Source
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.
Sukces
www.empathy.pl
Typowy projekt Open Source
Projekt zaczyna cierpieć z powodu braku organizacji i czynione są próby jego formalizacji.
Często powstaje fundacja mająca na celu finansowanie :)
Problemy
www.empathy.pl
Typowy projekt Open Source
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.
Co dalej
www.empathy.pl
Typowy projekt Open Source
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
Następnie
www.empathy.pl
Typowy projekt Open Source
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.
Na koniec
www.empathy.pl
Słowo o licencjach Open Source
BSD ( np. FreeBSD, NetBSD, OpenBSD)
MIT (Massachusetts Institute of Technology)
Apache (Apache Software Fundation)
PHP (PHP i część projektów opartych na PHP)
Microsoft Public License
GNU GPLoprogramowanie wykorzystujące kod na licencji GNU GPL musi także być wydane na licencji GNU GPL
GNU LGPLumożliwia wykorzystywanie w innych projektach jako biblioteki
MPL (Mozilla Public License) mniej restrykcyjna niż licencje GNU
Licencje restrykcyjne
Licencje liberalne
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 projektuocena wiarygodności
analiza możliwości projektu względem naszych wymagańanalizy architektury rozwiązania
analiza jakości koduanaliza kompatybilności wstecznej
analizy jakości dokumentacji oraz jej kompletnościanalizy 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 aplikacjikonieczność 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ń KlientaDopisanie 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
oraz dostosowania modułów stworzonych na potrzeby wdrożenia
Każdorazowa aktualizacja wymaga gruntownego testowania całości
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
Projekty Open Source posiadają inne cele niż projekty komercyjne:
Cele
Zysk
Jakość (odpowiedzialność)
Stabilność
Systematyczny rozwój
Idee
Technologie
Poznawanie ludzi
Open Source Projekty komercyjne
www.empathy.pl
Biznesowe aspekty Open Source
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.
Rozwój
www.empathy.pl
Biznesowe aspekty Open Source
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.
Wsparcie
www.empathy.pl
Biznesowe aspekty Open Source
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.
Security
www.empathy.pl
Z życia wzięte
Rok 2000 – powstaje komercyjny CMS MamboRok 2001 – wprowadzenie podwójnego licencjonowaniakod 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 :)
Czy Microsoft ma rację? ;)
Open Source„niższy koszt wdrożenia, wyższy koszt utrzymania”
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
Pytania?