不久前，我发表了广受欢迎的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 条评论