特别声明

本文拥有创作共用授权之相同方式共享授权4.0版国际许可协议（Creative Commons Attribution ShareAlike 4.0 International License）授权许可。 开源之道独立精心翻译分享，欢迎同道中人商讨。

打造开源社区领导力

融入到开源社区是需要花费一定时间且付出一定努力的，甚至产品的开发策略也得做一些变化。过去那些传统的、私有的开发需要秘密的进行、严格的层级管理，而开放的开放方法则需要更为开放的环境和共同的价值取向。代码贡献决定影响力和技术方向，而不是官衔、或公司的位置，这是开源项目中最大的特色。

开源项目是在多样化和全球化的环境中所开发而成，它本身拥有属于自身的角色、约定俗成、工具、以及流程。简单地说，每个社区均拥有自己独特的文化、且花时间去建立信任和合作的方式，在开源当中理解相应的文化需要一番努力，这一点无可否认。

本指南诠释了作为一家公司如何在开源项目中打造领导力和影响力，当然这些开源项目可能是该公司在商业上所依赖的而且已经参与到项目中的。在本指南中将会学习到在开源项目的领导力文化和角色、他们是如何做决策的、作为公司又该如何打造领导力、以及在开源社区中成为一个优秀的领导者的几点特征。

为什么要在开源项目打造声望

虽然开源文化是有关协作的，但上游的贡献只是塑造开源项目进展的第一步。 如果项目对贵公司自己的产品至关重要，那么在指导或影响项目方向方面发挥积极作用也很重要。

尽管开源项目已经无数次的证明了自身协作的价值 ，当然尤其是 —— 和竞争对手一起协作的时候，拥有能够影响项目进展的能力很明显超越了竞争对手。这就是为什么要在开源项目中打造和维护领导力是企业的关键战略和目标。说虽然这么说，但是在开源中打造声望可没有那么简单，不是说敲敲桌子就可以的，是需要雄厚的资金实力的。

开源中的领导力文化

作为企业，很自然的会认为开源社区的领导力和公司内的领导力是一样的，天下的乌鸦一般黑。可是越是直觉相信对的事，往往都是错的。

来自 Autodesk 的开放总监 Guy Martin 解释说：”公司往往会想’哦，不错，我们是大公司，为什么我们不将自己排在首位，让社区先做我们的事情？’，随着时间的流逝，他们慢慢会发现这样的思考是错误的。也会逐渐理解想要获得影响力的唯一方式是在社区中赢得，获得信任的唯一方式是做出贡献。”

为什么要在开源领域中获得领导力？ 1.贵司产品依赖于开源软件和技术（而且是来自社区主创的项目）。 2.开源为贵司提供了快速的创新之路，从而让公司专注于客户的增值和燃点。 3.开源统治着软件的生态（换句话说，即“软件正在吞噬世界”）。 4.软件（相比于硬件)是企业的核心价值差异化的因素，它正在重新定义整个行业。

公司领导力与开源领导力之间的异同

虽然在开源项目中获得领导力对于公司在商业领域的成功至关重要，但采用这种全新的产品开发方法往往是违反直觉的，在开始时往往还蛮尴尬。

传统上，私有的开发方式需要秘密的进行，且有着严格的层级管理。然而，在开源的开发方式中，职位和头衔都是毫无意义的，相反，开源的开发更加重视开放和共识。

在开源项目中，代码的贡献才是决定影响力和技术方向的真实情况，这也就意味着不可以在代码贡献中滥竽充数，它必须是真材实料，并以有意义的形式推动项目的进展。

在开始的时候，为上游做贡献以及开放式的协作，那种感觉好像是把自己的储蓄拿出来散掉一样，但是这样的感觉并不是真的，相反，这是思维和行为发生变化的一种错觉，要知道这在创新和经济上都是益处多多。

关于开源的领导力可以从以下几个角度思考：

• 影响，而不是控制
• 透明度是作为众包解决方案的手段，而不是单纯的曝光
• 领导，而不是听之任之

“想要成功的从私有开发转型到开源的头脑和文化中是需要付出时间和努力的，而且要经常隔三差五的提醒自己。”Ibrahim Haddad，三星电子研发副总裁和开源负责人

来自三星的 Ibrahim Haddad 还特意创作了下面的图表供大家做参考:

治理概览

就目前而言，开源社区的治理向导理论水平还差很远，也就是说资料还蛮少，但是这并不意味着社区本身就缺少相应的治理。对于社区来讲行为准则和社区指南都是独特的，但多数时候是说明一些那些行为是受欢迎的，那些行为又是被明令禁止的，而至于治理策略，则会详细的说明该开源项目的政策、组织架构、开发路线图等。维护条款通常是用于一些具体的项目决策，如软件的更新。

但是围绕项目和社区的治理并不能代表公司整体的治理政策和问题。因为开源软件经常会是消费的部分、也是贡献的内容、甚至是商业公司有兴趣的重新分发和产品化的内容，所以，开源治理有必要成为整体 IT 治理的必要的部分。

企业通常会遇到一些相类似的问题，如多个部门是如何采用开源项目的、贡献到上游社区采用不同的方式、内部创建的开源项目也是不同理念。那么开发一个标准集对于这些混乱的场景是很有帮助的。

来自 Autodesk 的开放总监 Martin 分享道：“在 Autodesk，我们对于贡献上游采用的是一个流程，作为一个工程师我将之流程化，我并不希望出现为了只有5行代码的缺陷修复，需要参考 500页的文档，以及十几种不同的流程，所以我与合规团队一起工作，将工作流程简化到极致，以让工程师们可以在合理的时间内完成它。 同样，公司内部创建开源项目也采用了同样办法。“”

每个公司最好在自己的开源治理政策和流程中制定详细的处理法则，从而实现最适合自己公司实际运作的方式;也要实际上反映社区这个层次的最佳治理。但是，请一定注意，不同的开源活动需要制定不同的流程，没有什么”一招打遍天下的功夫”。

一致的治理规划可以有效的防止巨大的版本偏差，以及开源的许可协议、安全问题等。对于利用开源的企业来说，可以帮助确保合规性，尤其是要交付产品的时候。

文化概览

想要拥抱开源的心态非常的急切，甚至迫不及待的想让内部的文化转型，但是，请稍安勿躁，不要因为开源而迷失了自我，但是也不要盲目的将开源社区视为和公司完隔离的境地。

“为了在一个开源项目中发展影响力，你要和一群原来从不认识的组队，他们来自不同的公司，而且有着不同的观点，大多数时候未必同意你！” Gil Yehuda，Oath (Yahoo+AOL)开源高级总监。

是的，说起来容易，做起来很难！在开源社区争论、事情讨论踌躇不前都是非常常见的，所以往往解决办法是通过共识来采取众多方式中的某一种。

Yehuda 进一步解释道：“在开源社区，不同的人来自不同的公司，这其中有一些是共同的目标和共享成果，但是仍有一部分是分歧、争论等内容。”

举例来说，某一些开发者希望增加新的功能来满足一些需求，但是另外一些开发者则不想引进新的功能，只希望保持现有的稳定。新功能也许会影响到稳定性和扩展性，于是就会陷入一场争执，至少会紧张一段时间。

因为社区是没有“独裁者”来做决定的，是通过共识来决定的，所以能够解决问题是非常了不起的，尤其是往某一个方向行进。

如果你在项目中有足够的影响力，那么其中之一能够做的事情就是帮助社区向更为有利的解决方案上发展，如果你具有领导能力并且是社区中值得信赖的成员，那么大家即使在可能对他们产生短期负面影响的决策中也会支持你，因为你对社区有着深厚的兴趣。

当然建立这样的领导力和持续的来维护它，不仅是公司的任务，也是个人应该达成的目标。

Oath 的方法论就是当看到有可能发生争执的情况时，公司会希望开发者参与进去，协助渡过难关。

“在 Oath 会进行积极的探讨，针对这样的情况在公司内部首先会进行各种对话，以想出如何以最佳方式处理，公司会让开发者们分享彼此所掌握和了解的情况，以及他们可能如何解决的。” Gil Yehuda，Oath (Yahoo+AOL)开源高级总监。

同样重要的是要理解领导力取决于人，而不是公司。因此即使是某个独立的开发者受到了Ta雇主的支持和资助，但是独立的开发者并不完全是该公司的“木偶”，如果发生冲突，独立开发者离开这家公司，那么该公司就有失去社区影响力的风险。

如果贵司的某个产品严重依赖于某个开源项目，而在该开源项目的上游贡献者仅仅安排了一个人，那么贵司就有单点故障的危险，必须考虑往该项目投入更多的人，来预防某些不愉快的事情发生。这也就是说贵司应该有多名员工为上游做贡献。而事实上，这点是有违直觉的，因为大多数人的第一反应就是如此的投入人力是的其它公司受益，有点忒不划算，但是直接往往都是错的，如果你不这么做，损失将会更大。

通过平衡工作量，你可以有效的降低某位关键的开发者离职所带来的在社区失去影响力的风险。对于那些积极寻求提高他们在社区建立领导地位的开发者来说，这也是一个有吸引力的计划，因为这最终会提升他们的职业生涯和获得能力。 更多开发人员在此计划中发挥主导作用。

更进一步讲，一家公司可以在内部实施 inner sourcing 来采用开源的实践和原则，这么做可以顺利的完成开源的文化转型，增大创新成功的几率，以及进一步和开源社区建立紧密的联系、树立影响力、吸引优秀的开发者。

简短地说，如果目标是建立和保持领导力，从而对关键项目进行一定程度的控制，那么文化在其所有细微差别以及多个层面都是必不可少的。

以上这一切，不过是希望看官牢记1%原则：

“90% 是被动的参与 —— 这是用户社区； 9% 积极的参与、提及bug、公开的回答问题 —— 这是我们称之为‘贡献者’的占比；只有那1% 是帮助指导项目的方向，并控制项目的 走向，分配bug，做决策 —— 这就是‘维护者’，或者更为简单的称呼：‘领导者’。” Intel/Yocto 项目 Jeff Osier-Mixon 。

每个项目都是独一无二的；要基于项目而采用灵活的法则。

在一个协作的项目中领导力的角色

虽然角色看起来与公司角色和结构类似，但每个项目都是不同的，并由一组特定的社区准则和治理策略进行结构化和管理。请仔细阅读项目的文档、加入实时聊天 IRC 频道、私有聊天、邮件列表等来全方位了解社区的角色是如何定义的、项目是如何组织和管理的。

同时，如下一下领导者角色是较为常见供参考的。

技术领导者

• 提交者/维护者
• TAB/TSC 成员
• TSC 主席或首席架构师
• 文档/技术作家 – “这是一个特殊的维护者”

治理领导者

• 执行总监
• 委员会/分委员会
• 董事会成员/成员代表

运营领导者

• 项目经理
• 社区经理以及布道师

领导力角色矩阵

请记住，尽管这些角色的叫法上和传统意义上的公司的层级管理架构一样，但是他们之间有着本质上的不同。人们不能够从旧的、封闭的模型中的价值、流程和原则一下子就转到新的开源的模型上，在对多方面，他们是彼此对立的，当然也有一点相似的地方。无论如何，开源模式和传统模式在很多重要方面都是不同的，而且是不相容的，你只能选择一种，而拒绝另外一种。

在开源的领导者来说，积极的倡导提高透明度、必须在项目取得进展之前达成共识，这些都是让他们感到舒适的约定，然而，这对于传统意义上的领导者来说，这样的流程和领导风格让他们备受挫折。

为了应对这样的改变所可能引来的冲突或不适，很多公司没有选择正面的解决办法，而是试图逃避这样的局面，干脆和上游社区分离了，fork 代码过来直接在内部搞起来了。那么公司就会面临更大的失败，从长远的角度来看，fork 项目是不可持续也是难以扩展的，越是远离社区的其它成员，那么随着时间的推移，想要从社区的下一个版本中引入修复bug或新的功能，付出的代价就越大。

简而言之，开源是一项社区工作，你如果顽冥不化、拒绝改变，那么所做的任何事情都会让你的工作远离社区，这最终将对你的公司产生不利影响。

如何成为一名领导者

在一个以协作为几乎的环境中想要成为一名领导者，不仅需要人们认可的技能，而且以身作则的战斗在第一线。

“其实很简单，细心的留意社区有哪些工作需要完成，做就好了，如提交或修复bug、回答问题、在技术峰会上在展台做志愿者，等等。” – Jeff Osier-Mixon，Intel 开源社区经理，在开源领导力峰会2017上的演讲

当然了，在开源中是需要特定的技能集的，而且还能用到对的地方，—— 只有设身处地的去进行实际的练习，方能理解大伙的动态，亲手做些一线的实际工作更妙。

换句话说，要成为一名领导者，是需要赢得团队的尊重的。你不可以要求别人的尊重，需要去赢得。

从哪里加入来证明你的实力和赢得领导力

项目的文档会说明如何加入委员会、成为一名维护者、乃至加入成为任何级别的一员，仔细阅读这些文档，找到合适自己的小组，你可以以任何自己愿意的方式参与，最怕的其实是止步不前。

一个人能够发挥影响力的一件事就是倾听，理解，真正尝试在进入之前阅读情况。如果你能养成这种习惯，那么我认为人们会尊重你的贡献并发现你更有影响力，

开源的技术会议也是一个不错的开发者见面的好机会，当然也是建立社区领导力不错的时机。在网络之外，在这些技术活动中进行演示是一种非常值得倡导的一种方式，可以分享你以及贵司的成就以及对开源项目的贡献等。

以 Oath 为例，帮助开发者优化他们的演示技能，甚至对特定的演示进行一定打磨，以保证能够讲台上的成功。熟能生巧，所以开发者做越多的演示，就会越做越好 —— 那么相应的就有更多人认识他们，知道他们的名字，以及更为重要的在开源社区的工作。

贡献到上游会让工程师最大程度的在社区建立自己的信任和声誉。谁都明白，为上游社区修复缺陷对于整个社区都是有益的，这是有目共睹的，大家知道你不仅仅是在自己的内部做这件事，都会认可你的价值。

加入一个项目和创建一个项目的异同

加入一个项目，也就意味着赢得领导力之路阻且长。诚然，它依旧有它自身的优点，比如可以立即马上获得现有社区的成果，而不是自己从头开始。

话说回来，你创建一个开源项目，所要建立的领导力，也未必有人服你。

如果你自己所建立的项目，所有的开发者均是来自贵公司，而且你确实是行政意义上的领导者，同时这也意味着贵司是唯一在该项目中工作的群体。

如果你确实开始了一个项目，那么除了建立领导力之外，坦率地说没有其他人可以加入。 更不用说项目不怎地，或者根本就是与已建立的项目竞争，那就更是如此。

“开始一个项目会花去大量的时间，如果你的代码没有比另外一个已存在的更好的话，不如去为另外一个做贡献，然后赢得领导力！” Guy Martin, Autodesk 开放总监

技术贡献

在开源社区中，捐赠代码是一件严肃的事情。构建项目恰是所有实践的重点所在，借助于很多双手，让工作更加的轻松，且众多的贡献也降低了风险并保证了质量。不管怎么样，代码才是目标。

首要的规则就是：你所贡献的内容对于其他人也是有益的，而不是仅仅为了满足自身需求的。但是需要强调的一点是有用未必都是非常大的进步，小的缺陷修复之类的都是可以的。重点在于贡献是对大伙都有用的，而无关乎大小。

Ibrahim Haddad 先生还建议贡献者应遵循正确的编码风格，遵循项目的各种流程工作，提供文档和解释，认真听取反馈，并耐心等待接受。

雇佣人才

开源的开发者非常的紧缺是大家众所周知的事情。鉴于开源项目的采用率处于历史最高水平并且没有放缓的迹象，在可预见的未来可能仍然存在这种情况。 这对于公司来讲，不仅意味着很难招聘到熟练的开发人员，而且留住他们也需要采取一些积极的改变。

在2016年，Cloud Foundry 做了一个报告发现，仅在美国就有“25万个软件开发人员的职位空缺，以及需要技术技能的50万个未完成职位。” 此外，分析师预测，开发人员职位数量将“在未来十年内增长至100万”。

对于开源开发者的需求是空前的！

当然你可以在开源社区中找到谁是领导者、谁又是普通开发者、谁又是经验丰富的贡献者，然后直接找到他们并尝试雇佣他们。亦或者你还可以让他们帮助你推荐一些他们愿意在一起工作的开发者。

“如果你打算雇佣一名维护者，或是想雇一名厉害的贡献者，请时刻牢记，这些人被很多公司盯着，而且他们是这个世界做着足够灵活的工作的人，这也就意味着，他们虽然从一家公司换到另外一家公司，但是却在同一个项目中工作，唯一改变的是签署薪水的公司名称。” Guy Martin, Autodesk 开放总监

有心的读者可以从本指南系列的另外一篇 ——如何正确的招聘开源人才，获得更为详细的内容。

培养人才（最佳方法）

非常值得庆幸的是，开源在如今算是炙手可热的领域了，开发者们正在努力的寻找让他们施展拳脚的机会，或者磨炼他们的技能。Autodesk 的Martin 就经常说道，他采访过的每一位开发者都询问他是否可以帮助人们打造自身的开源品牌。帮助开发者在开源社区中赢得领导力不仅在公司一个令人振奋的事情，对于招聘也是极有益处的。

提高自己公司在开源工作中的知名度也可以帮助招募开发人员。有些公司甚至提供开源培训以增加公司的吸引力。 在技术会议上展示公司的开源项目、在社区中贡献代码都是提高公司知名度的最佳方式。 要求你的开发人员与其他开发人员建立联系并邀请他们加入，也往往能够很好地进行。

另外一个吸引开发者关键的方法是提供学徒制，开发者们喜欢在现实当中重要的项目进行大量的打造声誉的挑战，提供学徒制和导师制简直是一举两得的好举措，除了吸引开发者之外，对于激励已有人才也是很实用的。

终上所述，获得社区的信任，以让开源开发者对贵司产生兴趣，而反过来说，作为开发者也希望能够找到值得信任的公司来发挥自己的能力，有望成为开源的领导者。

“与其他任何人一样，具有商业动机的开发人员通过其贡献的质量和数量在项目中获得影响力。” – GitHub 开源指南， 领导力和治理

战略贡献

战略贡献对建立领导力至关重要。因为他们更加倾向于解决整个生态系统中的所共有的问题，亦或者是将项目推动到超越社区目标线。

是的，开源不仅仅只是释出代码，然后就置之不理。还有很多事情需要去做：提供文档、扩展生态、进行广泛的合作以推进项目的代码和工具集，等等。要继续待着这个“游戏”的圈子里，而且要保持透明度和信任感，这才是开源的关键所在。

非技术贡献和支持

除了技术贡献之外，战略和其它的方式的贡献与支持均是进一步打造社区领导力的方式。

其中包括开发者教育、提供导师制等，提供支持是另外一条非常成功的构建领导力之路。

其中的关键，还在于要审时度势，认清现状，看看社区除了技术贡献之外还需要什么，一旦找到了可以贡献的，就大胆的去开干吧！以实力证明自己。

写在最后

总而言之，想要成为一名好的领导者并赢得影响力，需要花费大量的时间，以及辛勤的工作。

除此之外，还有一些“特定的”路径：

• 采用开放源代码软件项目文化、实践和工具，遵循其规则和流程，一定要记住：这无关乎你，它关乎于项目。
• 做一些实际的工作。项目实在是太需要工作的人了，但是不怎么需要全明星，如果你都不能够做一些实事的话，就不可能赢得领导的机会。请尽快的展示你能够做的，然后去做一些哪里需要哪里去的干将。
• 要慷慨大方，去贡献对整个项目有益的代码。
• 构建共识，真正的领导者会构建共识，即使在成为领导者之前，也要努力帮助达成共识，以表明你不是暴君或独裁者。
• 认同领导力是变化着的。以人本身为识别和认同领导力角色，而不是依靠公司或谁是他们的老板。

致谢

本指南的贡献者有：

• Guy Martin, Autodesk 开放总监
• Gil Yehuda, Oath 开源高级总监

这些资源是与TODO（公开对话，开放式开发）小组 – Linux基金会的专业开源程序网络小组合作创建的。 特别感谢那些贡献自己的时间和知识来制作这些综合指南的开源项目经理。 参与的公司包括Autodesk，Comcast，Dropbox，Facebook，Google，Intel，Microsoft，Netflix，Oath（Yahoo + AOL），Red Hat，Salesforce和Samsung。 要了解更多信息，请访问 todogroup.org。我们邀请您在GitHub上下载、传播，如果可以请积极的参与这些指南。