万圣节一:微软开源软件内部备忘录

1998年，开源软件开始获得巨大的吸引力，微软很害怕。1998年8月，微软向关键人员发送了一份内部备忘录，教育他们了解开源软件以及对其商业模式的潜在威胁。

这份备忘录最终泄露并公之于众。微软证实了这份备忘录的真实性。

这份备忘录(被称为“万圣节文件”)引人入胜地回顾了微软对开源软件的早期想法，以及该公司如何决定定义他们的战略和重点。

我们在下面重新发布了万圣节文档。

享受。

Vinod Valloppillil (VinodV)
1998年8月11日- v1.00
微软的秘密

开源软件:A(新?)开发方法

执行概要

开源软件(OSS)是一个开发过程，它促进在现有代码/知识库中快速创建和部署增量特性，并修复错误。近年来，随着Internet的发展，OSS项目已经获得了传统上与商业项目(如操作系统和关键任务服务器)相关联的深度和复杂性。

因此，OSS对微软构成了直接的、短期的收入和平台威胁——尤其是在服务器领域。此外，开源软件中固有的并行性和自由的思想交流所带来的好处是我们目前的授权模式无法复制的，因此对开发人员的思想占有率构成了长期威胁。

然而，其他OSS过程的弱点为微软提供了在关键特性领域获得优势的途径，如架构改进(例如:

存储+)、集成(例如模式)、易用性和组织支持。

开源软件

是什么?

开源软件(OSS)是一种软件，其中的源文件和二进制文件都是针对特定产品发布或可访问的，通常是免费的。OSS经常被误认为是“共享软件”或“免费软件”，但两者之间有显著的区别许可每个产品的模型和流程。

软件许可分类

许可的大类包括:

• 商业软件

商业软件是微软典型的基本业务。

它必须购买，不能重新分发，通常只能以二进制文件的形式提供给最终用户。

• 有限试用软件

有限试用软件通常是免费分发的商业软件的功能有限版本，旨在推动商业代码的购买。例如60天定时炸弹评估产品。

• 共享软件

共享软件产品功能齐全，可自由再发布，但有一个授权，最终必须由个人和公司购买。许多互联网工具(如“WinZip”)利用共享软件作为一种分发方法。

• 非商业用途

非商业用途的软件是由非营利实体免费提供和再分发的。

公司等必须购买产品。网景导航器就是一个例子。

• 免版税二进制文件

免版税二进制文件由只能以二进制形式自由使用和分发的软件组成。

Internet Explorer和NetMeeting二进制文件适合这种模式。

• 免版税图书馆

免版税库是一种软件产品，其二进制文件和源代码可以自由使用和分发，但终端客户在不违反许可证的情况下不得修改。这方面的例子包括类库、头文件等。

• 开源(bsd风格)

一个小型、封闭的开发团队开发bsd风格的开源产品，并允许自由使用和重新分发二进制文件和代码。虽然允许用户修改代码，但开发团队通常不接受公众的“签到”。

• 开源(apache风格)

Apache采用bsd风格的开源模型，并通过允许外部各方签入核心代码库来对其进行扩展。

• 开源(CopyLeft, linux风格)

基于CopyLeft或GPL(通用公共许可证)的软件采用开源许可证之一至关重要的更深入了一步。

BSD和Apache风格的软件允许用户“分叉”代码库，并将他们自己的许可条款应用到他们修改的代码中(例如使其商业化)，而GPL许可证要求所有派生作品也必须是GPL代码。只要你的衍生品也可以被破解，你就可以自由破解这段代码

开源软件对微软来说意义重大

本文主要关注开源软件。

开源软件与其他形式的授权(特别是“共享软件”)在两个非常重要的方面有很大的不同:

1. 始终存在完全免费购买核心代码库的途径
2. 与自由分发的二进制文件不同，开源鼓励使用过程围绕核心代码库，并鼓励其他开发人员扩展代码库。

微软对OSS的关注有以下几个原因:

1. OSS项目已经达到了“商业品质”

在许多客户环境中，OSS进入的一个关键障碍是它被认为缺乏质量。OSS的支持者认为，在OSS软件中更大的代码检查和调试会导致更高质量的代码比商业软件好。

最近的案例研究(互联网)在客户眼中提供了非常引人注目的证据，证明OSS项目可以达到/超过商业质量。然而，在这个时候，除了传闻之外，没有强有力的OSS代码质量的证据。

2. OSS项目已经变得大规模和复杂

OSS解决的另一个进入障碍是项目的复杂性。

OSS团队正在承担的项目，其规模和复杂性在此之前一直是商业的、经济组织的/有动机的开发团队的专属领域。例如Linux操作系统和Xfree86 GUI。

OSS过程的生命力直接与Internet联系在一起，以提供大规模的分布式开发资源。OSS项目规模的一些例子:

3. OSS有一个独特的开发过程，具有独特的优势/劣势

OSS过程在其参与者的动机和可以用来解决问题的资源方面是独特的。

因此，OSS有一些有趣的、不可复制的资产，应该彻底理解。

历史

开源软件起源于业余爱好者和科学界，其典型特征是开发人员/用户对源代码的特别交换。

网络软件

开源软件最大的研究案例是互联网。正如Tim O 'Reilly在一次采访中所描述的那样，互联网上最早的大多数代码过去是，现在仍然是基于OSS的。http://www.techweb.com/internet/profile/toreilly/interview)：

蒂姆·奥莱利:我们开始时传达的最大信息是，“开源软件是可行的。”.．.绑定has absolutely dominant market share as the single most mission-critical piece of software on the Internet.

Apache是占主导地位的Web服务器。SendMail运行着大约80%的邮件服务器，并且可能涉及Internet上的每一封电子邮件

自由软件基金会/ GNU项目

现代、有组织的OSS的第一个实例通常要归功于麻省理工学院的Richard Stallman。1983年底，斯托曼创建了自由软件基金会(FSF)，目标是创建一个免费版的UNIX操作系统。

FSF以GNU的名字(递归地代表“GNU 's Not Unix”)发布了一系列源代码和二进制文件。

最初的FSF / GNU计划没有达到创建一个完全OSS Unix的最初目标。然而，他们确实贡献了一些著名的、广泛使用的应用程序和编程工具，包括:

• GNU Emacs最初是一个强大的字符模式文本编辑器，随着时间的推移，Emacs被增强为编译器，邮件阅读器等提供了一个前端。
• GNU C编译器(GCC) - GCC是学术界和OSS世界中使用最广泛的编译器。除了编译器之外，还有一组相当标准化的中间库作为ANSI C库的超集。
• GNU内容-后记打印机/查看器。

版权许可

FSF/GNU软件引入了“copyleft”许可方案，它不仅使对GNU软件隐藏源代码是非法的，而且使对作品隐藏源代码也是非法的源自GNU软件。描述这个许可证的文件被称为通用公共许可证(GPL)。

《连线》杂志对该计划及其意图有如下总结(http://www.wired.com/wired/5.08/linux.html)：

通用公共许可证(GPL)允许用户销售、复制和更改受版权保护的程序(这些程序也可以受版权保护)，但您必须传递同样的自由来销售或复制您的修改并进一步更改它们。

您还必须让您修改的源代码免费提供。

第二项条款——衍生作品的开放源代码——是CopyLeft许可中最具争议性的(也可能是最成功的)方面。

开源过程

商业软件开发过程的特点是围绕经济目标的组织。然而，由于金钱通常不是开源软件背后的(主要)动机，理解所构成的威胁的本质需要对开源开发团队的过程和动机有深刻的理解。

换句话说，要理解如何与OSS竞争，我们必须以一个过程而不是一个公司为目标。

开源开发团队

internet驱动的OSS团队的一些关键属性:

• 地理上遥远的。例如，Linux的一些主要开发人员统一分布在欧洲、美国和亚洲。
• 大量的贡献者和少量的核心个人。

  Linux，再一次，有超过1000人提交补丁、错误修复等，有超过200人直接为内核贡献代码。

• (短期内)不是金钱驱动的。这些人更像是业余爱好者，在保持其他全职工作的同时，将他们的空闲时间/精力花在OSS项目开发上。

  随着商业版本的Linux操作系统的出现，这种情况已经开始有所改变。

OSS开发协调

通讯——互联网规模

OSS团队的协调极度依赖于internet原生的协作形式。采用的典型方法涵盖了互联网协作技术的全部领域:

• 电子邮件列表
• 新闻组
• 国际用户全天候监控
• 网站

OSS项目的规模相当于Linux和Apache只有如果能够聚集足够大的高技能开发人员社区来解决问题，则是可行的。因此，OSS能够处理的项目的规模与Internet的增长之间有直接的关联。

共同的方向

除了沟通媒介，另一组因素含蓄地协调团队的方向。

共同的目标

共同目标相当于贯穿整个开发团队的分布式决策的愿景陈述。

一个明确的指令(例如“重新创建UNIX”)比多个无形的指令(例如“制作一个好的操作系统”)更有效地交流和执行。

常见的先例

优先级是潜在的最重要的因素解释了像Linux操作系统这样的大型OSS项目的快速而有凝聚力的增长。

因为整个Linux社区在处理许多其他形式的UNIX方面都有多年的共同经验，所以他们能够以一种非对抗性的方式很容易地辨别出哪些有效，哪些无效。

对于在文本编辑器中使用的命令语法没有争论-每个人都已经使用了“vi”，开发人员只是将命令名称空间分成块进行开发。

拥有20:20的历史后见之明能够提供一个强大且含蓄的结构。在更有前瞻性的组织中，这种结构是由强有力的、有远见的领导提供的。

共同的一套技能

NatBro指出，需要一个被普遍接受的技能集作为OSS开发的先决条件。这一点与常见的先例现象密切相关。

他在邮件中写道:

一个关键的属性…是OSS利用和加强的通用UNIX/gnu/make技能集。我认为如果准入门槛比现在高得多，整个过程就行不通了……

一个技术一般的UNIX程序员可以使用Linux和许多OSS产品做很多事情。换句话说——对于OSS领域的开发人员来说，抓痒并不难，因为东西之间的构建非常相似，调试也相似，等等。

虽然先例确定了最终目标，但公共技能集属性描述了精通实现该目标所需过程的人员数量。

大教堂和集市

开源软件倡导者Eric Raymond在1997年5月首次发表了一篇非常有影响力的论文(http://www.redhat.com/redhat/cathedral-bazaar/)．Raymond的论文被Netscape(当时的)CTO Eric Hahn明确引用，作为他们决定发布浏览器源代码的动机。

Raymond剖析了他的OSS项目，以得出未来其他OSS项目可以利用的经验法则。

Raymond的一些规则包括:

每一项优秀的软件工作都是从满足开发人员的个人需求开始的

这总结了开发人员在OSS过程中的核心动机之一——解决单个开发人员面临的眼前问题——这使得OSS能够在没有来自营销/支持组织的持续反馈的情况下发展复杂的项目。

优秀的程序员知道该写什么。伟大的作家知道重写(和重用)什么。

Raymond认为，开发人员在严格的开源过程中比在更传统的开发环境中更有可能重用代码，因为他们总是能够始终保证访问整个源代码。

广泛可用的开放源代码降低了查找特定代码片段的搜索成本。

“打算扔掉一个;不管怎样，你会的。”

引用弗雷德·布鲁克斯的《神秘的人月》，第11章。因为OSS中的开发团队通常分布非常广泛，Linux中的许多主要子组件都有几个初始原型，然后由Linus选择和改进一个设计。

将用户视为共同开发人员是实现快速代码改进和有效调试的最省事途径。

Raymond提倡为OSS项目提供强有力的文档和重要的开发人员支持，以使其收益最大化。

代码文档被引用为商业开发人员通常忽视的一个领域，这在OSS中是一个致命的错误。

早发布。经常发布。倾听你的客户。

然而，OSS的倡导者会注意到，他们的发布-反馈周期可能比商业软件快一个数量级。

如果有足够大的beta测试人员和合作开发人员，几乎每个问题都会很快被描述出来，并且对某些人来说解决方法也很明显。

这可能是雷蒙德对OSS过程的洞察的核心。

他将这条规则解释为“调试是可并行的”。下面是更深入的分析。

并行开发

一旦建立了组件框架(例如关键API和结构定义)，OSS项目(如Linux)就会利用多个独立的小团队来解决特定的问题。

因为开发人员通常是业余爱好者，“资助”多个相互竞争的努力的能力不是问题，OSS过程受益于从许多产生的实现中挑选最佳潜在实现的能力。

注意，这非常依赖于:

• 愿意提交代码的一大群人
• 一个强大的、隐式的组件化框架(在Linux的情况下，它继承自UNIX体系结构)。

并行调试

Eric Raymond提出的核心论点是，与软件开发的其他方面不同，代码调试是一种效率几乎随项目中个人数量的增加而线性提高的活动。与调试一段开源代码相关的管理或协调成本很少/没有-这是OSS布鲁克斯定律中的关键“突破”。

Raymond收录了Linus Torvald对Linux调试过程的描述:

我最初的提法是，每个问题“对某些人来说都是透明的”。

李纳斯提出异议，认为理解并解决问题的人不一定，甚至通常都不是第一个描述问题的人。“有人发现了问题，”他说，“而另一些人理解了它。我将公开表示，找到它是更大的挑战。”但关键是，这两件事往往发生得很快

交替:

“调试是并行的”。

杰夫[达基<(电子邮件保护)>]注意到，尽管调试需要调试器与一些协调开发人员通信，但它不需要调试器之间的重大协调。因此，它不会受到二次复杂度和管理成本的影响，而增加开发人员是有问题的。

并行调试的一个优点是bug及其修复程序的发现/传播速度比传统过程快得多。例如，当TearDrop IP攻击第一次发布到网络上时，不到24小时，Linux社区就有了一个可用的修复程序。

“脉冲调试”

并行调试的一个扩展，我将添加到Raymond的假设是“脉冲调试”。以Linux操作系统为例，安装操作系统的行为隐含着安装的行为调试/开发环境。因此，如果一个特定的用户/开发人员在另一个人的组件中遇到了一个错误——特别是如果这个错误是“浅层的”——这个用户很有可能很快地修补代码，并通过互联网协作技术，很快地将这个补丁传播给代码维护者。

换句话说，由于从GNU工具派生的通用开发/调试方法，OSS进程对调试过程的进入门槛非常低。

解决冲突

任何大规模的开发过程都会遇到必须解决的冲突。决议通常是为了进一步推进项目而做出的任意决定。在商业团队中，公司层级+绩效评估结构解决了这个问题——OSS团队如何解决它们?

在Linux方面，Linus Torvalds是这个项目无可争议的“领导者”。

他将大型组件(例如网络、设备驱动程序等)委托给几个他信任的“副手”，这些“副手”实际上进一步委托给少数“区域”所有者(例如局域网驱动程序)。

其他组织由Eric Raymond描述:(http://earthspace.net/~esr/writings/homesteading/homesteading-15.html):

一些非常大的项目完全抛弃了“仁慈的独裁者”模式。

一种方法是将共同开发人员转变为投票委员会(就像Apache一样)。另一种是轮换专政，在这种专政中，在高级共同开发人员的圈子中，控制权偶尔会从一个成员传递给另一个成员(Perl开发人员以这种方式组织自己)。

动机

本节概述了OSS开发人员寻求为OSS项目做出贡献的一些关键原因。

解决手头的问题

这基本上是雷蒙德的第一条经验法则的重新表述——“每一个好的软件工作都是从挠开发者的痒开始的”。

许多OSS项目——比如Apache——都是从一个小的开发团队开始着手解决眼前的问题。代码的后续改进通常来自于个人将代码应用于他们自己的场景(例如。

发现没有特定网卡的设备驱动程序，等等。)

教育

Linux内核源于赫尔辛基大学的一个教育项目。类似地，Linux / GNU系统的许多组件(X windows GUI、shell实用程序、集群、网络等)都是由教育机构的个人扩展的。

• 例如，据报道，在远东地区，Linux的发展速度比互联网连接还要快——这主要是由于教育的采用。
• 大学是OSS作为教学工具的最初支持者之一。
• 由于Linux源代码的广泛可用性，基于Linux的研究/教学项目很容易“传播”。特别是，这通常意味着新的研究思路首先在Linux上实现并可用，然后才可用/合并到其他平台。

自我满足

OSS开发社区提出的最虚无缥缈、也许也是最深刻的动机是纯粹的自我满足。

在《大教堂与集市》中，埃里克?

雷蒙德引用:

Linux黑客最大化的“效用函数”不是经典的经济，而是他们自己的自我满足和在其他黑客中的声誉的无形。

当然，“除非别人叫你黑客，否则你不是黑客。”

人类圈的家园

Raymond发表的第二篇论文“人类圈上的家园”(http://sagan.earthspace.net/~esr/writings/homesteading/)，讨论了经济动机交换(例如为了金钱而开发商业软件)和“礼物交换”(例如为了荣誉而开发OSS)之间的区别。

“宅地”是通过第一个“发现”它或最近对它做出重大贡献来获得财产。

“人类圈”被宽泛地定义为“所有工作的空间”。因此，Raymond假定，OSS黑客的动机是在工作主体中占有最大的区域。换句话说，把最大的一部分功劳揽在自己身上。

摘自《人类圈的家园》:

富足使得指挥关系难以维持，交换关系几乎成为毫无意义的游戏。在礼物文化中，社会地位不是由你所控制的东西决定的，而是由你放弃了什么．

.．.

如此看来，开源黑客社会其实是一种礼物文化。

在它里面，并不严重缺乏“生存必需品”——磁盘空间、网络带宽、计算能力。软件是免费共享的。这种富足创造了一种情况，在这种情况下，衡量竞争成功的唯一标准是在同龄人中的声誉。

更简洁地说(http://www.techweb.com/internet/profile/eraymond/interview)：

西姆斯:所以你寻找的稀缺性是注意力和奖励的稀缺性?
雷蒙:完全正确。

利他主义

这是一个有争议的动机，我倾向于相信，在某种程度上，利他主义“退化”为雷蒙德提出的自我满足论点的一种形式。

一个较小的动机，部分源于利他主义，是对微软的抨击。

代码分支

在任何大型开发团队中，一个关键的威胁是代码分叉的风险，而在互联网规模的开发团队中，这种威胁尤其会因流程混乱而加剧。

代码分叉发生在开发项目的普通推拉过程中，项目代码库的多个不一致版本进化而来。

例如，在商业世界中，Windows NT代码库的强大、单一管理被认为是它相对于商业UNIX实现(SCO、Solaris、IRIX、HP-UX等)中的“分叉”代码库的最大优势之一。

在oss - BSD Unix中分叉

在OSS领域，BSD Unix是分叉代码的最好例子。

最初的BSD UNIX是加州大学伯克利分校(U-Cal Berkeley)为了教学目的而尝试创建一个免版税的UNIX操作系统版本。然而，Berkeley对代码库的非学术使用进行了严格限制。

为了创建一个完全免费的BSD UNIX版本，一个专门的(但封闭的)开发团队创建了FreeBSD。其他与FreeBSD团队意见不一致的开发人员出于这样或那样的原因将操作系统分裂为其他变体(OpenBSD、NetBSD、BSDI)。

有两个主要因素导致了BSD树的分叉:

• 不是每个人都能对BSD代码库做出贡献。

  这限制了有效的“人类圈”的规模，并为其他人可信地声称他们的分叉代码将比核心BSD代码更具主导地位创造了可能性。

• 与GPL不同，BSD的许可证对衍生代码没有任何限制。因此，如果你认为你的修改足够酷，你可以自由地分叉代码，收取费用，改变它的名字，等等。

这两种动机都造成了一种情况，即开发人员可能会试图强行在代码中进行分叉，并以牺牲BSD社会的集体利益为代价来收取版税(金钱或自我)。

Linux中缺少分叉

与BSD示例相反，Linux内核代码库没有分叉。Linux代码库保持完整性的一些原因包括:

• 普遍接受的领导力

Linus Torvalds是Linux世界的名人，他的决定被认为是最终决定。

相比之下，类似的名人领袖并不存在于bsd衍生的努力中。

Linus被开发团队认为是一个公正、理性的代码管理员，他在Linux社区的声誉相当高。然而，莱纳斯并没有参与每一个决定。通常，子组会解决它们之间(通常是很大的)差异，并防止代码分叉。

• 开放会员资格和长期贡献潜力。

与BSD的封闭成员制相反，任何人都可以为Linux做出贡献，而您的“地位”——以及因此“建立”更大一块Linux的能力——取决于您以前的贡献大小。

这间接地进一步抑制了代码分叉。

几乎没有可靠的机制可以让分叉的、少数的代码库能够保持主要Linux代码库的创新速度。

• GPL许可消除了代码分叉的经济动机

因为Linux的衍生品必须通过一些免费途径获得，它降低了拥有Linux分叉树的少数政党的长期经济收益。

• 代码库的分叉也意味着“人类圈”的分叉

自我动机促使OSS开发人员在最大的人类圈中植入最大的利益。代码库的分叉不可避免地缩小了任何后续开发人员完成新代码树的空间。

开源的优势

微软需要关注的OSS产品的核心优势是什么?

OSS指数属性

像我们的操作系统业务一样，OSS生态系统有几个指数属性:

• OSS进程随着Internet的发展而发展

任何OSS项目面临的最大限制是找到足够多的有兴趣为项目贡献时间的开发人员。作为一个推动者，互联网绝对有必要将足够多的人聚集到一个操作系统规模的项目中。

更重要的是，增长引擎这些项目的主要原因是互联网覆盖范围的扩大。协作技术的改进直接润滑了OSS引擎。

换句话说，互联网的发展将使现有的OSS项目变得更大，并将使“较小”软件类别的OSS项目变得可行。

• OSS过程是“赢者通吃”

就像商业软件一样，从长远来看，在许多类别中最可行的单个OSS项目将扼杀竞争性的OSS项目，并“获得”它们的IQ资产。例如，Linux正在杀死BSD Unix，并吸收了BSD Unix的大部分核心思想(以及商业Unix中的思想)。

该特性为特定项目提供了巨大的先发优势

• 开发人员寻求为最大的OSS平台做出贡献

OSS项目越大，为其Noosphere贡献大型、高质量组件的声望就越大。这种现象导致了在给定的部分中OSS过程的“赢家通吃”性质。

• 更大的OSS项目可以解决更多的“手头问题”

项目越大，代码得到的开发/测试/调试就越多。调试越多，部署它的人就越多。

长期的信誉

二进制文件可能会死亡，但源代码永远存在

可行的OSS生态系统最有趣的含义之一是长期可信度。

定义长期信誉

如果你不可能在短期内被赶出这个行业，那么长期信誉是存在的。

这会迫使竞争对手改变与你打交道的方式。

例如，空客工业公司从政府的明确支持中获得了最初的长期信誉。因此，在竞标航空公司合同时，波音在与洛克希德竞标时比在与空客竞标时更有可能接受短期的、非经济的回报。

松散地应用于软件行业的术语，如果FUD策略不能用于对抗它，那么产品/过程是长期可信的。

Oss是长期可信的

OSS系统被认为是可信的，因为源代码可能来自数百万个地方和个人。

例如，Apache停止存在的可能性比WordPerfect消失的可能性要低几个数量级。Apache的消失与二进制文件的消失(受到购买移位等的影响)无关，而是与源代码和知识库的消失有关。

反过来说，客户知道Apache还会存在5年左右——前提是它的用户/开发社区存在一些最小的持续兴趣。

一个Apache客户，在讨论他在OSS上运行他的电子商务网站的理由时说，“因为它是开源的，我可以指派一两个开发人员来维护它，我自己可以无限期地维护它。

”

缺乏代码分叉会增加长期可信度

GPL及其对代码分叉的厌恶让客户放心，他们不会因为订阅特定的Linux商业版本而走到进化的“死胡同”。

“进化的死胡同”是软件FUD争论的核心。

并行调试

Linux和其他OSS的倡导者正在提出一个越来越可信的论点，即OSS软件至少和商业替代品一样健壮——如果不是更健壮的话。Internet为OSS世界提供了一个理想的、高能见度的展示平台。

特别是那些依靠OSS进行业务操作的更大、更精明的组织(例如isp)，他们可以独立于商业提供商的计划修复一个停止工作的错误(例如，UUNET能够在第一次公开攻击的24小时内获得、编译并将泪滴攻击补丁应用到他们部署的Linux机器上)，这一事实让他们感到欣慰。

并行开发

换句话说，“开发人员资源在OSS中基本上是免费的”。因为潜在的开发人员是巨大的，所以同时研究一个问题的多个解决方案/版本并最终选择最佳解决方案在经济上是可行的。

例如，Linux TCP/IP堆栈可能重写了3次。特别是汇编代码组件一直在不断地手工调优和改进。

OSS =“完美的”API传播/文档

OSS的API传播/开发人员教育基本上是为开发人员提供底层代码。在闭源模型中，API的传播基本上默认为信任，而OSS API的传播则让开发人员自己做决定。

释放率

强组件化的OSS项目能够在开发人员完成代码后立即发布子组件。

因此，OSS项目快速频繁地发展。

开源的弱点

OSS项目的弱点主要有3个方面:

• 管理成本
• 过程问题
• 组织的可信度

管理成本

OSS项目的最大障碍是处理管理成本的指数级增长，因为项目的创新速度和规模都在增加。这意味着OSS项目创新速度的限制。

启动一个OSS项目是困难的

来自Eric Raymond的评论:

很明显，一个人不能以集市风格从头开始编码。人们可以以集市的方式进行测试、调试和改进，但这是非常困难的产生一个市集模式的项目。

莱纳斯没有尝试。我也不知道。您的新兴开发人员社区需要有一些可运行和可测试的东西。

Raymond的论点可以扩展到如果项目没有明确的先例/目标(或目标太多)，启动/维持项目的困难。

市场信誉

显然，互联网上的源代码片段远远多于OSS社区。

是什么将“死源代码”与繁荣的集市区分开来?

一篇文章(http://www.mibsoftware.com/bazdev/0003.htm)提供以下资料信誉标准:

“…以一个严格的最低参与者数量来思考是有误导性的。Fetchmail和Linux现在有大量的beta测试者，但很明显他们在开始的时候都很少。

这两个项目所拥有的都是一小撮热心人士和一个貌似合理的承诺。承诺部分是技术方面的(这段代码稍加努力就会很棒)，部分是社会学方面的(如果您加入我们的团队，您将获得和我们一样多的乐趣)。

所以，一个成熟的集市的存在是可信的，这是集市发展的必要条件!”

我认为一个集市可信的一些关键标准包括:

• 大未来人类圈-项目必须足够酷，智力奖励能够充分补偿开发者投入的时间。Linux操作系统在这方面更胜一筹。
• 挠痒痒-该项目必须是重要的/可部署的大量观众开发人员．Apache web服务器在这里提供了一个很好的例子。
• 先解决问题的适量解决太多的问题会让OSS开发社区沦为测试人员的角色。

  在使用开源软件之前解决的太少会减少“看似合理的承诺”，并且不能提供足够强大的组件框架来有效地协调工作。

Post-Parity发展

在向JimAll描述这个问题时，他给出了一个“追逐尾灯”的完美类比。从一个大型的半组织的暴徒中获得协调行为的最简单的方法是将他们指向一个已知的目标。尾灯为模糊的视觉提供了具象性。在这种情况下，有一个尾灯可以跟随，代表着有强大的中央领导。

当然，一旦这种隐含的组织原则不再可用(一旦一个项目达到了与最先进的“同等水平”)，推动新领域所需的管理水平就会变得巨大。

这可能是Linux社区面临的最有趣的障碍，因为他们在许多方面已经达到了与UNIX最先进的水平相当的水平。

毫不起眼的工作

在OSS不久的将来，另一件值得观察的有趣的事情是，团队能够很好地处理将商业级产品带到生活中所必需的“乏味”工作。

在操作系统领域，这包括一些基本的小功能，如电源管理、挂起/恢复、管理基础设施、UI细节、深度Unicode支持等。

对于Apache，这可能意味着新手管理员的功能，如向导。

综合/建筑工作

跨模块的集成工作是OSS团队遇到的最大成本。

Nathan Myrhvold在1998年5月的一封电子邮件备忘录中指出，在软件开发的所有方面中，集成工作最受Brooks定律的约束。

到目前为止，Linux已经做到了极大地得益于以前UNIX所推动的集成/组件化模型。此外，由于HTTP协议和UNIX服务器应用程序设计的相对简单的容错规范，Apache的组织也得到了简化。

未来需要改变核心架构/集成模型的创新对于OSS团队来说将是难以置信的困难，因为它同时贬低了他们的先例和技能集。

过程问题

这些都是OSS设计/反馈方法的固有弱点。

迭代的成本

OSS进程的关键之一是要比商业软件有更多的迭代(众所周知，Linux内核每天更新不止一次!)然而，商业客户告诉我们他们想要更少的转速，不是更多。

“非专业”反馈

Linux操作系统不是为最终用户开发的，而是为其他黑客开发的。

类似地，Apache web服务器隐式地针对最大、最精明的站点运营商，而不是部门内网服务器。

这里的关键线索是，由于OSS没有明确的市场/客户反馈组件，愿望清单——以及因此产生的功能开发——由最精通技术的用户主导。

微软的开发团队一次又一次地学到的一件事是，易用性、UI的直观性等必须从头开始构建到产品中，而不能在以后的时间里粘贴上去。

这里观察到的有趣趋势是商业OSS提供商(如Linux领域的RedHat, Apache领域的C2Net)对反馈周期的影响。

组织的可信度

OSS如何提供服务消费者对软件供应商的期望是什么?

支持模型

产品支持通常是OSS软件包的潜在消费者担心的第一个问题，也是商业再分发者吹捧的主要特性。

然而，绝大多数OSS项目都是由各自组件的开发人员支持的。将这种支持基础设施扩展到商业产品的预期水平将是一个重大挑战。

在IIS和Apache中，用户和开发人员之间存在许多数量级的差异。

从短期到中期来看，仅这一因素就会将OSS产品降级到用户社区的顶层。

战略期货

一个影响用户全面采用OSS项目的非常严重的问题是在OSS开发周期中缺乏战略方向。虽然对OSS产品中当前功能包的增量改进是非常可信的，未来的功能没有组织承诺来保证他们的发展。

对于Linux社区来说，“注册”帮助建立企业数字神经系统意味着什么?Linux如何保证与以前的API编写的应用程序的向后兼容性?

如果Linux的下一个版本违背了某些承诺，你会起诉谁?Linux如何与其他实体建立战略联盟?

开源商业模式

在过去的两年里，随着出售OSS软件的公司的出现，OSS又发生了另一个转折，更重要的是，他们雇佣了全职的开发人员来改进代码库。是什么样的商业模式使这些薪水合理?

在许多情况下，这些问题的答案类似于“为什么我应该将我的协议/应用程序/API提交给标准组织?”

二次服务

OSS-ware的供应商向客户提供销售、支持和集成。

实际上，这将OSS-ware供应商从打包产品制造商转变为服务提供商。

亏损领先者-市场进入

Loss Leader OSS业务模型可用于两个目的:

• 启动一个新生市场
• 打入现有市场，与根深蒂固的、封闭的参与者

许多OSS创业公司——尤其是那些在操作系统领域的公司——将资助OSS产品的开发视为对抗微软的战略亏损领先者。

Linux发行商，如RedHat、Caldera和其他发行商，都明确表示愿意资助那些向OSS社区发布所有工作成果的全职开发人员。通过同时为这些努力提供资金，Red Hat和Caldera暗中勾结，并相信他们将通过扩大Linux市场而不是直接相互竞争来获得更多的短期收入。

一个间接的例子是O 'Reilly & Associates雇佣了Larry Wall——PERL的“领导者”和全职开发人员。PERL参考书的头号出版商当然是O 'Reilly & Associates。

就短期而言，特别是当OSS项目处于增长曲线最陡峭的部分时，这样的投资会产生正的ROI。

从长远来看，ROI动机可能会引导这些开发人员开发专有扩展，而不是发布OSS。

下游供应商商品化

这与亏本销售业务模式密切相关。然而，这些企业并没有试图通过大规模扩大市场来获得边际服务回报，而是通过使下游供应商商品化来提高其所在价值链部分的回报。

目前最好的例子是瘦服务器供应商，如Whistle Communications和Cobalt Micro，他们分别积极资助SAMBA和Linux的开发人员。

Whistle和Cobalt的收入都来自硬件数量。因此，资助OSS使他们能够避免今天的PC市场，即必须向操作系统供应商支付“税”(NT服务器零售价为800美元，而Cobalt的目标建议零售价约为1000美元)。

最早的Apache开发人员受雇于资金紧张的isp和icp。

另一个最近的例子是IBM与Apache的交易。

通过宣布HTTP服务器是一种商品，IBM希望将收益集中在技术上更为神秘的应用程序服务上，它捆绑在Apache发行版中(同时也希望获得Apache巨大的市场份额)。

先发者-现在构建，以后$$

OSS的指数级特性之一——成功的OSS项目在其空间中吞并不太成功的项目——意味着一种先发制人的商业模式，即通过今天直接投资于OSS，他们可以在以后先发制人/淘汰有竞争力的项目——特别是如果项目需要API推广的话。这就相当于在OSS中占据先发优势。

此外，OSS过程的开发人员规模、迭代率和可靠性优势对于那些通常无法负担大量内部开发人员的小型初创公司来说是一种福音。

这个领域的初创公司包括SendMail.com(制作商业支持的sendmail邮件传输代理)和C2Net(制作商业和加密的Apache)。

注意，没有成功创业的案例原始一个OSS项目已经被观察到。在这两种情况下，OSS项目都存在之前初创公司成立了。

太阳微系统公司最近宣布，它的“JINI”项目将通过OSS的形式提供，并可能代表抢占原则的应用。

Linux

接下来的几节将分析最著名的OSS项目，包括Linux、Apache，以及Netscape的OSS浏览器。

第二份备忘录题为“Linux操作系统竞争分析”，提供了对Linux操作系统的深入回顾。

在这里，我提供了我在Linux中的发现的顶级总结。

是什么?

Linux(发音为“LYNN-ucks”)是互联网上市场份额第一的开源操作系统。Linux很大程度上源自于UNIX操作系统25年以上的经验教训。

高级功能:

• 多用户/多线程(内核和用户)
• 多平台(x86、Alpha、MIPS、PowerPC、SPARC等)
• 受保护的32位应用程序内存空间;虚拟内存支持(开发中的64位)
• SMP (Intel & Sun CPU)
• 支持多个文件系统(FAT16, FAT32, NTFS, Ext2FS)
• 高性能组网
  • NFS / SMB / IPX /可路由协议组网络
  • Unix与Unix性能测试中最快的堆栈
• 磁盘管理
  • 条带，镜像，FAT16, FAT32, NTFS
• Xfree86 GUI

Linux是一个真正可靠的OS +开发过程

像其他开源软件产品一样，Linux的真正关键不是产品的静态版本，而是围绕它的过程。这个过程为客户的Linux投资提供了可信度和未来安全的氛围。

• 在关键任务环境中值得信赖．Linux已经部署在任务关键的商业环境中，并获得了大量的公众好评。
• Linux =最好的UNIX。Linux在大多数主要性能类别(网络、磁盘I/O、进程ctx交换机等)上优于许多其他UNIX。

  为了扩大他们的特性库，Linux还大量地窃取了其他UNIX的特性(shell特性、文件系统、图形、CPU端口)。

• 只有Unix操作系统获得市场份额。Linux正朝着最终占领x86 UNIX市场的方向发展，并且是近年来唯一获得净服务器操作系统市场份额的UNIX版本。我相信Linux比NT更能在不久的将来成为SCO最大的威胁。
• Linux的进程迭代非常快。例如，Linux中相当于TransmitFile()的API从想法到最终实现只用了大约2周的时间。

Linux是服务器的一个短期或中期威胁

微软面临的来自Linux的主要威胁是针对NT服务器。

Linux对NT服务器(和其他unix)的未来优势是由以下几个关键因素决定的:

• Linux使用普通PC硬件，由于操作系统模块化，可以在比NT更小的系统上运行。Linux经常用于在旧的486上运行的DNS等服务。
• 由于继承了UNIX的传统，对于一些组织来说，Linux的转换成本比NT低
• UNIX的可伸缩性、互操作性、可用性和可管理性(SIAM)优于NT。
• 只要服务/协议是商品，Linux就能获胜

Linux不太可能对桌面构成威胁

从中长期来看，Linux不太可能对桌面构成威胁，原因如下:

• 糟糕的终端用户应用和关注点。OSS开发过程在解决单个组件问题方面比解决集成场景(如端到端易用性)要好得多。
• 桌面安装基础的切换成本。更换桌面是困难的，挑战者必须能够证明自己具有显著的边际优势。

  Linux的过程更侧重于后发优势(例如复制已被证明有效的东西)，因此不太可能提供提供转换动力所需的先发优势。

• UNIX传统将减缓侵蚀。易用性必须从头开始设计。Linux的黑客定位永远无法满足普通桌面用户的易用性要求。

Linux跳动

除了攻击OSS项目的一般弱点(例如。

集成/架构成本)，一些针对Linux的具体攻击有:

• 击败UNIX

NT和Sun的所有标准产品问题都适用于Linux。

• 将扩展功能折叠到商品协议/服务中，并创建新的协议

Linux的基地目前是商品网络和服务器基础设施。通过将扩展功能(例如文件系统中的存储+，网络中的DAV/POD)折叠到今天的商品服务中，我们提高了标准并改变了游戏规则。

网景

为了重新树立它在浏览器领域的信誉，Netscape最近发布并试图围绕其Mozilla源代码创建一个OSS社区。

组织与授权

网景的组织和授权模式松散地基于Linux社区和GPL，但有一些不同。

首先，Mozilla和Netscape Communicator是由Netscape工程师提供同步的两个代码库。

• Mozilla = OSS，免费分发的浏览器
• Netscape Communicator = Mozilla的品牌，轻微修改(例如主页默认设置为home.netscape.com)版本。

与完整的GPL不同，网景保留拒绝/强制修改Mozilla代码库的最终权利，网景的工程师被任命为大型组件的“区域主管”(目前)。

的优势

利用OSS社区的反微软情绪

相对于其他OSS项目，Mozilla被认为是对微软体制最直接、近期的攻击之一。这个因素本身可能是激励开发人员使用Mozilla代码库的一个关键激励因素。

新的可信度

Mozilla源代码的可用性在一定程度上恢复了网景在浏览器领域的信誉。

正如bharat所指出的http://ie/specs/Mozilla/default.htm:

“他们通过发布代码保证，他们永远不会像Wordstar那样完全从地平线上消失。即使用户基数缩水，Mozilla浏览器也将在未来10年继续生存下去。”

挠痒痒

浏览器被广泛使用/传播。

因此，愿意解决“眼前的问题”和/或修复bug的人可能相当多。

弱点

后平价发展

Mozilla已经接近IE4/5了。因此，没有强有力的例子来帮助隐含地协调开发团队。

网景已经指派了一些顶级的开发人员全职管理Mozilla的代码库，看看这将如何帮助(如果有的话)Mozilla开拓新领域的能力将是很有趣的。

小的人类知识的总和

一个有趣的缺点是OSS浏览器剩余的“Noosphere”的大小。

1. 独立浏览器基本完成。

独立浏览器不再有需要开发的大型、高知名度的部分。换句话说，网景已经解决了有趣的80%的问题。在调试/修正Netscape剩余20%的代码时，几乎没有自我满足。

2. 网景的商业利益削弱了人类圈贡献的影响力。

Linus Torvalds对Linux代码库的管理可以说是以创建最好的Linux为目标的。

相比之下，网景明确保留了在网景的基础上进行代码管理决策的权利商业/商业利益．开发者的代码并没有创造出重要的产品，而是屈从于网景公司的股价。

集成成本

对Mozilla的努力最大的潜在危害是客户对浏览器特性的期望的集成程度。如前所述，集成开发/测试不是一个可并行的活动，因此是伤害由OSS过程。

特别是，针对IE5+的许多新工作不仅仅是在浏览器中集成组件，而是在操作系统中继续集成。

这将是一个非常痛苦的竞争对手。

预测

因此，争论的焦点在于，与目前相当成功的Apache和Linux项目不同，网景的Mozilla项目将:

• 在Linux和一些UNIX上生成占主导地位的浏览器
• 从长远来看，继续落后于IE

请记住，源代码只是在很短的时间前(1998年4月)发布的，已经有证据表明人们对Mozilla的兴趣正在减弱。从4月到6月，Mozilla邮件列表上的邮件列表数量下降，这是非常不科学的证据。

Mozilla邮件列表的内部镜像可以在http://egg.Microsoft.com/wilma/lists上找到

Apache

历史

转述的http://www.apache.org/ABOUT_APACHE.html

1995年2月，Web上最流行的服务器软件是由伊利诺伊大学香槟分校的NCSA开发的公共域HTTP守护进程。然而，httpd的开发在1994年年中之后停滞不前，许多网站管理员已经开发了他们自己的扩展和错误修复，需要一个通用的发行版。

一个由这些网站管理员组成的小组，通过私人电子邮件联系，为了协调他们的变化(以“补丁”的形式)而聚集在一起。到1995年2月底，8位核心贡献者组成了最初的Apache集团的基础。1995年4月，Apache 0.6.2发布。

在1995年5月至6月期间，一个新的服务器架构(代号为Shambhala)被开发出来，它包括一个模块化结构和API，以获得更好的可扩展性，基于池的内存分配，以及一个自适应的预分叉进程模型。

团队在7月份切换到这个新的服务器基础，并添加了0.7版本的特性。x，导致Apache 0.8.8(及其同类)在8月发布。

小组成立不到一年，Apache服务器就超过了NCSA的httpd，成为互联网上排名第一的服务器。

组织

Apache开发团队由大约19名核心成员和来自世界各地的数百名网站管理员组成，他们都提交过这样或那样的错误报告/补丁。Apache的bug数据可以在下面找到:http://bugs.apache.org/index．

Apache团队所遵循的代码管理和争议解决程序的描述可以在上面找到http://www.apache.org:

领导:

有一个由项目创始人组成的核心贡献者小组(非正式地称为“核心”)，当核心成员提名杰出的贡献者并且其他核心成员同意时，这个小组会不时地扩大。

争议解决:

对代码的更改是在邮件列表上提出的，通常由活跃的成员进行投票——在发布周期内提交代码更改需要3 +1(赞成投票)和no -1(没有投票或否决)

的优势

市场份额!

Apache目前在互联网上的网站占有率遥遥领先。拥有最大的市场份额，就能对市场的演变提供极其强大的控制。

特别是，Apache在web服务器领域的市场份额呈现出以下竞争障碍:

• 最低公分母的HTTP协议——降低了我们扩展协议以支持新应用程序的能力
• 为UNIX注入更多活力——Apache走到哪里，UNIX就必须跟上。

3.^{理查德·道金斯}方支持

Apache可用的工具/模块/插件的数量一直在以越来越快的速度增长。

弱点

性能

从短期来看，IIS在SPECweb上完胜Apache。

更进一步，随着IIS进入内核并利用与NT的更深入集成，预计这种领先优势将进一步增强。

相比之下，Apache则需要为其所有操作系统环境创建可移植的代码。

HTTP协议复杂性和应用服务

Apache能够立足并迅速发展的部分原因是因为HTTP协议非常简单。随着越来越多的功能在不起眼的web服务器上分层(例如多服务器事务支持，POD等)，Apache团队将如何跟上这一趋势将是很有趣的。

例如，ASP支持是企业内部网中IIS的关键驱动因素。

IBM和apache

最近，IBM宣布在其WebSphere应用服务器中支持Apache代码库。

然而，媒体愤怒的实际结果仍不清楚:

• IBM仍然提供并支持Apache和Domino的GO web服务器
• IBM的承诺似乎是:
  • 帮助Apache移植到战略IBM平台(AS/400等)
  • 将Apache二进制文件重新分发给请求Apache支持的客户
  • 对Apache二进制文件的支持(如果是从IBM购买的?)
• IBM让开发人员积极参与Apache开发/讨论组。
• IBM在为NT优化Apache方面起着主导作用

其他一些oss项目:

• Gimp- - - - - -http://www.gimp.orgGimp (GNU图像处理程序)是一个OSS项目，为Unix工作站创建一个Adobe Photoshop克隆。然而，在功能方面，他们的1.0版本项目更类似于PaintBrush。
• 酒/瓦比- - - - - -http://www.wine.orgWine (Wine不是一个模拟器)是一个用于UNIX的OSS windows仿真库。Wine(在某种程度上)与Sun的WABI项目竞争，后者是非oss的。

  例如，旧版本的Office能够在WINE中运行，但性能仍有待评估。

• PERL- - - - - -http://www.perl.orgPERL(实用评估和报告语言)是所有Apache web服务器事实上的标准脚本语言。PERL在UNIX上非常流行，特别是由于其强大的文本/字符串操作和UNIX对所有功能的命令行管理的依赖。
• 绑定- - - - - -http://www.bind.org- BIND(伯克利互联网名称守护进程)是互联网事实上的DNS服务器。在许多方面，DNS是在BIND的基础上开发的。
• Sendmail- - - - - -http://www.sendmail.orgSendmail是当今互联网上#1的共享邮件传输代理。
• 鱿鱼- - - - - -http://squid.nlanr.net—Squid是基于ICP协议的OSS Proxy服务器。

  鱿鱼虽然性能不佳，但在国际大型isp中颇受欢迎。

• SAMBA- - - - - -http://samba.org—SAMBA为UNIX系统提供SMB文件服务器。最近，SAMBA团队也成功地对UNIX进行了反向工程并开发了一个NT域控制器。SGI雇佣了一位SAMBA领导者。

  http://www.sonic.net/鲁洛夫•/报告/ linux - 19980714 phq.html:“到今年年底，Samba将能够完全取代所有主要的NT服务器功能。”

• KDE- - - - - -http://www.kde.org-“K”桌面环境。结合集成的浏览器，shell和Unix桌面办公套件。

  以下是截图:http://www.kde.org/kscreenshots.html而且http://www.kde.org/koffice/index.html．

• 总监互联网上占主导地位的邮件列表服务器完全是通过OSS用PERL编写的。

微软的反应

总的来说，微软对OSS现象的反应需要更多的思考和讨论。本文档的目标是教育和分析OSS过程，因此在本节中，我只给出一个非常肤浅的选项和关注点列表。

产品缺陷

在不久的将来，微软最可能感受到OSS项目“压力”的地方是哪里?

服务器vs.客户端

服务器比客户端更容易受到OSS产品的攻击。原因包括:

• 客户更频繁地“切换任务”-一般客户端桌面比服务器用于更广泛的应用程序。因此，集成，易于使用，适合和完成等。

  都是关键属性。

• 服务器是更特定于任务的如果目标/先例被明确定义，OSS产品工作得最好——例如，提供商品协议
• 商品服务器的“承诺”比客户端低-用开源替代方案取代诸如文件、打印、邮件中继等商品服务器不会影响最终用户的体验。

  此外，在这些商品服务中，一个“一次性的”“实验性的”解决方案经常会被组织所接受。

• 服务器是专业管理的这发挥了OSS在定制方面的优势，并减轻了缺乏终端用户易用性方面的弱点。

获取OSS的好处-开发者的思想分享

OSS过程收集和利用互联网上成千上万个人的集体智商的能力简直令人惊叹。更重要的是，OSS的传播与互联网的规模比我们自己的传播速度要快得多。

微软如何抓住那些专注于OSS产品的狂热开发者的注意力?

一些初步想法包括:

• 通过更广泛的代码许可获得并行调试的好处在向诸如大学和某些合作伙伴等组织分发NT的源代码许可时要更加自由。
• 提供低成本/免费的入门级工具工具的第二级效应是生成一种共同的技能集/词汇，供开发人员使用。正如NatBro所指出的，Linux/UNIX中一致的开发人员工具集的广泛可用性是隐式协调系统的关键手段。
• 发布部分源代码-试着让黑客对微软赞助的代码库产生兴趣。

  部分TCP/IP堆栈可能是第一个候选。然而，OshM指出，挑战在于在微软的代码库中找到足够大的Noosphere来引起人们的兴趣。

• 提供更多的可扩展性Linux“狂热开发人员”喜欢编写/理解未记录的API和内部结构。记录/发布一些“不受支持”的内部API可能是产生外部创新的一种手段，可以利用我们的系统投资。

  特别是，确保来自更多团队的更多组件是可脚本化/自动化的，这将有助于确保高级用户可以使用我们的组件。

• 创建社区/人类知识的总和．MSDN覆盖的人群非常庞大。我们该如何创造能够利用庞大开发者群体提供网络利益的社交结构呢?

  例如，如果我们在Microsoft.com上有一个中央VB展示，允许VB开发人员发布他们的VB项目的完整源代码，与其他VB开发人员分享，会怎么样?我认为许多VB开发人员会从可以从Microsoft.com下载他们的名字/代码中获得极大的自我满足。

• 监控OSS新闻组．学习新思想，雇佣最优秀/最聪明的人。

获取OSS的好处-微软内部流程

微软能从OSS的例子中学到什么?

更具体地说:我们如何在内部重新创建OSS开发环境?本文的不同评论者一致指出，在内部，我们应该将微软视为一个理想的OSS社区，但是，由于各种原因，我们没有这样做:

• 不同的发展“模式”。设置NT构建/开发环境极其复杂，与Office团队使用的环境截然不同。
• 不同的工具/源代码管理器。一些团队使用SLM，另一些使用VSS。不同的bug数据库。

  不同的构建过程。

• 没有中央存储库/代码访问。没有一组中央服务器来查找、安装、检查您当前范围之外的项目的代码。即使只是为调试符号提供一个中央存储库也是一个巨大的改进。NatBro:

“微软的操作系统开发人员不能用Excel来挠痒痒，Excel开发人员也不能用操作系统来挠痒痒——他们要花几个月的时间才能弄清楚如何构建、调试和安装，而且他们可能无法获得适当的源代码访问权限。”

• 广泛的开发人员沟通．处理特定组件和错误报告的邮件列表通常不对团队成员开放。
• 更强的组件健壮性．

  Linux和其他OSS项目使开发人员可以很容易地在系统中试验小组件，而不用在其他组件中引入回归:

“人们必须独立于其他部分工作，因此组件之间的内部抽象被很好地记录和公开/导出，并且更加健壮，因为他们不知道它们将如何被调用。linux开发系统已经发展到允许更多的开发人员在上面聚会，而不会引起大量的集成问题，因为健壮性存在于每个级别。从长远来看，这对整体稳定是很好的，而且已经有所体现。”

当然，诀窍是在不产生OSS过程成本的情况下获得这些好处。

这些成本通常是设立此类壁垒的首要原因:

• 集成。一个组件的全职开发人员在尝试分析和集成公司内其他开发人员的修复之前已经有很多工作要做。
• 迭代成本和依赖关系。一个Excel开发人员使用的“划痕”版本操作系统和另一个Excel开发人员使用的“核心”操作系统之间可能存在迷你代码分叉。

扩展OSS的好处——服务基础设施

支持一个平台和开发社区需要很多服务OSS无法提供的基础设施。这包括PDC, MSDN, ADCU, isv, ihv等。

当然，OSS社区的“MSDN”是一个松散的联盟，网站的API文档质量不一。微软有机会做到这一点真的利用web来推广开发人员。

削弱OSS攻击

一般来说，微软通过攻击OSS项目的核心弱点而获胜。

去商品化协议和应用

OSS项目已经能够在许多服务器应用程序中获得立足点，因为高度商品化的简单协议的广泛实用。

通过扩展这些协议和开发新的协议，我们可以阻止OSS项目进入市场。

David Stutz做了一个非常说得好:在与微软的桌面集成水平竞争时，实际上是商品协议成为整合的手段用于OSS项目。在各种IETF工作组中有大量的IQ被消耗，他们正在快速地为这些OSS项目创建集成的体系结构模型。

微软扩展商品协议的一些举措包括:

• DNS与目录集成．利用目录服务通过动态更新、安全性、身份验证为DNS增加价值
• HTTP-DAV．

  DAV很复杂，协议规范为各种应用程序提供了无限级别的实现复杂性(例如，Exchange优于DAV的设计很好，但肯定不行的单一明显的设计)。Apache将很难选择DAV的正确的第一个实现领域。

• 结构化存储．

  改变文件服务空间(一个关键的Linux/Apache应用程序)中的游戏规则。创建一个引人注目的客户端优势，也可以扩展到服务器。

• MSMQ用于分布式应用程序．MSMQ是分布式技术的一个很好的例子，其中大部分价值都在服务和实现中，而不是在有线协议中。

  MTS、DTC和COM+也是如此。

使集成引人注目——尤其是在服务器上

专业服务器的崛起是一个特别强大和可怕的长期威胁，直接影响我们的收入流。对抗这种威胁的关键之一是在服务器平台上创建有价值的集成场景。David Stutz指出:

这里的底线是，谁拥有最好的面向网络的集成技术和流程，谁就将赢得商品服务器业务．

嵌入式系统、移动连接和普及网络协议的融合将使服务器(尤其是“专业服务器”??)的数量激增。通用商品客户端是一项很好的业务——与专用商品服务器业务相比，它会相形见绌吗?

• 系统管理．系统管理功能可能涉及产品/平台的所有方面。

  因此，它不容易以组件化的方式移植到现有的代码库上。它必须从一开始就设计好，或者是对给定项目中所有组件有意识地重新评估的结果。

• 易用性．与管理一样，这通常必须从头开始设计，从而导致大量的开发管理成本。

  OSS项目将始终存在与此特性区域匹配的问题

• 解决方案．ZAW，拨号网络，向导等。
• 客户端集成．我们如何利用客户基础在我们的服务器上提供类似的集成需求?

  例如，MSMQ作为一个中间件，需要密切同步的客户端和服务器代码库。

• 中间件控制非常重要．显然，由于服务器及其协议面临商品化的风险，为了保持服务器操作系统业务的利润率，更高级的功能是必要的。

组织的可信度

• 发布/服务包流程。通过整合和管理与最新补丁同步的艰巨任务，微软提供了一个相对于基本OSS流程的关键客户优势。
• 长期的承诺。通过诸如企业协议、长期研究、执行主题演讲等工具，微软能够致力于长期愿景，并创建比OSS过程更大的长期秩序感。

其他有趣的连结

• http://www.lwn.net/ -总结了Linux开发世界的每周事件。
• Slashdot,http://slashdot.org/- OSS社区的每日新闻/讨论
• http://www.linux.org
• http://www.opensource.org
• http://news.freshmeat.net/ -关于最新开放源码版本和项目更新的信息

致谢

许多人提供了数据点、校对、深思熟虑的电子邮件以及对这篇论文和Linux分析的分析:

Nat布朗
吉姆他
查理Kindel
本Slivka
Josh Cohen
乔治Spix
大卫曾
斯蒂芬妮·弗格森
杰基·埃里克森
迈克尔·纳尔逊
德怀特Krossa
大卫·D’索萨
大卫Treadwell
大卫·冈特
Oshoma Momoh
亚历克斯Hopman
杰弗里·罗伯逊
Sankar Koundinya
亚历克斯·萨顿
伯纳德Aboba