开源十年的历史经验总结与商业化进程

来源: LUPA开源社区

　　任何建立在社区基础之上的事业都有可能引发激烈的争议。说到底，如果没有争议，我们如何才能决定最佳的发展方向呢？

　　自诞生之日起，开放源码所体现的就是这种开放精神。其中，部分人可能是出于挑衅，部分人可能是过于自信，但更多的人是直率和坚持己见，这些沉迷于社区工作、既合作又争吵的精英们的目标只有一个，那就是让开源运动能够在多个有价值潜力的方向上突飞猛进。

　　所谓有价值潜力，就是在社区的某个角落能够隐约听见可能赢利的商业模式敲响的鼓点，能够吸引厂商和资本关注的东西。一般说来，关注度越大，发展潜力越大，那么随之而来的争吵也就会越激烈。

　　在开源商业会议（3月25~26日，美国旧金山）召开之际，11位开源社区的思想领袖共同探讨了开源目前的现状，揭示了一些最具诱惑力的话题，以及形成今日开源现状的各种矛盾冲突。

　　开源的历史经验

　　开源社区已经有了丰富而且复杂的历史，但多年来它却是在不断试错的过程中走过来的。从开源社区的历史中我们能够得出什么样的教训和经验呢？

 

　　谈论一家公司或一个项目的失误是比较容易的，但是开源社区就是全部开源软件开发者的经济体，或者说就是软件业本身。这样一个行业并没有一个领导中心，而是无数彼此分离的角色在走着各自的道路。但这也正是它比单一的公司更为健康的关键所在。

　　如果要我说，我认为最大的失误与其说发生在技术领域，还不如说发生在法律领域。有些公司已经进入法律程序，有些还在预审阶段。SCO与IBM的开源官司在美国引发了软件专利诉讼狂潮。而在此之前，美国专利局实际上是限制软件专利诉讼的。打破这种限制对于整个软件业和美国经济来说都是一个巨大的错误。美国道富银行也在利用商业专利打官司。美国通过了《数字千年版权法》，还将其推行到了其他国家，这是完全违背用户意愿的。这些就是我希望修正的错误，如果我有能力修正的话。



　　我们的最大失误可以追溯到1985年。那个时候，我们的宣传功能完全被自由软件基金会拿走了。从纯技术层面看，1987年前后当廉价的32位PC问世时，开源原本应该发起一场有效的宣传攻势，但结果却没有。如此说来，由于我们的理论基础薄弱、法律上的“污点”、社区的四分五裂和我们在宣传方面令人可笑的无能，让我们白白浪费了10年时间。

　　不过公平地讲，无论是我还是其他任何人，都没有在那个时候担负起宣传的责任。很显然，开源社区始终未能突破技术发烧友的圈子，直到1997年以后，Linus Torvalds和我找到了一个更好的故事，情况才有所好转。各位是否知道，玛雅人发明了车轮，却只将它用在了儿童玩具上？会讲故事真的很重要。开源并不是处在边缘地带默默无闻的第一种技术，只是因为它还没有找到一个很好的创世神话而已。



　　开源要想在开发和商业运作两方面取得进展，除了试错或者摸着石头过河以外别无他途。在商业上的最大失误可能就是对许可证制度过于着迷了，这种事情虽然重要，但是太耗费精力了。

　　此外还可指出其他的教训，我要说的是，开源项目和开源企业应当更为主动积极地去证明自己在关键任务环境中的作用。在这方面虽然已经有了一些进展，但开源社区也只是从去年才开始对此有所关注的。



　　我坚持认为，最大的教训依然是“桌面问题”。从很早的时候起，人们就把Linux当成一种可替代的桌面系统来看待的，直到今天依然如此。与此同时，操作系统及其相关基础设施工具，如Apache、PHP等在服务器端出现了爆炸式的增长和扩散。我知道很多人都在抨击Windows甚至Mac OS X，就是因为它们不开放。这也许是真的，但没有人会认为这两种操作系统所带来的用户体验会输于Linux（至少今天是如此）。这里的教训就是，开源应该提供比其他操作系统更直接、更实实在在的利益，市场自会有能力去做出选择。终有一天，我们会得到一套完美的Linux桌面，但我看不出它会很快出现。



　　最大的教训：知识产权很重要。我这么说当然不是说开源社区不尊重知识产权，恰恰相反，我们绝对相信健全的知识产权制度有助于软件业的繁荣。

　　我的意思是说，在开源社区，我们一直在试图改变世界，却忘记了这个世界是用知识产权堆砌起来的，我们威胁到了现有的商业厂商。于是他们开始磨刀霍霍（有微软的FUD为证），开始反击，这让情况变得非常复杂。现在，光靠善意的代码是打不赢这场战役的。



　　在过去几年间，专利厂商也得到了相同的教训，那就是只有优秀的软件是不够的。我最近浏览过SourceForge，它上面有大约17万个项目，但是大多数项目已经流产了。成功的软件，无论是开源的还是专利的，都需要开发过程与其他环节——分发、市场推广、销售等的完美结合。如果没有Red Hat，Linux就不可能成为主流操作系统。我知道有些人不同意我的看法，但是我坚持认为，没有JBoss公司就没有JBoss、没有MySQL公司就没有MySQL、没有Sugar公司就没有Sugar。对于这些事实，是不会有太多争议的。尽管PostgreSQL是个非常棒的数据库，但是因为它的背后没有一家公司在做支撑，所以它没有成功。我们目前想做的也就是让EnterpriseDB成为这样一家幕后公司。这比构建优秀的软件更为重要。我们需要市场推广、服务、销售、技术支持、文档等等。所有这一切并不是开源项目必须要做的，而是想做软件的投资商应该做的。



　　我根本不认为开源的历史上有过什么重大的失误。我举个例子。10年来，像IBM、苹果和其他一些公司都在尝试着想把微软从操作系统的宝座上拉下来，但他们都失败了。再看看今天，谁是增长最快的服务器操作系统？是Linux，而这个平台最早只是由一个芬兰学生开发的。开源所做到的，却是数百亿、数十亿美元身家的公司所做不到的。我们从中学到的经验就是，只要你以透明的方式正确地解决了问题，你就能利用开源社区做出非常受欢迎的优秀软件。像Linux、MySQL和其他的开源软件极大地破坏了软件业的传统经营方式，把更强大的力量放在了用户手中。这是好事，没有什么失误。



　　我没看到什么失误，但是当我看到面向行业的开源项目很少有人支持时，也会感到沮丧。一般说来，除了教育和公用行业以外，只有极少的开源项目会引起关注或被采用。所以当我看到Sakai和Moodle做得如此之好，能在教育和培训市场上与专利软件竞争，我很高兴。我们需要在保险、银行、汽车、零售、能源、通信以及其他所有行业复制这些成功经验。另外一件我认为需要做的事情，是要更好地宣传世界各地的自由和开源的英雄们。正是这些人彻底改变了IT业。



　　我们学到了很多的教训：比如开源项目最好不要由某个组织启动，非赢利组织能提供更好的帮助，同时也教会了我们如何更好地与社区做沟通等。不过这些都已成为过去了。下一步是要继续保持增长，要和相关的商业组织开展合作，从企业的角度去提升开源产品的水平，力争进入主流商业和主流市场。



　　最好的经验：仔细选择项目开发人员是最重要的。

　　较大的失误：我认为开源社区没有对BSD操作系统社区正在做什么予以足够的关注。开放、网状沟通、自由的BSD社区特点非常突出，他们的工作理应获得更多的关注。

　　最大的失误：最大的失误总是会落实在一件事上：坏的代码。必须承“认坏的代码＝坏的项目”。坏的代码会扼杀开源项目。

　　开源的商业化

　　开源软件被广泛采用并且商业化，这对于开源项目来说是一种新的挑战或压力吗？



　　商业化产生了额外的压力，尤其对于那些原本免费、但在企业参与变成商业产品的项目来说压力更大。坦率地讲，一个牵涉商业利益的开源软件项目会引起很多人的“过敏”反应。之所以会产生这种反应，主要是因为商业利益有可能毁掉该项目的开发决策过程。事实上，如果没有某种问责制，那么开源项目就有可能在很大程度上成为不能及时交付而且可用性极差的学术试验，这对于商业利益来说是有风险的。如何将这种问责制应用于开源项目，是商业化能否成功的关键。

　　当某个项目的采用率增加时，就会需要一定程度的管理和指导。一个有趣的场景是，一个项目在多个社区中都有不小的采用率，因此也就产生了很多潜在的利益冲突。如果没有一个合适的管理架构，那么该项目就会因无法协调各种不同的利益而出现纷争的局面。

　　不过这些情况实际上都不适用于我们这样把知识产权、项目和企业捆绑成一个实体的公司。我们的社区是开放的，开发工作和其他开源项目完全一样。这样的社区就能够平衡对资金的需求和推动社区去提供对客户有价值的产品这两种需求。



　　确实如此，但我认为开源的结构本身就可以减轻开源项目的成功所附带的不利影响。例如，所有的企业并购，都可以预期合并后的公司会通过投资很快进入某个市场。不过开源项目可不是强迫就能做得来的。社区是不能强迫的，而要把采用率转变成收入也是强迫不来的。所以我认为，我们正在看到并将继续看到开源社区会出现大量的类似淘金热的心态，正是由于对开源商业模式已经有了很紧迫的需求，所以不太可能陷入Web 2.0这样干打雷不下雨的尴尬窘境。

　　我所担心的主要是可能会出现走捷径的现象。很多人将开源只看成是营销花招。他们提供一定数量的开源代码作为一种甜头，诱惑一些人去购买他们的“正版”软件。以我的经验，这种做法只会削弱开源对于客户的价值，只会让客户对开源模式失去信任感。我真得不希望让客户们以为开源模式不过是厂商的一种新的营销伎俩，从而对开源失去兴趣。



　　有开源项目，就有将此项目商业化的企业。但是商业增长并非所有人都会优先考虑的东西。Apache项目就非常普及，但从未有人想过要靠它来挣钱。不过我认为，认识到可以用开源来构建商业模式已经是一个巨大进步了。这在5～10年前还是不可想象的。而像Red Hat、Sun、IBM等公司利用开源软件已经赚到了大把大把的美元。

　　不过有一点必须弄清楚，你要做的是商业化，还是只做项目。如果是做商业化，就需要有一个商业模式，能够为客户的付出提供有价值的东西。事实上，有两类开源客户，他们都是需要加以关注的市场。这两类用户就是不付费的社区用户和付费的企业客户。你需要同时为这两类客户提供服务。如果你不够商业化，那结果就会像Apache。如果你不够社区化，那你也不可能获得广泛的采用率和开发规模。在商业化机会到来之前，采用率应该是第一位的。做到这一点并不容易，但只要路子走对了，获得双方用户的欢迎还是有可能的。



　　首先，认识到开源软件商业化带来的机会是很重要的。我认为Digium就是这样一家站在了下一步发展前沿的公司。以赢利的企业来开发开源项目，这对企业来说存在着一个机遇，因为它能够提供非赢利组织所无法提供的市场推广、产品质量保障、正规的测试、文档、行业认证，以及其他很多的好处。

　　另外，由于一些企业只使用开源软件，但实际上却没有以任何方式对社区做出回馈贡献，所以也存在着一些难题。从法律上说，这种做法有时候是允许的，但肯定不利于开源项目的发展，尤其是当这些企业还与投入了资源开发该项目核心技术的公司相互竞争的时候。虽然跟项目关系密切的社区很清楚这两类公司的差别，但是普通的使用人群可能并不知晓。所以我认为应该教育用户去支持“真正”开源的企业，这对于发挥开源模式的最大效率是至关重要的。



　　开源“项目”转变成“产品”是有极大的可能性，因为现在已有很多企业在把开源作为其核心基础设施的组成部分，因为风险投资公司正在主动地向开源公司投资。

　　这种状况是带来了更多的压力，但也创造了更多的机会。而且因为已经有了一些成功的开源商业模式，所以商业化正在变得越来越简单。



　　我不认为存在什么普遍的和完善的指南这一类东西能够指导开源项目在一夜之间变得流行起来。

　　同样的，一些开源项目要想在其基础上产生成功的商业模式似乎也有很长的路要走。假如所有的名校都开始安排大量的时间用开源的成功商业模式去教育学生的话，那我们就知道开源真正成功了。依我看，是会出现很多新的挑战和压力，但那不是因为技术，而是因为商业问题。我们的开源社区有很多很多杰出的开发人员，我们同样希望这些社区里能够诞生很多很多杰出的、具有“远大抱负”的商业领袖。



　　实行商业化至少有两种做法。一是简单地增加性能，从而增加代码量。看一下Linux内核的发展轨迹，随着代码量的增加，其复杂性也增加了。而更多的复杂性也就意味着更多的缺陷。这并不新鲜，所有的软件都是这么走过来的，开源软件当然也不能例外。我们必须制定关键性、战略性的决策，找出能够保持软件质量的最佳开发模式。

　　第二种做法对于一直在社区中共同开发的项目构成了挑战。因为当这些项目被商业化以后，来自商业化的利润回流却是非常不公平的。这种状况目前已经引起了开发人员和商业人员之间的关系紧张，但我认为，这个行业最终将能找到某种标准，可以公平地分配商业化的利润。



　　目前的情况和上世纪90年代末没有太大差别。好事情是，开源项目中的商业利益确实可能会在一些重要的开源项目中产生好的代码。但坏事情是，它也同样可能会让开发人员屈服于无法拒绝的一些坏的代码。不可能所有的项目都好到既能拒绝水平差的编程人员又能拒绝他们的坏的代码。



　　对于开源项目来说，最大的挑战就是要继续保持清醒和热情。最早的一些开源项目都是由一些相对小型的社区开发的，开发人员围绕某个特殊理念充满了激情。很坦率地讲，他们开发项目时，完全没有想过赚钱的目的。但是随着开源运动的发展，参与者们不得不谨慎从事了。有人曾对我说：“当组织变大以后，它也就变得愚蠢了。”我认为这句话也适用于任何新技术或者新趋势。因此，开源项目需要做的就是保持清醒，维持他们的优势，千万别向最低的水平看齐。



　　我不认为商业化会产生什么新问题。只不过会多少改变问题的影响范围而已。坦率地讲，行业媒体如此热衷的所谓“商业化是否会毁掉开源？”的担忧，对我来说已经是五年前的老问题了。



　　今天，许多公司都面临着一个很大的问题，那就是企业的运营其实完全依赖于开源，但他们甚至还没有开始制定企业的开源战略。我遇到过这样的一些CEO，他们根本不知道自己的企业在使用开源，过后才发现企业不仅在用，而且企业所有的关键任务项目都在依赖开源。

　　我当年在编写发放开源许可证规则时，根本没有想到开源会有今天这么热，一家企业就拥有70张许可证。然而，要处理70张许可证的各种组合实在是太复杂了。所以我建议企业顶多拿3张许可证，可彼此兼容就行，这对于大多数商业用途的开源产品发布来说足够了。

　　我想，我们的下一步目标或许并不在软件本身。今天，Wikipedia已成为全球最大的内容提供商，而且其内容全部开放。我们要好好想想，还有什么项目可以做到这一点？

声明：LUPA开源社区刊登此文只为传递信息，并不表示赞同或者反对。