`
guohui_fz
  • 浏览: 56230 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

The Magic Cauldron(魔法大锅炉)

阅读更多

The Magic Cauldron(魔法大锅炉)

作者:Eric Raymond
译者:[AKA]rover HansB iasc等


1. 近乎魔法


   在威尔士的神话中,Ceridwen女神有一口巨大的锅,当女神念动只有她自己知道的咒语时,那口锅就变出奇妙的食物。在现代科学中, Buckminster Fuller 提出了一种“短暂化”的概念,认为在早期的物理资源投资越来越多的被信息内容所代替的情况下,技术会变得越来越有效和廉价。Arthur C. Clarke指出“任何足够高级的技术都与魔法别无二致”,从而把二者联系起来。对很多人来说,开放源代码社区的成功看来就象难以置信的魔法。高质量的软 件变得免费,在充满竞争而且资源稀缺的现实世界,这似乎不能继续下去,但是它进行的还不错。要点在哪?Ceridwen的大锅只是一个小诡计吗?如果不 是,在这种情况下,“短暂化”是怎么工作的——女神究竟念动了什么咒语?

2. 超越高手的才能


   开放源代码文化的经验肯定使许多学习过软件开发的人们感到困惑。“大教堂和市集”一文描述了分散协作软件开发是怎样有效的推翻了Brooks的定律,产 生了使一个独立的工程具有空前可靠性和质量的开发方式。“开拓智域”一文揭示了市集模式开发风格中的社会动力学,这应该用人类学家所谓的“赠与文化”的术 语而不是常规的交换经济术语来理解,在这种文化中,成员在做出贡献大小方面竞争。本文中我们将开始推翻一些流行的关于软件生产经济学的神话;然后对“大教 堂和市集”和“开拓智域”两篇文章进行经济学、搏弈论和商业模型领域的分析,发展一种新的概念工具,来理解开放源代码开发者的赠与文化在交换经济里也可以 继续下去的理由。


  先不岔开话题,沿着上面的线索分析,我们需要抛弃(至少要暂时忽略)在"赠于文化"层次上的分析。“开拓智 域”中赠于文化的存在是基于生存所需要的物质资料极大的丰富,以至于社会交换已经不很重要的环境里;这种分析虽然在纯粹的精神世界中非常有说服力,但针对 现实生活中大多数开放源码开发者实际所处的综合经济环境来说,这种解释则显得有些无力。对许多人来说,社会交换仍然是他们努力工作的驱动力,但是已经渐渐 失去了吸引力。必须在资源匮乏的经济学中为他们的行为找到足够的理由,才能使这些行为在物质资料丰富的赠于文化中得以立足。


   因此,我们现在将(从整个资源匮乏经济学领域)思考维持开放源码开发的协作和交换模式。在分析的过程中,通过深入剖析和列举实例,我们同时也就回答了那个 非常实际的问题:“我如何通过开放源码来赚钱?”。不过,这个问题是根据与软件开发本质相悖的普遍软件开发经济模型而提出的,首先我们需要展示一下隐藏在 这个问题之后的许多思维误区。


  (在展开分析之前还有最后一个需要说明的是:本文中对开放源码开发模式的讨论和提倡,不能被理 解为对封闭源码模式的彻底否定,也没有反对现有的软件知识产权体系,更不是对"共享"的无私呼吁。虽然开发源码开发团体中的一些人仍然热衷于这些讨论,但 从“大教堂和市集”发表以来,经验已经清楚的表明这些争论没有必要的。重要的是开放源码的开发模式和经济效益能够制造出质量更好、可靠性更高、成本更低、 可以选择的方案更多的好产品来。)

3.制造业的错觉


  我们需要注意的是计算机程序和其他类型的工具和资本货物一样,都有两种经济价值:使用价值和销售价值.


  程序的使用价值就是它作为工具的经济价值;销售价值是它作为作为商品的价值.(用经济学的专业说法,销售价值是产品最终价值,使用价值是产品中间价值)


  当大多数人说到软件产业时,总是按照拥有下列特性的"工厂模式"经济来分析:


  1.大多数开发者的劳动由销售价值的收入来支付


  2.软件的销售价值与开发成本(例如,功能复制所需的资源花费)和使用价值成一定比例.


  换句话说,人们有很强的思维惯性去假定软件具有标准工业品的特性。但是这两个假设都错了。


   首先,编写用于出售的代码只是编程行业的冰山一角.在微机世界前期,大家普遍认为世界上90%的代码在银行和保险公司内部编写.这虽然已经不再是事实 --现在其他行业也越来越加大了软件开发的力度,金融行业所占的比例从而下降--但是短期内我们仍将会看到大约95%的代码是公司内部编写.


  这些代码包括大多数为中等或大规模公司所定制的MIS,金融和数据库软件.包括象设备驱动这样的专业技术代码(几乎没有人靠卖设备驱动赚钱,这一点我们将会在后面讨论);包括日益增长的数控机器的各种嵌入式代码--从机械工具和喷气客机、汽车、微波炉甚至烤面包炉.


  大多数这种内部代码与其环境集成在一起,复制和再利用十分困难(不论环境是商业办公室的程序套件还是联合收割机的加油系统)。因而一旦环境变化,需要做许多工作使软件与之同步.


   这种工作称为"维护".任何软件工程师或系统分析员都会告诉你这就是程序员的大部分工资的来源(超过75%).因此,大多数程序员工时花费在编写和维护 更本不能卖的内部代码上(当然大多数程序员以此为生)--读者们也许乐意去查查报纸上的"诚聘信息"部分的编程工作列表检验一下.


  我强烈的希望读者试试浏览本地报纸的招聘信息,看看编程.数据处理,和包含软件开发工作的软件工程项目等等.将这些工作按照其目的是使用还是销售进行分类,你将深受启发.


   很明显,即使为"销售"定义了最大范围,20人中还是至少有19个由使用价值资助(作为产品中间价值).这就是为什么我们认为软件工业中以销售价值驱动 的部分只占5%原因.注意,本文中其他部分的分析并非完全倚赖于这个数;即使这个数字达到15%甚至20%,在经济上的推论结果仍然八九不离十.


  (当我在技术讨论会上演讲时,我经常由讨论两个问题开始:听众为写软件付多少钱,和有多少薪水是依赖于软件的销售价值的.第一个问题应者甚众,而第二个问题则寥寥无几,大而且量的听众对这个问题十分诧异)


   其次,经过对实际客户行为的调查,软件销售价值与其开发和升级成本相关的理论很容易被推翻.开发和升级成本相关的商品(对打折之前来说)占很大比例- -食品,汽车,机械工具,甚至有许多无形的产品--例如,音乐、地图或数据库资料的复制权.这产品在生产者倒闭后仍然能保持甚至增加其销售价值.


  与上述形成鲜明对比的是.当一个软件产品生产者歇业时(或者如果产品开发被终止),几乎没有客户愿意为其花钱,而不管它理论上的使用价值或同样功能产品的开发费用有多高.(要检验这个说法,去你附近的软件商店打折柜台看看吧:-))


  在生产者失败时,零售商的行为很有启示.他们知道一些生产者不知道的东东.他们深知:客户愿意花费的价格在很大程度上由卖主未来可以提供的服务决定.(这里的'服务'被广义的理解为完善,升级和后续产品).


  换句话说,软件主要是一个稳定的服务性行业,认为它是制造性行业是没有理由的错觉.


   另外,检查一下我们为什么会有这些惯性思维也很有益处.它们也许来自于软件生产者大力宣传的销售类产品,这些是的软件业一小部分,也是宣传的唯一的一部 分,大多数明显和重头的广告宣传的产品是昙花一现的短期产品,就像游戏,他们几乎不需要提供后续服务(合同规定的除外)


  另外,值得注意的是,制造业错觉所倡导的价格体系事实上会越过保持开发预算不崩溃的底线.既然(像一般认为地)超过典型软件产品周期花费的75%在维护,调试和扩展上,那么通常的那种只采用高额售价,极低相关服务费用的定价策略,只会导致各方面都差的服务.


  用户的损失在于,即使软件是服务性行业,工厂模式促使生产者减低服务质量.如果生产者靠出卖比特挣钱,大量的努力是制造比特并将它们推销出门;帮助服务部分,因为不是利润的中心,将会成为只付出的一点点努力和资源,为了避免激怒用户所设的垃圾站.


   另一方面是大多数生产者使用这种工厂模式会导致长远的失败. 为满足无限的售后服务和技术支持需要的固定价格产品提供资金,只有在那些膨胀足够迅速的市场里 --其过去的销售和未来的收入能够满足支持和生存周期的花费--才能存活.一旦市场成熟和销量下降,维持生计,大多数生产者除了消减单独产品的开支之外没 有别的选择.


  不管是直接(废止产品)还是间接(支持很差),都会把客户推给竞争对手(因为这些行为损害了依附于服务产品的期 望值).短期来看,可以通过将修订过 bug的版本发布为新产品避免这个陷阱.而长远来看,避免陷阱的唯一可能是对行业进行有效的市场垄断.最终,只有唯一的幸存.


   事实上,我们一再的看到这种缺乏支持的模式害死一些市场环境中很强大的竞争者,(这种模式对那些那些经历过计算机发展史幸存下来的人尤其深刻,包括个人 操作系统,字处理,通用财务程序或商业软件).这种不正确的动机来自于工厂模式导致的赢家通吃的态势,而且最后即使你是赢家的客户也会遭殃.


   如果不是工厂模式,那又是什么?为了有效的控制软件生存周期真实的花费体系(同时在经济学和非正式场合的意义上的"有效"),我们需要一个建立于服务合 同,合约,和买卖双方持续交易基础上的价格体系.所以,在以效益为目的的自由市场条件下,我们能管窥大多数成熟的软件工业最终遵循的价格体系.


  为什么说开放源码软件的地位日益增长,不仅仅是技术,也是经济上对主流秩序的挑战?上述内容给我们一些启示.软件开发的"free",会将我们推向以服务支配的世界,同时暴露出一直依赖销售封闭源码产品的方式有多脆弱.


   "free"的概念很容易被误解为其他含义。降低产品花费会导致支撑软件业的整个基础投入增长,而不是降低。只有汽车的价格降低时,汽车的需求才会上升 --这也是为什么在开放源码世界中,另外那5%的根据销售价值付酬的程序员不好受的原因.在free的变革中,有损失的不是程序员而是那些没看清形势而将 赌注押在封闭源码策略上的投资者。

4. "信息应该免费"的神话


  与工厂模式错觉相呼应的是,思考开放源码经济的人们还常常被另外一个神话搞糊涂.那就是"信息应该免费".这常常以数字信息产品的复制边际成本几乎为零来解释,这个解释暗示了其价格似乎就应该为零.


  其实你只要考虑一下诸如藏宝图,瑞士银行的账号口令,或计算机服务的确认口令,等等信息的价值,就很容易看破这个神话.即使这些确认信息可以不用任何花费的复制,但是被其确认的对象无法复制.也就是说,非零的边缘成本由被那些确认信息继承下来.


  提到这个神话的主要目的是声明它与开放源码的经济价值的讨论无关;就象我们在后面将会看到的,即使假设软件是符合制造业产品(非零)价值结构,仍是如此.所以我们没必要钻软件是否应该免费的牛角尖.

5.驳斥公用悲剧说


  质疑主流模式,看看我们是否能建立另一种模式----对是支撑起开放源码协作的原 因作出有力的经济学解释.


  这个问题需要从两个不同的方面考查.一个方面是我们要解释那些为开放源码作出 贡献的人士的个体行为;另一方面,我们需要理解那种支撑象Linux和Apache这样的 开放源码项目的经济力量.


   Hardin的著名寓言告诉我们:设想一个乡村农夫们拥有一片公用绿地.他们在那里放牧牲畜.但是放牧使公用性退化,撕裂草皮,留下泥泞,很难恢复. 如果没有对分配放牧的权利达成协议(或约定)以防止过度放牧;所有牧主都还会赞成尽可能快的增加牲畜数量,以便在公共绿地变成泥潭之前榨取最大的利润.


  大多数人使用象这样的直觉的合作模式.这事实上并不是对开放源码--他们是(供不应求的)自由骑士,而不是(被过度使用的)过剩的公共货物--经济问题的正确判断,不过,我在大多数未充分考虑的反对声后面都听到过类似的看法.


  公共拥有的悲剧预言只会出现三种结果.一种是泥潭;一种是为了村民的利益,强制性的使用某种分配协定(共产主义的解决方案);第三种是公用被打破,村民各筑藩篱,保护自己的一小块草地(私有制的解决方案).


  当人们本能的的将这种模式应用于开放源码合作时,因此预计它只有很不稳定的短暂的半衰期.因为没有明显的方法去强制在互联网上工作的程序员执行工作时间分配策略,这种模式就断言公用将会打破,结果是出现各种各样的封闭代码软件和反馈给公用的工作量迅速减少.


  事实上,经验清楚的显示出了与之相反的趋势.开放源码开发的广度和深度(由Matalab和freshmeat.net的每日宣布的数据统计)在稳定增加.很明显,这些都得出"公用悲剧"模式无法描述事态的发展.


  答案的一部分正是建立在软件使用并不降低其价值的事实基础之上.实际上,对开放源码软件来说,当用户被其修正和特性(代码补丁)把握之后,软件的广泛使用还会增加其价值.公用悲剧被颠覆了,越放牧,草长得越高.


  答案的另一部分是基于很难收取那些为公用源码基础所作的小补丁的市场价值.假设我为一个恼人的bug写了个修正,而且有人认为这个修正值钱;我如何才能从那些人手里拿到钱?对于这种小额的,通常也是适当的付款,常规的付费体系如此昂贵竟成为真正的问题.


   比起价钱不仅仅很难收取,也许如何定价还要难得多.让我们想一想,假设互联网上已经拥有理论上完美的小额付费系统--即安全,方便,又不需要更多手续 费.而你写了个补丁叫做"Linux内核的某某修正".你该要价多少?在潜在购买者还没看到补丁时,他们又该如何判断值不值得为它付费呢?


  我们的问题就像F.A.Hayek的"计算问题"在哈哈镜中的变形--它就象个超市,即要估价补丁的功能值多少,又要相信定价是合理的以促进交易.


   不幸的是,超市方式有一系列的不足,所以补丁的作者----打补丁的黑客有两种选择:躺在补丁上收钱,或免费扔出去.第一种选择将一无所获.第二种也可 能如此,不过或者它会促使其他人提供互惠的给予,以解决上面那位黑客所头疼的问题.第二种明显无私的选择,在这种游戏情况中,竞然事实上是自私的.


   在分析这种合作时,自由软件的开发所面临的问题会很重要(他们可能会工作在清贫,或没有足够的回报的情况下),这并不是由最终用户的数量决定的.开放源 码项目的复杂性和沟通所带来的成本几乎完全和参与的开发者的数量成函数关系;拥有更多的几乎从不看源码的最终用户对此似乎没有任何益处.这只会增加在项目 邮件列表中无聊问题出现频率,但是建立一个相关的常用问题列表,不理睬那些显然不读FAQ的人(事实上这已经是通用做法),可以很容易解决这个问题.


   开放源码软件的真正最重要的自由软件开发问题是提交补丁功能时的磨合成本.可能的贡献者在声望上小有收获(见《开拓智域》一文),而没有金钱上的补偿, 想着"根本不值得提交这个修订,因为我不得不打补丁,写修改记录,在FSF任务文件上署名...".因为这个原因,拥有大量贡献者(其次才是成功)的项目 很强壮.与之相反的是,每个有许多相互有制约关系的项目都需要有从始到终的贡献者.这种磨合成本就像政治一样呆板.总之,自由软件项目本身可以向你解释为 何松散,无组织的Linux 文化,比紧密组织且集中管理的BSD项目的努力,更能吸引合作能量的意向;以及为何自由软件基金会,也在Linux崛起时重要性相对的减弱.


  这条路不管走多远都是好的.但是,这只是在黑客写了补丁并公布了这个补丁后的事后诸葛亮式解释.我们需要的另一半答案是对为何JRH最初会写这个补丁,而不是为拥有销售回报的封闭源码程序工作.作出经济解释.到底什么商业模式创造了开放源码开发繁荣发展的环境呢?

6. 封闭源码的原因


  在给开放源码经营模式分类之前, 我们应该先大致地考虑一下封闭的代价.当我们封闭源码时,我们究竟在保护什么?


  比方说你雇了某人来编写和组织一个(不妨说)为你的生意专用的结算软件,那么和开放源码比起来,封闭源码一点也不会有助于解决问题. 如果你想封闭源码, 唯一合理的理由就是你想把这个软件卖给别人, 或者不让你的竞争者使用它.


  比较明显的原因是你在保护销售价值, 但是对95%的供内部使用的软件来说这没意义.那么封闭还有别的什么好处吗?


  第二个原因(保持竞争优势)还有待检验. 假如说你把那个结算软件开放源码了,它流行起来, 并且从社会上得到了改进. 现在, 你的竞争者也开始使用它了,他没有花开发费用就得到了好处, 而且影响了你的生意. 这是不是一种反对开放源码的理由呢?


   可能是--也可能不是. 真正的问题在于你从分散开发负担中得到的好处是否多于由那些不劳而获的人带来的竞争损失. 许多人倾向于为这类交易作苍白的辩解,方法是: (a)避而不谈从额外的开发帮助中得到的功能上的改进. (b) 不认为开发费用是降低了, 而是假定你无论如何也是要承担这些开发费用的, 所以把它们作为开放源码(如果你这么选择的话)的代价是错误的.


  还有别的许 多封闭源码的根本就是荒谬的理由. 举例说, 你可能误以为封闭源码可以使你的商用系统更加安全, 不容易被破解或闯入. 如果是这样, 我建议你立刻找一个密码专家来诊断一下你的系统. 真正的猜疑心很重的人都知道不能相信封闭源码程序的安全性, 因为这是他们是从惨痛的教训中学到的.安全性是可靠性的一个方面; 只有那些被彻底检查过的算法和代码实现才可能被相信是安全的.

7.使用价值集资模型


  使用价值与销售价值之间的差别让我们注意到的一个基本事实是只有销售价值本身受到了来自从封闭原码到开放原码这个转变的威胁;使用价值并没有。


  如果使用价值,而不是交换价值,的确是软件发展的根本驱动力;而且开放原代码的发展的确是比原代码封闭要更加有影响力和更加有效率,那么我们应该期待着去寻找一种环境,在这种环境中光是使用价值已能够完全地促使 开放原代码向前发展。


  实际上,这样的几个环境模型并不难以找到。在这样的模型中,开放原代码的全职开发者的生存完全可以由(开放原代码的)使用价值来实现。


  7.1 Aapache的个案:(价值分享)


  假如你在为一个拥有高效性高可靠性网络服务器的商业公司服务。也许这个服务器是用来为电子商务服务的,也许是作为一个出售广告的高可视性的媒体输出装置,也许只是用来构建一个门户站点。你需要一天7小时的在线时间,你需要速度,还有规范性。


  那么你该如何做呢?这里有些基本的策略可以供你参考:


   购买一个私有的网络服务器,这样,你是在冒险相信卖方的宣传与你的需求是一致的,你在冒险相信卖方的技术竞争力能给提供完善的保障。即使假设这两个方面 是有保障的,网络服务器本身也会由于缺乏规范的服务而出现问题。你只能通过卖方的经过挑选提供的几种工具来维护的你的服务器。这种购买私有的服务器的路子 并非一个很大众化的方法!


  自己做一个!做一个自己的网络服务器在目前还是不可忽略的一种调剂办法;网络服务器并不太复杂,当 然比浏览器要简单。一个专门用途的网络服务器可以做得功能专一但很好用。走这条路的话,你能得到你所需要的各种特性和自己的规范,尽管在其升级的过程中你 要付出很多。或许你的公司在你离开或退休后,还会发现这个服务器有了这样或那样的问题。


  参加Apache小组!Apache 服务器是有一个通过Internet交流的小组写出来的--小组成员都是系统管理员,他们相信比较明智的做法是将他们的能力集合起来去写,并提高一个单一 方向的代码集而不是去花费时间各自同时写完全不相关的代码。这样做的结果是他们能够同时发挥“自己做一个”和大范围大规模测试代码的优势。


  选择Apache小组的优势很明显。到底有多明显,可以根据Netcraft 的每周回顾来判断一下。Netcraft上说Apache服务器从其诞生起一直在稳定地夺取其他私有服务器的市场份额。1999年6月,Apache 的各种版本占有了61%的市场份额;--没有合法的拥有者,没有组织机构,也根本没有合同制约的组织形式在背后操纵。


  总的说起来,Apache的故事提供了一个模式:软件使用者通过支持开放原代码计划而发现了这个模式,他们发现这样做能以最小的代价给他们带来越来越好的软件,比其他任何方法都要有效。


  7.2 Cisco的各案:风险均摊


   一些年以前,两个Cisco(网络产品制造厂家)的程序员被分配来写一个分布式的打印系统的程式代码用做Cisco的合作网络的应用。这个项目的挑战性 很大。这个系统要使任意一个用户能在这个网络上的任意一台打印机上打印东西(而用户和打印机可能只是隔壁或者相隔几千公里),当打印机没有纸了或其他紧急 情况系统要能够将任务导向另一台附近的打印机。系统还要能够将这一个突发时间报告给打印机管理员。


  他们两个对Unix上的打印软件做了一些很不错的修改,加上一些包的原语言,就做成了那项工作,但接着问题就来了。


   问题是两个程序员都不愿意在Cisco永远呆下去。结果两名程序员都将离开,而软件也会无人维护而“腐烂”(就是无法满足实际应用中不断变化的要求而失 去其应用)。没有任何一个人愿意看到这样的情况在他自己或工作上发生,那两个程序员也认为他们已经做了Cisco公司要求他们做的事情,其他的问题已经不 是他们的工作范围了。


  于是他们跑到他们的经理那里要求将这个打印软件的原代码开放。他们认为这样的话Cisco不仅不会失去什么反而会得到更多。通过协作鼓励用户和软件开发合作者的组织的发展,Cisco能够弥补因为软件原创人员的离开所带来的损失。


   Cisco的故事引出另一个模式:原代码开放使开发一个软件的风险被众多协作者分摊了而且投资分花费很小。所有的团体都发现原代码的开放,以及一个成员 各自独立却互相协作的社区的存在将提供一个无风险的开发环境,而且这个环境是有商业价值的----它能够自己赚钱养活自己!

8.为何销售价值存在问题


  开放源码使得直接获取软件销售利润非常困难。困难并不是来自技术方面的,因为源代码和可执行代码一样易于拷贝,并且版权法和许可证法的约束不同使得通过开放源码软件来获取销售利润比封闭源码软件难。


   真正的困难来自维护开放源码发展的许可证本身。因为三个相互推动的原因,大多数的开放源码许可证禁止对用户使用、分发、修改软件的权利进行限制,以此避 免有人利用开放源码软件牟取直接利润。为了更好的理解这些原因,我们有必要对这些许可证所涉及的社会背景——黑客文化(可以访问下面网址:http: //www.tuxedo.org/~esr/faqs/ hacker-howto.html>做一番探讨。


  原因与 对市场的敌视无关,虽然这样的误解在黑客圈外至今广为流传。不排除有小部分的黑客确实一直对商业动机抱有敌意,但大部分的黑客还是愿意与一些以盈利为目的 Linux集成商(如RED HAT、SUSE、Caldera)合作的。这也表明只要符合他们的意愿,大多数的黑客会乐意和商家合作的。如此看来,黑客们敌视以获取直接利润为目的的 许可证的真正原因非常微妙也非常有趣。


  原因之一,对等原则。大多数开放源码的开发者允许别人利用他们的成果来获取利益,还有 许多开放源码的开发者同时还规定不允许某一方(有时源码的开发者除外)出于特权地位来牟取利润。只要黑客们自己潜意识里打算从他们开发的软件或补丁中赢 利,他们一般也愿意别人来与他合作,共同赢利。


  原因之二,意想不到的后果。黑客们发现在许可证中对软件的商业应用与销售进行 限制和收费(为获得销售利润而通常采用的做法)会使得人际关系变得淡漠。其中一个特例就是所谓的“盗版光盘”,这本来应该鼓励的,但现在却被认为是违法和 不道德的。总的来说,对用户使用、销售、修改、分发软件的权力(以及版权协议中其他复杂权利)进行限制会导致人们循规蹈矩,时时刻刻担心自己会犯法(这种 担心会随着人们使用的软件包的增加而愈演愈烈)。这无疑是非常不妙的,因此简化许可证,解除许可证中的各项限制已成为大势所趋。


   原因之三,也是最关键的一个原因,就是代码共享。这种赠与文化在《开拓智域》一文中有生动的描述。某些许可证体系中用来保护知识产权或者限制直接获取销 售利润的各项规定使得人们不能合法的实现代码共享,(如Sun公司的Jini&Java "社区资源"许可证)。然而代码共享却被认为是最后一根救命“稻草”(《开拓智域》一文中大段大段的解释了这个问题),当软件维护者无力承担或者放弃对代 码的维护时(比方说是一个非常封闭的许可证),代码共享就非常关键了。


  黑客群体对于对等原则还是有所妥协的,所以他们能够容 忍一些象Netscape的NPL(NPL明确规定不允许非公开源码的产品使用开放源码的 Mozilla代码)一样给予源码创作者一些特权的许可证。对于第二条原因,妥协的就少一些。而对第三条原因极少会作出让步(这也是Sun公司的JAVA and Jini Community License计划遭到黑客们广泛反对的原因)。


  上述原因解释了开放源码定义中的各项条款。这些条款从一些典型的自由软件版权协议(如GPL协议,BSD协议,MIT协议以及Artistic协议)的细微特征中表达了黑客群体的思想,它们(虽然不是有意的,但客观上)使得获取直接利润极为困难。

9. 间接销售价值模式


  然而,还是有办法来开拓与软件服务相关的市场,从而获得间接销售价值。有五种已知的和两种正在探索的模式(未来可能会发展出更多的新发展模式)。


  9.1 失败的领导者/市场定位者


  在这种模式中,利用开放源代码软件为直接产生收入的专有软件来创造或维持一种市场位置。在大多数普遍的情形中,开放源代码的客户端软件带动了服务器软件的销售,或者可增加了门户网站的访问量/广告收入。


   网景公司(Netscape)在1998年开放了Mozilla浏览器的源代码时,就是使用了这种策略。他们浏览器端的商业收入只占总收入的13%,而 且在Microsoft开始发布Internet Explorer后市场份额还在下降。IE强大的市场营销(及其捆绑策略后来成为反托拉斯案的核心问题)迅速的吞噬了Netscape浏览器的市场份额, 造成了Microsoft试图垄断浏览器市场,并利用微软强加给用户的HTML的“标准”,形成逐步把Netscape 赶出服务器市场的态势。


  通过开放仍然流行的Netscape浏览器的源代码,Netscape有效的阻止了Microsoft垄断浏览器的可能性。他们期望开放源代码协作会加速浏览器的开发和测试,并希望能降低Microsoft的IE的发展速度,阻止它独自定义HTML标准。


   这个策略生效了。在1998年11月,Netscape实际上开始从IE那里夺回市场份额。在1999年初Netscape被AOL收购时,保持 Mozilla所取得的竞争优势是很明显的,这一点可以从AOL的行动中显而易见,AOL首先对外的承诺的就是继续支持Mozilla计划,虽然她还处在 alpha测试阶段。


  9.2. 糖霜策略


  这种模式是针对硬件制造商的(这里的硬件包括从以太网或其他外部设备直到计算机系统的所有东西)。市场压力迫使硬件公司书写和维护软件(从设备驱动程序、配置工具直到整个操作系统的级别),但是软件本身并不是利润中心。它是一项开支——通常是一项重要开支。


   在这种情况下,开放源代码是一种很好的策略。由于没有赢利上的损失,所以没有负面影响。销售商获得的是奇迹般膨胀的开发人员队伍,对用户需求获得更加快 速、灵活的反应能力,并且通过同行检查而获得的更好的可靠性。而且可以免费得到了其他系统的移植。这种做法还可在很大程度上提高客户对公司的信任度,因为 客户的技术人员可以花费了更多的时间根据自己的需要定制代码。


  有一些经常被销售商提出的反对开放硬件驱动程序源代码的理由。为了不把它们和这里的更加一般的问题搅在一起,我在附录里专门讨论了这个问题。


  开放源代码的“将来获益”的效果在糖霜策略中体现的尤其强烈。硬件产品有一个有限的制造和支持的生命周期,在那以后,用户就自己照顾自己了。但如果他们可以获得驱动程序的源代码,并可根据需要加以修改的话,他们就更可能高高兴兴的成为同一公司的回头客。


  糖霜模式的一个非常戏剧性的例子是苹果公司在1999年三月中旬决定开放它们的MacOSX服务器的操作系统“Darwin”的代码。


  9.3 奉送食谱,开办饭店


  在这种模式中,开放源代码软件建立了一种市场定位,并不是为了象在失败的领导者/市场定位者模式中一样针对封闭源代码软件,而是针对服务。


  (我曾经把这种模式称为“奉送剃刀,销售刀片”,但是软件和服务二者的关联并不如剃刀/刀片所类比的那么紧密。)


  这是红帽和其他Linux发行商所采用的模式。他们卖的其实并不是软件代码本身,而是通过组合和测试一个能转的操作系统产生的附加价值,这个操作系统被担保有销路并与同一品牌的操作系统兼容。构成他们的价值的其他元素包括免费安装和提供可选的持续技术支持合同。


   开放源代码的创造市场的能力极为强大,尤其是对那些天生就作服务的公司来说更是如此。进来一个非常有教育意义的例子是Digital Creations公司,它是一个创建于1998年的web站点设计机构,专长于复杂的数据库和事务站点的开发。他们的主要工具,公司的知识财产——皇冠 上的明珠,是一个对象发布系统,它曾经有过几个名字,现在被称为Zope。


  当Digital Creations的人寻找风险投资时,风险投资商仔细的估计了他们的预期市场份额,他们的人力资源和那套工具后,就建议Digital Creations开放Zope的源代码。


   从传统的软件工业标准来看,这看起来绝对是一个疯狂的举动。常规的商业学校认为象Zope这种核心知识财富是一个公司的掌上明珠,是在任何情况下也不能 放弃的。但是那位风险投资商从两个相互关联的角度来考虑问题,一个是Zope的真实核心资产实际上是它的人员的大脑和技术;第二个是Zope作为一个创造 新市场的标准而不仅仅是一个秘密武器会产生更多的价值。


  为了看清这一点,请比较两种情况。在通常情况下,Zope保留为 Digital Creations的秘密武器。让我们假定它是一个很有效的武器。结果,公司可以在很短的时间内交付高质量的软件——但是没人知道这个秘密武器。满足客户 是容易的,但是建造一个客户群体是困难的。


  然而那个风险投资商看到了对Zope系统开放源码可以为Digital Creations的真正财富——它的技术员工产生巨大的广告效应。他期望使用Zope的客户会认为雇用象Digital Creations这样的专家会比自己开发自己的Zope技术更加高效。


  Zope的一个负责人曾经非常公开的确认了他们的开放源代码策略“开启了许多其它方式无法开启的门”。潜在的客户确实反应了这种情况——所以Digital Creations公司迅速发展起来。


  另一个很近的例子是e-smith公司。这个公司出售定制的开放源代码的Linux的 Internet安全服务器。他们的一个负责人描述了e-smith迅速扩展的免费下载服务,他说“大多数公司都要考虑软件盗版问题,而我们把它看作一个自由市场。”


  9.4 附加产品


  在这种模式中,我们出售开放源代码的附加产品。在低端市场,出 售杯子和T恤衫;在高端市场上,出售专门编辑并出版的文档和书籍。


  O'Reilly集团是一个附加产品公司的很好的例子,他出版了很多优秀的开放源代码软件的参考资料。O'Reilly实际上雇用和支持了一些著名的开放源代码黑客(例如Larry Wall和Brain Behlendorf),并以次提高它在市场上的声望。


  9.5 未来免费,出售现在


  在这种模式下,我们以封闭的许可证发布软件的可执行文件和源代码,但是包含一个有关封闭条款的期限。比如,我们可以写一个许可证,允许免费的散发软件,禁止不付报酬的商业应用,并保证发布一年以后或开发商终止开发后软件将在GPL保护之下。


  在这种模式下,客户可以保证产品能够根据他们的需要定制,因为他们可以得到源代码。产品的将来也是得到保证的——许可证保证了如果始创公司失败后,开放源代码社区仍能够接管该产品。


  因为销售价格和数量是依赖于客户对产品的期望值,始创公司可以享受到比以封闭源代码许可证发行的软件更优厚的收入。而且,因为老的代码是在GPL保护下的,所以它可以得到同行认真的检查、排错和添加其他小功能,这样可以为原创者减轻75%的维护负担。


  这种模式被Aladdin公司成功的采用了,它创造了流行的Ghostscript程序(一个PostScript解释器,它可以把PostScript翻译成许多打印机的内部语言)。


  这种模式的主要缺点是那些封闭的条款倾向于抑制产品开发早期的同行检查和参与,而那时是最需要的大家的参与的时候。


  9.6 软件免费,销售品牌


  这还是一个试探性的商业模式。我们开放一项软件技术,保留测试包或一套兼容性标准,然后卖给用户一个品牌认证,保证他们对这种技术的实现和其他具有这种品牌的产品相互兼容。


  (这是Sun公司应该对待Java和Jini的方式。)


  9.7 软件免费,销售内容


  这时另一种试探性的商业模式。想象一些象股票信息订阅的服务。价值既不在客户端软件也不再服务器商,而在于提供客观的的可靠的信息。因此我们开放所有的软件,出售内容订阅。当黑客们把客户端移植到新的平台上或者以不同方式扩展它时,我们的市场自动扩展了。


  (这是为什么AOL应该开放它的客户端软件。)

10. 何时开放,何时封闭


  在考察了支持开放源代码软件开发的几种商业模型之后,我们可以来讨论一下何时开放源代码、何时封闭源代码才有经济意义这样的一般性问题了。首先,我们必须弄清楚每种策略如何盈利。


10.1 靠什么盈利?


  封闭源代码的方式让你可以从秘密的比特中收取利润;另一方面,它阻止了其他同行对代码进行检验的可能性。开放源代码方式为其他同行检验创造了条件,而且你也不能从秘密的比特中获得利润。


   从秘密的比特中盈利很好理解;传统的软件商业模型就是围绕着它建立的。但是直到近来,其他同行检验代码的价值还未被很好的理解。然而,Linux操作系 统使得我们对问题的认识更加清晰,这些认识我们本应在几年前从Internet核心软件和其他软件工程分支的发展历史中就应该学到——开放源代码的同行检 验是得到高可靠性和高质量的软件的唯一可伸缩的方法。


  因此,在一个竞争的市场上,寻找高可靠性和高质量软件的客户会给那些开 放源代码软件开发人员以回报,是他们探索出怎样在服务、附加值和与软件相关的辅助市场中维持一个稳定的收支循环。这种现象正是Linux令人惊讶的成功背 后的原因,Linux在1996年的一片空白发展到1998年末的商业服务器市场的17%,而且似乎会在两年之内占领这个市场(1999年初,IDC 预测Linux将在2003年成长的比所有其它操作系统的总和还要快)。


  开放源代码的一个几乎同样重要的作用是作为一种传播开放标准,围绕它建立市场的手段作用。Internet的戏剧性增长得益于没人拥有TCP/IP;没人有权封锁Internet的核心协议。


   TCP/IP和Linux成功的所造就的互连网络对世界的影响是显而易见的,开放的系统最终减少了信任和平等的问题——如果大家都能够看到底层结构是怎 样工作的话,他们就会理所当然的更加信任它;人们更加喜欢一个所有人都是平等的底层结构,而不是一个某一方具有获利的特权并可以施加控制的底层结构。


   然而,其实为了向软件用户说明平等的重要性时,我们不必非要强调网络的影响力。没有哪个软件用户在质量和功能类似的开放源代码软件存在的条件下放弃开放 源码软件,而去选择封闭源代码软件,非要让自己被某个供应商垄断控制才高兴。软件对消费者的事务越重要,这个问题就越突出——它越重要,消费者就越不能容 忍自己被另外一方控制。


  最后,和信任问题相关的开放源代码的重要优势就是它的光明前景。如果源代码是开放的,即使发行者垮掉了,客户还是能掌握一些资源。这对于糖霜策略尤其重要,因为硬件趋向于较短的生命周期,但是作用更加普遍,并转换成开放源代码的增长价值。


  10.2 它们怎样相互作用?


  当从秘密比特得到的回报比从开放源码高的时候,从经济意义上说应该封闭源代码。当从开放源代码得到的收益比从秘密比特高的时候,那么无疑开放源代码更有意义。


   从表面上看,这是一个很普通的想法。但是当我们注意到开放源代码的回报比秘密比特更加难以度量和预计时,就是说回报常常被低估而不是被高估,这一点就不 那么平淡无奇了。实际上,直到1998年初业界主流开始重新考虑遵从Mozilla发行源代码的前提时,开放源代码的回报一直被普遍错误的认为是零。


   那么我们怎样评价开放源代码的回报呢?一般的说这是一个困难的问题,但是我们可以象处理其他任何一个预言性问题一样来处理它。我们可以从观察开放源代码 成功和失败的案例开始。试着抽象出一个模型,至少给出一个定性的感觉,在什么情况下开放源代码对投资者或追求最大回报的商业操能产生净收益。然后我们再用 数据来细化这个模型。


  从《大教堂和市集》一文的分析中,我们可以得到开放源代码在(a) 可靠性/稳定性/可扩展性至关重要时,和(b) 设计和实现的正确性除了采用其他同行检验的办法外难以验证时具有高的投资回报。 (在实践中多数重要程序都符合第二个标准。


   当软件对一个消费者至关重要时,消费者为避免被一个垄断的供应商所控制的愿望提升了他对开放源代码的兴趣(也因此提升了开放源代码厂商的市场竞争力)。 因此,另一个标准(c)当软件是一项非常重要的资产时(例如,很多企业中的MIS部门),封闭源码会把用户推向开放源代码一方。


   在应用程序领域,我们看到开放源代码底层软件创造了信任和平等的结果,随着时间的推移,一定会吸引到更多的客户,从而胜过封闭源代码底层软件;在这个迅 速扩张的市场上占有较小的份额常常比在封闭的和迟缓的市场上占有较大份额还要好。因此,对于基础结构软件,开放源代码的方式比利用知识产权得到收益的封闭 源代码方式会得到更高的长期回报。


  实际上,潜在用户根据发行商的策略推知它的将来发展能力,同时他们有不愿接受一个垄断供货 商的本能,因为这将意味着要处处受到约束;除非已经有了一个压倒性的市场力量,否则你可以选择一个开放源代码的方式也可以选择一个从封闭代码直接受益的方 式——但是不可能同时选择二者。(在别的地方可以看到类似的情况,举例来说,在电子市场上用户常常拒绝购买单独货源的设计。)这种情况的消极性可以消除一 些:在网络占支配地位的地方,开放源代码似乎是正确的选择。


  我们可以总结一下这种逻辑:在(d) 创建一个公共计算和通讯的底层结构时,开放源代码软件似乎可以比封闭源代码软件成功的获得更大的回报。


  最后,我们注意到,相对于核心算法和基础知识已被很好理解的服务提供商,提供唯一或独特服务的商家更加担心竞争对手会模仿他们的方法。因此,在(e) 核心方法(或功能)是公有知识一部分时,开放源代码更加可能取胜。


   实现了Internet核心软件,Apache, 和ANSI标准的Unix API的Linux系统是上面分析的五个标准的典型样板。在十五年建造自己的封闭协议(如DECNET,XNS,IPX等等)帝国的尝试失败之后,90年 代中期数据网络重又向TCP/IP集中,这生动的印证了这种市场向开放源代码演化的道路。


  另一方面,开放源代码对拥有自己独 特的创造价值的软件资产的公司没有太多意义(强烈满足条件(e)),下面这些情况也不太适用与开放源码,比如软件(a) 对失效相对不敏感,(b) 可以用同行检验以外的方式来验证,不是(c) 关键事务的,并且不是主要从(d) 网络作用或普遍使用上获得价值的。


  作为一个极端的例子,1999年初由一家公司问我“我们是否应该开放源代码?”,这家公司为锯木机编写计算切割模式的软件,可以从原木中获得最大的板材。我的结论是“不”。他们唯一接近满足的条件是(c);但是在紧要关头一个熟练的操作员可以手工的决定切割模式。


  值得指出的是,满足这些条件的特定产品或技术会随时间发生变化,从下文的案例中我们会看到这一点。


  总而言之,下面的条件宜于采用开放源代码模式:

   (a) 可靠性/稳定性/可扩充性非常关键时
   (b) 设计和实现的正确性不能很容易的用其他同行检验以外的方法验证时
   (c) 软件对用户控制他/她的事务非常关键时
   (d) 软件用来创建一个公共计算和通讯基础结构时
   (e) 关键方法(或等价功能)是公共工程知识的一部分时


  10.3 Doom: 一个案例


  id 软件公司卖得最火的游戏Doom的历史展示了市场压力和产品演化怎样改变了封闭源代码软件相对于开放源代码的收益数量。


   当Doom在1993年末第一次发布时,它的主观视角,实时动画是极为独特的(条件(e)的对立面)。不仅因为它那令人叫绝的视觉效果,而且在很长一段 时间内没人知道他们是怎样在低级的处理器上实现这些效果。这些秘密的比特可以获得非常重要的收益。而且,开放源代码的潜在收益很低。作为一个单独的游戏, 这个软件(a) 它的故障的代价很小,(b) 不是非常难于验证,(c) 对任何一个用户来说都不是至关重要的,(d) 并不得益于网络。所以Doom成为封闭源代码在经济上是很合理的。


  然而,Doom周围的市场不是静止的。竞争对手发明了它的动画技术的等价功能,其他的“主观射击”游戏比如毁灭公爵(Duke Nukem)等开始出现。当这些游戏侵蚀Doom的市场份额时,秘密比特的收益开始下降。


   另一方面,扩展市场份额的努力带来了新的技术挑战——更好的可靠性,更多的游戏特色,更大的用户群,和跨平台。随着"deathmatch" 的多人游戏模式和Doom游戏服务的出现,市场开始显示出对网络的依赖。所有这些需求都要求id公司在下面版本的游戏中花费更多的精力。


  所有这些趋势都提升了开放源代码的回报。在某一点回报曲线交叉,开放源代码成为id公司在经济上合理的选择,他们可以从诸如游戏扩展选集等第二市场上获益。在这一点之后的某个时间,事情确实发生了。 1997年末Doom的完整源代码被公开发行。


  10.4. 知晓何时放手


   Doom是一个有趣的案例,因为它既不是一个操作系统也不是一个通讯/网络软件;因此这远离了开放源代码的通常的明显的例子。确实,Doom的生命周 期,包括交叉点,可以作为今天的代码生态中应用软件的典型——在这个生态环境中,通讯和分布计算软件要求较高健壮性/可靠性/可扩充性、只能通过同行检验 来验证,并且常常超越技术环境和竞争者之间的界限(包含信任和平等)。


  Doom从一个单机游戏演化到deathmatch模 式。网络计算越来越重要。同样的趋势可以从最重要的商业应用程序,如ERP系统看到。商务网络把供应商和客户更加紧密的联系在一起——当然,它们包含在整 个万维网的体系结构之中。这种情况到处可见,开放源代码的回报稳步增加。


  如果当前的趋势继续下去的话,下个世纪软件技术和产品管理的核心挑战将是知晓应该何时放手——何时把封闭源代码转变为开放源代码体系结构,从而得到同行检验的好处,并从服务和其他第二市场上得到更高的回报。


  大家很明显都不想在任何一个方向上离交叉点太远。除了这个,等待太长时间面临着严重的风险——你可能会被一个走向开放源代码的同一市场上的竞争对手铲平。


   这个问题之所以严重的原因是,可以被吸引到某类产品的开放源代码合作者的用户群和专家群是有限的,而且这些人很难于转移。如果两个功能基本相同的竞争代 码一先一后开放源代码,那么先开放的更加可能吸引更多数的用户和更多数的最激情的合作开发人员;后开放的则不得不吃剩饭。吸引来的人员难以转移,因为用户 对软件已经熟悉,而开发人员已经在代码上投资了很多的时间。

11. 开放原代码的商业运作


  在开放式原代码的社区中,通常是以一种倾向于增强开放式原代码生产效益的方式来组织其自身的商业活动的。尤其在LINUX的世界里,存在着一个具有重要经济意义的事实,那就是存在有许多相互竞争的发行商,而他们形成了一个与开发团体相分离的、独立的层次。


   开发人员写原代码,并且使得这些原代码在互连网上是可以被下载的。每个发行商都从这些可下载的原代码中选取一些,并将它们进行综合,包装,并且注册商 标,最后将其买给顾客。用户可以选择发行商的产品,也可以通过直接从开发商的网站下载原代码而增补其自己已安装的发行版。


  这 一分化出来由发行商形成的层的作用是为创造了一个非常易于改变、可对产品不断完善的内在市场。开发人员为了吸引更多的发行商和顾客的注意力,在他们软件的 质量上彼此竞争。而发行商则为了从用户那里赚得更多的钱,互相在他们选择原代码的策略以及他们给软件带来的附加价值上竞争。


   内在市场结构中的第一特征就是网络中没有什么原代码是不可缺少的。开发商可能倒闭,即使他们的那部分底层代码没有直接被其他开发者所用,为吸引更多注意力 而导致的竞争将倾向于尽快产生一个在功能上可替代的产品。发行商可能在没有破坏或修改开放原代码的情况下就破产了。整个开放式原代码的商业系统作为一个整 体,与任何一个独立的封闭原代码的操作系统的发行商相比较而言,对市场需求有着更快的反应,并且在抑制巨大的波动及自我创新方面有着更强的能力。


   开放源码另一个重要的特征就是通过分工降低成本,提高了效率。开发商不愿经受传统的封闭原代码项目中那种例行公事般的压力,而是象这样来工作:没有来自 市场方面的那些不得要领、分散注意力的表单;没有要求他们使用不适合的而且已过时的语言或开发环境的强制命令;没有打着突出产品的特性和保护知识产权的幌 子要求用一种新的,不兼容的方式重新设计“轮胎”的命令;而且最重要的是没有项目完成最后期限的约束。这样,公司就不会在产品还没有做好以前,就匆匆忙忙 地推出一个1.0版本,正如DEMARCO和LISTER在从对"做完了再喊我"管理模式的讨论中所作出的评论(见《开发队伍与产品》一文)那样,这种模 式通常不仅会有益于质量的提高,而且实际上有助于一项真正的研究成果以最快的速度进行传播。


  另一方面,发行商们可以专门从事他们能高效完成的事情。这样,他们就可以集中精力在系统的综和一体化,包装,质量保证及服务方面,而不用去考虑所需要的大量的资金问题以及使正在进行的软件开发保持其竞争力的问题。


  通过作为开放式原代码商业模式中不可缺少的一部分,即来自于用户的不断的信息反馈和监督,无论是发行商还是开发商都会比较诚实一些。

12.成功的复制


  公用的悲剧也许并不在于他们对现如今存在的开放式原代码商业模式发展的适应性,但这并不意味着不存在任何理由去怀疑开放式原代码社区内目前的状况是否能持续下去。主要的参与者是否会随着风险的进一步增大而背叛共同的合作?


   这一问题可以从几种不同的层次来提出。我们的那个与"成功的公用"相反的故事是基于这样一种论断的,那就是个人对开放式原代码的贡献价值很难以量化的方 式来衡量。但是这一论断对于像LINUX的发行商那些已经拥有一部分与开放式原代码相连系的收入的公司来说,就没有太大的影响力了。而且,他们每天的贡献 价值已经量化了。但是,现在这种合作角色稳固吗?


  对这一问题的研究将导致我们对一些问题有趣的思考,譬如现如今真实世界中开放式原代码软件的经济状况,以及什么才是未来软件业中真正的软件服务行业中的典范。


  从实际的角度来讲,适用于现存的开放式原代码社区的这一问题通常可以用两种不同的方式来提出。一种LINUX将分裂吗?另一种是与第一个相反的,LINUX将发展成为一个处于支配地位,类似于垄断性的产品?


   当暗示LINUX将分裂时,我们不能不联想到20世纪80年代UNIX版本分裂的历史,许多人又重新开始思考历史是否回重演。尽管无休止的有关开放标准 的讨论,尽管有许许多多的联盟,协作和合同,UNIX的所有权归属还是分裂了。事实证明卖方通过增加或改变操作系统设备从而使他们的产品与众不同的愿望比 他们通过维持其兼容性,不断的减少独立软件开发商的进入障碍,以及降低维持与顾客的固定业务关系的总成本,来增大UNIX的整个市场份额的兴趣要更强烈。


   但是上述情况不大可能发生在LINUX身上,这是基于一个很简单的原因,那就是LINUX的所有开发商都被限制基于开放原码这样的根基来进行开发和其他 运作。而且事实上,对于他们其中的任何一个发行商来说都不太可能保持他们产品的与众不同,因为使得LINUX的原代码得以高效发展的许可证条款要求他们与 所有的发行商一起分享原代码。任何一个发行商只要一开发出新的特性,他们有的竞争对手都可以免费克隆它。


  因为所有的发行商都 深知这一点,所以甚至没有人想过要实施一个阴谋,一个和导致UNIX标准分裂的策略类似的计划。相反,LINUX的发行商被迫以一种实际上对顾客和整个市 场有利的方式进行竞争。那就是,他们必须在服务、技术支持、以及实际上能使得安装和使用都比较方便的设计方面进行竞争。


  共同 的开放的原代码还去除了垄断的可能性。当LINUX社区内的人们担心这一问题时,通常会抱怨一个叫"RED HAT(红帽子)"的名字,而"RED HAT"是LINUX最大的也是最成功的发行商,它几乎拥有美国市场上90%的份额。但是还有一个值得引人注目的事情,那就是在被大家期盼已久的RED HAT的6.0版本在1999年5月份宣布发行后的一段时间里,通过从RED HAT自己的FTP站点下载光盘镜像,一个图书发行商和许多其他光盘软件发行商就已经开始以比RED HAT更底的价格进行销售了,而且事实上在这段时间里RED HAT的CD-ROMS还没有真正的成批装船销售。


  但 是,RED HAT自己并未对此事怒不可遏,因为他们非常清楚的知道他们没有也不可能拥有他们他们产品中二进制数据中的任一个比特。因为LINUX社区里的社会准则不 允许他们这样做。在后来的日子里出现了JOHN GILMORE的著名的论断,那就是互连网上的人将对互连网的检查制度解释为对它的破坏和一些例行公事的程序。基于此,对LINUX负责的黑客们则巧妙地 将企图控制原代码也解释为是对它们的破坏和一些例行公事的手续。对于RED HAT来说,他们如果反对对他们的新产品在发行之前进行克隆,这一行为将严重地使他们未来吸引开发商们进行共同合作的能力大打折扣。


   也许就目前来说,以一种与法律相结合的形式来表达LINUX社区准则的软件许可证制度正积极主动的阻止了RED HAT对他们的基于开放源码产品的垄断。他们唯一能卖的就是一个品牌、服务以及与那些自愿付给他们钱的用户之间的技术支持关系。这不会让压倒性的垄断局面 出现有太大的的可能性。

13. 开放研发和再开发


   投资者向开放源码世界投资的另一个原因就是要改变他。开发者逐渐感觉到他们可以从他们想干的事情中获得报酬,而不是用自己的正式工作的收入来维持他们对 开放源码运动的爱好。象Red Hat, O'Reilly Associates和VA Linux System这样的公司正在探索通过雇佣并维持稳定且能干的开放源码程序员来建立半独立的研发机构需要多大的投入。


  这种方式 只有在公司通过迅速扩大市场所带来的收入能够足够用于支付那种研究实验室时才是经济上可行的。O'Reilly之所以能够负担Perl和 Apache的主要作者来完成他们的工作是因为经过努力公司能够出售和Perl以及Apache相关的书;VA Linux System能够让实验室有足够的经费来源的原因是随着Linux的繁荣,他们可以卖掉更多的工作站和服务器;Red Hat可以负担他的高级研发实验室也是由于实验室可以不断提升公司的Linux产品的价值并吸引更多的用户。


  在将专利、商业秘密等知识产权看成是企业的掌上明珠的文化的熏陶中,这种思想(开放源码)对于传统软件产业的战略家来说简直是无法解释(尽管自由软件市场事实上在不断地扩大)。为什么你花钱来做的研究得到的成果却可以让你

分享到:
评论

相关推荐

    Cauldron

    标题"Cauldron"可能指的是一个特定的字体设计或排版工具,这在"字体"这一标签中得到了进一步确认。在计算机领域,字体是决定文本视觉表现的关键元素,包括字母、数字、标点符号等字符的形状、大小、风格。Cauldron...

    cauldron-源码.rar

    【标题】:“Cauldron源码分析” 【描述】:Cauldron是一个开源项目,其源码的深入理解能够帮助我们了解软件的架构、设计模式以及编程技巧。通过对Cauldron源码的分析,...这将对个人的职业发展有着极大的推动作用。

    前端开源库-grimoirejs-cauldron

    **灰树大锅:GrimoireJS Cauldron 前端开源库详解** GrimoireJS Cauldron,简称“灰树大锅”,是基于GrimoireJS框架的一个...通过理解并熟练运用Cauldron,可以极大地提升团队协作效率,确保项目的稳定性和可维护性。

    cauldron-1.7.10-1.1388.1.0-server.zip

    Minecraft核心可以装MOD的,感谢下载,我QQ1780614962.有全套核心,需要的可以来找我,包括PE低版本核心高版本核心

    Python库 | cauldron-notebook-0.0.16.tar.gz

    对于数据科学家和Python开发者来说,掌握Cauldron Notebook的使用能够极大地提高工作效率和代码质量,是值得学习和应用的库。通过不断迭代和升级,Cauldron Notebook有望在未来继续引领数据科学工具的发展潮流。

    PyPI 官网下载 | cauldron-notebook-0.2.1.tar.gz

    **PyPI 官网下载 | cauldron-notebook-0.2.1.tar.gz** PyPI(Python Package Index)是Python编程语言的官方软件仓库,它提供了大量的第三方库供开发者下载和使用。在这个场景中,我们关注的是一个名为`cauldron-...

    PyPI 官网下载 | cauldron-notebook-0.3.6.tar.gz

    《PyPI官网下载:深入解析cauldron-notebook-0.3.6.tar.gz》 在Python的世界里,PyPI(Python Package Index)是开发者们发布、分享和安装Python库的重要平台。今天我们要关注的是PyPI上的一款名为“cauldron-...

    PyPI 官网下载 | cauldron-notebook-1.0.8.tar.gz

    虽然`cauldron-notebook`本身并不直接与ZooKeeper集成,但在构建大规模、云原生的数据科学工作流时,ZooKeeper可能会作为一个潜在的组件来确保不同节点间的协调和数据一致性。 **云原生 (Cloud Native)** 云原生是...

    Python库 | cauldron_notebook-0.3.3-py2.py3-none-any.whl

    **Python库 Cauldron Notebook 0.3.3** Cauldron Notebook 是一个Python库,专注于提供一种高效、互动的环境来进行数据科学和机器学习项目。它以其易用性和强大的可视化能力为特点,旨在简化数据分析工作流程。该库...

    Cauldron:在Vulkan或Direct3D 12上进行快速原型制作的简单框架

    Cauldron由AMD开发,并在内部用于开发原型,演示和SDK示例。 Cauldron被编译为静态库。 要查看其运行情况,请检查以下项目。具有Cauldron功能的项目单次下采样器(SPD) 随机屏幕空间反射(SSSR) 亮度保存映射器...

    Cauldron:来自 Cauldron 的非官方叉子-开源

    一个来自 Cauldron 的非官方叉子,我添加了伪造库...新 Cauldron 调用 KCauldron,请在 https://sourceforge.net/projects/kcauldron/files/?source=navbar 下载

    cauldron-web:Cauldron网站的镜像存储库

    新的Cauldron,它使用grimoirelab工具来分析GitHub用户,组织和git存储库。 如果您想尝试一下,请参考。 开发现场版本 也许您可能想修改一个实时版本的Cauldron以查看实时变化。 为了使之成为可能,您将需要对配置...

    cauldron:收集一切

    使用Cauldron,您可以根据规则存储所有对象 免费软件:BSD许可证 文档: : 。 特征 Cauldron允许您根据一组规则存储所有对象。 用法 该API是WIP,但实际上可以运行: 请注意,这需要克隆存储库(而不是安装存储库...

    minecraft-cauldron-dns:minecraft-cauldron-dns 的 Docker 镜像

    Cauldron 上的 Minecraft DNSTechpack 这些是在上运行的 Minecraft DNSTechpack 的 docker 镜像。 用法 docker run -v /minecraft/merge -v /minecraft/world -v /minecraft/logs --name minecraft-dns-data ...

    morrics-magical-cauldron

    莫里斯魔力大锅 莫里克的魔法大锅是随机内容生成器的集合,旨在在《龙与地下城》的休闲游戏中使用。 除了从预定义的表格(例如,按种族划分的角色名称)中生成随机内容外,它还对用户提交的内容进行随机化处理,包括...

    envirofix:使用Enviromine Mod在Cauldron服务器上死后重置状态值的快速修复

    然而,当玩家在 Cauldron 服务器上死亡后,可能会面临一个问题:状态值不会自动重置,这可能导致玩家在复活后仍然受到之前状态的影响,影响游戏平衡。 Cauldron 服务器是基于 CraftBukkit 和 Spigot 的多模组服务器...

    cauldron-react

    请转到大锅React安装$ npm install cauldron-react --save 注意:希望您包括的css演示应用为了通过示例进行记录并使开发/手动测试变得容易,有一个演示应用程序可以通过执行以下命令启动: $ yarn dev 查看demo/...

    scripts:运行 Cauldron 所需的所有脚本的基本存储库

    Cauldron 插件的入门脚本集合 警告! 这些脚本都不适用于 Rhino/Nashorn,仅仅是因为该项目在某种程度上符合 ES6(这两个引擎都不是)。 这些都是在 GraalVM 上开发的,从 GraalVM r19 开始,它与 Windows 兼容! ...

    Cauldron:从Java对象生成Dart对象并在它们之间进行序列化

    釜从Java对象生成Dart对象并在它们之间进行序列化maven { url ' https://jitpack.io ' }implementation ' com.github.ArcaneArts:Cauldron:latest.release '基本用法Cauldron.jar <package> <server> <dart> ...

Global site tag (gtag.js) - Google Analytics