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