想知道如何为你的开源软件项目收集使用指标？考虑一下使用这些替代方案的利弊。

我们这些支持开源项目社区的人经常被问到很多有关使用指标的问题。这些指标通常是为了通过用户量和知名度来衡量软件的重要性。我们一般都想知道有多少人使用该软件，有多少次安装，以及有多少人生活接触过它。

但简而言之，我们尚无法直接回答上述问题。

如果你想要寻找一个明确的解决方案，那很抱歉要让你失望了。有关使用指标的问题，没有人有完美的答案，至少没有准确的答案。

好消息是，有一些近似的和替代指标至少能够部分地满足你对软件使用情况了解的渴求。本文探讨了这些替代方案以及它们的优点和缺点。

下载量

当你浏览提供软件的网站时，你通常可以看到软件的下载次数。映入我脑海的一个例子是 Firefox ，它曾经有一个下载计数器。Firefox 的下载量是一个印象深刻的数字，给人的印象是 Firefox 是一个流行的浏览器，在一段时间内确实如此。

然而，个人行为会直接影响这一数字的准确性。举例而言，当一个人定期重置他们的设备时，每一次重建都会引发一次独立的下载。考虑到这一现实，需要设计一种方法从下载量中去除几十次（或许是几百次）的下载次数，因为那是一个人。

下载量不仅会高估使用量，还会低估使用量。例如，一个系统管理员可能会下载一个新版本的 Firefox 一次并将其拷贝到 U 盘上，然后安装到数百台设备上。

下载量指标是易于收集的，你可以在服务器上记录每一个下载请求。问题在于你不知道在这些软件下载以后会发生什么。下载它的人是否如预期的那样使用软件，还是遇到了问题而放弃了它。

对于开源项目而言，你可以考虑各种下载量指标，比如来自以下途径的下载指标：

• 项目官网
• 包管理器，比如 npm、PyPi 和 Maven
• 代码仓库，如 GitHub、GitLab、Gitee 等

你可能还对源代码的下载量感兴趣，因为下游项目更可能使用源代码形式（参见 《如何衡量你的开源项目的影响》一文）。相应的下载指标包括：

• 从代码仓库克隆的数量，比如 GitHub、GitLab 和 Gitee
• 从官网下载的归档文件（tar、zip）的数量
• 通过像 npm、PyPi 和 Maven 这样的包管理器下载的源代码数量

源代码的下载指标比二进制代码的下载指标更不可靠（虽然尚无相关研究表明如此）。试想一下，一名开发人员想要你的最新版本的源代码，并将他们的构建管道配置为每次构建都克隆你的仓库。再想象一下，一个自动构建过程失败了，它试图重新构建而不断地克隆你的版本库。你还可以考虑这样一个下载量低于预期的场景——源代码仓库在某些地方缓存了，下载来源是由这些缓存所提供的。

相关阅读：跟踪你的开源社区的 5 个指标

总而言之，下载量指标是用于提供当前使用情况和探测趋势的很好的指征。我们无法明确地定义一次下载是如何转化为使用的。不过我们可以认为增加的下载量是更多潜在用户的标志。举例而言，如果你为你的软件做了广告并在活动期间得到了更高的下载量，可以合理地假定广告推动了更多人下载该软件。下载行为的来源与元数据还可以提供额外的与使用行为相关的内容。你的软件的哪些版本仍在使用中？什么操作系统或者特定语言的版本更加流行？这有助于社区决定将哪个平台的软件作为支持与测试的优先选项。

议题

作为一个开源项目，你可能有一个议题追踪器。当某个人提出一个议题时一般有两个目标，报告一个漏洞或者请求增加一项功能。提议者很可能已经使用过你的软件了。作为一名用户，他可能发现了一个漏洞或者发现了对一个新功能的需求。

很明显，大多数用户不会执行额外的步骤来提交议题。提议者是我们的忠实用户，我们对他们表示感谢。此外，通过提出议题，他们已经成为了非代码贡献者，他们也有希望成为代码贡献者。经验法则是大约每 10000 名用户中，可能有 100 名提议者，以及 1 名代码贡献者。当然取决于用户类型，上述比例可能有出入。

回到指标问题，你可以将提议者数量作为评估使用量的下界。相关的指标包括：

• 提议者数量
• 活跃提议者的数量（在过去 6 个月内提出议题的提议者）
• 同时有代码贡献的提议者的数量
• 尚未解决的议题的数量
• 对议题发布的评论数量

邮件列表、论坛和问答网站

很多开源项目都拥有用户邮件列表、论坛，并且出现在类似 Stack Overflow 的问答网站上。与提问者一样，在这些地方发帖的人可被视作用户的冰山一角。与邮件列表、论坛和问答网站上的社区活跃程度相关的指标也可用于反映用户数量的上升或下降。相关指标可以集中于以下地方的活动，包括：

• 用户邮件列表的订阅量
• 论坛用户的数量
• 问题的数量
• 答案的数量
• 发布信息的数量

上报功能

为了获得精确的用户数量，一个方案是让软件在使用时上报信息。

这是令人毛骨悚然的。想象一下，系统管理员的防火墙报告了一个非预期的到你的服务器的网络连接，你不仅无法再收到软件报告（被防火墙拦截了），恐怕连你的软件也可能在未来被禁止使用。

负责任的设置上报功能的方式为设置一项可选服务来检查更新并让用户知道使用最新版本。另一项可选功能可以集中在使用遥测上，你可以通过该功能询问用户是否允许匿名上报软件使用情况。如果经过深思熟虑的实施，这种方式可以允许用户通过他们使用软件的方式帮助优化软件。用户可以持有这样的意见：我一般不允许这种使用信息的分享；但对于一些软件，因为希望开发人员在长期内将软件优化得更好，我愿意这样做。

星标与复刻

星标与复刻是如 GitHub、GitLab、Gitee 等社交化编程平台的功能。这些平台上的用户可以给一个项目加星标。为什么他们要给项目加星标呢？GitHub 的文档作出了解释：你可以给一个仓库和主题加星标，以跟踪感兴趣的项目，和在你的新闻订阅中发现相关的内容。给一个项目加星标与将其加入书签的效果一样，并且还提供了一种向项目仓库的维护者展示赞赏的方式。星标的数量已经成为了项目流行程度的标志。当一个项目发布重大公告并获得相当的关注时，项目的星标数量会呈上升趋势。星标的数量指标并不反映软件的使用量。

在社交化编程平台上的 复刻 Fork 是将项目仓库复制一份在自己名下。仓库的非维护者可以在他们自己的克隆仓库中做修改，并将修改通过 拉取请求 pull request （PR）的方式提交审核。复刻比星标更能反映软件社区的规模。开发者也可能为了保存一份代码副本而克隆一个项目，以便在原始仓库消失后他们仍能访问代码。因为复刻功能在代码贡献工作流中的应用，复刻量是衡量开发社区的良好指标。复刻量通常也不反映非开发人员的使用，因为非开发人员一般不创建复刻。

社交媒体

包括 Facebook、Instagram、LinkIn、Reddit、Twtter 等社交媒体平台提供了相同兴趣的人们聚集的平台。采用社交媒体策略，开源项目可以通过在平台上设置相应的聚集空间来吸引对项目感兴趣的人们。通过这些社交媒体途径，开源项目可以分享项目新闻、更新，指出贡献者和用户。这些社交媒体途径还可以用于认识那些本不会通过其他途径与项目互动的人。

我在犹豫是否建议关注以下指标，因为它与软件的真实使用量没有清晰的联系，并通常需要分析其中的积极、消极和中性的情绪。人们可能因为很多不同的原因对你的项目感到激动而关注它，但并不实际使用它。然而与之前已经讨论过的指标一样，能够在社交媒体上吸收人群本就是项目受关注的整体指标。不同社交媒体平台的指标包括：

• 关注者与订阅者的数量
• 消息的数量
• 活跃的消息作者的数量
• 喜欢、分享、回复以及其他交互的数量

网站分析与文档

网站流量也是一个有用的指标。这一指标主要受到你的服务范围以及市场营销活动影响，而不是用户量。然而，我们还有一张王牌：我们的用户文档、教程、手册以及 API 文档。我们可以发现我们的网站以及文档中的什么主题更引人注意。文档的访问者数量应当大致随着软件的使用者数量增长而增长。因此我们可以通过网站的访问量探知对项目的普遍兴趣，并进一步通过观察文档的访问者来观察用户风向。这些指标包括：

• 网站访问者数量
• 文档访问者的数量
• 访问者在你的网站与文档上所花的时间

活动

活动的指标可以在你主持与项目相关的活动时使用。这是建立社区的很好的方式。有多少人提交摘要想要在你的活动中发言？有多少人出席你的活动？不论是在线下活动还是线上活动这可能都很有趣。当然，你如何推广你的活动在很大程度上决定有多少人到场。同时你可以将自己的活动与人们出行的大型活动放在一起以方便人们参加你的活动。只要你使用一贯的活动策略，你可以通过演讲者提交的材料与参会者注册的增加来表征软件受欢迎程度与用户群的增加。

你并不需要举办你自己的活动来收集有用的指标。如果你在开源活动中主持有关你项目的讨论，你可以衡量有多少人出席主要关注你的项目的会议。像 FOSDEM 这样的活动，一些讨论特别聚焦于开源项目的更新与发布，会议室中都挤满了人（像 FOSDEM 的所有会议一样）。

你可以考虑如下指标:

• 以你的项目为中心的活动的出席人数
• 提交到以你的项目为中心的活动的演讲数量
• 以你的项目为中心的演讲的出席人数

关于估算开源软件使用的结论

正如我们已经如上展现的，有很多指标可以反映软件使用的趋势，没有一个指标是完美的。在大多数情况下，这些指标可能被个人行为、系统设计和噪音所严重影响。因此，考虑到每一个指标的相对不确定性，我们建议你不要孤立地使用任何一个指标。但是如果你从不同的来源收集了一系列的指标，你应当能够探测到用户行为与软件使用的趋势。如果你有办法在多个具有共性的开源项目中比较同一组指标，例如类似的功能、强大的相互依赖性、在同一基础设施上托管，以及其他特征，你就可以提升你对用户行为基线的感知。

需要注意的是，在这篇概述中，我们选择突出能够评估直接使用情况的指标。而大多数软件都依赖于其他各种软件包，如果我们不提及作为软件依赖链的一部分而被间接使用的严重影响，这就是我们的疏忽。因此，我们建议将上下游依赖的合计数量作为你的分析中的另一层内容。

最后，作为数据与指标的使用者，我们鼓励你认识到你的利益相关方的权利与责任。你发布的任何指标都有可能影响用户行为。最好的做法是经常一同分享你的背景信息——基础、来源、估算方法和其他关键上下文信息，这有助于其他人解释你的结果。

感谢 CHAOSS 社区在爱尔兰都柏林举行的 CHAOSScon EU 2022 上的富有洞察力的对话，上述对话激发这篇博文的想法。我们还要感谢 CHAOSS 社区的成员审阅并帮助优化本文。

via: https://opensource.com/article/22/12/open-source-usage-metrics

作者：Georg Link 选题：lkxed 译者：CanYellow 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

如果你认为开源软件是共享软件、免费软件和公有领域软件的代名词，那么你并不是唯一有这种看法的人。

当你听到“ 开源软件 （ open source ） ”一词时，你是否认为它与诸如 共享软件 （ shareware ） 、 免费软件 （ freeware ） 或 公有领域软件 （ public domain ） 之类的术语同义？ 如果是这样的话，你并不是唯一有这种看法的人。在软件行业内外的许多人都认为这些术语是一样的。本文说明了这些术语的不同之处，认为开源是一种变革性的许可和开发模式。分享我与以上几种软件打交道的经验，可能是探究差异的最佳方法。

共享软件和免费软件

早在 1982 年，当我在 Apple II Plus 上用 BASIC 编写代码时，我就开始从事计算机程序员的工作。我回想起去家乡当地的计算机商店，并在塑料袋中找到看起来价格高昂的装有游戏和实用程序软件的软盘。请记住，这是从一个中学生的角度来看的。

但是，有一些软件可以免费或以最低价格获得。依据具体许可模式，它被称为共享软件或免费软件。在共享软件模式下，你只能在一定时间内使用该软件，如果你发现它有用，则要求你将支票寄给该软件的作者。

但是，某些共享软件实际上也鼓励你复制并提供给你的朋友。这种模式通常称为免费软件。也就是说，共享软件和免费软件确切定义之间的差异十分微小，因此很容易将两者简单地统称为“共享软件”。我虽不能肯定，但是我不记得我是否向任何软件作者提供过使用共享软件的费用，主要是因为我在十几岁的时候就没有钱，但是我肯定喜欢使用这些软件程序，并且从中学到了很多有关计算机的知识。

回顾过去，我现在意识到，如果该软件是根据开源许可条款而非共享软件条款提供的，那么作为一名新兴的程序员，我本可以在成长中学到很多东西，并且可以取得更多成就。这是因为几乎没有共享软件会提供源代码（即，人类可读的软件形式）。共享软件还包含许可限制，禁止接收者试图泄露其源代码。如果无法访问源代码，则很难了解该软件的实际工作方式，从而很难扩展或更改其功能。这使得最终用户完全依赖共享软件原始作者进行任何更改或改进。

使用共享软件模式，任何开发人员社区几乎都不可能对代码施加影响，并进一步围绕代码进行创新。再分发和商业使用也可能受到进一步的限制。尽管共享软件可能在价格方面是免费的（至少在最初是免费的），但它在自由权利方面并不是免费的，并且不允许你通过探索代码的内部原理来学习和创新。

这就引出了一个大问题：它与开源软件有何不同？

开源许可的基础

首先，我们需要了解“开源”是指许可模式和软件开发模式，两者与共享软件都有很大不同。在一种称为非 “左版” （ copyleft ） 开源许可的开源形式下，向用户提供了关键的自由权利，例如对访问源代码没有限制；可以出于任何目的出售、使用或赠送该软件；可以修改软件。

这种形式的许可也不需要支付任何使用费或许可费。因为许可是高度宽松的，不需要谈判就可以使用，这种许可模式的一个惊人结果是它具有独特的能力，可以使无数软件开发人员协作起来对代码进行新的、有用的更改和创新。尽管从技术上讲，在这种许可模式下不需要提供源代码，但是几乎所有人都可以使用它来查看、学习、修改和分发给他人。

非“左版”开源许可的另一个方面是，此类软件的任何接收者都可以添加其他许可限制。这意味着以这种许可形式对代码进行许可的初始作者，无法阻止接收者可能依据限制性更强的条款不再进一步许可给其他人。例如：

假设作者 Noah 编写了一些软件，并根据非“左版”开源许可将其分发给了接收者 Aviva。然后，Aviva 修改并改进了 Noah 的软件，她有权根据非“左版”开源许可条款使用该软件。然后，Aviva 可以决定对可能限制该软件使用的任何接收者施加进一步的限制，例如在何处或如何使用它（例如，Aviva 可以增加一项限制，规定该软件只能在以下地区使用：加利福尼亚，并且不允许在任何核电厂中使用）。 即使 Aviva 可以访问源代码，也可以选择永远不将修改后的源代码发布给他人。

不幸的是，有无数的专有软件公司以上述方式使用非“左版”开源许可软件。实际上，共享软件程序可以通过添加共享软件类型限制（例如，无法访问源代码或排除商业用途）来使用非“左版”开源许可软件，从而将非“左版”开源许可代码转换为共享软件许可模式。

幸运的是，许多使用非“左版”开源许可软件的专有软件公司都看到了发布源代码的好处。这些组织一般通过诸如 GitHub 之类的软件存储平台向其接收者或更广泛的开源社区提供修改后的源代码，从而继续保持开源模式的持久性，实现创新的良性循环。这并不是完全出于慈善目的（或者至少通常不是这样）：这些公司希望鼓励社区创新和进一步改进，从而使他们也一并受益。

同时，许多专有软件公司不选择这样做，这也完全符合非“左版”开源许可证条款的规定。

“左版”许可的开源软件

1989 年，一种新的被称为 GNU 通用公共许可证（也称为 GPL 许可证）的开源许可证被开发出来，其目的是确保软件“生来自由”（如同言论自由），并且能始终保持这种自由，这与非“左版”开源许可软件有时会发生的情况不同。作为版权法的独特适用，只要遵守这些规则（稍后会再介绍），GPL 许可证能够确保持续的软件自由。版权的这种独特适用称为 “左版” （ copyleft ） 。

与非“左版”开源软件一样，“左版”许可证允许接收者不受限制地使用该软件、检查源代码、修改软件，以及将原始或经修改的软件进一步分发给其他接收者。与非“左版”开源许可证不同，“左版”开源许可证要求所有接收者必须也具有这些相同的自由权利。除非不遵守规则，否则这些自由权利决不能被收回。

使“左版”开源许可证能够强制执行，并促使人们遵守法规的原因是版权法的适用。如果“左版”代码的接收者不遵守许可条款（例如，对软件使用添加任何其他限制或不提供源代码），则其许可将被终止，并且由于他不再享有使用该软件的法律许可，他将成为版权侵犯者。因此，该“左版”许可软件任何下游接收者的自由权利得以保障。

超越基础：其他软件许可模式

我在前面提到了公有领域软件，尽管它通常与开源软件混为一谈，但是这种模式有所不同。公有领域软件是指已采取步骤查看后获知没有与该软件相对应的版权存在，最常见的情况是软件版权到期或被作者放弃。（在许多国家/地区，版权保护机制尚不明确，这就是为什么某些公有领域软件可能选择开源许可模式作为备选方案的原因。）使用公有领域软件无需许可证。尽管如果源代码可获取的话，许多人会认为公有领域软件是开源软件的一种形式，但无需许可证是否让公有领域软件成为“开源软件”，是存在很多争论的主题。

有趣的是，有许多开源项目利用公有领域软件的小模块来实现某些功能。甚至还有声称整个程序属于公有领域的软件，例如实现了 SQL 数据库引擎并在许多应用程序和设备中使用的 SQLite。没有许可条款的软件也是很常见的。

许多人错误地认为这种未经许可的软件是开源软件，属于公有领域，或者不受限制地免费使用。在大多数国家（包括美国），软件的版权在其创建时就已存在。这意味着不以许可证的形式许可就不能使用它，除非它以某种方式放弃版权，并将其放置在公有领域。此通用规则存在一些例外情况，例如法律层面的默示许可或合理使用。但是在如何将它们应用于特定状况方面，情况非常复杂。在意图让其遵守开源许可条款的情况下，我不建议提供没有许可条款的软件，因为这会导致混乱和潜在的滥用。

开源软件的好处

就像我之前说的那样，开源是高效的软件开发模式，并具有推动创新的巨大能力。但这到底意味着什么？

开源许可模式的好处之一是大大减少了创新方面的摩擦，尤其是原始作者以外的其他用户所进行的创新。这种摩擦是有限的，因为使用开源软件通常不需要协商许可条款，从而大大简化并降低了使用成本。反过来，这创建了一种开源生态系统，它鼓励快速修改和组合现有技术以形成新的事物。这些修改通常能回馈到开源生态系统中，从而构造了一个创新循环。

驱动大量事物（从你的烤面包机到火星飞行器）运转的无数种软件，正是这种轻松地将各种程序组合在一起的能力的直接结果——开源开发模式让所有这些软件得以成为现实。

作者简介：Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 红帽公司 （ Red Hat ） 开源法务团队的资深商务法律顾问，还担任 北卡罗来纳大学 （ University of North Carolina ） 的兼职法律教授。在任职红帽公司之前，Jeffrey曾担任 高通公司 （ Qualcomm ） 的专利和开源法律顾问。

译者简介：薛亮，集慧智佳知识产权咨询公司互联网事业部总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

近日， 黑鸭软件 （ Black Duck Software ） 发布了开源安全与风险分析（OSSRA）年度报告，报告对 2018 年以来 1200 多个商业代码库的匿名数据进行了分析和研究。对当今的企业来说，开源软件、库和组件往往起着重要的作用。开源代码采用率高有许多原因，其中包括开源社区的许多程序员愿意为项目贡献时间、项目代码的透明性、以及比开发内部系统更少的实现时间等。

在黑鸭审查的所有代码库中，有 96% 包含了开源组件，而大多数没有开源代码的代码库其实包含不到 1000 个文件。在超过 1000 个文件的代码库中，开源代码的采用率高达 99%。

开源代码有着它的安全优势，但也存在着安全漏洞未修补的隐患，开发人员可能没意识到项目正在被安全漏洞影响。在报告审查的代码库中，至少包含一个漏洞的代码库占 60% ，这个数字比 2017 年统计的结果 78% 有所下降。

黑鸭认为，发现的漏洞有 40% 都是关键级的。“事实上，开源并不总是更安全。”报告指出，无论项目源码是专有的还是开源的，都可能因为漏洞的存在，安全性变得薄弱。项目人员应该及时加以识别和修补这些漏洞。

报告中发现漏洞的平均“年龄”为 6.6 岁。其中，最老的 CVE-2000-0388 是 FreeBSD libmytinfo 库中的缓冲区溢出漏洞，在 28 年前被披露。报告结果显示，有 43% 的代码库包含一个超过 10 年的 bug。这表明不少企业可能没意识到开源的用处，也没有对组件目录进行系统管理，这些软件没有打新的补丁，更容易被攻击。

“一般只有少数开源漏洞，比如那些影响 ApacheStruts 或 OpenSSL 的漏洞，有可能被广泛利用。”研究人员表示，项目组织应该把他们的开源漏洞管理和缓解工作的重点放在 cvss 评分和漏洞的可用性上，在关注 “0day” 的同时，也应该关注开源组件的生命周期。

来源：开源中国

更多资讯

黑客届“奥斯卡”来了！国际安全技术大牛 5 月底齐聚北京

随着网络安全问题越来越引发全球关注，对黑客、安全漏洞等话题感兴趣的极客和技术爱好者们将在北京迎来盛会。有黑客界“奥斯卡”之称的 DEF CON 近日宣布，即将举办 DEF CON CHINA Baidu 安全行业国际峰会，5月31日至6月2日，数千名全球安全技术大牛将齐聚北京 751D·PARK，同台切磋技艺。

来源： 北京日报客户端
详情： http://t.cn/ESl6YeJ

还在随便下载软件？CNCERT 公布 116 个高危恶意程序

2019 年 2 月期间，国家互联网应急中心（简称“CNCERT”）在全国范围内继续开展计算机恶意程序传播渠道安全监测工作，对已备案的计算机软件下载站进行安全监测，判定计算机恶意程序 216 个，其中高危恶意程序 116 个，涉及 8 个省份的 11 家软件下载站及应用商店。2019 年 4 月下旬，CNCERT 将本次监测结果形成报告对外发布。

来源： FreeBuf.COM

详情： http://t.cn/ESl6mGB

阿桑奇在英被判 50 周监禁处罚

据英国“天空新闻”刚刚消息，维基解密创始人阿桑奇在英被判50个星期监禁。“你曾有一个选择，你选择的行动就是犯罪，”该法院法官德博拉·泰勒在法庭上说，“你没有心甘情愿地投向......你不会自愿到法院来。”随后，泰勒宣布阿桑奇被判“50 周监禁”。

来源： 环球科技

详情： http://t.cn/ESlXhc5

Windows 10 的安全功能使得基于 Chromium 的浏览器运行慢了三倍多

正如 Vivaldi 开发人员所揭示的那样，Windows 10 中内置的安全功能使基于 Chromium 的浏览器在测试环境中的速度降低了三倍多。Yngve Pettersen 在博客文章中解释说，开发人员在将 Windows 10 测试人员添加到 Windows 单元测试集群时发现了这个性能问题。

来源： cnBeta.COM

详情： http://t.cn/ESlXLjD

（信息来源于网络，安华金和搜集整理）

CIP 的目标是创建一个基本的系统，使用开源软件来为我们现代社会的基础设施提供动力。

现如今，现代民用基础设施遍及各处 —— 发电厂、雷达系统、交通信号灯、水坝和天气系统等。这些基础设施项目已然存在数十年，这些设施还将继续提供更长时间的服务，所以安全性和使用寿命是至关重要的。

并且，其中许多系统都是由 Linux 提供支持，它为技术提供商提供了对这些问题的更多控制。然而，如果每个提供商都在构建自己的解决方案，这可能会导致分散和重复工作。因此， 民用基础设施平台 Civil Infrastructure Platform （CIP）最首要的目标是创造一个开源基础层，提供给工业设施，例如嵌入式控制器或是网关设备。

担任 CIP 的技术指导委员会主席的 Yoshitake Kobayashi 说过，“我们在这个领域有一种非常保守的文化，因为一旦我们建立了一个系统，它必须得到长达十多年的支持，在某些情况下超过 60 年。这就是为什么这个项目被创建的原因，因为这个行业的每个使用者都面临同样的问题，即能够长时间地使用 Linux。”

CIP 的架构是创建一个非常基础的系统，以在控制器上使用开源软件。其中，该基础层包括 Linux 内核和一系列常见的开源软件如 libc、busybox 等。由于软件的使用寿命是一个最主要的问题，CIP 选择使用 Linux 4.4 版本的内核，这是一个由 Greg Kroah-Hartman 维护的长期支持版本。

合作

由于 CIP 有上游优先政策，因此他们在项目中需要的代码必须位于上游内核中。为了与内核社区建立积极的反馈循环，CIP 聘请 Ben Hutchings 作为 CIP 的官方维护者。Hutchings 以他在 Debian LTS 版本上所做的工作而闻名，这也促成了 CIP 与 Debian 项目之间的官方合作。

在新的合作下，CIP 将使用 Debian LTS 版本作为构建平台。 CIP 还将支持 Debian 长期支持版本（LTS），延长所有 Debian 稳定版的生命周期。CIP 还将与 Freexian 进行密切合作，后者是一家围绕 Debian LTS 版本提供商业服务的公司。这两个组织将专注于嵌入式系统的开源软件的互操作性、安全性和维护。CIP 还会为一些 Debian LTS 版本提供资金支持。

Debian 项目负责人 Chris Lamb 表示，“我们对此次合作以及 CIP 对 Debian LTS 项目的支持感到非常兴奋，这样将使支持周期延长至五年以上。我们将一起致力于为用户提供长期支持，并为未来的城市奠定基础。”

安全性

Kobayashi 说过，其中最需要担心的是安全性。虽然出于明显的安全原因，大部分民用基础设施没有接入互联网（你肯定不想让一座核电站连接到互联网），但也存在其他风险。

仅仅是系统本身没有连接到互联网，这并不意味着能避开所有危险。其他系统，比如个人移动电脑也能够通过接入互联网而间接入侵到本地系统中。如若有人收到一封带有恶意文件作为电子邮件的附件，这将会“污染”系统内部的基础设备。

因此，至关重要的是保持运行在这些控制器上的所有软件是最新的并且完全修补的。为了确保安全性，CIP 还向后移植了 内核自我保护 Kernel Self Protection （KSP）项目的许多组件。CIP 还遵循最严格的网络安全标准之一 —— IEC 62443，该标准定义了软件的流程和相应的测试，以确保系统更安全。

展望未来

随着 CIP 日趋成熟，官方正在加大与各个 Linux 提供商的合作力度。除了与 Debian 和 freexian 的合作外，CIP 最近还邀请了企业 Linux 操作系统供应商 Cybertrust Japan Co., Ltd. 作为新的银牌成员。

Cybertrust 与其他行业领军者合作，如西门子、东芝、Codethink、日立、Moxa、Plat'Home 和瑞萨，致力于为未来数十年打造一个可靠、安全的基于 Linux 的嵌入式软件平台。

这些公司在 CIP 的保护下所进行的工作，将确保管理我们现代社会中的民用基础设施的完整性。

想要了解更多信息，请访问 民用基础设施官网。

via: https://www.linux.com/blog/2018/6/cip-keeping-lights-linux

作者：Swapnil Bhartiya 选题：lujun9972 译者：wyxplus 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这个共同福利并不适用于专有软件：保持隐藏的东西是不能照亮或丰富这个世界的。

“开源软件肯定不太安全，因为每个人都能看到它的源代码，而且他们能重新编译它，用他们自己写的不好的东西进行替换。”举手示意：谁之前听说过这个说法？ ^注1

当我和客户讨论的时候（是的，他们有时候会让我和客户交谈），对于这个领域 ^注2 的人来说种问题是很常见的。在前一篇文章中，“[许多只眼睛的审查并不一定能防止错误代码]”，我谈论的是开源软件（尤其是安全软件）并不能神奇地比专有软件更安全，但是和专有软件比起来，我每次还是比较青睐开源软件。但我听到“关于开源软件不是很安全”这种问题表明了有时候只是说“开源需要参与”是不够的，我们也需要积极的参与辩护 ^注3 。

我并不期望能够达到牛顿或者维特根斯坦的逻辑水平，但是我会尽我所能，而且我会在结尾做个总结，如果你感兴趣的话可以去快速的浏览一下。

关键因素

首先，我们必须明白没有任何软件是完美的 ^注6 。无论是专有软件还是开源软件。第二，我们应该承认确实还是存在一些很不错的专有软件的，以及第三，也存在一些糟糕的开源软件。第四，有很多非常聪明的，很有天赋的，专业的架构师、设计师和软件工程师设计开发了专有软件。

但也有些问题：第五，从事专有软件的人员是有限的，而且你不可能总是能够雇佣到最好的员工。即使在政府部门或者公共组织 —— 他们拥有丰富的人才资源池，但在安全应用这块，他们的人才也是有限的。第六，可以查看、测试、改进、拆解、再次改进和发布开源软件的人总是无限的，而且还包含最好的人才。第七（也是我最喜欢的一条），这群人也包含很多编写专有软件的人才。第八，许多政府或者公共组织开发的软件也都逐渐开源了。

第九，如果你在担心你在运行的软件的不被支持或者来源不明，好消息是：有一批组织 ^注7 会来检查软件代码的来源，提供支持、维护和补丁更新。他们会按照专利软件模式那样去运行开源软件，你也可以确保你从他们那里得到的软件是正确的软件：他们的技术标准就是对软件包进行签名，以便你可以验证你正在运行的开源软件不是来源不明或者是恶意的软件。

第十（也是这篇文章的重点），当你运行开源软件，测试它，对问题进行反馈，发现问题并且报告的时候，你就是在为 共同福利 commonwealth 贡献知识、专业技能以及经验，这就是开源，其因为你的所做的这些而变得更好。如果你是通过个人或者提供支持开源软件的商业组织之一 ^注8 参与的，你已经成为了这个共同福利的一部分了。开源让软件变得越来越好，你可以看到它们的变化。没有什么是隐藏封闭的，它是完全开放的。事情会变坏吗？是的，但是我们能够及时发现问题并且修复。

这个共同福利并不适用于专有软件：保持隐藏的东西是不能照亮或丰富这个世界的。

我知道作为一个英国人在使用 共同福利 commonwealth 这个词的时候要小心谨慎的；它和帝国连接着的，但我所表达的不是这个意思。它不是克伦威尔 ^注9 在对这个词所表述的意思，无论如何，他是一个有争议的历史人物。我所表达的意思是这个词有“共同”和“福利”连接，福利不是指钱而是全人类都能拥有的福利。

我真的很相信这点的。如果i想从这篇文章中得到一些虔诚信息的话，那应该是第十条 ^注10 ：共同福利是我们的遗产，我们的经验，我们的知识，我们的责任。共同福利是全人类都能拥有的。我们共同拥有它而且它是一笔无法估量的财富。

便利贴

1. （几乎）没有一款软件是完美无缺的。
2. 有很好的专有软件。
3. 有不好的专有软件。
4. 有聪明，有才能，专注的人开发专有软件。
5. 从事开发完善专有软件的人是有限的，即使在政府或者公共组织也是如此。
6. 相对来说从事开源软件的人是无限的。
7. …而且包括很多从事专有软件的人才。
8. 政府和公共组织的人经常开源它们的软件。
9. 有商业组织会为你的开源软件提供支持。
10. 贡献--即使是使用--为开源软件贡献。

脚注

• 注1： 好的--你现在可以放下手了
• 注2：这应该大写吗？有特定的领域吗？或者它是如何工作的？我不确定。
• 注3：我有一个英国文学和神学的学位--这可能不会惊讶到我的文章的普通读者 ^注4 。
• 注4： 我希望不是，因为我说的太多神学了 ^注5 。但是它经常充满了冗余的，无关紧要的人文科学引用。
• 注5： Emacs，每一次。
• 注6： 甚至是 Emacs。而且我知道有技术能够去证明一些软件的正确性。（我怀疑 Emacs 不能全部通过它们...）
• 注7： 注意这里：我被他们其中之一 Red Hat 所雇佣，去查看一下--它是一个有趣的工作地方，而且我们经常在招聘。
• 注8： 假设他们完全遵守他们正在使用的开源软件许可证。
• 注9： 昔日的“英格兰、苏格兰、爱尔兰的上帝守护者”--比克伦威尔。
• 注10： 很明显，我选择 Emacs 而不是 Vi 变体。

这篇文章原载于 [Alice, Eve, and Bob - a security blog] 而且已经被授权重新发布。

via: https://opensource.com/article/17/11/commonwealth-open-source

作者：Mike Bursell 译者：FelixYFZ 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

“实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ 不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员单方面的乐观主义。”

— 出自 Owen Astrachan 教授于 2004 年 2 月 23 日在 CPS 108 上的讲座

指责开源软件总是离奇难用已经不是一个新论点了；这样的论点之前就被很多比我更为雄辩的人提及过，甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？

在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为 编写代码实现和一个跟 StackOverflow 一样的系统可以简单到爆，并自信的 声称他们可以在 7 月 4 号的周末就写出一版和 StackOverflow 原版一模一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品 就已经是一个很好的例证了。

秉承着自由讨论的精神，我们来假设一个场景。你在思考了一阵之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以像我一样打字飞快，一分钟能敲 100 个词 (也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计 2.3MB 的源码来估计（包括 .CS、 .SQL、 .CSS、 .JS 和 .aspx 文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。

或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭 StackOverflow 源代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄 StackOverflow 源代码用时的十倍时间来让我自己写 StackOverflow，我可是打死也做不到。

好的，我知道你在听到这些假设的时候已经开始觉得泄气了。你在想，如果不是全部实现，而只是实现 StackOverflow 大部分 的功能呢？这总归会容易很多了吧。

好的，问题是什么是 “大部分” 功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题及其答案的投票系统，来显示大家对某个答案是赞同还是反对。因为只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且与 Markdown 结合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的 那个超棒的编辑器 ）。你还需要为所有控件购买或者设计一些小图标、小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。

但是如果你实现了以上所有功能，可以说你就已经把要做的都做完了。

除非……除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现对问题答案的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登录事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和 徽章 Badge 。你需要去显示用户的 Karma 历史，以及他们的历史点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 Slashdot、Reddit 或是 StackOverflow 这些动作影响到。

在这之后！你会以为你基本已经大功告成了！

……为了产品的完整性，在上面所述的工作都完成之后，你又奋不顾身的去实现了升级功能，界面语言的国际化，Karma 值上限，以及让网站更专业的 CSS 设计、AJAX，还有那些看起来理所当然做起来却让人吐血的功能和特性。如果你不是真的动手来尝试做一个和 StackOverflow 一模一样的系统，你肯定不会意识到在整个程序设计实施的过程中，你会踩到无数的鬼才会知道的大坑。

那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？

正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也同样是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码:

create table QUESTION (ID identity primary key,
                                             TITLE varchar(255), --- 为什么我知道你认为是 255
                                             BODY text,
                                             UPVOTES integer not null default 0,
                                             DOWNVOTES integer not null default 0,
                                             USER integer references USER(ID));
create table RESPONSE (ID identity primary key,
                                             BODY text,
                                             UPVOTES integer not null default 0,
                                             DOWNVOTES integer not null default 0,
                                             QUESTION integer references QUESTION(ID))

如果你让这些开发者去实现 StackOverflow，进入他脑海中的就是上面的两个 SQL 表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登录和注销功能、评论功能、投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登录和评论的功能。

但这种简单的实现却远远不能体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它的数据库的 Schema 没有多大关系 —— 实际上在有幸研读过 StackOverflow 的源码之后，我得以印证了自己的想法，StackOverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后大量的精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的很少会去考虑到产品背后的打磨和雕琢工作，因为他们认为这些打磨和雕琢都是偶然的，甚至是无足轻重的。

这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 StackOverflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遭遇种种关键和核心的问题，让他们阴沟翻船，半途而废。拿徽章功能来说，如果你要针对普通终端用户来设计徽章， 则要么需要实现一个用户可用来个性化设置徽章的 GUI，要么则取巧的设计出一个比较通用的徽章，供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给徽章这种东西设计一个功能全面的 GUI 是根本不可能的。而且他们会固执地把任何标准徽章的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 程序都在使用的流程和方案：即实现一个通用的机制，提供以 Python 或 PHP 为基础的一些系统 API， 以便那些可以自如使用 Python 或 PHP 的人可以轻松的通过这些编程接口来定制化他们自己的徽章。而且老实说，PHP 和 Python 可是比任何可能的 GUI 接口都要好用和强大得多，为什么还要考虑 GUI 的方案呢？（出自开源开发者的想法）

同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何 mod 的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计（即要求用户必须拥有一个 OpenID 并知道如何使用它）在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的却是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。

开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低售后维护支持的成本一样，懂行的消费者也会在他们购买这些产品之前就确保产品好用，以防在使用的时候不知所措，然后无奈的打电话给售后来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。

这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache、Django、PostgreSQL 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而即使是最新版本的 Ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。

相比之下，MS SQL (微软的 SQL 数据库) 则不需要你手工配置以上的任何一样东西。至于 Apache …… 我的天，Apache 简直复杂到让我根本来不及去尝试给一个新用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机、MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也 只是 一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项就 恰恰在 这种基础构架的开发和创新上，这也正是驱使开发者为开源做贡献的最本真的动力。

所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的在一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。

via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/

作者：Benjamin Pollack 译者：hopefully2333，yunfengHe 校对：yunfengHe，wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出