前方的另一条路
2001年9月
*
（这篇文章解释了为什么下一代软件中，大部分可能会是基于服务器的，这对程序员意味着什么，以及为什么这种新型软件对初创公司来说是一个巨大的机遇。本文源自一次在BBN实验室的演讲。）
*
1995年夏天，我的朋友罗伯特·莫里斯和我决定创办一家公司。当时，为网景公司IPO造势的公关活动正进行得如火如荼，媒体上关于在线商务的讨论也沸沸扬扬。那时，整个万维网上可能只有大约三十家真正的网店，而且全部是手工制作的。如果在线商店会大量涌现，那么就需要有制作它们的软件，于是我们决定来编写这样的软件。
在最初大约一周的时间里，我们打算把它做成一个普通的桌面应用程序。后来有一天，我们萌生了一个想法：让这个软件在我们的网络服务器上运行，用浏览器作为界面。我们尝试重写软件，使其能在万维网上运行，结果清楚地表明，这才是正确的方向。如果我们的软件在服务器上运行，对用户和我们自己来说都会轻松得多。
事实证明，这是一个好计划。如今，作为“雅虎商店”，这款软件已成为最流行的在线商店构建工具，拥有约一万四千名用户。
当我们创办Viaweb时，几乎没有人明白我们所说的“软件在服务器上运行”是什么意思。直到一年后Hotmail推出，人们才开始理解这一点。现在，所有人都知道这是一种有效的方法。我们当时的身份如今有了专门的名称：应用服务提供商。
我认为，下一代软件中的很大一部分将会按照这种模式来编写。即使是微软——这家最有可能蒙受损失的巨头——似乎也预见到了将某些功能从桌面端转移出去的必然性。如果软件从桌面端转移到服务器上，对开发者来说，这将意味着一个截然不同的世界。本文描述了作为这个新世界的首批访客，我们所目睹的那些令人惊讶的事物。在软件确实向服务器转移的程度上，我在这里所描述的，就是未来。
下一件大事？
当我们回顾桌面软件时代时，我想我们会惊叹于人们当时所忍受的种种不便，就像我们现在惊叹于早期汽车车主所忍受的一切一样。在最初二三十年里，你必须是个汽车专家才能拥有汽车。但汽车带来的好处是如此巨大，以至于很多并非汽车专家的人也想要拥有它。
计算机现在就处于这个阶段。当你拥有一台台式电脑时，你最终会学到很多你并不想知道的、关于其内部运行原理的知识。但美国超过一半的家庭都拥有电脑。我母亲有一台电脑，用来收发电子邮件和记账。大约一年前，她收到一封来自苹果公司的信，信里给她提供购买新版操作系统的折扣，这让她感到惊慌。当一个六十五岁、只想用电脑收发邮件和记账的老太太，居然需要考虑安装新操作系统的问题时，那肯定是不对的。普通用户甚至不应该知道“操作系统”这个词，更不用说“设备驱动程序”或“补丁”了。
现在有了另一种交付软件的方式，可以让用户免于成为系统管理员。基于网络的应用程序，就是在网络服务器上运行、并以网页作为用户界面的程序。对于普通用户来说，这种新型软件将比桌面软件更容易使用、更便宜、更具移动性、更可靠，而且往往也更强大。
有了基于网络的软件，大多数用户除了他们使用的应用程序之外，什么都不用操心。所有那些杂乱、多变的东西都会放在某个服务器上，由擅长处理这类事务的人来维护。因此，你通常不再需要一台严格意义上的“电脑”来使用软件。你所需要的只是一个带有键盘、屏幕和网页浏览器的东西。也许它能无线上网，也许它同时也是你的手机。不管它是什么，它都将是一种消费电子产品：价格大约两百美元，人们主要根据外观来选择。你在互联网服务上的花费将超过在硬件上的花费，就像现在电话的情况一样。[1]
点击一下，从发出到服务器返回大约需要十分之一秒，所以对于像Photoshop这类交互性很强的软件，用户可能仍然希望计算在本地桌面进行。但如果你看看大多数人用电脑做的事情，十分之一秒的延迟根本不是问题。我母亲并不真正需要一台台式电脑，而且有很多像她一样的人。
用户的胜利
在我家附近有一辆车，保险杠上贴着一张标语：“宁死也不愿麻烦。” 大多数人，在大多数时候，都会选择最省事的那种方案。如果基于网络的软件获胜，那将是因为它更方便。而且看起来它确实会如此，无论对用户还是开发者来说都是这样。
要使用一个纯粹基于网络的应用程序，你只需要一个连接互联网的浏览器。因此，你可以在任何地方使用它。而当你把软件安装在台式电脑上时，你就只能在那一台电脑上使用它。更糟糕的是，你的文件也被困在那台电脑上。随着人们逐渐习惯于网络，这种模式的弊端变得越来越明显。
这里切入的楔子尖角是基于网络的电子邮件。如今，数百万人认识到，无论身在何处，你都应该能够访问电子邮件。既然你能看到电子邮件，为什么不能看日历呢？如果你能和同事讨论一份文档，为什么不能编辑它呢？为什么你的任何数据要被困在某个遥远桌子上的某台电脑里呢？
“你的电脑”这个整体概念正在消逝，取而代之的是“你的数据”。你应该能从任何电脑上访问你的数据。或者更确切地说，任何客户端，而客户端不一定非得是电脑。
客户端不应该存储数据，它们应该像电话一样。事实上，它们可能会变成电话，或者电话变成它们。而且，随着客户端变得越来越小，你还有另一个理由不把数据保存在上面：随身携带的东西可能会丢失或被偷。把你的掌上电脑落在出租车上，就像一次磁盘崩溃，只不过你的数据不是被抹掉了，而是被交给了别人。
对于纯粹基于网络的软件，你的数据和应用程序都不存放在客户端。因此，你无需安装任何东西就能使用它。而且，没有安装过程，你也就无需担心安装出错。应用程序和你的操作系统之间不可能存在不兼容问题，因为软件根本不在你的操作系统上运行。
由于无需安装，在“购买”基于网络的软件之前试用它会很容易，也会很普遍。你应该期待能够免费试驾任何基于网络的应用程序，只需去到提供它的网站即可。在Viaweb，我们的整个网站就像一个大箭头，指引用户去体验测试版。
试用完演示版后，注册服务应该只需要填一个简短的表格（越简短越好）。而那应该是用户需要做的最后一项工作。使用基于网络的软件，你应该无需额外付费、无需做任何事、甚至可能毫不知情就能获得新版本。
升级不会再像现在这样是件大事。随着时间的推移，应用程序会悄然变得更强大。这需要开发者付出一些努力。他们必须设计出能够在不使用户困惑的情况下更新的软件。这是一个新问题，但有办法解决。
对于基于网络的应用程序，所有用户使用的都是同一版本，而且漏洞一旦发现就能立即修复。因此，基于网络的软件应该比桌面软件拥有更少的漏洞。在Viaweb，我怀疑我们在任何时候都从未有过十个已知漏洞。这比桌面软件要好上几个数量级。
基于网络的应用程序可以被多人同时使用。对于协作类应用来说，这显然是个优势，但我敢打赌，一旦用户意识到这是可能的，他们就会希望在大多数应用中都实现这一点。例如，允许两个人同时编辑同一个文档通常会很有用。Viaweb允许多个用户同时编辑一个网站，这更多地是因为这是编写该软件的正确方式，而不是因为我们预期用户会想要这样，但事实证明，确实有很多用户需要这个功能。
当你使用基于网络的应用程序时，你的数据会更安全。磁盘崩溃不会成为过去式，但用户将不再听到它们。崩溃会发生在服务器农场内部。而且，提供基于网络应用的公司确实会进行备份——这不仅是因为他们会有真正的系统管理员来操心这些事情，更是因为一个丢失了用户数据的ASP将面临巨大、巨大的麻烦。当人们在磁盘崩溃中丢失自己的数据时，他们不会那么生气，因为他们只能怪自己。但当一家公司替他们弄丢了数据时，他们就会生气得多。
最后，基于网络的软件应该更不容易受到病毒的攻击。如果客户端除了浏览器之外不运行任何东西，那么运行病毒的机会就会减少，本地也没有数据可以被破坏。而一个企图攻击服务器本身的程序，应该会发现它们防守得非常好。[2]
对于用户来说，基于网络的软件将会减少压力。 我想，如果你深入探究普通Windows用户的内心，你会发现一种巨大的、几乎未被开发的、对这种软件特质的渴望。一旦这种渴望被释放出来，它可能会成为一股强大的力量。
代码之城
对于开发者来说，基于网络的软件与桌面软件最显著的区别在于，一个基于网络的应用程序不是单一的代码块。它将是一组不同类型的程序的集合，而不是一个单一的大型二进制文件。因此，设计基于网络的软件就像设计一座城市，而不是设计一栋建筑：除了建筑物，你还需要道路、路标、公用设施、警察和消防部门，以及为增长和各种灾难所做的规划。
在Viaweb，软件包括用户直接与之交互的相当大的应用程序、这些程序所使用的程序、在后台持续运行以查找问题的程序、在程序出错时尝试重启的程序、定期运行以编译统计数据或为搜索建立索引的程序、我们显式运行以进行资源垃圾回收或移动、恢复数据的程序、伪装成用户（以衡量性能或暴露漏洞）的程序、用于诊断网络故障的程序、用于执行备份的程序、与外部服务的接口、驱动着一排令人印象深刻的、显示实时服务器统计数据的仪表盘的软件（参观者很喜欢，但对我们来说也是不可或缺的）、对开源软件的修改（包括漏洞修复），以及大量的配置文件和设置。特雷弗·布莱克韦尔编写了一个出色的程序，在我们被雅虎收购后，它能在不关闭商店的情况下，将商店迁移到全国各地的新服务器上。程序会传呼我们，向用户发送传真和电子邮件，与信用卡处理商进行交易，并通过套接字、管道、HTTP请求、SSH、UDP数据包、共享内存和文件等方式相互通信。Viaweb的某些部分甚至体现为“没有程序”，因为Unix安全的关键之一就是不运行那些可能被人用来入侵服务器的不必要的实用程序。
这不仅仅止于软件。我们花了大量时间思考服务器配置。我们自己用组件组装服务器——部分是为了省钱，部分是为了得到我们确切想要的东西。我们必须考虑我们的上游ISP是否与所有主干网有足够快的连接。我们先后与多家RAID供应商建立了联系。
但硬件不仅仅是需要担心的问题。当你掌控了它，就能为用户做更多事。对于桌面应用，你可以指定最低硬件要求，但无法增加更多。如果你管理服务器，只需安装相关硬件，就能一步让所有用户实现呼叫、发送传真、通过电话下达命令或处理信用卡等。我们总是寻求用硬件添加新功能的方式，这不仅是为了取悦用户，也是为了在竞争对手中脱颖而出——他们要么销售桌面软件，要么通过ISP转售基于Web的应用，因此无法直接控制硬件。
因为基于Web的应用软件将是一系列程序的集合，而非单一二进制文件，所以它可以用任意多种不同语言编写。当编写桌面软件时，你几乎被迫使用与底层操作系统相同的语言——即C和C++。于是这些语言（尤其在非技术人员如经理和风险投资人眼中）被视为“严肃”软件开发的标配。但这只是桌面软件交付方式的一种人为产物。对于基于服务器的软件，你可以使用任何想要的语言。[3] 如今许多顶级黑客用的语言与C和C++相去甚远：Perl、Python，甚至Lisp。
对于基于服务器的软件，没人能规定你用什么语言，因为你控制了整个系统，直至硬件。不同语言擅长不同任务。你可以为每项任务选择最合适的。而当你面对竞争对手时，“你可以”意味着“你必须”（我们稍后会再谈这一点），因为如果你不利用这种可能性，你的竞争对手就会。
我们的大多数竞争对手使用C和C++，这使他们的软件明显处于劣势，因为（除其他原因外）他们无法绕过CGI脚本的无状态性。如果你想修改什么，所有更改都必须发生在一个页面上，并在底部放个“更新”按钮。正如我在别处写过的，通过使用许多人仍视为研究语言的Lisp，我们可以让Viaweb编辑器表现得像桌面软件一样。
版本发布
在这个新世界中，最重要的变化之一是发布方式。在桌面软件业务中，发布是一次巨大的创伤，整个公司都为之汗流浃背，推出一个单一的庞大代码块。无论是过程还是产物，都让人自然而然联想到笨重的大象。
对于基于服务器的软件，你可以像修改为自己写的程序那样进行更改。你以一系列增量更改的方式发布软件，而不是偶尔的一次大爆发。典型的桌面软件公司一年可能发布一到两次。而在Viaweb，我们常常一天发布三到五次。
当你切换到这种新模式时，你会意识到软件开发深受发布方式的影响。许多在桌面软件业务中看到的最棘手问题，都源于发布的灾难性本质。
当你一年只发布一个新版本时，倾向于整批处理bug。在发布日期前一段时间，你组装一个新版本，其中一半代码被拆除并替换，引入了无数bug。然后一队QA人员进入并开始计数，程序员则按列表逐一修复。他们通常无法完成列表，而且没人确定终点在哪里。这就像从池塘里捞碎石。你从未真正知道软件内部发生了什么。最好情况下，你只会得到一种统计意义上的正确性。
对于基于服务器的软件，大部分更改是小而增量的。这本身就不太可能引入bug。这也意味着在准备发布软件时，你知道最需要仔细测试什么：最后更改的部分。你对代码的控制力会强得多。一般来说，你确实知道其内部发生了什么。你当然没有记住源码，但阅读源码时，你像飞行员扫描仪表盘，而不是像侦探解开谜团。
桌面软件滋生某种对bug的宿命论。你知道自己交付的东西充满bug，甚至已设置机制来弥补（如补丁发布）。那么多几个又何必担心？很快，你开始发布明知有缺陷的完整功能。苹果今年早些时候就这么做过。他们感到发布新操作系统的压力，其发布日期已推迟四次，但部分软件（如CD和DVD支持）尚未准备好。解决方案？他们发布了未完成部分的操作系统，用户必须稍后自行安装。
对于基于Web的软件，你永远不必在其运行前发布，而且一旦运行，就可以立即发布。
行业老手可能会想，说“你永远不必在其运行前发布软件”听起来不错，但当你承诺在特定日期交付新版本时怎么办？对于基于Web的软件，你不会做出这种承诺，因为没有版本概念。你的软件是渐进且持续变化的。有些更改可能比其他更大，但版本的概念并不自然地适用于基于Web的软件。
如果有人记得Viaweb，这可能听起来很奇怪，因为我们总在宣布新版本。这完全是为了公关目的。我们了解到，商业媒体以版本号来思考。他们会为主要版本大幅报道，意思是版本号首位数字变化；而对于小版本，即小数点后数字变化，通常最多一段话。
我们的一些竞争对手提供桌面软件，并且确实有版本号。对于这些发布——这种事实在我们看来正是他们落后的证据——他们会得到各种宣传。我们不想错过，于是也开始给软件编版本号。当我们想要宣传时，列出自上次“发布”以来添加的功能，给软件贴上新的版本号，并发布新闻稿说新版本立即可用。令人惊讶的是，从未有人质疑过我们。
到我们被收购时，已这样做了三次，所以到了Version 4。如果我没记错的话，是Version 4.1。Viaweb成为Yahoo Store后，不再迫切需要宣传，所以尽管软件继续演进，版本号这个概念被悄然放弃了。
Bug
基于Web软件的另一大技术优势是你能复现大多数bug。用户的数就在你的磁盘上。如果有人弄坏了你的软件，你不必像桌面软件那样猜测发生了什么：你应该能在他们与你通话时复现错误。如果内置错误检测代码，你甚至可能已经知道了。
基于Web的软件全天候运行，所以你做的每件事都会立即受到考验。Bug会快速显现。
软件公司有时被指责让用户来调试他们的软件。而这正是我所提倡的。对于基于Web的软件，这实际上是个好计划，因为bug更少且是暂时性的。当你逐步发布软件时，一开始遇到的bug会少得多。而且当你能够复现错误并立即发布更改时，你能在大多数bug出现时迅速找到并修复。我们从未有足够多的bug需要正式追踪系统。
当然，你应该在发布前测试更改，所以不应发布重大bug。那些不可避免漏网的少数bug会涉及边缘情况，只在遇到它们的少数用户中显现，直到有人来电投诉。只要你及时修复，对普通用户来说，净效果是bug少得多。我怀疑普通的Viaweb用户从未见过bug。
修复新bug比修复旧bug容易。通常，找到刚写代码中的bug相当快。当它出现时，你往往在查看源码前就已知错，因为你潜意识里已在担心它。修复六个月前写的东西里的bug（如果一年发布一次，那是平均情况）则更费工夫。而且由于你对代码理解不够，更可能以丑陋方式修复，甚至引入更多bug。[4]
当你尽早捕获bug时，得到的复合bug也会更少。复合bug是两个独立bug相互作用：你下楼时绊倒，伸手去抓扶手，它却脱落了。在软件中，这类bug最难找，也往往后果最糟。[5] 传统“先破坏所有再过滤bug”的方法固有地会产生大量复合bug。而逐次小更改发布的软件倾向于不产生这种问题。地面不断清扫干净，不留任何可能卡住东西的松散物体。
使用一种称为函数式编程的技术会有所帮助。函数式编程意味着避免副作用。你更可能在研究论文而非商业软件中看到它，但对Web应用来说，它被证明非常有用。编写纯函数代码的完整程序很难，但你可以用这种方式编写大量模块。这让软件这些部分更容易测试，因为它们没有状态，在持续制作和测试小修改的环境中非常方便。我用这种风格写了Viaweb编辑器的许多部分，并将我们的脚本语言RTML设为纯函数语言。
来自桌面软件业务的人会觉得这难以置信，但在Viaweb，bug几乎成了一种游戏。由于发布的大多数bug涉及边缘情况，遇到它们的用户很可能是高级用户，在突破界限。高级用户对bug更宽容，尤其是因为bug可能是在添加他们要求的功能时引入的。事实上，由于bug罕见，且只有做复杂操作才会遇到，高级用户常常为捕获一个bug而自豪。他们怀着胜利而非愤怒的心情打电话给支持，仿佛就在我们身上得了分。
支持
当你能复现错误时，客户支持方式也会改变。在大多数软件公司，支持是为了让客户安心。他们要么打来询问已知bug，要么只是操作失误，你需要弄清问题。无论哪种情况，你从他们那里学不到什么。因此，你往往把支持电话视为麻烦，希望尽可能远离开发者。
但在Viaweb，事情并非如此。在Viaweb，支持是免费的，因为我们想听到客户的声音。如果有人遇到问题，我们想立即知道，以便复现错误并发布修复。
所以在Viaweb，开发者总是与支持紧密联系。客户支持人员与程序员相距约十米，并知道他们随时可以打断任何工作来报告真正的bug。我们会离开董事会会议去修复严重bug。
我们的支持方式让所有人都更开心了。客户们喜出望外。想象一下，当你拨打支持热线时，对方视你为带来重要消息的人，那种感觉何等美妙。客服人员喜欢这种方式，因为它意味着他们能真正帮助用户，而不是照本宣科。程序员们同样高兴，因为他们能够重现bug，而不是仅凭模糊的二手报告去猜测。
我们即时修复bug的政策，改变了客服人员与黑客之间的关系。在大多数软件公司，客服人员是薪酬微薄的人肉盾牌，而程序员则仿佛是上帝之子的微缩版，世界的创造者。无论报告bug的程序如何，都往往是单向的：客服人员听到bug后填写表格，最终（可能通过QA）传递给程序员，由他们记入待办清单。但在Viaweb，情况截然不同。客服人员从客户那里听说bug后，不到一分钟就能站在程序员旁边，听到他说：“该死，你说得对，这确实是个bug。”听到黑客们承认“你说得对”，客服人员感到无比欣慰。他们带着一种期待的神情来报告bug，就像猫咪叼着刚捕获的老鼠献给你一样。这也让他们在评估bug严重性时更加谨慎，因为此刻他们的荣誉系于一线。
在被Yahoo收购后，客服人员被调离程序员很远的地方。直到那时我们才意识到，他们实际上既是QA，在某种程度上也是市场人员。除了捕获bug，他们还掌握着那些更为模糊、类似bug的问题的线索，比如让用户困惑的功能。他们还是某种代理焦点小组；我们可以询问他们用户更想要两个新功能中的哪一个，而他们的判断总是准确无误。
士气
能够立即发布软件是一个巨大的激励因素。常常在步行上班的路上，我会想到对软件的一些改动，并在当天完成。这对大型功能同样适用。即使某个功能需要两周时间来编写（很少有项目耗时更长），我知道一旦完成，就能立即在软件中看到效果。
如果不得不等待一年才能发布下一版本，我肯定会搁置大部分这些想法，至少暂时如此。然而，想法这东西，会催生更多想法。你有没有注意到，当你坐下来写作时，最终成稿中有一半想法是写作过程中新冒出来的？软件开发亦是如此。实施一个想法时，会激发你产生更多想法。因此，搁置一个想法不仅损失了实施它的时间，还损失了实施它可能带来的所有后续想法。事实上，搁置想法甚至可能抑制新想法：当你开始构思某个新功能时，瞥见架子上堆积的待办事项，就会想“但下一版本我已经有很多想做的了。”
大公司在未实施新功能时，往往在做的是规划它们。在Viaweb，我们有时也会因此遇到麻烦。投资者和分析师会问我们未来有何计划。诚实的回答是，我们没有任何计划。我们对想要改进的地方有大致想法，但如果我们知道具体怎么做，早就做了。未来六个月我们要做什么？那就是看什么最能赢得胜利。我不知道我是否敢于这样回答，但这就是事实。计划不过是架子上想法的另一种说法。当我们想到好主意，我们就去实施。
在Viaweb，如同许多软件公司，大多数代码都有明确的所有者。但一旦你拥有某样东西，你就完全拥有它：除了软件的所有者，没有人需要批准（甚至知道）一次发布。除了怕在同行面前显得像个傻瓜之外，没有任何防故障的保护，而这种担忧已经绰绰有余。我之前可能给人留下我们只是轻率地埋头写代码的印象。我们确实速度很快，但在将软件发布到那些服务器之前，我们经过了非常仔细的思考。对于可靠性而言，专注比慢速更为重要。因为高度专注，海军飞行员能在夜晚、在起伏的航母甲板上以140英里的时速安全降落一架4万磅的飞机，而普通青少年切个百吉饼都没这么稳。
这种编写软件的方式当然是双刃剑。它更适合一个小而精的、值得信赖的编程团队，而非一个由平庸者组成的大公司，在那里坏主意是被委员会而非提出者本人拦截的。
反向的布鲁克斯
幸运的是，基于Web的软件确实需要更少的程序员。我曾在一家中等规模的桌面软件公司工作，整个工程部门有100多人，其中只有13人负责产品开发，其余都在处理发布、移植等事务。而基于Web的软件，你（最多）只需要那13人，因为没有发布、移植等事宜。
Viaweb仅由三人编写完成。我一直面临招聘更多人的压力，因为我们想被收购，也知道买家很难为只有三名程序员的公司出高价。（解决方案：我们雇了更多人，但为他们开辟了新项目。）
当你能用更少的程序员编写软件时，节省的不仅仅是金钱。正如Fred Brooks在《人月神话》中指出的，向项目增派人手往往会让进度变慢。开发者之间可能的联系数量随团队规模呈指数增长。团队越大，他们在会议上协商软件如何协同工作的时间就越多，因不可预见的交互产生的bug也会更多。幸运的是，这个过程逆向同样成立：随着团队变小，软件开发效率呈指数级提升。我记不起Viaweb的程序员们开过什么正式的会议。我们每次需要交流的内容，在去午餐的路上就都说完了。
如果说这里有什么缺点，那就是所有程序员都必须在一定程度上兼任系统管理员。当你托管软件时，必须有人盯着服务器，而实践中能真正做好这件事的，只有写软件的那些人。在Viaweb，我们的系统组件众多且变化频繁，软件与基础设施之间没有明确的界限。武断地划出这样的界限会限制我们的设计选择。因此，尽管我们一直希望（“再过几个月”）一切能稳定到可以雇一个专门操心服务器的人，但这个时刻从未到来。
我认为，只要你们还在积极开发产品，就只能是这种情况。基于Web的软件永远不会是你写完、提交、然后回家就完事的东西。它是一个活的实体，此刻正在你的服务器上运行。一个严重的bug可能不只是让一个用户的进程崩溃，而是让所有用户都崩溃。如果你的代码中的bug破坏了磁盘上的数据，你必须修复它。诸如此类。我们发现，不需要每分钟都盯服务器（大约一年后），但绝对要密切关注最近改动过的地方。你不能深夜发布代码然后回家。
观察用户
对于基于服务器的软件，你与代码的联系更为紧密，与用户的联系也能更紧密。Intuit公司以在零售店向顾客自我介绍并请求跟随他们回家而闻名。如果你曾旁观某人初次使用你的软件，就能想象他们遇到了多少惊喜。
软件应当符合用户的预期。但相信我，除非你亲自观察，否则你无法预知用户会怎么想。而基于服务器的软件为你提供了关于用户行为的前所未有的信息。你不再局限于小规模、人造的焦点小组。你可以看到每位用户的每一次点击。你需要仔细考虑观察什么，因为你不想侵犯用户隐私，但即使是最普通的统计抽样也可能极其有用。
当用户使用你的服务器时，比如，你就不必依赖基准测试了。基准测试是模拟用户，而基于服务器的软件让你观察真实用户。要决定优化什么，只需登录服务器看看什么在消耗所有CPU。你也知道何时该停止优化：我们最终把Viaweb编辑器优化到了内存受限而非CPU受限的程度，既然我们无法减少用户数据的大小（好吧，没有简单的办法），我们就知道差不多该收手了。
效率对基于服务器的软件至关重要，因为你要为硬件买单。每台服务器能支持的用户数量是你资本成本的除数，所以如果软件非常高效，你就能以低价竞争并仍能盈利。在Viaweb，我们将每个用户的资本成本降到了约5美元。现在这个数字会更低，可能低于给他们寄第一张账单的成本。如果你的软件效率尚可，现在硬件几乎是免费的。
观察用户既能指导设计，也能指导优化。Viaweb有一种名为RTML的脚本语言，让高级用户定义自己的页面风格。我们发现RTML成了某种建议箱，因为用户只有在预定义页面样式无法满足需求时才会用到它。例如，最初编辑器在页面顶部放置按钮栏，但在不少用户用RTML将按钮移到左侧后，我们将此设为预定义页面样式中的一个选项（实际上后来成了默认选项）。
最后，通过观察用户，你常常能发现他们何时遇到了麻烦。既然顾客永远是对的，那就是你需要修复的信号。在Viaweb，吸引用户的关键是在线试用。那不仅仅是市场人员制作的一系列幻灯片。在我们的试用中，用户实际使用软件。大约需要五分钟，结束时他们就构建了一个真实、可运行的商店。
试用是我们获得几乎所有新用户的途径。我认为对大多数基于Web的应用程序来说也是如此。如果用户能顺利完成试用，他们就会喜欢产品。如果他们感到困惑或无聊，就不会喜欢。因此，任何能让更多人完成试用的改进，都会加快我们的增长速度。
我研究过用户参加试用的点击轨迹，发现他们在某一步会感到困惑，点击浏览器的“后退”按钮。（如果你尝试编写基于Web的应用程序，你会发现“后退”按钮会成为你最有趣的哲学问题之一。）于是我在那个地方加了一条消息，告诉用户他们快完成了，并提醒他们不要点击“后退”按钮。基于Web的软件另一个伟大之处在于，你能立即从改动中获得反馈：完成试用的人数瞬间从60%上升到90%。而由于新用户数量取决于完成试用的人数，仅这一项改动就使我们的收入增长了50%。
金钱
在90年代初，我读到一篇文章，文中提到软件是一种订阅业务。起初，这听起来颇为讽刺。但后来我意识到这反映了现实：软件开发是一个持续的过程。我认为，公开收取订阅费，而不是迫使人们不断购买和安装新版本以便持续付费，这样更为清晰。幸运的是，订阅模式天然适合基于Web的应用计费。
应用托管是一个公司能扮演重要角色的领域，不太可能由免费软件填补。托管应用压力大，且有实际开销。没有人愿意免费做这件事。
对于公司而言，基于Web的应用是理想的收入来源。不必每个季度从零开始，你拥有持续的收入流。因为软件是渐进演进的，无需担心新模型会失败；本质上，从未需要新模型，如果你对软件做了什么用户讨厌的改动，你会立刻知晓。你不会有坏账问题；如果用户不付款，你可以立即停止服务。而且不存在盗版可能。
最后一项“优势”可能会成为问题。某种程度上，盗版对软件公司是有利的。如果某些用户无论价格如何都不会购买你的软件，那么使用盗版复制品你并未损失什么。实际上，你反而受益，因为他成为了使你的软件成为标准的又一个用户——或者可能在高中毕业后购买正版。
尽可能，公司喜欢实施所谓的“价格歧视”，即根据每个客户的支付能力收费。[8] 软件尤其适合价格歧视，因为边际成本接近于零。这就是为什么某些软件在Sun工作站上运行比在Intel机器上更贵：使用Sun的公司对节省资金不感兴趣，可以安全地收取更高费用。盗版实际上是最低层次的价格歧视。我认为软件公司明白这一点，并有意对某些盗版行为视而不见。[9] 对于基于服务器的软件，他们需要想其他办法。
基于Web的软件卖得好，特别相比桌面软件，因为它易于购买。你可能认为人们决定购买然后再购买是两个独立步骤。那是我在Viaweb之前的想法，在我考虑这个问题时是这样想的。实际上，第二步可以反馈到第一步：如果某物难以购买，人们会改变他们是否需要它的想法。反之亦然：当某物易于购买时，你会卖出更多。我因为亚马逊的存在而买了更多书。基于Web的软件是世界上最容易购买的，特别是如果你刚做过在线演示。用户只需输入信用卡号即可。（让用户做更多事，后果自负。）
有时基于Web的软件通过ISP作为经销商提供。这是个坏主意。你必须亲自管理服务器，因为你需要不断改进硬件和软件。如果放弃对服务器的直接控制，你就放弃了开发Web应用的大部分优势。
我们的几个竞争对手因此自食其果——我认为，通常是因为被那些对此巨大潜在渠道兴奋不已、却没意识到这会毁掉他们希望通过该渠道销售的产品的高管们所压倒。通过ISP销售Web软件就像通过自动售货机卖寿司一样。
客户
客户是谁？在Viaweb，最初是个人和小公司，我认为这将是Web应用的一般规律。这些用户准备尝试新事物，部分是因为他们更灵活，部分是因为他们想要新技术的低成本。
Web-based应用对于大公司也常常是最佳选择（尽管他们认识这一点会很慢）。最好的内网就是互联网。如果一家公司使用真正的Web应用，软件会运行得更好，服务器管理得更好，员工也能从任何地方访问系统。
反对这种方法的论点通常围绕安全：如果员工访问更方便，对坏人也是如此。一些大型商家不愿使用Viaweb，因为他们认为客户的信用卡信息在他们自己的服务器上更安全。虽然很难婉转地说明，但实际上数据在我们手中几乎肯定比在他们那里更安全。谁能雇佣更好的人员来管理安全，是一个整个业务都围绕运行服务器的技术初创公司，还是一家服装零售商？不仅我们有更优秀的人员关注安全问题，我们更重视安全问题。如果有人侵入服装零售商的服务器，最多影响一家商家，可能被掩盖，最坏情况可能是某人被解雇。如果有人侵入我们的服务器，可能影响数千商家，很可能成为CNet的新闻，并可能导致我们破产。
如果你想确保资金安全，你会把它藏在床垫下，还是存入银行？这个论点适用于服务器管理的每一个方面：不仅仅是安全，还包括正常运行时间、带宽、负载管理、备份等。我们的存在依赖于正确做好这些事情。服务器问题对我们来说是大忌，就像危险的玩具对玩具制造商，或沙门氏菌爆发对食品加工商。
大公司使用基于Web的应用在某种程度上是外包IT。尽管听起来激进，我认为这通常是个好主意。公司通过这种方式得到的服务可能比内部系统管理员提供的更好。系统管理员可能会变得古怪且反应迟钝，因为他们不直接面对竞争压力：销售人员必须应对客户，开发者必须应对竞争对手的软件，但系统管理员，如同老单身汉，几乎没有外部力量使他保持规矩。[10] 在Viaweb，我们有大量外部力量让我们保持警觉。打电话给我们的是客户，而不仅仅是同事。如果服务器出现问题，我们会立刻跳起来；多年后想到这件事，我仍会肾上腺素激增。
因此，Web应用通常对大公司也是正确答案。然而，他们会是最后认识到这一点的，就像桌面电脑一样。部分原因是相同的：说服大公司需要昂贵方案，会有很大利益可图。
富裕客户总是倾向于购买昂贵的解决方案，即使便宜解决方案更好，因为提供昂贵解决方案的人能花更多钱去推销。在Viaweb，我们总是遇到这种情况。我们失去了几个高端商家，他们被Web咨询公司说服，认为花五十万美元在自家服务器上定制在线商店会更好。通常，他们的确没有更好，比如不止一位商家在圣诞购物季负载上升时发现了问题。Viaweb远比这些商家所得到的要先进得多，但我们负担不起去告诉他们。每月300美元，我们无法派出穿着得体、声音权威的团队给客户做演示。
大公司支付额外费用的大部分是高价销售给他们的成本。（如果国防部为一千美元的马桶座付款，部分原因是高价销售马桶座本身成本不菲。）这也是为什么内网软件将继续繁荣的原因之一，尽管这可能是个坏主意。它只是更昂贵。这个难题你无法解决，所以最好的计划是首先争取较小客户。其余的会随时间而来。
服务器之子
在服务器上运行软件并非新鲜事。实际上，这是旧模式：大型机应用全是基于服务器的。如果服务器软件是个好主意，为什么上一次失败了呢？为什么桌面电脑取代了大型机？
起初，桌面电脑并不显得威胁。第一批用户全部是黑客——或当时所称的爱好者。他们喜欢微型计算机，因为它便宜。第一次，你可以拥有自己的电脑。“个人电脑”现在已是语言的一部分，但在最初使用时，它带有大胆冒险意味，如同今天的“个人卫星”。
为什么桌面电脑接管了呢？我认为是因为它们有更好的软件。而微型计算机软件更好的原因在于它可以由小公司编写。
我想没有多少人意识到初创公司在最初阶段是多么脆弱和不确定。许多初创公司几乎偶然开始——一两个人，全职工作或在校，编写可能变成公司的原型。在这个幼虫阶段，任何重大障碍都会让初创公司立即死亡。编写大型机软件需要前期投入太多。开发机器昂贵，且因为客户是大公司，你需要一支看起来有说服力的销售队伍去推销。启动一家写大型机软件的初创公司远比晚上在Apple II上拼凑点东西要严肃得多。因此，你不会有太多初创公司编写大型机应用。
桌面电脑的到来激发了许多新软件，因为为它们编写应用对幼虫初创公司似乎是可实现的目标。开发成本低，客户是个人，你可以通过电脑商店甚至邮购联系到他们。
推动桌面电脑步入主流的是VisiCalc，第一个电子表格软件。它由两人在阁楼编写，却能做到大型机软件做不到的事情。[11] VisiCalc在其时代是如此进步，人们购买Apple II仅为运行它。这是趋势的开始：桌面电脑赢了是因为初创公司为它们编写软件。
看来这次服务器软件会很好，因为初创公司会编写它。现在电脑如此便宜，你可以像我们一样，用桌面电脑作为服务器开始。低成本处理器已吞噬了工作站市场（现在你几乎听不到这个词），并且已大部分占领服务器市场；Yahoo的服务器处理互联网上最高负载，全部使用与你的桌面机相同的低成本Intel处理器。一旦你写好软件，出售只需一个网站。我们几乎所有用户都是通过口头传播和媒体报道直接访问我们的网站。[12]
Viaweb是典型的幼虫初创公司。我们害怕开公司，头几个月通过把整个事情当作可随时取消的实验来安慰自己。幸运的是，除了技术问题外，几乎没有障碍。在我们编写软件期间，我们的Web服务器就是我们开发用的同一台桌面机，通过拨号线连接外部世界。那个阶段我们的唯一开销是食物和房租。
现在的初创公司更应该有理由编写基于 Web 的软件，因为编写桌面软件已经变得不那么有趣了。如今要编写桌面软件，你得按照微软的规矩来，调用他们的 API，还得绕开他们那个满是漏洞的操作系统。而且，就算你成功做出了什么火爆的产品，你可能发现自己不过是替微软做了市场调研。
如果一家公司想打造一个让初创公司愿意在其上构建的平台，他们就必须把它做成黑客们自己也想用的东西。这意味着它必须价格低廉且设计精良。Mac 刚推出时在黑客中很受欢迎，很多人为它编写软件。[13] 而 Windows 上这种情况就少得多，因为黑客不用它。那些擅长编写软件的人，现在大多运行着 Linux 或 FreeBSD。
我觉得我们当初不会为了写桌面软件而创办公司，因为桌面软件必须运行在 Windows 上，而在我们为 Windows 写软件之前，我们得先使用它。Web 让我们得以绕开 Windows，把运行在 Unix 上的软件直接通过浏览器送到用户面前。这是一个令人解放的前景，很像二十五年前个人电脑到来时的情景。
微软
当年桌面电脑问世时，IBM 是人人都害怕的巨头。现在很难想象了，但我还清楚地记得那种感觉。如今令人恐惧的巨头是微软，而我认为他们对自身面临的威胁并不像当年的 IBM 那样盲目。毕竟，微软正是刻意在 IBM 的盲区里建立起自己的生意。
我之前提到，我母亲其实并不真正需要一台桌面电脑。大多数用户可能也不需要。这对微软来说是个问题，而他们心知肚明。如果应用程序都运行在远程服务器上，那就没人需要 Windows 了。微软会怎么做？他们能利用自己对桌面的控制来阻止或限制这一代新软件吗？
我的猜测是，微软会开发某种服务器/桌面的混合体，让操作系统与他们控制的服务器协同工作。至少，文件将对那些需要的用户集中可用。如果可能的话，我不指望微软会一路走到极端，把计算都放到服务器上，只留一个浏览器作为客户端。如果客户端只需要一个浏览器，那客户端上就不需要微软；而如果微软控制不了客户端，他们就没法把用户推向自己的服务器端应用。
我认为微软很难把精灵重新塞回瓶子里。客户端类型会太多，他们无法全部控制。而且如果微软的应用只兼容某些客户端，竞争对手就可以通过提供任何客户端都能用的应用来胜过他们。[14]
在一个基于 Web 的应用世界里，微软没有天然的位置。他们也许能为自己争得一席之地，但我觉得他们不会像统治桌面应用世界那样统治这个新世界。
与其说是竞争对手会绊倒他们，不如说他们会自己绊倒自己。随着基于 Web 的软件兴起，他们将面临的不仅是技术问题，还有他们自己的一厢情愿。他们需要做的是蚕食自己现有的业务，而我看不出他们能面对这一点。那种把他们带到今天这一步的专注固执，现在会反过来与他们作对。IBM 当时正处于完全相同的境地，却无法驾驭。IBM 之所以姗姗来迟、三心二意地进入微型计算机业务，是因为他们对威胁自己的现金奶牛——大型机业务——感到矛盾。微软同样会因为想保住桌面而被拖累。一头现金奶牛可以成为背上一只该死的沉重猴子。
我并不是说没有人会统治服务器端应用。最终也许有人会的。但我认为会有一段漫长而愉快的混乱时期，就像微型计算机早期那样。那对初创公司来说是个好时代。许多小公司蓬勃发展，靠的是做出酷的东西。
初创公司，但更极致
典型的初创公司节奏快、不拘小节，人少钱少。那几个人拼命工作，而技术放大了他们所做决策的影响。如果他们赢了，就是大赢。
在编写基于 Web 应用的初创公司里，你联想到初创公司的一切都被推向了极致。你可以用更少的人、更少的钱来编写并发布一个产品。你必须更快，而且可以更不拘小节。你完全可以以三个人坐在公寓客厅里、服务器托管在 ISP 机房的方式发布产品。我们就是这么做的。
随着时间的推移，团队变得规模更小、速度更快、更加不拘小节。1960 年，软件开发意味着一屋子戴着角质架眼镜、系着窄黑领带的人，在 IBM 编码表单上勤勉地每天写十行代码。1980 年，是一个八到十人的团队，穿着牛仔裤去办公室，对着 vt100 终端敲代码。现在，是几个人坐在客厅里，抱着笔记本电脑。（而牛仔裤原来也不是不拘小节的终点。）
初创公司压力很大，而不幸的是，在基于 Web 的应用里，这一点也被推向了极致。许多软件公司在早期阶段都有过开发者睡在办公桌底下之类的时期。基于 Web 的软件令人担忧的是，没有什么能阻止这成为常态。那些睡桌底的故事通常是这样结尾的：最后我们终于发布了，然后大家回家睡了一星期。而基于 Web 的软件永远不会“发布”。你可以随心所欲地连续工作 16 小时。而且因为你能，你的竞争对手也能，你往往会被迫如此。你能，所以你必须。这是帕金森定律的反向运行。
最糟糕的还不是工作时间，而是责任。程序员和系统管理员传统上各有各的担忧。程序员要担心 bug，系统管理员要担心基础设施。程序员可能整日埋头于源代码，但某时某刻他们能回家然后忘掉这一切。系统管理员永远无法真正放下工作，但当他们凌晨 4 点被呼叫时，通常不需要做什么太复杂的事。而基于 Web 的应用，把这两种压力结合在了一起。程序员变成了系统管理员，却没有了通常令这份工作可以忍受的明确界限。
在 Viaweb，我们头六个月只是写软件。我们像普通早期初创公司那样长时间工作。在桌面软件公司，这会是我们拼命工作的阶段，但和下一阶段——我们把用户放到服务器上之后——相比，那就像是度假。把 Viaweb 卖给雅虎的第二大好处（仅次于钱）就是能把整个事情的最终责任甩到一家大公司的肩上。
桌面软件迫使用户成为系统管理员。基于 Web 的软件迫使程序员成为系统管理员。总的压力更小了，但程序员承受的更多了。这未必是坏消息。如果你是一家与大公司竞争的初创公司，这就是好消息。[15] 基于 Web 的应用提供了一种直截了当的方法来比竞争对手更拼。没有哪个初创公司会要求更多。
刚刚好
可能让你对编写基于 Web 应用望而却步的一件事，是网页作为用户界面的简陋。这是个问题，我承认。有一些东西我们当时真的很想加进 HTML 和 HTTP 里。但重要的是，网页已经“刚刚好”了。
这和第一批微型计算机有相似之处。那些机器里的处理器其实并非被设计为计算机的 CPU。它们被设计用在红绿灯之类的东西里。但像设计 Altair 的埃德·罗伯茨这样的人意识到，它们已经“刚刚好”了。你可以把这样一块芯片和一些内存（第一台 Altair 只有 256 字节）以及前面板开关组合起来，就能得到一台能工作的计算机。能拥有自己的计算机这件事太令人兴奋了，所以哪怕再有限制，也有很多人愿意买。
网页并非被设计为应用程序的界面，但它们已经“刚刚好”了。而且对相当数量的用户来说，能在任何浏览器里使用的软件，其本身就是很大的胜利，足以抵消界面上的任何笨拙。也许你没法用 HTML 写出最好看的电子表格，但你能写出一个可以多人同时从不同地点使用、无需特殊客户端软件，或者能整合实时数据流，或者能在某些条件触发时呼你的电子表格。更重要的是，你能写出一些还没有名字的新类型应用。VisiCalc 毕竟不只是大型机应用的微型机版本——它是一种新类型的应用。
当然，服务器端应用不一定非得是基于 Web 的。你也可以用其他类型的客户端。但我相当确定那是坏主意。如果能假设每个人都会安装你的客户端，那会很方便——方便到你会轻易说服自己他们都会装——但如果他们不装，你就完蛋了。因为基于 Web 的软件对客户端不做任何假设，它能在 Web 能到达的任何地方工作。这已经是一个巨大的优势，而且随着新的 Web 设备激增，这个优势还会增长。用户会喜欢你，因为你的软件就是能用；你的日子也会更轻松，因为你不用为每个新客户端去调整它。[16]
我觉得我比任何人都更密切地观察了 Web 的演变，但我无法预测客户端会发生什么。融合可能正在到来，但会在哪里？我挑不出赢家。我能预测的一件事是 AOL 和微软之间的冲突。无论微软的 .NET 最终变成什么，它很可能涉及将桌面连接到服务器。除非 AOL 反击，否则他们要么被推到一边，要么变成微软客户端和服务器软件之间的一根管道。如果微软和 AOL 陷入客户端战争，唯一能确定在两边都能工作的就是浏览 Web，这意味着基于 Web 的应用将是唯一处处能用的类型。
这一切会如何发展？我不知道。而如果你押注在基于 Web 的应用上，你也不必知道。没人能在不破坏浏览的情况下破坏这一点。Web 可能不是交付软件的唯一方式，但它是现在就能用、而且会长久可用的一种。基于 Web 的应用开发成本低，即使是最小的初创公司也容易交付。它们工作量大，而且压力特别大，但这只会让初创公司的胜算更大。
为什么不来？
E. B. 怀特从一位农民朋友那里听说，许多电围栏其实根本没有通电流，他觉得很有趣。显然牛会学会远离它们，之后你就不需要电流了。“站起来吧，牛们！”他写道，“趁暴君们还在打呼噜，去夺取你们的自由！”
如果你是一个曾想过有朝一日创办公司的黑客，大概有两件事让你止步不前。一是你完全不懂商业。二是你害怕竞争。这两道围栏里都没有电流。
关于商业，你只需要知道两件事：做出用户喜欢的东西，并且让收入大于支出。如果这两件事你做对了，你就会领先于大多数初创公司。其余的你可以在过程中慢慢摸索。
你最初赚的可能不会比花的多，但只要差距缩小得足够快，你就能应付。如果启动资金不足，这至少会鼓励你养成节俭的习惯。你花的越少，就越容易赚得比花得多。幸运的是，推出一个基于 Web 的应用可以非常便宜。我们当时以不到一万美元启动，现在会更便宜。我们不得不在服务器上花费数千美元，还要再花数千美元获取 SSL。（当时唯一销售 SSL 软件的公司是 Netscape。）现在你可以租一个更强大的服务器，包含 SSL，费用比我们当初仅带宽的费用还低。你现在可以用低于一把豪华办公椅的成本推出一个基于 Web 的应用。
至于构建用户喜欢的东西，这里有一些通用建议。从制作一个你自己想用的干净、简单的东西开始。快速推出 1.0 版本，然后继续改进软件，在这过程中密切倾听用户意见。客户永远是对的，但不同的客户对事情的看法不同；最不成熟的用户告诉你需要简化和澄清什么，最成熟的用户告诉你需要添加什么功能。软件最好的状态是易用，但实现这一点的方法是让默认设置正确，而不是限制用户的选择。如果你的竞争对手的软件很烂，不要自满；你的软件应该与它可能达到的标准比较，而不是与当前竞争对手的现有水平比较。你自己要一直使用你的软件。Viaweb 本应是一个在线商店构建器，但我们也用它来制作自己的网站。不要仅仅因为他们的职位就听从市场人员、设计师或产品经理。如果他们有好的想法，就采纳，但决定权在你；软件必须由懂设计的黑客来设计，而不是由懂一点软件的设计师来设计。如果你不能像实现软件那样设计软件，就不要创业。
现在让我们谈谈竞争。你害怕的可能不是像你这样的黑客团队，而是真正的公司，有办公室、商业计划、销售员等等，对吧？其实，他们比你们更怕你们，而且他们是对的。几个黑客去搞清楚如何租办公室或雇销售人员，比任何规模的公司去编写软件都要容易得多。我两边都经历过，我知道这一点。当 Viaweb 被雅虎收购后，我突然发现自己在一家大公司工作，感觉就像在齐腰深的水里跑步一样。
我不是在贬低雅虎。他们有一些优秀的黑客，高层管理者也是实干家。对于大公司来说，他们是非凡的。但他们的工作效率仍然只有小型初创公司的十分之一左右。没有哪家大公司能比这做得更好。微软可怕之处在于，这么大的一家公司居然能开发软件。他们就像一座能行走的山。
别被吓倒。你能做微软做不到的事，就像他们能做你做不到的事一样。没有人能阻止你。开发基于 Web 的应用，你不需要征求任何人的许可。你不需要做授权交易，不需要在零售店获得货架空间，也不需要低声下气地让操作系统捆绑你的应用。你可以直接将软件交付到浏览器，除了阻止他们浏览网页，没有人能挡在你和潜在用户之间。
你可能不信，但我向你保证，微软怕你。那些自满的中层管理者可能不担心，但比尔担心，因为他曾经就是你，在 1975 年，上一次新型软件交付方式出现的时候。
注释
[1] 意识到大部分钱都在服务中，构建轻量级客户端的公司通常试图将硬件与在线服务结合起来。这种方法效果不佳，部分原因是需要两种不同类型的公司来构建消费电子产品和运行在线服务，也因为用户讨厌这个想法。送剃须刀，靠刀片赚钱可能对吉利有效，但剃须刀的承诺比 Web 终端小得多。手机制造商满足于销售硬件，而不试图同时赚取服务收入。这可能是互联网客户端也应该采用的模式。如果有人只是卖一个外形美观的小盒子，带浏览器，你可以通过任何 ISP 连接，全国每个技术恐惧症患者都会买一个。
[2] 安全性总是更多地取决于不搞砸，而不是任何设计决策，但基于服务器的软件本质会导致开发者更注意不搞砸。入侵服务器可能造成巨大损害，因此 ASP（想继续经营的公司）可能会在安全方面格外小心。
[3] 1995 年，当我们开始做 Viaweb 时，Java 小程序被认为是用开发基于服务器应用的万能技术。对我们来说，小程序似乎是一种过时的想法。下载程序到客户端运行？更简单的是直接让程序在服务器上运行。我们没有在 applets 上浪费太多时间，但无数其他初创公司一定被引诱进这个焦油坑。很少有人能活着逃脱，否则微软不可能在最新版本的 Explorer 中放弃 Java。
[4] 这一点归功于 Trevor Blackwell，他补充说：“编写软件的成本随其大小非线性增长。也许这主要是由于修复旧 bug，如果能快速找到所有 bug，成本可能更接近线性。”
[5] 最难找到的 bug 可能是一种复合 bug 的变体，其中一个 bug 恰好掩盖了另一个。当你修复一个 bug 时，另一个就显现出来。但看起来好像修复本身出了问题，因为那是你最后改的东西。
[6] 在 Viaweb 内部，我们曾举办过一个比赛，描述我们软件最差的地方。两名客户支持人员的答案并列第一，我至今想起仍不寒而栗。我们立即修复了这两个问题。
[7] Robert Morris 写了订单系统，用于购物者下订单。Trevor Blackwell 写了图像生成器和经理端，用于商家检索订单、查看统计数据和配置域名等。我写了编辑器，用于商家构建他们的网站。订单系统和图像生成器是用 C 和 C++ 写的，经理端主要用 Perl，编辑器用 Lisp。
[8] 价格歧视如此普遍（你经常听到零售商声称他们的采购能力意味着更低的价格），以至于我惊讶地发现它在 1936 年的《罗宾逊-帕特曼法案》中被定为非法。但这项法律似乎没有得到有力执行。
[9] 在《No Logo》中，Naomi Klein 说，“城市青年”偏好的服装品牌不会太努力防止入店行窃，因为在他们目标市场中，入店行窃者同时也是时尚领导者。
[10] 公司经常纠结于外包什么、不外包什么。一个可能的答案：外包任何不直接暴露于竞争压力的工作，因为外包会使其暴露在竞争压力下。
[11] 那两个人是 Dan Bricklin 和 Bob Frankston。Dan 用 Basic 在几天内写了一个原型，然后在接下来的一年里，他们一起工作（大部分时间在晚上）写了一个用 6502 机器语言编写的更强大版本。当时 Dan 在哈佛商学院，Bob 名义上有一份写作软件的正式工作。“做企业没有太大风险，”Bob 写道，“如果失败了，就失败了。没什么大不了的。”
[12] 这并不像听起来那么容易。口碑传播花了很长时间，我们直到雇了一家公关公司（公认是业界最好的）每月支付 1.6 万美元，才开始获得大量媒体报道。然而，事实是唯一的显著渠道是我们自己的网站。
[13] 如果 Mac 这么好，为什么输了呢？还是成本问题。微软专注于软件业务，并向苹果硬件释放了一大群廉价组件供应商。而且，在关键时期，西装革履的管理者接管也没有帮助。
[14] 有一件事有助于基于 Web 的应用，也有助于让下一代软件不被微软压制，就是有一个好的开源浏览器。Mozilla 是开源的，但似乎因为长期作为公司软件而受损。一个维护良好的小巧快速浏览器本身就是一件好事，可能也会鼓励公司制造小型 Web 设备。此外，一个合适的开源浏览器会让 HTTP 和 HTML 继续进化（比如 Perl）。它将大大有助于区分选择链接和点击链接；你只需要对 HTTP 做一个微小的增强，允许在一个请求中包含多个 URL。级联菜单也会很好。
如果你想改变世界，就写一个新的 Mosaic。觉得太晚了？1998 年很多人认为推出新搜索引擎太晚了，但 Google 证明他们错了。只要当前选项够烂，总有新事物的空间。先确保它能运行在所有免费操作系统上——新事物从用户开始。
[15] Trevor Blackwell 可能比任何人都更了解这一点，他写道：
“我想更进一步说，因为基于服务器的软件对程序员要求很高，它会导致根本性的经济转变，远离大公司。它需要程序员的那种强度和专注，他们只愿意在自己公司时提供。软件公司可以雇佣熟练的人在不苛刻的环境工作，也可以雇佣不熟练的人忍受艰苦，但他们不能雇佣高技能的人拼命工作。既然资本不再需要，大公司能带来的东西就很少了。”
[16] 在这篇文章的原始版本中，我建议避免使用 Javascript。那在 2001 年是个好计划，但现在 Javascript 能用了。