一个人可以独自运行一个开源项目吗？

当您为雇主（无论是公司还是客户）编写代码时，通常都知道由谁负责。您有批准PR的团队负责人，决定下一个版本功能的董事和产品经理，以及做出重大决策的CTO和CEO。

使用开源，这些权限可能会变得更加模糊。贡献者是志愿者，可以随心所欲地来去。确定决策制定方式和项目进展的方式称为治理。根据项目的不同，治理方式可能与代码本身一样开放，或者全部取决于单个创始人的领导，有时被称为终身仁慈的独裁者（简称BDFL）。一些人通过绩效和社区投票任命董事会，而另一些人则由公司发起人来挑选他们的人来做出决定。

因为无论在什么时候项目的好意和随心所欲都能大规模地取得成功，都需要做出决定并解决冲突。一个小型项目可以使用无声的共享规则进行操作。一旦项目形成一个更大的社区，则需要写下并明确地做出决策的过程，以便新的参与者知道如何成功参与。 “这是实现任何规模的基本前提，” Drupal首席技术官Tim Lehnen说。

无论采取何种形式的治理，都可以促进开源项目的进展并鼓励做出贡献。 Mozilla首席研究工程师，Rust核心团队成员，编译器和语言的共同负责人Nicholas Matsakis说：“建立既支持贡献者又帮助确保他们看到他们的贡献得到认可的结构至关重要。”设计团队。毕竟，OSS的主要优势在于它能够吸引这么多人。当人们重视他们的努力时，他们就会坚持下去，并且会对项目产生影响。”

Stack Overflow自己的Sara Chipps说：“开源可能具有牛仔文化。”他曾是.NET Foundation董事会和OpenJS Cross Project Council的董事会成员。 “引入护栏时，您要确保每个项目都能获得成功的安全，令人鼓舞和开放的环境。”

我与参与OSS项目的几个人进行了交谈，以了解最有效的护栏是来自BDFL，是一个拥有最终决定权的人，还是与几个人的委员会达成共识。

BDFL风格：戴皇冠的头部沉重

“一生的仁慈独裁者”一词是为Python的创建者Guido van Rossum创造的，大多是在开玩笑，但这个名字却很固定。这个术语涵盖了所有创始人领导的开源项目，包括Linux内核，Drupal，Clojure和Ruby。有大量受欢迎的OSS项目都依靠专门的创始人来管理，因此必须有一些好处。

我在开源堆栈交换中向社区询问了这一点。 “我一直认为BDFL模型介于传统的开放源代码项目结构和传统的公司项目结构之间，”使用bta的用户回答道。 “您拥有OSS的开放性，透明性和一般文化，但只有一个强大的项目经理来做出高层决策并指导整体工作。”

BDFL可以表明项目具有很强的远见，并将长期保持这一远见。 bta继续说道：“它使领导者能够发展并坚持有凝聚力的长期愿景，而不是一系列短命的领导人不断改变计划和方向。” D. SM的另一位用户写道：“如果您在项目愿景方面与BDFL保持一致，那么为BDFL运行的项目做出贡献是有意义的。”

如今，如此众多的流行语言都在BDFL模型上运行，这绝非偶然。 Perl，Ruby，Rails，Python和Scala都是从创建者主导的项目开始的。甚至C ++都有一个创建者Bjarne Stroustrup，他一直是标准委员会的活跃成员，担任语言扩展小组的主席已有24年。 “在语言的早期阶段（“早期”是该语言的前10到20年），至关重要的一点是，要让某人对语言有长期的了解，并在其成功上拥有既得的个人利益，这至关重要。” Ryan Cavanaugh，Microsoft的TypeScript语言的首席工程主管。 “我认为，当今几乎所有广泛使用的语言都始于强大的集中式设计师，这并不是一个巧合。”

有了符合贡献者愿景的BDFL，项目就可以遵循该愿景，并在发布方面取得实质性进展。 “您有一小部分人正在尝试做某事，” DevOps工程师兼Apache软件基金会成员Rob Tomkins说。 “与一大群人，他们必须放慢脚步，他们可以更快地行动，更快地做出决定。我尝试尽可能地保持开放的态度，因为Linus [Linux的创造者Torvalds]取得了巨大的成功。”

尽管Linux Foundation确实托管了许多流行的开源项目，包括jQuery，Kubernetes和具有不同治理形式的Node.js，但Linux内核仍然具有宽松的BDFL结构。 Linux基金会总经理兼战略计划高级副总裁Mike Dolan表示：“ Linux内核遵循一个模型，其中Linus负责监督最终发布细节，但几乎所有决定实际上都是由各自的子系统维护者或子系统组维护者做出的。所有项目都是包容性的，这意味着任何人都可以做出贡献并参与技术社区。”

但是，随着项目的发展，其他贡献者可能会发现自己在某些领域获得了专业知识，有时甚至是非正式的领导。 “在任何大型项目中，围绕各个主题至少总会有一个非正式的权力所在地，” Mozilla的研究工程师，Rust Core团队成员Manish Goregaokar说。 “ BDFL不可能始终无处不在，因此您要做的至少是将他们的角色正规化并使其易于参与。”

看来，BDFL的长期项目可以使领导者成为最终决策者，而不再是处于争吵状态的杂草丛生的领导者。同样的情况也适用于Drupal的创始人Dries Buytaert。 Lehnen说：“ Dries在Drupal中担任BDFL的角色使他成为涉及Drupal软件的任何事情的最终决策者。” “但是，Drupal项目具有比软件变更管理更广泛的治理框架。对Drupal项目的日常贡献已通过同行评审过程进行了审查和接受。” [ed。注意：您可以收听Dries，在最近的Stack Overflow播客中讨论其工作方式的详细信息：]

在某些方面，许多BDFL风格的项目最终都将作为混合型治理运作，而BDFL拥有最终决定权，而以下团队则负责制定细节。 Goregaokar说：“如果大多数权力都移交给其他人群，那么BDFL模型就可以发挥作用，而BDFL则可以让这些人群做出决定。” “这与Rust中发生的事情没什么不同。”

当然，没有人能独自成功，也没有人能完美。卡瓦诺说：“实际上，我认为今天没有语言设计师会坐在山顶上，每隔几个月下来发表声明，然后再回到隐居状态。” “他们正在与尊重他们意见的人交谈，寻找人们提出棘手的问题，并且可能做出比您在名称中的'独裁者'部分所期望的要妥协得多的事情。”

这是您依靠核心人物承担的风险之一。该项目的成功或失败取决于独裁者的实力及其管理复杂技术项目的能力。 Matsakis说：“有些人具有超常的能力，既可以引导讨论，暂缓所需的投入，也可以做出明智的决定。” “其他人，没有那么多。因此，这是您要冒的风险。”

尽管存在一些幸存者对我们认为模型成功的偏见，但我们当然不能轻视该模型的好处。 “没有人谈论过不成功的语言的BDFL，因此我们已经在谈论一个由其职位性质证明了自己的专业知识和智慧的人们。” Cavanaugh说。

Lehnen说：“ BDFL模型的潜在弊端很多，并且与项目创建者的个性不同。”有时候，创始人的个性是问题所在。拥有强大见解，独到见解以及雄心勃勃地推动行业重大变革的人们并不总是最乐于助人。奇普斯说：“这不是一个能很好地反映大多数人的模型。” “他们认为他们是周围通常很难相处的人-不友善，不友好，不受欢迎。但是他们碰巧创造了一些很棒的东西。”

实际上，该模型的大多数问题都来自于依赖单个开发人员，而不管他们的个性如何。如果由于彩票中奖或公交车事故而消失，则该项目将陷入困境。凭借天才的技术能力善于创造新语言的人可能不是一个伟大的人或项目经理，并且不管他们的编程能力或能力如何，他们只是时间和精力有限的一个人。 Matsakis说：“试图独自运行一个项目真的很累。” “我无法想象任何人可以独自尝试运行Rust项目。”

虽然开源项目与企业不同，但企业的软件项目也不依赖一个人。奇普斯说：“即使是初创公司也不是那样工作的。” “人们容易犯错，因此在某些时候，人们要么精疲力尽，要么厌倦工作，要么被要求下台。这是在项目初期的有效模型，因为它可以在扩展时迅速做出决策，并且会崩溃；人们容易犯错，而且会犯错误，而且没有无限的时间。它确实可以防止官僚主义，但是在一定规模上，迅速拉动触发器是不好的。”

近年来，我们已经看到这种模式在逐渐蔓延：范·罗苏姆（van Rossum）卸任，托瓦尔兹（Torvalds）在受到粗鲁，侵略性行为的指控后休息了一段时间。他们增加了额外的决策支持和社区参与。因此，硬币的另一面是什么样的。让我们看一下社区主导的项目有哪些优点和缺点，以及如何通过基金会的参与来改善这一点。

委员会设计

在由BDFL领导的项目可以围绕中央愿景协调贡献者并快速做出决策的情况下，该项目寻求团体的共识，无论是被选出的委员会还是在其中投票的人，或是通过专职贡献赢得特权投票方式的一群人，总是会减慢速度。有时，这种较慢的，可衡量的决策过程实际上可能是净积极的。 Matsakis说：“如果做得好，开放式治理将为您提供巨大的投入，这可以更好地为您的决策提供依据。” “人们可能会贡献出您尚未想到的想法。”

进行这些开放，较慢的对话可以帮助您实现想法，甚至您可能不确定的想法。有时，能够找出错误答案的确定“原因”与找到新的正确答案一样有价值。汤姆金斯（Tomkins）告诉我一个有关他何时对Apache Commons Listserv进行更改的故事。 “我讨论了我们应该保留Apache Maven构建基础架构还是迁移到Gradle，这是Spring Framework的用途。为了进行健康的对话，我试图明确表示我只是在推动界限，并且我对社区所说的没事。每个人都在想，‘不，我们不要搬到Gradle。那是负数。让我们呆在Maven上。’而我当时想，这很有道理。”

有了更成熟的技术，这种思想探索绝对是加分的。来自经验丰富且亲自参与该技术成功的多个开发人员的全新思路可以使它在未来几年保持相关性。卡瓦诺说：“任何一种已经足够成功的语言，足以保证委员会能够决定其方向，首先必须已经“足够好”以证明委员会的合理性。” “共识委员会的慢性不会成为一个严重的障碍。”

Goregaokar表示：“在Rust上，正和思维的趋势很好。” “通常在技术决策中会涉及重大的权衡取舍，但是人们努力寻找正和答案，以表明您也可以吃蛋糕。并非总是可能的，但是如果可行，它确实可以很好地工作。”建立积极，富有成效的对话可能很困难，建立共识并不意味着每个人都参与其中。有时，委员会的决定与总体共识有所不同。 Matsakis说：“大多数时候，我们会以与RFC线程的'感觉'相一致的方式来决定事情，但并非总是如此。”

委员会的问题不仅来自试图建立共识，还来自谁来参加这些委员会。对于创始人领导的项目，这个问题尚无定论。您构建了它，然后运行了它。但是委员会通常是由现有成员选举或选举产生的。对于那些由公司赞助商选择董事会成员的项目，这一决定可能会显得格外烦恼，尤其是对于那些更加理想化的贡献者而言。

委员会风格的治理实际上与BDFL风格存在一个问题：倦怠。如果您认为自己必须做每一个决定都很累，请尝试与一群人一起做每一个决定。 “开放式治理可能很累人，” Goregaokar说。 “有时候人们有很强的见解，而且很难处理受到强烈见解轰炸的讨论。”

BDFL治理重视决定性和远见，而委员会治理重视耐心和同情心。汤金斯说：“人们有其细微差别。” “没关系。您的语气必须格外谨慎和宽容，并且要理解其他国家/地区的人们，因为他们不一定了解这种语言以及我们中某些人的细微差别。您只需要有耐心和宽容，我认为这样可以建立一个更健康的项目。”

当出现多种好的解决方案时，委员会可能会陷入僵局，或者当感觉受到伤害时，委员会就会陷入战斗。这就是为什么现在许多开源项目都属于伞形基础，可以解决这些元治理问题。 Mozilla，Linux，Apache甚至Java都提供了曾经被撤职的监督小组，以权衡这些问题。甲骨文公司Java平台事业部软件开发副总裁Georges Saab表示：“有一个上诉程序，因此，如果有人觉得自己做错了事，或者没有以合理的理由做出决定，他们就会感到不满。”和OpenJDK董事会主席。 “但是我很高兴地说我们不必雇用它。在过去的十年中，我们没有发生过这样的问题。”

可持续有机规范

当然，所有这些治理都是为了确保OSS项目在长期内是可持续的，并且参与者可以感觉到自己正在受到重视并从中受益。为开源做贡献有很多好处，它可以增强简历，使您的技能保持最新状态并与其他开发人员建立联系。但是事实仍然是，这主要是志愿者工作。

汤姆金斯说：“我尽力做到热情和开放，因为真的很难找到提交者。” “外面的每个人都超级忙。每个人都在空闲时间做这些事情。如果我能令人耳目一新地欢迎大家，从长远来看，人们更有可能与我一起工作。”

Bootstrap，Hogan.js等的创建者Jacob Thornton讲了一个经典演讲（警告：咸味语言）。他谈到开放源代码给人造成的损失，尤其是在该项目变得流行时。善政和行为守则可以减轻这种压力。奇普斯说：“开放源代码只是一个令人不快的地方，您可以在其中做出让人喜欢的东西，然后突然有人对您大喊大叫。” “那不是很好。开源治理允许为这些人提供支持系统。”

成功的项目，特别是那些使用开源代码构建关联业务的项目，可以找到公司投资者。这些小组可能会提供财务或技术支持，但他们也可能开始歪曲项目的任务。 “对我们来说，一个重要的教训是将业务和技术工作的治理分开。” Dolan说。许多公司在其解决方案中使用OSS并产生实际收入。他们很快意识到需要回馈。另一种情况是，他们将花费太多金钱来维持与上游社区不同步的项目代码库。这就是我们许多项目找到可持续发展的周期，并希望取得长期成功的原因。”

这些管理规则不仅使贡献者对其所做的工作感到满意；它们还有助于确保项目朝着有益的方向发展。不管样式如何，大多数项目都有一个提案和RFC流程，可以根据需要调整任何新功能。 “对于我们来说，重要的是，我们今天要添加的任何功能都可以满足具体需求，而不仅仅是以推测方式添加到该语言中，” Cavanaugh说。 “一旦我们对功能建议感到满意，最后一步就是实施它，然后我们可以尝试一下，找出所有可能的情况，并确保我们已经创建了将永远成为一个好东西的东西。除了语言。”

Linux基础可能是当前治理的黄金标准。他们起步很早，从根本上创造了现代开源理念。 Linux操作系统设想的代码贡献就像集市，而不是大教堂。也就是说，任何人都可以贡献力量，而不仅仅是选民。由于他们很早就开始开源，因此随着时间的推移，他们已经获得了丰富的经验。 Chipps说：“将Linux基金会作为父基金会是治理的一个很好的例子。” “由于它在很多方面都失败了，因此必须在所有工作上都变得更好。它开始是一个对抗的地方。现在官僚机构太多了，这是不可能的。”

多兰同意：好的决定来自经验，经验来自于破坏事物。 “我们当然是通过做事，破坏事情以及必须帮助解决这些问题来学习的。这不仅适用于软件，还可以对治理本身进行建模。我们还聘请了开放源代码专业人士，他们在进入Linux Foundation之前已经建立并破坏了许多东西，并在我们建立新社区时将这些经验带到了桌面。”

像代码本身一样，开源项目及其治理仍在进行中。它仍在弄清楚什么是治理模式，以及如何将所有志愿人员的捐款变成可持续的模式。但是他们已经改变了世界，并将继续与世界一起改变。