Собор и Базар

2. Проблемы с пересылкой почты.

C 1993 года я занимался решением технических проблем небольшого свободно доступного ISP, который назывался Chester Counter InterLink (CCIL). Я был одним из основателей CCIL и написал свою собственную BBS (вы можете проверить это, сделав telnet на locke.ccil.org). Сегодня он поддерживает почти три тысячи пользователей на девятнадцати линиях. Благодаря этой работе, я имел неограниченный доступ к Internet через линию 56K! Итак, мне пришлось использовать почту Internet. По некоторым причинам мне было сложно соединить CCIL и мою домашнюю машину по протоколу SLIP. В конце концов, когда мне это удалось, оказалось, что очень неудобно делать telnet для проверки своей почты. Я хотел, чтобы когда почта приходила на snark, я получал об этом сообщение и мог бы обрабатывать ее локальными инструментами.

Простой sendmail мне помочь не мог, потому что моя домашняя машина не всегда находится в сети и не имеет статического IP адреса. Мне нужна была программа, которая бы через SLIP соединие забирала мою почту. Я знал, что такие вещи существуют, и большинство из них использует простой протокол POP (Post Office Protocol). К тому же в операционную систему BSD/OS на locke был включен POP3 сервер.

Мне нужен был POP3 клиент. Одну такую программу я нашел через сеть (на самом деле я нашел три или четыре). Некоторое время я использовал pop-perl, но в нем отсутствовала одна необходимая возможность: он не умел выбирать адреса так, чтобы можно было правильно отвечать на письма.

Проблема заключалась в следующем. Допустим, что кто-то по имени 'joe' прислал мне на locke письмо. Если я пытался ответить на него, после того как забрал его на snark, мой mailer пытался адресовать ее несуществующему joe на snark. Исправлять вручную '@ccil.org' было утомительно.

Нужные мне возможности были очевидны, но ни один из существующих POP клиентов не знал как это сделать. Это приводит нас к первому уроку:

1. Все хорошие программы появляются для личных нужд разработчиков.

Необходимость – мать изобретения. Слишком часто программисты работают над программами, из которых они не могут извлечь ни пользы ни удовольствия – ничего кроме денег. Но в мире Linux – все по-другому, и это объясняет высокое качество программ для Linux.

Вы думаете, я тут же начал разрабатывать свой POP3 клиент, соревнуясь с уже имеющимися? Ни в коем случае! Я внимательно осмотрел все POP утилиты, которые были у меня под рукой, и спросил себя, которая из них наиболее соответствует моим требованиям. Потому что:

2. Хорошие программисты знают, что можно написать; а великие знают, что можно переписать.

Я не претендовал на великого программиста, а попытался его имитировать.

Характерная черта великих – это их лень. Они знают, что судят не по усилиям, а по результатам. Почти всегда легче начать с чего-то сделанного, чем с нуля.

Линус Торвальдс, например, не пытался написать свою систему с нуля. Он начал использовать идеи и исходники от Minix, небольшой UNIX-подобной системы для 386 машин. Почти весь исходный текст Minix был переписан, однако, он послужил основой для того что позже стало Linux'ом.

Действуя в том же духе, я начал искать существующую POP утилиту, чтобы использовать ее как основу для разработки.

В мире UNIX'a всегда существовала традиция делать исходные тексты открытыми и дружественными к повторному использованию кода. Именно поэтому проект GNU выбрал UNIX как основную операционную систему. Мир Linux'a полностью перенял эту традицию. Здесь вы можете найти терабайты исходных текстов, и поэтому шансов найти что-нибудь подходящее в мире Linux'a выше, чем где бы то ни было.

Мне это подошло. Вместе с теми программами, которые я нашел раньше, у меня оказались девять кандидатов: fetchpop, PopTart, get-mail, gwpop, pimp, popperl, popc, popmail и upop. Сначала я остановился на fetchpop, автором которой является Seung-Hong Oh. Я добавил туда мою процедуру переписывания заголовка и другие возможности, которые автор принял в версии 1.9. Несколькими неделями позже я наткнулся на код 'popclient' – программу, написанную Карлом Харрисом – и обнаружил одну проблему. Хотя у fetchpop были оригинальные идеи (например, режим демона), но написан он был любителем. Код Карла был значительно профессиональнее, но его программе недоставало несколько важных возможностей, в том числе и тех, которые я реализовал для fetchpop'a.

Что делать? Оставить все как есть или начать заново? Если бы я начал заново мне пришлось бы пожертвовать своими программами ради более надежной основы для разработки.

Самым существенным поводом для того чтобы начать заново, была поддержка нескольких протоколов. POP3 один из наиболее часто используемых post-office протоколов сервера, однако он далеко не единственный. Fetchpop и другие подобные программы не используют POP2, RPOP или APOP, а у меня уже появилась мысль использовать IMAP – недавно разработанный, очень мощный post–office протокол.

3. «Даже если вы не планировали выбрасывать первую версию; выбрасывая ее, вы все равно выигрываете.» (Фред Брукс «The Mythical Man-Month», глава 11) Другими словами, когда вы первый раз реализуете какое-либо решение, вы часто не понимаете проблему до конца. Во второй раз вы уже набираете достаточно знаний, чтобы сделать это правильно. Итак, если вы хотите написать что-нибудь стоящее, лучше хотя бы один раз начать все заново.

Я сказал себе, что изменения в fetchpop были моей первой попыткой. Итак, я решил начать все заново. 25 июня я послал набор программ для popclient'a Карлу Харрису и обнаружил, что он практически потерял интерес к этой работе. Код был не очень аккуратный, и содержал несколько ошибок. Мне пришлось сделать много изменений, и мы согласились, что мне следует стать владельцем программы.

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

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

4. При правильном отношении интересная проблема найдет вас сама.

Отношение Карла Харриса больше не имело значения. Он понял, что:

5. Когда вы теряете интерес к программе, ваша последняя обязанность передать ее компетентному преемнику.

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