为什么 Stack Overflow 会如此成功?

最近问答类网站相当的热门。说起问答(Question & Answer)网站,很多人会第一反应想起 Quora ,实际上,这类网站中 Quora 并非做的最好的(但或许是借了 Facebook 的风头),最为成功的要数 Stack Overflow 。更为准确的说,是 Stack Exchange Network,Stack Overflow 现在只是 Stack Exchange network 的子站点而已。

Stack Overflow 由 Jeff Atwood 和 Joel Spolsky 这两个非常著名的 Blogger 在 2008 年月创建,7月小范围的进行 Beta 测试,直到 9 月份才开始公开的 Beta 测试。Joel Spolsky 大家应该熟悉,国内已经引进了他的数本大作,影响力最大的应该是《软件随想录》,此外,Joel 还拥有 Fog Creek 这家运转得不错的软件公司;Jeff Atwood 是著名技术技术 Blog Coding Horror 的作者。有趣的是,这两个人过去还 打过嘴仗。Stack Overflow 面向编程人员群体,在其推出一年之后,又推出了面向系统管理员的 Server Fault ,2009 年8月正式面向一般计算机用户的 Super User。用这个方式不断进行横向扩展,到现在为止, 旗下已经有 43 个问答站点,甚至包括英语和烹调这样的主题。到2010年年末,Stack Overflow 单个站点在 Alexa 的 Rank 是 160 ,月度独立访客超过 1600 万,每月Page View 超过 7200 万 (refer)。Stack Exchange Network 在 2010 年 5 月接受了来自 Union Square Ventures 的 600 万美元的投资,在 2010 年扩大并完善了整个团队,从三个全职工程师发展到了 20 多人的队伍,搬进了 7500 平房英尺的豪华装修的办公室(当然每个人都坐着1000美元一把的椅子)。从各项指标来看,同样作为 Startup,Quora 距离 Stack Overflow 的还差得很远,虽然拿到了更多的钱、吸引了更多眼球。

StackOverflow_vs_quora.png

Stack Overflow 为什么会如此成功?

你当然可以说是众包(Crowdsourcing)的功劳,但哪一个成功的社区能少了众包的功劳呢?如果实际一点说,不可或缺的因素我想是两个创始人的技术和社区基因。作为两个著名的 Blogger,没有人会质疑 Joel 和 Jeff 在 目标用户(开发人员)需求的精准把握。何况在上线前后,Jeff 通过技术社群又进行了大量的调研和反馈(Joel 倒是似乎第一次做 Web 项目,Fog Creek 主要是软件开发)。此前市场上已经有 Experts-Exchange 之类的老牌产品,Stack Overflow 则反其道而行之(Anti-Experts-Exchange),作为技术人员,你一定遇到过搜索技术问题到了 Experts-Exchange 网站,但是你发现问题下面并没有合适的解答,仅仅有人提问,但是没有有效的激励回答者则是没有价值的。Stack Overflow 参考 Reddit 等网站的用户激励机制,关注问题质量,其做法是通过威望值(Reputation Point) 与徽章(Badge) 建立起信任评价体系,并且做到对参与者的有效激励。我是否说过技术人员都是”好面子”的?没有,那么现在记住这句话吧。

此外,秉承独特的设计理念。Stack Overflow 绝对没有多余的或是跟风的功能(比如一些不必要的 Social Network 特性)。如果看过 Joel 的书或是订阅他的 Blog,你应该知道他是个相当偏执的家伙,尤其是在产品设计方面,他认为对的事情绝不会妥协,参见他在《软件随想录》中的《别给用户太多选择》以及《用软件搭建社区》等章节。我不知道究竟团队在功能设计上是怎么分工的,但 Joel 一定是毫无质疑的植入自己的设计理念。另外要补充的是,Stack Overflow 重新将”标签”化腐朽为神奇,也是相当值得称道的。

横向的业务扩展模式。与 Quora 综合性的问答不同的是,Stack Exchange network 采取攻其一点,再进攻其余的方式。在面向开发人员的 Stack Overflow 获得验证并且成功之后,向类似话题领域扩展;然后与不同团队进行合作,逐渐引入更多的主题(比如 Ubuntu、面向物理学的话题等等)。最后,如果把几十个话题合起来,恰好是一个庞大的 — 论坛。Stack Overflow是否重新”改造”了论坛这个古老的交流模式?

技术?是个关键因素,但不是主要因素。作为 Startup,罕见的使用微软了技术体系进行开发,但也用开源软件。观察 Stack Overflow 所用的技术方案,会觉得是个大杂烩,除了 C# 、ASP.net 、SQL Server 等,也有 HAproxy、Redis 这些解决方案。 据 Joel 说,效率和成本也还不错。扩展模式上则首选 “Scale Up”, 总之,就是有点特别。但是,用户体验相当好,这个是最难模仿的一个地方(另一个是运营套路)。

或许,Stack Overflow 的成功因素不止这些,你认为呢?

补充,来自霍炬 (@virushuo) 的观点:首先工具本身非要重要。有足够好和专注的工具。其次,种子用户非常重要。So,小范围测试的时候奠定了基础,之后始终按照这个确定的方向积累。

补充, Joel 的说法是”push for high-quality content and its decision to segment the service into well defined verticals”。

延伸参考:

EOF

此文作者:, 位于 Startup 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Facebook 如何发布代码 (How Facebook Ships Code 译文)

按:这篇 How Facebook Ships Code 提供了大量的细节信息,之前已经有朋友提供了一个翻译版本,阅读之后发现有些许错误,并且原文有更新,所以基于前面的翻译版本我重新翻译了一个(完整的)版本。一并谢过。希望这个版本对大家也有所参考。

我对 Facebook 的运作方式着迷。这是个非常独特的环境,很难被复制(这个方式并不适合所有的公司,即使有些公司尝试过这么做)。下面这些笔记来自我和Facebook的许多朋友的交谈,关于他们开发、运维与软件发布等方面。

好像很多人都对 Facebook 感兴趣… 这家公司的工程师驱动文化(Developer-driven culture)已经被公众大加研究,并且其它其它公司也在探求是否/如何实现工程师驱动文化。Facebook 的内部流程实在够神秘,当然,工程师团队也会发布一些关于新功能以及部分内部系统公开备忘,不过这些大多数是”说明”类的文章(What),而非讲述”机制”(How)… 所以,外部人员很难明白 Facebook 的创新以及如何比其它公司做到更有效的对服务进行优化。我作为外部人员尝试深入理解 Facebook 的运作,汇集了几个月来的这些观察信息。出于对信息来源的隐私保护,我去掉了特定功能/产品的名字。我又等了6个月以后才发布这些记录,所以,有些信息肯定过时了。我希望发布这些信息会有助于了解 Facebook 的管理机制如何在组织中进行决策的推行而非逐步陷入混轮…很难说这与 Facebook 的成败或是 Facebook 的产品协作相关。我相信很多面向消费者的互联网公司会从 Facebook 这个案例受益。

*非常*感谢那些帮助我整理这篇文章的 Facebook 内部的朋友们。也要感谢项 epriest fryfrog 这样的朋友,他们协助我进行对本文进行校正、编辑。

记录:

  • 截止到2010年6月,Facebook有将近2000名员工,10个月前只有大约1100人,一年之间差不多翻了一番!
  • 工程部和运维部是两个最大的部门,每个大概都有 400-500人。这两个部门人数大约占了公司的一半。
  • 产品经理(PM)与工程师的比例大约为1-7到1-10。
  • 每个工程师入职时,都要接受 4 到 6 周的 “Boot Camp” 培训,通过修复Bug 和听更资深的工程师的课程来熟悉 Facebook 系统。每次 Boot Camp 大约有 10% 的人无法完成课程而被淘汰。
  • 培训结束后,每个工程师都可以访问线上的数据库【标准课程”能力越大,责任越大” ( “with great power comes great responsibility”) 对此有阐释,另有一份明晰的”不可触犯的天条”,比如共享用户的隐私数据】。
  • [修改, 感谢 fryfrog] “Facebook 有非常牢靠的安全保障,以免有人(你可以想象内部有人有这个权限的)不小心/故意做了些糟糕的的事。如果你已经”成为”了需要别人支持的人,事由将被记录,并且有谨慎的审计。这里不允许钻空子。
  • 任何工程师都可以修改Facebook的代码库,签入(Check-in)代码。
  • 浓厚的工程师驱动文化。”产品经理基本可以被忽略”,这是Facebook一名员工的话。工程师可以修改流程的细节,重新安排工作任务,随时植入自己的想法。[评论] “本文的作者是一个产品经理,所以这个论断引起里我的注意。你看完整篇文章后会发现,很显然,Facebook 的文化实际上是拥抱产品经理的实践的,所以,不是产品经理的角色被忽略,而是,这家公司的文化看上去是想让”每个人”感受到对产品的责任”。
  • 在每月的跨部门会议上,由工程师来汇报工作进度,市场部和产品经理会出席会议,也可以做些简短的发言,但如果长篇大论的话,将如实反馈给他们的主管,”产品人员在上次会议说的太多”。他们确实想让工程师来主导产品的开发,对自己的产品负责。
  • 项目需要的资源都是自发征集的:
  • 某个产品经理把工程师们召集起来,让他们对自己的想法产生兴趣。
  • 工程师们决定开发那些让他们感兴趣的特性。
  • 工程师跟他们的经理说:”我下周想开发这5个新特性”。
  • 经理会让工程师独立开发,可能有时会让他优先完成一些特性。
  • 工程师独立完成所有的特性 — 前端 JavaScript/后端数据库,等等所有相关的部分。如果需要得到设计人员的帮助,需要先让设计人员对你的想法产生兴趣(专职的设计师很少)。请架构师帮忙也是如此。但总体来说,工程师要独立完成所有的任务。
  • 对于某个特性是否值得开发的争执,通常是这么解决的:花一个星期的时间实现,并在小部分用户中(如1%的内华达的用户)进行测试。
  • 工程师通常乐衷致力于架构、扩展性以及解决”难题”,那样能获得声望和尊敬。他们很难对前端项目或用户界面产生太大的兴趣。这跟其他业务为导向的公司可能正好相反,那些公司人人都想做客户能直接接触到的东西,然后会指着某个特定的用户体验说,”那是我做的”。在 Facebook,后端的东西,比如 News Feed 算法、广告投放算法、Memcache 优化等等,是工程师真正倾慕的项目。
  • News Feed 因为太重要了,扎克会亲自审查任何变动。这是个特例。
  • [更正, 感谢 epriest ]”所有的代码变更都要经过强制性的代码审查(比如一个或者多个工程师)。我相信这篇文章只是说 扎克并不自己审查每一个变更”。
  • [更正, 感谢 fryfrog ]”所有的修改至少要被一个人审查,而且这个系统可以让任何人很方便地审核其他人的代码,即使你没有邀请他。提交未经审查的代码,将被视为恶意行为”。
  • 工程师负责测试、Bug 修复以及启动对自己项目的维护。有单元测试和集成测试的框架可用,但很少使用。
  • [更正, 感谢 fryfrog ] “补充一下,我们是有 QA 的,只是没有正式的 QA 组而已。每个办公室或通过VPN连接的员工会使用下一版的 Facebook,这个版本的 Facebook 会经常更新,通常比公开的早 1-12 小时。所有的员工被强烈建议提交 Bug,而且通常会很快被修复”。
  • 回复:很奇怪只有很少的 QA 或自动测试 — “大部分工程师都能写出基本没有bug的代码,只是在其他公司他们不需要这么做。如果有 QA 部门,他们只要把代码写完,扔给他们就行了” [编辑:请注意这是很主观的,我选择包括这部分内容是因为这和那些其它公司的标准开发实践完全相反]
  • 回复:很奇怪,缺少产品经理的影响和控制 — 产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的管理者搞好关系。需要大致了解技术,不要提一些愚蠢的想法。
  • 默认情况下,所有提交的代码每打包一次(周二)。
  • 只要多一分努力,终于一天会发生改变。
  • 星期二的代码发布,需要所有提交过代码的工程师在场。
  • 发布开始前,工程师必须在一个特定的 IRC 频道上候命,否则将会被公开问责。
  • 运维团队通过逐步滚动的方式进行代码发布:
  • Facebook 有大约 60000 台服务器。
  • 有9个代码发布级别。
  • [更正 感谢 eriest] “九个级别并非同轴的(concentric)。有三个同轴的阶段(p1=内部发布, p2=小范围外部发布, p3=完整的外部发布),其余六个阶段是辅助层,比如内部工具、视频上传主机等等”。
  • 最小的级别只有6台服务器。
  • 比如,星期二的代码发布会先发布到 6 台服务器上(第一级),运维组会观测这 6 台服务器,保证代码正常工作,然后再提交到下一级。
  • 如果发布出现了问题(如报错等等),那么就停止下一级的部署,提交出错代码的工程师负责修复问题,然后从头继续发布。
  • 所以一次发布可能会经历几次重复:1-2-3-修复,回到 1, 1-2-3-4-5-修复, 回到1, 1-2-3-4-5-6-7-8-9。
  • 运维团队受过严格训练,很受尊敬,而且极具有业务意识。他们的工作指标不止包括分析错误日志,负载和内存使用状态等等,还包括用户行为。比如,如果一个新的发布导致一定比例的用户对 Facebook 功能进行声讨,运维团队将查看相关指标,可能基于他们的调查停掉该次发布。
  • 在发布过程中,运维组使用基于 IRC 的通知系统,可以通过 Facebook、Email、IRCIM SMS 通知每一个工程师,如果需要他们注意的话。对运维组不做回应会被公开问责。
  • 代码一旦发布到第9级,并且稳定运行,本周的发布宣告结束 。
  • 如果一个特性没有按时完成,也没什么大不了的(除非外部依赖严重),下次完成时一并发布即可。
  • 如果被 SVN-blamed(应该指没按照规范提交代码会受到的惩罚)、公开问责(Public shamed, 示众?还是通告批评?)或工作经常疏忽就很可能被开除。”这是一个高效的文化”。不够高效或者不够聪明的员工会被剔除。管理层会在 6 个月的时间里观察你表现,”你不能适应这种文化,只能说再见”。每一级都是这个待遇,即使是 C 级别和 VP 级别,如果不够高效,也会被开除。
  • [更正, 感谢 epriest ] “人们不会因为导致 Bug 而被解雇,只有在发布他们的代码时导致问题,而他们恰恰又不在场(也找不到其他可以替代的人)”。
  • [更正, 感谢 epriest] “被问责不会导致解雇。我们特别尊重别人,原谅别人。大部分高级工程师都或多或少犯过一些严重的错误,包括我。但没有人因此被解雇”。
  • [更正, 感谢 fryfrog] “我也没有遇到过因为上面提到过的犯错而被解雇。我知道有人不小心将整个网站宕掉过。一旦有人犯错,他们会竭尽全力修复问题,也让其他人得到了教训。就我来看,这种公然蒙羞与被解雇的恐惧相比更为奏效”。

分析 Facebook 的研发文化如何随着时间演化是件非常有趣的事。特别是当公司发展壮大到数千员工的时候,这种文化是否还能够延续?

你觉得如何?在你公司里,”开发者驱动(developer-driven)文化” 将会可行么?

译者后记:很多时候是管中窥豹也是非常有趣的,而且,应该细致一点儿。另外,或许我们更应该关注为什么 Facebook 能够形成这样的文化。你说呢?

译者后记续:Facebook 能形成工程师主导的文化,应该和 Facebook 的产品形态有很大关系。毕竟 Facebook 人人都会用 Facebook … 换言之,如果是 Amazon / eBay 这样面向商业的用户的公司,业务逻辑会让工程师陷入五里雾中。

EOF
延伸阅读:Hacker News: What I Learned from Zuckerberg’s Mistakes

此文作者:, 位于 Arch 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

年度技术回顾之数据库、NoSQL、开源软件

本文已经首发于InfoQ中文站,版权所有,原文为年度技术回顾之数据库、NoSQL、开源软件,如需转载,请务必附带本声明,谢谢。

InfoQ中文站是一个面向中高端技术人员的在线独立社区,为Java、.NET、 Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如QCon、免费迷你书下载如《架构师》等。

年终岁尾,做个总结吧。要说过去的这一年,起码国内的技术会议多了很多,甚至是几千块的门票也有市场了,可能也是物价上涨的副作用?像 QCon(Beijing)、SD 2.0 、微博开发者大会、TUP、UCD 年会、D2 年会、Verlocity(Beijing) 等会议,参会人都非常踊跃甚至有些会议一票难求,这是好现象,相信 2011 年有更多有价值的会议值得我们参加。再说说技术方面的事儿吧,下面是我的几个关注点。

数据库

Oracle RDBMS 、SQL Server 、DB2 等几大商业化产品似乎没什么值得一说的事件。Oracle 公司收购 Sun 之后,MySQL 前途曾一度堪忧,现在看起来 MySQL 生命力依旧顽强,只是在今年开发节奏明显慢了不少,也或许是 Oracle 在调整节奏,不过 5.5 版本的发布还是让不少 DBA 颇为惊喜,除了 InnoDB 成为默认的存储引擎之外,其他的一些特性倒是差不多都来自技术社区的反馈或是驱动,比如来自 Google、Facebook 的改进,多少对新的 MySQL 特性产生了一定影响。值得注意的是,这一年中 PostgreSQL 发展相当的迅猛,随着 9.0 的发布,引入了更为高级的复制技术,弥补了功能上的一个短板,MySQL 的命运多舛给 PostgreSQL 带来了契机,令人感慨。以前我期待的 SSD 虽说已经逐渐成熟,但似乎没有像预期的那样对数据库软件带来更大的影响。

NoSQL

去年的回顾文章中我说到 “就数据管理方式的趋势来看,NoSQL在将来会成为一个非常重要的数据解决方案”。一年之后,NoSQL 的确已经成为网络架构中一个基础的组成部分了。涌现出来的 NoSQL 相关的产品,最成功的要数 MongoDB,在新型 Startup 中颇为流行,赢得了不少创业技术团队的青睐 (比如,引领创新潮流的 LBS 先驱 FourSquare就是采用的 MongoDB ,尽管为此吃了不小的亏 ),创建 MongoDB 的 10gen 技术团队甚至在年底拿到了红杉的风险投资。除了 MongoDB 之外, Redis 的发展也不错。来自名门大厂的 Cassandra、Dynamo、CouchDB 等产品的发展倒是稍显平淡。作为 MySQL 的 NoSQL 插件出现的 HandlerSocket 的让人感到惊喜。这个技术方案会给很多应用场景带来新的契机,相信新的一年会有很多技术团队大胆的采用 HandlerSocket。其它几个 DB,似乎到现在仍没有类似的解决方案出现。

我有一个猜测是 Redis 从 VM 转向 Diskstore 模式后,有可能超越 MongoDB 么?

开源试水

Yahoo! 发布的 S4 不出意外的话,极有可能成为 Hadoop 那样有影响力的项目,对于实时计算领域会带来极大的冲击 。相信今年国内会有用户进行尝试。LinkedIn 开源的 Kafka 也有必要关注一下。针对招聘类网站会有一定的借鉴意义。

2010 或许可以称之为中国互联网企业回馈开源领域的试水之年。先是淘宝网开源平台,淘蝌蚪 (code.taobao.org) 的上线并且推出分布式 Key-Value 存储及高性能缓存系统—-TAIR,随后开放了淘宝文件系统以及 WebX 框架,足见诚意。說起 WebX,人人网也发布了自己的开源 Web 开发框架 Rose。然后有盛大创新院开源哼唱检索引擎,随后在互联网口水大战尘埃落定之后,金山的启动金山卫士开源计划,甚至百度也发布了 JavaScript 开发框架 Tangram –喊了一年终于开源了一个产品出来,颇为不易阿。而淘宝系的前端工程师们的开源项目 KISSY 发展也颇为迅猛,推荐关注。更早一些的开源项目,豆瓣的 BeansDB 在年底进行了大幅度更新,再次引起技术社区的注意。此外,射手播放器作者沈晟发布的基于MongoDB的短网址分支项目 SESO 也很有意思,希望能继续发展下去。基于 Key-Value 的开源产品多了不少,天涯也开放了一个 Memlink

以团队为单位进行的产品开源,很容易变成一个只是”公开代码”的项目,开源,还应积极鼓励技术团队成员积极的与技术社区互动,输出更多文档,用更多的案例支撑,这样才能相辅相成,才能取得真正的收益。否则的话,容易被看成为了开源这个”名”而开源,有始无终。

期待在 2011 年,腾讯能在开源领域做点表率?还是网易开源一个游戏引擎呢?只有拭目以待了。也期待国内互联网企业能积极支持开源社区,不要只顾着开源自己的那几个产品。开源比封闭更值得欣赏,心态也比姿态更为重要。

说到开源,顺便说一下”开放平台”,2009年喊着做开放平台的各大网站,现在已基本偃旗息鼓,国内这一年中也没有一家将所谓的”开放平台”真正的做起来,倒是经过一年多的铺垫,新浪以微博为基础的的应用平台已经具备了一定的潜力和规模,2011年值得期待。如果说开源,看的是心态,那么,开放平台,则看的是企业的心胸。

2011 做点什么?

眼看着越来越多的解决方案,越来越开放的技术分享,不由得让人生疑:架构是否已经不再重要?其实,构建一般中到大型的站点,已经没什么秘密技术可言(比如,还有人一度放出来”腾讯大讲堂”这样的内部信息资料,颇为戏剧性,但大家看了之后也就是新鲜几天而已,网络中更有价值的信息已经是比比皆是了)。重要的是如何用成熟的技术将产品做好,加快开发节奏,更快改进产品质量。

所以,对我自己而言,新的一年重要的还是回归基本技术,和团队一起将丁香园( http://dxy.com )的产品做好,”望着天上的星,也要看着脚下的坑”,关注新东西,更要避免因为技术冒进造成不必要的人力物力浪费,说起来容易,真的做起来,怕是也没那么简单。

EOF

此文作者:, 位于 OpenSource 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Movable Type 是如何被 WordPress 超越的?

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

movable-type-logo.jpg
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 落败的第一个原因:错误的时机采用了错误的收费策略

MT_vs_WP.jpg

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 吸引了开源社区的力量

wordpress-registered-trademark.png

如果说语言决定运势,似乎有些技术巫婆的味道。Ben Trott 用 Perl 语言开发的 Movable Type ,而 WordPress 则是用 PHP 进行开发。很不幸的是,Perl 差不多是过去 10 年最让人扼腕的一门语言,从 Perl 5 之后一直停滞不前,直到去年 Perl 6 才姗姗来迟,Perl 没有凤凰涅槃,终究彻彻底底的成为了一门小众语言。Perl 功能超级强大,但有个相当大的弊端,那就是一个人写出来的程序,换一个人很难读懂。这意味着 Perl 写出来的 Movable Type 很难借助于群体的力量而继续改进,终究将 MT 变成属于小众群体的工具。2003 年的时候,PHP 还不够先进,但是 PHP 一直在迅速进化,而 PHP 用户群也越来越大,PHP 语言越来越流行2。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 的 静态(3)页面发布功能依然是一个不可替代的优秀特性,虽说 WordPress 启用了 Cache 之后,MT 这一点已经不具备多大的优势了。当然,难以割舍的还有习惯和一种别样的感情,所以,至今国内仍有不少出色的网志是构建在 Movable Type 之上的。

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

Movable Type is Dead, Long Live Movable Type.

EOF

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

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

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

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

此文作者:, 位于 Review 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.