Ten wpis jest dedykowany tym wszystkim, którzy chcieliby zrozumieć czym jest “wydanie” produktu w świecie wolnego oprogramowania i czym różni się ono od tradycyjnego modelu.
Aby zrozumieć w całości model naszego postępowania, i jego przyczyny, warto przeczytać esej Katedra i Bazar Erica S. Raymonda, ale w telegraficznym skrócie chodzi o zasadę “wydawaj wcześnie, wydawaj często“(ang. release early, release often).
Omówię teraz efekt zastosowania tej zasady na model wydawniczy na przykładzie Mozilli Corp. i przeglądarki Firefox.
W efekcie zastosowania modelu bazarowego, otwartego, nasze źródła są zawsze dostępne. Rozwój aplikacji opiera się na narzędziu zarządzania wersjami. To znaczy, że jest katalog, a w nim kod źródłowy aplikacji. Każdy na świecie ma do tego dostęp. Ma to ogromne implikacje w rozumieniu ideologii Wolnego Oprogramowania, gdyż gwarantuje użytkownikowi cztery fundamentalne prawa, co jest jednak tematem na osobny tekst. Na razie skupmy się na tym, że kod źródłowy ma swój numer.
W danym momencie jest to wersja, dajmy na to, 1 (pierwsza). W momencie gdy ktokolwiek, którykolwiek programista dokona jakiejkolwiek zmiany w kodzie źródłowym zmieniana jest wersja. Wersja kodu bez tej zmiany to wersja 1, a z tą zmiana to wersja 2. Każda następna wersja będzie nosiła następny numer.
Drugim ważnym elementem pozwalającym zrozumieć jak działa system wydań w wolnym oprogramowaniu jest kwestia linii rozwoju kodu. Dwa podstawowe pojęcia związane są z analogią drzewa – to pień (trunk) i gałęzie (branches). Pień to główna linia rozwoju kodu, tam wchodzą wszystkie zmiany i z niego odłączają się gałęzie. Spójrzmy na obrazek:
To co widzimy na dole to właśnie “trunk”. Linia główna. Z niej odłączane są co pewien czas i numerowane, gałęzie stabilne. 1.7 (na nim bazował Firefox 1.0), potem 1.8 (na nim bazował Firefox 1.5 i Firefox 2.0), 1.9 (na nim będzie bazował Firefox 3.0) i następna będzie linia 2.0 (na niej będzie bazował Firefox 4.0).
Odłączenie gałęzi polega na wzięciu kodu z danego momentu w trunku i stworzeniu osobnej linii od tego momentu nazwanej gałęzią. Zmiany w gałęzi następują rzadziej, dotyczą tylko kwesti związanych z wydaniem danej wersji, są mniej eksperymentalne i mają na celu stabilizacje i przygotowanie wydania. W tym czasie w gałęzi głównej (trunk) mogą pojawiać się zmiany eksperymentalne, i inne nowości, które kiedyś stworzą następne wydanie.
Krytycznie ważne jest to, że nasze systemy automatyzacji co kilka godzin kompilują i umieszczają na serwerze tzw. nightly builds dzięki czemu można w każdej chwili pobrać i zobaczyć jak działa aktualna wersja ze źródeł sprzed godziny.Jak widać dla każdej gałęzi tworzone są osobne buildy.
Także wszystkie informacje na temat tego co planujemy dla Firefoksa 3 i silnika Gecko 1.9 są publicznie dostępne, wszystkie zmiany jakie nastąpiły, na przykład, w ciągu ostatniego dnia można śledzić, a wszystkie zadania można przeglądać (tu na przykład zmiany blokujące wydanie Gecko 1.9).
Co to oznacza w zderzeniu z mediami? Problemy. Dziennikarze przyzwyczajeni, że znalezienie czegoś na serwerze oznacza wyciek wydania, przeszukują nasze serwery FTP, aby pochwalić się odnalezieniem na nich czegoś, a potem z stwierdzają, że zniknęło. W kontekście tego co pisałem powyżej powinno być to jasne, że na naszych serwerach są setki tzw. “kompilacji” robionych różnych gałęzi, które każdy może pobrać i przetestować. Jednak tylko niektóre z nich są wydaniami. Czymś co jest kierowane do odbiorców. I do mediów.
W kwestii wydań nie różnimy się w politce od innych firm. W momencie wydania piszemy o tym na serwisach informacyjnych typu DevNews, blogujemy, wysyłamy informacje do prasy, a samo wydanie ląduje w specjalnym katalogu o nazwie “releases” na serwerze.
Problem polega na tym, że dziennikarze przywyczajeni do tradycyjnego modelu, łapią co tylko znajdą na serwerze, linkują do tego i ogłaszają to jako wydanie, myląc tym samym użytkowników i potencjalnie narażając ich na niebezpieczeństwo. Kiedy? Ano załóżmy, że tzw. wersja nocna na 2 dni przed wydaniem zawiera błąd, który podczas testów jakości uda nam się wyłapać i poprawić przed wydaniem. Jeśli dziennikarze zachęcili ludzi do pobrania wersji bez poprawki, stworzyli (gwarantując własnym autorytetem) iluzję, że dana osoba pobrała coś o jakości “wydania produktu Mozilli”. Tymczasem myśmy nic nie wydali, dziennikarz wprowadził odbiorców w błąd.
Drugim przykładem z ostatnich dni jest ogłoszenie wydania Firefoksa 4.0 alpha 1pre przez innego dziennikarza skanującego nasze serwery. Na dodatek ów dziennikarz napracował się, aby przetestować osobno wydajność tego z ostatnią betą Firefoksa 3 i porównać je.
Co dokładnie definiuje czy mamy doczynienia z Fx3.0beta3 czy Fx4.0alpha1? W katalogu browser/config istnieje plik version.txt, który zawiera jedną linię tekstu będącą numerem wydania.Jeśli spojrzymy w historię tego pliku, zobaczymy, że zawsze tuż po wydaniu, albo tuż po odłączeniu gałęzi jest ona podbijana do następnego numeru. Kilka godzin później pojawiają się pierwsze nocne kompilacje z tym numerkiem, ale nie oznacza to wydania, prawda?
Zatem w przypadku porównywania dwóch nocnych kompilacji możemy mieć doczynienia z czymś takim:
Górne kółko oznacza wydanie z nowo utworzonej gałęzi 1.9 z której wyjdzie Firefox 3. Dolne to wydanie z tego samego dnia, ale z gałęzi głównej z której kiedyś powstanie gałąź 2.0 i Firefox 4. Oba są z tego samego dnia. Jak dużo zmian mogło się tam pojawić? Kilka… w tym ta która podniosła numerek w pliku version.txt do 4.0a1pre. Czy jest sens porównywać je dziś? Nie bardzo. W ciągu najbliższych miesięcy najpierw skupimy się na wydaniu Firefoksa 3, a potem zaczniemy prace nad poważnymi zmianami w głównej linii na drodze do Mozilli 2.0 i Firefoksa 4.
Wydanie Firefoksa 4.0alpha1 nastąpi nie wcześniej niż za pół roku. Co prawda trwają już eksperymentalne prace nad platformą Mozilla 2.0, ale są one jeszcze w bardzo wczesnym stadium.
Nie istnieje żadne wydanie, które nie znajduje się w katalogu releases, o którym nie napisaliśmy na DevNews, i o którym nie poinformowaliśmy dziennikarzy. Pisanie o takich wydaniach jest zwyczajnym wprowadzaniem użytkowników w błąd, narażaniem ich na używanie wersji nie certyfikowanej przez Mozillę jakościowo i narażanie wizerunku Mozilli na szwank w przypadku, gdyby takie niestabilne wydanie “polecone” przez dziennikarzy okazało się wadliwe.
Chcąc pisać o wolnym oprogramowaniu trzeba to wiedzieć. Bo nie tylko my tak robimy, można pobrać codzienne kompilacje Ubuntu, KDE, WordPressa, WebKita, NetBeans, VLC i wielu innych.
Drodzy dziennikarze. Dziękujemy Wam za zainteresowanie naszymi pracami. Jesteście dla nas wspaniałymi partnerami i sprawiedliwymi krytkami, cenimy współpracę z Wami i staramy się dać Wam to czego potrzebujecie. Wasze zainteresowanie zbliżającym się Firefoksem 3 odbieramy z dumą i traktujemy jako dowód, że robimy coś ważnego.
Jednocześnie prosimy, zrozumcie nas. Nasz model rozwoju jest taki a nie inny z bardzo konkretnych powodów. Pragmatycznych. Wierzymy, że udostępnianie codziennych kompilacji pomaga naszej społeczności testować i współpracować z nami. Jesteśmy do bólu otwarci, możecie zajrzeć wszędzie, obejrzeć stan prac nad dowolnym zadaniem, przeczytać o wszystkich planach, uczestniczyć w naszych cotygodniowych konferencjach telefonicznych na temat Firefoksa 3 i Gecko 1.9, do których dołączyć może każdy. Piszemy blogi, jesteśmy dostępni na IRCu.
Jeśli będziecie obniżać bezpieczeństwo naszych użytkowników i mylić ich, jedyne co możemy zrobić aby się bronić, to zmniejszyć stopień naszej przejrzystości. Zacząć chować się z tym co robimy, aby unikać chaosu. Przecież nikt tego nie chce, prawda?
8 replies on “Czym jest “wydanie” w świecie wolnego oprogramowania”
Bardzo fajny tekst 🙂 Może niektórzy w końcu zrozumieją… 😉
Bardzo dobry tekst, ale wydaje mi się, że jednak nic nie zmieni, bowiem pościg za kasą i sensacją jest obecnie ważniejszy, niż rzetelność.
Bardzo fajny tekst,niestety nie zrozumieją 😉
Ci, którzy mieli zrozumieć, już rozumieją. Ci, którzy nie rozumieją, po prostu tego nie przeczytają 🙂
Bardzo dobry tekst (szczególnie ostatnie trzy akapity), ale podzielam opinię przedmówców – prędzej Microsoft przejdzie na open source niż nasi polscy “redaktorzy” wezmą sobie to wszystko do serca. Ludzie piszący na stronach typu dobreprogramy.pl ewidentnie dorabiają sobie do pensji (kieszonkowego?) i nie będzie im się chciało odwalać rzetelnej, dziennikarskiej roboty. Przecież można przeczytać kilka zagranicznych źródeł (nieuważnie), ewentualnie samemu gdzieś pogrzebać (nie wiedząc co się robi) – i news gotowy. Dziwi mnie tylko trochę, że ktoś to czyta…
Witam.
Wydaje mi się, że cały ten artykuł ma jeden główny przekaz: nie czytamy się wzajemnie, Panowie, bo wygodniej nam pisać. Ktokolwiek zerknie i przeczyta podlinkowany materiał o Firefoksie 4.0 (mojego zresztą autorstwa), znajdzie tam domniemanie, że jest to “przemalowana” wersja 3.x. To domniemanie bardzo szybko przerodziło się w pewność i zostało podkreślone, a nawet – jeśli mnie pamięć nie myli – wyróżnione na czerwono w kolejnym materiale o Firefoksie (również tutaj podlinkowanym).
Rozumiem, że deweloperom przeglądarki może zależeć na tym, by ludzie korzystali wyłącznie z wydania stabilnego. Tak długo jednak, jak czytelnicy będą chcieli czytać o Firefoksie 4, 5, 6, prasa będzie o nim pisać.
Sądzę, że nic nie stoi na przeszkodzie, żeby Mozilla zamknęła stronę z nocnymi buildami (wstęp tylko dla wybrańców) albo udostępniała wyłącznie kody źródłowe. Żaden, powtarzam z całą mocą, ŻADEN z tych czynów nie jest sprzeczny z ideą open source.
Pozdrawiam
/ŁB
Ps. Byłbym wdzięczny za powiadomienie mnie o ewentualnej odpowiedzi – z pewnością postaram się ją skomentować. Niestety, nie mam czasu na czytywanie blogów. Nawet tych najwartościowszych, jak choćby ten.
Łukaszu, dziękuje, że odniosłeś się do tego. Martwi mnie tylko, że deklarując “nie czytamy się wzajemnie”, popełniasz dalej błędy, które wskazują na niezrozumienie powyższego wpisu.
1) “Ktokolwiek zerknie i przeczyta podlinkowany materiał o Firefoksie 4.0 (mojego zresztą autorstwa), znajdzie tam domniemanie, że jest to “przemalowana” wersja 3.x.” – nie istnieje Firefox 4.0. Nie ma czegoś takiego. To troche tak jakbym w prima aprilis zmienił w pliku version.txt numerek na 9.0, na jedną godzinę, a Ty napisałbyś artykuł o wydaniu pre alpha Firefoksa 9.0!
2) “Rozumiem, że deweloperom przeglądarki może zależeć na tym, by ludzie korzystali wyłącznie z wydania stabilnego.”
Zależy nam niewątpliwie na tym, aby końcowi użytkownicy korzystali ze stabilnej. Cieszymy się, że testerzy (ponad 800 tysięcy!) testują kolejne wersje Beta, Alpha i kompilacje nocne, ale istnieje naturalny gradient – ten kto interesuje się bardziej, ten kto lepiej rozumie w co się pakuje, ten znajduje kompilacje na serwerach FTP i je testuje na własne, dobrze rozumiane, ryzyko. Twoim artykułem przełamujesz ten gradient. Nagle osoba kompletnie nie wiedząca nic, nie rozumiejąca i nie umiejąca oszacować ryzyka, nie znająca się na tym jak działa Mozilla, taka, która nie da sobie rady sama kiedy coś pójdzie nie tak dostaje bezpośredni link do pobrania jakiejś paczki…
To zupełnie co innego i w tym momencie, w moim przekonaniu, jesteś odpowiedzialny za to co się stanie z komputerem tej osoby, z jej danymi, zakładkami itp. To Ty ją tam skierowałeś.
Problem polega na tym, że Ty odmiennie ode mnie postrzegasz kwestię publiczności, zakładasz, że jak coś jest na FTP, to my gwarantujemy tego jakość i stabilność i bezpieczeństwo. To nie prawda. I nasz system nie przewiduje dziennikarzy poważnych magazynów linkujących do nocnych kompilacji.
3) “Sądzę, że nic nie stoi na przeszkodzie, żeby Mozilla zamknęła stronę z nocnymi buildami (wstęp tylko dla wybrańców) albo udostępniała wyłącznie kody źródłowe. Żaden, powtarzam z całą mocą, ŻADEN z tych czynów nie jest sprzeczny z ideą open source.”
Masz racje. Nie jest. I co z tego? My nie robimy “minimum” tylko “maximum” tego co nazywa się Open Source. Pracujemy w modelu otwartym i te kompilacje są nam potrzebne, są elementem naszego ekosystemu. Od lat działa to bardzo dobrze, gradientalna linia dostępu – zwykli użytkownicy trafiają na wersje finalna, troche bardziej zaawansowani i web developerzy na wersje beta, jeszcze bardziej zaawansowani testerzy na wersje alpha i na nocne kompilacje.
Zakładam, że skoro Ty docierasz do tych kompilacji, rozumiesz ryzyko jakie podejmuje się instalując je. Mówiąc inaczej – absolutnie nic nie stoi na przeszkodzie, aby kompilacja nocna, która podlinkowałeś wszystkim czytelnikom kasowała zawartość twardego dysku w każdą niedzielę o 24:00. I nie, nie jest to wirus, po prostu mogliśmy testować funkcję, która nie obsługiwała czegoś i w pewnych okolicznościach szkodziła. Tego typu błąd zostałby z pewnością wyłapany i naprawiony na długo zanim wydalibyśmy to, ale Ty już podałeś nieświadomym niczego ludziom link do tamtej wersji. Kto jest winien?
A Twoja propozycja… cóż… czy naprawde sądzisz, że Mozilla powinna zmieniać sposób działania, żeby zabrać pistolet, którym ktoś nie umie się posługiwać? Przecież wszyscy mamy dobrą wolę, wspólne cele, czemu nie możemy współpracować zamiast się odgradzać nawzajem?
dobry tekst.
no i niestety brak obiecywanej odpowiedzi pana Bigo, niestety coraz więcej widzę na “popularnych” serwisach i vortalach pisania o wersjach alfa, beta i RC, bez żadnych wzmianek o tym że takie wersje mogą (w najlepszym razie) pozbawić cię danych, zakładek itp…
smutne to.