开源的成功始于归零

总是付出 110% 的努力?可能不是。以下是为什么“目标归零”可能是更好的成功策略
462 位读者喜欢这篇文章。
Top open source projects to watch in 2017

Opensource.com

“总是付出 110% 的努力。” 我们很多人从小到大,乃至整个职业生涯都听过这句话。虽然从某种程度上来说这是一个很好的建议,但如果走向极端,它也可能会损害我们成功的机会。

几年前,在飞往韩国的国际航班上,我开始阅读 An Astronaut’s Guide to Life on Earth,作者是克里斯·哈德菲尔德上校,他是第一位领导国际空间站任务的加拿大宇航员。这本书彻底改变了我对公司和个人应如何参与开源社区工作的看法。

哈德菲尔德和所有宇航员一样,在能够飞上太空之前,经历了大量的训练、准备和辛勤工作。他从所有这些经历中学到的是,团队动态是任务成功和安全返回地球的关键组成部分。通过这一切,他形成了一套在团队中有效工作的方法,特别是作为新成员。他称这种方法为目标归零。其基本前提是,如果你在最初加入团队努力时就试图付出 110% 的努力(成为 +1),你就会损害自己在该努力中取得长期成功的机会。目标归零意味着你是有能力的,同时学习如何成为团队的有效成员。

这在生活的许多不同领域都适用。例如,我在 Cal Fire 的志愿者工作中就使用了它,在那里,融入整体团队努力以进行防火和灭火是完成工作所必需的。

以下是一些具体的方法,你可以如何在开源项目中目标归零,并着眼于未来做出 +1 的贡献。

做好功课

正如哈德菲尔德在太空计划中发现的那样,也正如我在 Cal Fire 的志愿者经历中所体验到的那样,在你尝试加入或贡献你不熟悉的项目社区之前,做好功课是不可替代的。

以下是你想要确定的一些基本信息

  • 正在使用哪些沟通工具?(IRC、Slack、电子邮件列表、论坛等)
  • 这些工具上的沟通规范是什么?(高层次讨论、深入技术探讨等)
  • 项目遵循什么开发流程?(短期、活跃的发布周期还是更长、更大的发布周期)
  • 项目治理是什么样的?(成功的拉取请求是什么样的,人们如何让代码被接受/审查等)
  • 项目的领导结构是什么样的?(仁慈的独裁者、分布式领导等)

获得这些问题的答案不仅可以帮助你了解项目正在做什么,还可以为你提供一个框架,以确定你可以从哪里开始贡献,以一种表明你是有能力的,但又不会大喊“我是一个 +1;看我!”的方式。

主动承担脏活累活

一旦你对项目和社区有了一定的了解,你就可以开始做出贡献了。以“归零”的方式做到这一点的一个好方法是寻找可能被认为是脏活累活的事情,特别是像以下领域:

  • 文档(开源项目几乎总是缺乏文档)
  • 测试/质量保证(同上)
  • 回答问题(这还有一个额外的好处,可以帮助你更全面地学习代码/项目)
  • 缺陷修复/分类(这些通常具有挑战性,但可能被其他开发人员视为单调乏味)
  • 社区管理/推广

通过专门深入这些领域,你不仅可以在工作中学习,还可以表明你正在努力产生最初的“中性影响”,同时你也在快速进步。现有的项目成员会注意到这一点,你将有助于巩固你的声誉,成为一个想要让项目变得更好的人,而不仅仅是一个想要炫耀自己名声的人。

尊重每一个人

哈德菲尔德讲述了他的同事宇航员的故事,他们从未飞上太空。几乎所有人,他们未被选中的最主要因素之一是他们被认为的“+1 性”。他指出,“远征行为”的概念在太空飞行中至关重要(特别是长期任务)。简而言之,这意味着你需要能够依靠与你一起工作的人,并与他们相处融洽,以完成任务/项目的目标。

这意味着尊重每一个人,无论你是否同意他们在某个话题或一段代码上的立场。记住

  • 专业精神永远不会减分。
  • 批评代码/解决方案,而不是人。
  • 不要像挥舞旗帜一样炫耀你(或你公司)的名声。
  • 理解尊重是双向的(你需要付出才能获得)。

此时,你可能会想,“好吧,当然,这一切听起来都像是常识。” 这里有一个秘密——它确实是;然而,当公司及其优先事项介入开源项目时,有时常识会退居次要地位,让位于公司(甚至个人)认为需要发生的事情。

每个公司和每个人都有一定程度的自负——这是健康且可以预期的。然而,诀窍在于理解,人际关系动态(经常被谈论的“软技能”)是所有协作努力的核心,无论你是在地球上方 249 英里的轨道上运行,在野外火灾指挥所工作,还是为开源项目做出贡献。

在你开始产生 +1 影响之前,你目标归零的能力是你和你的公司在帮助开源项目和你自己取得成功方面的关键优势。

在洛杉矶举行的 开源峰会上,在 Guy Martin 的演讲 目标成为开源归零者 中了解更多信息。

标签
User profile image.
Guy Martin 是 NVIDIA 的开源和标准总监,他在那里与 Omniverse 产品团队合作,帮助他们驾驭开放领域,项目包括 Universal Scene Description、MaterialX 和许多其他项目。他还就开源最佳实践为组织的其他部门提供咨询。

3 条评论

这里有很多好的观点。有人可能会将其总结为“自豪地佩戴你的新手徽章!”
不过,我希望看到的一件事是减少对文档的轻蔑评论:“文档(开源项目几乎总是缺乏文档)”。也许最好说,“开源项目总是可以使用更多更好的文档。” 将指责变成邀请和机会。

感谢 Greg 的评论。我同意“自豪地佩戴你的新手徽章”是一个很好的总结。

我当然不是要贬低文档,只是想指出文档通常不是许多开源项目首先要做的。但我确实喜欢你的措辞,我也同意总是有机会改进开源项目中不仅仅是代码的东西。

回复 作者 Greg P

杰出的文章。你应该写一本关于这个主题的书;认真地。
作为一个长期的 Linux“新手”,我简直对大量的人感到震惊,他们利用自己的“帮助职位”只是为了向别人展示他们有多聪明。
我曾经认识的一位教授过去常常在他的新学期迎新课上以“……我站在这里不是为了向你们展示我知道多少,而是为了展示你们有多大的能力……”开始。
非常好!

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
 

每周在您的收件箱中获取精彩内容。

© . All rights reserved.