Powiedzmy to sobie wprost


Spis treści


Czy “wojny przeglądarek” się już nie skończyły? Czy Mozilla odciśnie swe piętno na Internecie?

Internet, cyfrowa wspólnota ziemska, znaczy coraz więcej w naszym życiu. To dzięki źródłom jego żywotności i szerokiego stosowaniaotwartemu rozwojowi, otwartym standardom i oprogramowaniu o otwartym źródle powstała światowa sieć, a także inne uniwersalne systemy, takie jak globalne adresowanie i dostarczanie poczty elektronicznej.

Pozostając w tym duchu, kod Mozilli 1.0 i narzędzia programistyczne dostarczają programistom zasobów, które potrzebują by dowolnie tworzyć i prezentować ich dane i informacje na stronach www.

Celem projektu Mozilla jest stworzyć i rozwijać zgodną ze standardami technologię kliencką. Jako że coraz więcej programistów i firm określa Mozillę jako technologię strategiczną, Mozilla 1.0 będzie wspierać dalsze popularyzowanie i stosowanie zgodnego ze standardami oprogramowania o otwartym źródle w Internecie, w ten sposób zwiększając swą żywotność.

Dlaczego tak długo trwało tworzenie Mozilli 1.0?

Na początku dramatycznie zmienił się zakres projektu. Początkowo miała to być aktualizacja z linii Netscape Communicator 4.x do proponowanej linii 5.x. Jednakże, po uruchomieniu projektu stało się jasne, że wiele z jego celów nie może zostać zrealizowane przy użyciu instniejącego podstawowego kodu źródłowego.

Podjęta została decyzja o zresetowaniu projektu Mozilla i rozpoczęcia tworzenia kodu od nowa. Decyzja ta rozszerzyła zakres projektu w olbrzymim stopniu.

Po drugnie, nie wszystkie zmiany projektu w nowym kodzie wprowadzono od razu. Proces rozwoju projektu okazał się być podobnym do przebudowy domu: bez planów ogólnych, dużo szczegółów przed rozpoczęciem... W rzeczywistości jednak jest to mało prawdopodobne.

Ostatecznie, mimo że jest to wydanie 1.0, nie byłoby ono oceniane ogólnie wg standardów dotyczących pierwszych wydań produktów. Zamiast tego, Mozilla 1.0 będzie porównywana z najnowszymi generacjami przeglądarek komercyjnych. Przepracowaliśmy więc odpowiednio wiele czasu, by upewnić się, że to wydanie trafi w swój czas.

Kiedy użytkownik doświadczy czegoś naprawdę innowacyjnego?

W przypadku Mozilli 1.0, zarówno pod względem funkcjonalności jak i interfejsu użytkownika, nacisk położono na to, by pozwolić Netscape na stworzenie solidnego zamiennika dla serii Netscape Communicator 4.x. Zaszło jednakże wiele gruntownych zmian, które wyraźnie dotyczą dalszej ewolucji funkcjonalności z punktu widzenia użytkownika, i to przygotowało Mozillę do ekscytującego i szybkiego rozwoju w przyszłości:

Rozważmy dla przykładu, przeglądanie w panelach. H. J. van Rantwijk zastosował tą technikę w innej przeglądarce. W zeszłym rok wraz z przyjaciółmi zastosował XUL do stworzenia Multizilli. David Hyatt zobaczył to w działaniu i szybko utworzył nowy widget XUL natywnie implementujący podstawowe techniki przeglądania w panelach. Są one teraz standardową częścią zbioru możliwości Mozilli, a prace nad bardziej zaawansowaną Multizillą wciąż trwają.

Projekt Mozilla i społeczność skupionych wokół niego programistów pracują razem nad tworzeniem stale ulepszanego produktu, sami natomiast oczekujemy, że eksperymenty nad interfejsem użytkownika i implementacją produkcji znacznie przyspieszą w momencie wydania Mozilli 1.0.

Słyszałem, że liczba błędów wzrasta. Czy to prawda?

"Raport o błędzie" może być wysłany do Bugzilli z jakiegokolwiek związku z projektem Mozilla, który jest na tyle istotny, by angażować w niego ludzi i publicznie go śledzić. Nasz system raportowania błędów i system śledzący zawiera wszystkie raporty od chwili powstania projektu Mozilla, zatem liczba błędów samoczynnie musi rosnąć, ponieważ poprawione błędy i tak pozostają w bazie danych.

Nie ma dokładnej możliwości powiązania liczby raportów o błędach z ogólną jakością produktu:

  1. Niektóre raporty dotyczą operacji, a nie kodu.
  2. Znacząca liczba raportów o błędach związanych z kodem dotyczy tych samych błędów, część stanowi tzw. “niepoprawne raporty o błędach”, a część wyraża opinię lub prośbę o poszczególne rozszerzenia.
  3. Prośby o nowe możliwości (Requests for new features, RFEs albo “requests for enhancements”) są śledzone jako raporty o błędach.
  4. Istnieją grupy tzw. “meta-błędów” (ang. meta-bugs), które są używane do obsługi projektu. Na przykłąd, istnieje meta-błąd dla każdego wydania milestone, w którym śledzimy sprawy istotne dla tego wydania.
  5. Liczba raportów o błędach jest wprost proporcjonalna do liczby uczestników projektu: im więcej uczestników, tym więcej nadesłanych do Bugzilli raportów.
  6. Istnienie raportu o błędzie niewiele mówi, jeśli w ogóle, o jego skutkach dla użytkowników. Pojedynczy raport o blędzie może wskazywać na ogromny problem dotyczący wszystkich użytkowników, albo może dotyczyć szczególnych sytuacji, w których zdecydowana większość użytkowników raczej się nie znajdzie. Ponieważ raporty o błędzie dotyczą każdej bardziej niecodziennej sprawy, jest całkiem prawdopodobne, że liczba raportów o błędzie może rosnąć wraz z ogólnym wzrostem jakości.

Podczas gdy liczba raportów o błędzie nie pozwala określić “rzeczywistej ilości błędów” my śledzimy inne jej pomiary, w szczególności Średni Czas Między Awariami (ang. Mean Time Between Failures, MTBF), który jest powszechnie uznawanym wymiarem standardowym (sprawdź np. tą analizę aktualnej kompilacji).

Jaki jest związek mozilla.org z firmami sponsorującymi, takimi jak Netscape i AOL?

Mozilla.org istnieje by uczynić Mozillę odnoszącym sukcesy projektem o otwartym źródle. Wspiera całą społeczność Mozilli i stanowi centralny punkt kontaktu dla zainteresowanych używaniem lub ulepszaniem podstawowego kodu Mozilli.

Mozilla.org jest całkowicie niezależna przy podejmowaniu decyzji. Priorytetem jest tu długotrwałe dobro kodu i społeczności. Mozilla.org bywa sponsorowana przez firmy posiadające zasoby sprzętowe (serwery i inne) i ludzkie, akceptuje najlepsze z ofiarowanych przez nich rozwiązań i ściśle kontaktuje się z dystrybutorami.

Niektórzy członkowie grupy mozilla.org stanowią ochotnicy, w tym "Chief Lizard Wrangler". Inni członkowie są sponsorowani przez pracodawców. We wszystkich przypadkach bardziej wymagane jest poświęcenie dla samego projektu niż jakiś konkretny produkt z niego wynikły. Mozilla.org ma głęboko zakorzenione zobowiązanie do pełnej przezroczystości.

Czy nie jest tak, że większość pracy robi Netscape (pisanie kodu i dokumentacji, testowanie, itp)?

Netscape jest największym pojedynczym ofiarodawcą projektu Mozilla i wzmocnił społeczność zatrudniając dużą liczbę byłych ochotników, przez co pozwolił wielu z nim na skupienie się na tym projekcie na pełnym etacie.

Od samego początku pracownicy Netscape zaangażowani byli w większość aspektów dotyczących podstawowego kodu, zwyle wraz z kilkoma kluczowymi ochotnikami i rosnącą liczbę pracowników innych firm stosujących kod Mozilli. Obecnie, około 300 ludzi niezwiązanych z Netscape ofiarowało swój kod projektowi.

Liczba ludzi uczestniczących w innych aspketach projektu jest jeszcze większa. W szczególności liczba tych, którzy uczestniczą w testowaniu i raportowaniu błędów jest ogromna. Ostatnie wydania z mozilla.org zostały ściągnięte przez 300 000 - 400 000 ludzi każda, dając projektowi znakomity zestaw danych testowych.

Setki ludzi uczestniczą w działalności testowej, wspomagając tych programistów, którzy piszą kod. Pozwala to programistom na bycie bardziej wydajnymi.

Podobnie, wiele z generowanej dokumentacji, w tym różnych podręczników, pochodzi od ochotniczej społeczności.

Czy AOL będzie używać Mozilli?

Mozilla.org nie może mówić o planach AOL, może to tylko sama AOL. CompuServe, podmiot będący w 100% własnością AOL, aktualnie dostarcza technologię Mozilli znaną jako “Gecko” jako część klienta CompuServe 7.0. AOL obecnie testuje wersję beta klienta AOL 7.0, który również korzysta z Gecko, ale jest jeszcze zbyt wcześnie by mówić o planach na przyszłość.

Jakie warunki licencyjne dotyczą podstawowego kodu Mozilli?

Podstawowy kod Mozilli jest rozwijany i licencjonowany jako oprogramowanie o otwartym źródle/wolne oprogramowanie. Oznacza to, że odbiorca kodu źródłowego ma zagwarantowane prawa podstawowe (ang. basic rights).

Główna część podstawowego kodu Mozilli objęta jest Publiczną Licencją Mozilli (MPL, Mozilla Public License) i Publiczną Licencją Netscape (NPL, Netscape Public License). Pliki objęte zgodnymi licencjami open-source/free software (takie jak licencje BSD czy MIT) również mogą być w niej zawarte.

Skutkiem tego podstawowy kod Mozilli może być zgodnie z prawem:

przez każdą osobę prawną i fizyczną do dowolnych celów.

Więcej informacji o oprogramowaniu o otwartym źródle i wolnym oprogramowaniu można znaleźć w języku angielskim na stronach, odpowiednio: http://opensource.org i http://www.fsf.org. Informacje w języku polskim można znaleźć na stronie opensourcepl.org.

Kod podstawowy aktualnie jest relicencjonowany, by uczynić łatwiejszym legalne mieszanie kodu Mozilli z kodem innych projektów, które także są wolne, ale mają niekompatybilne licencje (chodzi o GNU GPL i LGPL). Spowolnienie tego procesu jest wynikiem “zaginięcia” niektórych ofiarodawców

Jakie inne technologie opracowała mozilla.org? Komu mogą się one przydać?

Podstawowy kod Mozilli zawiera szerokie spektrum względnie modularnych rozwiązań opartych na standardach. Dla programistów, szczególnie OEMs, kod podstawowy może się okazać atrakcyjnym wolnym “plug and play-ground”, źródłem wysokiej jakości oprogramowanioa do tworzenia lub rozszerzania przenośnych i zgodnych ze standardami aplikacji związanych z siecią i www.

Wiele z tych rozwiązań jest zastosowanych w Mozilli 1.0, ale nie wszystkie.

Na przykład istnieją takie narzędzia deweloperskie jak Bugzilla, która jest przykładem technologii Mozilli, która odniosła sukces daleko poza głównym celem projektu Mozilla. Obecnie znaleźć można tysiące instalacji Bugzilli używanych na całym świecie do śledzenia informacji o innych projektach - otwartych i komercyjnych, które z pakietem Mozilla nie mają nic wspólnego.

Ponadto, znaleźć można także różne inne projekty, jak np. Rhino, implementację JavaScriptu w Javie (co pozwala twórcom rozwiązań opartych na Javie na dostarczenie możliwości skryptowych użytkownikom końcowym).

Co słychać na mozilla.org?

Cokolwiek się dzieje, dzieje się bardzo otwarcie. Godny uwagi jest fakt, że już początkowe założenia projektu w pierwszym “rozkładzie jazdy” (październik 1998 r.) poruszały tą właśnie kwestię (inne założenia dotyczyły kwestii technicznych).

Sama strona www jest w gruncie rzeczy tworzona przez i dla programistów. Zwykle nie ma ona znaczenia dla innych grup, takich jak prasa czy użytkownicy końcowi. Jeśli masz wystarczające zdolności techniczne, możesz skorzystać ze świetnych narzędzi, takich jak edycja www albo wyglądający na prosty (ale to tylko pozory) podgląd graficzny w czasie rzeczywistym (real-time) stanu kompilacji poszczególnych produktów na różnych platformach (na przykład ten podląd najnowszego stanu jednej z gałęzi produktu Mozilla).

Rozwój Mozilla idzie po ścieżce zdefiniowanej w okresowo aktualizowanym “rozkładzie jazdy” (ang. roadmap document). Priorytety i cele są definiowane w “manifestach”, takich jak Manifest Mozilli 1.0.