整体创新

在波士顿红帽峰会的主题演讲中，红帽 CEO Jim Whitehurst 提出，2009 年全球企业 IT 支出 1.3 万亿美元中，有 5000 亿美元基本上被浪费了（由于新项目夭折和 2.0 版本综合症）。此外，由于 IT 支出的目的是创造价值（通常每 1 美元 IT 支出产生 6-8 美元的价值），企业 IT 支出中 5000 亿美元的浪费转化为 3.5 万亿美元的经济价值损失。他接着解释说，通过正确的创新——在软件商业模式、软件架构、软件技术和应用方面——我们可以从今天浪费的资金中获得全部价值，从而加强了创新胜过成本节约的论点。

但随后埃森哲的首席技术架构师 Paul Daugherty 出现了，在他的主题演讲中，他列出了客户选择开源软件的五个主要原因（现在在他们的客户中高达 78%）

第一 (76%)：质量比专有软件更好。

第五 (54%)：总拥有成本更低。

那么到底是哪个？创新胜过成本节约？还是质量胜过成本节约？

根据 David Upton 博士的研究，如果您实践基于路径的创新（也称为持续创新或 Kaizen），那么质量和创新是一回事。或者，从数学上讲，创新是质量改进随时间的积分。不幸的是，Upton 博士的研究还表明，大多数高管薪酬结构并不奖励有纪律的持续改进，而是奖励通常是“大赢/大输”的努力。而且，反常的是，他们倾向于预先奖励那些下注的人，而不是那些在赌注真正可以被评判时在场的人。这鼓励高管们将创新变成一项高风险业务，而创新本可以成为可持续价值创造的可靠引擎。这使得一线员工害怕和厌恶“下一个大事件”，尤其是当它有高管赞助时。反过来，这导致了 IT 部门最糟糕的情况，即保守地保护那些从一开始就不合适的系统。但还有更好的方法。

在他的主题演讲中，Jim 正确地指出，模块化、分层架构更容易进行增量改进。不仅人多出 bug 少，而且人多力量大。高度模块化的系统鼓励大规模参与，许多微小改进的总和可以被视为一个巨大的改进。本周在波士顿，红帽解释了其 Cloud Foundations 平台——一个由数千个较小更改支持的单一大型更改，而这些较小更改又是由成千上万个更小的更改支持的，这绝对清楚地说明了这一点。红帽的工程模型拥抱增量创新，所有贡献社区的积分简直令人叹为观止。

但是，当我们把这些创新分解成它们的组成要素时，我们经常发现，在最精细的细节层面上，从创新中衍生出来的原子性变更与对系统质量的非常具体、非常实在的改进之间没有区别。事实上，将质量视为修复损坏的东西（好像它永远不需要再次被触及）是不如将其视为使适应成为改进的。当然，为了构建高质量的产品，消除缺陷很重要，但消除那些会降低未来环境中适用性的不灵活或错误的假设也同样重要。当每个人都能够进行这样的适应时，结果简直就是转型。

我在自由/开源软件社区中花费了大量时间：作为 GNU C 和 C++ 编译器以及 GNU 调试器的主要开发人员近 10 年，以及自那时以来 10 多年向他人传授我的经验。我获得的关于开源软件开发和软件质量之间关系的最深刻的见解之一来自对 开源软件开发的两个案例研究：Apache 和 Mozilla 论文中发表的分析的吸收，该论文发表在 TOSEM，2002 年 7 月。有关完整解释，请参阅我在 2009 年发表的主题演讲的这份文字记录。对于本文的目的，我想重点关注该论文统计了 388 位不同的 Apache 贡献者，其中 1 号开发人员完成了所有工作的 20%，而 388 号开发人员所做的更改微不足道，以至于在图表中几乎看不到。该论文解释说，论文中研究的开源代码比也研究过的同类专有软件更快地交付成果，bug 更少，而且 bug 本身也修复得更快。该论文观察到，由于像 Apache 这样的开源软件不限制参与，那些可能没有进入 MUSTFIX 列表的 bug（在开发人员资源稀缺的情况下肯定会如此，因为每个开发人员都必须从利润中获得报酬）仍然可以被世界上某个关心特定问题的开发人员修复。因此，我以为我接受了论文解释的内容，以及我从自己的经验中了解到的，开源是迄今为止清理复杂软件项目中不可避免出现的所有极端情况的最佳方法。为持续改进欢呼！但这只是故事的一半。

在红帽公司的新员工培训中，我多次教授这篇论文的内容之后，我产生了一个新的见解，这是故事的另一面。想象一下，你拥有你维护的一小块代码世界，有一天你发现有些东西出错了。你搜索又搜索，然后你得出结论，问题不在于你编写的代码，而在于更远的地方，在你没有编写的某些库或应用程序中。你可能会发现问题出在 Apache 上，通过做出这个判断，你可以通过查看代码、观察行为来验证你的假设，如果你是对的，你可以通过修复该缺陷成为第 389 号开发人员，就像之前的许多人一样。但是，假设你发现问题出在某些专有软件中。这就是你改进系统的能力结束的地方。此外，你仍然有问题。WTF？！（What's The Fix?! - 怎么修复？！）

你可以记录问题，让客户怀疑你自己的软件，或者你可以在你自己的代码中放置一个变通方案。变通方案不是“正确”的修复，但它可能会给你你需要的行为，现在你不是修复问题，而是实际上创建了第二个问题，暂时抵消了第一个问题，也许。你无法确定，因为你无法看到原始问题，只能看到它投下的阴影。现在想象一下，有数百个模块，有数百个修复机会，但实际上却产生了变通方案。很容易看出，当源代码可用时，系统中可能潜伏着数百倍的缺陷或潜在缺陷，而根本不需要有任何缺陷！

因此，开源不仅允许开发人员修复 bug 所在的位置，而且还强烈鼓励（和文化）不要仅仅因为 bug 出现在另一个模块中而污染自己的工作。与专有软件相比，累积结果已被测量出 100 倍或更多的质量差异，正如 Coverity 所测量的那样。如此大的质量差异是显而易见的。并且具有赋能性。并且鼓励不仅要修复错误，还要改进可以做得更好的地方。所有这一切都起到鼓励提高质量和创新的作用，直到 IT 实现其真正的承诺：创造价值。