Niektórzy, tak jak autor, są po prostu konserwatystami i cenią sobie to co jest sprawdzone, natomiast inni – pomimo satysfakcji z narzędzia – czują potrzebę systematycznego aktualizowania oprogramowania dla nowości, niekoniecznie im potrzebnych. Ot tak, z potrzeby bycia na bieżąco. Z tego też powodu wiele osób zmigrowało z OpenOffice.org do pierwszej wersji LibreOffice, a szczerze mówiąc, nie było ku temu istotnych przesłanek.

Z czasem wszelakie migracje zakończono sukcesem, a gdy niespodziewanie i z wielkim bólem udostępniono OpenOffice’a 3.4 (bądź OpenOffice’a 3.4.1 dla Polaków), temat “lepszości” powrócił i był rozstrzygany na płaszczyźnie dostępności zasobów ludzkich tudzież tempa dodawania nowych funkcji. Gdyż jak to komentują użytkownicy: co z tego, że dodają rzeczy całkowicie mi zbędne? Ważne, że program jest rozwijany.

Ponieważ Apache OpenOffice poległ w tej rywalizacji, Rob Weir nie raz i nie dwa, winy doszukiwał się w postępowaniu konkurencyjnej The Document Foundation, oskarżając jej członków o zbałamucenie dziennikarzy, a w konsekwencji o sianie kłamstw na temat (nie)życia poczciwego już OpenOffice’a. Często też wypominał rywalom kopiowanie pracy inżynierów OpenOffice’a, jednocześnie krytykując brak takiej możliwości w drugą stronę i zarzucał licencyjną obłudę. W ten też sposób LibreOffice zyskał wiele funkcji, tworząc je w długim okresie migracji infrastruktury Oracle’a pod skrzydła Apache, a także kopiując cudzą pracę w późniejszym okresie.

Problemy, a właściwie zarzuty licencyjnej obłudy wracały jak bumerang, kiedy ni stąd ni zowąd, Michael Meeks (członek TDF) wyszedł z inicjatywą relicencjowania projektu na zasadach Mozilli, argumentując to całkiem pragmatycznymi podstawami: możliwością przełączania kodu między licencjami GPLv2.0+, LGPLv2.1+ oraz AGPLv3.0+, a także zaprzestaniem pobierania oświadczeń od kontrybutorów.

Krok ten pomimo panujących animozji byłby również pomyślny dla rywali z Apache, gdyż licencja MPL 2.0 jest kompatybilna z licencją Apache. Jednakże swój głośny sprzeciw wyraził Markus Mohrhard (hacker LO Calca), pisząc o motywacji do pracy nad projektami FLOSS i krytykując próby zastraszania inżynierów, którym miano grozić zmarnowaniem ich wysiłku.

However I will not agree with people suggesting that re-licensing your commits for another project is a good idea. The Libreoffice project has chosen a free and open source license and anybody implying that refusing to re-license commits is against the FOSS ideas or trying to force developers to re-license by threatening that the changes will be otherwise rewritten disqualifies for any further discussions. In my opinion similar tactics are used by some of our closed-source competition and I feel ashamed that I know about a project using these in the open source world.

Z biegiem czasu sprawa rozeszła się po kościach, a status quo został utrzymany. LibreOffice nadal jest rozpowszechniany na zasadach licencji wirusowej, a bolączką Roba Weira nadal jest niemożność skopiowania pracy rywali.

Wielu użytkowników oby dwóch pakietów (w tym autor tego tekstu) oczekiwało gorącej rywalizacji i wyścigu zbrojeń. W niektórych przypadkach OpenOffice korzystał z życzliwości społeczności LibreOffice i importował konkurencyjne rozwiązania (np. wybieracz kolorów od Christiana Lippka czy skrypt konwertujący pliki .SDF do .PO od Tamasa Zolnai). Nastał jednak moment, gdy możliwości powielania pracy się skończyły, a unaocznia to fakt zgłoszonych projektów do Google Summer of Code 2013.

Apache OpenOffice - pomysły na Google Summer of Code 2013

Z jedenastu projektów, trzy są dostępne już w LibreOffice 4 (tak krytykowanym za mało znaczące zmiany), a jeden jest drugą próbą implementacji kart (stworzoną nota bene przez Andrzeja Wytyczak-Partykę w ramach Summer of Code 2005).

Można zadawać sobie pytania, po co OpenOffice’owi obsługa skórek Firefoksa czy obsługa protokołu CMIS, lecz nijak to nie wpłynie na priorytety inżynierów, którzy przecież sami zasugerowali powyższe idee. Poddawać krytyce można za to sens ścieżki, którą podążają, aby zrealizować powyższe pomysły. Summer of Code to wydarzenie, które pozwala w dwa miesiące wykonać kawał porządnej roboty (i zarobić niemałe pieniądze), a zasugerowane skórki, pracownik SUSE zaprogramował podczas weekendu i przy piwie… Użytkownikom zatem nie pozostaje nic innego jak pokorna akceptacja powyższego wyboru bądź też modlenie się w skrytości ducha o pojawienie się studenta z dużą ambicję i lepszym pomysłem od tego, który zaprezentował mentor.

Dodatkowo na niekorzyść OpenOffice’a należy uwzględnić czas. Jeżeli projekty w ogóle zostaną zakończone, to pierwsze zmiany będą dostępne dopiero w październiku, czyli najwcześniej 9 miesięcy po konkurencji. W przypadku powstania wartościowych zmian w kodzie rywale najpewniej i wtedy wykorzystają pracę inżynierów OpenOffice’a, co nieraz już miało miejsce w przeszłości.

Należy także przestać dawać wodzić się za nos. Publiczne wojenki między przedstawicielami obu projektów to czysta polityka, a faktem jest, że sukces OpenOffice’a jest dla The Document Foundation ich własnym sukcesem, gdyż zyskują w ten sposób dostęp do bazy dobrej jakości kodu. Tyle że takie postępowanie eliminuje szanse na jakikolwiek wyścig zbrojeń i skazuje OpenOffice’a na powolną pogoń za rywalem (z zyskiem dla użytkowników LibreOffice). OpenOffice oczywiście będzie nadal rozwijany i wykorzystywany, jednakże jego zasięg będzie mocno ograniczony, a jeśli nic się nie zmieni, jego sytuacja zacznie przypominać sytuację systemów BSD wobec Linuksa.

Jest jeszcze jeden wariant: ludzie stojący za OpenOffice’m muszą podążać ścieżką, która zostanie odrzucona przez The Document Foundation, jednakże czy idąc tym torem, zyskają sympatię i uznanie u dotychczasowych użytkowników? Myślę, że jest na to szansa.

Zgodnie ze wcześniejszymi przewidywaniami, OpenOffice 4 podlega procesowi symfonizacji interfejsu i jak na razie, dzieje się to bez szkód dla czasu reakcji pakietu. Będzie to drugi pakiet po Calligra Suit wykorzystujący możliwości panoramicznych monitorów, podczas gdy TDF skupia się zaledwie na żmudnych analizach rozpoznawalności ikon, a także wiąże się z ohydną paletą kolorów ze stylistyki Tango.

Do namysłu daje również chęć zaprogramowania kart w ramach programu Summer of Code. OpenOffice przyswoił już boczne menu, które dostał w formie darowizny od IBM-a. Ta sama donacja zawierała kod odpowiedzialny właśnie za przeglądanie dokumentów w kartach. Oznaczać to może, że kontrybucja firmy IBM wcale nie jest tak użyteczna, jak nam to przedstawiano, oraz że zaadaptowanie kodu będzie kosztować więcej pieniędzy i wysiłku niż napisanie tego samego od nowa, co niekoniecznie musi być dużym problemem, zwłaszcza gdy brzemię to ponosi Google. Tak czy inaczej, na barkach OpenOffice’a spoczywa wielki ciężar – ciężar wynajdowania koła od nowa, gdyż wszystkie inne koła, te od LibreOffice, Symphony czy nawet od samego OpenOffice.org, są kołami niewymiarowymi i niedopasowanymi.

Tymczasem użytkownicy nadal oczekują wydania OpenOffice’a 4, którego premierę zapowiedziano na pierwszym kwartał tego roku!