Linux 版 (精华区)

发信人: NightOwl (Deamon&Daemon), 信区: Linux
标  题: 世纪末的思考——魔法大锅炉(Eric Raymond) (转载)
发信站: 紫 丁 香 (Sun Jan  2 02:33:20 2000), 转信

发信人: fkbch (无灵子@笨愚斋), 信区: Linux
标  题: 世纪末的思考——魔法大锅炉(Eric Raymond) (转载)
发信站: BBS 水木清华站 (Fri Dec 31 18:08:56 1999)

【 以下文字转载自 FreeDevelop 讨论区 】
【 原文由 Aka 所发表 】

《魔法大锅炉》(The Magic Cauldron)一文是国际自由软件知名人士Eric Raymond
在1999年夏天发表的一篇重要著作。xiaobo曾经把Richard Stallman比喻为自由软件
王国的教皇、Linus则为掌管大权的国王、而Raymond则被比喻为一个兢兢业业的宰相。
这个比喻很有意思,也挺形象。Eric Raymond总是在努力的推动着自由软件的发展,
他的文章如:《黑客文化简史》、《如何成为一名黑客》、《大教堂和市集》、
《开拓智域》等总是具有震撼的力量,所以当iasc第一次向我介绍了这篇新作时,我
就感觉到应该把这篇文章翻译成中文,以让更多的国内计算机爱好者来领略其中的
力量。在我粗览了全文后,翻译的决心更大了,但是面对内容如此丰富、内涵如此
深邃、引用非常广泛的巨著,我又有些畏缩了。幸而得到了iasc, merlin等朋友的
热情鼓励与合作,同时又先后获得了wclee, liyuhang, sto, ly_hust, kiwi, lilly,
wl_wan等网友的支持与帮助,才得以让这篇中文译稿面市,欣慰的同时也对上面所有
参加翻译的朋友表示最 现康 谢意。

本文分析了开放源代码现象不断发展的经济基础。首先推翻了一些流行的关于程序开
发资金和软件价格结构的神话。给出了一个关于开放源代码协作稳定性的搏弈论分析。
给出了九种开放源代码开发的可发展模型,其中两种是不盈利的,七种是盈利的。接
着发展了一种定性的理论,说明什么时候封闭代码在经济上是合理的。然后考察了当
前市场上发明的几种新颖的开放源代码开发的盈利方法学,包括赞助系统和任务市场
的引入。最后做出了结论,试着对将来做了一些预测。

全文共分18章,其中merlin和iasc参与翻译了序言和目录,merlin参与翻译了1, 2, 9,
10章,iasc参与翻译了1, 3, 4, 5章,wclee参与翻译了第2章,liyuhang参与翻译了
第6章,sto参与翻译了第7章,ly_hust参与翻译了第8章,wl_wan参与翻译了11, 12章,
rover参与翻译了13, 14, 15, 16, 17章,同时在翻译过程中kiwi和lilly等热心网友都
积极参与翻译工作,AKA的老朋友,现在在美国读书的waterbird也给了我许多意见和指
导,在此一并表示感谢。

由于我们造诣尚浅,翻译过程中肯定会出现许多不确切甚至是错误的地方,我们热诚
欢迎所有网友给我们提出意见和建议,您可以直接发信到SMTH上AKA的信箱,你的建议
将被用于更新和修正这篇译文,我们在此先向你表示深深的谢意。

注:本文的原文可以从下面的地址获得:
    http://www.tuxedo.org/~esr/writings/magic-cauldron/magic-cauldron.html


下面请大家开始阅读正文吧。

===========================================================================
  魔法大锅炉

  Eric S. Raymond著
  1999年六月


本文分析了正在不断发展的开放源代码现象的经济基础。我们首先推翻了一些
流行的关于软件开发中投资和软件价格结构的神话,给出了一个关于开放源代
码协作稳定性的游戏规则分析。我们给出了九种开放源代码开发的可发展模型,
其中两种是不盈利的,七种是盈利的。接着我们发展了一种定性的理论,说明
什么时候封闭代码在经济上是合理的。然后我们考察了当前市场上发明的几种
新颖的开放源代码开发的盈利方法学,包括赞助系统和任务市场的引入。我们
最后做出了结论,试着对将来做了一些预测。Table of Contents

目录

1.近乎魔法
2.超越高手的天赋
3.制造业的错觉
4."信息需要免费"的神话
5.驳斥公用悲剧说
6.封闭源码的原因
7.使用价值集资模型
 7.1 Apache案例:成本分担
 7.2 Cisco案例:风险分散
8.为何销售价值存在问题
9.间接的销售价值模型
 9.1 失败的领导者/市场定位者
 9.2 糖霜策略
 9.3 奉送食谱,开办饭店
 9.4 衍生物
 9.5 现在收费,未来免费
 9.6 软件免费,卖标准
 9.7 软件免费,卖内容
10.何时开放,何时封闭
 10.1 靠什么盈利?
 10.2 他们如何互相作用?
 10.3 Doom:一个学习的案例
 10.4 知道何时该放手
11.开放原代码的商业运作
12.成功的复制
13.开放研发和二次开发
14.由此及彼
15.结论:自由软件变革之后
16.参考文献和致谢
17.附录:为何封闭驱动程序损失卖主金钱
18.本文档修订记录

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%的市
场份额<http://www.netcraft.com/survey/>;--没有合法的拥有者,没有组织
机构,也根本没有合同制约的组织形式在背后操纵。

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

--
       @@@@           @@@@
     @@@@@ @@   N   @@ @@@@@
   \ @@@@ @ @@  i  @@ @ @@@@ /
      @@@  @@   g   @@  @@@
        @@@     h     @@@
      \         t         /

※ 来源:.紫 丁 香 bbs.hit.edu.cn.[FROM: 202.118.179.51]
[百宝箱] [返回首页] [上级目录] [根目录] [返回顶部] [刷新] [返回]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间:205.807毫秒