менее, автор кулинарной книги может не привести полное описание рецепта голландского соуса непосредственно для яиц «Бенедикт», особенно если этот соус встречается в других блюдах в той же книге, например в рецепте приготовления спаржи. В большой кулинарной книге, скорее всего, будет только один рецепт голландского соуса, на который автор будет ссылаться при описании всех блюд, где он используется, примерно вот так: «см. Голландский соус, с. 123».

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

Эта система не идеальна, поскольку в схеме перекрестных ссылок могут быть ошибки. Например, если я нахожусь в середине приготовления яиц «Бенедикт» и пытаюсь найти ссылку на голландский соус на странице 123, я могу открыть кулинарную книгу на 132 странице, и нужного мне рецепта там не будет.

В программировании постоянно встречаются такие сбои. Люди иногда ошибаются, а компьютеры этого не прощают. При написании программы многое может пойти не так: можно сделать ошибку в синтаксисе языка программирования (сравнимую с опечаткой в кулинарной книге) или сослаться на неверный файл в директиве включения (как посмотреть не на ту страницу в поисках рецепта голландского соуса). Более того, у компиляторов нет никакой возможности понять, что вы имеете в виду, если вы не сказали это совершенно точно.

Когда я делаю похожую ошибку в программе, компилятор выдает мне сообщение об ошибке. Обычно такие сообщения бывают краткими и точными: «expected expression, line 3, column 5» («ожидается выражение в строке 3, колонке 5»). Это может оказаться и ошибкой при наборе, и простой логической ошибкой. Такое сообщение напоминает шеф-повара на суматошной кухне, который бросает один взгляд через плечо помощника, готовящего тарелку яиц «Бенедикт», и выносит приговор: «Голландский соус слишком густой!» Оба этих сообщения констатируют ошибку, и, хотя в них нет четких инструкций решения проблемы, они чрезвычайно полезны.

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

* * *

Получив «добро» от начальства, мы с Ричардом и Доном собрались, чтобы разработать нашу стратегию портирования.

Прежде всего мы должны были вернуться к демоверсии Ричарда и разобраться со всеми трудными местами, которые он в ней обошел. Чтобы сделать это, нам предстояло скопировать исходный код Konqueror на Macintosh и скомпилировать его. Затем нужно было все проверить и выловить ошибки, чтобы в результате код браузера выглядел как написанный для системы Mac.

Также, поскольку Konqueror относился к свободному ПО, нам приходилось подчиняться лицензии Столлмана, которую авторы прикрепили к своему софту. Наше руководство хотело опубликовать исходный код части программного обеспечения, но по большей части он должен был быть закрытым и проприетарным[15]. Причина проста: Mac OS X была продуктом, который приносил Apple прибыль. В эру iPhone компания начала публиковать бесплатные обновления программного обеспечения, но во времена, о которых идет речь, операционная система Macintosh в Соединенных Штатах стоила 129 долларов для одного компьютера{13}. Когда мы продумывали нашу стратегию разработки веб-браузера, руководство предпочитало не «свободное, как свобода слова» и не «бесплатное, как бесплатное пиво» ПО, а «хорошо спрятанное, как деньги».

Мы с Доном и Ричардом должны были работать, соблюдая это ограничение, и, пока мы вырабатывали наш план портирования, учитывая противостояние открытого и закрытого кода, в наших отношениях начала вырисовываться интересная динамика.

Дон обожал занудствовать по поводу деталей лицензий свободного ПО. За время работы в Netscape и Eazel он подробно изучил эту тему и любил чесать языком, обсуждая достоинства, недостатки и положения различных лицензий. Он явно получал удовольствие, объясняя хитросплетения стандартной общественной лицензии ограниченного применения исходного кода Konqueror. Эти положения гласили, что если мы включаем Konqueror в «кулинарную книгу» Macintosh как отдельную главу, используя его код только с помощью перекрестных ссылок, и открыто публикуем любые изменения, которые делаем, чтобы рецепт Konqueror «получался вкусным» на Macintosh, мы работаем в соответствии с лицензией свободного программного обеспечения Столлмана.

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

Я был где-то посередине.

Я серьезно относился к лицензии свободного программного обеспечения. Уважать условия, на которых кто-то другой делал свою работу доступной всем, было правильно.

Более того, если мы не будем соблюдать условия лицензионного соглашения Konqueror, это может привести к судебному иску в отношении Apple. Я не хотел зацикливаться на всех этих лицензиях, но считал важным потратить некоторое время и удостовериться, что мы учли все варианты и с технической, и с юридической точки зрения.

К лицензированию мы относились по-разному, так