开源项目管理可能存在风险

了解开源代码如何在降低风险中发挥巨大作用。

图片来源：

Opensource.com

我们的数字生活由编程哲学家们驱动，他们选择公开开发代码。

所有程序都始于指令行。当准备执行时，这些指令行会被转换为计算机可以执行的二进制格式。开源程序是指人类可读代码对任何人开放访问的程序。这种开放和自由的理念使得这些项目能够影响每个人的生活。

Linux 内核是所有 Android 设备的核心，并且几乎三分之一的互联网流量都依赖于一个公开开发的项目，Netflix。（请阅读《时代》杂志上关于此事的精彩文章。）在项目计划中使用开源软件的选择，如何影响组织内项目的风险数量和类型？

风险既是一种感知，也是一种现实。工具帮助我们从感知走向现实，就像好的温度计帮助我们将“热”和“冷”的笼统概念转变为更具体的、可量化的温度（在 Google 上查看示例）。随着时间的推移，我们采用了不同的标准和技术来讨论具体的温度，这些标准和技术取决于受众和标准的局限性。开尔文、摄氏度、华氏度，甚至 RealFeel 现在都是衡量温度的既定标准。

Weather graph

^{图示 1：量化温度}

每个项目都有风险，每个 PM（项目经理）对风险的感知和表达都不同，准确程度也各不相同。对风险的理解可能很简单，就像“好”或“坏”的描述，类似于“热”和“冷”这些词。PMBOK（项目管理知识体系）指出，讨论风险管理的过程应从定性评估转向定量评估（正如项目管理协会的出版物《项目管理知识体系指南/PMBOK 指南》（第五版）中所述）。与温度类似，项目管理学科也有不同的可量化标准来衡量项目风险。至少其中一项风险评估标准说明了为什么在项目规划过程中，开源软件经常被拒绝作为项目的可能考虑因素。

Tom Kendrick 的著作《识别和管理项目风险》（Kendrick，2015）中讨论的风险复杂性指数是我们的基础。复杂性指数在项目风险管理中并不少见。David Bearden 使用复杂性指数来展示 NASA 采用其 FBC（更快、更好、更便宜）理念如何影响项目风险。虽然他的指数基于近期数据点，但 Kendrick 书中的风险复杂性指数试图更具预测性。Kendrick 将该指数的公式表述为

指数 = (技术 + 架构 + 系统) X 规模

“技术”、“架构”和“系统”的评分范围为 0 到 5，基于 PM 的经验和能力。“架构指的是高层功能组件和任何外部接口，而系统是产品中将要使用的内部软件和硬件。技术维度被定义为项目中使用的开发基础，”Kendrick 在他的书中说道。他解释说，该指数可以使用以下关键指标进行评分

0. 仅需现有技术
1. 在少数领域需要对现有技术进行少量扩展
2. 在少数领域需要对现有技术进行重大扩展
3. 几乎可以肯定可能实现，但在某些领域需要创新
4. 可能可行，但在许多领域需要创新
5. 全新的，技术可行性存疑

“规模”根据项目预期人数分配数值

0.8 最多 12 人
2.4 最多 40 人
4.3 最多 100 人
6.6 超过 100 人

在这个指数中，0 到 20 的结果被认为是低风险，20 到 40 是中等风险，而 40 到 100 的范围是高风险。正如价格标签是对杂货店货架上给定商品生产要素成本的总结一样，该指数是对导致项目风险的项目的总结。在风险管理的这个阶段，风险已被识别和量化。最初，整个风险指数指的是组织内部进行的项目风险。在制定缓解措施后，可以使用矩阵重新评估项目的风险。

Project management risk evaluation

^风险评分

在 Adrienne Watt 著作《风险管理》中关于风险管理规划的章节中，她讨论了四种降低风险的策略。它们是风险规避、风险分担、风险降低和风险转移。在应用这些策略的某种组合后，PM 团队可以重新计算风险复杂性指数，以确定他们是否已将项目的总体风险降低到可接受的水平。

开源的关键问题在于，当使用开源时，风险由组织承担。诸如 BSD 非常简短的许可证之类的开源代码许可证包含明确将责任从代码的创建者转移到代码用户的语言。它通过声明“本软件按‘原样’提供，不提供任何明示或暗示的保证”来实现这一点。对于 Linux，GPL 3.0 前言指出，“为了开发者和作者的保护，GPL 明确声明此自由软件不提供任何保证”（自由软件基金会，2007 年）。

这削弱了先前列出的缓解措施的几个关键方面。如果组织承担代码的技术责任，他们避免、分担、降低或转移风险的能力就会降低。开源代码仍然可以是风险管理策略解决方案的一部分，在某些情况下，开源代码是降低风险的巨大因素。

来自主要供应商的软件包含该供应商策略税的额外风险。与 Microsoft Windows 相关的策略税在 Valve（流行的游戏发行平台 Steam 的创建者）那里达到了临界点。Valve 选择降低增加的风险，并开发了 SteamOS，将其发行软件移植到开源代码上运行（Dingman，2013）。他们为其基础选择的代码策略税要低得多，从而显着降低了他们的风险。

虽然 Valve 的程序员人才库意味着他们拥有审核和理解相关源代码的技术知识，但并非所有企业都资源充足。拥有大量程序员的企业倾向于将开源应用程序纳入其项目规划中。2010 年，Google 将其大量机器从 Windows 切换到 Linux。Netflix 运行 FreeBSD 以利用 ZFS 中内置的技术。

品牌价值在企业资产组合中起着重要作用，可能损害品牌形象的项目可被视为将公司置于更高的风险之中。更敏感的品牌领域之一是 IT 安全公司，他们为每个客户开展项目。通过与该行业员工的私下交谈，我了解到他们转移风险的一种方式是通过公司沟通渠道的政策。他们没有任何内部沟通渠道。相反，每位员工都必须使用多种外部通信技术。组织的现实情况是，如果他们的品牌成为成功攻击的受害者，并且任何新闻周期都包含该组织的名称，这将对品牌造成严重损害，因此对于电子邮件，他们使用 Gmail，对于聊天，他们使用 Slack（渗透测试，2016 年）。他们依赖无数其他应用程序和服务来减少攻击面并将风险转移给尽可能多的组织。

项目风险的真正成本并非在项目完成时结束，而是在整个产品生命周期内与客户满意度息息相关。为了准确说明开源项目带来的品牌风险，最近发生了一个令人痛心的例子。当趋势科技 (Trend Micro) 团队开展一个项目来构建其组织网站时，他们选择了流行的开源 WordPress 套件。最近，WordPress 出现了一个漏洞，该漏洞被黑客利用，并因其针对修复此漏洞的衡量响应而受到大多积极关注。相比之下，趋势科技的网站因早期项目经理的决策而受到了类似的负面新闻报道（McCaskill，2017 年和 JupiterBroadcasting，2017 年）。

鉴于围绕开源的这种负面新闻，难怪许多 PM 忽视了开源在实际降低项目复杂性指数方面可能具有的优势。KDE 网站最近发布了对 Thomas Weissel 的采访，Thomas Weissel 是一位为奥地利学校系统工作的开发人员，他完成了一个将 KDE 纳入他工作的奥地利学校的项目。在采访中，他描述了开源的一个关键优势，即团队解决问题的可访问性。用他的话说

“这是我选择 Plasmashell：KIOSK 系统的另一个原因。我报告了很多关于 KIOSK 系统的问题，Plasma 开发人员在查找和修复我为 5.8 发现的所有错误方面做得非常出色。我们现在拥有一个完全锁定的桌面，以确保没有人意外删除或重新配置用户界面的重要部分，”Weissel 说（Riddell，2017 年）。

长期开源评论员 Chris Fisher 反问 PM，他们认为闭源供应商需要多长时间才能在项目执行期间响应已识别的错误。这是架构成本从组织转移到开发人员的一个极好例子。对于企业级项目，大型闭源供应商可能愿意与其客户合作。对于较小规模的项目，项目团队的响应能力可能是他们根据特定需求调整软件的唯一途径。

开源解决方案已被市场各个领域采用，以适应我们技术基础设施中的关键角色。Tom Kendrick 开发的风险复杂性指数有助于我们理解在市场各个维度上采用开源解决方案的困难。

总的来说，开源解决方案将风险从软件供应商转移到组织。在当今品牌建设既昂贵又至关重要的环境中，开源解决方案对使用它们的品牌构成直接风险。尽管存在这种风险，但许多大型和小型项目仍然为那些通过实施可以降低复杂性指数的项目选择开源解决方案。KDE 开发团队与奥地利的一位小型项目经理合作开发尽可能最好的代码的例子，清楚地表明了开源领域的一个显着优势。虽然代码作者可能不承担法律责任，但他们对产品的自豪感通常是他们交付最佳产品的强大动力。