不久前，我发表了非常受欢迎的1 文章 如何不泡一杯茶。 为了寻找一些可以写的东西，我突然想到我可以写一些我认为几乎与世界和平、进步和博爱/姐妹之爱一样重要的东西：开源项目。 现在有很多关于如何创建开源项目的指南，以至于开始一个新的、成功的、社区支持的项目变得几乎太容易了。 我认为现在是时候纠正这种平衡，并给你一些关于如何不做开源项目的线索了。
扔过墙
你知道它是怎么回事：你是一家大公司，你有一个开发团队为一个项目工作了好几年，你对它非常满意。 维护和改进代码相当昂贵，但幸运的是，你想到其他人可能想使用它——或其中的一部分。 最近，你的一些客户抱怨说很难获得改进和新功能，合作伙伴抱怨说你的 API 晦涩难懂、定义不清且容易发生未记录的更改。
然后你想到了一个绝妙的主意：为什么不开源它，并告诉他们他们的担忧已经结束了？ 你所需要做的就是获取现有代码，创建一个 GitHub 或 GitLab2 项目（最好是在一个属于你的开发人员的《权力的游戏》主题用户名下），创建一个公共存储库，上传所有代码，并发布新闻稿宣布：a) 你的项目的可用性；以及 b) 你是多么伟大的开源公民。
人们会争先恐后地为你的项目做出贡献，你突然就会有数百名开发人员基本上为你免费工作，提供新功能和错误修复！
牢牢掌控项目
然而，当你将你的项目开源时，存在一种危险，即其他人会认为他们有权对其进行更改。 应该工作的方式是，你的产品经理提出一堆需要实现的新功能，并将它们作为问题发布在存储库中。 你幸运的新贡献者然后可以编写代码来满足新功能，你可以测试它们，然后，如果它们没问题，你可以将它们接受到项目中！ 免费开发！ 有时，如果你幸运的话，客户或合作伙伴（在这个过程中除了你之外的唯二重要方）会在项目存储库上提出问题，这些问题在经过你标准的瀑布式开发流程并由适当的产品经理审查后，可以被接受为“已批准”的问题，并被指定包含在项目中。
存在一种危险，即由于你已经将项目代码开源，有些人可能会认为这是一个借口，为你的客户没有注意到的错误编写不相关的功能和修复程序（因此，你可以安全地假设，他们不在乎）。 显然，在这种情况下，你应该拒绝并关闭任何与此类功能或修复程序相关的问题，并拒绝（或只是忽略）任何相关的补丁。
更糟糕的是，你有时会发现开发人员3 抱怨你如何运行项目。 他们可能会“fork”项目，制作他们自己的版本。 如果他们这样做，请注意让你的法律部门对付他们。 有可能，由于你的项目是开源的，他们可能会辩称他们有权创建一个新版本。 更好的做法是让你的公共关系部门对付他们，诋毁新项目，对他们进行人身攻击4 ，并向所有人表明你占据了道德制高点。
拥抱多样性（在许可方面）
你的组织中可能有人会说开源项目不需要许可证。5 不要听信他们的海妖之歌：他们是错的。 你的开源项目需要的是大量许可证！ 让你的开发人员为他们接触的每个文件选择他们最喜欢的许可证，或者，更好的是，让项目经理选择。 开源促进会 维护了一个有用的列表，但将这仅仅视为一个起点：为什么不在你的项目中自由地散布不同的许可证？ 我们一直听到多样性是好的，所以为什么不将其应用于你的开源项目代码呢？
避免文档
有些人认为文档对于开源项目可能很有用，他们是对的。 很少有人似乎理解的是，他们对文档类型的期望很可能被他们之前的经验所扭曲。 另一方面，在你决定将你的项目开源之前，你积累了大量的内部项目文档和外部产品营销材料：这是个好消息。 你所需要做的就是创建一个 docs 文件夹并将所有 PDF 文件复制到那里。 不要忘记在每次进行新的产品版本时更新它们！
避免工具
你所需要的只是代码（和文档——见上文）。 你的内部开发人员已经仔细构建和维护了构建环境，因此，他们应该能够毫无问题地构建和测试项目的任何部分。 许多此类工具都是内部的，可以被认为是专有的，因此详细信息必须保密。 任何真正有用的贡献者都应该能够自己解决他们需要的一切，并且不需要任何帮助，因此提供关于如何在存储库中实际构建代码的任何信息基本上是多余的：不要费心。
对于更“专业”的组织，另一种选择是提供构建环境，允许贡献者批量构建以查看它们是否编译（同时避免让他们访问工具本身，显然）。 虽然这可以奏效，但要注意为开发人员/测试人员提供过多的输出，因为这可能会泄露机密信息。 通常，“构建成功”或“构建失败”消息就足够了。
避免图表
尽管有些人认为，图表是危险的。 它们可能会泄露太多关于你对项目的基本假设（以及因此，你正在销售的基于它的产品）的信息，而且认真的开发人员应该能够从你已放入存储库的 1,500 个源文件中推断出他们需要的所有信息。
来自项目早期迭代的一些“市场营销”图表可能是可以接受的，但前提是它们有些过时，并且没有提供对代码现有结构的任何真正洞察力。
保持沉默
有时，贡献者——或者那些希望成为贡献者的人，如果你对他们的请求微笑以待——会提出问题。 在过去，这些问题往往被发送到电子邮件列表6 ，在那里它们可以被安全地忽略（除非它们来自重要的客户）。 最近，开发人员期望使用其他渠道来联系项目团队成员，例如问题或聊天。
重要的是你要记住，你对这些外部贡献者没有任何责任或义务：他们应该是在帮助你。 更重要的是，你的内部开发人员会太忙于编写代码，而无法回答可能提出的各种不明智的查询（至于所谓的“漏洞披露”，你可以只在你内部版本的产品中修复这些漏洞，或者至少向你的客户保证你已经修复了）。 鉴于大多数开源项目都会附带问题数据库，甚至可能附带聊天频道，你应该怎么做？
答案很简单：退回到电子邮件。 坚持认为保证受到关注7 的唯一渠道是电子邮件。 不要犯未能创建电子邮件地址的错误，人们可以将查询发送到该地址；如果贡献者收到通用的自动回复（“感谢您的电子邮件；团队成员应尽快回复您”），他们比收到退回消息更容易忘记他们期望收到电子邮件的回复。 哦，关闭任何未经你许可创建问题的人的问题，理由是“未能遵循项目流程”。8
发布巨大的提交
没有人9 希望不得不跟踪代码（或更糟糕的是，文档——见上文）的许多微小更改，或者让贡献者挑剔它。 然而，有一种有用的方法可以避免这种情况，那就是训练你的开发人员只向开源项目发布大型提交。 你需要确保你的内部开发人员理解，只有当项目团队（或更具体地说，产品团队）认为代码准备就绪时，才应将其发布到外部存储库。 不要试图将开源存储库用作你的版本控制系统：你应该在内部拥有非常好的流程，并且通过一些自动化，你可以设置它们以定期将成批更新复制到外部存储库。10
- 嗯，很多人都读过它，所以我假设你喜欢它。
- 可能有其他公共存储库可用，但你不会听说过它们，所以你为什么要关心？
- 这类人的规范术语是“抱怨者”：他们总是“专家”。 根据他们的说法（以及他们 20 年的安全经验等等）。
- 或者ad mulierem——请不要在你的攻击中带有性别歧视。
- 或许可证，取决于你的拼写选择。
- 如果它们存在——一个明智的组织可以小心地避免创建它们。
- “关注”可以包括“全部删除”过滤器。
- 显然，你实际上不需要在任何地方定义流程是什么。
- 至少在你的产品组织中是这样。
- 请注意，“定期”并不等同于“频繁”。 目标是每隔一两个月一次。
本文最初发表在 Alice, Eve, and Bob 上，并经作者许可转载。
4 条评论