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?

t.wesolowski@empathy.plwww.empathy.pl