在任何一家公司的开源部门中，最常见的任务之一是评估内部软件，确定它是否可以作为回馈社区的开源项目。我们在 PayPal 进行相关评估时发现回答下面四个问题对我们的审查潜在的开源软件的过程非常有用：

• 谁关心这个项目？

• 我们还在使用这个项目吗？

• 我们还在维护这个项目吗？

• 这个项目能够在一颗公共代码树上开发吗？

谁关心这个项目？

在公司之外，谁会对这个软件感兴趣？开源软件失去社区的支持将一事无成。如果外面没有人对这个项目感兴趣，围绕你的成果构成一个有意义的社区的几率就会变得渺茫。一旦维护这个项目的员工都离开了，就一定要有人接管这个项目，否则这个项目最终会被抛弃。

有很多可以获得外部反馈的方法。和其他公司的同事说、写博客、参加社交聚会和发表会议演讲都是不错的方法。有些员工可能已经做好了这件事，有些需要 告诉他们可以说些什么，并且要怎样做，而有些则不希望谈论他们的工作。其实很多人只需要有人告诉说他们是允许与外面的的人谈论他们的工作的。同时我们还发 现给需要的人提供演讲培训以及帮助开发者管理博客内容是非常有效的。

我们还在使用这个项目吗？

如果我们不再使用该项目，那么它总是能够通过开源的审查。如果我们不再继续开发这个软件，我们不太可能完成维护项目的任务或者围绕其建立一个社区。 而如果一个它依赖的组件(或者软件本身)发现了一个漏洞，那么一定会有一个人要花费时间处理这个问题。除此之外，将 bug 分类、指导新的贡献者、合并代码这些都需要时间，而一个公司是不太可能投入大量的时间维护一个它不再使用的软件的。

然而，更大的问题在于，将失败的项目开源是很差的企业行为。如果我们因为不符合我们的需求而抛弃一个项目，那么其他人也不可能发现它是真正有用的项 目，开源并不是我们抛弃无用软件的垃圾桶。如果一家公司只是开源了一些它不再需要的一些软件，那么还不如它根本没有开源过软件。

我们还在维护这个项目吗？

正如上面提到的，维护一个开源项目需要时间。而其消耗的时间取决于项目的规模。一个编码风格检查程序耗费的时间不可能和一个强大的应用程序框架相 比，但是他们都需要一定的时间。另一点不能忽视的是，开发人员和他们的管理者要有一定程度的共识。如果管理者不愿意开发者在维护项目上花费时间的话，我们 将会再次走将软件抛弃的路。

当你在一个比较灵活的环境中工作时，你能用很多种方法处理这些问题。如果你选择的工作是基于开发者能力的，那么你应该适当的减少参与开发工作的每个 开发者的能力。如果你选择的工作是将任务分发给多个人做的，那么你需要明确每个人要处理哪个部分。否则这些项目很容易夭折。如果这一切对于管理者而言是不 合理或者不可行的，那么这些项目需要额外的审查

这个项目能够在一颗公共代码树上开发吗？

代码中存不存在不能让我们将整个代码树公开的部分？如果这些代码由于依赖内部系统而不能完全公开，那么这些依赖关系将需要被分离、抽象或模块化。如 果这样做了之后软件对外界的价值不大，那么你需要考虑是否添加部分内部依赖来让整个项目变得更加有价值。如果不能添加内部依赖的话，那就没有理由再继续下 去了。

更深入的讲，你不能在内部开发你的软件，将你项目的里程碑版本配合合适的开源许可证发布到 GitHub 中，从而合理的参与到开源中。外部的开发人员必须能够平等地参与到设计与开发相关的讨论中，这样才不至于让你的社区走向没落。从另外一个角度来看，这也意味着你需要开放一些内部的资料给社区，并允许他们在公开的讨论相关的技术，而不是一味地由内部贡献这些资料。

结语

这四个问题并不能代表所有情况，一家公司必须从项目开源后对公司和开源社区的意义等方面考虑，而这四个问题可以作为讨论的起点，相信明确了这几个问题后，你会很快得到你的结论的。

原文链接 : https://opensource.com/business/16/1/4-questions-ask-open-sourcing-project

本文转载自： http://www.linuxstory.org/4-questions-before-open-source/