将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.我们想要什么样的统一？

除了上面提出的特定问题之外，该问题还具有更广泛的含义，因为它指出了两个项目的假设统一的实际原因和含义。 我们是否要在新结构中混合使用相等的零件？ 那可能吗？ 我在上面强调了几点，这表明这种情况在技术上将是困难的。 我们是否希望LibreOffice建立在ASF和AOO之上？ 显然不是我，但是之前有人问过这个问题。 我们为什么要这样做？ 这是可能的？ 许可差异表明需要废弃特定的LibreOffice贡献。 最终，这意味着LibreOffice将溶解于AOO并消失，而所有工作却一事无成，并且鉴于两个项目之间的大小差异，这就像大象试图通过一把锁。 我们是否要在LibreOffice上建立AOO？ 关于许可证，这是可能的。 ASF会想要吗？ 我不知道。 我认为Document Foundation可以容纳。 我们以前曾见过大规模移民的浪潮。 我们当然可以加入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）的企业意愿。 因此，如果要满足这两个项目的要求，则应密切注意这一运动的真正含义，并听取当前对该项目的贡献者的意见。 当涉及软件自由时，就没有必要回避社区。