成为一名 InnerSource 贡献者（Contributor ）

你正在为你团队的产品实现一个新功能，你需要一些新功能才能使此功能正常工作。与其直接做，不如慢下来先想一想：这个功能是否反映了一个普遍的问题？在共享的业务领域里，你的组织中的其他团队也会面对这种情况吗？是否与你的需求刚好一致？如果有适用的，那么请在你的团队处理之前找到：是否有可以使用或改进以满足需求的共享的解决方案？应该有吧？

非洲有句谚语说：“如果你想走得快，就一个人走吧。如果你想走得更远，就一起走。” 软件开发团队也是如此：

如果你想快速行动，独立行动是个好主意。这样做的缺点是重复造轮子。特别是在重新实现核心逻辑时，重复实现将付出比独立行动所带来好处更高的代价。

与其他团队协作可以分担你的开发成本。就像在开源项目中一样，它可以让你的团队构建比你独立完成的更大的东西。

但每个团队都有不同的产品路线图和规划！我以前尝试过使用共享组件——它们的集成时间总是比我重新实现它们所需要的时间长。这些组件总是在某些方面有所欠缺——我的特性请求从来没有在其他团队的路线图上得到优先权！

与传统项目不同，InnerSource 项目有贡献者这个角色。是的，有时你希望这些共享的解决方案有新功能，作为一名贡献者，你可以自由地查看这些组件的源代码，对其进行修改并使用最终的改进版本。

是的，有时候你会迫切需要在按照你的进度要求修复错误，而这个问题在社区维护团队中没有得到相同的优先级。成为一名贡献者你可以自己行动并为团队修复这个错误。

对于许多人来说，这种工作方式需要改变心态：与其等待功能的实现或bug的修复，不如解决问题。现在有了第三种解决方案。花时间和精力与InnerSource项目一起核对您的需求是什么——然后直接在共享项目中进行更改。因此，除了你的编程技能，你还需要沟通技能，才能在一个内源项目中取得成功——清晰地表达你的需求，并找到一个对你的团队和项目团队都有效的解决方案。

“但是，我可以直接生成项目副本（fork)，在那里进行更改，并避免所有协调工作！”当然，生成项目副本是完成工作的一种方式。但从长远来看，这意味着你要为你的团队维护这个项目副本——并将你的改动推进到项目维护团队做的任何新版本中。将你的更改贡献给项目团队也意味着你可以从他们对组件的深入了解中获益。他们会在你的补丁中发现问题，以防这些问题在生产中显现出来。

如果具备技术和商业上的合理性，贡献者可以提出需求来复用现有组件而不是重复造轮子。他们可以与经理讨论内部开源协同的好处。

那么内部_开源_只是关于_源_代码吗？当然不是。如果你的团队业务依赖于外部组件，你需要确保它得到良好的维护和运行。作为 InnerSource 贡献者，你可以通过多种方式帮助项目维护团队。当你使用组件时发现并报告问题，这是很有价值的贡献。创建或修复测试用例，用来展示哪些不是按照预想方式工作的代码是很有价值的。改进文档也是如此，这样其他人就可以用更少的时间去使用这些项目并为项目做出贡献。支持其他用户，帮助他们进行错误分类也是有价值的贡献。改进构建也是一个很有价值的贡献示例。

总之，贡献无论大小都有着它的价值。这是我为 tensorflow/models 贡献的一个特性，在图中进行了简单的标签更改。

通过本文，你了解了如何成为一名贡献者。我们研究了分享的心态，我们深入探讨了共享解决方案的好处，最后，我们研究了 InnerSource 贡献的范围通常是什么样的。