2015 年 3 月，总部位于柏林的 Zalando 领导层将公司全体技术团队聚集在一个时髦的地下 техно 俱乐部（毕竟这里是柏林），并宣布了一种新的工作方式——被称为“彻底敏捷”。受到丹尼尔·平克的《驱动力》、布莱恩·罗伯逊的合弄制系统和敏捷运动的启发，“彻底敏捷”强调《驱动力》中提出的自主性、精通和目标感，作为公司技术战略和文化的支柱。借助这个新框架，Zalando 可以更有效地从电子零售商发展为在线时尚平台；从自上而下的命令和控制转变为敏捷；从停滞不前/不酷的 Java 单体架构转变为可扩展且技术上具有挑战性的微服务架构，从而支持对开发采取多语言方法。
正如您可能从如此重大的文化转型中所预料的那样，“彻底敏捷”深刻地改变了 Zalando 的开源开发工作。在此之前，我们在 GitHub 上的活动非常少：围绕 PostgreSQL 的几个项目、在公司年度黑客周期间出现的一个监控和警报解决方案，以及云团队一位多产的开发人员创建的几个 Python 项目，就构成了公司的所有产品。“彻底敏捷”让工程师们可以自由地选择和使用他们认为必要和最佳的技术（包括开源技术）来完成工作，或者在没有现有软件的情况下构建自己的软件。技术游戏规则的采用鼓励了微服务、RESTful API 和 AWS 等云技术的使用，让他们可以自由地进行实验。我们许多工程师都觉得这是他们职业生涯中第一次有人信任他们自己做决定。
在 2015 年剩下的时间里，围绕特定编程语言、开发类型、方法论、AWS 使用、Web 开发和其他主题，形成了数十个新的非正式技术协会。我与我们的平台/基础设施工程主管一起创建了一个新的开源协会，并与大约 20 名定期参加我们双周会议的工程师一起，起草了我们的“如何开源”指南的初稿。这些指南现在看来非常简陋，但它们涵盖了基本知识：使用哪个许可证（MIT）、版本控制、创建维护者文件等。我们与组织的其余部分分享了这些指南，并将它们作为一份活的文件保存，随着我们学到更多东西，它始终可以更改。
与此同时，github.com/zalando 上发布的项目数量飙升至数百个。我们的团队对开源表现出的热情促使协会接下来制定了一套“开源优先”原则，以将这种开放性制度化。这些原则鼓励我们的工程师分享他们的代码，而不是将其隐藏在私有存储库中，并鼓励他们“承担责任”、“确保安全”、“提供文档”和“寻求帮助”。该信息通过鼓励精通、团队自主性和项目的端到端交付以及扎实的工艺，加强了“彻底敏捷”的支柱。
当然，文化转型需要的不仅仅是创建和发布指南和原则。当您在一个快速发展、分布广泛且正在经历重大组织变革的组织中工作时，让每个人都跟上速度可能需要一些时间。在“彻底敏捷”之前，许多 Zalando 工程团队一直期望在他们被期望执行功能性任务、做他们的主管/经理所说的事情或两者兼而有之的背景下工作。这种文化可能有利于交付速度，但它不会鼓励工程师参与他们正在构建的产品或独立解决问题。我们在 GitHub 上的项目也反映了这一点。开源协会的成员培养了产品思维，他们开始抱怨我们与世界分享的工作通常对我们自己以外的任何人都不可用。
快速扫描我们的 GitHub 存储库显示，质量参差不齐。有些项目开箱即用且有用，并且拥有用户或外部贡献者，但我们的总体输出表明，我们没有反映出“开源”对我们的团队意味着什么的连贯定义。我们已经使用 GitHub API 和我们每月入职小组的人才来生成实时指标仪表板，向我们展示哪些项目最受欢迎以及其他一些数据点。但更深入的调查显示，许多工程师在发布存储库时没有 README 文件，没有邀请贡献，也没有澄清他们工作背后的“原因”。许多项目都严重依赖我们自己独特的系统。并且由于有如此多的项目需要跟踪，因此缺乏对我们作为一个技术组织正在做什么以及原因的透明度和洞察力。尽管我们的开发团队呈指数级增长（自“彻底敏捷”重大发布以来增长了 3 倍），但我们在 GitHub 上的活动现在分散在整个组织的许多不同团队中，仍然没有官方的监督者。
2016 年 1 月，我成为 Zalando 的开源布道者，并着手引导我们的技术团队走向连贯、有效的开源战略。面对 300 多个项目，而且总有更多项目在路上，从哪里开始呢？我的首要任务之一是在 GitHub 上发布我们的操作指南，并开始提高内部意识。入职几周后，我去参加了 FOSDEM，并会见了其他更有经验的开源布道者，如 GitHub 的 Brandon Keepers 和 PayPal 的 Duane O'Brien。这些专业人士就如何鼓励工程师在其开源工作中交付最大价值向我提供了一些宝贵的反馈。
为了全面了解我们在 GitHub 上发布的内容，我深入研究并检查了我们 GitHub 存储库上的 300 多个项目中的每一个。这个审查过程花费了几个月的时间，并揭示我们发布了很多并非真正开源的工作——即对广大社区来说开箱即用的工作。在一些指导下，我们可以扭转局面。但这需要与项目创建者进行多次一对一的讨论。幸运的是，我处于进行此类沟通的理想位置，并开始工作。
我的流程如下
- 查看我们 GitHub 组织上的给定存储库
- 评估 README 中项目目的的清晰度（它做什么以及如何做，为什么做这些事情）、设置/安装说明以及其他需要了解的信息
- 确保项目得到积极维护并包含维护者文件
- 查看是否有贡献指南文件，或者是否有任何贡献者邀请
- 查找其他 Zalando 依赖项
- 跟进项目的维护者，询问他们项目的目标是什么，是否计划添加任何缺失的内容，例如 README 说明或贡献者指南，然后开始帮助他们
有些项目我们根本没有维护或使用——所以在获得项目创建者的许可后（并且，如果需要，调查团队以确保我们可以删除而不会破坏任何内容），我删除了这些项目。更多时候，我们发布了一些仅对我们自己有用的东西；在这些情况下，下一步要么是撤回存储库并在 GitHub Enterprise 上发布，要么...要么...要么什么？我们绝对需要降低我们 GitHub 组织上的信噪比。我们希望确保最强大的工作能够登上我们项目仪表板的顶部，并且最容易被发现。但是，许多此类项目的创建者确实希望他们的代码保持公开。
目标是想出一种方法，让我们既能尊重他们的意愿，又能让一位资深的 Zalando 工程师所说的“找到酷的东西”成为可能。
解决方案：创建一个名为 Incubator 的新 GitHub 组织来存储那些“开放编码”项目，并且只将主要的 Zalando GitHub 组织用于“酷的东西”。在向我们的工程师保证从一个组织转移 GitHub 存储库是可能且低风险的之后，我联系了项目创建者和维护者，并与他们合作转移了他们的工作。为了帮助澄清原因，我们在我们的“操作指南”中添加了一个新部分，解释了主组织和 Incubator 之间的区别，以及哪些存储库仅适用于 GitHub Enterprise。
当 GitHub 通知我新项目刚刚上线时，我会检查它们，看看它们的开箱即用性和完善程度如何。如果 README 没有明确说明某些内容依赖于我们自己的系统，或者如果尚未详细说明明确的目的，我会立即跟进项目创建者，询问他们的项目愿景。从我们主要 GitHub 组织上的 300 多个项目，我们现在减少到 149 个项目。现在，我们向公众重点展示的项目集合比以往任何时候都更强调可用性、良好的文档、明确的目的和“酷的东西”。
在完善我们的指南和流程，在 GitHub 上发布它们，并在与任何不了解它们的工程师进行一对一交流后，我们的工程团队仅用了几个月的时间就适应了，而无需任何额外的干预。根据用户反馈（即开发人员的疑问或困惑点）不断澄清指南有助于迭代，以确保指南尽可能清晰。并且抓住一切机会用“在我们的指南中找到您的答案！”来回答问题——在 HipChat 论坛、一对一交流和会议中——强化了这一信息。我还将操作指南的关键部分整合到我每月向新员工进行的开源演示中，以便他们了解我们的流程并知道在哪里找到他们问题的答案。
在过去的几个月里，我的开源布道工作的重点已从基层意识提升和转移存储库，转变为与项目创建者合作推广他们的优秀项目。 Zappr（一种增强工作流程并使团队能够强制执行存储库要求的 GitHub 集成）背后的工程师将他们的项目从黑客攻击发展成为官方 GitHub 集成。Patroni（PostgreSQL 的高可用性解决方案）和Connexion（API First Python Flask 框架）也已发展成为具有外部贡献者、科技媒体报道和社区支持的强大项目。开发人员完成了大部分艰苦的工作；我主要向他们展示机会之门在哪里敞开，并在他们需要任何帮助时引导他们跨过门槛。
协会的持续工作提高了人们对我们交付社区可以使用的开源产品的方式的认识。协会成员是民主、务实地推动和塑造我们 100 多个交付团队内部开源文化的关键。我们每两周讨论一次项目、社区管理、许可、行业趋势和其他相关主题，议程主题由工程师提出滚动进行。不在我们柏林技术总部的同事通过 Google Hangout 加入。我们在那里提出对我们的操作指南的任何更改，然后通过 Google Docs 记录下来，并与广大协会成员（现在约占我们整个技术组织的 20%）分享。我们收集意见并互相挑战。然后，经过大约一周的审查和审议，我们将新的更改纳入操作指南。这样，我们的开源文化仍然是草根和有机的——即“彻底敏捷”。
评论已关闭。