將LibreOffice和Apache Open Office放在一起-個人觀點（由Charles-F。Schulz撰寫）

幾天之後，隨著我們接近LibreOffice項目四周年，一個古老的主題在互聯網上重新出現： Apache OpenOffice和LibreOffice應該會面。 我想分享有關該主題的見解，儘管我認為這並不重要，但即使LibreOffice和Apache OpenOffice的開發人員並沒有真正考慮合併，也是如此。 在開始之前，請允許我提醒大家，以下是我的個人觀點，不是文件基金會，民主黨，政府的觀點。 我的判斷力明顯偏頗； 我什至是一個參與的黨。 但是我在這些問題上也比較有知識，我認為您也想閱讀 這篇文章 由Leif Lodahl撰​​寫，以使我的評論內容更符合情境。 首先讓我澄清一下，將兩個項目放在一起是一個固有的政治概念，涉及幾個問題。 其中，以下內容：

1.我們將如何見面？

宣布LibreOffice項目時，該項目要求Oracle加入，並將該品牌的所有權轉讓給新項目。 效果不好。 甲骨文等待了很長時間才決定將其品牌以及OpenOffice.org的代碼授權給Apache軟件基金會。 這裡有一個重要的觀點：Oracle對這些資產進行了許可。

他沒有給他們或把他們賣給ASF。 從一開始就無法確定是否會放棄“ OpenOffice”品牌，而使用LibreOffice將是該品牌。 即使不是這樣，它將如何運作？ 我們會以兩個品牌發布相同的軟件嗎？ 用兩個不同的名稱發布兩個不同的版本？

2.我們將要收集什麼？

這就是許可部分的來源：選擇許可也許是實現統一的最大技術障礙之一。 一方面，由於其許可證（LGPL和MPL），LibreOffice代碼庫可以接受根據Apache許可證獲得許可的補丁程序，但相反的做法則更為困難（儘管可能並非絕對不可能）。 在統一的情況下，這種受限的代碼流將是決定性的，因為它將導致在我們保持文檔基金會的當前許可方案不變的情況下，停止在Apache許可下對任何新補丁的許可。 我的猜測是Apache Software Foundation不會允許這種情況發生。

3.我們在哪裡見面？

換句話說：在哪個存儲庫中？ 哪裡？ 我們是否將ASF的SVN存儲庫或Document Foundation自己的基礎設施與Git一起用作版本控制的首選系統？ 也許第三方（現有的或臨時創建的）是另一種選擇。

4.誰？

誰將成為決定性政黨是另一個敏感的問題。 一方面，文檔基金會將是各方之一。 根據統一的類型（如下），某些討論領域將不在文檔基金會的章程中進行討論，這會使事情變得複雜。 除了Document Foundation和Apache Software Foundation，Oracle可能至少是另一方。 顯然是IBM。 話雖這麼說，但尚不清楚社群在此問題上的聲音是什麼：那麼，文檔基金會將是唯一直接代表其成員，LibreOffice項目的個人貢獻者的實體。 ASF所做的相同，但是Apache OpenOffice僅佔整個ASF社區的一小部分。

5.我們想要什麼樣的統一？

除了上面提出的特定問題之外，該問題還具有更廣泛的含義，因為它指出了兩個項目的假設統一的實際原因和含義。 我們是否要在新結構中混合使用相等的零件？ 那可能嗎？ 我在上面強調了幾點，這表明這種情況在技術上將是困難的。 我們是否希望在ASF和AOO上建立LibreOffice？ 顯然不是我，但是之前已經有人問過這個問題。 我們為什麼要這樣做？ 這是可能的？ 許可差異表明需要廢棄特定的LibreOffice貢獻。 最終，這意味著LibreOffice將溶解於AOO並消失，而所有工作卻一事無成，並且鑑於兩個項目之間的大小差異，這就像大象試圖通過一把鎖。 我們是否希望在LibreOffice上建立AOO？ 關於許可證，這是可能的。 ASF會想要嗎？ 我不知道。 我認為可以容納文檔基金會。 我們以前曾見過大規模移民的浪潮。 我們當然可以加入AOO團隊。 基本上，每個項目的貢獻者都是法官們用腳投票。 這是Document Foundation，Apache，Oracle或IBM無法控制的。

6.我們將實現什麼？

當舊的OpenOffice.org項目的成員用來與Sun Microsystems的人員討論該項目的未來時，他們經常聽到相同的問題：“告訴我們，為什麼OpenOffice.org的基金會可以幫助解決該項目的問題？” 毫無疑問，贊成基金會的任何觀點都被拋在一邊，提出了不涉及獨立基金會存在的任何其他解決方案。 它曾經根據理性的觀點完美地說明了實際結果與預測結果之間的差異：兩者不一定互補。 具有諷刺意味的是，現在我必須問一個相同的問題：“統一為什麼能幫助解決任何項目的問題？” 我將快速列出令人關注的領域和問題，這些問題和問題通常是將兩個辦公套件組合在一起的原因：

• 普通品牌/較高的品牌資產
• 每個人都可以為相同的代碼庫做出貢獻（是的！）
• 有兩個類似的辦公套件毫無意義
• 不再存在互操作性問題

較高的品牌資產曾經是2010年和2011年的一個很好的論據，也許是最好的論據。我在開始這篇文章時指出LibreOffice項目的創始人已積極尋求Oracle同意在新項目中使用OpenOffice。 現在，距LibreOffice項目成立四周年僅幾小時的路程。 該項目進展順利。 仍有許多工作要做，但它已經超出了許多人以前想像的可能性。 儘管LibreOffice品牌在2010年和2011年從零開始，但情況有所變化。 顯然，OpenOffice擁有一個知名度更高的品牌，因為它利用了其舊項目已存在10年的優勢。 很遺憾地說，Apache OpenOffice除了它的存在之外，在這項成就中沒有什麼優點。 但是，LibreOffice作為一個品牌已經建立，其品牌資產在世界各地都在增長。 銷毀這些品牌中的任何一個都會帶來一些痛苦的後果。 我們真的想要這個嗎？ 有沒有人有可行且可持續的品牌過渡計劃？ 我還沒聽說過

通用項目可以貢獻相同的代碼庫，從而使其成為“更好，更強大”的辦公套件這一事實值得商bat。 LibreOffice通過兩個套件的許可規範從Apache OpenOffice獲得了所需的東西。 但是從純粹的貢獻來看，Apache OpenOffice幾乎沒有提供LibreOffice。 另外，兩個貢獻者團隊的規模如此之大，以至於AOO開發人員的加入對LibreOffice而言意義不大，反之，事情將會很有趣。 但是，這意味著我們再次打算與納稅人一起打仗，就好像我們在測量團。 社區成員隨心所欲地來去去，統一併不是我們所有人都必須尋找的東西。

當然，擁有兩個類似的辦公套件幾乎沒有什麼價值，儘管這是軟件自由的基本表達，僅此一項就足夠了。 我們也有150個Linux發行版，如果我們環顧四周並採用這種思維方式，我們將希望與Calligra，Abiword和Gnumeric結合使用。 那也沒有任何意義。 但是請記住，AOO和LibreOffice都沒有尋求“相似”，儘管受到了普遍的歡迎，但它們每個季度都以截然不同的方式增長。 對於Calligra來說也是如此，這是一個使用完全不同的代碼庫開發的項目。 簡而言之，克隆可能沒有多大意義，但是選擇是一個好的選擇，尤其是當選擇涉及實際差異時。 現在，AOO和LibreOffice之間在功能，文件格式支持，生態系統和工程流程方面也確實存在差異。 隨著時間的流逝，這兩個套件之間的選擇變得更加清晰。 我們不應忘記，當我們想像自由軟件和專有軟件之間的競爭時，我們並不是在暗示雙方都應該只有一個選擇。

最後但並非最不重要的一點是，各種消息靈通的各方都提到互操作性問題是一個問題，並且從根本上說，這是採用ODF等開放標準的障礙。 儘管這是一個複雜的問題，但從某種意義上說，在特定情況下可能會遇到的問題往往會引起麻煩，但它也不是一個非常關鍵的問題。 這些通常涉及使用OpenOffice.org或AOO以及LibreOffice的用戶群，以及已經遷移到ODF的文檔。 實施中差異的增加總是導致文檔演示中的視覺差異（儘管沒有數據丟失），從而給用戶帶來挫敗感和不適感。 解決這些障礙的唯一可能的方法（除了謹慎而費力的遷移專家負責）之外，還要讓AOO和LibreOffice在特定的互操作性問題上進行合作。 但是請不要誤會：任何將Microsoft Office或Calligra與ODF文檔一起使用的人，基本上都會產生自己的不兼容性。 因此，目前的問題範圍更廣，預計已經持續了幾年。 這不僅僅是一個AOO-LibreOffice問題。 從長遠來看，混合可以解決此問題，但仍會迫使某些用戶放棄一個實現而放棄另一個實現。

在結束這篇漫長的文章之前，我要指出，在就這一主題進行了一切論述和完成後，一切都取決於有關當事方的當前意願和目標。 似乎沒有給我指出這一點，但是直到今天，我仍然沒有找到Apache OpenOffice甚至存在的真正原因。 這並不意味著您認為項目成員是白痴或無能，相反。 但是，如果我們談論統一，那麼就會產生一個問題，即為什麼要創建LibreOffice和Document Foundation。 我們不知道為什麼要創建Apache OpenOffice，這超出了（從Oracle）將資產許可給第三方（Apache）的企業意願。 因此，如果要滿足這兩個項目的要求，則應密切注意這一運動的真正含義，並聽取當前對該項目的貢獻者的意見。 當涉及軟件自由時，就沒有必要迴避社區。