Your SlideShare is downloading. ×
0
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

"Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski, KrakSpot#4

2,642

Published on

Prezentacja z czwartej edycji KrakSpota. "Dlaczego open-source to zło? Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski

Prezentacja z czwartej edycji KrakSpota. "Dlaczego open-source to zło? Zagrożenia w stosowaniu technologii open-source w projektach komercyjnych" - Tomasz Wesołowski

Published in: Technology
3 Comments
0 Likes
Statistics
Notes
  • W 100% zgadzam sie z autorem.
    Przykładów na fatalną jakość projektów Open Source są tysiące.
    Tu wspomniano o Mambo/Joomla, które oprócz tego,
    że ich jakość pozostawia bardzo wiele do życzenia (tzw. kod spaghetti), to psują rynek. Grono osób związanych 'odgórnie' z wspomnianym projektem wręcz domaga się od wielu organizacji (także rządowych) finansowych dotacji, argumentując to koniecznością pozyskania funduszy na rozwój projektu, którego te organizacje również używają.
    Ostatecznie za finansowanie tego typu wynalazków płaci często podatnik i tracą firmy, które poprzez zdrową, naturalna konkurencję na rynku, oferują lepsze, komercyjne rozwiązania, zarabiając na tym i dając pracę.
    Abstrahując od Mambo/Joomla warto zwrócić uwagę również na te bardziej zaawansowane rozwiązania OS.
    Dla przykładu proponuję prześledzić oficjalne repozytorium dla języka PHP - PEAR.
    Kilkanaście procent kodu tam prezentowanego po prostu nie działa. Przykładowo - klasa wspomagająca budowanie webserwisów uraczy nas błędem braku odpowiedniego pliku w paczce.
    Co zatem z teorią, że wolne oprogramowanie śledzą miliony par oczu i wyłapują błędy? PHP wg statystyk obsługuje 40% domen!
    Ilu to będzie programistów? 100 milionów? 500 milionów?
    Nikt nie widzi tak fundamentalnych błedów na oficjalnym repo?
    Jescze inna kwestia związana z OS jest taka, że dobrze jest, gdy student wchodzący na rynek pracy ma już jakieś portfolio. Biorąc udział przy projekcie Open Source w czasie studiów, będzie miał lepszy start na rynku pracy.
    Ale współtworząc projekt OS na studiach, jego kompetencje często są jeszcze dość niskie.

    Naprawdę warto się zastanowić, czy utrzymując się z wykonywania zawodu związanego tworzeniem oprogramowania warto wspierać tych wśród nas, którzy w celu zrealizowania sobie znanych celów, zmniejszają popyt na nasze usługi, zalewając rynek darmowymi i kiepskimi odpowiednikami, bądź nawet podróbkami.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Piękny, książkowy przykład FUD`u :)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • No niestety, zgoda z przedmówcą. Szkoda więcej gadać, zresztą - 'Microsoft Certified Partner' - w tym przypadku nie oznacza chyba profesjonalizmu.
    Choć aby oddać sprawiedliwość, część zarzutów może być słusznych i nadawać się do dyskusji, ale na zupełnie innym poziomie.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total Views
2,642
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
3
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Dlaczego Open Source to zło? Zagrożenia przy stosowaniu technologii Open Source w projektach komercyjnych Tomasz Wesołowski Empathy Interactive
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. Komercyjne wdrożenia „Darowanemu koniowi nie patrzy się w zęby” Ale w przypadku komercyjnych wdrożeń trzeba zajrzeć :) www.empathy.pl
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. Pytania? t.wesolowski@empathy.pl www.empathy.pl

×