可持续的开源项目是那些能够自给自足的项目。简而言之，它们能够满足其持续的成本。
然而，从选择和采购的角度来看，可持续性也意味着项目能够及时交付改进和修复其产品的问题，并且项目本身有合理的前景持续到未来。
在我们网站的其他地方，您可以找到文章，描述一些评估开源软件的正式方法，作为软件可持续性成熟度模型的一部分。
然而，也存在一些非正式的方法来评估开源项目的可持续性，这些方法在对正式方法论的投资不合理的情况下可能很有用，例如，如果您的组织进行的软件评估数量相当少且不频繁。
在本文档中，我们将看看您可以使用基本的网络研究技术和公开可访问的信息来评估的一些关键可持续性指标
请注意，这些绝不是评估软件时需要考虑的唯一因素；另请参阅 OSS Watch 的选择开源软件的技巧和开源软件采购的决策因素。
代码活动：贡献和贡献者
为了使项目具有可持续性，它必须有贡献者，并且其代码库需要不断发展。您可以通过查看项目的版本控制系统并查看贡献模式来跟踪这一点。Black Duck Software 的 Ohloh 网站是一个方便的工具。
以下是 CKAN 的贡献历史示例
软件项目往往会经历不同的活动周期；在一个项目开始时，当框架和主要功能就位时，通常会有一阵开发热潮，然后随着项目成熟，并且工作重心转移到修复错误和提高性能上，步伐往往会放缓。稍后，当有重大功能添加或转移到新框架时，可能会出现另一次活动热潮。
因此，看到一个项目的代码库的贡献数量出现波动是很正常的，对于某些项目来说，如果贡献数量下降实际上是一个好兆头，因为它表明了稳定性和成熟度。
再次，看看 CKAN，我们可以将上面的图表与项目贡献者数量的衡量标准进行比较
因此，这里的情况是，为该项目做出贡献的开发人员总数正在稳步增加，但开发速度在达到顶峰后正在放缓。这是一个好兆头，因为它表明即使项目进入更稳定的阶段，它也在吸引开发人员。
然而，这是另一个例子，HtmlCleaner。
这是一个在不活跃了一年左右后“重启”的项目。项目本身已经相当成熟。然而，任何在 2012 年评估该项目的人都会正确地担心其可持续性。
最后，这是一个很好的例子，说明了这种方法的局限性
从这里看起来，该项目似乎在 2008 年底几乎死掉了，此后就没有活动了。然而，该项目（在本例中为 OpenSAML）实际上并没有死！该项目只是更改了其源代码存储库的位置，但这尚未反映在其在 Ohloh 网站上的配置文件中。
如果您看一下项目自己的网站，您可以关注其存储库的链接，并查看此日期之后很久的代码贡献。因此，重要的是不要仅仅从表面上看待这些类型的图表，而是要检查它是否反映了版本控制系统本身中正在发生的事情。
发布历史
项目采用非常不同的方法进行发布，因此很难在项目之间进行概括。有些项目可能会承诺定期发布，如果存在可持续性问题，这将会在周期中断中显而易见。然而，许多项目会在他们觉得准备就绪时进行发布，因此发布不会遵循任何特定的模式。
因此，与查看创建发布的开发者社区相比，发布历史可以讲述一个不太有用的故事。
一个例外是，如果在开发者活动良好水平的情况下，已经有一段时间没有发布；这可能表明项目内部存在治理问题，阻止其发布；唯一的找出方法是进入项目沟通渠道，看看是否存在问题。
以下是 HtmlCleaner 从 2006 年到 2013 年的发布历史。这在很大程度上反映了项目中的活动模式，但也表明在过去一年中，发布更加有规律。
以下是 CKAN 2011-2013 年的发布历史，显示该项目在过去 9 个季度中的 8 个季度创建了一个新版本
同样，SQLite 项目从 2006-2013 年也频繁发布
请注意，与活动数据不同，发布历史通常无法以易于分析的方式获得。您可能需要从网页输入列表，或获取源代码在源代码控制系统中被“标记”为特定版本时的日期。
用户社区
没有用户，软件就无法持续。用户驱动功能，识别错误，并塑造项目方向以满足他们的需求。通常不清楚如何确定用户社区在一个软件项目中的规模和投入，因为参与度往往因项目类型而异。
一个好的起点是使用搜索引擎来了解谁在谈论该项目。一个有用的工具是 Google 趋势，它可以让您看到有多少人在搜索关于某个主题的信息。例如，我们可以比较 “CloudStack” 与 “OpenStack” 的搜索量
您还可以使用搜索引擎来发现讨论该项目的博客文章和文章。同样，您可以在 Twitter 上关注该项目的主题标签，或在 LinkedIn、Facebook 和 Google+ 上关注相关活动。项目是否有大量的“粉丝”？或者它是否从用户那里产生大量的推文？
请注意，即使社交媒体上有很多用户的抱怨，这也不一定是负面信号——它至少表明有足够多的人足够关心该产品，即使他们有问题也愿意使用它！
另一个要使用的工具是项目的问题跟踪器。一个健康的项目应该有相当数量的问题——尽管这听起来可能有点违反直觉。基本上，所有软件都有错误和需要改进的地方。一个健康的用户社区将不断发现这些错误，并确定软件可以改进的领域。当然，有些项目非常成熟，在错误跟踪器上的活动可能相对较少。
然而，对于较新的项目，如果跟踪器中没有错误报告，这可能表明要么是一个反应非常迅速的开发人员社区，他们在问题出现后立即关闭问题，但更有可能表明一个项目没有足够的用户来发现任何问题。
再次，注意误报：可能没有可见的错误，因为项目在某个时候已从使用一个系统转移到另一个系统。例如，ePrints 在 Trac 中有其遗留问题，但新问题在 Github 上报告。
您还可以查看项目提供的用户社区工具，以了解可持续性，例如用户论坛和邮件列表。其中许多工具提供内置分析，或者您可以使用 Markmail 等第三方网站。
例如，如果我们查看 Markmail 上 Hadoop 邮件列表中的消息，您可以看到该项目的邮件列表活动随时间的增长
再次注意，社区可以很容易地从一个工具转移到另一个工具——例如，可能有一个项目开始时使用的旧邮件列表，在某个日期之后就没有帖子了，但新用户实际上可能通过其 Facebook 或 Google+ 页面与项目进行交互。
总而言之，这应该让您对用户社区的健康状况有一个合理的了解。您可以采用正式的方法，实际从这些各种工具中导出数字，但考虑到来源的多样性，定性方法似乎更现实。
寿命
项目有时会遵循自然的周期，即被创建，经历一段高活动的热潮，然后进入稳定的生产阶段，最终随着同一领域的新项目以更强大的技术基础取代它而消亡。
然而，一些开源项目也非常长寿，例如 Apache Web 服务器。
当这种情况发生时，其影响往往具有一定的自我维持性，因为更保守的组织会采用该软件，并长期保留使用它，从而导致对其可持续性的长期投资。
如果一个项目已经存活足够长的时间来应对几个技术替代周期，这是一个很好的迹象，表明它将在未来几年内继续存在。警告信号是，当项目社区似乎正在稳定地迁移到另一个项目时；如果发生这种情况，即使是一个大型成熟的项目最终也会开始遭受损失。
对于较新的项目，则更难判断；如果它们处于项目开始时的快速开发阶段，通常没有真正的迹象表明该项目会逐渐消失并被下一个热门事物取代，还是会进入长期而富有成效的生命周期。
例如，当 Node.js 首次出现时，曾有人争论围绕该项目的最初“热潮”是否会是短暂的。然而，该项目现在已经三年了，并且显示出进入更稳定阶段的迹象。
对于较新的项目，最佳的行动方案可能是减轻风险而不是避免风险；例如，制定良好的退出策略，投资于项目支持的互操作性和开放标准，并定期审查项目与其竞争对手相比的演变情况。
生态系统
除了关注项目周围的开发者和用户之外，考虑与项目互动的公司也很重要。这包括托管和支持提供商、咨询和定制服务，以及将软件与其他产品捆绑作为解决方案一部分的公司。
项目周围的生态系统是一个重要的指标，因为很明显，这些公司对软件本身的可持续性有浓厚的兴趣。
有时使用的比喻是“珊瑚礁”——一个可持续的项目会积累越来越多的专业化合作伙伴和提供商。同样，如果出现服务公司正在远离支持该项目的迹象，这可能表明存在潜在问题。
并非所有软件项目本质上都适合这种生态系统，但在有公司提供服务的情况下，查看它们的多样性很有用。例如，它们是否仅在一个或两个国家/地区运营？它们是小型公司和大型公司的混合体吗？它们是否都针对单一行业领域？
总结
这些绝不是考虑软件可持续性时的唯一因素，如果您正在进行大量的评估，那么采用正式的方法和工具集可能是一项值得的投资。然而，对于临时评估，这份简报应该提供一个良好的起点。
最初发布在 OSS Watch 网站上。根据知识共享许可协议重新发布。 作者：Scott Wilson。
2 条评论