我之前写过关于 Apache 软件基金会 为大规模开源治理提供了典范 的事实。 即使拥有这些卓越的品质，事情仍然会出错。 Apache 为开源贡献者提供了一些最佳保护，但其成熟的规则可能会被熟练的政治家和/或坚定的议程所操纵。 我们可以从他们的经验中学到什么？
在极小部分的 Apache 项目中，出现了一些问题，这些问题似乎源于 Apache 的规则和文化被有意地玩弄。 它们在 Apache 工作中只占非代表性的一小部分，但它们为开源社区如何被玩弄提供了宝贵的教训。 在本文中，我提到了两个这样的项目：Apache Harmony，一个独立于 Sun 创建的 Java SE 实现，现在位于 Apache Attic 中；以及 Apache OpenOffice，它是 OpenOffice.org 项目的继任者之一，该项目在 Oracle 收购 Sun Microsystems 后关闭。
所有规则都是可被玩弄的
我假设任何稳定的组织规则系统都会创建一个与规则数量和它们运行时间成正比的博弈空间。 在 Apache 的案例中，由此产生的失败模式包括以下内容...
共识可能意味着视而不见
Apache 的核心原则是共识。 这是一件好事。 在文化上，Apache 成员不愿阻碍共识，他们认为每个项目都有权在规则范围内选择自己的道路。 当成员确实发声时——这种情况确实会发生——人们会认为表达异议表明愿意亲自参与解决问题。对于大多数情况来说，这是一种很好的方法，但这意味着当失败模式复杂且具有政治性时，Apache 成员可能会倾向于保持沉默，而不是提出异议，特别是当所涉及的项目处于他们兴趣的边缘时。 我曾与许多 Apache 成员谈论过少数失败或失败的项目，几乎所有人都认识到这些项目存在严重问题。 但没有人愿意发声——他们说“这是项目的事情”。 受影响项目的参与者有各种各样的动机来忍受这些问题而不是解决它们，因此他们不愿发声，以免引发进一步的批评。 即使他们这样做（正如 AOO 的 PMC 主席曾经做过的那样），也有一种 惩罚信使 的倾向。 许多 Apache 流程将沉默视为批准，这通常是正确的做法。 但在极少数情况下，当正在进行积极的博弈时，有毒的情况往往会被搁置太久。
多样性很难衡量
当 Apache 的高级成员达成共识，认为一个项目应该存在时，对多样性的期望很容易得到满足。 Apache Harmony 就是一个很好的例子。 虽然提议和启动它的个人确实出于优秀的动机，并且代表了真正的多元化背景，但在一段时间后，该项目变成了一种有效的单一文化，在 Apache 的治理中仍然没有受到挑战。
不参考其从属关系而认可个人的原则意味着很少有人会询问许多贡献者的动机。 众所周知，IBM 和英特尔是该项目的幕后推手，我相信许多（如果不是全部）参与该项目的表面上独立的开发人员受雇于履行最终来自其中一家公司的合同义务。 在项目建立之后，我相信生成一个完整的、可运行的实现不再是这些公司的主要目标。 对于这两家公司来说，维持 Apache Harmony 的目标似乎更可能是施压 Sun Microsystems（当时我在那里工作，并积极代表 Apache 游说他们获得 Apache Harmony 的 TCK 许可）的商业政治目标。
通过熟练的政治参与，这些公司的员工确保了 Apache 的规则在表面上得到了满足，即使客观研究表明该项目缺乏真正的和多样化的社区，或者对完全工作和可持续代码的现实期望。 当 Oracle 收购 Sun Microsystems 并与 IBM 就 Java 许可进行谈判时，社区努力的空洞变得不可避免。 虽然 Sun 之前的工作处于弱势谈判地位，但 Oracle 的强硬市场运作模式意味着 IBM 很快达成了一项新的协议。 其直接和直接的后果是 Apache Harmony 的贡献者消失了，不久之后该项目就被送进了 Apache Attic。
私人政治与透明度
虽然透明度是既定的，但在政治气氛浓厚的环境中，即使项目采取的最终行动是公开的，实际上也可能不会发生。 在某些情况下，可能会依赖项目的私人邮件列表，但我认为博弈更喜欢双边公司关系中受 NDA 保护的安全性。
围绕 Apache Harmony 的参与显然是由 IBM 在幕后策划的，只有公司间谈判的结论——以及实际的技术决策——才公开露面。 为了使透明度有效，每个决策的完整生命周期都需要受到公众的监督。
这也是为什么开放标准需要在开放环境中创建以及在那里维护的原因。 例如。 在某些情况下，私人对话是不可避免的，但 Apache 的格言“如果它没有在邮件列表中发生，它就没有发生”蕴含着巨大的智慧。 即使所有决策最终都以合理的理由公开出现，博弈的可能性也源于对决策背后的理由和完整谈判过程保持私密的容忍。
过度使用 Apache 的私人邮件列表的问题较小，因为每位 Apache 成员都有权查看每个邮件列表。 当对外部干扰的偏执导致 Apache OpenOffice 项目在其 PMC 的私人列表上进行了许多对话时，最终受到了导师和其他成员的干预。 早期关于将项目引入 Apache Incubator 的私人对话更令人担忧。
从属关系有层次
为了扩展透明度问题的一个重要维度，贡献者雇主的隐藏行业政治很容易隐藏在贡献者从属关系与 Apache 无关的惯例背后。 这在围绕 Apache Harmony 的情况中清晰可见； 这也是 Apache OpenOffice 背后的重要动态。
在这两种情况下，IBM 都有一个未公开的动机，希望看到该项目继续进行并被认为是健康的。 我相信他们与合作伙伴进行了谈判，以确保在两个项目生命周期的关键时刻，有许多贡献者表面上独立于 IBM 参与。 这给人一种多样性的表象，加强了项目参与者的其他偏见，认为该项目是健康的。 但在这两种情况下，当 IBM 停止参与时，该项目都变得奄奄一息。
博弈是不可避免的
我必须强调和再强调，长期以来，我一直是——并且仍然是——Apache 软件基金会的忠实粉丝和拥护者，该基金会为开源在商业中的使用增长做出了巨大贡献。 在 Sun，我冒着职业风险为他们辩护和倡导，并且由于他们在绝大多数项目中表现出的卓越表现，我仍然是他们的支持者。
以 Apache 的规模——今天它有超过 350 个顶级项目 和近 40 多个正在孵化的项目——必然会出现一些极端情况，暴露出规模、成熟度和政治重要性带来的问题。 Apache 不太可能在很大程度上阻止这些极端情况的发生； 创建更多规则只会增加可博弈的表面，同时阻碍新项目。 但重要的是，我们要了解即使是最好的社区流程的局限性，并将这些教训纳入新社区出现时的治理设计中。
经验教训
其他人如何在治理设计中解决 Apache 面临的问题？ 这里有四个想法。
- 政治是会发生的； 为此而设计。 在开源兴起之前，Java 社区流程（无论你怎么看）的主要目的是防止大型公司的政治将 Java 的设计从 Sun 的手中夺走。 Sun 看到的威胁 Java 的相同力量将出现在任何开发关键任务代码的社区中。 Apache 制定了出色的措施来处理这个问题，但即使是这些措施也被证明是可被玩弄的，因此这显然是一个艰难的设计要求。
- 透明度至关重要，无处不在。 正如路易斯·布兰代斯大法官曾经指出的那样，“阳光被认为是最好的消毒剂； 电灯是最有效的警察。” 没有正式的流程能够恰当地体现它，但重要的是要对动机和从属关系以及决策过程的透明度抱有期望。 决策的过程可能与决策本身一样重要，也需要记住。 正式的流程不能坚持记录每次对话，但是像 Apache 那样期望开放可能需要一个监察员角色来支持那些怀疑信任正在被破坏的人。
- 动机确实很重要。 询问人们为谁工作不仅是可以的——更重要的是，每个人都对彼此的从属关系和动机有基本的信任。 Apache 创建了一个“无品牌房间”，每个人都完全根据他们个人选择的身份受到对待，但这为滥用留下了太多空间。 四大自由保护社区成员免受彼此既得利益的侵害，但当政治博弈正在进行时，必须进一步采取行动。 你不能强迫人们告诉你他们为什么在那里，但期望它是常识，并将那些没有声明其外在利益的人视为可疑是合理的。
- 项目有生命周期； 为它们做好计划。 寿命终止与失败不同，你可以为此做好准备。 Apache 制定了 一个很好的流程来做到这一点。 尽管如此，有时人们会有否认的动机，你需要确保你在设计中考虑到这种否认，以及项目本身生命周期的结束和其他可预测的 病态。
本文 最初发表于 Meshed Insights，经作者许可在此转载。
2 条评论