开源项目是什么_在开源项目之前要了解什么

开源项目是什么

贵公司将内部项目作为开源发布。 恭喜你！ 您知道您的代码已经准备就绪，但是您准备好承担所有新职责吗？

项目作为开源发布后，您的公司不仅要对该项目负责，而且还要对将围绕该项目形成的社区负责。 这通常需要更改开发/构建/发布工作流程。 这与代码本身无关； 涉及使开源项目成功的代码的所有过程和基础结构。

发布开源项目之前，这是您需要了解和期望的。

确定您公司的目标

在继续进行之前，请花一点时间评估您公司发布项目的目标。 该公司将投入大量时间和精力来准备发布该版本，并将投入更多的精力来维护项目和围绕它形成的社区。 尽管这些努力可能是无私的，但公司更有可能期望其投资。

在进入项目及其社区之前，请确保您已意识到这些目标。 采取步骤确保您的公司能够满足他们的要求，不仅对公司有帮助，而且还从总体上帮助了自由和开源软件（FOSS）。 不知道或不满足其开源项目目标的公司完全退出了FOSS的参与，这对任何人都没有帮助。

了解社区的期望

尽管您的公司可能仍掌握王国的钥匙，并决定合并哪些贡献以及何时捆绑发布，但所有开发都必须与周围的社区进行公开沟通和协调。

换句话说，该项目必须根据社区对开源项目的期望而运作。 这些期望包括（但不限于）：

• 所有开发工作（包括错误修复，新功能开发，产品路线图以及关于这些问题的讨论和问题跟踪）都是公开进行的，并与社区进行协调与合作。
• 与代码相关的所有构建过程 （持续集成/部署等）都是公开运行的，并且社区可以访问。
• 该公司接受来自社会各界，其中“贡献”不仅是指代码，但也文档，设计，产品路线图，指导，管理，以及相关的其他问题对项目的贡献 。 必须及时审查和考虑所有文稿，并且必须公开提供反馈。

知道社区是关键

开源项目会产生很多工作，尽管实际上通常只做专有软件开发工作。 尽管如此，仍然需要付出巨大的努力来转换流程和文化，以在开放式系统中有效，高效地工作并支持开源社区。

如果工作量很大，为什么要这样做？

正如我之前提到的，企业通常不会全心全意地发布项目。 他们之所以这样做，是因为他们希望从希望在项目周围形成的社区中受益，但是只有当公司赢得，建立并保持社区的信任时，这些收益才会发生。

这种信任是通过与社区进行公开，沟通和协作来完成所有工作而实现的。 公司做出的任何完全单方面或私人的决定都将违反这种信任并疏远社区。 当社区疏远时，他们离开了（有时分叉代码以从其他地方重新开始）。

无法从消失的社区中受益。 这就给公司留下了一堆开放的代码，但是没有人使用或关心，更不用说不能满足其开源项目时设定的目标。

启动您的公共问题追踪器

项目发布后，所有错误报告（以前的和新的错误报告）都必须在项目的公共问题跟踪器中可用。 这是您需要做的一些事情：

• 将先前存在的错误/故障单/问题移至项目的问题跟踪器。
  • 请注意，移动通常需要脚本。
  • 在进行任何操作之前，请复查所有现有问题，并关闭那些根本没有希望修复的问题。
  • 在将它们移至公共跟踪器之前，请确保从所有先前存在的错误/票据/问题中删除所有专有信息。
• 决定是否将已关闭的错误/故障单/问题移至公共跟踪器。
  • 这是可选的，但可以为将来的开发提供有价值的环境。
  • 在将其公开之前 ，请确保从计划移动的所有已关闭错误/故障单/问题中删除所有专有信息。
• 创建一个新的工作流，以便将所有错误/票证/问题都有效地路由到公共问题跟踪器并通过公共问题跟踪器。
  • 协调和培训所有报告或与错误/故障单/问题互动的公司员工。
  • 如果您使用公开可用的问题报告工具（例如ZenDesk），则新的工作流程必须确保已报告的问题已有效地转移到了公共问题跟踪器，并且报告方（通常是客户）仍会收到他们提供的服务和信息。期望。

准备打开您的产品路线图

项目作为开源发布后，其开发路线图和所有相关讨论将公开可用。

• 关于路线图上的内容（以及原因）的所有讨论和决定现在都必须公开进行，并征询社区的意见。
• 社区反馈应纳入路线图。

请注意：尽管路线图和有关它的所有讨论都是公开进行的，并得到了社区的意见，但除非做出其他调整，否则公司可能仍然对路线图的内容，时间和原因拥有最终决定权 。 应当以尊重项目现在服务和支持的社区的方式来完成此工作。

如果公共路线图包含与专有功能交互或依赖于专有功能的要素，则与项目交互的每个人都必须小心， 不要在讨论公共路线图时泄漏专有信息 。

定义贡献工作流程

项目作为开源发布后，所有对该项目的贡献都必须使用一个面向公众的工作流程 ，无论该贡献来自原始公司还是社区。

这是典型工作流程的示例：

• 贡献者将公共存储库派生或克隆到自己的计算机上。
• 贡献者创建存储库的功能分支，并在该分支上开发其贡献。 这项工作是在自己的计算机上完成的，因此是私有的。
• 一旦他们的贡献准备就绪，贡献者就将他们的贡献提交回公共资源库。 （该过程取决于所使用的版本控制系统和项目的首选项。）
• 该贡献由有资格这样做的社区成员（通常称为核心贡献者）公开审查。 然后，这些人选择合并，推迟或关闭（拒绝）捐款。 如果贡献被合并，则可能是主/领导或其他分支，但这取决于项目的需求和工作流程。

每个项目都必须考虑并决定其特定的捐助需求和工作流程，并在项目的CONTRIBUTING.md文件中将其公开。

不要忘记构建过程

在计划开放内部项目的源代码时，通常会忽略构建过程。 这是不幸的，因为一旦项目发布，构建过程也会公开进行。

打开构建过程时需要确保以下几点：

• 该代码没有专有或仅内部的派生 。
  • 如果存在，它将背叛即将离开的社区的信任。
  • 这也将大大增加合并和维护代码所需的工作。
• 所有构建过程都必须与公开可用的代码（主/头或为构建而维护的稳定分支）一起工作（无论对项目和产品最有意义的是什么）。
• 所有构建工件应在构建完成后立即公开提供。
  • 之后，如何分配它们（例如，推送给客户）是业务决策，但是构建工件（包括最终二进制文件）始终是公开可用的。

支持有关社区治理和工具的公开讨论

项目发布后，所有影响项目或其社区的决定都必须公开做出，包括治理的变化，对工具的调整（例如版本控制或持续集成）以及对通信路径的更改或添加。

这并不一定意味着每个微小的决定都必须发送给委员会或需要整个社区的充分讨论。 通常，从社区中征求建议和反馈并在决策时考虑它们就足够了。

所有最终决定，其背后的原因及其预期结果必须公开宣布，可用，并记录在项目用于此类事务的任何跟踪系统中（通常是邮件列表加上文档系统或Wiki）。

打开与特定项目有关的其他任何内容

您现在知道了：

与项目有关的所有事情都需要公开进行。

项目作为开源发布后，它不再属于公司“ you”，而是现在属于“我们”社区（公司是公司的一部分）。 这意味着必须在所有方面将社区包括在内。

^{非常感谢John SJ Anderson对本文的评论和建议。 本文中的任何和/或所有缺陷都是我的。}

翻译自: https://opensource.com/article/17/6/what-know-you-open-source-your-project

开源项目是什么