The Other Road Ahead

Сентябрь 2001

(Эта статья объясняет, почему значительная часть ПО следующего поколения будет серверной, что это будет значить для программистов и почему этот новый тип ПО — отличная возможность для стартапов. Основана на докладе в BBN Labs.)

Летом 1995 года мы с моим другом Робертом Моррисом решили основать стартап. PR-кампания вокруг IPO Netscape была тогда в самом разгаре, и в прессе много говорили об онлайн-коммерции. В то время в Сети было, наверное, около тридцати реальных магазинов, и все они были сделаны вручную. Если онлайн-магазинов должно было стать много, потребовалось бы ПО для их создания, поэтому мы решили его написать.

Первую неделю или около того мы собирались делать это как обычное desktop-приложение. Затем однажды нам пришла в голову идея запустить ПО на нашем веб-сервере, используя браузер как интерфейс. Мы попробовали переписать ПО для работы через Веб, и стало ясно, что это правильный путь. Если бы мы написали ПО для работы на сервере, это сильно упростило бы жизнь и пользователям, и нам самим.

Это оказался хороший план. Сейчас, под именем Yahoo Store, это ПО — самый популярный конструктор онлайн-магазинов, у него около 14 000 пользователей.

Когда мы запустили Viaweb, мало кто понимал, что мы имеем в виду, когда говорили, что ПО работает на сервере. Только после запуска Hotmail годом позже люди начали понимать. Сейчас все знают, что это вполне рабочий подход. Появилось даже название для того, кем мы были: Application Service Provider, или ASP.

Я думаю, что значительная часть ПО следующего поколения будет написана по этой модели. Даже Microsoft, которой есть что терять больше всех, похоже, видит неизбежность переноса некоторых вещей с десктопа. Если ПО уйдёт с десктопа на серверы, это будет совсем другой мир для разработчиков. Эта статья описывает удивительные вещи, которые мы увидели, оказавшись одними из первых посетителей этого нового мира. В той мере, в какой ПО действительно переходит на серверы, то, что я здесь описываю, — это будущее.

Следующая большая вещь?

Когда мы оглянемся на эпоху desktop-софта, я думаю, мы будем удивляться неудобствам, с которыми мирились люди, точно так же, как сейчас удивляемся тому, с чем мирились первые автовладельцы. Первые двадцать-тридцать лет, чтобы владеть автомобилем, нужно было быть экспертом по автомобилям. Но автомобили были такой большой удачей, что многие люди, не будучи экспертами, всё равно хотели их иметь.

Компьютеры сейчас в этой фазе. Когда у вас есть настольный компьютер, в итоге вы узнаёте о происходящем внутри него гораздо больше, чем хотели бы. Но больше половины домохозяйств в США имеют такой. У моей мамы есть компьютер, который она использует для электронной почты и ведения счетов. Около года назад она встревожилась, получив письмо от Apple с предложением скидки на новую версию операционной системы. Что-то не так, когда шестидесятипятилетней женщине, которая хочет использовать компьютер для почты и счетов, приходится думать об установке новых операционных систем. Обычные пользователи не должны даже знать слов «операционная система», не говоря уже о «драйвере устройства» или «патче».

Сейчас появился другой способ доставлять ПО, который избавит пользователей от необходимости становиться системными администраторами. Веб-приложения — это программы, которые работают на веб-серверах и используют веб-страницы как пользовательский интерфейс. Для среднего пользователя этот новый тип ПО будет проще, дешевле, мобильнее, надёжнее и часто мощнее, чем desktop-софт.

С веб-приложениями большинству пользователей не придётся думать ни о чём, кроме самих приложений, которыми они пользуются. Вся беспорядочная, постоянно меняющаяся часть будет лежать где-то на сервере, обслуживаемая людьми, которые умеют это делать. И поэтому вам, по сути, не нужен будет компьютер как таковой, чтобы пользоваться ПО. Всё, что вам понадобится, — это что-то с клавиатурой, экраном и веб-браузером. Возможно, у него будет беспроводной интернет. Возможно, это будет ещё и ваш мобильный телефон. Что бы это ни было, это будет потребительская электроника: что-то стоимостью около 200 долларов, что люди выбирают в основном по внешнему виду корпуса. За интернет-сервисы вы будете платить больше, чем за оборудование, — так же, как сейчас с телефонами. [1]

Чтобы клик дошёл до сервера и обратно, потребуется около десятой доли секунды, поэтому пользователи интенсивно интерактивного ПО, такого как Photoshop, по-прежнему захотят, чтобы вычисления происходили на десктопе. Но если посмотреть, для чего большинство людей используют компьютеры, задержка в десятую секунды не была бы проблемой. Моей маме настольный компьютер не нужен, и таких людей, как она, очень много.

Выигрыш для пользователей

Рядом с моим домом есть машина с наклейкой на бампере: «Лучше смерть, чем неудобство». Большинство людей в большинстве случаев выберут тот вариант, который требует меньше усилий. Если веб-приложения победят, то потому, что они удобнее. И, похоже, именно так и будет — и для пользователей, и для разработчиков.

Чтобы пользоваться чисто веб-приложением, всё, что вам нужно, — это браузер, подключённый к интернету. Поэтому веб-приложением можно пользоваться где угодно. Когда вы устанавливаете ПО на свой настольный компьютер, вы можете пользоваться им только на этом компьютере. Хуже того, ваши файлы заперты на этом компьютере. Неудобство этой модели становится всё более очевидным по мере того, как люди привыкают к сетям.

Тонким концом клина здесь стала веб-почта. Миллионы людей теперь понимают, что доступ к электронной почте должен быть откуда угодно. И если вы можете видеть свою почту, почему не календарь? Если вы можете обсуждать документ с коллегами, почему не редактировать его? Почему какие-то ваши данные должны быть заперты на каком-то компьютере, стоящем на далёком столе?

Сама идея «вашего компьютера» уходит и заменяется на «ваши данные». Вы должны иметь возможность получить доступ к своим данным с любого компьютера. Точнее, с любого клиента, а клиент не обязан быть компьютером.

Клиенты не должны хранить данные; они должны быть как телефоны. Они, по сути, могут стать телефонами или наоборот. И по мере того, как клиенты становятся меньше, появляется ещё одна причина не хранить на них свои данные: то, что вы носите с собой, можно потерять или украсть. Оставить КПК в такси — это как сбой диска, только ваши данные передаются кому-то другому, а не испаряются.

С чисто веб-приложениями ни ваши данные, ни сами приложения не хранятся на клиенте. Поэтому вам не нужно ничего устанавливать, чтобы пользоваться ими. А когда нет установки, не нужно беспокоиться, что установка пойдёт не так. Не может быть несовместимости между приложением и вашей операционной системой, потому что ПО не работает на вашей операционной системе.

Поскольку установка не требуется, попробовать веб-приложение, прежде чем «купить» его, будет легко и обычно. Вы должны иметь возможность бесплатно протестировать любое веб-приложение, просто зайдя на сайт, где оно предлагается. В Viaweb весь наш сайт был как большая стрелка, указывающая пользователям на тест-драйв.

После пробы демо подписка на сервис должна требовать не больше, чем заполнить короткую форму (чем короче, тем лучше). И это должно быть последним действием, которое пользователю придётся сделать. С веб-приложениями вы должны получать новые релизы без доплаты, без всякой работы и, возможно, даже не зная об этом.

Апгрейды больше не будут такими шоками, как сейчас. Со временем приложения тихо станут мощнее. Это потребует определённых усилий от разработчиков. Им придётся проектировать ПО так, чтобы его можно было обновлять, не сбивая с толку пользователей. Это новая проблема, но способы её решения есть.

В веб-приложениях все пользуются одной и той же версией, и баги могут быть исправлены сразу, как только обнаружены. Поэтому в веб-приложениях должно быть гораздо меньше багов, чем в desktop-софте. В Viaweb я сомневаюсь, что у нас когда-либо было больше десяти известных багов одновременно. Это на порядки лучше, чем у desktop-софта.

Веб-приложениями могут пользоваться одновременно несколько человек. Это очевидная победа для совместных приложений, но я готов поспорить, что пользователи начнут хотеть этого в большинстве приложений, как только осознают, что это возможно. Часто будет полезно позволить двум людям редактировать один и тот же документ. Viaweb позволял нескольким пользователям редактировать сайт одновременно — скорее потому, что это был правильный способ написать ПО, чем потому, что мы ожидали, что пользователи захотят этого, но оказалось, что многие захотели.

Когда вы пользуетесь веб-приложением, ваши данные будут в большей безопасности. Сбои дисков не уйдут в прошлое, но пользователи о них больше не услышат. Они будут происходить в серверных фермах. И компании, предлагающие веб-приложения, будут реально делать резервные копии — не только потому, что у них будут настоящие системные администраторы, которые этим занимаются, но и потому, что ASP, который теряет данные пользователей, окажется в очень больших, очень больших неприятностях. Когда люди теряют собственные данные при сбое диска, они не могут сильно злиться, потому что злиться им не на кого, кроме себя. Когда компания теряет их данные за них, они разозлятся гораздо сильнее.

Наконец, веб-приложения должны быть менее уязвимы для вирусов. Если клиент не запускает ничего, кроме браузера, шансы запустить вирусы меньше, и локальных данных, которым можно навредить, нет. А программа, которая попыталась бы атаковать сами серверы, обнаружила бы, что они очень хорошо защищены. [2]

Для пользователей веб-приложения будут менее стрессовыми. Думаю, если бы можно было заглянуть внутрь среднего пользователя Windows, обнаружилось бы огромное и почти не реализованное желание ПО, отвечающего этому описанию. Высвобожденное, оно могло бы стать мощной силой.

Город кода

Для разработчиков самое заметное отличие веб-приложений от desktop-софта в том, что веб-приложение — это не один кусок кода. Это будет набор программ разных типов, а не один большой бинарник. И поэтому проектирование веб-ПО похоже на проектирование города, а не здания: помимо зданий нужны дороги, дорожные знаки, коммуникации, полиция и пожарная служба, а также планы как для роста, так и для разных видов катастроф.

В Viaweb ПО включало довольно крупные приложения, с которыми пользователи общались напрямую, программы, которыми эти программы пользовались, программы, которые постоянно работали в фоне в поиске проблем, программы, которые пытались перезапустить что-то, если оно сломалось, программы, которые периодически запускались, чтобы собирать статистику или строить индексы для поиска, программы, которые мы запускали явно для сборки ресурсов или перемещения и восстановления данных, программы, которые притворялись пользователями (чтобы измерять производительность или выявлять баги), программы для диагностики сетевых проблем, программы для бэкапов, интерфейсы к внешним сервисам, ПО, управлявшее впечатляющим набором циферблатов с реальной серверной статистикой (хит у посетителей, но необходимый и нам самим), модификации (включая исправления багов) к open-source ПО и огромное количество конфигурационных файлов и настроек. Тревор Блэквелл написал великолепную программу для переноса магазинов на новые серверы по всей стране без их остановки после того, как нас купил Yahoo. Программы отправляли нам сообщения на пейджер, рассылали факсы и письма пользователям, проводили транзакции с процессорами кредитных карт и общались друг с другом через сокеты, пайпы, http-запросы, ssh, udp-пакеты, разделяемую память и файлы. Часть Viaweb даже состояла из отсутствия программ, поскольку один из ключей безопасности в Unix — не запускать ненужные утилиты, которыми могут воспользоваться, чтобы взломать ваши серверы.

Этим дело не ограничивалось. Мы много времени думали о конфигурациях серверов. Мы собирали серверы сами из компонентов — отчасти чтобы сэкономить, отчасти чтобы получить именно то, что нам нужно. Нам приходилось думать, достаточно ли быстрые соединения у нашего вышестоящего ISP со всеми бэкбонами. Мы по очереди встречались с поставщиками RAID.

Но железо — это не только то, о чём надо беспокоиться. Когда вы его контролируете, вы можете больше сделать для пользователей. С desktop-приложением вы можете указать определённое минимальное железо, но не можете добавить ничего сверх. Если вы администрируете серверы, вы можете одним действием дать всем своим пользователям возможность вызывать кого-то на пейджер, отправлять факсы, посылать команды по телефону, обрабатывать кредитные карты и т. п. — просто установив соответствующее оборудование. Мы всегда искали новые способы добавлять функции через железо — не только потому, что это нравилось пользователям, но и как способ отстроиться от конкурентов, которые (либо потому, что продавали desktop-софт, либо потому, что перепродавали веб-приложения через ISP) не имели прямого контроля над железом.

Поскольку ПО в веб-приложении будет набором программ, а не одним бинарником, его можно писать на каком угодно числе разных языков. Когда вы пишете desktop-софт, вы практически вынуждены писать приложение на том же языке, что и базовая операционная система, — то есть на C и C++. И поэтому эти языки (особенно среди нетехнических людей, таких как менеджеры и VC) стали считаться языками для «серьёзной» разработки ПО. Но это был просто артефакт того, как desktop-софт приходилось доставлять. Для серверного ПО вы можете использовать любой язык, какой хотите. [3] Сегодня многие из топовых хакеров используют языки, очень далёкие от C и C++: Perl, Python и даже Lisp.

С серверным ПО никто не может указать вам, какой язык использовать, потому что вы контролируете всю систему, вплоть до железа. Разные языки хороши для разных задач. Вы можете использовать тот, который лучше всего подходит для каждой. А когда у вас есть конкуренты, «вы можете» означает «вы должны» (мы ещё вернёмся к этому), потому что если вы не воспользуетесь этой возможностью, то воспользуются ваши конкуренты.

Большинство наших конкурентов использовали C и C++, и это делало их ПО заметно хуже, потому что (помимо прочего) у них не было способа обойти безсостоятельность CGI-скриптов. Если вы хотели что-то поменять, все изменения должны были происходить на одной странице с кнопкой Update внизу. Как я писал в другом месте, используя Lisp, который многие до сих пор считают исследовательским языком, мы смогли заставить редактор Viaweb вести себя больше как desktop-софт.

Релизы

Одно из важнейших изменений в этом новом мире — то, как вы делаете релизы. В desktop-индустрии релиз — это огромная травма, в которой вся компания потеет и напрягается, чтобы выпихнуть один гигантский кусок кода. Очевидные сравнения напрашиваются и с процессом, и с получаемым продуктом.

С серверным ПО вы можете вносить изменения почти так же, как делали бы это в программе, которую пишете для себя. Вы выпускаете ПО как серию инкрементальных изменений, а не как редкий большой взрыв. Типичная компания, делающая desktop-софт, может делать один-два релиза в год. В Viaweb мы часто делали от трёх до пяти релизов в день.

Когда вы переходите на эту новую модель, вы осознаёте, насколько разработка ПО зависит от того, как оно выпускается. Многие из самых неприятных проблем в desktop-индустрии связаны с катастрофичной природой релизов.

Когда вы выпускаете только одну новую версию в год, вы склонны разбираться с багами оптом. Где-то перед датой релиза вы собираете новую версию, в которой половина кода вырвана и заменена, что вносит бесчисленные баги. Затем приходит команда QA и начинает их подсчитывать, а программисты идут по списку, исправляя их. Они обычно не доходят до конца списка, да и вообще никто точно не знает, где этот конец. Это как доставать обломки из пруда. Вы никогда по-настоящему не знаете, что происходит внутри ПО. В лучшем случае вы получаете что-то вроде статистической корректности.

С серверным ПО большинство изменений малы и инкрементальны. Уже это само по себе с меньшей вероятностью вносит баги. Это также значит, что вы знаете, что нужно тщательнее всего протестировать перед релизом ПО: последнее, что вы изменили. У вас гораздо более крепкая хватка над кодом. Как правило, вы знаете, что происходит внутри него. Конечно, вы не помните исходник наизусть, но когда вы его читаете, то делаете это как пилот, осматривающий приборную панель, а не как детектив, пытающийся раскрыть тайну.

Desktop-софт порождает определённый фатализм по отношению к багам. Вы знаете, что выпускаете нечто, набитое багами, и даже завели механизмы компенсации этого (например, патч-релизы). Так зачем переживать о ещё нескольких? Вскоре вы выпускаете целые функции, которые, как вы знаете, сломаны. Apple сделала это в этом году. Они чувствовали давление выпустить свою новую ОС, дата релиза которой уже была сдвинута четырежды, но часть ПО (поддержка CD и DVD) не была готова. Решение? Они выпустили ОС без недоделанных частей, и пользователям придётся доустановить их позже.

С веб-приложениями вы никогда не должны выпускать ПО до того, как оно работает, и можете выпустить его, как только оно работает.

Ветеран индустрии может подумать: красиво звучит, что не нужно выпускать ПО до того, как оно работает, но что если вы пообещали поставить новую версию своего ПО к определённой дате? С веб-приложениями вы не давали бы такого обещания, потому что нет версий. Ваше ПО меняется постепенно и непрерывно. Какие-то изменения могут быть больше других, но идея версий просто не ложится естественно на веб-приложения.

Если кто-то помнит Viaweb, это может показаться странным, потому что мы всё время анонсировали новые версии. Это делалось исключительно для PR. Деловая пресса, как мы выяснили, мыслит номерами версий. Они дадут вам большой материал за крупный релиз, означающий новую первую цифру в номере версии, и, как правило, максимум абзац за точечный релиз — новую цифру после десятичной точки.

Некоторые наши конкуренты предлагали desktop-софт и реально имели номера версий. И за эти релизы, сам факт которых казался нам свидетельством их отсталости, они получали всевозможную публичность. Мы не хотели это пропускать, поэтому начали тоже присваивать номера версий своему ПО. Когда нам нужна была публичность, мы составляли список всех функций, которые мы добавили со времени последнего «релиза», лепили новый номер версии на ПО и выпускали пресс-релиз о том, что новая версия теперь доступна. Удивительно, но никто никогда нас на этом не подловил.

К моменту, когда нас купили, мы делали это трижды, так что были на Версии 4. Если правильно помню, Версии 4.1. После того, как Viaweb стал Yahoo Store, такой отчаянной нужды в публичности больше не было, поэтому, хотя ПО продолжало развиваться, вся идея номеров версий была тихо отброшена.

Баги

Другое крупное техническое преимущество веб-приложений в том, что вы можете воспроизвести большинство багов. Данные пользователей у вас прямо на диске. Если кто-то ломает ваше ПО, вам не нужно гадать, что происходит, как было бы с desktop-софтом: вы должны быть в состоянии воспроизвести ошибку, пока пользователь говорит с вами по телефону. Возможно, вы даже уже знаете об ошибке, если в ваше приложение встроен код для обнаружения ошибок.

Веб-ПО используется круглосуточно, поэтому всё, что вы делаете, тут же прогоняется через мясорубку. Баги всплывают быстро.

Софтверные компании иногда обвиняют в том, что они позволяют пользователям отлаживать своё ПО. И это именно то, что я отстаиваю. Для веб-ПО это вполне хороший план, потому что багов меньше и они недолговечны. Когда вы выпускаете ПО постепенно, багов изначально гораздо меньше. А когда вы можете воспроизводить ошибки и выпускать изменения мгновенно, вы можете находить и исправлять большинство багов сразу, как они появляются. У нас никогда не было достаточно багов одновременно, чтобы заморачиваться формальной системой отслеживания багов.

Конечно, изменения нужно тестировать перед релизом, чтобы крупных багов не выпускалось. Те немногие, что неизбежно проскальзывают, будут касаться граничных случаев и затронут лишь нескольких пользователей, которые столкнутся с ними до того, как кто-то позвонит и пожалуется. Если вы исправляете баги сразу же, чистый эффект для среднего пользователя — гораздо меньше багов. Сомневаюсь, что средний пользователь Viaweb когда-либо видел баг.

Исправлять свежие баги легче, чем старые. В коде, который вы только что написали, баг обычно находится довольно быстро. Когда он всплывает, вы часто знаете, что не так, ещё до того, как заглянете в исходник, потому что вы уже подсознательно об этом беспокоились. Исправление бага в чём-то, что вы написали полгода назад (средний случай, если вы релизитесь раз в год), — это гораздо больше работы. И поскольку вы хуже понимаете код, скорее всего, исправите криво или даже внесёте ещё больше багов. [4]

Когда вы ловите баги рано, вы также получаете меньше составных багов. Составные баги — это два отдельных бага, которые взаимодействуют: вы спотыкаетесь, спускаясь по лестнице, и когда тянетесь к перилам, они отламываются у вас в руке. В ПО такие баги найти сложнее всего, и последствия у них обычно самые худшие. [5] Традиционный подход «сломать всё, а потом отфильтровать баги» по своей природе порождает много составных багов. А ПО, выпускаемое сериями маленьких изменений, по своей природе склонно их не порождать. Полы постоянно подметаются, и на них не остаётся каких-либо незакреплённых предметов, которые могли бы потом застрять в чём-то.

Помогает, если вы используете технику под названием функциональное программирование. Функциональное программирование означает избегание побочных эффектов. Это то, что чаще встречается в исследовательских статьях, чем в коммерческом ПО, но для веб-приложений оказывается действительно полезным. Сложно написать целые программы как чисто функциональный код, но значительные куски можно написать так. Это делает эти части вашего ПО проще для тестирования, потому что у них нет состояния, что очень удобно, когда вы постоянно делаете и тестируете маленькие изменения. Большую часть редактора Viaweb я написал в этом стиле, а наш скриптовый язык RTML мы сделали чисто функциональным.

Людям из desktop-индустрии будет трудно в это поверить, но в Viaweb баги стали почти игрой. Поскольку большинство выпущенных багов касались граничных случаев, пользователи, которые с ними сталкивались, как правило, были продвинутыми — теми, кто исследовал границы возможного. Продвинутые пользователи более снисходительны к багам, особенно потому, что вы, вероятно, ввели их в процессе добавления какой-то фичи, о которой они сами просили. На самом деле, поскольку баги были редкими и чтобы их увидеть, нужно было делать что-то сложное, продвинутые пользователи часто гордились, что поймали один. Они звонили в саппорт скорее с триумфом, чем с гневом, как будто заработали очки против нас.

Поддержка

Когда вы можете воспроизводить ошибки, это меняет ваш подход к клиентской поддержке. В большинстве софтверных компаний поддержка предлагается как способ заставить клиентов чувствовать себя лучше. Они либо звонят вам по поводу известного бага, либо просто делают что-то не так, и вам нужно выяснить, что именно. В любом случае многому от них вы не научитесь. И поэтому вы склонны рассматривать звонки в поддержку как геморрой, который вы хотите как можно дальше изолировать от своих разработчиков.

В Viaweb всё было не так. В Viaweb поддержка была бесплатной, потому что мы хотели слышать клиентов. Если у кого-то была проблема, мы хотели узнать об этом сразу, чтобы воспроизвести ошибку и выпустить исправление.

Поэтому в Viaweb разработчики были в постоянном тесном контакте с поддержкой. Сотрудники клиентской поддержки сидели примерно в десяти метрах от программистов и знали, что могут прервать что угодно сообщением о настоящем баге. Мы уходили со встречи совета директоров, чтобы исправить серьёзный баг.

Наш подход к поддержке делал всех счастливее. Клиенты были в восторге. Только представьте, каково это — позвонить на линию поддержки и быть принятым как человек, приносящий важные новости. Сотрудникам поддержки это нравилось, потому что они могли реально помогать пользователям, а не читать им скрипты. А программистам это нравилось, потому что они могли воспроизводить баги, а не слышать смутные пересказы о них из вторых рук.

Наша политика исправлять баги на лету изменила отношения между сотрудниками поддержки и хакерами. В большинстве софтверных компаний сотрудники поддержки — это недооплачиваемые живые щиты, а хакеры — маленькие копии Бога-Отца, создатели мира. Какой бы ни была процедура сообщения о багах, она, скорее всего, односторонняя: сотрудники поддержки, услышав о баге, заполняют какую-то форму, которая в итоге передаётся (возможно, через QA) программистам, которые добавляют это в свой список дел. В Viaweb всё было совсем иначе. В течение минуты после того, как сотрудник поддержки услышит о баге от клиента, он мог стоять рядом с программистом и слышать, как тот говорит: «Чёрт, ты прав, это баг». Сотрудникам поддержки нравилось слышать это «ты прав» от хакеров. Они приносили нам баги с тем же ожидающим видом, с каким кошка приносит вам только что убитую мышь. Это также делало их внимательнее в оценке серьёзности бага, потому что теперь на кону была их репутация.

После того как нас купил Yahoo, сотрудников поддержки перевели далеко от программистов. Только тогда мы осознали, что они фактически выполняли роль QA и в какой-то мере маркетинга. Помимо ловли багов, они были хранителями знаний о более размытых, баго-подобных вещах — например, о фичах, сбивавших пользователей с толку. [6] Они также были своего рода прокси-фокус-группой: мы могли спросить их, какую из двух новых фич пользователи хотят больше, и они всегда были правы.

Боевой дух

Возможность выпускать ПО немедленно — большой мотиватор. Часто, идя на работу, я думал о каком-то изменении, которое хотел внести в ПО, и делал его в тот же день. Это работало и для более крупных фич. Даже если что-то требовало двух недель на написание (мало какие проекты занимали больше), я знал, что увижу эффект в ПО, как только оно будет готово.

Если бы мне пришлось ждать год до следующего релиза, я бы отложил большинство этих идей на полку — хотя бы на время. Но в идеях вот что: они порождают новые идеи. Замечали ли вы, что когда вы садитесь что-то писать, половина идей, оказывающихся в тексте, — это те, которые вы придумали уже во время написания? То же самое с ПО. Работа над реализацией одной идеи даёт вам больше идей. Поэтому, откладывая идею на полку, вы теряете не только эту задержку в реализации, но и все те идеи, к которым реализация привела бы. На самом деле, отложенная идея, вероятно, даже подавляет новые идеи: когда вы начинаете думать о какой-то новой фиче, вы краем глаза замечаете полку и думаете: «но у меня уже полно нового, что я хочу сделать к следующему релизу».

Большие компании вместо реализации фич их планируют. В Viaweb мы из-за этого иногда попадали в неловкие ситуации. Инвесторы и аналитики спрашивали нас, что мы планируем на будущее. Честным ответом было бы: у нас нет никаких планов. У нас были общие идеи о том, что мы хотим улучшить, но если бы мы знали как, мы бы это уже сделали. Что мы собирались делать в ближайшие полгода? Что бы ни казалось самой большой победой. Не знаю, осмеливался ли я когда-либо дать такой ответ, но это была правда. Планы — просто другое слово для идей на полке. Когда нам приходили хорошие идеи, мы их реализовывали.

В Viaweb, как и во многих софтверных компаниях, у большей части кода был один определённый владелец. Но когда вы чем-то владели, вы действительно этим владели: никто, кроме владельца куска ПО, не должен был одобрять (или даже знать) о релизе. Не было никакой защиты от поломок, кроме страха выглядеть идиотом перед коллегами, и этого было более чем достаточно. Возможно, я создал впечатление, что мы беспечно пёрли вперёд, штампуя код. Мы действительно шли быстро, но очень тщательно думали, прежде чем выпустить ПО на эти серверы. И внимание гораздо важнее для надёжности, чем медленные движения. Благодаря пристальному вниманию пилот ВМФ может посадить 40 000-фунтовый самолёт со скоростью 140 миль в час на качающуюся палубу авианосца ночью безопаснее, чем средний подросток режет рогалик.

Конечно, такой способ написания ПО — обоюдоострый меч. Он работает гораздо лучше для маленькой команды хороших, надёжных программистов, чем работал бы в большой компании с посредственными, где плохие идеи отлавливают комитеты, а не люди, у которых они возникли.

Брукс наоборот

К счастью, для веб-ПО действительно нужно меньше программистов. Однажды я работал в средней desktop-софтверной компании, где в инженерии в целом было больше 100 человек. Только 13 из них занимались разработкой продукта. Все остальные работали над релизами, портами и тому подобным. С веб-ПО всё, что вам нужно (максимум), — это эти 13 человек, потому что нет релизов, портов и тому подобного.

Viaweb был написан всего тремя людьми. [7] Я всё время был под давлением нанять ещё, потому что мы хотели, чтобы нас купили, и знали, что покупателям будет трудно заплатить высокую цену за компанию всего с тремя программистами. (Решение: мы наняли ещё, но создавали для них новые проекты.)

Когда вы можете писать ПО с меньшим числом программистов, это экономит больше, чем деньги. Как заметил Фред Брукс в The Mythical Man-Month, добавление людей в проект, как правило, замедляет его. Число возможных связей между разработчиками растёт экспоненциально с размером группы. Чем больше группа, тем больше времени они будут проводить на встречах, договариваясь, как их ПО будет работать вместе, и тем больше багов получат от непредвиденных взаимодействий. К счастью, этот процесс работает и в обратную сторону: по мере уменьшения групп разработка ПО становится экспоненциально эффективнее. Не помню, чтобы у программистов Viaweb когда-либо было настоящее собрание. У нас никогда не было больше того, что можно сказать за один раз, чем мы успевали сказать по дороге на обед.

Если у этого и есть минус, то он в том, что все программисты должны быть в какой-то степени и системными администраторами. Когда вы хостите ПО, кто-то должен следить за серверами, и на практике делать это как следует могут только те, кто это ПО написал. В Viaweb наша система имела столько компонентов и менялась так часто, что не было чёткой границы между ПО и инфраструктурой. Произвольно проведённая граница ограничила бы наши проектные решения. И поэтому, хотя мы постоянно надеялись, что однажды («через пару месяцев») всё будет достаточно стабильно, чтобы мы могли нанять человека, чья работа — только беспокоиться о серверах, этого так и не случилось.

Не думаю, что могло быть иначе, пока вы активно развиваете продукт. Веб-ПО никогда не будет тем, что вы пишете, коммитите и идёте домой. Это живая штука, прямо сейчас работающая на ваших серверах. Плохой баг может не просто положить процесс одного пользователя — он может положить их все. Если баг в вашем коде портит какие-то данные на диске, вам нужно его исправить. И так далее. Мы обнаружили, что не обязательно следить за серверами каждую минуту (после первого года или около того), но за тем, что вы недавно меняли, точно надо приглядывать. Вы не выпускаете код поздно ночью и потом идёте домой.

Наблюдение за пользователями

С серверным ПО вы в более тесном контакте со своим кодом. И вы также можете быть в более тесном контакте со своими пользователями. Intuit знаменита тем, что представлялась клиентам в розничных магазинах и просилась пойти с ними домой. Если вы когда-либо смотрели, как кто-то впервые использует ваше ПО, вы знаете, какие сюрпризы их, должно быть, ждали.

ПО должно делать то, что пользователи думают, оно будет делать. Но вы понятия не имеете, что пользователи будут думать, поверьте мне, пока не посмотрите на них. И серверное ПО даёт вам беспрецедентную информацию об их поведении. Вы не ограничены небольшими, искусственными фокус-группами. Вы можете видеть каждый клик каждого пользователя. Нужно тщательно подумать, на что именно смотреть, потому что вы не хотите нарушать приватность пользователей, но даже самая общая статистическая выборка может быть очень полезна.

Когда пользователи у вас на сервере, вам, например, не нужно полагаться на бенчмарки. Бенчмарки — это симулированные пользователи. С серверным ПО вы можете наблюдать реальных пользователей. Чтобы решить, что оптимизировать, просто зайдите на сервер и посмотрите, что съедает весь CPU. И вы также знаете, когда остановиться с оптимизацией: мы в итоге довели редактор Viaweb до состояния, когда он упирался в память, а не в CPU, и поскольку мы ничего не могли сделать, чтобы уменьшить размер данных пользователей (ну, ничего лёгкого), мы поняли, что можно остановиться.

Эффективность важна для серверного ПО, потому что вы платите за железо. Число пользователей, которое вы можете поддерживать на сервере, — это делитель ваших капитальных затрат, поэтому, если вы сделаете своё ПО очень эффективным, вы сможете продавать дешевле конкурентов и всё равно получать прибыль. В Viaweb мы снизили капитальные затраты на пользователя примерно до 5 долларов. Сейчас было бы меньше — вероятно, меньше, чем стоимость отправки им счёта за первый месяц. Железо сейчас бесплатно, если ваше ПО разумно эффективно.

Наблюдение за пользователями может направлять вас и в дизайне, и в оптимизации. У Viaweb был скриптовый язык RTML, позволявший продвинутым пользователям определять собственные стили страниц. Мы обнаружили, что RTML стал чем-то вроде ящика предложений, потому что пользователи прибегали к нему только тогда, когда предустановленные стили страниц не могли сделать то, что они хотели. Изначально редактор размещал панели кнопок поперёк страницы, но после того, как ряд пользователей с помощью RTML разместили кнопки слева сбоку, мы сделали это опцией (фактически дефолтной) в предустановленных стилях страниц.

Наконец, наблюдая за пользователями, вы часто можете понять, когда у них возникают трудности. А поскольку клиент всегда прав, это признак того, что вам нужно что-то исправить. В Viaweb ключом к привлечению пользователей был онлайн-тест-драйв. Это была не просто серия слайдов, сделанная маркетологами. В нашем тест-драйве пользователи реально использовали ПО. Это занимало примерно пять минут, и в конце они построили настоящий, работающий магазин.

Тест-драйв был тем способом, которым мы получали почти всех своих новых пользователей. Думаю, для большинства веб-приложений будет так же. Если пользователи могут успешно пройти тест-драйв, продукт им понравится. Если они запутаются или заскучают, нет. Поэтому всё, что мы могли сделать, чтобы провести больше людей через тест-драйв, увеличивало нашу скорость роста.

Я изучал клик-трейлы людей, проходящих тест-драйв, и обнаружил, что на определённом шаге они путались и нажимали кнопку Назад в браузере. (Если вы попробуете писать веб-приложения, обнаружите, что кнопка Назад становится одной из самых интересных философских проблем.) Поэтому я добавил в этом месте сообщение, говорящее пользователям, что они почти закончили, и напоминающее не нажимать кнопку Назад. Ещё одна классная вещь в веб-ПО — то, что от изменений вы получаете мгновенный фидбэк: число людей, завершающих тест-драйв, сразу выросло с 60% до 90%. А поскольку число новых пользователей было функцией от числа завершённых тест-драйвов, наш рост выручки увеличился на 50% — только за счёт этого изменения.

Деньги

В начале 1990-х я читал статью, в которой кто-то говорил, что ПО — это бизнес подписки. Сначала это показалось мне очень циничным утверждением. Но потом я понял, что оно отражает реальность: разработка ПО — непрерывный процесс. Думаю, чище брать плату по подписке открыто, а не вынуждать людей покупать и устанавливать новые версии, чтобы они продолжали вам платить. И к счастью, подписки — естественный способ выставлять счета за веб-приложения.

Хостинг приложений — это область, где компании сыграют роль, которую вряд ли заполнит freeware. Хостинг приложений — это большой стресс, и у него есть реальные расходы. Никто не захочет делать это бесплатно.

Для компаний веб-приложения — идеальный источник дохода. Вместо того чтобы начинать каждый квартал с чистого листа, у вас есть рекуррентный поток выручки. Поскольку ваше ПО развивается постепенно, вам не нужно беспокоиться, что новая модель провалится; никакой новой модели как таковой быть не должно, и если вы сделаете с ПО что-то, что пользователи ненавидят, вы узнаете об этом сразу. У вас нет проблем с невыплаченными счетами; если кто-то не платит, вы просто отключаете сервис. И нет возможности пиратства.

Это последнее «преимущество» может оказаться проблемой. Некоторый объём пиратства — на руку софтверным компаниям. Если какой-то пользователь точно не купил бы ваше ПО ни за какую цену, вы ничего не теряете, если он пользуется пиратской копией. На самом деле вы выигрываете, потому что он — ещё один пользователь, помогающий сделать ваше ПО стандартом, или, может, купит копию позже, когда окончит школу.

Когда могут, компании любят делать кое-что под названием ценовая дискриминация — назначать каждому клиенту цену, которую тот может себе позволить. [8] ПО особенно подходит для ценовой дискриминации, потому что предельная себестоимость близка к нулю. Поэтому некоторый софт стоит дороже для запуска на машинах Sun, чем на Intel: компания, использующая Sun, не заинтересована в экономии, и с неё можно безопасно брать больше. Пиратство фактически является нижним уровнем ценовой дискриминации. Думаю, софтверные компании это понимают и намеренно закрывают глаза на некоторые виды пиратства. [9] С серверным ПО им придётся придумывать какое-то другое решение.

Веб-ПО хорошо продаётся, особенно по сравнению с desktop-софтом, потому что его легко купить. Вы можете думать, что люди сначала решают купить что-то, а потом покупают это, как два отдельных шага. Я так и думал до Viaweb, в той мере, в какой вообще думал об этом вопросе. На самом деле второй шаг может откатываться назад в первый: если что-то трудно купить, люди передумают, хотели ли они этого. И наоборот: вы продадите больше чего-то, когда это легко купить. Я покупаю больше книг, потому что существует Amazon. Веб-ПО — пожалуй, самое лёгкое в мире для покупки, особенно если только что было онлайн-демо. Пользователю не должно требоваться многим больше, чем ввести номер кредитной карты. (Заставлять делать больше — на свой страх и риск.)

Иногда веб-ПО предлагается через ISP, действующих как реселлеры. Это плохая идея. Вы должны сами администрировать серверы, потому что вам нужно постоянно улучшать и железо, и ПО. Если вы отдаёте прямой контроль над серверами, вы отдаёте большинство преимуществ разработки веб-приложений.

Несколько наших конкурентов прострелили себе ногу таким образом — обычно, как я думаю, потому, что их перехватили костюмчики, возбуждённые этим огромным потенциальным каналом и не понимавшие, что он погубит продукт, который они через него надеялись продавать. Продавать веб-ПО через ISP — это как продавать суши через торговые автоматы.

Клиенты

Кем будут клиенты? В Viaweb это изначально были частные лица и небольшие компании, и я думаю, это будет правилом для веб-приложений. Это те пользователи, которые готовы пробовать новое, отчасти потому что они более гибкие, и отчасти потому что им нужны более низкие издержки новых технологий.

Веб-приложения часто будут лучшим выбором и для больших компаний (хотя они будут медленно это осознавать). Лучший интранет — это интернет. Если компания использует настоящие веб-приложения, ПО будет работать лучше, серверы будут лучше администрироваться, а сотрудники смогут получать доступ к системе откуда угодно.

Аргумент против такого подхода обычно сводится к безопасности: если доступ легче для сотрудников, то и для злоумышленников тоже. Некоторые крупные мерчанты не хотели использовать Viaweb, потому что думали, что данные кредитных карт их клиентов будут в большей безопасности на их собственных серверах. Это было непросто донести дипломатично, но на самом деле данные почти наверняка были в большей безопасности у нас, чем у них. Кто может нанять лучших людей для управления безопасностью — технологический стартап, чей весь бизнес — запускать серверы, или продавец одежды? У нас были не только лучшие люди, занимавшиеся безопасностью, мы и беспокоились о ней больше. Если кто-то взламывал серверы продавца одежды, это затрагивало максимум одного мерчанта, вероятно, могло быть замолчано, и в худшем случае мог быть уволен один человек. Если кто-то взламывал наши серверы, это могло затронуть тысячи мерчантов, вероятно, попало бы в новости CNet и могло вывести нас из бизнеса.

Если вы хотите сохранить деньги в безопасности, держите ли вы их под матрасом дома или несёте в банк? Этот аргумент применим к каждому аспекту администрирования серверов: не только к безопасности, но и к аптайму, пропускной способности, управлению нагрузкой, бэкапам и т. п. Наше существование зависело от того, чтобы делать это правильно. Серверные проблемы были для нас большим табу — как опасная игрушка для производителя игрушек или вспышка сальмонеллёза для переработчика пищи.

Большая компания, использующая веб-приложения, в этой части аутсорсит ИТ. Как бы радикально это ни звучало, думаю, в целом это хорошая идея. Компании, скорее всего, получат лучший сервис таким образом, чем от внутренних системных администраторов. Системные администраторы могут стать вредными и неотзывчивыми, потому что они не подвергаются напрямую конкурентному давлению: продавцу приходится иметь дело с клиентами, разработчику — с ПО конкурентов, а у системного администратора, как у старого холостяка, мало внешних сил, чтобы держать его в форме. [10] В Viaweb у нас было полно внешних сил, чтобы держать нас в тонусе. Звонившие нам люди были клиентами, а не просто коллегами. Если сервер залипал, мы вскакивали; даже мысль об этом до сих пор даёт мне выброс адреналина, годы спустя.

Так что веб-приложения обычно будут правильным ответом и для больших компаний. Однако они будут последними, кто это осознает, точно так же, как было с настольными компьютерами. И отчасти по той же причине: будут стоить немалых денег усилия убедить большие компании, что им нужно что-то более дорогое.

Всегда есть тенденция, что богатые клиенты покупают дорогие решения, даже когда дешёвые лучше, потому что те, кто предлагает дорогие решения, могут больше тратить на их продажу. В Viaweb мы всё время с этим сталкивались. Мы потеряли несколько хайэндных мерчантов, ушедших к веб-консалтинговым фирмам, которые убеждали их, что им будет лучше, если они заплатят полмиллиона долларов за кастомный онлайн-магазин на своём собственном сервере. Как правило, им было не лучше, что обнаружил не один из них, когда наступал рождественский сезон шопинга и нагрузка на их серверы росла. Viaweb был гораздо более продвинутым, чем то, что большинство этих мерчантов получали, но мы не могли позволить себе им об этом рассказать. При цене 300 долларов в месяц мы не могли позволить себе посылать команду хорошо одетых и убедительно звучащих людей делать презентации клиентам.

Большая часть того, за что доплачивают большие компании, — это затраты на продажу им дорогих вещей. (Если Министерство обороны платит тысячу долларов за крышку унитаза, это отчасти потому, что продажа крышек унитаза по тысяче долларов сама по себе обходится дорого.) И это одна из причин, почему интранет-ПО будет процветать дальше, хотя это, вероятно, плохая идея. Оно просто дороже. С этой загадкой ничего не сделать, поэтому лучший план — сначала идти за более мелкими клиентами. Остальные придут со временем.

Сын сервера

Запуск ПО на сервере — ничего нового. На самом деле это старая модель: приложения для мейнфреймов все серверные. Если серверное ПО — такая хорошая идея, почему оно проиграло в прошлый раз? Почему настольные компьютеры затмили мейнфреймы?

Поначалу настольные компьютеры не выглядели большой угрозой. Первыми пользователями были все хакерами — или хоббистами, как тогда говорили. Им нравились микрокомпьютеры, потому что они были дешёвые. Впервые у вас мог быть собственный компьютер. Фраза «персональный компьютер» сейчас часть языка, но когда её только начали использовать, она звучала намеренно дерзко, как сегодня прозвучала бы фраза «персональный спутник».

Почему настольные компьютеры захватили рынок? Думаю, потому, что у них было лучше ПО. И, думаю, причина того, что ПО для микрокомпьютеров было лучше, в том, что его могли писать маленькие компании.

Не думаю, что многие осознают, насколько хрупки и неуверены стартапы на самой ранней стадии. Многие стартапы начинаются почти случайно — пара парней либо с дневной работой, либо в учебном заведении пишут прототип чего-то, что, если будет выглядеть многообещающе, может превратиться в компанию. На этой личиночной стадии любое значимое препятствие остановит стартап мёртво на месте. Писать ПО для мейнфреймов требовало слишком большого первоначального коммитмента. Девелоперские машины были дорогими, а поскольку клиентами были бы большие компании, вам бы понадобился внушительно выглядящий отдел продаж, чтобы продавать им. Запустить стартап для написания ПО для мейнфреймов было бы гораздо более серьёзным предприятием, чем просто сколачивать что-то на своём Apple II вечерами. И поэтому стартапов, пишущих приложения для мейнфреймов, было немного.

Появление настольных компьютеров вдохновило много нового ПО, потому что написание приложений для них казалось личиночным стартапам достижимой целью. Разработка была дешёвой, а клиентами становились отдельные люди, до которых можно было достучаться через компьютерные магазины или даже по почтовым каталогам.

Приложением, вытолкнувшим настольные компьютеры в мейнстрим, был VisiCalc — первая электронная таблица. Его написали два парня, работавших на чердаке, и всё же он делал то, что не могло делать никакое ПО для мейнфреймов. [11] VisiCalc был таким прорывом для своего времени, что люди покупали Apple II просто чтобы запустить его. И это было началом тренда: настольные компьютеры победили, потому что стартапы писали для них ПО.

Похоже, что серверное ПО на этот раз будет хорошим, потому что его будут писать стартапы. Компьютеры сейчас настолько дёшевы, что можно начинать, как делали мы, используя настольный компьютер в качестве сервера. Недорогие процессоры съели рынок рабочих станций (вы сейчас редко даже слышите это слово) и большую часть пути прошли по серверному рынку; в серверах Yahoo, обрабатывающих нагрузки не меньшие, чем где-либо в интернете, стоят те же недорогие процессоры Intel, что и в вашей настольной машине. А после того, как вы написали ПО, всё, что вам нужно, чтобы его продавать, — это веб-сайт. Почти все наши пользователи приходили на наш сайт напрямую — через сарафанное радио и упоминания в прессе. [12]

Viaweb был типичным личиночным стартапом. Нам было страшно создавать компанию, и первые несколько месяцев мы успокаивали себя, считая всё это экспериментом, который можем в любой момент свернуть. К счастью, препятствий, кроме технических, было мало. Пока мы писали ПО, нашим веб-сервером была та же настольная машина, которую мы использовали для разработки, подключённая к внешнему миру по dial-up. Нашими единственными расходами на этой стадии были еда и квартплата.

Сейчас у стартапов ещё больше причин писать веб-ПО, потому что писать desktop-софт стало гораздо менее весело. Если сейчас вы хотите писать desktop-софт, вы делаете это на условиях Microsoft, вызывая их API и обходя их баговую ОС. И если вам удастся написать что-то взлетевшее, может выясниться, что вы попросту делали маркетинговые исследования для Microsoft.

Если компания хочет сделать платформу, на которой стартапы будут что-то строить, она должна сделать её такой, чтобы хакеры сами захотели её использовать. Это значит, что она должна быть недорогой и хорошо спроектированной. Mac был популярен у хакеров, когда только вышел, и многие из них писали для него ПО. [13] С Windows такого вы видите меньше, потому что хакеры им не пользуются. Те люди, которые хороши в написании ПО, сейчас, как правило, гоняют Linux или FreeBSD.

Не думаю, что мы бы запустили стартап, чтобы писать desktop-софт, потому что desktop-софт должен работать на Windows, а прежде чем писать ПО для Windows, нам пришлось бы ею пользоваться. Веб позволил нам обойти Windows стороной и доставлять ПО, работающее на Unix, прямо пользователям через браузер. Это освобождающая перспектива, очень похожая на появление ПК двадцать пять лет назад.

Microsoft

Когда появились настольные компьютеры, гигантом, которого все боялись, была IBM. Сейчас это сложно представить, но я очень хорошо помню это ощущение. Сейчас пугающий гигант — Microsoft, и не думаю, что они так же слепы к нависающей над ними угрозе, как была IBM. В конце концов, Microsoft сознательно построила свой бизнес в слепой зоне IBM.

Я уже упоминал, что моей маме на самом деле не нужен настольный компьютер. Большинству пользователей, наверное, тоже. Это проблема для Microsoft, и они это знают. Если приложения работают на удалённых серверах, никому не нужна Windows. Что будет делать Microsoft? Смогут ли они использовать свой контроль над десктопом, чтобы предотвратить или ограничить это новое поколение ПО?

Моё предположение — Microsoft разработает какой-то серверно-десктопный гибрид, где ОС работает в связке с серверами, которые они контролируют. Как минимум, файлы будут централизованно доступны для пользователей, которые этого хотят. Не ожидаю, что Microsoft пойдёт до конца, в крайность с вычислениями на сервере и одним лишь браузером в качестве клиента, если может избежать этого. Если на клиенте нужен только браузер, на клиенте не нужна Microsoft, а если Microsoft не контролирует клиента, она не может подталкивать пользователей к своим серверным приложениям.

Думаю, Microsoft будет нелегко удержать джинна в бутылке. Будет слишком много разных типов клиентов, чтобы они могли контролировать их все. И если приложения Microsoft работают только с некоторыми клиентами, конкуренты смогут переиграть их, предложив приложения, работающие на любом клиенте. [14]

В мире веб-приложений нет автоматического места для Microsoft. Они могут добиться того, чтобы занять там место, но не думаю, что будут доминировать в этом новом мире, как доминировали в мире desktop-приложений.

Дело не столько в том, что конкурент их подставит, сколько в том, что они сами споткнутся. С подъёмом веб-ПО они столкнутся не только с техническими проблемами, но и со своим собственным желаемым за действительное. То, что им нужно сделать, — это каннибализировать свой существующий бизнес, и я не вижу, чтобы они с этим столкнулись лицом к лицу. Та самая целеустремлённость, которая привела их сюда, теперь будет работать против них. IBM была в точно такой же ситуации, и они с ней не справились. IBM сделала позднее и половинчатое вхождение в бизнес микрокомпьютеров, потому что им было сложно угрожать своей дойной корове — мейнфреймовому компьютингу. Microsoft точно так же будет ограничена желанием спасти десктоп. Дойная корова может оказаться чертовски тяжёлой обезьяной на спине.

Я не говорю, что никто не будет доминировать в серверных приложениях. Кто-то, вероятно, в итоге будет. Но думаю, будет хороший долгий период радостного хаоса — точно как в ранние дни микрокомпьютеров. То было хорошее время для стартапов. Множество маленьких компаний расцвело, делая крутые вещи.

Стартапы, только ещё больше

Классический стартап быстрый и неформальный, с малым числом людей и небольшими деньгами. Эти немногие люди работают очень много, а технологии умножают эффект принимаемых ими решений. Если они побеждают, побеждают по-крупному.

В стартапе, пишущем веб-приложения, всё, что вы ассоциируете со стартапами, доведено до крайности. Вы можете написать и запустить продукт ещё меньшим числом людей и за ещё меньшие деньги. Вам нужно быть ещё быстрее, и вам сходит с рук ещё большая неформальность. Вы можете буквально запустить свой продукт втроём, сидя в гостиной квартиры, с сервером, размещённым в коллокейшне у ISP. Мы так и сделали.

Со временем команды становились меньше, быстрее и неформальнее. В 1960 году разработка ПО означала комнату, полную мужчин в роговых очках и узких чёрных галстуках, индустриально пишущих по десять строк кода в день на кодировочных формах IBM. В 1980-м это была команда из восьми-десяти человек, носящих в офис джинсы и печатающих в vt100. Сейчас это пара ребят в гостиной с ноутбуками. (И джинсы, как выясняется, не последнее слово в неформальности.)

Стартапы — это стресс, и это, к сожалению, тоже доведено до крайности с веб-приложениями. У многих софтверных компаний, особенно в начале, есть периоды, когда разработчики спят под столами и тому подобное. Тревожащая вещь в веб-ПО — то, что нет ничего, что мешало бы этому стать дефолтом. Истории про сон под столами обычно заканчиваются: и потом мы наконец зашипали, и все ушли домой и спали неделю. Веб-ПО никогда не шипается. Вы можете работать по 16 часов в день, сколько захотите. И поскольку вы можете, и ваши конкуренты могут, вы, как правило, вынуждены это делать. Вы можете — значит, вы должны. Это закон Паркинсона наоборот.

Хуже всего не часы, а ответственность. У программистов и системных администраторов традиционно есть свои отдельные заботы. Программистам приходится беспокоиться о багах, системным администраторам — об инфраструктуре. Программисты могут провести длинный день по локоть в исходном коде, но в какой-то момент они уходят домой и забывают об этом. Системные администраторы никогда полностью не оставляют работу, но когда их вызывают на пейджер в 4 утра, им обычно не приходится делать ничего сложного. С веб-приложениями эти два вида стресса объединяются. Программисты становятся системными администраторами, но без чётко обозначенных границ, которые обычно делают эту работу выносимой.

В Viaweb мы провели первые полгода, просто пишущи ПО. Мы работали обычные длинные часы раннего стартапа. В desktop-компании это была бы фаза, где мы пахали бы, но по сравнению со следующей фазой, когда мы пустили пользователей на свой сервер, это было как отпуск. Вторым крупнейшим бенефитом продажи Viaweb в Yahoo (после денег) было возможность сбросить конечную ответственность за всё это на плечи большой компании.

Desktop-софт заставляет пользователей становиться системными администраторами. Веб-ПО заставляет программистов. В сумме стресса меньше, но больше для программистов. Это не обязательно плохая новость. Если вы стартап, конкурирующий с большой компанией, это хорошая новость. [15] Веб-приложения предлагают прямой способ переработать своих конкурентов. А большего стартап и не просит.

Достаточно хорошо

Одна вещь, которая может отпугнуть вас от написания веб-приложений, — это убогость веб-страниц как UI. Это, признаю, проблема. Есть несколько вещей, которые мы очень хотели бы добавить в HTML и HTTP. Но что важно — то, что веб-страницы достаточно хороши.

Здесь есть параллель с первыми микрокомпьютерами. Процессоры в тех машинах вообще-то не предназначались для того, чтобы быть CPU компьютеров. Они были спроектированы для использования в таких вещах, как светофоры. Но такие парни, как Эд Робертс, разработавший Altair, поняли, что они достаточно хороши. Можно было скомбинировать один из этих чипов с какой-то памятью (256 байт в первом Altair) и переключателями на передней панели — и у вас был рабочий компьютер. Иметь возможность владеть собственным компьютером было настолько захватывающе, что нашлось полно людей, готовых их покупать, какими бы ограниченными они ни были.

Веб-страницы не были спроектированы для того, чтобы быть UI для приложений, но они достаточно хороши. И для значительного числа пользователей возможность использовать ПО из любого браузера будет сама по себе достаточным выигрышем, чтобы перевесить любую неуклюжесть UI. Возможно, вы не сможете написать самую красивую электронную таблицу на HTML, но вы можете написать таблицу, которой одновременно из разных мест могут пользоваться несколько человек без специального клиентского ПО, или которая может включать живые потоки данных, или которая может звать вас на пейджер, когда срабатывают определённые условия. Что важнее, вы можете писать новые виды приложений, у которых ещё даже нет названий. VisiCalc, в конце концов, был не просто микрокомпьютерной версией мейнфреймового приложения — это был новый тип приложения.

Конечно, серверные приложения не обязаны быть веб-приложениями. У вас мог бы быть какой-то другой тип клиента. Но я почти уверен, что это плохая идея. Было бы очень удобно, если бы можно было предположить, что все установят ваш клиент — настолько удобно, что вы легко могли бы убедить себя, что они это сделают, — но если они этого не сделают, вы попали. Поскольку веб-ПО не делает никаких допущений о клиенте, оно будет работать везде, где работает Веб. Это уже большое преимущество, и оно будет расти по мере распространения новых веб-устройств. Пользователи будут вас любить, потому что ваше ПО просто работает, а ваша жизнь будет проще, потому что вам не придётся подстраивать его под каждый новый клиент. [16]

Мне кажется, я наблюдал за эволюцией Веба так же пристально, как кто-либо ещё, и я не могу предсказать, что произойдёт с клиентами. Конвергенция, вероятно, грядёт, но где? Я не могу выбрать победителя. Одно, что я могу предсказать, — это конфликт между AOL и Microsoft. Чем бы ни оказался .NET от Microsoft, он, вероятно, будет связывать десктоп с серверами. Если AOL не даст отпор, их либо оттеснят, либо превратят в трубу между клиентским и серверным ПО Microsoft. Если Microsoft и AOL развяжут войну клиентов, единственное, что точно будет работать на обоих, — это просмотр Веба, что означает: веб-приложения будут единственным типом, который работает везде.

Как всё это разыграется? Не знаю. И вам не нужно знать, если вы ставите на веб-приложения. Никто не сможет это сломать, не сломав браузинг. Веб может быть не единственным способом доставки ПО, но это способ, который работает сейчас и продолжит работать ещё долго. Веб-приложения дёшевы в разработке и легки в доставке даже самому маленькому стартапу. С ними много работы, и работа особенно стрессовая, но это лишь улучшает шансы стартапов.

Почему бы и нет?

Э. Б. Уайту было весело узнать от знакомого фермера, что многие электризованные заборы не имеют тока. Коровы, видимо, учатся держаться от них подальше, и после этого ток уже не нужен. «Вставайте, коровы! — писал он. — Хватайте свою свободу, пока деспоты спят!»

Если вы хакер, когда-то задумавшийся о том, чтобы открыть стартап, вас, вероятно, удерживают от этого две вещи. Одна — что вы ничего не знаете о бизнесе. Другая — что вы боитесь конкуренции. Ни в одном из этих заборов нет тока.

Есть только две вещи, которые вам нужно знать о бизнесе: создайте то, что пользователи любят, и зарабатывайте больше, чем тратите. Если вы делаете эти две вещи правильно, вы будете впереди большинства стартапов. Остальное вы разберёте по ходу дела.

Поначалу вы можете не зарабатывать больше, чем тратите, но пока разрыв сокращается достаточно быстро, всё нормально. Если стартуете с недофинансированием, это, по крайней мере, привьёт привычку к бережливости. Чем меньше вы тратите, тем легче зарабатывать больше, чем тратите. К счастью, запустить веб-приложение может быть очень дёшево. Мы запустились меньше чем на 10 000 долларов, и сегодня это было бы ещё дешевле. Нам пришлось потратить тысячи на сервер и ещё тысячи, чтобы получить SSL. (Единственной компанией, продававшей тогда SSL-ПО, была Netscape.) Сейчас вы можете арендовать гораздо более мощный сервер с включённым SSL дешевле, чем мы платили только за трафик. Сегодня можно запустить веб-приложение за меньшие деньги, чем стоит модное офисное кресло.

Что касается создания того, что любят пользователи, вот несколько общих советов. Начните с того, чтобы сделать что-то простое и чистое, чем вы сами захотите пользоваться. Выпустите версию 1.0 быстро, потом продолжайте улучшать ПО, внимательно слушая пользователей по ходу. Клиент всегда прав, но разные клиенты правы в разном; наименее искушённые пользователи показывают вам, что нужно упростить и прояснить, а самые искушённые говорят, какие фичи нужно добавить. Лучшее, чем может быть ПО, — это простота, но способ её добиться — правильно настроить дефолты, а не ограничивать выбор пользователей. Не успокаивайтесь, если ПО ваших конкурентов хромает; стандарт, с которым нужно сравнивать ваше ПО, — это то, каким оно могло бы быть, а не то, что случайно есть у ваших текущих конкурентов. Пользуйтесь своим ПО сами, постоянно. Viaweb должен был быть конструктором онлайн-магазинов, но мы и свой сайт тоже сделали с его помощью. Не слушайте маркетологов, дизайнеров или продакт-менеджеров только из-за их должностей. Если у них хорошие идеи — используйте их, но решать вам; ПО должно проектироваться хакерами, понимающими дизайн, а не дизайнерами, мало знающими о ПО. Если вы не умеете и проектировать ПО, и реализовывать его — не запускайте стартап.

Теперь поговорим о конкуренции. То, чего вы боитесь, — это, видимо, не группы хакеров вроде вас, а реальные компании с офисами, бизнес-планами, продавцами и так далее, верно? Так вот, они боятся вас больше, чем вы их, и они правы. Паре хакеров гораздо проще разобраться, как арендовать офис или нанять продавцов, чем компании любого размера написать ПО. Я был по обе стороны и знаю это. Когда Viaweb купил Yahoo, я вдруг оказался работником большой компании, и это было как пытаться бежать в воде по пояс.

Не хочу принизить Yahoo. У них были хорошие хакеры, и топ-менеджмент был настоящими бойцами. Для большой компании они были исключением. Но они всё равно были примерно в десять раз менее производительными, чем маленький стартап. Никакая большая компания не может сделать намного лучше. Что пугает в Microsoft — так это то, что такая большая компания вообще может разрабатывать ПО. Они как гора, которая ходит.

Не давайте себя запугать. Вы можете делать столько же того, чего не могут Microsoft, сколько они могут того, чего не можете вы. И никто не может вас остановить. Вам не нужно ни у кого просить разрешения разрабатывать веб-приложения. Вам не нужно заключать лицензионные сделки, или получать место на полках в розничных магазинах, или унижаться, чтобы ваше приложение поставлялось в комплекте с ОС. Вы можете доставлять ПО прямо в браузер, и никто не сможет встать между вами и потенциальными пользователями, не помешав им сёрфить Веб.

Можете не верить, но я вам обещаю: Microsoft боится вас. Самодовольные мидл-менеджеры — возможно, нет, но Билл боится, потому что он сам был когда-то таким, как вы, — ещё в 1975 году, когда в последний раз появился новый способ доставки ПО.

Примечания

[1] Осознав, что значительная часть денег — в сервисах, компании, делающие лёгких клиентов, обычно пытались скомбинировать железо с онлайн-сервисом. Этот подход работал плохо, отчасти потому, что для производства потребительской электроники и для запуска онлайн-сервиса нужны два разных типа компаний, а отчасти потому, что пользователи ненавидят саму идею. Раздавать бритвы и зарабатывать на лезвиях может работать для Gillette, но бритва — гораздо меньший коммитмент, чем веб-терминал. Производители сотовых трубок довольны тем, что продают железо, не пытаясь захватить ещё и сервисную выручку. Это, вероятно, должно быть моделью и для интернет-клиентов. Если бы кто-то просто продавал хорошо выглядящую маленькую коробочку с веб-браузером, через которую можно подключаться через любой ISP, каждый технофоб в стране купил бы такую.

[2] Безопасность всегда больше зависит от того, чтобы не лажать, чем от какого-либо проектного решения, но природа серверного ПО заставит разработчиков обращать больше внимания на то, чтобы не лажать. Компрометация сервера может нанести такой ущерб, что ASP (желающие остаться в бизнесе), вероятно, будут осторожны с безопасностью.

[3] В 1995 году, когда мы начинали Viaweb, считалось, что Java-апплеты — это технология, на которой все будут разрабатывать серверные приложения. Апплеты казались нам старомодной идеей. Скачивать программы для запуска на клиенте? Проще пойти до конца и запускать программы на сервере. Мы тратили мало времени на апплеты, но бесчисленное множество других стартапов, должно быть, было заманено в эту смоляную яму. Немногие могли выбраться живыми, иначе Microsoft не смогла бы убрать Java из последней версии Explorer.

[4] Эта мысль принадлежит Тревору Блэквеллу, который добавляет: «Стоимость написания ПО растёт более чем линейно с его размером. Возможно, это в основном из-за исправления старых багов, и стоимость может быть более линейной, если все баги находятся быстро».

[5] Самый сложный для нахождения вид багов — это, пожалуй, вариант составного бага, где один баг случайно компенсирует другой. Когда вы исправляете один баг, другой становится видимым. Но кажется, что виновато исправление, поскольку это было последним, что вы изменили.

[6] В Viaweb у нас однажды был конкурс на описание худшего в нашем ПО. Двое сотрудников поддержки разделили первый приз с записями, которые я до сих пор содрогаюсь вспоминать. Мы тут же исправили обе проблемы.

[7] Роберт Моррис написал систему заказов, через которую покупатели делали заказы. Тревор Блэквелл написал генератор изображений и менеджер, который мерчанты использовали для получения заказов, просмотра статистики, настройки доменных имён и т. п. Я написал редактор, который мерчанты использовали для построения своих сайтов. Система заказов и генератор изображений были написаны на C и C++, менеджер в основном на Perl, а редактор — на Lisp.

[8] Ценовая дискриминация настолько распространена (как часто вы слышали, чтобы ритейлер заявлял, что его покупательная способность означает более низкие цены для вас?), что я был удивлён, обнаружив, что она запрещена в США актом Робинсона-Патмана 1936 года. Этот закон, судя по всему, активно не применяется.

[9] В No Logo Наоми Кляйн пишет, что одёжные бренды, которые любит «городская молодёжь», не слишком стараются предотвращать кражи в магазинах, потому что в их целевой аудитории воры — это и есть законодатели моды.

[10] Компании часто думают, что отдавать на аутсорс, а что нет. Один возможный ответ: отдавайте на аутсорс любую работу, которая не подвержена напрямую конкурентному давлению, потому что аутсорсинг тем самым подвергнет её конкурентному давлению.

[11] Этими двумя парнями были Дэн Бриклин и Боб Франкстон. Дэн за пару дней написал прототип на Basic, потом в течение года они вместе работали (в основном по ночам) над более мощной версией, написанной на машинном языке 6502. Дэн был тогда в Harvard Business School, а у Боба номинально была дневная работа — писать ПО. «В создании бизнеса не было большого риска, — писал Боб. — Если бы он провалился, он бы провалился. Ничего страшного».

[12] Не совсем так легко, как я это подаю. Сарафанному радио ушло мучительно много времени на раскачку, и мы не начали получать много упоминаний в прессе, пока не наняли PR-фирму (по правде говоря, лучшую в индустрии) за 16 000 долларов в месяц. Однако правдой было то, что единственным значимым каналом был наш собственный веб-сайт.

[13] Если Mac был так хорош, почему он проиграл? Опять же, цена. Microsoft сконцентрировалась на бизнесе ПО и натравила на железо Apple рой дешёвых поставщиков компонентов. Также не помогло то, что в критический период верхушку захватили костюмчики.

[14] Одна вещь, которая помогла бы веб-приложениям и удержала бы следующее поколение ПО от того, чтобы быть затенённым Microsoft, — это хороший опен-сорсный браузер. Mozilla — опен-сорс, но, похоже, пострадал от того, что слишком долго был корпоративным ПО. Маленький, быстрый браузер, который активно поддерживается, был бы отличной вещью сам по себе и, вероятно, также подстегнул бы компании создавать маленькие веб-устройства.

Помимо прочего, нормальный опен-сорсный браузер заставил бы HTTP и HTML продолжать эволюционировать (как, например, Perl). Веб-приложениям сильно помогло бы умение различать выбор ссылки и переход по ней; для этого хватило бы тривиального расширения HTTP — разрешения нескольких URL в запросе. Каскадные меню тоже были бы хороши.

Если хотите изменить мир, напишите новый Mosaic. Думаете, уже поздно? В 1998 году многие думали, что уже поздно запускать новый поисковик, но Google доказал обратное. Всегда есть место для чего-то нового, если текущие варианты достаточно паршивые. Сначала убедитесь, что оно работает на всех свободных ОС, — новые вещи начинаются со своих пользователей.

[15] Тревор Блэквелл, который, вероятно, знает об этом из личного опыта больше, чем кто-либо ещё, пишет:

«Я бы пошёл дальше и сказал, что, поскольку серверное ПО так тяжело для программистов, оно вызывает фундаментальный экономический сдвиг прочь от больших компаний. Оно требует от программистов такой интенсивности и преданности, которую они захотят отдавать только тогда, когда это их собственная компания. Софтверные компании могут нанимать квалифицированных людей для работы в не слишком требовательной среде и могут нанимать неквалифицированных людей терпеть тяготы, но они не могут нанимать высококвалифицированных людей вкалывать. Поскольку капитал больше не нужен, большим компаниям мало что есть предложить».

[16] В оригинальной версии этого эссе я советовал избегать JavaScript. Это был хороший план в 2001 году, но JavaScript теперь работает.

Спасибо Саре Харлин, Тревору Блэквеллу, Роберту Моррису, Эрику Рэймонду, Кену Андерсону и Дэну Гиффину за чтение черновиков этой статьи; Дэну Бриклину и Бобу Франкстону за информацию о VisiCalc; и снова Кену Андерсону за приглашение выступить в BBN.

Это эссе и ещё 14 других вы найдёте в Hackers & Painters.