От 1993 година насам ръководя техническия отдел на един малък, свободно достъпен Интернет доставчик, наречен Chester County Interlink (CCIL), намиращ се в Уест Честър, Пенсилвания. (Аз съм един от съоснователите на CCIL и автор на нашия уникален многопотребителски софтуер за таблото за обяви -- можете да му хвърлите едно око чрез telnet до locke.ccil.org. Днес той поддържа почти три хиляди потребители на тридесет линии.) Работата ми позволяваше денонощен достъп до мрежата през линията на CCIL с 56K, а на практика дори и го изискваше!
Постоянно изпитвах въпиюща нужда от Интернет поща. Поради различни сложни причини беше трудно да се подкара SLIP между домашната ми машина (snark.thyrsus.com) и CCIL. Когато най-накрая успях, открих че е доста досадно периодично да правя telnet до locke, за да си проверя пощата. Исках тя ми да се доставя на snark, така че да бъда уведомяван при пристигането й, и да мога да я обработвам с всичките си налични инструменти.
Простото препращане със sendmail не ми вършеше работа, тъй като личната ми машина не беше винаги в мрежата и нямаше постоянен IP адрес. Имах нужда от програма, която да може да се свърже чрез моята SLIP връзка и през нея да изтегли пощата ми, която да бъде доставена на място. Знаех, че съществуват такива решения, и повечето от тях използват един прост приложен протокол, наречен POP (Post Office Protocol). Така или иначе в операционната система BSD/OS на locke вече беше включен готов POP3 сървър.
Нуждаех се от POP3 клиент. Така че влязох в мрежата и открих един. По-точно, открих три-четири. Използвах pop-perl за известно време, но му лиспваше свойство, което изглeждаше очевидно: възможността да пренаписва адресите на източената поща, така че когато отговарям, всичко да сработва правилно.
Проблемът беше следният -- да предположим, че някой с име `joe' ми е изпратил поща от locke. Ако аз източа пощата и сетне се опитам да му отговоря, моят пощенски софтуер бодро би се опитал да я достави на несъществуващия `joe' на snark. Ръчното редактиране на адреса при отговор, за да се добави `@ccil.org' бързо започна да се превръща в голяма мъка.
Това очевидно беше нещо, което компютърът трябва да прави вместо мен. Но никой от съществуващите POP клиенти не знаеше как! И това ни довежда до първата поука:
1. Всеки качествен софтуер възниква, за да начеше крастата на разработчика.
Може би това трябваше да е очевидно (от край време е известно, че "Необходимостта е майка на изобретателността"), но твърде често софтуерните разработчици срещу заплащане прекарват дните си в досадна работа върху програми, от които нито имат нужда, нито намират удоволствие. Но не и в света на Linux -- което може да обясни защо е толкова високо общото ниво на качество на софтуера, създаден в Linux обществото.
И какво мислите -- да не би веднага да се хвърлих в буйния вихър, за да кодирам чисто нов POP3 клиент, който да се конкурира със съществуващите? В никакъв случай! Внимателно огледах POP инструментите, които имах на разположение, задавайки си въпроса: "Кой от тях е най-близо до това, което искам?". Защото:
2. Добрите програмисти знаят какво да пишат. Великите знаят какво да пренапишат (и преизползват).
Не претендирам да съм велик програмист, но поне се опитвам да подражавам на такъв. Характерен белег на великите програмисти е градивният мързел. Те знаят как да получат нещо не с оглед на усилията, които трябва да се вложат, а с оглед на резултатите, и знаят че почти винаги е по-лесно да се започне от добро частично решение, вместо от нищо.
Например Линус Торвалдс всъщност не се опитва да напише Linux от нищото. Вместо това, той започва да преизползва код и идеи от Minix, една малка подобна на Unix операционна система за PC клонинги. В края на краищата, целият код на Minix отпада или е пренаписан изцяло -- но докато е там, той осигурява скеле, опора за пеленачето, което впоследствие ще се преврне в Linux.
В същия дух, аз се оглеждах за съществуващ POP инструмент, който да е сравнително добре кодиран, с цел да го използвам като основа за разработка.
Традицията на споделяне на код в Unix света винаги е била благосклонна към преизползването на кода (тъкмо затова проектът GNU избра Unix като основна операционна система, въпреки сериозните резерви спрямо самата нея). Linux светът доведе тази традиция почти до технологичните й граници -- съществуват терабайти от общодостъпен отворен код. Така че отделянето на време за търсене на нечие друго "почти достатъчно" решение, е по-вероятно да ви донесе добри резултати в Linux света, отколкото където и да е другаде.
Поне така стана при мен. Заедно с тези, които намерих по-рано, моето второ претърсване даде общо девет кандидата -- fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail и upop. Първия на който се спрях, беше `fetchpop' от Seung-Hong Oh. Добавих моето свойство за пренаписване на заглавната част, и направих разни други усъвършенствания, които авторът прие в своето издание 1.9.
Няколко седмици по-късно, обаче, попаднах на кода на `popclient' от Карл Харис, и открих, че имам проблем. Макар че fetchpop носеше някои добри оригинални идеи (например своя daemon режим), той можеше да обработва само POP3 и беше кодиран твърде аматьорски (по това време Seung-Hong беше блестящ, но неопитен програмист, и двата белега на това си личаха). Кодът на Карл беше по-добър -- напълно професионален и надежден. Но на неговата програма й липсваха няколко важни и сложни за реализация свойства на fetchpop (включително тези, които бях кодирал самият аз).
Да остана или да се прехвърля? Ако се прехвърлех, щях да изоставя работата по кода, която вече бях свършил, в замяна на по-добра основа за разработка.
Практически мотив за прехвърлянето беше поддръжката на множество протоколи. POP3 е най-често използваният, но не единствен пощенски протокол. Fetchpop и другите конкуренти не разбираха нищо от POP2, RPOP, или APOP, а аз вече имах смътни помисли за възможността просто за кеф да добавя IMAP (Internet Message Access Protocol, най-модерно проектираният и най-мощен пощенски протокол).
Но аз имах и едно по-скоро теоретично основание да мисля, че прехвърлянето може да е много добра идея. Това е нещо което научих много преди Linux.
3. "Свиквай с мисълта, че един опит ще отиде на вятъра -- така или иначе това ще се случи." (Фред Брукс, "Митичният човеко-месец", Глава 11)
Казано другояче, човек често не разбира проблема, докато не завърши с първата реализация на решението му. Вторият път може би ще знае как да го направи правилно. Така че ако иска да го схване, трябва да бъде готов да започне отначало поне веднъж [JB].
Е, добре -- казах си -- промените във fetchpop бяха моят първи опит. И тъй, аз се прехвърлих.
След като на 25 юни 1996 изпратих първия си набор от поправки до Карл Харис, открих, че всъщност той вече е загубил интерес към popclient. Кодът беше малко изоставен, с висящи незначителни грешки. Аз имах да прилагам много промени, и бързо се споразумяхме, че най-логичното, което мога да сторя, е да поема програмата.
Всъщност без да забележа, проектът дръпна напред. Вече не просто гласях малки промени за един съществуващ POP клиент. Аз поех поддръжката на целия клиент, и в главата ми имаше бълбукащи идеи, които знаех, че може би ще доведат до големи промени.
В една софтуерна култура, която насърчава споделянето на код, това е естественият начин за развитието на един проект. Действах съобразно това:
4. Ако имаш подходящата нагласа, интересните проблеми сами ще те намерят.
Нагласата на Карл Харис обаче беше дори по-важна. Той разбра, че:
5. Когато изгубиш интерес към една програма, последният ти дълг към нея е да я оставиш в ръцете на способен наследник.
Без дори да го обсъждаме, Карл и аз разбирахме, че имаме една обща цел -- да намерим най-доброто решение. Единственият въпрос и за двама ни беше дали мога да докажа, че при мен програмата ще остане в добри ръце. След като го сторих, той постъпи достойно и бързо ми я предаде. Надявам се да постъпя по същия начин, когато дойде и моя ред.