作者文章: Fenng

从 Solaris 到 illumos – 关于技术权力抗争、开源以及梦想的故事

今天看了现任 Joyent 工程副总裁 Bryan Cantrill 的演讲：Fork Yeah! The Rise and Development of illumos，讲述 illumos 项目的来龙去脉，披露了不少关于 Sun 、 Oracle 以及开源社区的信息，据说 Cantrill 在做这个演讲的时候，与会者很「动容」。而其中的陈年往事咀嚼起来很是值得思考。

首先说说这位 Bryan Cantrill ，「他曾荣登 MIT 《科技创业》35位35周岁以下顶尖技术专家榜，并被 InfoWorld 评为年度杰出创新家。在加盟 Joyent 团队之前，Cantrill 是Sun公司的杰出工程师。他在Sun公司花了十多年的时间研究了系统软件，包括从内核到浏览器客户端代码，以及和内核相关的多种组件。最有名的便是 Cantrill 联合设计并实现了DTrace。」(refer) 在 Oracle 收购 Sun 之后，Cantrill 于 2010 年 7 月离开的 Oracle，加入了 Joyent 。

在 Bryan Cantrill 的演讲中，他先是从个人的角度回顾了一下「历史」：从 SunOS 4.x 到 Solaris 的转换过程中，有很多优秀的工程师离开，导致这个问题的主要原因是引入了不成熟的 SCM 工具，Network Software Environment (NSE) — 可见，技术官僚的错误决定在哪里都是极有破坏性的。NSE 的糟糕引来了工程师的「逆袭」，Larry McVoy 干脆开发了一套 NSE 轻量级的变种，NSElite。通过 NSElite 以及后来的 Teamware , Roger Faulkner、Tim Marsland、Joe Kowalski 以及 Jeff Bonwick 等人领导的 Solaris 2.3 项目基本达到了还可以的并行开发的效率，不过到了 Solaris 2.4 就无能为力了，质量再次滑坡。

Solaris 2.5 的开发则是背水一战，只许成功，不许失败。这个时候，Sun 有了新的硬件 UltraSPARC-I 。为确保开发质量，工程师们进行了「接管」： Jeff Bonwick 担当起代码看门人的角色，坚持「if it’s broken, rip it out」的原则，确保了 Solaris 2.5 按时发布，并且确保了软件质量。经此一役，工程师们再也不愿意失去对操作系统开发上的控制。

到了 1990 年代中期，一个无法回避的论断是 Unix 必将死于 Windows NT 之手，而令人无法相信的是，Sun 居然是唯一一家意图对抗 Windows NT 的操作系统开发商。新一代「Bonwick Youth」的加入，天才们互相吸引，期待给操作系统带来革新，就像当年的 Xerox PARC 实验室那样。到了 2001 年年中，新的激进的开发开始了，这些新的操作系统功能包括：DTrace、ZFS、Zones、FMA、SMF 等。这些激动人心的特性并非由市场或是管理层驱动，而完全是工程师的想法。

ZFS，号称「终极文件系统」，首席设计师即为 Jeff Bonwick。

而这个时候，Linux 以及开源运动已经兴起，对 Sun 不可能没有冲击，内部也在反思。但是出于知识产权方面的限制，讨论了未有定论。2005 年，时任 CEO 的 Jonathan Schwartz 做出决定将操作系统开源，先是 Dtrace 开源，然后是 OpenSolaris ，时间是 2005 年 6 月。遗憾的是，有些小的但是至关重要的软件则无法开源(比如有些驱动程序含有第三方知识产权)，为此 Sun 制定了 CDDL 许可协议，不过与 GPL 不兼容。

2007 年开始，Sun 决定创建一个全新的基于 OpenSolaris 的发布，名字仍然叫做 OpenSolaris，接下来的几年，Sun 与 OpenSolaris 管理委员会(OGB) 陷入了诸多摩擦，相互牵制。OpenSolaris 发展缓慢。

随着 2009 年 Oracle 宣布收购 Sun，到 2010 年收购完成收购。OpenSolaris 的命运已经很清楚了：Oracle 对此毫无兴趣。

Illumos Logo

2010 年的夏天，存储厂商 Nexenta 的 Garrett D’Amore 在 Rich Lowe、Jason King 等人的帮助下，发起了 illumos 项目， D’Amore 等人针对版权限制的软件，或是从头写代码，或是从 BSD 系统移植，2010 年 8 月 3 日，illumos 正式可用。「Illumos」这个词来自 Illuminare，也即拉丁语的 Illuminate，「照明、照亮」的意思，可谓深有用意。

illumos 项目的最终目标有两个：一是使用开源代码取代所有仍在 OpenSolaris 使用的专有代码，二是围绕之前的OpenSolaris 代码库建立一个独立的社区。严格来说，并非 OpenSolaris 的分支项目。

2010 年 8 月 13 日，星期五，Oracle 内部泄露出来的邮件写到「在企业版Solaris系统完整发布后，我们将会向得到许可的 CDDL 或其他开源授权发布更新。通过这种方式，技术创新将会首先出现在我们发布的版本中。我们将不再实时发布整个Solaris系统的源代码。」

Oracle 的对待 OpenSolaris 的冷漠乃至不作为导致了 Solaris 团队的大范围流失，比如前文提到的 Jeff Bonwick 也在 2010年 9 月 30号离职。在不到 90 天内，DTrace 团队全部成员离开 Oracle，其他关键特性的开发人员亦纷纷离职。好消息是，这些离开的工程师全部加入了支持 illumos 项目的公司，比如 Nexenta、Joyent 、Delphix 等。关于 DTrace、ZFS 、Zones 等操作系统特性的创新将由 illumos 传承，但不会再次出现在 Solaris 上。illumos 软件库将成为记录操作系统技术危机的一个活标本。

从 Oracle 离开的 OpenSolaris 工程师们绝大多数活跃于 illumos 社区，给 ZFS 、DTrace、Zones 等带来了更多激动人心的特性。基于 illumos 的发布包括 OpenIndian、SmartOS、illumian 等，这些发布版面向不同用户群，互为补充，发展势头不错。

但是，发展中的 illumos 项目依然矛盾重重，去年 LWN 杂志的一篇题为 Illumos: the successor to the OpenSolaris community 的文章揭示了开源社区的一些明争暗斗。开发者 Stamos Tolias 抨击 illumos 项目的「思维狭隘，ZFS中心独裁以及大教堂式的开发模式」，并且企图另建分支。Illumos 的发展被认为不够开放，缺乏独立性，而 Oracle 的潜在诉讼也正在威胁 illumos 的命运。谁都知道 Oracle 公司打官司的「威力」。

也正是因为 illumos 项目由几家商业公司支持，暂时来看，怕是很难摆脱「大教堂」模式的开发弊病，而这引起了技术社区的批评。在这里，只能期待这些支持 illumos 项目的商业公司不要短视。祝愿 illumos 在将来能有更好的发展吧。

如诸君所见，illumos 项目寄托了一代技术精英的梦想。从 SunOS 到 Solaris ，从 OpenSolaris 再到 illumos ，期间发生的故事不知道有多少，关于 Sun 跌宕起伏的命运，关于技术权力抗争、开源以及梦想的故事，或许将来能有人详细如实的记录下来，一定非常有借鉴意义。

「Code over discussion; Innovation over democracy」
参考信息：

PS. 一时仓促，应有谬误，欢迎指出。

–EOF–

产品的最短路径

最近和同事以及一些业界朋友聊起用药助手这款应用的产品理念的时候，我常常会提及「产品的路径要短」这句话。其实我想表达什么意思呢？你的产品和用户要靠的非常近，尽量缩减中间环节，减少不可控环节的依赖。比如，通过一款产品解决人们看病的问题，的确是很多人的梦想，但是那需要太多支撑技术，遥不可及。远不如针对个别场景解决一个基本问题来得实际。

比较长的产品路径会有什么问题? 举个例子，假定你是一个创业者，从种种渠道的信息你断定健康信息管理市场潜力巨大。开发了一款小型电子设备，这个设备可以测量收集个人的健康数据信息(我们从各种报道中经常看见此类产品上市的消息)，然后通过手机或者无线网络再传输到你的服务器上，然后… 听起来这是个很好的创意，健康数据多么值钱… 进行医疗分析或者辅助治疗，激动人心。且慢，这样的产品路径太长了。首先，你的设备制造就要考虑很多事情，设计、外包生产，然后，最起码做数据接口，各种设备得适配，再然后，要有渠道去推销给人们使用这个设备，用户毕竟不会飞来(能说服他们买单?)，还需要有很好的售后支持…这其中任何一个环节对创业团队来说，要控制好，成本都太高了，而且，链条太长，也注定无法快起来。

所以，我建议创业团队做产品，路径必须要短。拥有简短路径的土鳖产品，也比华而不实的靠概念堆砌起来得产品更有价值。当然，凡事都有反例，但别用反例来反驳了，有些朋友会想起苹果公司，毕竟苹果的成功目前来看，还是不可复制的。这也是我不太看好一个电子商务巨头去进军手机市场的理由。

补充一点，做产品，也不要绕路绕的太远。比如，你发现有的用户在你的电子商务平台上进行欺诈，于是乎，投入大量人力物力研发反欺诈技术手段，过了一段时间，发现效果不显著，反欺诈工具无效? 提高技术研发力度?… 当然，也是治标不治本。正所谓，为了一根香肠，没必要去买一头猪或是养一头猪，更没必要去开养猪场。甚至，你需要的那根香肠可以用其他食品替代。

–EOF–
Updated: 就这个话题延伸一下，一个传统企业(比如某些医药企业)试图打造的自己某个产品品牌的在线社区也无疑是徒劳的，要么是拿钱打水飘，要么做成了「体外循环」，背离初衷。比较合适的方式？借助已经成熟的社区，事半功倍。毕竟，你只是想拉近和用户的距离，宣传品牌，培养忠诚度，但没必要总把用户拉来你家打牌吧？

文案的力量

文案对于互联网产品的作用，就好比路标对行路人的作用。清晰无误的文案带来的效果有的时候胜过胜过数百行代码。和百姓网的朋友交流的时候谈到他们的一个真实案例：付费产品的转化率始终始终无法提高，后来产品人员在表单下面添加了一小行文字，意想不到的是，转化率增加 20% 多；最近丁香园的某个产品改进过程中也有一个相似的例子，功能本身没有改变，只是增加了一行文字提示，结果? 询价量大幅上升。

我无意夸大这两个案例有多么神奇，而想强调的是，我们可以通过一些成本最低的改进来改善我们的产品，那就是，写更好的文案。

差的文案有什么影响? 举个例子吧，糟糕的路标有的时候让人恼火，比如北京地铁最早用东西南北做出口的标记，你可以想一下有多少人在地铁里能分清方向? 这是一个经典反面案例；而支付宝当年因为证书问题导致用户修改信息陷入「死循环」，其实也是加一行文字就能避免用户多次重试；再想想我们经常遇到的「您提交了非法请求」、「提交的表单无效」之类的让人莫名其妙或是哭笑不得的提示信息吧……

国内的互联网创业公司似乎并不怎么重视产品文案的力量(当然当下多数人也不重视文字的力量)。有些团队喜欢在技术和数据分析上猛下功夫，但是不知道，用户有的时候在一堆功能前一头雾水的主要原因就是你的文案写的不够清晰。好的文案样本可以看一下豆瓣的，清晰直接，一目了然。每次豆瓣发布新产品或是改版，我都要仔细学习一下豆瓣产品经理的文章，比如这篇豆瓣的初衷，在国内互联网产品团队中堪称无出其右。

国外的互联网创业公司相对来说，更重视写作能力，看重文字，比如 37 Signals 一以贯之的实践，甚至在《重来》这本书中写到「会写就代表会思考」，并且建议「如果你准备从一堆人挑出一个人做某份工作，那就挑文章写的最好的那个」，我个人很赞同这个观点。接下来，在团队成员的招募过程中，必须要加强对候选人写作能力的要求，这也是丁香园团队目前做的很不好的一块。据说俞军在百度招产品经理的时候就让应聘者写一份产品分析文档，不知道这里面有多看重候选人的文字方面的能力。

一个优秀的产品人员应该关注文案、写好文案，重视文案的力量，文案不只是对网络编辑的要求，产品经理、工程师，同样应该重视。我们常说重视细节，其实文案、文字，同样是细节。

注意：以上所说的「文案」，单指互联网产品的「文案」，不是指广告公司面对的那种「文案」。

–EOF–

游击队 vs. 军团作战

在过去一段时间发现，一些大的互联网公司，比如 Amazon、Google、Facebook、Tencent，已经非常倾向于「游击队」作战模式，也即启用技术小团队，快速灵活、便于沟通；而不是动辄几百上千人攻关大项目，我知道淘宝以前有「上万人天」的大项目。

比如，亚马逊 CTO Werner Vogels接受访谈时透露：「亚马逊就建立了很多的技术小团队，每个团队基本上都是 8-10 个人，这种团队的灵活性体现在，当有了新的想法马上就能够行动起来，而且沟通简单，不需要开很多会议才能把事情说清楚」，「这些技术小团队围绕的是亚马逊提供的各种服务，比如购物、推荐系统、甚至评论服务。」

而 Facebook ，公司已经形成了「特别认可小团队」的文化，「It’s important to understand that, at Facebook, we believe in particularly small teams」(refer), 绝大多数项目最多六七个人。

至于 Google，施密特曾有一次在接受采访时表示，「我们的成功产品都是由反应快的小团队开发的」，即使 Google+ 这样毕其功于一役的项目动用了超过 500 人，但「Circles 的设计是由一个人主导的。团队约为5-10人，他们在通用平台上做彼此的工作」

至于腾讯，从对张小龙的采访可知一斑。甚至去年的明星产品微信，团队也并不大，「微信第一批成员不到十人」(refer)。

我不厌其烦的举众多例子，是无意陷入到争论中(至于软件行业的朋友，就更没必要来抬杠了)。这些信息或许给我们一个启示: 游击队模式或许是个好方法。毕竟，军团作战，我是说几十乃至数百上千人的协同开发，实际上给协调和沟通带来了相当大的挑战，与其投入昂贵的管理成本，不如反其道行之，让这些问题不存在。

从我过去一年中的实践来看，收效不错。作为一个管理者，应该尽量克制投入军团作战的野心，尽管「小即美」的道理浅显易懂，但跳出思维定势似乎不那么容易。对于创业团队，人手本来就少，更是应该将单个开发小组尽可能的缩小，两三个人一个小组，效率应该会非常好，而且，创业团队几乎不存在「基础设施集中与否」的问题。

–EOF–