核心团队
即使一个内源项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。 建立一个核心团队，专门负责处理项目的基本事务。 他们的工作可以确保贡献者能够增加和使用满足他们自己使用场景需要的特性。
- 很难为项目做出贡献。
这可能是由于以下情况：
- 不能在本地运行该项目。
- 糟糕的文档。
- 复杂的代码。
- 测试不充分。
- 难以使用该项目。
一些可能的原因：
- 糟糕的文档（再次）。
- 频繁的bug。
- 不直观的设置。
有一个人人都依赖的中心项目。 这是一个多么好的内源候选项目啊！ 不幸的是，这个项目是自然发展起来的，各种贡献和补充功能都是胡乱地加进去的。 现在，它是一个恶心的、厚厚的代码泥潭，没有人理解，每个人都不敢去碰。 很明显，它应该进行一次大修（例如，重构、测试、文档等），但尽管每个人都需要并希望这项工作发生，却没有人投入时间和精力来完成这些事。
许多团队需要这个项目。
- 该项目有大量的技术债务。
- 与团队项目到适配和项目自身的迭代速度比较缓慢。
- 没有一个负责者或维护者对项目和项目贡献生态负责。
- 每个作出贡献的团队都很忙，因此优先考虑那些能给自己带来直接回报的工作。
- 随着项目发展，项目变得越来越难使用和修改是一个普遍的趋势。
组建一个核心团队，他们的工作是进行项目的维护，以便其他人可以很容易地加入到项目中并为其做出贡献。 这个核心团队做的工作对于建立一个健康的使用和贡献的项目生态系统是非常必要的。 这种关键的工作往往不会被常规到贡献所关注。 这类工作的类别包括项目沟通、本地环境适配和DevOps基础设施搭建。
下面是一些具体的例子。
- 产品Bug
- 文档
- 入门教程和示例
- 自动化测试
- CI/CD
- 本地环境适配
- 模块化
- 版本管理
- 监测
- 开拓新的类别/功能类别
上面的每一个条目对一个健康的产品生态都是非常重要的，但是却不太可能被优先考虑。
核心团可以由少数的全职或者兼职的人组成。 这种选择取决于所需的工作量、资源的可用性和组织的文化。 最重要的是，和其他团队一样，赋予他们权利，让他们承担责任，通过这样的方式形成一个核心团队。
由于他们的核心作用，核心团队成员几乎都应该充当 Trusted Committer 的角色（关于这个概念的更多信息，请参见学习路径和模式）。 虽然受 Trusted Committer 的角色主要侧重于帮助他人对项目的贡献和使用，但核心团队成员也会定期对项目做出贡献。 核心团队并没有自己的商业目标来驱动其贡献。 他们根据什么最能帮助他人使用和贡献项目来决定工作内容。
不断提醒核心团队这一目标的一个好方法是让他们定期报告。
- 使用本项目的活跃团队的数量
- 对项目做出贡献的非团队人数。
持续关注这些指标会自然驱使核心团队优先考虑正确的工作，从而围绕项目创建一个繁荣的InnerSource生态系统。
- 它提升了项目的使用性并降低了项目贡献难度。
- 许多团队使用该项目并为其做出贡献。
- 他人对项目的交互和反馈是衡量核心团队做得好与坏的标准。
项目贡献者都只关注自己业务，而不太关心项目的后续的发展，组建一个核心团队，并给他们分配维护项目任务，可以弥补这样的缺陷。 核心团队弥补了这种缺陷，扮演了团队润滑剂的角色，促使项目贡献生态保持健康发展。
- 围绕其可重用的CI/CD流水线，*Nike**实施了这种模式来管理其InnerSource工作。*实施了这种模式，
- WellSky为一个关键项目建立了一个核心团队。这使他们能够显著扩大对该项目的InnerSource贡献--见具有核心团队的广泛应用规模的InnerSource。
结构化