Question

互联网软件带来的最大变化之一，就是软件发布方式的改变。对于桌面软件来说，发布新版本是一个很痛苦的过程，整个公司不得不使尽全力，满头大汗地挤出一大块巨型代码。从过程和结果上来看，无异于一次分娩。

互联网软件则完全不同，就像你写给自己用的程序一样，修改起来很方便。软件的发布过裎可以分解为一系列的渐进式修改，而不是猛地推出一个大幅变动的版本。常见的桌面软件可能一年发布一到两个新版本，而我们在Viaweb经常是一天发布三到五个版本。

一旦采用了这种新模式，你就会知道发布方式对软件开发的影响有多么重大。桌面软件开发之中的许多棘手问题，都是源自于它的那种灾难性的发布方式。

如果一年发布一个新版本，你很可能会以打包方式处理bug，把它们留着，然后一次性全部解决。在发布新版本前，你可能会修改和更换一半的代码，从而又引入无数新的bug。接着，质量监控人员（Quality Assurance）开始测试新代码，逐一列出新发现的bug，你再按照这张清单把它们一个个消除。通常没办法把清单全部做完，它随时都在增长，说实话，谁也不确定它到底会有多长。这就好像在足球场上捡小石块一样费劲，你永远不知道为什么软件内部会出这么多问题。最好的结果也不过是，你得到了一个统计学意义上“合格”的版本。

对于互联网软件来说，大部分的变化都是细微和渐进的，所以引入bug的机会比较小。而且，在发布前测试的时候，你知道应该最仔细地测试哪个部分——显然就是你修改过的部分。这使得你对代码的掌握变得牢固得多。一般来说，这时候你确实是对软件内部的情况一清二楚。当然，这不是说你把所有代码都装在了脑子里，而是说你阅读代码的时候，非常自如流畅，不会像侦探破案那样苦思冥想，而是像飞行员那样，瞄一眼仪表板，就对飞行状况胸有成竹。

桌面软件导致了bug的宿命论。你很清楚，发布出去的软件肯定有bug，你甚至早就准备好了应对机制（比如发布补丁）。既然如此，bug再多一点又何妨？没过多久，你要发布下一个版本了，你明知其中某个操作完全不能使用，但还是照样发布。苹果公司前几年就干过这种事。他们必须发布新版操作系统了，压力越来越大，发布日期已经推迟了四次，无法再推了，可是有些部分还一点儿没写（比如CD和DVD操作的部分）。怎么办？他们就把没写完的操作系统发布出去了，用户必须日后自己动手安装缺失的部分。

互联网软件的发布规则是：它运行不了，你就无法发布；一且它能运行了，你就可以立刻发布。

这个行业的老手可能会想：你说得好听！软件运行不了，就不发布，但是如果你已经对外承诺了明确的发布日期，到时却没有准备好，怎么办？这个问题听起来有道理，但是事实上，你不会对互联网软件做出这样的承诺，因为它根本没有“版本”这个概念。你的软件是连续性渐变的，某些更新也许比较重大，但是“版本”这个概念不适用于互联网软件。

如果你还没忘记Viaweb的旧事，你可能会觉得我这么说听上去很奇怪，因为那时我们总是宣布将有新版本推出。这只是公关伎俩啦，我们知道媒体喜欢听到版本号。如果你发布一个大的版本更新（版本号的第一位数发生变动），它们就会以大篇幅报道；如果你发布一个小的版本更新（版本号小数点后发生变化），它们最多只用一段话提一下。

我们的一些竞争对手的产品是桌面软件，确实有版本号。对我们来说，这种发布方式只表明他们的落后，但是他们却因此把媒体的目光都吸引过去了。我们不想做局外人，所以也开始为自己的软件加上版本号。什么时候需要媒体宣传了，就开出一张单子，上面总结了自从上次“发布”以来，我们新增的所有功能，然后在上面填一个新的版本号，发出一个新闻稿，宣布新版本已经准备就绪了。真是神奇啊，从来没有人看穿我们的把戏。

到被收购的时候，我们已经这样干了三次，所以已经到了第四版。如果我没记错的话，那时是4.1版。Viaweb变成Yahoo Store以后，媒体的曝光就没有那么必要了。所以，虽然软件一直没有中断开发，但是版本号却悄悄地被放弃了。