Artėjant 4-osioms „LibreOffice“ projekto metinėms po kelių dienų, internete vėl pasirodė sena tema: Turėtų susitikti „Apache OpenOffice“ ir „LibreOffice“. Norėčiau pasidalinti savo įžvalgomis šia tema, nors manau, kad tai nėra svarbu, tuo labiau, kad „LibreOffice“ ir „Apache OpenOffice“ kūrėjai tikrai negalvoja apie susijungimą. Prieš pradėdamas leiskite visiems priminti, kad ši yra mano asmeninė nuomonė, o ne Dokumentų fondo, nei Demokratų partijos, nei mano vyriausybės nuomonė. Aš akivaizdžiai šališkas savo sprendimu; Aš netgi dalyvaujanti šalis. Bet aš taip pat esu gana nusimanantis šiais klausimais ir, manau, norėsite perskaityti ir jūs šis pranešimas pateikė Leifas Lodahlas, norėdamas kontekstualizuoti mano komentarus. Pirmiausia leiskite man paaiškinti, kad dviejų projektų sujungimas yra savaime politinė koncepcija, apimanti kelis klausimus. Tarp jų:
1. Kaip mes susitiktume?
Paskelbus „LibreOffice“ projektą, projektas paprašė „Oracle“ prisijungti ir perduoti prekės ženklo nuosavybės teises naujam projektui. Jis neveikė gerai. „Oracle“ ilgai laukė, kol nusprendė licencijuoti prekės ženklą „Apache Software Foundation“ kartu su „OpenOffice.org“ kodu. Čia yra svarbus dalykas: „Oracle“ licencijavo tą turtą.
Jis jų nedavė ir nepardavė AKM. Gebėjimas atsisakyti „OpenOffice“ prekės ženklo iš pat pradžių būtų šiek tiek neaiškus, o „LibreOffice“ bus naudojamas prekės ženklas. Net jei taip nėra, kaip tai veiktų? Ar išleistume tą pačią programinę įrangą dviem prekės ženklais? Du skirtingi leidimai dviem skirtingais pavadinimais?
2. Ką mes rinktume?
Čia atsiranda licencijavimo dalis: licencijų pasirinkimas yra bene viena didžiausių techninių kliūčių susijungti. Viena vertus, „LibreOffice“ kodų bazė savo licencijų (LGPL ir MPL) dėka gali priimti pataisymus, licencijuotus pagal „Apache“ licenciją, tačiau priešingai yra sunkiau (nors galbūt ir ne visiškai neįmanoma). Šis ribotas kodų srautas būtų lemiamas susivienijimo scenarijuje, nes tai leistų nutraukti bet kokio naujo pleistro licencijavimą pagal „Apache“ licenciją, o mes paliksime nepakitusią dabartinę „Document Foundation“ licencijavimo schemą. Spėju, kad „Apache Software Foundation“ neketina to leisti.
3. Kur mes susitiktume?
Kitaip tariant: kurioje saugykloje? Kur? Ar mes naudosime ASF SVN saugyklą, ar „Document Foundation“ nuosavą infrastruktūrą su „Git“ kaip pasirinkta sistema versijų valdymui? Galbūt kita galimybė būtų trečioji šalis (esama ar sukurta ad-hoc).
4. Kas?
Kas būtų lemiamos partijos, yra dar vienas opus klausimas. Viena vertus, Dokumentų fondas būtų viena iš šalių. Atsižvelgiant į susivienijimo tipą (žemiau), kai kurios diskusijų sritys nebus aptartos Dokumentų fondo įstatuose, o tai apsunkina šį klausimą. Be „Document Foundation“ ir „Apache“ programinės įrangos fondo, „Oracle“ tikriausiai būtų bent viena kita dalyvaujanti šalis; ir akivaizdu, kad IBM. Tai pasakius, nėra visiškai aišku, koks būtų bendruomenės balsas šiuo klausimu: tada Dokumentų fondas būtų vienintelis subjektas, kuris tiesiogiai atstovautų savo nariams, individualiems projekto „LibreOffice“ dalyviams. ASF daro tą patį, tačiau „Apache OpenOffice“ yra tik maža dalis visos ASF bendruomenės.
5. Kokio susivienijimo norėtume?
Be konkrečių aukščiau užduotų klausimų, šis klausimas turi platesnę reikšmę, nes būtent jis nurodo tikrąją hipotetinio dviejų projektų suvienijimo priežastį ir prasmę. Ar norime lygių dalių mišinio naujoje struktūroje? Ar tai įmanoma? Aš išryškinau keletą aukščiau esančių punktų, kurie rodo, kad šis scenarijus būtų techniškai sunkus. Ar norime, kad „LibreOffice“ būtų įkurta ant ASF ir AOO? Akivaizdu, kad ne aš, bet klausimas buvo užduotas anksčiau. Kodėl mes tai darytume? Tai įmanoma? Licencijų skirtumai rodo, kad reikės atsisakyti konkrečių „LibreOffice“ įnašų. Galų gale tai reikštų, kad „LibreOffice“ ištirptų AOO ir išnyktų, kai visi darbai būtų atliekami už dyką, o atsižvelgiant į dviejų projektų dydžio skirtumus, tai būtų tarsi dramblys, bandantis įveikti spyną. Ar norime, kad AOO būtų įkurta „LibreOffice“? Kalbant apie licencijas, tai būtų įmanoma. Ar AKM to norėtų? Aš nežinau. Manau, kad Dokumentų fondas gali sutalpinti. Jau anksčiau matėme masinės migracijos bangas. Žinoma, galime prisijungti prie AOO komandos. Iš esmės prie kiekvieno projekto prisidėtų teisėjai, balsuojantys kojomis. Tai nėra kažkas, ko negali kontroliuoti „Document Foundation“, „Apache“, „Oracle“ ar IBM.
6. Ką mes pasiektume?
Kai seno „OpenOffice.org“ projekto nariai aptarė projekto ateitį su „Sun Microsystems“ žmonėmis, jie dažnai girdėjo tą patį klausimą: „Papasakokite, kodėl„ OpenOffice.org “fondas galėtų padėti išspręsti projekto problemas?“ Neabejotinai bet koks fondo naudai iškeltas klausimas buvo nustumtas į šalį, iškėlus bet kokį kitą sprendimą, kuris nereikalautų nepriklausomo fondo egzistavimo. Jis naudodamas puikiai iliustruoja skirtumą tarp faktinių rezultatų ir numatomų rezultatų, pagrįstų racionaliu argumentu: šie du variantai nebūtinai papildo vienas kitą. Keisdamas ironija, dabar turiu užduoti tą patį klausimą: "Kodėl susivienijimas padėtų išspręsti bet kurio projekto problemas?" Greitai išvardysiu susirūpinimą keliančias sritis ir problemas, kurios dažnai nurodomos kaip dviejų biurų komplektų sujungimo priežastys:
- bendras prekės ženklas / didesnė prekės ženklo nuosavybė
- visi gali prisidėti prie tos pačios kodų bazės (taip!)
- nėra prasmės turėti du panašius biuro liukso numerius
- nebėra sąveikos problemų
Didesnis prekės ženklo kapitalas anksčiau buvo labai geras argumentas, galbūt geriausias, 2010 ir 2011 m. Aš pradėjau šį įrašą pažymėdamas, kad projekto „LibreOffice“ įkūrėjai aktyviai ieškojo „Oracle“ sutikimo naudoti „OpenOffice“ naujam projektui. Dabar mums tereikia kelių valandų nuo „LibreOffice“ projekto ketvirtojo jubiliejaus. Projektas vyksta gerai. Dar daug ką reikia nuveikti, tačiau jis viršijo tai, ką daugelis anksčiau įsivaizdavo. Nors „LibreOffice“ prekės ženklas prasidėjo nuo nulio 2010 ir 2011 m., Viskas pasikeitė. Akivaizdu, kad „OpenOffice“ turi labiau žinomą prekės ženklą, nes jis naudojasi 10 metų senojo projekto pranašumais; Apgailestauju sakydamas, kad „Apache OpenOffice“ už šį pasiekimą turi mažai kreditų, išskyrus jo egzistavimą. Tačiau „LibreOffice“ kaip prekės ženklas yra įsitvirtinęs ir jo prekės ženklo nuosavybė visur labai auga. Bet kurio iš šių prekių ženklų sunaikinimas sukeltų skaudžių pasekmių. Ar mes tikrai to norime? Ar kas nors turi įgyvendinamą ir tvarų prekės ženklo perėjimo planą? Nesu to girdėjęs.
Tai, kad bendras projektas galėtų prisidėti prie tos pačios kodų bazės, tokiu būdu paversdamas jį „geresniu ir stipresniu“ biuro paketu, yra ginčytinas. „LibreOffice“ pasiėmė tai, ko norėjo, iš „Apache OpenOffice“ per abiejų programų komplektų licencijos specifikacijas; tačiau vien tik „Apache OpenOffice“ turi mažai ką pasiūlyti „LibreOffice“. Be to, dvi dalyvių komandos yra tiek skirtingo dydžio, kad AOO kūrėjų pridėjimas nebūtų labai reikšmingas „LibreOffice“, o jei būtų priešingai, viskas būtų įdomu. Tačiau tai reikštų, kad vėl ketiname žaisti su mokesčių mokėtojais, tarsi matuotume pulkus. Bendruomenės nariai ateina ir eina, kaip nori, o susijungimas nėra tai, ko mes visi būtinai ieškome.
Tikrai yra mažai naudos turėti du panašius biuro paketus, nors tai yra pagrindinė programinės įrangos laisvės išraiška, ir vien to turėtų pakakti. Mes taip pat turime kaip 150 „Linux“ paskirstymų ir jei apsižvalgysime bei pritaikysime tokį mąstymą, norėsime susimaišyti su „Calligra“, „Abiword“ ir „Gnumeric“. Tai irgi neturi prasmės. Nepamirškite, kad nei AOO, nei „LibreOffice“ nesiekia būti „panašūs“ ir, nepaisant populiaraus suvokimo, kiekvieną ketvirtį jie auga labai skirtingai. Tą patį galima pasakyti ir apie „Calligra“, projektą, kuris sukurtas naudojant labai skirtingą kodų bazę. Trumpai tariant, klonai gali neturėti daug prasmės, tačiau pasirinkimas yra geras, ypač jei pasirinkimas susijęs su realiais skirtumais. Dabar tarp AOO ir „LibreOffice“ yra realių skirtumų, susijusių su funkcijomis, failo formato palaikymu, taip pat ekosistemos ir inžinerijos procesais. Laikui bėgant, pasirinkimas tarp šių dviejų liukso numerių tampa aiškesnis. Neturėtume pamiršti, kad įsivaizduodami konkurenciją tarp laisvos ir nuosavos programinės įrangos nereiškiame, kad kiekvienoje pusėje turėtų būti tik viena galimybė.
Paskutinis, bet ne mažiau svarbus dalykas - įvairios išmanančios šalys nurodė sąveikos klausimus kaip problemą ir iš esmės yra kliūtis priimti tokius atvirus standartus kaip ODF. Nors tai yra sudėtinga problema, ji taip pat nėra akinančiai kritinė problema, ta prasme, kad problemos, su kuriomis galima susidurti, dažniausiai kyla tam tikrose sąlygose. Paprastai tai apima vartotojų bazę, naudojančią „OpenOffice.org“ arba AOO, kartu su „LibreOffice“ ir dokumentais, kurie jau perkelti į ODF. Didėjantys diegimų skirtumai visada lemia vizualius dokumentų pateikimo skirtumus (nors duomenų neprarandama), todėl vartotojams kyla nusivylimas ir diskomfortas. Vienintelis galimas šių kliūčių sprendimas (be kruopštaus ir darbščio kamuolio nešimo migracijos eksperto) yra priversti AOO ir „LibreOffice“ bendradarbiauti konkrečiais sąveikos klausimais. Tačiau nesuklyskite: kiekvienas, naudojantys „Microsoft Office“ ar „Calligra“ su ODF dokumentais, iš esmės sukurs savo nesuderinamumus. Todėl dabartinė problemos apimtis yra platesnė ir jos tikimasi kelerius metus; tai nėra tik AOO-LibreOffice problema. Mišinys tai išspręstų ilgalaikėje perspektyvoje, tačiau kai kuriuos vartotojus vis tiek priverstų atsisakyti vieno diegimo kitam.
Prieš baigdamas šį ilgą įrašą leiskite man atkreipti dėmesį, kad kai viskas bus pasakyta ir padaryta šia tema, viskas priklauso nuo dabartinės dalyvaujančių šalių valios ir tikslų. Man gali pasirodyti nemalonu tai nurodyti, bet iki šiol neradau tikros priežasties, kodėl „Apache OpenOffice“ net egzistuoja. Tai nereiškia, kad projekto narius laikote idiotais ar nekompetentingais, priešingai. Bet jei kalbėsime apie susijungimą, kyla klausimas, kodėl buvo sukurti „LibreOffice“ ir „Document Foundation“. Mes tiksliai nežinome, kodėl buvo sukurta „Apache OpenOffice“, o ne korporacinė valia (nuo „Oracle“) licencijuoti turtą trečiajai šaliai („Apache“). Taigi, jei šie du projektai susitiks, reikėtų atkreipti ypatingą dėmesį į tikrąją šio judėjimo prasmę ir išklausyti dabartinius projektų dalyvius. Kai yra susijusi su programinės įrangos laisve, nėra prasmės vengti bendruomenės.