The Other Road Ahead

September 2001

Сентябрь 2001

(This article explains why much of the next generation of software
may be server-based, what that will mean for programmers,
and why this new kind of software is a great opportunity for startups.
It's derived from a talk at BBN Labs.)

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

In the summer of 1995, my friend Robert Morris and I decided to
start a startup. The PR campaign leading up to Netscape's IPO was
running full blast then, and there was a lot of talk in the press
about online commerce. At the time there might have been thirty
actual stores on the Web, all made by hand. If there were going
to be a lot of online stores, there would need to be software for making
them, so we decided to write some.

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

For the first week or so we intended to make this an ordinary
desktop application. Then one day we had the idea of making the
software run on our Web server, using the browser as an
interface. We tried rewriting the software to work over
the Web, and it was clear that this was the way to go.
If we wrote our software to run on the server, it would be a lot easier
for the users and for us as well.

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

This turned out to be a good plan. Now, as
Yahoo Store, this
software is the most popular online store builder, with
about 14,000 users.

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

When we started Viaweb, hardly anyone understood what we meant when
we said that the software ran on the server. It was not until
Hotmail was launched a year later that people started to get it.
Now everyone knows that this is a valid approach. There is
a name now for what we were: an Application Service Provider,
or ASP.

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

I think that a lot of the next generation of software will be
written on this model. Even Microsoft, who have the most to
lose, seem to see the inevitablity of moving some things off
the desktop. If software moves
off the desktop and onto servers, it will mean a very different
world for developers. This article describes the surprising
things we saw, as some of the first visitors to this new world.
To the extent software does move onto
servers, what I'm describing here is the future.

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

The Next Thing?

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

When we look back on the desktop software era, I think we'll marvel
at the inconveniences people put up with, just as we marvel now at
what early car owners put up with. For the first twenty or thirty
years, you had to be a car expert to own a car. But cars were such
a big win that lots of people who weren't car experts wanted to
have them as well.

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

Computers are in this phase now. When you own a desktop computer,
you end up learning a lot more than you wanted to know about what's
happening inside it. But more than half the households in the US
own one. My mother has a computer that she uses for email and for
keeping accounts. About a year ago she was alarmed to receive a
letter from Apple, offering her a discount on a new version of the
operating system. There's something wrong when a sixty-five year
old woman who wants to use a computer for email and accounts has
to think about installing new operating systems. Ordinary users
shouldn't even know the words "operating system," much less "device
driver" or "patch."

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

There is now another way to deliver software that will save users
from becoming system administrators. Web-based applications are
programs that run on Web servers and use Web pages as the user
interface. For the average user this new kind of software will be
easier, cheaper, more mobile, more reliable, and often more powerful
than desktop software.

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

With Web-based software, most users won't have to think about
anything except the applications they use. All the messy, changing
stuff will be sitting on a server somewhere, maintained by the kind
of people who are good at that kind of thing. And so you won't
ordinarily need a computer, per se, to use software. All you'll
need will be something with a keyboard, a screen, and a Web browser.
Maybe it will have wireless Internet access. Maybe it will also
be your cell phone. Whatever it is, it will be consumer electronics:
something that costs about $200, and that people choose mostly
based on how the case looks. You'll pay more for Internet services
than you do for the hardware, just as you do now with telephones. [1]

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

It will take about a tenth of a second for a click to get to the
server and back, so users of heavily interactive software, like
Photoshop, will still want to have the computations happening on
the desktop. But if you look at the kind of things most people
use computers for, a tenth of a second latency would not be a
problem. My mother doesn't really need a desktop computer, and
there are a lot of people like her.

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

The Win for Users

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

Near my house there is a car with a bumper sticker that reads "death
before inconvenience." Most people, most of the time, will take
whatever choice requires least work. If Web-based software wins,
it will be because it's more convenient. And it looks as if it
will be, for users and developers both.

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

To use a purely Web-based application, all you need is a browser
connected to the Internet. So you can use a Web-based application
anywhere. When you install software on your desktop computer, you
can only use it on that computer. Worse still, your files are
trapped on that computer. The inconvenience of this model becomes
more and more evident as people get used to networks.

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

The thin end of the wedge here was Web-based email. Millions of
people now realize that you should have access to email messages
no matter where you are. And if you can see your email, why not
your calendar?
If you can discuss a document with your colleagues,
why can't you edit it? Why should any of your data be trapped on
some computer sitting on a faraway desk?

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

The whole idea of "your computer" is going away, and being replaced
with "your data." You should be able to get at your data from any
computer. Or rather, any client, and a client doesn't have to be
a computer.

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

Clients shouldn't store data; they should be like telephones. In
fact they may become telephones, or vice versa. And as clients
get smaller, you have another reason not to keep your data on them:
something you carry around with you can be lost or stolen. Leaving
your PDA in a taxi is like a disk crash, except that your data is
handed to someone else
instead of being vaporized.

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

With purely Web-based software, neither your data nor the applications
are kept on the client. So you don't have to install anything to
use it. And when there's no installation, you don't have to worry
about installation going wrong. There can't be incompatibilities
between the application and your operating system, because the
software doesn't run on your operating system.

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

Because it needs no installation, it will be easy, and common, to
try Web-based software before you "buy" it. You should expect to
be able to test-drive any Web-based application for free, just by
going to the site where it's offered. At Viaweb our whole site
was like a big arrow pointing users to the test drive.

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

After trying the demo, signing up for the service should require
nothing more than filling out a brief form (the briefer the better).
And that should be the last work the user has to do. With Web-based
software, you should get new releases without paying extra, or
doing any work, or possibly even knowing about it.

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

Upgrades won't be the big shocks they are now. Over time applications
will quietly grow more powerful. This will take some effort on
the part of the developers. They will have to design software so
that it can be updated without confusing the users. That's a new
problem, but there are ways to solve it.

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

With Web-based applications, everyone uses the same version, and
bugs can be fixed as soon as they're discovered. So Web-based
software should have far fewer bugs than desktop software. At
Viaweb, I doubt we ever had ten known bugs at any one time. That's
orders of magnitude better than desktop software.

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

Web-based applications can be used by several people at the same
time. This is an obvious win for collaborative applications, but
I bet users will start to want this in most applications once they
realize it's possible. It will often be useful to let two people
edit the same document, for example. Viaweb let multiple users
edit a site simultaneously, more because that was the right way to
write the software than because we expected users to want to, but
it turned out that many did.

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

When you use a Web-based application, your data will be safer.
Disk crashes won't be a thing of the past, but users won't hear
about them anymore. They'll happen within server farms. And
companies offering Web-based applications will actually do backups--
not only because they'll have real system administrators worrying
about such things, but because an ASP that does lose people's data
will be in big, big trouble. When people lose their own data in
a disk crash, they can't get that mad, because they only have
themselves to be mad at. When a company loses their data for them,
they'll get a lot madder.

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

Finally, Web-based software should be less vulnerable to viruses.
If the client doesn't run anything except a browser, there's less
chance of running viruses, and no data locally to damage. And a
program that attacked the servers themselves should find them very
well defended. [2]

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

For users, Web-based software will be less stressful. I think if
you looked inside the average Windows user you'd find a huge and
pretty much untapped desire for software meeting that description.
Unleashed, it could be a powerful force.

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

City of Code

Город кода

To developers, the most conspicuous difference between Web-based
and desktop software is that a Web-based application is not a single
piece of code. It will be a collection of programs of different
types rather than a single big binary. And so designing Web-based
software is like desiging a city rather than a building: as well
as buildings you need roads, street signs, utilities, police and
fire departments, and plans for both growth and various kinds of
disasters.

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

At Viaweb, software included fairly big applications that users
talked to directly, programs that those programs used, programs
that ran constantly in the background looking for problems, programs
that tried to restart things if they broke, programs that ran
occasionally to compile statistics or build indexes for searches,
programs we ran explicitly to garbage-collect resources or to move
or restore data, programs that pretended to be users (to measure
performance or expose bugs), programs for diagnosing network
troubles, programs for doing backups, interfaces to outside services,
software that drove an impressive collection of dials displaying
real-time server statistics (a hit with visitors, but indispensable
for us too), modifications (including bug fixes) to open-source
software, and a great many configuration files and settings. Trevor
Blackwell wrote a spectacular program for moving stores to new
servers across the country, without shutting them down, after we
were bought by Yahoo. Programs paged us, sent faxes and email to
users, conducted transactions with credit card processors, and
talked to one another through sockets, pipes, http requests, ssh,
udp packets, shared memory, and files. Some of Viaweb even consisted
of the absence of programs, since one of the keys to Unix security
is not to run unnecessary utilities that people might use to break
into your servers.

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

It did not end with software. We spent a lot of time thinking
about server configurations. We built the servers ourselves, from
components-- partly to save money, and partly to get exactly what
we wanted. We had to think about whether our upstream ISP had fast
enough connections to all the backbones. We serially
dated
RAID suppliers.

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

But hardware is not just something to worry about. When you control
it you can do more for users. With a desktop application, you can
specify certain minimum hardware, but you can't add more. If you
administer the servers, you can in one step enable all your users
to page people, or send faxes, or send commands by phone, or process
credit cards, etc, just by installing the relevant hardware. We
always looked for new ways to add features with hardware, not just
because it pleased users, but also as a way to distinguish ourselves
from competitors who (either because they sold desktop software,
or resold Web-based applications through ISPs) didn't have direct
control over the hardware.

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

Because the software in a Web-based application will be a collection
of programs rather than a single binary, it can be written in any
number of different languages. When you're writing desktop software,
you're practically forced to write the application in the same
language as the underlying operating system-- meaning C and C++.
And so these languages (especially among nontechnical people like
managers and VCs) got to be considered as the languages for "serious"
software development. But that was just an artifact of the way
desktop software had to be delivered. For server-based software
you can use any language you want. [3] Today a lot of the top
hackers are using languages far removed from C and C++: Perl,
Python, and even Lisp.

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

With server-based software, no one can tell you what language to
use, because you control the whole system, right down to the
hardware. Different languages are good for different tasks. You
can use whichever is best for each. And when you have competitors,
"you can" means "you must" (we'll return to this later), because
if you don't take advantage of this possibility, your competitors
will.

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

Most of our competitors used C and C++, and this made their software
visibly inferior because (among other things), they had no way
around the statelessness of CGI scripts. If you were going to
change something, all the changes had to happen on one page, with
an Update button at the bottom. As I've written elsewhere, by
using Lisp, which many people still consider
a research language,
we could make the Viaweb editor behave more like desktop software.

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

Releases

Релизы

One of the most important changes in this new world is the way you
do releases. In the desktop software business, doing a release is
a huge trauma, in which the whole company sweats and strains to
push out a single, giant piece of code. Obvious comparisons suggest
themselves, both to the process and the resulting product.

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

With server-based software, you can make changes almost as you
would in a program you were writing for yourself. You release
software as a series of incremental changes instead of an occasional
big explosion. A typical desktop software company might do one or
two releases a year. At Viaweb we often did three to five releases
a day.

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

When you switch to this new model, you realize how much software
development is affected by the way it is released. Many of the
nastiest problems you see in the desktop software business are due
to catastrophic nature of releases.

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

When you release only one new version a year, you tend to deal with
bugs wholesale. Some time before the release date you assemble a
new version in which half the code has been torn out and replaced,
introducing countless bugs. Then a squad of QA people step in and
start counting them, and the programmers work down the list, fixing
them. They do not generally get to the end of the list, and indeed,
no one is sure where the end is. It's like fishing rubble out of
a pond. You never really know what's happening inside the software.
At best you end up with a statistical sort of correctness.

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

With server-based software, most of the change is small and
incremental. That in itself is less likely to introduce bugs. It
also means you know what to test most carefully when you're about
to release software: the last thing you changed. You end up with
a much firmer grip on the code. As a general rule, you do know
what's happening inside it. You don't have the source code memorized,
of course, but when you read the source you do it like a pilot
scanning the instrument panel, not like a detective trying to
unravel some mystery.

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

Desktop software breeds a certain fatalism about bugs. You know
that you're shipping something loaded with bugs, and you've even
set up mechanisms to compensate for it (e.g. patch releases). So
why worry about a few more? Soon you're releasing whole features
you know are broken.
Apple
did this earlier this year. They felt
under pressure to release their new OS, whose release date had
already slipped four times, but some of the software (support for
CDs and DVDs) wasn't ready. The solution? They released the OS
without the unfinished parts, and users will have to install them
later.

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

With Web-based software, you never have to release software before
it works, and you can release it as soon as it does work.

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

The industry veteran may be thinking, it's a fine-sounding idea to
say that you never have to release software before it works, but
what happens when you've promised to deliver a new version of your
software by a certain date? With Web-based software, you wouldn't
make such a promise, because there are no versions. Your software
changes gradually and continuously. Some changes might be bigger
than others, but the idea of versions just doesn't naturally fit
onto Web-based software.

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

If anyone remembers Viaweb this might sound odd, because we were
always announcing new versions. This was done entirely for PR
purposes. The trade press, we learned, thinks in version numbers.
They will give you major coverage for a major release, meaning a
new first digit on the version number, and generally a paragraph
at most for a point release, meaning a new digit after the decimal
point.

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

Some of our competitors were offering desktop software and actually
had version numbers. And for these releases, the mere fact of
which seemed to us evidence of their backwardness, they would get
all kinds of publicity. We didn't want to miss out, so we started
giving version numbers to our software too. When we wanted some
publicity, we'd make a list of all the features we'd added since
the last "release," stick a new version number on the software,
and issue a press release saying that the new version was available
immediately. Amazingly, no one ever called us on it.

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

By the time we were bought, we had done this three times, so we
were on Version 4. Version 4.1 if I remember correctly. After
Viaweb became Yahoo Store, there was no longer such a desperate
need for publicity, so although the software continued to evolve,
the whole idea of version numbers was quietly dropped.

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

Bugs

Баги

The other major technical advantage of Web-based software is that
you can reproduce most bugs. You have the users' data right there
on your disk. If someone breaks your software, you don't have to
try to guess what's going on, as you would with desktop software:
you should be able to reproduce the error while they're on the
phone with you. You might even know about it already, if you have
code for noticing errors built into your application.

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

Web-based software gets used round the clock, so everything you do
is immediately put through the wringer. Bugs turn up quickly.

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

Software companies are sometimes accused of letting the users debug
their software. And that is just what I'm advocating. For Web-based
software it's actually a good plan, because the bugs are fewer and
transient. When you release software gradually you get far fewer
bugs to start with. And when you can reproduce errors and release
changes instantly, you can find and fix most bugs as soon as they
appear. We never had enough bugs at any one time to bother with
a formal bug-tracking system.

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

You should test changes before you release them, of course, so no
major bugs should get released. Those few that inevitably slip
through will involve borderline cases and will only affect the few
users that encounter them before someone calls in to complain. As
long as you fix bugs right away, the net effect, for the average
user, is far fewer bugs. I doubt the average Viaweb user ever saw
a bug.

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

Fixing fresh bugs is easier than fixing old ones. It's usually
fairly quick to find a bug in code you just wrote. When it turns
up you often know what's wrong before you even look at the source,
because you were already worrying about it subconsciously. Fixing
a bug in something you wrote six months ago (the average case if
you release once a year) is a lot more work. And since you don't
understand the code as well, you're more likely to fix it in an
ugly way, or even introduce more bugs. [4]

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

When you catch bugs early, you also get fewer compound bugs.
Compound bugs are two separate bugs that interact: you trip going
downstairs, and when you reach for the handrail it comes off in
your hand. In software this kind of bug is the hardest to find,
and also tends to have the worst consequences. [5] The traditional
"break everything and then filter out the bugs" approach inherently
yields a lot of compound bugs. And software that's released in a
series of small changes inherently tends not to. The floors are
constantly being swept clean of any loose objects that might later
get stuck in something.

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

It helps if you use a technique called functional programming.
Functional programming means avoiding side-effects. It's something
you're more likely to see in research papers than commercial
software, but for Web-based applications it turns out to be really
useful. It's hard to write entire programs as purely functional
code, but you can write substantial chunks this way. It makes
those parts of your software easier to test, because they have no
state, and that is very convenient in a situation where you are
constantly making and testing small modifications. I wrote much
of Viaweb's editor in this style, and we made our scripting language,
RTML,
a purely functional language.

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

People from the desktop software business will find this hard to
credit, but at Viaweb bugs became almost a game. Since most released
bugs involved borderline cases, the users who encountered them were
likely to be advanced users, pushing the envelope. Advanced users
are more forgiving about bugs, especially since you probably
introduced them in the course of adding some feature they were
asking for. In fact, because bugs were rare and you had to be
doing sophisticated things to see them, advanced users were often
proud to catch one. They would call support in a spirit more of
triumph than anger, as if they had scored points off us.

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

Support

Поддержка

When you can reproduce errors, it changes your approach to customer
support. At most software companies, support is offered as a way
to make customers feel better. They're either calling you about
a known bug, or they're just doing something wrong and you have to
figure out what. In either case there's not much you can learn
from them. And so you tend to view support calls as a pain in the
ass that you want to isolate from your developers as much as
possible.

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

This was not how things worked at Viaweb. At Viaweb, support was
free, because we wanted to hear from customers. If someone had a
problem, we wanted to know about it right away so that we could
reproduce the error and release a fix.

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

So at Viaweb the developers were always in close contact with
support. The customer support people were about thirty feet away
from the programmers, and knew that they could always interrupt
anything with a report of a genuine bug. We would leave a board
meeting to fix a serious bug.

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

Our approach to support made everyone happier. The customers were
delighted. Just imagine how it would feel to call a support line
and be treated as someone bringing important news. The customer
support people liked it because it meant they could help the users,
instead of reading scripts to them. And the programmers liked it
because they could reproduce bugs instead of just hearing vague
second-hand reports about them.

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

Our policy of fixing bugs on the fly changed the relationship
between customer support people and hackers. At most software
companies, support people are underpaid human shields, and hackers
are little copies of God the Father, creators of the world. Whatever
the procedure for reporting bugs, it is likely to be one-directional:
support people who hear about bugs fill out some form that eventually
gets passed on (possibly via QA) to programmers, who put it on
their list of things to do. It was very different at Viaweb.
Within a minute of hearing about a bug from a customer, the support
people could be standing next to a programmer hearing him say "Shit,
you're right, it's a bug." It delighted the support people to hear
that "you're right" from the hackers. They used to bring us bugs
with the same expectant air as a cat bringing you a mouse it has
just killed. It also made them more careful in judging the
seriousness of a bug, because now their honor was on the line.

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

After we were bought by Yahoo, the customer support people were
moved far away from the programmers. It was only then that we
realized that they were effectively QA and to some extent marketing
as well. In addition to catching bugs, they were the keepers of
the knowledge of vaguer, buglike things, like features that confused
users. [6] They were also a kind of proxy focus group; we could
ask them which of two new features users wanted more, and they were
always right.

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

Morale

Боевой дух

Being able to release software immediately is a big motivator.
Often as I was walking to work I would think of some change I wanted
to make to the software, and do it that day. This worked for bigger
features as well. Even if something was going to take two weeks
to write (few projects took longer), I knew I could see the effect
in the software as soon as it was done.

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

If I'd had to wait a year for the next release, I would have shelved
most of these ideas, for a while at least. The thing about ideas,
though, is that they lead to more ideas. Have you ever noticed
that when you sit down to write something, half the ideas that end
up in it are ones you thought of while writing it? The same thing
happens with software. Working to implement one idea gives you
more ideas. So shelving an idea costs you not only that delay in
implementing it, but also all the ideas that implementing it would
have led to. In fact, shelving an idea probably even inhibits new
ideas: as you start to think of some new feature, you catch sight
of the shelf and think "but I already have a lot of new things I
want to do for the next release."

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

What big companies do instead of implementing features is plan
them. At Viaweb we sometimes ran into trouble on this account.
Investors and analysts would ask us what we had planned for the
future. The truthful answer would have been, we didn't have any
plans. We had general ideas about things we wanted to improve,
but if we knew how we would have done it already. What were we
going to do in the next six months? Whatever looked like the biggest
win. I don't know if I ever dared give this answer, but that was
the truth. Plans are just another word for ideas on the shelf.
When we thought of good ideas, we implemented them.

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

At Viaweb, as at many software companies, most code had one definite
owner. But when you owned something you really owned it: no one
except the owner of a piece of software had to approve (or even
know about) a release. There was no protection against breakage
except the fear of looking like an idiot to one's peers, and that
was more than enough. I may have given the impression that we just
blithely plowed forward writing code. We did go fast, but we
thought very carefully before we released software onto those
servers. And paying attention is more important to reliability
than moving slowly. Because he pays close attention, a Navy pilot
can land a 40,000 lb. aircraft at 140 miles per hour on a pitching
carrier deck, at night, more safely than the average teenager can
cut a bagel.

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

This way of writing software is a double-edged sword of course.
It works a lot better for a small team of good, trusted programmers
than it would for a big company of mediocre ones, where bad ideas
are caught by committees instead of the people that had them.

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

Brooks in Reverse

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

Fortunately, Web-based software does require fewer programmers.
I once worked for a medium-sized desktop software company that had
over 100 people working in engineering as a whole. Only 13 of
these were in product development. All the rest were working on
releases, ports, and so on. With Web-based software, all you need
(at most) are the 13 people, because there are no releases, ports,
and so on.

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

Viaweb was written by just three people. [7] I was always under
pressure to hire more, because we wanted to get bought, and we knew
that buyers would have a hard time paying a high price for a company
with only three programmers. (Solution: we hired more, but created
new projects for them.)

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

When you can write software with fewer programmers, it saves you
more than money. As Fred Brooks pointed out in The Mythical
Man-Month, adding people to a project tends to slow it down. The
number of possible connections between developers grows exponentially
with the size of the group. The larger the group, the more time
they'll spend in meetings negotiating how their software will work
together, and the more bugs they'll get from unforeseen interactions.
Fortunately, this process also works in reverse: as groups get
smaller, software development gets exponentially more efficient.
I can't remember the programmers at Viaweb ever having an actual
meeting. We never had more to say at any one time than we could
say as we were walking to lunch.

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

If there is a downside here, it is that all the programmers have
to be to some degree system administrators as well. When you're
hosting software, someone has to be watching the servers, and in
practice the only people who can do this properly are the ones who
wrote the software. At Viaweb our system had so many components
and changed so frequently that there was no definite border between
software and infrastructure. Arbitrarily declaring such a border
would have constrained our design choices. And so although we were
constantly hoping that one day ("in a couple months") everything
would be stable enough that we could hire someone whose job was
just to worry about the servers, it never happened.

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

I don't think it could be any other way, as long as you're still
actively developing the product. Web-based software is never going
to be something you write, check in, and go home. It's a live
thing, running on your servers right now. A bad bug might not just
crash one user's process; it could crash them all. If a bug in
your code corrupts some data on disk, you have to fix it. And so
on. We found that you don't have to watch the servers every minute
(after the first year or so), but you definitely want to keep an
eye on things you've changed recently. You don't release code late
at night and then go home.

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

Watching Users

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

With server-based software, you're in closer touch with your code.
You can also be in closer touch with your users. Intuit is famous
for introducing themselves to customers at retail stores and asking
to follow them home. If you've ever watched someone use your
software for the first time, you know what surprises must have
awaited them.

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

Software should do what users think it will. But you can't have
any idea what users will be thinking, believe me, until you watch
them. And server-based software gives you unprecedented information
about their behavior. You're not limited to small, artificial
focus groups. You can see every click made by every user. You
have to consider carefully what you're going to look at, because
you don't want to violate users' privacy, but even the most general
statistical sampling can be very useful.

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

When you have the users on your server, you don't have to rely on
benchmarks, for example. Benchmarks are simulated users. With
server-based software, you can watch actual users. To decide what
to optimize, just log into a server and see what's consuming all
the CPU. And you know when to stop optimizing too: we eventually
got the Viaweb editor to the point where it was memory-bound rather
than CPU-bound, and since there was nothing we could do to decrease
the size of users' data (well, nothing easy), we knew we might as
well stop there.

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

Efficiency matters for server-based software, because you're paying
for the hardware. The number of users you can support per server
is the divisor of your capital cost, so if you can make your software
very efficient you can undersell competitors and still make a
profit. At Viaweb we got the capital cost per user down to about
$5. It would be less now, probably less than the cost of sending
them the first month's bill. Hardware is free now, if your software
is reasonably efficient.

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

Watching users can guide you in design as well as optimization.
Viaweb had a scripting language called RTML that let advanced users
define their own page styles. We found that RTML became a kind of
suggestion box, because users only used it when the predefined page
styles couldn't do what they wanted. Originally the editor put
button bars across the page, for example, but after a number of
users used RTML to put buttons down the left
side,
we made that an
option (in fact the default) in the predefined page styles.

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

Finally, by watching users you can often tell when they're in
trouble. And since the customer is always right, that's a sign of
something you need to fix. At Viaweb the key to getting users was
the online test drive. It was not just a series of slides built
by marketing people. In our test drive, users actually used the
software. It took about five minutes, and at the end of it they
had built a real, working store.

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

The test drive was the way we got nearly all our new users. I
think it will be the same for most Web-based applications. If
users can get through a test drive successfully, they'll like the
product. If they get confused or bored, they won't. So anything
we could do to get more people through the test drive would increase
our growth rate.

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

I studied click trails of people taking the test drive and found
that at a certain step they would get confused and click on the
browser's Back button. (If you try writing Web-based applications,
you'll find that the Back button becomes one of your most interesting
philosophical problems.) So I added a message at that point, telling
users that they were nearly finished, and reminding them not to
click on the Back button. Another great thing about Web-based
software is that you get instant feedback from changes: the number
of people completing the test drive rose immediately from 60% to
90%. And since the number of new users was a function of the number
of completed test drives, our revenue growth increased by 50%, just
from that change.

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

Money

Деньги

In the early 1990s I read an article in which someone said that
software was a subscription business. At first this seemed a very
cynical statement. But later I realized that it reflects reality:
software development is an ongoing process. I think it's cleaner
if you openly charge subscription fees, instead of forcing people
to keep buying and installing new versions so that they'll keep
paying you. And fortunately, subscriptions are the natural way to
bill for Web-based applications.

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

Hosting applications is an area where companies will play a role
that is not likely to be filled by freeware. Hosting applications
is a lot of stress, and has real expenses. No one is going to want
to do it for free.

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

For companies, Web-based applications are an ideal source of revenue.
Instead of starting each quarter with a blank slate, you have a
recurring revenue stream. Because your software evolves gradually,
you don't have to worry that a new model will flop; there never
need be a new model, per se, and if you do something to the software
that users hate, you'll know right away. You have no trouble with
uncollectable bills; if someone won't pay you can just turn off
the service. And there is no possibility of piracy.

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

That last "advantage" may turn out to be a problem. Some amount
of piracy is to the advantage of software companies. If some user
really would not have bought your software at any price, you haven't
lost anything if he uses a pirated copy. In fact you gain, because
he is one more user helping to make your software the standard--
or who might buy a copy later, when he graduates from high school.

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

When they can, companies like to do something called price
discrimination, which means charging each customer as much as they
can afford. [8] Software is particularly suitable for price
discrimination, because the marginal cost is close to zero. This
is why some software costs more to run on Suns than on Intel boxes:
a company that uses Suns is not interested in saving money and can
safely be charged more. Piracy is effectively the lowest tier of
price discrimination. I think that software companies understand
this and deliberately turn a blind eye to some kinds of piracy. [9]
With server-based software they are going to have to come up with
some other solution.

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

Web-based software sells well, especially in comparison to desktop
software, because it's easy to buy. You might think that people
decide to buy something, and then buy it, as two separate steps.
That's what I thought before Viaweb, to the extent I thought about
the question at all. In fact the second step can propagate back
into the first: if something is hard to buy, people will change
their mind about whether they wanted it. And vice versa: you'll
sell more of something when it's easy to buy. I buy more books
because Amazon exists. Web-based software is just about the easiest
thing in the world to buy, especially if you have just done an
online demo. Users should not have to do much more than enter a
credit card number. (Make them do more at your peril.)

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

Sometimes Web-based software is offered through ISPs acting as
resellers. This is a bad idea. You have to be administering the
servers, because you need to be constantly improving both hardware
and software. If you give up direct control of the servers, you
give up most of the advantages of developing Web-based applications.

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

Several of our competitors shot themselves in the foot this way--
usually, I think, because they were overrun by suits who were
excited about this huge potential channel, and didn't realize that
it would ruin the product they hoped to sell through it. Selling
Web-based software through ISPs is like selling sushi through
vending machines.

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

Customers

Клиенты

Who will the customers be? At Viaweb they were initially individuals
and smaller companies, and I think this will be the rule with
Web-based applications. These are the users who are ready to try
new things, partly because they're more flexible, and partly because
they want the lower costs of new technology.

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

Web-based applications will often be the best thing for big companies
too (though they'll be slow to realize it). The best intranet is
the Internet. If a company uses true Web-based applications, the
software will work better, the servers will be better administered,
and employees will have access to the system from anywhere.

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

The argument against this approach usually hinges on security: if
access is easier for employees, it will be for bad guys too. Some
larger merchants were reluctant to use Viaweb because they thought
customers' credit card information would be safer on their own
servers. It was not easy to make this point diplomatically, but
in fact the data was almost certainly safer in our hands than
theirs. Who can hire better people to manage security, a technology
startup whose whole business is running servers, or a clothing
retailer? Not only did we have better people worrying about
security, we worried more about it. If someone broke into the
clothing retailer's servers, it would affect at most one merchant,
could probably be hushed up, and in the worst case might get one
person fired. If someone broke into ours, it could affect thousands
of merchants, would probably end up as news on CNet, and could put
us out of business.

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

If you want to keep your money safe, do you keep it under your
mattress at home, or put it in a bank? This argument applies to
every aspect of server administration: not just security, but
uptime, bandwidth, load management, backups, etc. Our existence
depended on doing these things right. Server problems were the
big no-no for us, like a dangerous toy would be for a toy maker,
or a salmonella outbreak for a food processor.

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

A big company that uses Web-based applications is to that extent
outsourcing IT. Drastic as it sounds, I think this is generally
a good idea. Companies are likely to get better service this way
than they would from in-house system administrators. System
administrators can become cranky and unresponsive because they're
not directly exposed to competitive pressure: a salesman has to
deal with customers, and a developer has to deal with competitors'
software, but a system administrator, like an old bachelor, has
few external forces to keep him in line. [10] At Viaweb we had
external forces in plenty to keep us in line. The people calling
us were customers, not just co-workers. If a server got wedged,
we jumped; just thinking about it gives me a jolt of adrenaline,
years later.

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

So Web-based applications will ordinarily be the right answer for
big companies too. They will be the last to realize it, however,
just as they were with desktop computers. And partly for the same
reason: it will be worth a lot of money to convince big companies
that they need something more expensive.

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

There is always a tendency for rich customers to buy expensive
solutions, even when cheap solutions are better, because the people
offering expensive solutions can spend more to sell them. At Viaweb
we were always up against this. We lost several high-end merchants
to Web consulting firms who convinced them they'd be better off if
they paid half a million dollars for a custom-made online store on
their own server. They were, as a rule, not better off, as more
than one discovered when Christmas shopping season came around and
loads rose on their server. Viaweb was a lot more sophisticated
than what most of these merchants got, but we couldn't afford to
tell them. At $300 a month, we couldn't afford to send a team of
well-dressed and authoritative-sounding people to make presentations
to customers.

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

A large part of what big companies pay extra for is the cost of
selling expensive things to them. (If the Defense Department pays
a thousand dollars for toilet seats, it's partly because it costs
a lot to sell toilet seats for a thousand dollars.) And this is
one reason intranet software will continue to thrive, even though
it is probably a bad idea. It's simply more expensive. There is
nothing you can do about this conundrum, so the best plan is to go
for the smaller customers first. The rest will come in time.

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

Son of Server

Сын сервера

Running software on the server is nothing new. In fact it's the
old model: mainframe applications are all server-based. If
server-based software is such a good idea, why did it lose last
time? Why did desktop computers eclipse mainframes?

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

At first desktop computers didn't look like much of a threat. The
first users were all hackers-- or hobbyists, as they were called
then. They liked microcomputers because they were cheap. For the
first time, you could have your own computer. The phrase "personal
computer" is part of the language now, but when it was first used
it had a deliberately audacious sound, like the phrase "personal
satellite" would today.

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

Why did desktop computers take over? I think it was because they
had better software. And I think the reason microcomputer software
was better was that it could be written by small companies.

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

I don't think many people realize how fragile and tentative startups
are in the earliest stage. Many startups begin almost by accident--
as a couple guys, either with day jobs or in school, writing a
prototype of something that might, if it looks promising, turn into
a company. At this larval stage, any significant obstacle will stop
the startup dead in its tracks. Writing mainframe software required
too much commitment up front. Development machines were expensive,
and because the customers would be big companies, you'd need an
impressive-looking sales force to sell it to them. Starting a
startup to write mainframe software would be a much more serious
undertaking than just hacking something together on your Apple II
in the evenings. And so you didn't get a lot of startups writing
mainframe applications.

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

The arrival of desktop computers inspired a lot of new software,
because writing applications for them seemed an attainable goal to
larval startups. Development was cheap, and the customers would
be individual people that you could reach through computer stores
or even by mail-order.

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

The application that pushed desktop computers out into the mainstream
was VisiCalc, the
first spreadsheet. It was written by two guys
working in an attic, and yet did things no mainframe software could
do. [11] VisiCalc was such an advance, in its time, that people
bought Apple IIs just to run it. And this was the beginning of a
trend: desktop computers won because startups wrote software for
them.

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

It looks as if server-based software will be good this time around,
because startups will write it. Computers are so cheap now that
you can get started, as we did, using a desktop computer as a
server. Inexpensive processors have eaten the workstation market
(you rarely even hear the word now) and are most of the way through
the server market; Yahoo's servers, which deal with loads as high
as any on the Internet, all have the same inexpensive Intel processors
that you have in your desktop machine. And once you've written
the software, all you need to sell it is a Web site. Nearly all
our users came direct to our site through word of mouth and references
in the press. [12]

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

Viaweb was a typical larval startup. We were terrified of starting
a company, and for the first few months comforted ourselves by
treating the whole thing as an experiment that we might call off
at any moment. Fortunately, there were few obstacles except
technical ones. While we were writing the software, our Web server
was the same desktop machine we used for development, connected to
the outside world by a dialup line. Our only expenses in that
phase were food and rent.

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

There is all the more reason for startups to write Web-based software
now, because writing desktop software has become a lot less fun.
If you want to write desktop software now you do it on Microsoft's
terms, calling their APIs and working around their buggy OS. And
if you manage to write something that takes off, you may find that
you were merely doing market research for Microsoft.

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

If a company wants to make a platform that startups will build on,
they have to make it something that hackers themselves will want
to use. That means it has to be inexpensive and well-designed.
The Mac was popular with hackers when it first came out, and a lot
of them wrote software for it. [13] You see this less with Windows,
because hackers don't use it. The kind of people who are good at
writing software tend to be running Linux or FreeBSD now.

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

I don't think we would have started a startup to write desktop
software, because desktop software has to run on Windows, and before
we could write software for Windows we'd have to use it. The Web
let us do an end-run around Windows, and deliver software running
on Unix direct to users through the browser. That is a liberating
prospect, a lot like the arrival of PCs twenty-five years ago.

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

Microsoft

Microsoft

Back when desktop computers arrived, IBM was the giant that everyone
was afraid of. It's hard to imagine now, but I remember the feeling
very well. Now the frightening giant is Microsoft, and I don't
think they are as blind to the threat facing them as IBM was.
After all, Microsoft deliberately built their business in IBM's
blind spot.

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

I mentioned earlier that my mother doesn't really need a desktop
computer. Most users probably don't. That's a problem for Microsoft,
and they know it. If applications run on remote servers, no one
needs Windows. What will Microsoft do? Will they be able to use
their control of the desktop to prevent, or constrain, this new
generation of software?

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

My guess is that Microsoft will develop some kind of server/desktop
hybrid, where the operating system works together with servers they
control. At a minimum, files will be centrally available for users
who want that. I don't expect Microsoft to go all the way to the
extreme of doing the computations on the server, with only a browser
for a client, if they can avoid it. If you only need a browser for
a client, you don't need Microsoft on the client, and if Microsoft
doesn't control the client, they can't push users towards their
server-based applications.

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

I think Microsoft will have a hard time keeping the genie in the
bottle. There will be too many different types of clients for them
to control them all. And if Microsoft's applications only work
with some clients, competitors will be able to trump them by offering
applications that work from any client. [14]

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

In a world of Web-based applications, there is no automatic place
for Microsoft. They may succeed in making themselves a place, but
I don't think they'll dominate this new world as they did the world
of desktop applications.

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

It's not so much that a competitor will trip them up as that they
will trip over themselves. With the rise of Web-based software,
they will be facing not just technical problems but their own
wishful thinking. What they need to do is cannibalize their existing
business, and I can't see them facing that. The same single-mindedness
that has brought them this far will now be working against them.
IBM was in exactly the same situation, and they could not master
it. IBM made a late and half-hearted entry into the microcomputer
business because they were ambivalent about threatening their cash
cow, mainframe computing. Microsoft will likewise be hampered by
wanting to save the desktop. A cash cow can be a damned heavy
monkey on your back.

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

I'm not saying that no one will dominate server-based applications.
Someone probably will eventually. But I think that there will be
a good long period of cheerful chaos, just as there was in the
early days of microcomputers. That was a good time for startups.
Lots of small companies flourished, and did it by making cool
things.

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

Startups but More So

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

The classic startup is fast and informal, with few people and little
money. Those few people work very hard, and technology magnifies
the effect of the decisions they make. If they win, they win big.

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

In a startup writing Web-based applications, everything you associate
with startups is taken to an extreme. You can write and launch a
product with even fewer people and even less money. You have to
be even faster, and you can get away with being more informal.
You can literally launch your product as three guys sitting in the
living room of an apartment, and a server collocated at an ISP.
We did.

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

Over time the teams have gotten smaller, faster, and more informal.
In 1960, software development meant a roomful of men with horn
rimmed glasses and narrow black neckties, industriously writing
ten lines of code a day on IBM coding forms. In 1980, it was a
team of eight to ten people wearing jeans to the office and typing
into vt100s. Now it's a couple of guys sitting in a living room
with laptops. (And jeans turn out not to be the last word in
informality.)

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

Startups are stressful, and this, unfortunately, is also taken to
an extreme with Web-based applications.
Many software companies, especially at the beginning, have periods
where the developers slept under their desks and so on. The alarming
thing about Web-based software is that there is nothing to prevent
this becoming the default. The stories about sleeping under desks
usually end: then at last we shipped it and we all went home and
slept for a week. Web-based software never ships. You can work
16-hour days for as long as you want to. And because you can, and
your competitors can, you tend to be forced to. You can, so you
must. It's Parkinson's Law running in reverse.

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

The worst thing is not the hours but the responsibility. Programmers
and system administrators traditionally each have their own separate
worries. Programmers have to worry about bugs, and system
administrators have to worry about infrastructure. Programmers
may spend a long day up to their elbows in source code, but at some
point they get to go home and forget about it. System administrators
never quite leave the job behind, but when they do get paged at
4:00 AM, they don't usually have to do anything very complicated.
With Web-based applications, these two kinds of stress get combined.
The programmers become system administrators, but without the
sharply defined limits that ordinarily make the job bearable.

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

At Viaweb we spent the first six months just writing software. We
worked the usual long hours of an early startup. In a desktop
software company, this would have been the part where we were
working hard, but it felt like a vacation compared to the next
phase, when we took users onto our server. The second biggest
benefit of selling Viaweb to Yahoo (after the money) was to be able
to dump ultimate responsibility for the whole thing onto the
shoulders of a big company.

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

Desktop software forces users to become system administrators.
Web-based software forces programmers to. There is less stress in
total, but more for the programmers. That's not necessarily bad
news. If you're a startup competing with a big company, it's good
news. [15] Web-based applications offer a straightforward way to
outwork your competitors. No startup asks for more.

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

Just Good Enough

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

One thing that might deter you from writing Web-based applications
is the lameness of Web pages as a UI. That is a problem, I admit.
There were a few things we would have really liked to add to
HTML and HTTP. What matters, though, is that Web pages are just
good enough.

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

There is a parallel here with the first microcomputers. The
processors in those machines weren't actually intended to be the
CPUs of computers. They were designed to be used in things like
traffic lights. But guys like Ed Roberts, who designed the
Altair,
realized that they were just good enough. You could combine one
of these chips with some memory (256 bytes in the first Altair),
and front panel switches, and you'd have a working computer. Being
able to have your own computer was so exciting that there were
plenty of people who wanted to buy them, however limited.

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

Web pages weren't designed to be a UI for applications, but they're
just good enough. And for a significant number of users, software
that you can use from any browser will be enough of a win in itself
to outweigh any awkwardness in the UI. Maybe you can't write the
best-looking spreadsheet using HTML, but you can write a spreadsheet
that several people can use simultaneously from different locations
without special client software, or that can incorporate live data
feeds, or that can page you when certain conditions are triggered.
More importantly, you can write new kinds of applications that
don't even have names yet. VisiCalc was not merely a microcomputer
version of a mainframe application, after all-- it was a new type
of application.

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

Of course, server-based applications don't have to be Web-based.
You could have some other kind of client. But I'm pretty sure
that's a bad idea. It would be very convenient if you could assume
that everyone would install your client-- so convenient that you
could easily convince yourself that they all would-- but if they
don't, you're hosed. Because Web-based software assumes nothing
about the client, it will work anywhere the Web works. That's a
big advantage already, and the advantage will grow as new Web
devices proliferate. Users will like you because your software
just works, and your life will be easier because you won't have to
tweak it for every new client. [16]

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

I feel like I've watched the evolution of the Web as closely as
anyone, and I can't predict what's going to happen with clients.
Convergence is probably coming, but where? I can't pick a winner.
One thing I can predict is conflict between AOL and Microsoft.
Whatever Microsoft's .NET turns out to be, it will probably involve
connecting the desktop to servers. Unless AOL fights back, they
will either be pushed aside or turned into a pipe between Microsoft
client and server software. If Microsoft and AOL get into a client
war, the only thing sure to work on both will be browsing the Web,
meaning Web-based applications will be the only kind that work
everywhere.

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

How will it all play out? I don't know. And you don't have to
know if you bet on Web-based applications. No one can break that
without breaking browsing. The Web may not be the only way to
deliver software, but it's one that works now and will continue to
work for a long time. Web-based applications are cheap to develop,
and easy for even the smallest startup to deliver. They're a lot
of work, and of a particularly stressful kind, but that only makes
the odds better for startups.

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

Why Not?

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

E. B. White was amused to learn from a farmer friend that many
electrified fences don't have any current running through them.
The cows apparently learn to stay away from them, and after that
you don't need the current. "Rise up, cows!" he wrote, "Take your
liberty while despots snore!"

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

If you're a hacker who has thought of one day starting a startup,
there are probably two things keeping you from doing it. One is
that you don't know anything about business. The other is that
you're afraid of competition. Neither of these fences have any
current in them.

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

There are only two things you have to know about business: build
something users love, and make more than you spend. If you get
these two right, you'll be ahead of most startups. You can figure
out the rest as you go.

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

You may not at first make more than you spend, but as long as the
gap is closing fast enough you'll be ok. If you start out underfunded,
it will at least encourage a habit of frugality. The less you
spend, the easier it is to make more than you spend. Fortunately,
it can be very cheap to launch a Web-based application. We launched
on under $10,000, and it would be even cheaper today. We had to
spend thousands on a server, and thousands more to get SSL. (The
only company selling SSL software at the time was Netscape.) Now
you can rent a much more powerful server, with SSL included, for
less than we paid for bandwidth alone. You could launch a Web-based
application now for less than the cost of a fancy office chair.

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

As for building something users love, here are some general tips.
Start by making something clean and simple that you would want to
use yourself. Get a version 1.0 out fast, then continue to improve
the software, listening closely to the users as you do. The customer
is always right, but different customers are right about different
things; the least sophisticated users show you what you need to
simplify and clarify, and the most sophisticated tell you what
features you need to add. The best thing software can be is easy,
but the way to do this is to get the defaults right, not to limit
users' choices. Don't get complacent if your competitors' software
is lame; the standard to compare your software to is what it could
be, not what your current competitors happen to have. Use your
software yourself, all the time. Viaweb was supposed to be an
online store builder, but we used it to make our own site too.
Don't listen to marketing people or designers or product managers
just because of their job titles. If they have good ideas, use
them, but it's up to you to decide; software has to be designed by
hackers who understand design, not designers who know a little
about software. If you can't design software as well as implement
it, don't start a startup.

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

Now let's talk about competition. What you're afraid of is not
presumably groups of hackers like you, but actual companies, with
offices and business plans and salesmen and so on, right? Well,
they are more afraid of you than you are of them, and they're right.
It's a lot easier for a couple of hackers to figure out how to rent
office space or hire sales people than it is for a company of any
size to get software written. I've been on both sides, and I know.
When Viaweb was bought by Yahoo, I suddenly found myself working
for a big company, and it was like trying to run through waist-deep
water.

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

I don't mean to disparage Yahoo. They had some good hackers, and
the top management were real butt-kickers. For a big company, they
were exceptional. But they were still only about a tenth as
productive as a small startup. No big company can do much better
than that. What's scary about Microsoft is that a company so
big can develop software at all. They're like a mountain that
can walk.

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

Don't be intimidated. You can do as much that Microsoft can't as
they can do that you can't. And no one can stop you. You don't
have to ask anyone's permission to develop Web-based applications.
You don't have to do licensing deals, or get shelf space in retail
stores, or grovel to have your application bundled with the OS.
You can deliver software right to the browser, and no one can get
between you and potential users without preventing them from browsing
the Web.

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

You may not believe it, but I promise you, Microsoft is scared of
you. The complacent middle managers may not be, but Bill is,
because he was you once, back in 1975, the last time a new way of
delivering software appeared.

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

Notes

Примечания

[1] Realizing that much of the money is in the services, companies
building lightweight clients have usually tried to combine the
hardware with an
online service.
This approach has not worked
well, partly because you need two different kinds of companies to
build consumer electronics and to run an online service, and partly
because users hate the idea. Giving away the razor and making
money on the blades may work for Gillette, but a razor is much
smaller commitment than a Web terminal. Cell phone handset makers
are satisfied to sell hardware without trying to capture the service
revenue as well. That should probably be the model for Internet
clients too. If someone just sold a nice-looking little box with
a Web browser that you could use to connect through any ISP, every
technophobe in the country would buy one.

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

[2] Security always depends more on not screwing up than any design
decision, but the nature of server-based software will make developers
pay more attention to not screwing up. Compromising a server could
cause such damage that ASPs (that want to stay in business) are
likely to be careful about security.

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

[3] In 1995, when we started Viaweb, Java applets were supposed to
be the technology everyone was going to use to develop server-based
applications. Applets seemed to us an old-fashioned idea. Download
programs to run on the client? Simpler just to go all the way and
run the programs on the server. We wasted little time
on applets, but countless other startups must have been lured into
this tar pit. Few can have escaped alive, or Microsoft could not
have gotten away with dropping Java in the most recent version of
Explorer.

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

[4] This point is due to Trevor Blackwell, who adds "the cost of
writing software goes up more than linearly with its size. Perhaps
this is mainly due to fixing old bugs, and the cost can be more
linear if all bugs are found quickly."

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

[5] The hardest kind of bug to find may be a variant of compound
bug where one bug happens to compensate for another. When you fix
one bug, the other becomes visible. But it will seem as if the
fix is at fault, since that was the last thing you changed.

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

[6] Within Viaweb we once had a contest to describe the worst thing
about our software. Two customer support people tied for first
prize with entries I still shiver to recall. We fixed both problems
immediately.

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

[7] Robert Morris wrote the ordering system, which shoppers used
to place orders. Trevor Blackwell wrote the image generator and
the manager, which merchants used to retrieve orders, view statistics,
and configure domain names etc. I wrote the editor, which merchants
used to build their sites. The ordering system and image generator
were written in C and C++, the manager mostly in Perl, and the editor
in Lisp.

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

[8] Price discrimination is so pervasive (how often have you heard
a retailer claim that their buying power meant lower prices for
you?) that I was surprised to find it was outlawed in the U.S. by
the Robinson-Patman Act of 1936. This law does not appear to be
vigorously enforced.

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

[9] In No Logo, Naomi Klein says that clothing brands favored by
"urban youth" do not try too hard to prevent shoplifting because
in their target market the shoplifters are also the fashion leaders.

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

[10] Companies often wonder what to outsource and what not to.
One possible answer: outsource any job that's not directly exposed
to competitive pressure, because outsourcing it will thereby expose
it to competitive pressure.

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

[11] The two guys were Dan Bricklin and Bob Frankston. Dan wrote
a prototype in Basic in a couple days, then over the course of the
next year they worked together (mostly at night) to make a more
powerful version written in 6502 machine language. Dan was at
Harvard Business School at the time and Bob nominally had a day
job writing software. "There was no great risk in doing a business,"
Bob wrote, "If it failed it failed. No big deal."

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

[12] It's not quite as easy as I make it sound. It took a painfully
long time for word of mouth to get going, and we did not start to
get a lot of press coverage until we hired a
PR firm
(admittedly
the best in the business) for $16,000 per month. However, it was
true that the only significant channel was our own Web site.

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

[13] If the Mac was so great, why did it lose? Cost, again.
Microsoft concentrated on the software business, and unleashed a
swarm of cheap component suppliers on Apple hardware. It did not
help, either, that suits took over during a critical period.

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

[14] One thing that would help Web-based applications, and help
keep the next generation of software from being overshadowed by
Microsoft, would be a good open-source browser. Mozilla is
open-source but seems to have suffered from having been corporate
software for so long. A small, fast browser that was actively
maintained would be a great thing in itself, and would probably
also encourage companies to build little Web appliances.

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

Among other things, a proper open-source browser would cause HTTP
and HTML to continue to evolve (as e.g. Perl has). It would help
Web-based applications greatly to be able to distinguish between
selecting a link and following it; all you'd need to do this would
be a trivial enhancement of HTTP, to allow multiple urls in a
request. Cascading menus would also be good.

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

If you want to change the world, write a new Mosaic. Think it's
too late? In 1998 a lot of people thought it was too late to launch
a new search engine, but Google proved them wrong. There is always
room for something new if the current options suck enough. Make
sure it works on all the free OSes first-- new things start with
their users.

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

[15] Trevor Blackwell, who probably knows more about this from
personal experience than anyone, writes:

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

"I would go farther in saying that because server-based software
is so hard on the programmers, it causes a fundamental economic
shift away from large companies. It requires the kind of intensity
and dedication from programmers that they will only be willing to
provide when it's their own company. Software companies can hire
skilled people to work in a not-too-demanding environment, and can
hire unskilled people to endure hardships, but they can't hire
highly skilled people to bust their asses. Since capital is no
longer needed, big companies have little to bring to the table."

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

[16] In the original version of this essay, I advised avoiding
Javascript. That was a good plan in 2001, but Javascript now works.

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

Thanks to Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson,
and Dan Giffin for reading drafts of this paper; to Dan Bricklin and
Bob Frankston for information about VisiCalc; and again to Ken Anderson
for inviting me to speak at BBN.

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

You'll find this essay and 14 others in
Hackers & Painters.

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