任何企业开源部门的一个相当普遍的任务是评估内部软件是否适合以开源形式回馈社区。在PayPal期间，我们发现有必要使用DaneseCooper建立的审查流程来审查潜在的开源项目，以回答以下四个问题： 1。与谁有关？ 2.我们还在用吗？ 3。我们做出承诺了吗？ 4。公有树结构下能顺利开发吗？ 今天的文章将围绕这四个问题展开，并讨论它们为何如此重要。 1。与谁有关？ 在企业之外，还有谁会对这个软件感兴趣？没有活跃社区的积极参与，任何开源项目都不可能成功。如果没有外界的兴趣，就很难在现有成就的基础上建立一个活跃的社区。一旦依赖劳资关系维系的项目开发者逐渐离开，就必须由其他人接手其开发维护工作，否则我们只是在历史的垃圾堆中添加一个废品。 有很多方法可以获得外部反馈。与其他企业的同行建立联系、撰写博客、在会议活动中交流或发表演讲都是实现这一目标的好方法。有些人天生就有这种能力，有些人需要一定的指导才能准确地表达自己，还有很多人不太擅长谈论与工作相关的话题。但在大多数情况下，员工需要得到公司的明确授权，才能告诉他们在外界可以说些什么。我们发现，对感兴趣的员工进行表达性培训是解决上述问题的好方法，当然也可以帮助开发人员充实其博客中的相关内容。 2.还在用吗？ 如果我们不再使用该软件，在开源之前总会有很多审查。如果我们不再积极开发软件，我们几乎不可能进一步推进该项目或围绕它建立社区。软件的单个组件（或软件本身）可能存在安全漏洞，这意味着必须有人追踪并修复它。更不用说处理其他一些常见的任务，包括对错误请求进行分类、指导新的贡献者、根据用户的实际需求调整任务处理等。这些任务需要时间的投入，而且作为一个业务我们不太可能花费大量时间维护一个不再使用的软件。 但最大的问题是开源失败的产品会影响企业声誉。如果我们因为一套解决方案不能解决真正的问题而转向其他软件工作，那么真的很难指望这个东西能真正帮助其他人完成他们的操作任务。开源社区不是帮助站或垃圾桶。我们不能把我们不想要的东西扔在这里。如果一家公司回馈社会的都是它不需要的软件，那么它还不如根本不开源这个想法。 3。我们做出承诺吗？ 如前所述，维护一个开源项目需要花费大量时间，具体时间段取决于项目的整体规模。一般来说，开源项目的维护时间普遍低于核心应用框架，但时间投入还是相当可观的。毫无疑问，开发人员及其经理将时间视为极其宝贵的资源。如果管理者不愿意让开发人员把时间花在项目维护上，那么项目本身很可能会陷入一种缓慢死亡的状态。 在敏捷环境中，您可以通过许多不同的方式来做到这一点。如果我们的过程依赖于功能组件和短期冲刺，那么我们可以通过一个组件和一个冲刺来实现项目维护。而如果选择基于任务的开发者能量分配方式，则应适当降低开发者投入项目维护的产能消耗。如果您要将工作分摊给多人，您自然会希望确保您确切知道每个人负责流程的哪些部分——否则任务可能会停滞不前。有些项目还需要全职社区技术人员的配合。如果这一切在管理者眼中都是不合理或不可行的，那么该项目就需要面临进一步的审查，以确定其是否适合开源。 4。公有树结构下能顺利开发吗？ 是否还有其他与代码相关的障碍限制我们在公众眼中编写项目代码？因此，我们必须将这种关系隔离、剥离或模块化。而且，如果相关流程不影响软件对外部参与者和用户的吸引力，那么大家应该考虑将这种内部关系解耦，从而帮助项目本身实现实用性。另外，如果没有更多的项目内容发布，那么相关的代码编写基本就可以停止了。 更重要的是，你不能继续在内部开发软件——在GitHub上发布带有许可证的主要版本，并合理使用好的开源资源。外部和内部开发人员必须能够参与并围绕设计和开发提案进行讨论，否则整个社区将被消灭。这意味着我们需要为社区提供一些可以讨论的东西，并将技术决策留给公众进行判断——而不是继续依赖企业的意愿来做决定。如果项目团队不想做这项工作，我们可能需要为他们的行为提供一些重要的指导，帮助他们走上开源之路。 总结 这四个问题当然不足以涵盖开源过程中可能出现的所有障碍。任何企业都需要评估项目中可能涉及的各种知识产权问题。此外，我们还必须对其他类似的开源项目进行研究，以确保我们的努力不会重复现有的解决方案。同时，项目本身必须对业务本身和整个开源社区具有真正的价值。但总的来说，这四个问题可以算是一个很好的对话切入点，你可以用它们来帮助你筛选出那些不适合作为第一个开源对象的软件解决方案。 原标题：开源项目前要问的4个问题，作者：DuaneO'Brien
