本文转载自微信公众号「计算机世界」，作者 Scott Carey 。转载本文请联系计算机世界公众号。
BBC：重复利用代码以加快功能交付
英国广播公司(British Broadcasting Corporation)在过去四年中有机地发展了一种内部开源文化。它使内部团队更紧密地联系在一起，实现了更好的跨部门协作，并推动了更高效的软件开发周期。
特别是在电视应用程序团队中，他们专注于时下流行的iPlayer和Sounds应用程序。在这个团队中，开源已经被很好地理解且运用，因为该团队在2012年就已经把自己的TV应用层打造成开源状态。但这种做法在其他团队中其实并不太常见。
“我们已经是开源的大消费者了，当我们开源自己的软件时(比如：电视应用层)，真正推动了内部开源文化，” BBCiPlayer和Sounds应用软件工程团队负责人Tom Sadler说，“内部开源在10个从事电视应用程序开发的团队中诞生是必然的，因为这些团队之间能够进行协作非常重要。”
例如BBC于2020年3月推出的 Sounds on TV 。这是一款用于智能电视的广播应用程序，得益于内部开源文化，它能够比预期更快地进入电视应用市场。因为这些团队通过内部开源重新利用了之前iPlayer 电视应用程序的代码，而不是从头开始设计。
通过经常跨团队地使用一致的拉取请求和持续交付流程，软件开发的内部开源方法开始传播开来。“与其需要一个团队专门为我们做事，我们转而与其合作会更好。”Sadler说。
那么，BBC如何处理和批准变更?归根结底是公司内部对构成重大或次要变更因素的判断。对于微小的变更，内部团队之间会有不约而同的信任。对于更重要的变更，BBC 遵循类似于Rust编程语言等大型开源项目的变更请求流程。也就是说，在此过程中，任何会直接受到该变更影响的人都可以在实施更改之前进行评论和建议更好的替代方案。
这种文化在新冠肺炎疫情期间为企业带来了好处。因为当开发人员团队在远程工作时，异步协作至关重要。Sadler说，“在新冠肺炎疫情期间，拥有实施拉取请求的心态、保持在 Slack 和 Teams 上对话以及实施跨团队决策的机制确实对我们有帮助。”
Asos：PR (拉取请求)不应该有特殊
四年前，在线服装零售商Asos在其大约70多个工程团队中建立内部开源时，并不具备大的优势。Asos 的架构和工程总监Dave Green表示：“这些团队现在是DevOps、敏捷的，拥有自己的应用程序并具有良好的自主性，因此我们看到了加速跨团队交付的机会。”
通过加速发展跨团队的内部开源思维，Asos能够打破一些部门各自为政的现象，鼓励代码重复利用，并给予代码更多的关注以提高质量。“我们想拆除壁垒，这样我们可以互相看到彼此。组织之间这样的透明度和良好的沟通使我们能够在Asos内部建立社区。”Asos 的首席工程师 Tony Gorman 说。
“我们的想法是让代码更好，实现更多功能，也尊重代码所有权的观念，因为每个人在不同方面都对代码开发都很重要，所以清晰透明地做事是很关键的。”他说。
然而，这并不意味着一切都一帆风顺。“这是一个过程。当你知道会有其他人会看到你的代码并做出贡献时，你编写的代码与仅在内部使用时编写的不同。文档和自动化是关键。”Green说。
Green和Gorman表示，在早期并没有产生太多的错误，但发生过这样一件事，一名工程师在决定去度假之前不遵循适当的流程就推出新功能。“这引发了一场激烈的争论。”Gorman说。
这个过程被Asos总结成一句口头禅：“PR (拉取请求)不应该有特殊。”通过使用 GitHub和Microsoft Azure Repos，以及Slack和Microsoft Teams等协作工具，Asos的工程师可以安全地以内部开源方式工作，跨团队协作在Asos已成为常态。
现在，Asos 看到内部项目的这种内部开源发展方式也可能值得回到社区发展。“我们希望有所回馈。”Gorman说。
从哪里开始进行内部开源
许多工程师都指出，PayPal是开始使用内部开源的黄金标准。
其他有用的内部开源入门资源包括电子书《Getting started with InnerSource》和《Adopting InnerSource》。
也可以查看InnerSource Commons中关于内部开源话题的活跃社区，其中包含博客、维基、Git存储库、YouTube上的学习路径系列视频、用户故事和经典模型。
作者：Scott Carey 是IDG UK Enterprise Titles的编辑，主要为InfoWorld撰稿。
原文网址：
https://www.infoworld.com/article/3638692/inner-source-in-the-enterprise-gains-momentum.html
