怎么成为开源贡献者_使开源成为时尚

怎么成为开源贡献者

2015年3月，总部位于柏林的Zalando领导将公司的整个技术团队聚集在一个时髦的地下技术俱乐部（毕竟是柏林）中，并宣布了一种新的工作方式-称为“ 激进敏捷性” 。 受丹尼尔·平克（Dink Pink）的Drive ，布莱恩·罗伯逊（Brian Robertson）的Holacracy系统和敏捷运动的启发，激进敏捷性强调Drive要求自治，精通和目标作为公司技术战略和文化Struts的呼吁。 有了这个新框架，Zalando可以更有效地从电子零售商转变为在线时尚平台。 从上至下的命令和控制到敏捷； 从停滞不前的Java整体到可扩展的，技术上具有挑战性的微服务架构，该架构支持多语言开发方法。

正如您可能期望的那样，从如此重大的文化转型中，Radial Agility彻底改变了Zalando的开源开发工作。 在那之前，我们的GitHub活动非常少：一些围绕PostgreSQL项目，在公司年度Hack Week之一期间出现的监视和警报解决方案，以及由多产的开发人员在云团队中创建的一些Python项目增加公司的产品。 Radical Agility赋予了工程师自由和鼓励选择和使用技术（包括开源）的权利，他们认为这对于完成工作或构建自己的软件（如果不存在）是必要且最佳的。 技术规则的采用鼓励微服务，RESTful API和AWS等云技术的使用，将它们释放出来进行试验。 我们的许多工程师认为这是他们职业生涯中第一次有人信任他们做出自己的决定。

在2015年剩余的时间里，围绕特定的编程语言，开发类型，方法，AWS使用，Web开发和其他主题，形成了数十个新的非正式技术协会。 与平台/基础设施工程负责人一起，我创建了一个新的开源协会，并与大约20名常规工程师一起参加我们的双周会议，我们编写了“如何开源”指南的初稿。 这些准则在事后看来是非常初级的，但涵盖了以下基础知识：哪些使用许可（MIT），版本控制，创建维护者文件等。我们与组织的其他成员共享这些准则，并将其作为现成的文档，始终作为主题随着我们了解更多而改变。

同时，在github.com/zalando上发布的项目数量激增至数百个。 我们的团队表现出对开源的热情，引导行会接下来制定了一套“开源优先”原则，以制度化这种开放性。 这些原则鼓励我们的工程师共享他们的代码，而不是将其隐藏在私人仓库中，以及“获取所有权”，“安全”，“提供文档”和“寻求帮助”。 通过鼓励精通，团队自治和端到端交付项目以及扎实的Craft.io，该消息加强了“激进敏捷性”的基础。

自然地，改变一种文化所需要的不仅仅是创建和发布指南和原则。 当您与一个快速发展的，正在经历重大组织变革的分布式组织一起工作时，使每个人都处于最新状态可能会花费一些时间。 急速敏捷之前，许多Zalando工程团队一直在这样的环境中工作：期望他们执行功能性任务，执行领导/经理所说的一切，或两者兼而有之。 这种文化可能对交付速度有好处，但它并不鼓励工程师参与他们正在构建的产品或独立解决问题。 我们在GitHub上的项目反映了这一点。 培育产品思维定势的开源协会成员开始抱怨，我们与世界共享的工作通常对我们自己以外的任何人都无法使用。

快速浏览我们的GitHub存储库可发现质量参差不齐。 有些项目是开箱即用的，并且吸引了用户或外部贡献者，但是我们的总体输出表明，我们并未反映出“开源”对我们团队的意义的统一定义。 我们已经使用GitHub API和每月入职小组的人才来生成实时指标仪表板，向我们显示哪些项目最受欢迎，以及其他一些数据点。 但是更深入的了解表明，许多工程师在没有README的情况下发布了回购协议，没有邀请投稿，也没有阐明他们工作背后的“原因”。 许多项目紧密依赖我们自己的独特系统。 由于要跟踪的项目如此之多，缺乏对我们作为技术组织正在做的事情及其原因的透明性和洞察力。 尽管我们的开发团队呈指数增长（自Radical Agility的发布以来增长了3倍），但我们的GitHub活动现在分散在组织中的许多不同团队中，仍然没有官方监督。

2016年1月，我成为Zalando的开源宣传员，并开始指导我们的技术团队制定一致，开源有效的战略。 拥有300多个项目，并且还有更多的项目，从哪里开始呢？ 我的头几个任务之一是在GitHub上发布操作方法，并开始提高内部意识。 上班几周后，我去了FOSDEM并遇到了其他更有经验的开源福音派，例如GitHub的Brandon Keepers和PayPal的Duane O'Brien。 这些专家为我提供了一些宝贵的反馈意见，说明如何鼓励工程师在开源工作中实现最大价值。

为了全面了解我们在GitHub上发布的内容，我在GitHub存储库中挖掘并检出了300多个项目中的每一个。 审核过程花了几个月的时间，并且表明我们发布了很多不是真正开源的工作，即对整个社区有用的即用型。 在一些指导下，我们可以解决这个问题。 但是，这样做需要与项目创建者进行许多一对一的讨论。 幸运的是，我处于进行这种交流的最佳位置，并且可以开始工作了。

我的过程像这样：

• 在我们的GitHub组织上查看给定的仓库
• 评估自述文件以清楚了解项目目的（做什么，如何做，为什么要做这些事情），设置/安装说明以及其他需要了解的知识
• 确保项目得到了积极维护并包含维护者文件
• 查看是否有供稿指南文件，或是否有供稿人的邀请
• 寻找其他Zalando依赖项
• 跟进项目的维护者，询问他们他们的目标是什么，如果他们计划添加自述文件或贡献者指南之类的缺失内容，然后开始帮助他们

有些项目我们根本没有维护或使用，因此在项目创建者同意之后，我删除了那些项目（并且，如有必要，请调查团队以确保我们可以删除而不会破坏任何内容）。 更多时候，我们发布了一些只对自己有用的东西。 在这种情况下，下一步是撤回仓库并在GitHub Enterprise上发布，或者...或...还是什么？ 我们绝对需要降低GitHub组织上的信噪比。 我们希望确保最强大的工作升至项目仪表板的顶部，并且最容易发现。 但是，许多此类项目的创建者确实希望其代码保持公开状态。

正如我们的一位资深Zalando工程师所说，我们的目标是想出一种方法，让我们既尊重他们的愿望，又使他们更有可能“找到很棒的东西”。

解决方案：创建一个名为Incubator的新GitHub组织，以存储那些“开放代码”项目，并仅将Zalando GitHub主组织用于“有趣的东西”。 在向我们的工程师保证可以从一个组织转移GitHub存储库并且风险较低之后，我联系了项目创建者和维护者，并与他们一起转移了他们的工作。 为了澄清原因，我们在“操作方法”中添加了新的部分，以说明主要组织和孵化器之间的区别，以及哪些存储库仅适用于GitHub Enterprise。

当GitHub通知告知我新项目刚刚上线时，我将对其进行检查，以了解它们的即用型和实用性。 如果README尚不清楚某些内容取决于我们自己的系统，或者尚无明确的明确目的，那么我将立即与项目创建者联系，询问他们的项目愿景。 从我们主要的GitHub组织上的300多个项目，到现在的149个项目。 现在，比以往任何时候，我们向公众强调的项目集合都强调可用性，良好的文档编制，目的明确和“很酷的东西”。

完善我们的指南和流程，将它们发布在GitHub上，并与不认识它们的任何工程师一对一共享后，我们的工程团队花了几个月的时间进行调整，而无需任何其他干预。 基于用户反馈（即开发人员的问题或困惑点）不断阐明准则，有助于迭代，以确保准则尽可能清晰。 在HipChat论坛，一对一和会议中，利用“以我们的指导原则为您提供答案！”的方式来回答问题，可以增强信息的准确性。 我还将操作方法​​的关键部分集成到了我的新员工的每月开源演示中，以便他们知道我们的流程并知道在哪里找到问题的答案。

在过去的几个月中，我的开源福音的重点已经从基层提高认识和转移回购转移到与项目创建者合作以推广他们的伟大项目。 Zappr背后的工程师是GitHub集成，可增强工作流并使团队能够执行回购要求，并将其项目从黑客演变为正式的GitHub集成。 Patroni （PostgreSQL高可用性解决方案）和Connexion （API First Python Flask框架）也已经发展成为具有外部贡献者，技术媒体报道和社区支持的强大项目。 开发人员会完成大部分艰苦的工作； 我主要向他们展示机会之门在哪里打开，并在他们需要任何帮助时引导他们越过门槛。

公会的持续工作提高了人们对我们交付社区可以使用的开源产品的方式的认识。 公会成员是以民主，实用的方式在我们的100多个交付团队中推动和塑造开源文化的关键。 我们每两周讨论一次项目，社区管理，许可，行业趋势和其他相关主题，并滚动列出工程师提出的主题。 不在我们柏林技术总部的同事可以通过Google环聊加入。 我们会在那里对我们的操作指南进行任何更改，然后通过Google Docs进行文档记录，并与广泛的Guild成员共享（他们现在占我们整个技术组织的20％左右）。 我们收集评论并互相挑战。 然后，经过大约一周的审查和审议，我们将新的更改纳入了操作方法中。 这样，我们的开源文化仍然是草根和有机的，即“ Radally Agile”。

翻译自: https://opensource.com/open-organization/16/11/openness-fashionable-zalando

怎么成为开源贡献者