W projekcie GNOME szykują się poważne zmiany. Wbrew zaleceniem nowoczesnego marketingu nie chodzi jedynie o podbicie numeru wersji oraz kosmetyczne poprawki. Postaram się w dwóch artykułach przybliżyć perspektywę przeobrażeń czekających to środowisko graficzne. Pierwszy tekst jest tłumaczeniem oficjalnego oświadczenia na temat wersji 3.0, które zostało wydane przez GNOME Release Team. Drugi będzie zawierał opis najbardziej zauważalnych przez użytkowników elementów nadchodzącej rewolucji: GNOME Shell oraz GNOME Zeitgeist. Miłego czytania! 🙂

Planowanie GNOME 3.0
Przez kilka pierwszych miesięcy 2008 roku członkowie GNOME Release Team dyskutowali na temat obecnego stanu naszego środowiska. Nie było to nic oficjalnego; właściwie można by to nazwać koleżeńskimi rozmowami fachowców na interesujące ich tematy. Zauważyliśmy wtedy, że GNOME mógłby jeszcze długo pozostać w wersji 2.x, dzięki czemu moglibyśmy nadal korzystać ze sprawdzonych metod rozwoju. Nie była to jednak ta wizja przyszłości, którą nasza Społeczność chciałaby urzeczywistniać: nuda i brak pomysłów. Powoli zaczął się formować plan. Z czasem rozwinął się, trochę zmienił, przybrał również bardziej konkretne kształty. Poinformowano więcej osób, zbieraliśmy więcej informacji zwrotnych. Ostatecznie na konferencji GUADEC Release Team przedstawił Społeczności wstępny plan działań, które miały nas doprowadzić do GNOME 3.0. Minęło trochę czasu, a właściwie minęło dużo czasu, ponieważ wiele osób było zajętych innymi rzeczami. Nigdy jednakże nie jest za późno na zabranie się do pracy nad słusznym projektem, nadszedł więc wreszcie czas, aby zacząć poważnie myśleć o GNOME 3.0!

Odbiegnijmy nieco od głównego tematu i rozważmy ogólne wrażenie – projektowi GNOME brakuje wizji. Przyglądając się samej Społeczności byłoby błędem powiedzieć, że brakuje jej wizji; niemniej projekt jako całość zmaga się z tym problem. To czego nam brakuje najbardziej to ludzie, którzy dali by swoje błogosławieństwo dla jednej, konkretnej wizji i uczynili ją oficjalną wyznaczając Społeczności konkretne cele, abyśmy mogli wspólnie pracować w jednym kierunku. Przed wydaniem wersji 2.x Społeczność ogólnie wyraziła aprobatę dla określonego projektu rozwoju i nie było w związku z tym potrzeby bezpośredniego wytyczania celów. Ale w ciągu co półrocznych wydań okazało się, że chociaż wszytko działa bardzo dobrze i nasze bieżące zamiary są w pełni realizowane, to długoterminowe cele zostają spychane na dalszy plan, ponieważ skupiamy się głównie na dopieszczaniu naszego pulpitu. Doszliśmy więc do momentu, kiedy należy przenieść działanie na inny poziom, co wymaga podjęcia poważnych decyzji – tym właśnie zajmuje się Release Team. Nie oznacza to, że członkowie tego zespołu posiadają monopol na pomysły rozwoju GNOME; są oni po prostu głosem Społeczności.

(Na boku warto zauważyć, że już dwa lata temu podjęliśmy pierwszą próbę poradzenia sobie z tym problemem. Rozwiązaniem miało być ponowne ustalenie zasad opracowywania strategii rozwoju poszczególnych elementów projektu. Niestety okazało się, że pominęliśmy kluczowy czynnik: ogólną i długoterminową strategię rozwoju całości. Nasze działanie nie przyniosło oczekiwanych rezultatów, ponieważ zebrane razem pomysły na rozwój poszczególnych części nie wystarczą aby wyznaczyć strategię dla całości)

Ale wróćmy do tematu i zastanówmy się nad podstawowymi zadaniami związanymi z GNOME 3.0. Naszym zdaniem należy się skupić przede wszystkim na trzech dziedzinach:

• User Experience (ogólnym wrażeniu związanym z korzystaniem ze środowiska)
• Wydajność platformy developerskiej
• Promocja GNOME

Są również i inne rzeczy, którymi warto byłoby się zająć, o ile tylko będzie zainteresowanie ze strony Społeczności.

Z perspektywy zarządzania wydaniami, pojawiają się również inne pytania w kontekście planowania GNOME 3.0. Zdecydowanie potrzebujemy planu, żeby zorganizować proces tworzenia kodu, ale przy okazji możemy przemyśleć kwestię dystrybucji GNOME: czy zestawy modułów są nadal najlepszym sposobem dostarczania użytkownikom środowiska GNOME? Nie ma jednoznacznej odpowiedzi na tak postawione pytanie, ale z pewnością nasz przyszły sposób udostępniania GNOME będzie wywierał swój wpływ.

User Experience
Gdy podczas konferencji GAUDEC mieliśmy okazję porozmawiać z różnymi osobami na temat GNOME 3.0, jedna z nich zwróciła nam uwagę, że byłoby grubym błędem wypuścić tę wersję beż poważnych zmian w interfejsie. Nawet mimo to, że niektórzy z nas nie zgadzają się z tym stwierdzeniem, jest to trafna uwaga. Okazuje się zresztą, że wystarczy powiedzieć na forum Społeczności, że istnieje coś również poza wersją 2.x, a od razu ludzie przestają snuć niejasne wizje i po prostu zabierają się do pracy nad wcielaniem pomysłów w życie.

Jest wiadome, że istnieją obecnie dwa ważne pomysły, które mogą mieć zasadniczy wpływ na wrażenia użytkowników:

• GNOME Shell – Idea tej „powłoki” nie dotyczy jedynie zmiany w funkcjonowaniu paneli i menedżera okien. Dotyczy raczej samego sposobu pracy w środowisku – rozpoczynania zadań i przełączania się między nimi. A mówiąc jeszcze bardziej ogólnie: sposobu zarządzania pulpitem.
• Zmiana sposobu dostępu do dokumentów (poprzez dziennik, np. GNOME Zeitgeist). Konieczność radzenia sobie z całym systemem plików nie szczególnie uszczęśliwia użytkowników; przeciwnie – zazwyczaj chcą oni po prostu mieć dostęp do swoich dokumentów bez konieczności szperania po całym dysku. Już od dawna Społeczność była zainteresowana nowatorskim rozwiązaniem tego problemu (za pomocą zakładek, tagów, historii…), ale nigdy dotąd nie odważyliśmy się z nim zmierzyć. Czas to zmienić.

Te dwie koncepcje stanowią podstawę do podniesienia naszego user experience, nie są to zwykłe poprawki które projektujemy a później wcielamy w życie; są to najbardziej zaawansowane projekty mające nam pomóc ruszyć naprzód w dziedzinie wrażeń korzystania z GNOME. Praca nad projektami GNOME Shell oraz GNOME Zeitgeist trwa już od ponad pół roku. Oznacza to, że wkładamy obecnie wysiłek nie w rozpoczęcie tych projektów, ale w doprowadzenie ich do końca, a później dopieszczanie.

Na usta cisną się od razu pytania o stare metody pracy na pulpicie. Na przykład: czy zwykły Panel GNOME będzie nadal dostępny, jeżeli z różnych powodów GNOME Shell nie zachwyci użytkowników? W tej chwili nie ma na to pytanie jednoznaczniej odpowiedzi i będziemy jeszcze musieli zmierzyć się z tym problemem. Jedni z nas uważają, że należałoby pozostawić przez pewien czas stare elementy interfejsu w celu ułatwienia migracji. Inni odpowiadają, że implementacja tych rzeczy pochłonie niepotrzebnie część ludzkich zasobów i spowolni pracę nad rzeczami istotnymi. Rzecz jasna, nie jest to prosty wybór. Niemniej, warto podkreślić, że twórcy dystrybucji oraz inni członkowie społeczności wykorzystujący GNOME w swoich produktach z pewnością będą utrzymywać przez pewien czas wersję 2.x, a my będziemy ich w tym wspierać jak długo tylko rozsądek pozwoli.

Wydajność Platformy
Od czasu wydania w 2002 roku GNOME 2.0 nastąpiło sporo zmian w naszej platformie developerskiej. Obecnie nowe interfejsy programowania (API) są przeładowane, pozostałe zaś są zbyt przestarzałe – niektóre z bibliotek są niemalże zupełnie nieużywane. To wszystko powoduje zamęt i niepotrzebnie utrudnia pracę developerów. Ponieważ chcemy aby powstawało jak najwięcej aplikacji dla GNOME, musimy się zająć tym problemem.

Teraz nadarza się doskonała okazja to przepisania platformy i uczynienia jej bardziej zrozumiałą dla nowicjuszy. Oto kilka kroków, które należałoby uwzględnić:

• Wyrzucenie wszystkich przestarzałych bibliotek; nie powinny być wykorzystywane w nowo powstających programach.
• Stworzenie specjalnej kategorii dla bibliotek, które będą obecne w platformie, ale nie będą już dostatecznie wspierane w danym momencie (jak na przykład Gstreamer): powinno to być czytelnym sygnałem , co powinno być używane, a co nie.
• wykorzystanie nowych, ciekawych technologii, które zaczynamy używać na naszym pulpicie: na przykład efekty 3D (Clutter) czy geolokalizacja (GeoClue i libchamplain).
• Integracja z niektórymi zewnętrznymi bibliotekami. Dla przykładu: pomimo że D-Bus czy Avahi są zewnętrznymi bibliotekami, chcemy aby programiści korzystali z nich. W ten sposób będzie łatwiej wyrazić nasze intencje

Prace, które zostały poczynione nad projektem Gobject Introspection również przycznią się do głębokiej zmiany w możliwościach dostępnych przy projektowaniu aplikacji GNOME. Właściwie to już rozpoczęliśmy korzystanie z tych rozwiązań, aby przekonać się w jaki sposób wpłynie to na GNOME Shell. Okazuje się, że możliwość korzystania z popularnych języków programowania – jak na przykład JavaScript – może przynieść znaczne korzyści.

To wszystko ma rzecz jasna wpływ na nasze aplikacje: będziemy musieli tak przepisać programy, aby nie były zależne od przestarzałych bibliotek oraz przygotować je na nadchodzące zmiany, np. GTK 3.0. Na szczęście jest to łatwo mierzalny proces i będziemy mogli śledzić postęp prac za pomocą prostej strony internetowej.

Promowanie GNOME
Nasza Społeczność z biegiem czasu coraz bardziej rozwijała się pod względem programowania, ale jednocześnie stale opierała się podjęciu zadania promocji GNOME. Przyczyną na pewno jest to, że nie jest to łatwe zadanie. Od momentu rozpoczęcia prac nad projektem baza naszych użytkowników znacznie się rozrosła, ale mimo to nadal nie angażujemy ludzi w zadania związane z promowaniem. GNOME 3.0 stanowi dobrą okazję do zmiany tego stanu rzeczy i przyciągnięcia osób, które mogłyby się zająć rozkręcaniem zainteresowania nad projektem GNOME. Promocja projektu jest bez wątpienia jednym z elementów, które wpływają na jakość wydania, tak więc Marketing Team może się znacznie przyczynić do sukcesu GNOME 3.0.

Rzecz jasna, najważniejszym celem tych działań będzie przygotowanie użytkowników do GNOME 3.0 oraz przekaz informacji na temat tego wydania. Oprócz ukazania zmian, które nastąpiły w samej wersji 3.0 dobrym pomysłem byłoby ukazanie zmian, które nastąpiły od czasu wydania GNOME 2.0; z tego punktu widzenia wersją 3.0 można byłoby nazwać 2.10 w stosunku do 2.0 i tak samo wersją 3.0 mógłby być 2.20 w stosunku do 2.10. Mogłoby to stanowić podstawę do wykazania, że nasze ewolucyjne podejście do rozwoju GNOME po prostu sprawdza się.

Jednym z często pojawiających się zagadnień w czasie dyskusji na temat możliwości wypromowania GNOME było stwierdzenie, że promocja desktopów jest w ogóle trudnym zadaniem. Ale wcale nie musimy zabierać się do tego w ten sposób. Możemy się skoncentrować na wrażeniach dotyczących GNOME: najbardziej podstawowym będzie rzecz jasna wrażenie używania GNOME Shell; ale przecież użytkownicy nie korzystają z samego tylko pulpitu, ale również uruchamiają aplikacje. Nigdy nie staraliśmy się wykazać dlaczego aplikacje tworzone dla GNOME są dobre, a właściwie to nigdy nie zwracaliśmy na te aplikacje szczególnej uwagi. Dla przykładu: dlaczego mielibyśmy nie umieścić na głównej stronie projektu GNOME informacji o dobrym odtwarzaczu muzyki? Wcale nie musielibyśmy wybierać pomiędzy Banshee a Rhythmbox: możemy wspierać oba, oba są przecież dobre na różne sposoby i oba składają się na wizerunek GNOME.

To podprowadza nas do trzeciego zagadnienia: musimy przerobić naszą stronę internetową. Pomimo że nasza obecna witryna jest znana z tego, że utrudnia komunikację między użytkownikami, nie byliśmy w stanie stworzyć nowej strony, która poprawiałaby błędy poprzedniczki. Naprawa strony internetowej jest trudnym zadaniem, ale nie możemy się poddawać. Strona projektu jest bardzo ważnym czynnikiem dla kształtowania się tożsamości społeczności GNOME i nie możemy tak po prostu zignorować aktualnych problemów. Przyczyną tego stanu rzeczy był brak ludzi chętnych do pracy, ale okazało się, że można znaleźć projektantów www, którzy lubią GNOME, a którzy po prostu nie wiedzieli, że mogą pomóc w jego rozwoju.

Fakt, że projektanci stron internetowych mogą odegrać znaczącą rolę jest wskazówką w odniesieniu do ogółu użytkowników. Na chwilę obecną nie szczególnie wspieraliśmy użytkowników w działaniach na rzecz promocji GNOME: co dana osoba może zrobić, jeżeli ma ochotę pomóc? Wszyscy wiemy jakie korzyści może przynieść informacja przekazywana z ust do ust (na sposób rozprzestrzeniania się wirusów…) spróbujmy zatem to wykorzystać!

Inne potencjalne obszary
Wyżej przedstawione dziedziny nie powinny zaskoczyć nikogo, kto tylko śledzi rozwój GNOME, były to raczej oczywiste wybory. Niemniej mamy też i innych kandydatów, którzy mogliby przyczynić się do sukcesu GNOME. Te obszary, na których również chcielibyśmy się skupić potrzebują jedynie ludzi, którzy mogliby się nimi zająć, tak, żebyśmy mogli wiedzieć, czego się w tej materii spodziewać.

Testowanie środowiska: poprzez utworzenie ostatnio Desktop Testing Team, to zagadnienie stało się bardziej widoczne. Moglibyśmy jednak być w tej dziedzinie bardziej nowocześni, a właściwie: powinniśmy. Pomogliśmy światu Wolnego Oprogramowania ujrzeć drogę do łatwości użytkowania i efektywności, i nie ma powodu, dla którego nie moglibyśmy osiągnąć podobnego sukcesu w dziedzinie testowania pulpitu.
Wygląd: Na odbywającej się w lutym imprezie GTK Theming API Hackfest udało się dojść do porozumienia, na jakich zasad powinny być w przyszłości projektowane tematy pulpitu. To daje nam kolejną szansę na odświeżenie wyglądu. Może się stać jedynie dzięki pomocy artystów: mając artystów i koderów pracujących razem, przy czym są to programiści wrażliwi na potrzeby projektantów, nie ma wątpliwości, że efekt tej współpracy będzie świetny.
Ludzie: Szkielet Telepathy ładnie się rozwinął w ciągu ostatnich paru lat i oferuje obecnie niezłe perspektywy integracji komunikatorów internetowych lub mówiąc bardziej ogólnie: perspektywy komunikacji z ludźmi korzystającymi z innych aplikacji. Wkładając nieco wysiłku można uczynić z GNOME platformę komunikacji społecznej, z której korzysta się nie tylko w celu pracy nad dokumentami, ale również w celu nawiązania rzeczywistego kontaktu z przyjaciółmi.
Mobilność: GNOME Mobile ujrzało światło dzienne wraz z wydaniem 2.24 i pomogło nam zaistnieć w świecie urządzeń przenośnych. Wszelkie zmiany planowane w GNOME z oczywistych przyczyn cieszą się zainteresowaniem GNOME Mobile Team.

Kwestie organizacyjne
Musimy określić konkretne ramy czasowe dla naszego projektu. Cel jest prosty: wydać GNOME 3.0 wraz z wersją 2.30. Jest to sensowne z różnych punktów widzenia. Jeżeli chodzi o kwestie techniczne, mielibyśmy wystarczający zapas czasu na integrację z nowymi technologiami czy projektami, np. GNOME Shell; jeżeli chodzi zaś o komunikację, to przejście z 2.30 na 3.0 wydaje się logiczne i łatwe do zrozumienia. Warto to podkreślić, że jeżeli porównamy wersję 2.26 i 2.0 jest zupełnie zaskakujące, że nadal trzymamy je w ramach jednej gałęzi 2.x, gdy tymczasem moglibyśmy spokojnie być w 3.x czy nawet 4.x. Uczynienie z 2.30 wersji 3.0 jest wszakże ambitnym zamierzeniem, ale mamy nadzieję je zrealizować dzięki temu, czego nauczyliśmy się w przeszłości.

Metody rozwoju przyjęte w czasie prac na GNOME 2.x są na ogół dobrymi metodami, zresztą społeczność się już do nich przyzwyczaiła. Jej członkowie rozumieją przyczyny dla których dokonujemy zamrożenia pakietów i respektują tę „nietykalność”. Nie jest to rzecz którą powinniśmy zmieniać tylko dlatego, że nadarza się dobra okazja do zmian; wręcz przeciwnie: te metody mogą uprościć dojście projektu do wersji 3.0. Wskazywano na pewien regres mający miejsce w ciągu ostatnich pary cykli i nie możemy tego zignorować. Wydaje się, że przyczyną tego stanu rzeczy było to, że jedynie cześć społeczności chciała się rozwijać, co powodowało różne kontrowersje. Położenie nacisku na rozwój całego projektu powinno uśmierzyć te kontrowersje i zlikwidować we wspólnocie poczucie cofania się.

Sześciomiesięczne cykle stały się elementem naszej kultury i wywarły swoje piętno na całym ekosystemie wolnego oprogramowania, tak że istnieją dystrybucje, których cykl wydawniczy uzależniony jest od naszego. Zmiana tak istotnego elementu zarządzania projektem, który zresztą całkiem dobrze się spisuje, w żaden sposób nie mogłaby nam pomóc. Dlatego też utrzymujemy sześciomiesięczny cykl wydań. Ale mając projekt szeroko zakrojonych zmian i tak dalekosiężne cele musimy dokonać pewnych adaptacji. Dlatego też 2.28 nie będzie samodzielnym wydaniem ani celem samym w sobie, a po prostu szczeblem na drodze ku GNOME 2.30, czyli inaczej mówiąc 3.0.

Oczywiście musimy wziąć pod uwagę możliwość, że wersja 2.30 nie będzie dla nas na tyle dobra, żeby ją nazwać 3.0. Nasze wydania nie opierają się jedynie na czasie, ale również na jakości. Jeżeli nasz zespół kontroli jakości uzna, że wydanie wersji 3.0 powinno być przesunięte w czasie – tak się stanie. W kontekście wydania 3.0 powinniśmy szczerze przyjrzeć się sytuacji na początku cyklu 2.29 i nie bać się ewentualnej publikacji jako 2.30 i oczekiwania na przykład na 2.32 jako przyszłe 3.0. Niemniej jak już zostało powiedziane chcemy aby społeczność starała się jak tylko może, aby zrealizować nasze założenie: „GNOME 2.30 = GNOME 3.0″.

Mówiąc jeszcze bardziej ogólnie: w GNOME 3.0 chcemy utrzymać dwie płaszczyzny wydań: długoterminową (na przykład trzyletnią) z dalekosiężnymi celami, które realizujemy na bazie sześciomiesięcznych cykli.

Podsumowanie
Już teraz można śledzić nasze plany dla wydań 2.27 i 2.29: zawierają one konkretne kroki oraz terminy, na utrzymaniu których będziemy się teraz koncentrować, aby urzeczywistnić plany odnośnie 3.0.

Jak już wspomniano są to ambitne plany i ich realizacja będzie możliwa jedynie wtedy, gdy pomoże nam kto tylko zdoła. Firmy mogą uczynić wiele – dla przykładu GNOME Shell jest rozwijany dzięki olbrzymiemu wsparciu pracowników firmy Red Hat. Ale GNOME w ogóle nie mógłby istnieć bez tych wszystkich ludzi, dla których nasz projekt jest prawdziwą pasją. Na szczęście ta pasja jest tak wielka, że możemy myśleć o tworzeniu tak ambitnych planów!

Zbliżamy się do końca. Wierzmy mocno, że to co staraliśmy się pokazać jest dobrym planem dla GNOME. Z pewnością nie jest to plan doskonały. Z pewnością po drodze będą narzekania i różne trudności. Ale jest to droga naprzód.

Źródło: Planning for GNOME 3.0