作者文章: Fenng

Movable Type 是如何被 WordPress 超越的?

前几天有一位网志⁽¹⁾读者发来反馈，我的个人站点文章分类的分页功能出了问题。读者的意见不能不重视，于是花了一点时间修复了一下。作为国内少数还在使用 Movable Type (MT) 作为网志发布工具的用户，处理的过程中不由使我再次涌起迁移到 WordPress (WP)的冲动，到现在 MT 甚至都不具备一个良好的原生的分页机制，不得不再次借助于第三方的插件来做到。不管承认与否，Movable Type 已经被 WordPress 全方位的无情的超越。如今的 Movable Type，已经不像当年那样被人津津乐道，甚至被 VideoEgg 收购的消息都没引起多大的反响。这是怎么一回事? 这几年发生了什么？在这个时间回顾一下，或许别具意义。

Movable Type 是如何被 WordPress 超越的？

让我们回到 2001 年，短暂无业闲暇中的 Perl 工程师 Ben Trott 为了满足妻子 Mena Trott 在网上书写的热情而创作了 Movable Type，9 月份作为个人项目发布了 Movable Type(这个单词也是”活字印刷”的意思)初始版本，10月份发布了 1.0 版本(Refer)。很快，免费（严格来说是 Donation-Ware 的版权形式）而精致优雅的 Movable Type 赢得了不少用户，引起了业界广泛注意。Ben 夫妇的夫妻店名为 Six Apart , 这个名字的由来据说是因为两个人的生日相差六天，和什么”六度分割”理论没什么直接联系。2004 年拿到第二轮融资。2003 年，Ben 夫妇二人拿到了来自伊藤穰一(Joi Ito) 的第一笔风险投资，2004 年拿到第二轮融资。资本一旦进入，情况似乎就发生了变化。在 2004 年发布的 3.0 版本引发了轩然大波，Six Apart 短视的将 Movable Type 的版权进行了调整，打算开始收费，这一杀鸡取卵的举措引来了大量用户的不满与诟病，从而使得不少用户转投当时并不成熟的 WordPress 的怀抱。到现在为止，我们似乎得到了 Movable Type 落败的第一个原因：错误的时机采用了错误的收费策略。

WordPress 的最初发展过程似乎没有什么秘密可言，在维基百科上可以找到关于 WordPress 发展的方方面面的信息。当时只有 19 岁的的 Matt Mullenweg 在 b2/cafelog 的基础上开发了 WordPress，遵循 Web 标准，于 2003 年 5 月以 GPL 版权形式发布。随后的两年中，Matt 被 CNET 雇佣，退学，在几位 WordPress 开发者的努力下推出了 1.5 这个重要的版本，2005 年 Matt 从 CNET 离职而全力投入 WordPress 项目，正式成立了 Automattic，随后发布了 Akismet 项目(用以对抗垃圾信息)， WordPress.com 相继正式对公共开放，看起来似乎是无心插柳柳成荫，其实是很大程度上依靠着开源社区的力量驱动。而 Movable Type 的版权形式让用户心怀芥蒂，直到 2007 年，Six Apart 才重新修改版权形式为 GPL (GPLv2) 。这个时候已经无法改变什么了。这几年中，Movable Type 几乎没有什么革新的功能出来，版本 3 和 Spam 较劲了许久，然后 4.0 解决了 Spam 问题后则是跟性能问题斗争，现在的版本 5 倒是有些中规中矩，只是时不我待。WordPress 的开发者分为 Lead Developer、Contributing Developer、Developer ，这种形式更能激发贡献者的热情，形成了一个相对更为健康的结构，而对于 Movable Type ，即使在开源后也几乎找不到这样的结构，只是知道目前日本的 Perl 技术社区承担了很大一部分开发改进工作。如果要总结一下 Movable Type 被 WordPress 超越的第二个原因：WordPress 吸引了开源社区的力量。

如果说语言决定运势，似乎有些技术巫婆的味道。Ben Trott 用 Perl 语言开发的 Movable Type ，而 WordPress 则是用 PHP 进行开发。很不幸的是，Perl 差不多是过去 10 年最让人扼腕的一门语言，从 Perl 5 之后一直停滞不前，直到去年 Perl 6 才姗姗来迟，Perl 没有凤凰涅槃，终究彻彻底底的成为了一门小众语言。Perl 功能超级强大，但有个相当大的弊端，那就是一个人写出来的程序，换一个人很难读懂。这意味着 Perl 写出来的 Movable Type 很难借助于群体的力量而继续改进，终究将 MT 变成属于小众群体的工具。2003 年的时候，PHP 还不够先进，但是 PHP 一直在迅速进化，而 PHP 用户群也越来越大，PHP 语言越来越流行²。WordPress 尽管开始粗糙，但是经过不断的改进后最终变得功能强大甚至完美。很多国内 Blogger 应该记忆犹新，选择 Movable Type 的话，必须要找能够支持 Perl 环境的虚拟主机，而虚拟主机支持 PHP 则几乎是”标配”。语言的选择决定了一个产品的基因，从某种程度上也决定了产品的命运。这是两种技术文化的碰撞，这是 Movable Type 被 WordPress 超越的第三个原因：选择 Perl 是一种错误。

Six Apart 步步抢得先机，却总是被后发的 WordPress 超过。Six Apart 在 2003 年就正式推出了 TypePad 这个 Blog 托管平台，远比 WordPress.com 起步早。做平台，非常关键的一点是需要一个好的生态来维系。Movable Type 想从软件 License 中赚钱的想法实际上已经注定了构建不出这样相对开放的生态。而 WordPress 则不然，始终坚持开源，团结技术社区。WordPress 逐步发展成为最流行的网志发布工具，而广泛的用户群则给 WordPress 带来了大量有价值的反馈，技术爱好者则进一步贡献了数不清的插件，很多用户因为 WordPress 有着这么多的插件而放弃 Movable Type，也难怪，到现在 MT 还没有一个合适的插件让用户很方便的显示相关文章，而 WordPress 下面类似的插件比比皆是，只是有的写的糟糕，有的写得精致而已。不难看出，WordPress 走了一条农村包围城市的路线，逐渐培养了大量的基础用户。时至今日，WordPress.com 是全球前 20 名的网站，而 TypePad 排名是 200 左右。 Movable Type 被 WordPress 超越的第四个原因：WordPress 构建了一个更好的产品生态，进而培育了一个成功的平台。

关于”生态”，我想说一下国内的一些开源产品，比如 Discuz!，较少得到来自技术社区的贡献，说是开源，仅仅是把代码公开，缺乏与技术社区良好的互动，形成不了良好的技术生态。

不知是不是 Ben Trott 最初单枪匹马写出来的 MT 的缘故，Six Apart 团队另一个特别的地方是没有出现有影响力的技术明星。在 2005 年，Six Apart 收购了 LiveJournal 背后的公司 Danga 。Danga 这个技术团队在 Web 2.0 历史上是值得纪念的，给业界贡献了 Memcached 、MogileFS 这样经典的开源产品，让无数创业团队受益，相信今天很多公司都在使用 Danga 团队开源的产品或是从 Memcached 中借鉴了 Key-Value 产品的设计理念。甚至那篇 LiveJournal’s Backend 也给了国内很多技术人员以启迪，我甚至认为这是 Web 2.0 技术大潮中最重要的 PPT 之一。遗憾的是，Brad Fitzpatrick 这位大牛没多久就离开了 Six Apart ，加入了 Google。这一次收购似乎没有给 Six Apart 带来什么。除此之外，业界很少有优秀的 Perl 为主导的技术团队了。后来， Six Apart 又有几次收购，似乎也都是为了技术团队而进行的。反观 Automattic ，迄今为止只进行过两三次收购而已，而且都是为了完善 WordPress 产品功能。第五个原因，Six Apart 的收购没有做到价值最大化。在雅虎的收购上我们也看到了类似的失败的做法。

抛开这两个产品的其它方面不谈，一个成功的产品和一个走向没落的产品之间的差异是一点一点产生的。我们能看到结局，但回到 2001 年的时候，没有人能预料到这些。当然，今天的 Movable Type 绝非一无是处，尤其是模板结构，现在也要比 WordPress 优秀，但是没办法，WordPress 好的模板主题更多。另外，MT 的静态⁽³⁾页面发布功能依然是一个不可替代的优秀特性，虽说 WordPress 启用了 Cache 之后，MT 这一点已经不具备多大的优势了。当然，难以割舍的还有习惯和一种别样的感情，所以，至今国内仍有不少出色的网志是构建在 Movable Type 之上的。

两个产品似乎从没剑拔弩张相向过，但我想 WordPress 至少是将 Movable Type 作为一个对手并一步一步将其超越的。我知道，作为 Movable Type 或是 WordPress 忠实用户的你，一定还有其它看法。

Movable Type is Dead, Long Live Movable Type.

–EOF–

注1: 为了纪念过去的一些原则上的争论，这里”Blog”一律译作”网志”。

注2: 关于 Perl 和 PHP 的那一段言论会引发争论。请原谅我的偏见和无知吧。

注3: MT 的静态发布，对于单个页面的访问，Web 服务器来说减轻了压力，但是对于需要频繁交互的应用需求，比如类似留言这样的操作，MT 就太慢了。

延伸阅读：这里有一篇老外写的分析文章，大部分观点都是类似的。

说说技术型创业团队的技术选型

看到微博上《程序员杂志》在征集”一分钟先生”的话题：如何做好公司/团队的技术选型？其实大公司或者大一点的团队选型几乎不需要太多讨论的 — 最后会不可避免的绕到技术官僚的话题上去。这里我想简单说说技术型创业团队技术上的选型问题。

拥抱开源技术

如果只能选择微软的技术路线，比如团队几个人只会用微软的技术做开发，甚至也不想学别的，那么似乎没有别的办法，将就一下吧。如果还有的选择，尽量选择使用开源技术。这样的好处是你不但可以有效的降低软硬件成本，还有更多的部署方案供选择，服务器上线甚至还能避免病毒的侵袭。开源技术的好处是出了问题，你总有办法可以找到答案，避免再次犯类似的错误。而用了微软的产品之后，可能平时不出问题，但一旦出了问题，你根本没什么办法，实际上，微软的产品使用门槛倒是低，但是复杂度可是一点都不小，而且随着发展，成本越来越高。国内有几个大中型网站，比如天涯、5173、大众点评、京东等，怕是深有感触吧，有的因为成本太高而继续被捆绑在贼船上，有的则破釜沉舟要摆脱这种束缚，但不管怎么说，总要付出一定的开销才可以掉头了。

好了，恭喜你选择了红色药丸，现在选择开源技术路线了，离开了微软的专卖店，进入到一个超级庞大的百货商店，这里还有数种分支供你选择呢，然后怎么办？选择大路货，选择可以掌控的技术产品，开源语言、开源程序、开源框架，乃至开源的解决方案。比如 PHP，比不上 Ruby 阳春白雪，但是用户基数大，你总能找到不错的工程师。PHP 虽然粗糙，但是管用。以 PHP 作为开发语言的成功产品不计其数，甚至很多东西根本不需要你再开发了，稍加定制即可使用。技术本身没有高下之分，差别在于使用技术的人。

Note：Paypal 和 X.com 合并之后，果断的将整个架构从微软的平台迁移到 Unix 平台；用微软技术体系构建的 MySpace 至今还在用微软的平台，被全面使用开源技术的 Facebook 短时间内全面超越。技术体系的选择是成功与否的唯一因素么？肯定不是。但至少是因素之一吧。

避免过度炫技

技术人员创业最容易犯的一个错误就是”炫技”。什么新用什么，使用最时髦的开发语言、部署的软件产品、调试最新版本的开发工具… 没错，用最新的东西容易给技术人员以满足感，但也很快会将你的时间资源消耗进去，除非你准备做的是一款基础产品。否则的话，你要花时间去学新的规范、熟悉新的功能、对付新出现的软件BUG… 可是这时候，最需要你做的是开发你要开发的产品，而不是捣鼓其它东西。一些新的技术或者方案，可以花一些时间分析一下但没必要立刻就用，确保将来有一天能真的使用上的时候，对一些重大的陷阱或是缺陷能够了然即可。

很多人神往 37Signals 的成功，但你一定要知道类似 37Signals 的团队，默默无闻的夭折掉的不知道有多少。每当我看到创业团队的就那么一两个人还整天在捣鼓 Go 、Erlang 这些东西，并想硬生生的用到他们的产品中去，我就知道，这样的团队要悬了。有这些精力，有这样的能力，应该想办法尽快让技术变现，研究一下怎么改进产品，怎么给用户带来更大的价值，这些不一定用最好的技术才能做出来。想办法尽快让产品发布，尽快接受更多人给你第一轮反馈，只凭创业团队几个人闭门冥想是很难出来好产品的，有的时候，产品推出的时机比完备的功能更为重要。要知道 GroupOn 最早也不过是搭建在 WordPress 上的几个页面，而阿里巴巴网站最初也不过是一个论坛，你又何必等到所有细节都打磨好呢？

拥抱开源技术，避免过度炫技，如果技术型团队创业(做互联网)，这两条都能坚持的话，我想你已经抓住了问题的 80% 的部分，基本上你不会做太多的无用功。

再说说如何找到合适的技术伙伴，刚刚启动的时候不要直接上来就找什么技术总监、技术经理、架构师这些看起来级别很高的人，因为这样级别的人未必认同你的想法和你的现在的团队，相反，我建议找能实现你产品想法的人。找一个合作者要比找一个管理者更为重要。最后有一点必须要说一下，不要因为一个人的技术喜好而舍弃整个技术团队，在任何时候这都是很愚蠢的事情。

这篇文章是比较有针对性写的，所以不具有普遍性，路过的朋友不要挑刺。

–EOF–

Updated：留言中有网友质疑”技术型团队”该怎么定义，按照他的说法，他心目中的技术型团队应该是”天才团队”，就这样。

新的技术产业：Web Performance Optimization

在 O’Reilly Velocity China 2010 大会上，业界最有影响里的 Web 性能技术专家 Steve Souders 宣告 Web Performance Optimization (WPO) 时代已经到来。这是个颇为重要的主题演讲，要知道，Google 已经开网站载入时间纳入到搜索排名因素之中(refer)，或许 Web 性能优化，商业网站要考虑作为一项战略来对待了。

我们看一组数据（信息来源）:

Amazon: 增加 100ms 延迟将导致收入下降 1%；
Google: 400 ms 延迟将导致每用户搜索请求下降 0.59%；
Yahoo!: 400ms 延迟会导致流量下降 5-9%；
Bing: 2 秒的延迟将导致收入降低 4.3%/用户(请问，首页用个那么大的背景图干啥?);
Mozilla 将下载页时间缩短 2.2 秒之后下载量增加 15.4%;
Google Maps 将文件大小减少 30% 后请求增加了 30%；
Netflix 在服务器端启用 gzip ，页面快了 13-25%，节省了 50% 的网络流量；
Shopzilla 将页面载入时间从 7秒缩减到 2秒，转化率提升了 7-12%，页面请求增加 25%，只用一半服务器就够了

要注意，这些只是数据，实际上，我们没有办法验证这些数据的真实性。但是可以肯定的是，网站访问速度过慢，一定对用户有负面影响。严重一些的，国外有 Friendster 因为网站访问过慢而导致的用户流失可以作为前车之鉴；网站访问速度快也可以增加竞争优势，比如Tumblr 一骑绝尘而将竞争对手 Posterous 甩在后面。国内这方面的例子比如优酷，斥重金改进用户访问速度，很大程度上保持了竞争优势。

相比投资在硬件上，我个人认为技术团队在 WPO 上的投入是可以用来评估团队技术能力的。有一次在和一位投资人聊起国内的分类网站哪个技术团队更具优势，我毫不犹豫的说看好百姓网，为何？访问一下同类网站，比较一下最终页面访问速度就知道了。这是体现一个技术团队意识和能力的地方。

当前最需要 WPO （甚至有些落后的) 的可能要数电子商务网站以及那些依托于大型 C2C 站点上的网店了。很多电子商务网站负责人非常重视 SEO，但在 SEO 已经快成为一种伪技术的今天，被忽视许久的 WPO 更应该引起重视。举例来说，可能绝大多数淘宝上的大卖家都不懂 Web 相关技术，当然也就无所谓什么 Web 性能优化了。我曾经见过有的卖家首页上一个页面放置几百个图片，一个页面动辄 7-8 Mb，用户访问速度可想而知，如果用户正常浏览都无法做到的话，要想购买产品恐怕也就无从谈起了。如果能对这一部分用户进行有针对性的处理，投入产出的价值还是显而易见的。说起图片来，可能这是最影响电子商务网站访问速度的一个因素，没有针对 Web 优化的图片、过大的尺寸或是失真的压缩图片比比皆是，无疑会严重影响用户体验与购买欲望(这里推荐做电子商务的朋友不妨关注一下 Yupoo.com 专门针对用户的这个需求而推出的图片管家服务)。

WPO 的好处？增加网站营收，降低运营开销，提升访问量，进而提升竞争力。

WPO 做起来其实并没有那么难，通过一些特定的准则(比如 YSlow 14条, refer)即可取得一些卓有成效的改进。期待 WPO 能早日成为 Web 工程师必备的常识。也建议每一个技术团队的负责人应该将 WPO 作为一项战略来抓，而不是只是一两个技术人员的事情。从现在就开始吧。

–EOF–

补充：”快比慢好”，Google 把这句话作为十大价值观之一(refer)。而 Facebook 从创立至今，也一直将提升页面访问速度作为一项重要的策略。

补充一篇必读文章：WPO – Web Performance Optimization

2010 年个人总结

每年年底我会写一篇个人总结。翻看了一下去年的总结和计划，去年的计划没有列太多，主要的事情还是执行了下来。

这一年中我最大的一个变化是从支付宝离职，入职丁香园。彻底拥抱变化了一次。去年年底的时候我说期待”有点改变会出现”, 没成想真的是这么发展的。这几天有朋友问我：在丁香园工作和在支付宝工作有什么最大的不同？我回答：更有效率。小团队执行力的优势很明显，不再有那种”Analysis Paralysis” (分析到瘫痪)、让人要死要活的会议了，感觉生命延长了许多。当然，团队小，意味着资源少，要用更少的资源做更多的做事，这是个很大的挑战。不过，团队成员的协作默契到位，非常难得。

刚离开支付宝的时候，颇有怅然若失的感觉。有所得，有所失，一切都是公平的。原来的同事们纷纷有了新机会，创造了更牛的业绩，也是好事情阿，为他们高兴。来到丁香园后，几件火烧眉毛的事情，比如网站可用性、网站性能、产品的改进做的都还可以，这一点要感谢一起战斗的同事们，这帮家伙很好。当然，也有做的不足之处，这个嘛回头内部再说。另外一个小变化是从 Windows 切换到了 Mac 工作平台。加上 iPad、iPhone，在体验这几个优秀产品的同时，也让我触类旁通有了一点心得，有些用在了产品改进中。

人生不如意事十常八九。这一年生活上有了一个很大的意外情况，猝不及防，回想起来心里隐隐作痛，可能这就是我们必须要承受的吧。都过去了，希望明年能如愿一些。

这一年，抱怨少了很多，心态好像更加平和了一点点，尽管还不够–人要改变自己真的很难。

我的 2010 榜单：

年度致敬：空椅子上的那个人
年度媒体：新浪微博，尽管前有 Twitter ，作为跟随者，新浪微博还是取得了另一种突破，通过微博，我也让我做了不少事情;
年度图书：REWORK。中文翻译版本《重来》。这本书的内容契合我这个时候的状态…
年度视频：罗永浩海淀剧院演讲生活中有各种可能，坚持理想可以做到很多，老罗证明了这一点;
年度硬件：威众路由器给我带来了不少便利
年度电影：Inception 盗梦空间结构上的繁复很吸引我

2011 年的 TO-DO List：

团队建设. 2010年的团队建设还有些不到位的地方。新的一年要多花一些精力在这个上面，争取大家都能快乐的工作、人尽所长，一起感受创业的乐趣。团队成员的成长、进步要放到首位，不能涸泽而渔。还会更多的请牛人来公司做一些交流，这一点上，公司会舍得做投入；
提高效率. 团队工作效率的提升也是一个重点。内部的一些流程、过程要理清，争取做到大家都能接受这些东西，并能体会其优势所在。当然，个人效率也有必要提升；
开拓思维. 面对一个新的产业，仍然有很多需要学习的东西。多收集信息，并借鉴一些国外同业网站的优点，有效的反馈给整个团队。
寻觅人才. 丁香园技术团队仍然需要各方面的人才。要有足够的耐心，寻找创业团队的伙伴不那么容易。如果你对我们要做的事情感兴趣，为什么不联系我一下呢？
阅读写作. 在这个物价飞涨的时刻，可能读书是成本最低的一项消遣了，适当的写点东西，梳理一下自己的思路，也是有必要的。2010 写的少了，新的一年争取多分享一些。 2011，我想和这个世界谈一谈。

最后，祝愿朋友们在新的一年不再无奈的发出一些怨念，乐观一些。

–EOF–

这里有我的一份 2011 预测，仅供娱乐。