（这是我最近在以色列和伦敦举行的OpenStack会议上发表的一篇演讲的散文版本。对于冗长的内容，我深表歉意。）
在Jonathan最近给董事会的更新中，我们描述了OpenStack迄今为止有2130名贡献者，其中466名每月都在活跃。这是一个令人难以置信的统计数字。毫无疑问，OpenStack成功地吸引了不寻常数量的贡献者，并且对于这样一个复杂的项目，他们的贡献相对容易。
然而，这不仅仅是一场数字游戏。我经常听到有人抱怨说，一个规模小得多、专注的团队可以达到OpenStack所达到的速度。从某种意义上来说，这是真的，但我认为兴趣和优先事项的多样性是像OpenStack这样的社区蓬勃发展的动力。
问题是如何提高我们众多贡献者的整体素质。为了做到这一点，我们需要能够设定期望。我们对贡献者的期望和价值是什么？
我将在这里尝试定义原型OpenStack开发人员。我们应该追求的理想。所有贡献者都应该遵守的标准。
（但是……在这里请容忍我。我只是一个小舌头。）
好的。我们从哪里开始？我们如何开始从我们面前的原始资源中锻造这位英雄？
让我们从基础知识开始。您对各种计算主题所需知识的广度和深度。
打开虚拟化，您可以从KVM开始。您应该了解CPU扩展，例如Intel的VT-x和I/O虚拟化与VT-d和PCI SR-IOV。对基于软件的虚拟化和半虚拟化的历史有一些了解也是很好的背景。现在了解KVM内核模块与用户空间组件qemu的职责。qemu如何模拟各种设备？实时迁移是如何工作的？虚拟机监控程序如何在迁移过程中使用页表标记来跟踪脏页？
如果不详细了解x86体系结构，那么理解所有这些可能就没有什么意义了。理解它与RISC架构的比较不会有什么害处。内存分割、MMU、页表都是有趣的话题。如果不学习一点汇编知识，至少是基本思想，你真的无法进入这一领域。从实际/保护模式到现代PAE或x86-64，了解x86的历史都很重要。不过，请忽略安腾。仅仅了解CPU是不够的，但是，您需要超越并思考CPU如何使用DMA和PCI等总线与外围设备交互。
而且，老实说，如果你走得这么远，你也可以理解基本的数字系统理论，比如如何从一组基本逻辑门构造计数器或寄存器…
哇，我想我有点跑题了。这就是虚拟化。对执行相同操作存储和网络我将把它作为一个练习留给读者。
不过，这只是OpenStack管理的基本资源背后的概念。这很复杂分布式系统，所以你有必要阅读一下这个话题。“法定人数”和“共识”是什么意思？为什么人们把Paxos算法描述为“快速的分布式系统”？当人们将OpenStack描述为“无共享”架构时，他们的意思是什么？他们疯了吗？您如何描述OpenStack的容错方法？
显然，与这一切相关的是需要深入了解数据库和消息传递系统。我们在这个项目上似乎有很多前MySQL顾问，但不要以此为借口。你知道什么是外键和交叉表连接，对吗？你真的需要知道哪种操作可以简单地锁定单个行，而不是整个表。对于消息传递，您可以在那里进行一些研究。我们都是关于OpenStack中的AMQP的，但过去还有一些其他消息传递协议。我个人最喜欢的是CORBA。基于代理、路由器和对等架构的区别是什么？我们在信息中谈论的“扇出”和“主题”是什么？顺便说一句，你知道我们实际上并没有在OpenStack中使用标准AMQP协议，对吗？
此时您不必触及任何代码行。但是，如果你想为OpenStack做贡献，你需要编写代码，对吗？几乎可以肯定的是蟒蛇，但我们也喜欢自己有点猛。对于Python，重要的是不仅要理解最基本的语法，还要理解更高级的主题，如迭代器、装饰器、上下文管理器和元类。您还需要对核心python发行版内外的大量python库有很好的了解。我们需要真正的Pythonistas。哦，我们正在移植到Python3，所以请确保您了解Python2和3之间的区别。
但是等等，等等。这不好。你不能直接进入Python。你需要从C开始。分配并释放你自己的内存，该死。如果你不学习指针，你就无法度过一生。现在学习如何使用线程和各种同步原语，以及为什么这一切都很糟糕。现在学习异步I/O技术；什么是事件循环，如何使用select（）和非阻塞套接字编写单线程服务器来处理来自多个客户端的请求。哦，理查德·史蒂文斯。我的英雄。不要害怕阅读一些RFC。
说到作者，我们忘记了算法。是的，那些。只要仔细研究Knuth的所有三卷。
现在，在返回Python之前，您可能应该使用JAX-RS在Java中实现REST API，使用Ruby on Rails实现web UI。在意识到这不再酷并切换到Node.js之前，和酷孩子们一起玩，把你们的UI移植到Sinatra。
此时，您可能已经准备好为OpenStack贡献一些代码了。但是，我讨厌认为任何人在编写软件时都没有充分了解用户体验设计我们正朝这里驶去。我们不想让囚犯管理收容所，是吗？我们为哪些“人物角色”设计？“作为一名web开发人员，我想启动一台虚拟机来测试我的代码。”
等等，我们忘了工具。如果你不知道自己的工具，你什么都做不了。您将在Linux上完成所有工作，无论是在虚拟机上还是通过在主机上运行Linux。如果你是一个严肃的人，你需要学习emacs。你将与grep和sed成为非常亲密的朋友，所以要学会正则表达式。懒惰和贪婪的正则表达式。您知道如何使用curl进行HTTP POST，对吗？
啊，傻瓜！哦，太棒了吉特! 你对git的了解永远不会太多。这是一份不断给予的礼物。如果你认为我是在开玩笑，那就花点时间了解一下交互式重新基线。重新排序、编辑、挤压和拆分提交！重写历史！你一辈子都在哪里？没有一个git细节太模糊而无法忽略。了解波浪号与修订参数中的插入符号的区别。如何通过在git-push中删除refspec的第一部分来删除分支。强制超越，激动人心！你疯了吗？不？了解git的reflog是如何成为历史的！
（给我一秒钟让我冷静下来，这里）
现在，你必须意识到一些事情。根据迄今为止所学的知识，您可能可以自己编写OpenStack。但这不是这里发生的事情。你是合作。您正在遵循一个过程。我们如何合作以及为什么要遵循某些流程，这是一个比您迄今为止所了解的任何内容都更复杂、更复杂且没有文档记录的主题。
要真正理解我们如何在OpenStack中完成工作，您需要深入了解开源文化。当我们说“粗略的共识和运行代码”或“do-acray”时，请理解我们的意思。
也许可以从关注linux-kernel邮件列表几个月开始，看看争议性的讨论是如何进行的，以及决定谁掌握权力和影响力平衡的微妙之处。如果你对这一切看起来多么不友好感到震惊和震惊，不要担心，你不是第一个。如果这是你从内核中得到的一个答案，那么这段时间花得很好。现在，寻找更友好的社区，了解他们是如何完成任务的。将它们与OpenStack进行比较，并问自己一些问题，比如“与其他社区相比，我们对投票决策的依赖程度如何？”或者“为什么OpenStack中的冲突似乎比其他地方少？”。
开源的历史很重要，它将告诉你如何与OpenStack打交道，反过来也将影响OpenStack的发展。了解“自由软件”与“开源”阵营，以及它们是如何哲学与GPL等版权许可证与Apache、MIT或BSD等许可证的选择有关。您是为了代码用户的自由，还是为了建立协作软件开发社区？您在向OpenStack捐款之前被要求签署的捐款协议–您对此有何感想？
想想不同的治理模型开源社区采用的。了解仁慈的独裁者、项目管理委员会、“承诺”、基于共识的决策以及我们代议制民主模式的利弊。
了解发布过程各种项目使用。基于时间的与基于功能的。具有合并窗口的快速发布周期。计划周期、功能冻结、发布候选项、稳定分支。当涉及到这么多维护人员和软件包时，不同的发行版是如何做到这一点的？我们经常使用Python，他们如何协调发布周期？
这一切都很好，但重要的是不要忽视外面的世界开源。了解极限编程和敏捷软件开发是如何演变的。阅读敏捷宣言。了解这一切与持续集成、持续交付和DevOps的关系。我们的操作环境大不相同，但代码审查是XP配对编程的变体吗？我们的门控主机是否优于传统的提交后CI？
你现在可以考虑接受基本程度的教育。但这足以成为一个有效的贡献者吗？你现在拥有了产生影响所需的一切吗？不，远非如此。最难的是学会成为好人你需要有出色的沟通技巧，当然是英语，主要是邮件列表、gerrit和IRC讨论的书面沟通技巧。我们确实每年在设计峰会上举行两次会议，所以您也需要能够亲自提出并捍卫您的想法。你需要改善你的爱尔兰口音。
不过，除此之外，你还需要了解别人。你需要知道什么时候需要同情，什么时候需要务实，什么时候要教条。什么时候你的补丁上有人的-1可能是一个棘手的否决，什么时候它只是一个“要么接受要么放弃”的建议？什么样的战斗值得战斗？你如何通过帮助你的其他贡献者来建立荣誉点，什么时候是合适的时候来寻求帮助并花掉这些荣誉点？
好的，我们准备好了！我们该怎么做把这一切付诸实践?
也许开始为项目做出贡献的最佳方式是代码审查。您可能每天至少要花几个小时进行代码审查。不仅因为项目中代码审阅者的数量对其速度影响最大，还因为这是开始与其他贡献者建立信任的最佳方式。如果你能在代码评审中表现出你的深思熟虑、敬业和勤奋，那么其他代码评审者会更倾向于优先考虑你的补丁，而不太仔细地审查你的工作。
一个好的代码审阅者能够同时关注小细节，同时考虑全局。尽量不要只在补丁上留下+1，而是写一些评论，说明你考虑过的事情。为什么有人会相信你的+1是2小时仔细分析、研究和测试的结果，而不是仅仅2分钟的编码风格检查？
此外，想想你正在与谁建立信任。作为一名新的代码审阅者，从项目的一些主要开发人员那里为一些丰富的补丁提供有用的输入可能会更有成效。再者，补丁分类也会有很大帮助——在核心审查人员访问补丁之前，发现补丁中的明显问题。不过，别忘了作为代码评审员指导新的贡献者。代码审查是项目面向这些贡献者的一面，也是您展示如何以身作则的机会。
现在，你显然想贡献代码。找到一些需要修复的异常错误，可能是一些在自动测试中很少出现的竞争条件。通过对您所做的所有代码进行审查，您在编码方面获得了极好的品味，您的工作无疑将达到这些标准。别忘了写一条详细、有用的提交消息，并包括一个单元测试，它可以捕获问题的任何回归。如果这是一个更实质性的更改，您必须将您的更改分成更小的部分，每个补丁代表您朝着最终结果前进的逻辑步骤。
如果您正在进行实质性的添加，如新功能或重新架构，则需要在蓝图中详细记录您的设计。确保阅读规范的人能够快速理解您试图解决的问题、为什么它很重要以及解决方案背后的总体思路。然后确保有足够的背景信息包括在内，以便于审核人员的工作。包括用例、任何相关历史记录、相关讨论或错误、考虑和拒绝的替代方法以及任何安全、升级、性能或部署影响。描述如何测试您的工作以及需要进行哪些文档更改。
当我们讨论蓝图时，不要忘记这些也需要审查人员。大多数项目现在都使用gerrit审查与蓝图相关的规范，因此这是一种展示设计技能和捕捉其他人还没有考虑过的东西的方法。
不过，回到代码。是的，为Nova、Neutron、Swift等各种综合服务项目做出贡献很重要。然而，还有许多其他领域始终需要代码贡献。首先，客户项目总是被遗忘。然后是奥斯陆项目正在努力清理的跨项目技术债务。我们还将逐步将所有OpenStack移植到Python 3，这将是一项需要很多人帮助的多年工作。
我们还非常重视OpenStack中的自动化测试，我们拥有的令人敬畏的CI系统并非无处不在。您应该随时准备投入到基础设施本身的贡献中，比如devstack-gate、zuul、nodepool或elastic-recheck等工具。最后但并非最不重要的是，我们的功能测试套件Tempest总是迫切需要更多的贡献来增加我们的测试覆盖率。
安全在OpenStack这样的公共计算服务中至关重要，在这方面有几种方法可以帮助您。首先，有一个小型漏洞管理团队，该团队与每个项目的-coresec团队合作，处理私下报告的安全漏洞，确保在首先向供应商，然后向更广泛的世界协调、负责地披露问题之前，为每个受支持的分支准备好修复程序。重要的工作就是这样。还有一个安全小组，它试图将相关各方的努力结合起来，就非实际漏洞的安全问题编写官方通知，为OpenStack开发威胁分析过程，并维护OpenStack安全指南。他们需要你的帮助！然而，最重要的是，在编写和审查代码时，您需要具有安全意识。如果你睁大眼睛，很有可能在工作过程中发现并报告现有漏洞！
然后有文档，总是任何开源项目中被遗忘的可怜孩子。然而，OpenStack有一些相当棒的文档和一个很棒的开发团队。不过，他们永远不会希望自己处理工作量，所以他们需要你在自己的专业领域投入精力，帮助完善这些文档。
我提到过漏洞.我们不能忘记这些虫子！错误是用户为项目提供有价值贡献的一种方式，我们必须确保这些贡献得到重视，以便用户继续提交错误。仅Nova就有700多个配置选项，该项目不可能单独测试所有可能的组合，因此我们依赖用户测试他们自己的用例，并将任何问题报告为错误。您应该在这里提供帮助，每天留出一些时间对新的错误进行分类，确保提供了足够的信息，并对错误进行了适当的标记、分类和优先级排序。
沿着同样的路线，用户经常与不明显或不一定是bug的问题进行斗争。您还应该关注论坛，如ask.openstack.org或openstack操作员邮件列表。从长远来看，任何可以帮助用户成功使用OpenStack的外联活动都会带来巨大的回报，即使是在您了解哪些问题对真正的用户来说最重要时也是如此。这种联系应该扩展到您参加的OpenStack会议，就您的工作进行演示，并听取用户的意见。
说到邮件列表，我们有一个非常活跃的openstack-dev邮件列表，仅在4月份就有2500多封电子邮件。这是OpenStack中随时发生的所有活动的中心。你真的必须跟踪那里正在发生的事情，并积极参与到可以帮助事情向前发展的地方。这很难跟上，但这真的不是一个选择。
然而，openstack-dev过载的副作用之一是现在发生了许多重要的对话IRC公司。你不能指望所有这些都在身边，所以请确保保持连接并记录所有频道，以便稍后赶上。
因为对话可以分布在多个地方，所以用小面包屑链接所有这些对话会很有帮助。邮件列表线程可能引用gerrit评论，该评论可能引用IRC对话的日志，该日志可能引用博客帖子，该帖子可能引用错误，该错误可能引用引用前一邮件列表线程的前一提交消息。
不过，不要被愚弄，以为IRC是关于严肃的事情。这也是一个你可以在个人层面上了解你的其他贡献者并建立更多重要信任的地方。您将结交在OpenStack和其中一些平台上工作的朋友友谊将比您参与OpenStack本身的时间更长。这在任何社区都是非常积极的迹象。然而，要小心结成集团。我们需要这个社区向最多元化的贡献者开放，而不是所有这些人都会接受以美国为中心的年轻白人男性极客幽默。
谈到派系，人们普遍指责OpenStack开发人员过于自我吸收，以至于忽略了真正的操作员和用户的需求。OpenStack开发人员不对他们所做决策的现实后果负责。“当你带着寻呼机时，你写的代码是不同的”。Lorin Hochstein提出了一个“采用开发人员”计划，运营商可以邀请个别开发人员跟踪他们几天，并在总结、错误报告和蓝图方面分享他们的经验。基本上，你应该抓住一切机会弄脏你的手并提供帮助运行生产OpenStack服务.
与操作员需求相关的是部署、配置和操作工具他们迫切需要与更熟悉软件工作原理的肮脏细节的人合作。许多开发人员使用devstack来部署他们的开发云，但偶尔部署一些更像生产的东西，并为您使用的任何工具做出贡献，都会带来巨大的好处。TripleO是一项值得贡献的伟大部署工作，因为它试图创建一个空间，让所有对部署感兴趣的人都可以在这里协作，同时也因为它密切跟踪OpenStack的开发分支。
一旦你作为一个个人贡献者成功地产生了影响，你应该考虑扩大你的领导不仅仅是以身作则。当然，你会倾向于自愿承担PTL职位在你贡献最多的项目上的责任。为了证明你愿意和值得信任这个职位，也许你会建议PTL将他们的一些责任委派给你。
你的领导兴趣也应该超越单个项目。在某些方面技术委员会与PTL的项目责任同样重要。您对如何、为什么以及何时添加新程序或集成项目有强烈的意见吗。如果不是，为什么不是？
OpenStack的治理和对OpenStack未来方向的共同责任超越了TC和PTL对项目本身的治理，延伸到了基金会董事会保护、授权和促进项目，并确保项目周围有一个健康的商业和非商业生态系统。你在乎技术委员会和董事会如何划分职责吗？或者，在项目的技术决策中，有多少明确的公司影响力是合适的？或者董事会如何做出直接影响项目的法律决定？或者个别成员如何在董事会中选举代表？你应该这么做。
等等，等等，我忘了一堆东西。你应该非常关心如何让贡献者加入进来，并参与很棒的OPW和GSoC项目。跟踪人们对该项目的看法是很重要的，因此你应该阅读任何关于该项目的文章，甚至关注推特上最恶劣的诽谤者。仔细观察我们的主要竞争对手，如AWS和GCE是如何发展的。确保保持相关的新发展，如NFV或Docker。密切关注Stackforge上的新项目，跟踪其发展情况。
啊，等等。你可能是雇佣全职做这个项目，对吗？嗯，你真的需要学会如何戴上上游和下游的“帽子”。你需要了解如何帮助雇主成功实现项目目标。你需要能够调和雇主需求和项目最佳利益之间的任何明显冲突。这不是一个零和游戏。与雇主的客户和合作伙伴会面，帮助交付雇主提供的OpenStack产品或服务，指导同事如何成功参与项目，并成为跨越上下游差距的桥梁。
最重要的是，通过这一切，对你遇到的每个人都要友善，并保持微笑。
BZZT…燃烧警报
我显然是在开玩笑，对吧？任何人都不可能不辜负这些期望并活着讲述故事？
很明显，当你把所有这些放在一起时，这些都是不合理的期望。这个故事的主人公并不存在。我们中的许多人都试图成为这样的人，但这是不可能的。如果你愿意的话，读一读这篇非常个人化的故事，讲述不合理的自我组合期望导致的倦怠。
但事实上，我今天想表达的是，你不需要为了做出贡献而成为英雄。500人远不是太多活跃的月度贡献者，只是冰山一角。为什么每个OpenStack会议的参与者都不能以某种小的方式做出贡献呢？
当指导新的红帽工程师时，我的基本建议总是“找到你的利基”。找到一些你感兴趣的东西，并且你可以看到一条明显的路径，从而产生重大影响，然后深入！忽略几乎所有其他事情，做你自己的事。也许过了一段时间，你会自动开始行动，你现在可以对其他领域产生同样大的影响。或者，你会坚持这个利基市场，并在长期内继续产生影响。
我最喜欢的一个不太可能的利基示例是错误分类。早在2001年夏天，我就开始认真地为GNOME项目做贡献，并成为其CORBA ORB（ORBit）的维护者，ORBit是该项目的另一个新贡献者，名为路易斯·维拉发布了这封电子邮件:
嘿，各位。顺便介绍一下：我是西面的新监督员。正如你们中的一些人可能已经注意到的，我正在慢慢地从bugzilla.gnome中清除evo和RC错误，并将其转移到bugzilla.ximian中。
路易斯继续为GNOME的“错误小组”注入新的活力，帮助建立了一个高效的错误分类过程，并教会GNOME社区如何真正重视和庆祝错误报告员和错误分类人员的贡献。如果你想在开源世界中名利双收，有多少人会选择bug分类作为起点？好吧，路易斯做到了，并产生了巨大的影响，然后转向工程管理，然后全力以赴进入法学院。他现在是维基媒体基金会助理总顾问。
在这个故事中有一个真正的“找到你的利基”教训，但同时也是一个我们作为一个社区需要学习的教训，以真正重视和庆祝贡献者可以帮助项目的各种不同方式。我们作为一个社区，需要更多地同情我们的其他贡献者，而不是根据他们没有做出贡献的程度来评判其他人，而不是因为很少有人分享您对某个特定领域的热情而感到愤怒，无论这对您个人来说有多重要。
我们还需要尝试运行项目的方式，以便适当地识别不同的角色和利基。我们对PTL的关注是否减损了其他人对项目管理的宝贵贡献？官方计划是认识特定领域重要性的唯一途径吗？如果程序是唯一的方式，那么我们是否需要更开放地创建程序，只要有一群人围绕某些特定的工作进行了联合？我们是否需要明确地提高那些在我们通常不认识的领域中从事艰苦落后工作的贡献者的形象？我们是否建立了一种文化，过分强调认可，而放弃了我们现在认可人们的一些方式？
问题多，答案少。但希望这能让对话开始。
