Докато изучавах поведението на Линус и съставях теория защо то биде успешно, съвсем съзнателено реших да проверя тази теория върху моя нов (несъмнено съвсем не толкова сложен и амбициозен) проект.
Но първото което сторих, бе значително да реорганизирам и опростя popclient. Реализацията на Карл Харис беше в много добро състояние, но й личеше един особен вид ненужна сложност, типична за много програмисти на C. Карл третираше кода като най-важен, а структурите от данни бяха като поддръжка за кода. В резултат на това, кодът беше прекрасен, но замисълът на структурите от данни беше непоследователен и твърде грозен (поне за високите стандарти на такъв стар LISP хакер като мен).
Освен за да усъвършенствам кода и дизайна на структурите от данни, имах и друга причина за това пренаписване. Така щях да ги развия в нещо, което разбирам напълно. Никак не е весело да отговаряш за поправянето на грешки в програма, която не разбираш.
През първия месец и нещо аз просто изпълнявах докрай следствията от основния дизайн на Карл. Първата сериозна промяна, която направих, беше да добавя поддръжка на IMAP. Сторих това като реорганизирах машините на протоколи в един общ драйвер и три таблици на методите (за POP2, POP3, и IMAP). Тази промяна, както и предишните, илюстрира един общ принцип, който е хубаво програмистите да имат наум, особено при езици като C, които по природа не извършват динамично типизиране:
9. Интелигентните структури от данни и тъпият код работят много по-добре, отколкото в обратния случай.
Брукс, Глава 9: "Покажи ми [кода] си и скрий [структурите от данни], и аз ще продължавам да съм объркан. Покажи ми [структурите си от данни], и обикновено няма да имам нужда от твоя [код]; ще е очевидно."
В действителност, той е казал "блок-схеми" и "таблици". Но отчитайки тридесетгодишно терминологично/културно изместване, смисълът е почти същия.
От този момент (в началото на септември 1996, някъде около шест седмици от самото начало) започнах да мисля, че е редно да се смени името -- в края на краищата, това вече не беше просто POP клиент. Но се колебаех, защото досега в дизайна нямаше нищо истински ново. Моята версия на popclient все още трябваше да развие своя собствена идентичност.
Това коренно се промени, когато fetchmail се научи как да препраща взетата поща към SMTP порт. Ще се върна на това след малко. По-напред туй: по-горе казах, че реших да използвам този проект, за да изпробвам теорията си за това какво свястно нещо е направил Линус Торвалдс. Как -- с право може би ще попитате -- сторих това? По следния начин:
Отплатата за тези прости оценки беше незабавна. От началото на проекта получих толкова качествени доклади за грешки, за които повечето разработчици биха извършили убийство -- често дори прикрепени с добри поправки. Получих смислени критики, получих поща от почитатели, получих интелигентни предложения за нови свойства на програмата. Което довежда до:
10. Ако се отнасяш към своите бета изпитатели като към свой най-ценен ресурс, те ще ти отвърнат, превръщайки се в най-ценния ти ресурс.
Интересен критерий за успеха на fetchmail е самият размер на бета списъка на проекта -- броят на приятелите на fetchmail. По времето, когато пиша това, той има 249 членове и расте с двама-трима седмично.
Всъщност, тъй като го ревизирах в края на май 1997, поради една интересна причина списъкът започна да губи членове след като достигна своя връх от около 300. Няколко души ме помолиха да ги отпиша, тъй като fetchmail им служел толкова добре, че те вече нямали нужда да следят трафика от списъка! Може би това е част от нормалния цикъл на живот на един зрял проект от базарен тип.