对于任何一家企业中的开源部门来说，相当常见的一项任务就是对内部软件进行评估以考量其是否适合以开源形式回馈社会。而在PayPal公司执行这项任务时，我们发现有必要利用Danese Cooper建立的一套审查流程对潜在开源项目加以审视，从而为以下四个问题找到答案：
1.与谁相关?
2.我们是否仍在使用?
3.我们是否做出承诺?
4.其在公共树结构下是否能够顺利进行开发?
今天的文章将着眼于这四个问题，并探讨它们为何如此重要。
1.与谁相关?
立足于企业之外，还有谁会对这款软件感兴趣?如果没有活跃社区的积极参与，任何开源项目都不可能取得成功。如果吸引不到外界的兴趣，那么以现有成果为基础建立活跃社区的希望也会变得非常渺茫。一旦依靠劳资关系维系的项目开发者们逐步离去，必须要有其他人接手其开发及维护，否则我们只是给历史的垃圾堆增添了一件废品。
获得外部反馈意见的方式可谓多种多样。与来自其它企业的同行们交流、撰写博客、在会议活动中进行沟通或者发表演讲都是不错的实现方式。有些人天生具备这种能力，有些人则需要一定程度的引导才能确切表达自己的意见，也有不少人不太擅长谈论与自己工作相关的话题。但在大多数情况下，员工需要得到企业的明确授权，告诉他们能够在外界发表怎样的言论。我们发现对有此意向的员工进行表达培训能够很好地解决上述问题，当然也可以帮助开发人员充实其博客中的相关内容。
2.我们是否仍在使用?
如果我们已经不再使用这款软件，那么在进行开源之前总是需要进行大量审查。如果我们不再积极开发这款软件，那么我们几乎不可能以该项目为核心执行进一步推动或者为其建立社区。软件中的某个独立组件中可能存在安全漏洞(或者存在于软件本身中)，这意味着必须有人全程追踪并加以解决。更不用提其它一些常见任务的处理工作，具体包括归类错误请求、指导新晋贡献者以及根据用户实际需要调整任务处理方式等等。这些工作都需要投入时间，而作为企业我们不太可能花费大量时间维护一款已经不再使用的软件。
不过***的问题在于，对失败产品进行开源会给企业声誉带来影响。如果我们由于一套解决方案无法解决实际问题而转向其他软件成果，那么真的很难指望这东西能够切实帮助其他人搞定运营任务。开源社区不是求助站或者垃圾桶，我们不可能随便把自己不想要的东西往这里一丢了事。如果企业回馈给社会的都是其不想要的软件，那还不如干脆别打开源的主意。
3.我们是否做出承诺?
正如之前所提到，维护开源项目需要投入大量时间，而具体时间周期则取决于项目的整体规模。一般来讲，开源项目的维护时间一般要低于核心应用框架，但其时间投入仍然相当可观。毫无疑问，开发人员及其管理者都会把时间视为一种极其宝贵的资源。如果管理者不愿意让开发人员把时间耗费在项目维护工作身上，那么项目本身很可能陷入慢性死亡状态。
而在敏捷背景之下，大家则可以采取多种不同处理方式。如果我们的流程依赖于功能组件与短期冲刺，那么我们可以通过一项组件配合一轮冲刺的方式实现项目维护。而如果大家选择基于任务的开发人员精力调派方式，则应当适当减少开发人员投入到项目维护方面的产能消耗。如果大家打算把工作均摊给多位成员，自然会希望确保了解每个人具体负责流程中的哪些部分——否则任务将很可能陷入僵局。一部分项目还需要全职社区技术人员予以配合。如果这一切在管理者眼中是不合理或者不可行的，那么该项目需要迎接进一步审查以考量其是否适合走向开源。
4.其在公共树结构下是否能够顺利进行开发?
是否还有其它与代码相关的阻力限制着我们在公众视野当中进行项目代码编写工作?如果这些代码由于同内部系统的关联性而无法进行公共开发，那么，我们必须对这种关联性加以隔离、剥离或者模块化处理。而且，如果相关流程并不影响该软件对外界参与者及使用者的吸引力，那么，大家应当考虑解耦这种内部关联关系，从而帮助项目本身实现实用性。另外，如果没有更多项目内容需要发布，那么相关代码编写也基本可以叫停。
更重要的是，大家绝不能继续以内部形式开发软件——通过许可将各重要发行版本发布在GitHub之上，同时合理启用良好的开源资源。外部与内部开发人员必须能够参与其中，并围绕设计与开发议案进行讨论，否则整个社区将被彻底架空。这意味着我们需要为社区提供可供讨论的素材，并把技术决议交给公众评判——而不能继续依靠企业内部的决策倾向。如果项目团队不想做这些工作，我们可能需要为其行为提供一些重要指导，从而帮助其走上开源正轨。
总结
这四个问题当然还不足以涵盖开源过程中可能出现的全部障碍。任何一家企业都需要对项目当中可能涉及的各类知识产权问题做出评估。另外，我们也必须对其它类似开源项目进行研究，确保自己的努力成果不会与既有方案相重复。与此同时，项目本身还必须对企业自身以及整个开源社区具备实际价值。但总体来讲，这四个问题可以算是一个良好的对话起点，大家可以利用它们帮助自己过滤掉那些不适合作为首发开源对象的软件方案。
原文标题：4 questions to ask before open sourcing a project，作者：Duane O'Brien
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
