Rozwój oprogramowania open-source

Tworzenie oprogramowania typu open source (OSSD) to proces, w ramach którego oprogramowanie typu open source lub podobne oprogramowanie, którego kod źródłowy jest publicznie dostępny, jest opracowywane w ramach projektu oprogramowania typu open source . Są to produkty oprogramowania dostępne z kodem źródłowym na licencji open source do badania, zmiany i ulepszania jego projektu. Przykłady niektórych popularnych produktów oprogramowania typu open source to Mozilla Firefox , Google Chromium , Android , LibreOffice i odtwarzacz multimedialny VLC .

Historia

W 1997 roku Eric S. Raymond napisał „Katedrę i bazar”. . W tej książce Raymond rozróżnia dwa rodzaje tworzenia oprogramowania. Pierwszym z nich jest konwencjonalne tworzenie oprogramowania o zamkniętym kodzie źródłowym. Według Raymonda taka metoda rozwoju przypomina budowę katedry; centralne planowanie, ścisła organizacja i jeden proces od początku do końca. Drugi to postępujący rozwój open source, który bardziej przypomina „wielki bełkotliwy bazar różnych programów i podejść, z którego spójny i stabilny system mógł pozornie wyłonić się tylko dzięki serii cudów”. Ta ostatnia analogia wskazuje na dyskusję związaną z procesem rozwoju open source.

Według Bara i Fogela różnice między tymi dwoma stylami programowania dotyczą ogólnie obsługi (i tworzenia) raportów o błędach i próśb o nowe funkcje oraz ograniczeń, w ramach których pracują programiści. Podczas tworzenia oprogramowania o zamkniętym kodzie źródłowym programiści często spędzają dużo czasu zajmując się tworzeniem raportów o błędach, a także obsługą próśb o nowe funkcje. Ten czas poświęcamy na tworzenie i ustalanie priorytetów dalszych planów rozwojowych. Prowadzi to do tego, że część zespołu programistów spędza dużo czasu na tych kwestiach, a nie na samym rozwoju. Ponadto w projektach o zamkniętym kodzie źródłowym zespoły programistów muszą często pracować pod ograniczeniami związanymi z zarządzaniem (takimi jak terminy, budżety itp.), które kolidują z kwestiami technicznymi oprogramowania. W przypadku tworzenia oprogramowania typu open source problemy te rozwiązuje się poprzez włączenie użytkowników oprogramowania w proces tworzenia oprogramowania lub nawet pozwolenie tym użytkownikom na samodzielne zbudowanie systemu. [ potrzebne źródło ]

Model

Model danych procesowych do tworzenia oprogramowania typu open source

Rozwój oprogramowania open source można podzielić na kilka faz. Określone tutaj fazy pochodzą z Sharma i in . Diagram przedstawiający strukturę danych procesowych tworzenia oprogramowania open source jest pokazany po prawej stronie. Na tym obrazku przedstawiono fazy rozwoju oprogramowania typu open source wraz z odpowiadającymi im elementami danych. Ten diagram jest tworzony przy użyciu metamodelowania i modelowania metaprocesów .

Rozpoczęcie projektu open source

Istnieje kilka sposobów rozpoczęcia pracy nad projektem open source:

  1. Osoba, która wyczuwa potrzebę projektu, publicznie ogłasza zamiar opracowania projektu.
  2. Deweloper pracujący na ograniczonej, ale działającej bazie kodu udostępnia ją publicznie jako pierwszą wersję programu typu open source.
  3. Kod źródłowy dojrzałego projektu jest udostępniany publicznie.
  4. Dobrze ugruntowany projekt open source może zostać rozwidlony przez zainteresowaną stronę zewnętrzną.

Eric Raymond zauważył w swoim eseju The Cathedral and the Bazaar , że ogłoszenie zamiaru projektu jest zwykle gorsze od upublicznienia działającego projektu.

Częstym błędem jest rozpoczynanie projektu, gdy wkład w istniejący podobny projekt byłby bardziej efektywny ( zespół NIH ) [ potrzebne źródło ] . Aby rozpocząć udany projekt, bardzo ważne jest zbadanie tego, co już istnieje. Proces rozpoczyna się od wyboru między przyjęciem istniejącego projektu a rozpoczęciem nowego. Jeśli rozpoczyna się nowy projekt, proces przechodzi do fazy inicjacji. W przypadku przyjęcia istniejącego projektu proces przechodzi bezpośrednio do fazy realizacji. [ oryginalne badania? ]

Rodzaje projektów open-source

Istnieje kilka rodzajów projektów open source. Po pierwsze, istnieje ogromna różnorodność programów i bibliotek, które składają się z samodzielnych fragmentów kodu. Niektóre mogą nawet być zależne od innych projektów open source. Projekty te służą określonemu celowi i zaspokajają określoną potrzebę. Przykładami tego typu projektów są jądro Linuksa , przeglądarka internetowa Firefox i pakiet narzędzi biurowych LibreOffice.

Dystrybucje to kolejny rodzaj projektów typu open source. Dystrybucje to kolekcje oprogramowania, które są publikowane z tego samego źródła i mają wspólny cel. Najbardziej widocznym przykładem „dystrybucji” jest system operacyjny. Istnieje wiele Linuksa (takich jak Debian , Fedora Core , Mandriva , Slackware , Ubuntu itp.), które dostarczają jądro Linuksa wraz z wieloma komponentami użytkownika. Istnieją inne dystrybucje, takie jak ActivePerl , język programowania Perl dla różnych systemów operacyjnych oraz dystrybucje Cygwin programów open source dla Microsoft Windows .

Inne projekty open source, takie jak pochodne BSD , utrzymują kod źródłowy całego systemu operacyjnego, jądro i wszystkie jego podstawowe komponenty, w jednym systemie kontroli wersji ; rozwijanie całego systemu razem jako jeden zespół. Te projekty rozwoju systemów operacyjnych ściśle integrują swoje narzędzia, bardziej niż w przypadku innych systemów opartych na dystrybucji.

Wreszcie istnieje projekt książki lub samodzielnego dokumentu. Te elementy zwykle nie są dostarczane jako część pakietu oprogramowania typu open source. Linux Documentation Project obsługuje wiele takich projektów, które dokumentują różne aspekty systemu operacyjnego Linux. Istnieje wiele innych przykładów tego typu projektów open source.

Metody

Trudno jest prowadzić projekt open source zgodnie z bardziej tradycyjną metodą tworzenia oprogramowania, taką jak model kaskadowy , ponieważ w tych tradycyjnych metodach nie można cofnąć się do poprzedniej fazy. W przypadku tworzenia oprogramowania typu open source wymagania rzadko są zbierane przed rozpoczęciem projektu; zamiast tego są oparte na wczesnych wersjach oprogramowania, jak opisuje Robbins. Poza wymaganiami często przyciągany jest personel-wolontariusz, który pomaga w opracowaniu oprogramowania w oparciu o wczesne wersje oprogramowania. Ten efekt sieciowania jest niezbędny według Abrahamssona i in.: „jeśli wprowadzony prototyp zbierze wystarczającą uwagę, stopniowo zacznie przyciągać coraz więcej programistów”. Jednak Abrahamsson i in. zwracają również uwagę, że społeczność jest bardzo surowa, podobnie jak biznesowy świat oprogramowania o zamkniętym kodzie źródłowym: „jeśli znajdziesz klientów, przeżyjesz, ale bez klientów umrzesz”.

Fuggetta argumentuje, że „szybkie prototypowanie, rozwój przyrostowy i ewolucyjny, spiralny cykl życia, szybki rozwój aplikacji, a ostatnio programowanie ekstremalne i zwinny proces tworzenia oprogramowania można w równym stopniu zastosować do oprogramowania własnościowego i otwartego”. Wskazuje również programowanie ekstremalne jako niezwykle przydatną metodę tworzenia oprogramowania open source. Mówiąc bardziej ogólnie, wszystkie programowania Agile mają zastosowanie do tworzenia oprogramowania open source, ze względu na ich iteracyjny i przyrostowy charakter. Inne metody Agile są równie przydatne zarówno do tworzenia oprogramowania open source, jak i zamkniętego: Internet-Speed ​​Development nadaje się do tworzenia oprogramowania open source ze względu na przyjętą zasadę rozwoju rozproszonego. Internet-Speed ​​Development wykorzystuje rozproszone geograficznie zespoły do ​​„pracy przez całą dobę”. Ta metoda, stosowana głównie przez duże firmy open source (ponieważ tylko one mogą sobie pozwolić na centra rozwojowe w różnych strefach czasowych), sprawdza się równie dobrze w projektach open source, ponieważ oprogramowanie tworzone przez dużą grupę ochotników w naturalny sposób mieć programistów rozproszonych we wszystkich strefach czasowych.

Narzędzia

Kanały komunikacji

Deweloperzy i użytkownicy projektu open source niekoniecznie pracują nad projektem w pobliżu. Wymagają pewnych elektronicznych środków komunikacji. Poczta elektroniczna jest jedną z najpopularniejszych form komunikacji wśród programistów i użytkowników open source. Często elektroniczne listy mailingowe są używane, aby upewnić się, że wiadomości e-mail są dostarczane jednocześnie do wszystkich zainteresowanych stron. Gwarantuje to, że przynajmniej jeden z członków będzie mógł na nie odpowiedzieć. Aby komunikować się w czasie rzeczywistym, wiele projektów korzysta z komunikatorów internetowych, takich jak IRC . Fora internetowe stały się ostatnio powszechnym sposobem uzyskiwania przez użytkowników pomocy w przypadku problemów napotykanych podczas korzystania z produktu typu open source. Wiki stały się powszechnym środkiem komunikacji dla programistów i użytkowników.

Systemy kontroli wersji

Podczas opracowywania OSS uczestnicy, którzy w większości są wolontariuszami, są rozmieszczeni w różnych regionach geograficznych, dlatego potrzebne są narzędzia pomagające uczestnikom współpracować przy opracowywaniu kodu źródłowego.

Na początku XXI wieku Concurrent Versions System (CVS) był wybitnym przykładem narzędzia do współpracy przy kodzie źródłowym używanego w projektach OSS. CVS pomaga zarządzać plikami i kodami projektu, gdy kilka osób pracuje nad projektem w tym samym czasie. CVS pozwala kilku osobom pracować nad tym samym plikiem w tym samym czasie. Odbywa się to poprzez przeniesienie pliku do katalogów użytkowników, a następnie scalanie plików, gdy użytkownicy skończą. CVS umożliwia również łatwe odzyskanie poprzedniej wersji pliku. W połowie 2000 roku system kontroli wersji Subversion (SVN) został stworzony w celu zastąpienia CVS. Szybko zyskuje popularność jako system kontroli wersji projektów OSS.

Wiele projektów open source korzysta obecnie z rozproszonych systemów kontroli wersji, które skalują się lepiej niż scentralizowane repozytoria, takie jak SVN i CVS. Popularnymi przykładami są git , używany przez jądro Linuksa i Mercurial , używany przez język programowania Python . [ potrzebne źródło ]

Śledzenie błędów i listy zadań

Większość projektów na dużą skalę wymaga systemu śledzenia błędów, aby śledzić stan różnych problemów w rozwoju projektu.

Narzędzia do testowania i debugowania

Ponieważ projekty OSS są często integrowane, wykorzystywane są narzędzia pomagające zautomatyzować testowanie podczas integracji systemu. Przykładem takiego narzędzia jest Tinderbox. Tinderbox umożliwia uczestnikom projektu OSS wykrywanie błędów podczas integracji systemu. Tinderbox prowadzi ciągły proces kompilacji i informuje użytkowników o częściach kodu źródłowego, w których występują problemy, oraz o platformach, na których te problemy występują.

Debuger to program komputerowy używany do debugowania (a czasem testowania lub optymalizowania) innych programów . GNU Debugger (GDB) to przykład debuggera używanego w tworzeniu oprogramowania typu open source. Ten debugger oferuje zdalne debugowanie, co czyni go szczególnie przydatnym do tworzenia oprogramowania open source. [ potrzebne źródło ]

Narzędzie do wycieku pamięci lub debugger pamięci to narzędzie programistyczne do wyszukiwania wycieków pamięci i przepełnień bufora . Wyciek pamięci to szczególny rodzaj niepotrzebnego zużycia pamięci przez program komputerowy, w którym program nie zwalnia pamięci, która nie jest już potrzebna. Przykładami narzędzi do wykrywania wycieków pamięci używanych przez Mozillę są XPCOM Memory Leak. Narzędzia do sprawdzania poprawności służą do sprawdzania, czy fragmenty kodu są zgodne z określoną składnią. Przykładem narzędzia sprawdzania poprawności jest Splint . [ potrzebne źródło ]

Zarządzanie pakietami

System zarządzania pakietami to zbiór narzędzi do automatyzacji procesu instalowania, aktualizowania, konfigurowania i usuwania pakietów oprogramowania z komputera. Menedżer pakietów Red Hat (RPM) dla .rpm i Advanced Packaging Tool (APT) dla formatu plików .deb to systemy zarządzania pakietami używane przez wiele dystrybucji Linuksa. [ potrzebne źródło ]

Publikowanie projektu

Katalogi oprogramowania i dzienniki wydań:

  1. wolnego oprogramowania

Artykuły:

  1. Cotygodniowe wiadomości o Linuksie
  2. IBM DeveloperWorks

Zobacz też

Linki zewnętrzne