Kad roze nav roze?¹

Kad biju izpētījis Linusa darbību un izveidojis viņa veiksmes teoriju, es pieņēmu apzinātu lēmumu pārbaudīt šo teoriju praksē savā jaunajā (protams, daudz vienkāršākā un mazāk ambiciozā) projektā.

Bet pirmais, ko izdarīju, es pārkārtoju un vienkāršoju popclient. Karla Harisa implementācija bija ļoti pamatota, bet atklāja nevajadzīgu sarežģītību, raksturīgu daudziem C programmētājiem. Viņš uzskatīja kodu par galveno bet datu struktūras kā atbalstu kodam. Rezultātā kods bija brīnišķīgs, bet datu struktūras izskatījās kā pagaidu un diezgan briesmīgas (vismaz pēc hakera un LISP veterāna augstajiem standartiem).

Tomēr man bija arī citi iemesli bez koda un datu struktūru uzlabošanas. Tā bija nepieciešamība izveidot kodu, ko es pats pilnībā pārzinu. Nav nekāda prieka būt atbildīgam par kļūdu labošanu kodā, ko pats nepārzini.

Pirmo mēnesi es vienkārši sekoju pieņēmumiem, kas izrietēja no Karla pamatdizaina. Pirmā nopietnā izmaiņa bija tā, ka es pievienoju IMAP atbalstu. Es to izdarīju, pārtaisot protokolu mašīnas vienkāršos draiveros un trīs metožu tabulās (priekš POP2, POP3 un IMAP). Šī un iepriekšēja izmaiņa ilustrē vispārīgo principu, ko labiem programmētājiem būtu jāpatur prātā, īpaši tādās valodās kā C, kas tiešā veidā neatbalsta dinamiskos tipus:

9. Gudras datu struktūras un vienkāršs kods strādā daudz labāk kā pretējā veidā.

Brūks savas grāmatas 9. nodaļā raksta "Parādi man plūsmas diagrammu un paslēp tabulas, un es turpināšu nesaprast. Parādi man tabulas, un parasti man plūsmas diagrammas nebūs vajadzīgas. Tās būs acīmredzamas". Pieļaujot trīsdesmit gadu terminoloģijas un kultūras izmaiņas, tas nozīmē to pašu.

Ap šo laiku (1996. gada agrs septembris, apmēram sešas nedēļas pēc sākuma) es sāku domāt, ka būtu nepieciešama nosaukuma maiņa — pēc visa tā tas vairs nebija vienkāršs POP klients. Bet es svārstījos, jo dizainā tomēr nebija nekā patiesi jauna. Manai popclient versijai vēl vajadzēja iegūt pašai savu identitāti.

Tas radikāli mainījās, kad es popclient iemācīju pārsūtīt savākto vēstuli uz SMTP portu. Es nonākšu līdz tam pēc brīža. Bet vispirms — kā es jau agrāk teicu, es nolēmu izmantot šo projektu, lai pārbaudītu savu teoriju par to, ko Linuss Torvalds ir izdarījis pareizi. Kā (jūs varētu prasīt) es to izdarīju? Sekojošos veidos:

• Es izlaidu agri un bieži (parasti ne retāk kā katras desmit dienas, intensīvas izstrādes brīžos — katru dienu).
• Es papildināju savu beta lietotāju sarakstu ar katru, kas man jautāja par fetchmail.
• Es nosūtīju garus, izsmeļošus laidienu paziņojumus beta lietotājiem, lai iedrošinātu viņus piedalīties.
• Un es klausījos savos beta testētājos, aptaujājot tos par dizaina lēmumiem, un atzinīgi novērtēju tos katru reizi, kad viņi man atsūtīja labojumu vai atsauksmes.

Atdeve no šiem vienkāršajiem pasākumiem bija momentāna. Jau no projekta sākuma man bija kļūdu ziņojumi ar tādu kvalitāti, par kuru vairums izstrādātāju būtu gatavi nogalināt, bieži vien, pat ar pievienotiem koda labojumiem. Fanu vēstulēs es ieguvu saturīgu kritiku un vērtīgus programmas iespēju uzlabojumus. Tas noved pie sekojoša likuma:

10. Attiecies pret saviem beta testētājiem kā pret savu vērtīgāko resursu, un viņi tev atsauksies kļūstot par tavu vērtīgāko resursu.

Viens interesants projekta veiksmes mērs ir kopējais projekta beta testētāju — projekta draugu skaits. Pēdējā šī darba pārskatīšanas laikā (2000. gada novembris) tajā bija 287 dalībnieku un tam pievienojās divi vai trīs jauni dalībnieki nedēļā.

Patiesībā, kad es pārskatīju sarakstu 1997. gada maija beigās, es pamanīju, ka  tas sāk zaudēt savus dalībniekus no sava augstākā punkta ap 300 dalībniekiem interesanta iemesla dēļ. Daudzi dalībnieki lūdza mani izslēgt viņus no saraksta, jo fetchmail darbojas tik labi, ka viņiem vairs nav nepieciešama sarakste šajā listē! Iespējams, tāda ir jebkura nobrieduša atvērtā koda projekta dzīves cikla daļa.

1. ^ Variācija par Ģertrūdes Šteinas frāzi Roze ir roze