hroch.spseol.czhroch.spseol.cz/~nozka/site/jaky_je_unix/katedrala-trziste.pdf · kkp # $ # ( ( $...

START EN CS EN/CS TISK P/T ZVONOriginal location: http://www.netaxs.com/~esr/writings/cathedral-bazaar/Copyright: Eric Raymond

Eric Raymond Eric Raymond

The Cathedral and the

BazaarKatedrála a tr�iště

22.11.1998 22.11.1998

Přeložil: Miloslav Nic [MNaaaa]27.7.1999

I anatomize a successful opensource

project, fetchmail, that was run as a

deliberate test of some surprising theories

about software engineering suggested by

the history of Linux. I discuss these theories

in terms of two fundamentally different

development styles, the ``cathedral'' model

of most of the commercial world versus the

``bazaar'' model of the Linux world. I show

that these models derive from opposing

assumptions about the nature of the

softwaredebugging task. I then make a

sustained argument from the Linux

experience for the proposition that ``Given

enough eyeballs, all bugs are shallow'',

suggest productive analogies with other

selfcorrecting systems of selfish agents,

and conclude with some exploration of the

implications of this insight for the future of

software.

Podrobně rozebírám úspěšný otevřený

projekt, fetchmail. Tento projekt cíleně

testoval některé překvapivé teorie o

softwarovém in�enýrství. Tyto teorie,

inspirované historií Linuxu, jsou

zasazeny do kontextu dvou různých

vývojových stylů, modelu "katedrály" ,

kterou pou�ívá většina komerčního

světa a Linuxového modelu "tr�iště".

Ukazuji, �e tyto modely vycházejí z

protikladných představ o vývoji

software. Na základě zkušeností

získaných s Linuxem poté dokazuji, �e

"Pokud máte dostatek očí, všechny

chyby jsou průhledné", nabízím analogie

s jinými sebeopravujícími systémy a

článek končím diskuzí o tom, jaké

implikace tato fakta mají pro

budoucnost software.

Contents Obsah

The Cathedral and the Bazaar Katedrála a tržiště

The Mail Must Get Through Pošta musí projít

The Importance of Having Users Je důležité mít uživatele.

Zvon: The Cathedral and the Bazaar http://www.zvon.org/ZvonHTML/Translations/cath...

1 z 2 22.2.2010 14:57

Release Early, Release Often Publikuj brzy, publikuj často

When Is A Rose Not A Rose? Když růže není růží

Popclient becomes Fetchmail Popclient se stává fetchmailem

Fetchmail Grows Up Fetchmail dospívá

A Few More Lessons From FetchmailNěkolik dalších lekcí zfetchmailu

Necessary Preconditions for theBazaar Style

Nutné podmínky pro styl tržiště

The Social Context of Open-SourceSoftware

Společenský kontext otevřenéhosoftware

Acknowledgements Poděkování

For Further Reading K dalšímu čtení

Epilog: Netscape Embraces theBazaar!

Epilog: Netscape přijala tržiště

START EN CS EN/CS TISK P/T ZVON

Zvon: The Cathedral and the Bazaar http://www.zvon.org/ZvonHTML/Translations/cath...

2 z 2 22.2.2010 14:57

TOC / OBSAH >>> EN CS EN/CS ZVON P/T1. The Cathedral andthe Bazaar

1. Katedrála a tržiště

Linux is subversive. Who would havethought even five years ago that aworld-class operating system couldcoalesce as if by magic out ofpart-time hacking by several thousanddevelopers scattered all over theplanet, connected only by the tenuousstrands of the Internet?

Kdo by si pomyslel ještě před pěti lety,že prvotřídní operační systém můževzniknout jakoby kouzlem z dobrovolnépráce několika tisíc programátorůroztroušených po celém světěpropojených pouze chapadly Internetu.

Certainly not I. By the time Linuxswam onto my radar screen in early1993, I had already been involved inUnix and open-source development forten years. I was one of the first GNUcontributors in the mid-1980s. I hadreleased a good deal of open-sourcesoftware onto the net, developing orco-developing several programs(nethack, Emacs VC and GUD modes,xlife, and others) that are still in wideuse today. I thought I knew how it wasdone.

Já určitě ne. Počátkem roku 1993, kdyse Linux poprvé objevil na mé radarovéobrazovce, jsem se již 10 let zabývalUnixem a otevřeným vývojem . Vpolovině osmdesátých letl jsem patřil kprvým přispěvatelům GNU, přesInternet jsem zpřístupnil řaduotevřeného software, vyvinul jsem nebose podílel na vývoji několika programů(nethack, VC a GUD módy Emacsu,xlife, atd.), které se dodnes používají.Domníval jsem se, že vím jak na to.

Linux overturned much of what Ithought I knew. I had been preachingthe Unix gospel of small tools, rapidprototyping and evolutionaryprogramming for years. But I alsobelieved there was a certain criticalcomplexity above which a morecentralized, a priori approach wasrequired. I believed that the mostimportant software (operatingsystems and really large tools likeEmacs) needed to be built likecathedrals, carefully crafted byindividual wizards or small bands ofmages working in splendid isolation,with no beta to be released before its

Linux postavil na hlavu mnohé z toho,co jsem znal. Léta jsem šířil Unixovouvíru v drobné nástroje, rychlé psaníprototypů a evoluční programování.Také jsem ale věřil v existenci kritickémeze složitosti, po jejímž překročení jejiž vyžadován více centralizovanýpřístup. Věřil jsem, že nejdůležitějšísoftware (operační systémy a opravduvelké nástroje jako Emacs) musí býtstavěny stejně jako katedrály, pečlivěopracovávány jednotlivými čarodějinebo malými skupinami kouzelníkůpracujících v příjemném osamění apublikujícími prvé výsledky své práceaž ve vhodný čas.

Zvon: http://www.zvon.org/ZvonHTML/Translations/cath...

1 z 3 22.2.2010 14:58

time.

Linus Torvalds's style of development -release early and often, delegateeverything you can, be open to thepoint of promiscuity - came as asurprise. No quiet, reverent cathedral-building here -- rather, the Linuxcommunity seemed to resemble agreat babbling bazaar of differingagendas and approaches (aptlysymbolized by the Linux archive sites,who'd take submissions from anyone)out of which a coherent and stablesystem could seemingly emerge onlyby a succession of miracles.

Vývoj ve stylu Linuse Torvalda -publikuj brzy a často, přenes naostatní vše co můžeš, buď otevřený ažtéměř k bodu promiskuity, to bylovelké překvapení.. Linuxovéspolečenství více připomíná velkéhlučné tržiště různých metod apostupů než tichou, oddanou práci nastavbě katedrály. Linuxové archivy,které přijímají příspěvky odkohokoliv, jsou toho důkazem. Zdáloby se, že z něčeho takového se můžekoherentní a stabilní systém vynořitpouze sérií zázraků.

The fact that this bazaar style seemedto work, and work well, came as adistinct shock. As I learned my wayaround, I worked hard not just atindividual projects, but also at tryingto understand why the Linux worldnot only didn't fly apart in confusionbut seemed to go from strength tostrength at a speed barely imaginableto cathedral-builders.

Fakt, že tento styl tržiště fungoval afungoval dobře, to bylo velképřekvapení. Když jsem se naučil vtomto světě orientovat, pracoval jsemusilovně nejen na jednotlivýchprojektech, ale také jsem se pokoušelporozumět, jak je možné, že se světLinuxu nejen že nerozletí na kusy vnaprostém zmatku, ale naopakneustále sílí rychlostí, kterou si umístavitelé katedrál stěží představit.

By mid-1996 I thought I wasbeginning to understand. Chancehanded me a perfect way to test mytheory, in the form of an open-sourceproject which I could consciously tryto run in the bazaar style. So I did --and it was a significant success.

V polovině roku 1996 se mi zdálo, žejsem systému porozuměl. Náhoda mipřihrála do cesty výborný způsob, jaksvé teorie otestovat formou otevřenéhoprojektu, který jsem mohl cíleněrozběhnout ve stylu tržiště. Využil jsemšance a projekt skončil velkýmúspěchem.

In the rest of this article, I'll tell thestory of that project, and I'll use it topropose some aphorisms abouteffective open-source development.Not all of these are things I firstlearned in the Linux world, but we'llsee how the Linux world gives themparticular point. If I'm correct, they'llhelp you understand exactly what it is

Ve zbytku článku vám budu vyprávětpříběh tohoto projektu a na jehozákladě navrhnu několik algoritmů proefektivní práci v otevřeném projektu.Ne vše jsem se naučil až ve světěLinuxu, ale uvidíme, jak Linuxový světklade na některé věci obzvláštní důraz.Pokud se nemýlím, pomůže vámpřesně pochopit, co činí z Linuxového


2 z 3 22.2.2010 14:58

that makes the Linux community sucha fountain of good software -- and helpyou become more productive yourself.

společenství takovou studnici dobréhosoftware a pomůže i vám zvýšitproduktivitu.

TOC / OBSAH >>> EN CS EN/CS ZVON P/T


3 z 3 22.2.2010 14:58

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T2. The Mail Must GetThrough

2. Pošta musí projít

Since 1993 I'd been running thetechnical side of a small free-accessISP called Chester County InterLink(CCIL) in West Chester, Pennsylvania(I co-founded CCIL and wrote ourunique multiuser bulletin-boardsoftware -- you can check it out bytelnetting to locke.ccil.org. Today itsupports almost three thousand userson thirty lines.) The job allowed me24-hour-a-day access to the netthrough CCIL's 56K line -- in fact, itpractically demanded it!

Od roku 1993 jsem měl na starostitechnické zabezpečení maléhoposkytovatele bezplatného přístupu kInternetu (Chester County InterLink -CCIL , West Chester, Pennsylvania).Patřím k zakladatelům CCIL a napsaljsem pro něj unikátní mnohauživatelskýbuletinový software, který si můžeteprohlédnout přes telnet na adreselocke.ccil.org. V dnešní doběpodporuje téměř 3000 uživatelů na 30linkách. Tato práce mi umožnila 24hodinový přístup na Internet přes 56Klinku CCIL, pro moji práce byl takovýpřístup nutností.

Accordingly, I had gotten quite usedto instant Internet email. Forcomplicated reasons, it was hard toget SLIP to work between my homemachine (snark.thyrsus.com) andCCIL. When I finally succeeded, Ifound having to periodically telnetover to locke to check my mailannoying. What I wanted was for mymail to be delivered on snark so thatI would be notified when it arrivedand could handle it using all my localtools.

Díky tomu jsem si zvykl na okamžitýpřístup k e-mailu. Z různých složitýchdůvodů bylo obtížné zprovoznit SLIPmezi mým domácím počítačem(snark.thyrsus.com) a CCIL. Když se mito konečně podařilo, pravidelnélogování a kontrola pošty přes telnet mězačalo obtěžovat. Potřeboval jsem nějakpřesunout poštu na můj domácí počítačsnark tak, abych byl upozorněn přijejím přijetí. Poštu jsem pak chtěl dáleizpracovávat s pomocí různýchprogramů na mém osobním počítači.

Simple sendmail forwarding wouldn'twork, because my personal machineisn't always on the net and doesn'thave a static IP address. What Ineeded was a program that wouldreach out over my SLIP connectionand pull across my mail to bedelivered locally. I knew such thingsexisted, and that most of them used a

Jednoduché přesměrování poštyprogramem sendmail nepřipadalo vúvahu, protože můj počítač není vždypřipojen k síti a nemá stálou IP adresu.Potřeboval jsem program, který by mnepřipojil přes SLIP a poté přenesl poštu.Věděl jsem, že takové programy existujía že většina z nich využívá jednoduchýaplikační protokol, nazývaný POP


1 z 6 22.2.2010 14:59

simple application protocol calledPOP (Post Office Protocol). And sureenough, there was already a POP3server included with locke's BSD/OSoperating system.

(poštovní protokol). A skutečně, nášBSD/OS operační systém v soběobsahoval i POP3 server.

I needed a POP3 client. So I went outon the net and found one. Actually, Ifound three or four. I used pop-perlfor a while, but it was missing whatseemed an obvious feature, theability to hack the addresses onfetched mail so replies would workproperly.

Potřeboval jsem tedy POP3 klienta.Rozhlédl jsem se po síti a jeden jsemnašel. Tedy ve skutečnosti jsem jichnalezl několik. Po nějaký čas jsempoužíval pop-perl, ale tomu chybělafunkce, kterou jsem považoval zapodstatnou, nebyl totiž schopenpozměnit adresy přicházející pošty tak,abych mohl na obdrženou poštu přímoodpovídat.

The problem was this: supposesomeone named `joe' on locke sentme mail. If I fetched the mail tosnark and then tried to reply to it,my mailer would cheerfully try toship it to a nonexistent `joe' onsnark. Hand-editing reply addressesto tack on `@ccil.org' quickly got tobe a serious pain.

Problém spočíval v tomto: řekněme, ženěkdo se jménem "joe" my poslale-mail. Pokud jsem si jej stáhl na snarka poté se na něj pokusil odpovědět, můjpoštovní klient se snažil poslat odpověďneexistujícímu joeovi na snarku. Ručníeditace adres mne ale brzy začalaunavovat.

This was clearly something thecomputer ought to be doing for me.But none of the existing POP clientsknew how! And this brings us to thefirst lesson:

Toto byla věc, kterou mohl počítač dělatza mne. Žádný z existujících klientů alenevěděl jak. A to nám přináší prvéponaučení:

1. Every good work of softwarestarts by scratching a developer'spersonal itch.

1. Každý dobrý program začíná tím,že řeší potíže samotnéhoprogramátora.

Perhaps this should have beenobvious (it's long been proverbial that``Necessity is the mother ofinvention'') but too often softwaredevelopers spend their days grindingaway for pay at programs theyneither need nor love. But not in theLinux world -- which may explainwhy the average quality of softwareoriginated in the Linux community is

Možná, že by to mělo být samozřejmé(existuje staré přísloví: "Nutnost jematka pokroku"), ale až příliš častovývojáři traví svůj čas prací naprogramech, za které jsou placeni, alekteré ani nemilují ani nepotřebují. Tovšak neplatí ve světě Linuxu a snadprávě proto je průměrná kvalitasoftware vyvinutého v Linuxovémspolečenství tak vysoká.


2 z 6 22.2.2010 14:59

so high.

So, did I immediately launch into afurious whirl of coding up abrand-new POP3 client to competewith the existing ones? Not on yourlife! I looked carefully at the POPutilities I had in hand, asking myself``which one is closest to what I want?

Takže, vrhl jsem se okamžitě dohorečného programování a začal psátzcela nového POP3 klienta, který bymohl soutěžit s existujícími programy?V žádném případě! Pečlivě jsemprostudoval známé POP programy ahledal takový, který nejvíce odpovídalmým představám.

2. Because good programmersknow what to write. Great onesknow what to rewrite (and reuse).

2. Protože dobří programátoři vědíco psát. Velcí vědí, co přepsat (aznovu použít)

While I don't claim to be a greatprogrammer, I try to imitate one. Animportant trait of the great ones isconstructive laziness. They know thatyou get an A not for effort but forresults, and that it's almost alwayseasier to start from a good partialsolution than from nothing at all.

Ačkoli o sobě netvrdím, že jsem velkýprogramátor, snažím se ty velkénapodobit. Důležitým rysem velkýchprogramátorů je konstruktivnílenost.Vědí, že člověk není oceňován zaúsilí, ale za výsledky, a že je téměř vždysnažší začít od dobrých částečnýchřešení než od úplého počátku.

Linus Torvalds, for example, didn'tactually try to write Linux fromscratch. Instead, he started byreusing code and ideas from Minix, atiny Unix-like OS for 386 machines.Eventually all the Minix code wentaway or was completely rewritten --but while it was there, it providedscaffolding for the infant that wouldeventually become Linux.

Linus Torvalds také nezačal psátLinux od prvé řádky. Místo toho použilkód a nápady Minixu, maléhooperačního systému napodobujícíhoUnix, který byl určen pro počítače řady386. Dnes již veškerý původní kódMinixu buďto zmizel zcela nebo byl odzákladu přepsán, ale na počátkuvytvářel lešení podpírající batole, kterése nakonec stalo Linuxem.

In the same spirit, I went looking foran existing POP utility that wasreasonably well coded, to use as adevelopment base.

Veden stejnými motivy jsem prohlíželexistující POP programy a hledaltakové, které byly vhodné jako základpro další vývoj.

The source-sharing tradition of theUnix world has always been friendlyto code reuse (this is why the GNUproject chose Unix as a base OS, inspite of serious reservations aboutthe OS itself). The Linux world hastaken this tradition nearly to itstechnological limit; it has terabytes

Tradice sdílení zdrojových souborůUnixového světa byla vždy nakloněnarecyklování starších kódů (proto takéGNU zvolil Unix jako svůj základníoperační systém). Linux dovedl tutotradici téměř k jejímu technologickémulimitu. V jeho světě jsou přístupnéterabyty volných zdrojů. Jestliže zde


3 z 6 22.2.2010 14:59

of open sources generally available.So spending time looking for someelse's almost-good-enough is morelikely to give you good results in theLinux world than anywhere else.

hledáte téměř vyhovující program, mátevětší šanci na úspěch než kdekolivjinde.

And it did for me. With those I'dfound earlier, my second searchmade up a total of nine candidates --fetchpop, PopTart, get-mail, gwpop,pimp, pop-perl, popc, popmail andupop. The one I first settled on was`fetchpop' by Seung-Hong Oh. I putmy header-rewrite feature in it, andmade various other improvementswhich the author accepted into his1.9 release.

Obdobně vše fungovalo i v mémpřípadě. Spolu s tím, co jsem nalezl jiždříve, můj druhý průzkum odkrylcelkem 9 kandidátů: fetchpop, PopTart,get-mail, gwpop, pimp, pop-perl, popc,popmail a upop. Nejdříve jsem serozhodl pro `fetchpop' od Seung-HongOh. Vložil jsem do něho moji funkci napřepisování adres a učinil několikdalších změn, které autor pozdějizařadil do verze 1.9.

A few weeks later, though, Istumbled across the code for`popclient' by Carl Harris, and foundI had a problem. Though fetchpophad some good original ideas in it(such as its daemon mode), it couldonly handle POP3 and was ratheramateurishly coded (Seung-Hong wasa bright but inexperiencedprogrammer, and both traitsshowed). Carl's code was better,quite professional and solid, but hisprogram lacked several importantand rather tricky-to-implementfetchpop features (including those I'dcoded myself).

Několik týdnů později jsem ale narazilna zdroj programu `popclient', kterýnapsal Carl Harris, a zjistil jsem, žestojím před problémem. Ačkolivfetchpop obsahoval několik dobrýchpůvodních nápadů (například móddémon), dokázal pouze spravovat POP3a byl programován poněkud amatérsky(Seung-Hong byl schopný, alenezkušený programátor, a obě tytocharakteristiky se na kódu projevily).Carlův kód byl lepší, na profesionálníúrovni a stabilní, ale jeho programuchybělo několik důležitých funkcí,které je celkem obtížné naprogramovat,včetně těch, které jsem programoval jásám.

Stay or switch? If I switched, I'd bethrowing away the coding I'd alreadydone in exchange for a betterdevelopment base.

Zůstat při starém nebo volit změnu?Pokud bych se rozhodl pro změnu,musel bych obětovat všechen dosudnapsaný kód, získal bych ale lepšívývojovou základnu.

A practical motive to switch was thepresence of multiple-protocolsupport. POP3 is the most commonlyused of the post-office serverprotocols, but not the only one.

Praktickým argumentem, kterýdoporučoval změnu, byla podpora řadyprotokolů. POP3 je nejběžněji používanýprotokol, ale není jediný. Fetchpop adalší podobné programy neuměly POP2,


4 z 6 22.2.2010 14:59

Fetchpop and the other competitiondidn't do POP2, RPOP, or APOP, andI was already having vague thoughtsof perhaps adding IMAP (InternetMessage Access Protocol, the mostrecently designed and most powerfulpost-office protocol) just for fun.

RPOP nebo APOP a já již začínalpřemýšlet o přidání IMAPu(nejnovějšího a nejvšestrannějšíhopoštovního protokolu).

But I had a more theoretical reasonto think switching might be as goodan idea as well, something I learnedlong before Linux.

Měl jsem ale i další, teoretický důvod,proč přemýšlet o změně. Bylo to něco,co jsem se naučil dlouho před Linuxem.

3. ``Plan to throw one away; youwill, anyhow.'' (Fred Brooks, ``TheMythical Man-Month'', Chapter11)

Počíteje s tím, že alespoň jednoubudete muset vše přepsat, stejněvás to nemine ((Fred Brooks, ``TheMythical Man-Month'', Chapter 11)

Or, to put it another way, you oftendon't really understand the problemuntil after the first time youimplement a solution. The secondtime, maybe you know enough to doit right. So if you want to get it right,be ready to start over at least once.

Nebo, řečeno jinými slovy, tak dlouhoproblému doopravdy neporozumíte,pokud se ho nepokusíte nějak vyřešit.Podruhé už budete možná vědět, jak nato. Takže pokud chcete najít správnéřešení, buďte připraveni začít alespoňjednou znovu.

Well (I told myself) the changes tofetchpop had been my first try. So Iswitched.

Dobře( řekl jsem si), úpravy fetchpopubyly mým prvním pokusem a změniljsem programovou základnu.

After I sent my first set of popclientpatches to Carl Harris on 25 June1996, I found out that he hadbasically lost interest in popclientsome time before. The code was a bitdusty, with minor bugs hanging out.I had many changes to make, and wequickly agreed that the logical thingfor me to do was take over theprogram.

Poté, co jsem 25. června 1996 poslalopravy popclienta Carl Harrisovi, zjistiljsem, že on sám již ve své podstatěztratil o projekt zájem. Kód už byltrochu zaprášený a bylo v něm několikdrobných, snadno opravitelných chyb.Já potřeboval učinit řadu změn a takjsme se rychle dohodli na tom, žeprojekt převezmu.

Without my actually noticing, theproject had escalated. No longer wasI just contemplating minor patches toan existing POP client. I took onmaintaining an entire one, and therewere ideas bubbling in my head thatI knew would probably lead to major

Aniž jsem si to sám uvědomil, projektnabral na tempu. Nepracoval jsem jižpouze na drobných změnáchexistujícího POP klienta. Převzal jsemvývoj celého programu a v mé hlavě serojily nápady, od kterých jsem očekával,že pravděpodobně povedou k velkým


5 z 6 22.2.2010 14:59

changes. změnám.

In a software culture that encouragescode-sharing, this is a natural wayfor a project to evolve. I was actingout this:

Ve společenstvích programátorů, vekterých je podporováno sdílení kódu, jetakovýto vývoj projektu přirozený. Jednaljsem podle následujícího pravidla:

4. If you have the right attitude,interesting problems will findyou.

4. Pokud máte správný přístup,zajímavé problémy si Vás najdousami.

But Carl Harris's attitude was evenmore important. He understood that

Ale přístup Carla Harrise byl ještědůležitější. Věděl že:

5. When you lose interest in aprogram, your last duty to it is tohand it off to a competentsuccessor.

5. Když ztratíte zájem o program,vaší poslední povinností je předat jejschopnému nástupci.

Without ever having to discuss it,Carl and I knew we had a commongoal of having the best solution outthere. The only question for either ofus was whether I could establish thatI was a safe pair of hands. Once I didthat, he acted with grace anddispatch. I hope I will act as wellwhen it comes my turn.

Aniž jsme o tom museli diskutovat, Carli já jsme věděli, že máme společný cíl,nalézt to nejlepší možné řešení. Jedinouotázkou pro oba zůstalo, jak prokázat,že jsem vhodný následovník. Jakmile semi to podařilo, zachoval se úctyhodně, apřenechal mi své místo. Doufám, žebudu jednat stejně, až přijde můj čas.

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T


6 z 6 22.2.2010 14:59

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T3. The Importance ofHaving Users

3. Je důležité mítuživatele.

And so I inherited popclient. Just asimportantly, I inherited popclient'suser base. Users are wonderful thingsto have, and not just because theydemonstrate that you're serving a need,that you've done something right.Properly cultivated, they can becomeco-developers.

A tak jsem zdědil popclienta. Rovněž,a to bylo stejně důležité, jsem zdědiljeho uživatele. Mít uživatele, to jebezvadná věc, a nejen proto, žemůžete prokázat, že děláte něcoužitečného. Pokud si jich řádněhledíte, mohou se z nich stát vašispolupracovníci.

Another strength of the Unix tradition,one that Linux pushes to a happyextreme, is that a lot of users arehackers too. Because source code isavailable, they can be effectivehackers. This can be tremendouslyuseful for shortening debugging time.Given a bit of encouragement, yourusers will diagnose problems, suggestfixes, and help improve the code farmore quickly than you could unaided.

Další silnou stránkou tradice Unixu,kterou Linux dotlačil až do extrému,je to, že mnoho uživatelů je zároveňprogramátory. Protože je zdrojový kóddostupný, mohou se i oni státefektivními hackery. To může býtneocenitelné pro zkrácení vývojovéhocyklu. Pokud se jim dostane alespoňmalého povzbuzení, vaši uživatelénaleznou problémy, navrhnou řešení apomohou vylepšit kód mnohemrychleji, než vy sám bez jejichpomoci.

6. Treating your users asco-developers is your least-hassleroute to rapid code improvementand effective debugging.

7. Pokud jednáte s uživateli jakose spolupracovníky, je to tanejsnažší cesta k rychlémuvylepšení kódu a efektivnímuodstraňování chyb.

The power of this effect is easy tounderestimate. In fact, pretty well allof us in the open-source worlddrastically underestimated how well itwould scale up with number of usersand against system complexity, untilLinus Torvalds showed us differently.

Sílu tohoto efektu je velmi snadnépodcenit. Ve skutečnosti asi všichni znás pohybujících se v otevřenémprostředí drasticky podceňovali, jaksnadno je udržován systém v chodupři zvyšujícím se množství uživatelů apři jeho narůstající složitosti, dokudnám Linus Torvalds neukázal, jak nato.


1 z 3 22.2.2010 14:59

In fact, I think Linus's cleverest andmost consequential hack was not theconstruction of the Linux kernel itself,but rather his invention of the Linuxdevelopment model. When I expressedthis opinion in his presence once, hesmiled and quietly repeated somethinghe has often said: ``I'm basically a verylazy person who likes to get credit forthings other people actually do.'' Lazylike a fox. Or, as Robert Heinlein mighthave said, too lazy to fail.

Ve skutečnosti se domnívám, žeLinusův nejchytřejší a nejdůležitějšípřínos nebylo vytvoření jádra Linuxu,ale jeho objev modelu vývoje. Kdyžjsem tuto větu pronesl jednou v jehopřítomnosti, usmál se a tiše zopakovalněco, co často říká: "Já jsem veskutečnosti velmi líný a rád jsemchválen za věci, které udělá někdojiný". Líný jako liška. Nebo, jak bymohl říct Robert Heinlein, příliš línýna to, abych mohl selhat.

In retrospect, one precedent for themethods and success of Linux can beseen in the development of the GNUEmacs Lisp library and Lisp codearchives. In contrast to the cathedral-building style of the Emacs C core andmost other FSF tools, the evolution ofthe Lisp code pool was fluid and veryuser-driven. Ideas and prototype modeswere often rewritten three or fourtimes before reaching a stable finalform. And loosely-coupledcollaborations enabled by the Internet,a la Linux, were frequent.

Když se ohlédneme do minulosti,nalezneme zde precedens využivajícímetody Linuxu a to vývoj Lispknihoven GNU Emacs a archívů Lispkódů. Na rozdíl od katedrálního stylupráce na Emacs-C a většině ostatníchFSF programů, vývoj Lisp zdrojů bylvelmi flexibilní a veden uživateli.Nápady a prototypy programů bylyčasto několikrát přepsány neždosáhly stabilní konečné podoby. Avolné spojení spolupracovníků přesInternet a la Linux bylo časté.

Indeed, my own most successful singlehack previous to fetchmail wasprobably Emacs VC mode, a Linux-likecollaboration by email with three otherpeople, only one of whom (RichardStallman, the author of Emacs andfounder of the FSF) I have met to thisday. It was a front-end for SCCS, RCSand later CVS from within Emacs thatoffered ``one-touch'' version controloperations. It evolved from a tiny,crude sccs.el mode somebody else hadwritten. And the development of VCsucceeded because, unlike Emacsitself, Emacs Lisp code could gothrough release/test/improvegenerations very quickly.

Ovšem, i můj vlastní nejúspěšnějšípříspěvek před fetchmailem byl svelkou pravděpodobností Emacs VCmód, spolupráce se třemi dalšímilidmi ve stylu Linuxu, z nichž dodnesosobně znám pouze RichardaStallmana FSF, autora Emacsu azakladatele FSF. Jednalo se o frontend pro SCCS, RCS a později CVS, prokteré Emacs nabízel jednoduchoukontrolu verzí. Vyvinul se z malého,jednoduchého sccs.el módu, kterýnapsal někdo jiný. A vývoj VC bylúspěšný, protože, na rozdíl odsamotného Emacsu, Lisp kód mohlvelmi rychle procházet cyklypublikuj/otestuj/vylepši .


2 z 3 22.2.2010 14:59



3 z 3 22.2.2010 14:59

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T4. Release Early,Release Often

4. Publikuj brzy,publikuj často

Early and frequent releases are acritical part of the Linux developmentmodel. Most developers (including me)used to believe this was bad policy forlarger than trivial projects, becauseearly versions are almost by definitionbuggy versions and you don't want towear out the patience of your users.

Časné a časté publikování vykonanépráce patří ke kritickým částemvývojového modelu Linuxu. Většinavývojářů, včetně mne, dříve věřila, žeje to špatný postup pro všechny většíprojekty, protože prvé verze majítéměř určitě řadu chyb a vy nechcetepokoušet trpělivost svých uživatelů.

This belief reinforced the generalcommitment to a cathedral-buildingstyle of development. If the overridingobjective was for users to see as fewbugs as possible, why then you'd onlyrelease one every six months (or lessoften), and work like a dog ondebugging between releases. TheEmacs C core was developed this way.The Lisp library, in effect, was not --because there were active Lisparchives outside the FSF's control,where you could go to find new anddevelopment code versionsindependently of Emacs's releasecycle.

Tato víra posilovala obecnou důvěru vestyl stavění katedrál. Pokud bylozákladní podmínkou, aby uživateléviděli co nejméně chyb, pak je nejlepšípublikovat maximálně jednou za půlroku a dřít do úmoru na odstraňováníchyb v mezidobí. Emacs C byl vyvíjentímto způsobem. Lisp knihovny alevznikaly rozdílně. Jednalo se o aktivníarchivy mimo kontrolu FSF, ve kterýchjste mohli nalézt nové aexperimentální verze i v obdobích, kdysamotný Emacs nebyl publikován.

The most important of these, the OhioState elisp archive, anticipated thespirit and many of the features oftoday's big Linux archives. But few ofus really thought very hard about whatwe were doing, or about what the veryexistence of that archive suggestedabout problems in FSF's cathedral-building development model. I madeone serious attempt around 1992 toget a lot of the Ohio code formallymerged into the official Emacs Lisplibrary. I ran into political trouble and

Nejdůležitější z těchto archívů, Ohiostate elisp archív, vykazoval ducha amnoho rysů dnešních velkýchLinuxových archívů. Ale jen málo z nástehdy opravdu důsledně přemýšlelo otom, co děláme, nebo o tom, cosamotná jejich existence naznačovala oproblémech modelu stavitelů katedrál,který FSF využíval. V roce 1992 jsemse vážně pokoušel zahrnout velkoučást Ohio archívu do oficiální EmacsLisp knihovny, ale narazil jsem na řadupolitických problémů a tento pokus


1 z 7 22.2.2010 15:00

was largely unsuccessful. byl z velké části neúspěšný.

But by a year later, as Linux becamewidely visible, it was clear thatsomething different and muchhealthier was going on there. Linus'sopen development policy was the veryopposite of cathedral-building. Thesunsite and tsx-11 archives wereburgeoning, multiple distributionswere being floated. And all of this wasdriven by an unheard-of frequency ofcore system releases.

Ale během roku, jak se Linux stávalznámým, bylo jasné, že probíhá něcojiného a mnohem zdravějšího.Linusova otevřená vývojová politikabyla přesným protikladem výstavbykatedrál. Sunsite a tsx-11 archívypřekypovaly, byla rozšiřována řadadistribucí. A to vše doprovázelapředtím nevídaná frekvence publikacínových verzí jádra systému.

Linus was treating his users asco-developers in the most effectivepossible way:

Linus jednal se svými uživateli jako sespolupracovníky tím nejefektivnějšímzpůsobem

7. Release early. Release often.And listen to your customers.

7. Publikuj brzy. Publikuj často. Anaslouchej svým zákazníkům.

Linus's innovation wasn't so much indoing this (something like it had beenUnix-world tradition for a long time),but in scaling it up to a level ofintensity that matched the complexityof what he was developing. In thoseearly times (around 1991) it wasn'tunknown for him to release a newkernel more than once a day! Becausehe cultivated his base of co-developersand leveraged the Internet forcollaboration harder than anyone else,this worked.

Linusova inovace nespočívala ani tak vtom, že něco podobného dělal (to užmělo dlouhou tradici ve světě Unixu),ale v tom, že celý proces převedl dorozměrů a složitosti samotnéhoLinuxu. V této ranné epoše (okoloroku 1991), byly běžné publikacenového jádra i několikrát denně.Protože si kultivoval svoji základnuspolupracovníků a využíval Internetpro spolupráci více než kdokoliv jiný,tak vše pracovalo.

But how did it work? And was itsomething I could duplicate, or did itrely on some unique genius of LinusTorvalds?

Ale jak to všechno mohlo pracovat? Abylo to něco, co jsem já sám mohlkopírovat nebo vše spočívalo nanenapodobitelné genialitě LinuseTorvalda?

I didn't think so. Granted, Linus is adamn fine hacker (how many of uscould engineer an entire production-quality operating system kernel?). ButLinux didn't represent any awesomeconceptual leap forward. Linus is not(or at least, not yet) an innovative

Já si to nemyslel. Je pravda, že Linus jezatraceně dobrý programátor, vždyťkolik z nás by dokázalo vytvářet celéjádro operačního systému v produkčníkvalitě? Ale Linux nepředstavovalžádný ohromný koncepční skok vpřed.Linus není, tedy alespoň zatím,


2 z 7 22.2.2010 15:00

genius of design in the way that, say,Richard Stallman or James Gosling (ofNeWS and Java) are. Rather, Linusseems to me to be a genius ofengineering, with a sixth sense foravoiding bugs and developmentdead-ends and a true knack forfinding the minimum-effort path frompoint A to point B. Indeed, the wholedesign of Linux breathes this qualityand mirrors Linus's essentiallyconservative and simplifying designapproach.

inovační genius designu, takový, jakoje třeba Richard Stallman nebo JamesGosling (NeWS, Java). Linus má spíšeinženýrský génius, má šestý smysl proobcházení chyb a slepých uliček, máopravdový cit pro nalezení nejméněnamáhavé cesty z bodu A do bodu B.Ovšem, celkový design Linuxu v soběnese tuto kvalitu a odráží Linusův vesvé podstatě konzervativní azjednodušující přístup.

So, if rapid releases and leveraging theInternet medium to the hilt were notaccidents but integral parts of Linus'sengineering-genius insight into theminimum-effort path, what was hemaximizing? What was he crankingout of the machinery?

Takže, pokud rychlé publikování avyužívání Internetu nebylo náhodné,ale představovalo integrální součástLinusova inženýrského genia pronalezení nejsnažší cesty, co se snažilmaximalizovat? Co dostával z celéhosoustrojí?

Put that way, the question answersitself. Linus was keeping hishacker/users constantly stimulatedand rewarded -- stimulated by theprospect of having an ego-satisfyingpiece of the action, rewarded by thesight of constant (even daily)improvement in their work.

Pokud je otázka položena takto, samanabízí odpověď. Linus udržoval svéuživatele/spoluautory neustálestimulované a odměňované.Stimulované tím, že mají neustále předsebou nějakou uspokující práci,odměňované tím, že vidí neustálá(dokonce denní) vylepšení své práce.

Linus was directly aiming to maximizethe number of person-hours thrown atdebugging and development, even atthe possible cost of instability in thecode and user-base burnout if anyserious bug proved intractable. Linuswas behaving as though he believedsomething like this:

Linus se pokoušel maximalizovat počethodin, které jsou věnovány naodstraňování chyb a na rozvoj, ačkolivhrozilo možné riziko nestability kódu avyhoření uživatelské báze, pokud by senějaká vážná chyba ukázalaneodstranitelnou.Linus se choval tak,jako by věřil v něco jako:

8. Given a large enough beta-testerand co-developer base, almostevery problem will be characterizedquickly and the fix obvious tosomeone.

8. Pokud máte dostatečně velkouzákladnu spolupracovníků atestovatelů, téměř každý problémbude rychle charakterizován a jehořešení bude pro někohojednoduché


3 z 7 22.2.2010 15:00

Or, less formally, ``Given enougheyeballs, all bugs are shallow.'' I dubthis: ``Linus's Law''.

Nebo, méně formálně "Pokud mátedostatek očí, všechny chyby jsouprůhledné". Já to nazývám Linusovýmzákonem.

My original formulation was that everyproblem ``will be transparent tosomebody''. Linus demurred that theperson who understands and fixes theproblem is not necessarily or evenusually the person who firstcharacterizes it. ``Somebody finds theproblem,'' he says, ``and somebodyelse understands it. And I'll go onrecord as saying that finding it is thebigger challenge.'' But the point isthat both things tend to happenquickly.

Má původní formulace tohoto jevuzněla: každý problém bude pro někohořešitelný. Linus ovšem upozornil, žečlověk, který problému porozuměl avyřešil ho, nemusí být a většinounebývá ten, kdo jej prvnícharakterizoval. Linus říká: "Někdonalezne problém a někdo jiný murozumí. A já dokonce tvrdím, že naléztproblém je náročnější". Důležité ale je,že nalezení i vyřešení většinouproběhne rychle.

Here, I think, is the core differenceunderlying the cathedral-builder andbazaar styles. In the cathedral-builderview of programming, bugs anddevelopment problems are tricky,insidious, deep phenomena. It takesmonths of scrutiny by a dedicated fewto develop confidence that you'vewinkled them all out. Thus the longrelease intervals, and the inevitabledisappointment when long-awaitedreleases are not perfect.

V tom je, myslím, základní rozdíl mezistylem stavitelů katedrál a stylemtržiště. Z pohledu stavitelů katedrál,programové chyby a vývojovéproblémy jsou náročné akomplikované jevy. Trvá měsícepečlivého zkoumání několikazasvěcených, než získáte jistotu, žejste vše vyhladili. Proto dlouhéintervaly mezi publikacemi anevyhnutelná zklamání, že dlouhoočekávaný program není zdalekadokonalý.

In the bazaar view, on the other hand,you assume that bugs are generallyshallow phenomena -- or, at least, thatthey turn shallow pretty quick whenexposed to a thousand eagerco-developers pounding on everysingle new release. Accordingly yourelease often in order to get morecorrections, and as a beneficial sideeffect you have less to lose if anoccasional botch gets out the door.

Z pohledu tržiště naopakpředpokládáte, že chyby jsou obvyklesnadno řešitelné, nebo alepoň, že setakovými rychle stanou, když se na nězaměří tisíce dychtivýchspolupracovníků, nedočkavěočekávajících další verzi. Protopublikujete často, abyste získali víceoprav a jako prospěšný vedlejší efektztrácíte méně, pokud občas dojde knějakému problému.


4 z 7 22.2.2010 15:00

And that's it. That's enough. If``Linus's Law'' is false, then anysystem as complex as the Linuxkernel, being hacked over by as manyhands as the Linux kernel, should atsome point have collapsed under theweight of unforseen bad interactionsand undiscovered ``deep'' bugs. If it'strue, on the other hand, it is sufficientto explain Linux's relative lack ofbugginess.

A to je vše. To opravdu stačí. Pokud je"Linusův zákon" nepravdivý, potomjakýkoliv systém tak komplexní, jakoje jádro Linuxu, na kterém sespolupodílelo tolik autorů, by se muselv nějaký okamžik zhroutit pod tíhounepředvídaných špatných interakcí anenalezených, hluboko ukrytých chyb.Pokud je ale pravdivý, pak postačujena vysvětlení, proč Linux obsahuje takmálo programových chyb.

And maybe it shouldn't have been sucha surprise, at that. Sociologists yearsago discovered that the averagedopinion of a mass of equally expert (orequally ignorant) observers is quite abit more reliable a predictor than thatof a single randomly-chosen one of theobservers. They called this the``Delphi effect''. It appears that whatLinus has shown is that this applieseven to debugging an operatingsystem -- that the Delphi effect cantame development complexity even atthe complexity level of an OS kernel.

A možná by to ani nemělo být takovépřekvapení. Sociologové již před letyobjevili, že průměrný názor velkéhomnožství stejně dobrých (nebošpatných) pozorovatelů je podstatněspolehlivější než názor jakékohokolivnáhodně zvoleného pozorovatele. To senazývá Delphi efektem. Zdá se, žeLinus prokázal, že tento jev se týká itvorby operačního systému, že Delphiefekt dokáže zkrotit i tak komplexnízáležitost, jako je konstrukce jádraOS..

I am indebted to Jeff Dutky<[email protected]> for pointingout that Linus's Law can be rephrasedas ``Debugging is parallelizable''. Jeffobserves that although debuggingrequires debuggers to communicatewith some coordinating developer, itdoesn't require significantcoordination between debuggers. Thusit doesn't fall prey to the samequadratic complexity andmanagement costs that make addingdevelopers problematic.

Jsem vděčen Jeffovi Dutky<[email protected]>, kterýupozornil na to, že Linusův zákonmůže být přeložen jako "debugování jeparalelizovatelné". Jeff si všiml, žeačkoliv odstraňování chyb vyžaduje,aby jednotliví spolupracovnícíkomunikovali s nějakýmkoordinátorem, nevyžaduje významnouspolupráci mezi jednotlivýmispolupracovníky. Proto nepadá za oběťkvadratickému zvyšování komplexity anárokům na administraci, která vjiných případech znesnadňuje zapojenívíce vývojářů.

In practice, the theoretical loss ofefficiency due to duplication of workby debuggers almost never seems to

Ve skutečnosti se teoretická ztrátaúčinnosti způsobená duplikací prácenezdá být problémem ve světě Linuxu.


5 z 7 22.2.2010 15:00

be an issue in the Linux world. Oneeffect of a ``release early and oftenpolicy'' is to minimize such duplicationby propagating fed-back fixes quickly.

Jeden z výsledků časného a častéhopublikování je fakt, že případnéduplikace jsou brzy odhaleny.

Brooks even made an off-handobservation related to Jeff's: ``Thetotal cost of maintaining a widely usedprogram is typically 40 percent ormore of the cost of developing it.Surprisingly this cost is stronglyaffected by the number of users. Moreusers find more bugs.'' (myemphasis).

Brooks dokonce učinil následujícípozorování: "Celková cena údržbyběžně používaného programu je okolo40 % nebo i více z ceny jeho vývoje. Jepřekvapující, že tato cena je značněovlivněna počtem uživatelů. Víceuživatelů nalezne více chyb.

More users find more bugs becauseadding more users adds moredifferent ways of stressing theprogram. This effect is amplified whenthe users are co-developers. Each oneapproaches the task of bugcharacterization with a slightlydifferent perceptual set and analyticaltoolkit, a different angle on theproblem. The ``Delphi effect'' seems towork precisely because of thisvariation. In the specific context ofdebugging, the variation also tends toreduce duplication of effort.

Více uživatelů nalezne více chyb,neboť s počtem uživatelů přibývázpůsobů, kterým jsou programytestovány. Tento efekt je zesílen,pokud se uživatelé zároveň podílejí navývoji programu. Každý z nich vnímáproblémy při detekci chyb z jinéhoúhlu pohledu. Delphi efekt funguje,jak se zdá, právě díky tétorozmanitosti. Ve specifickém kontextuodhalování chyb tento styl rovněžsnižuje množství duplikátních činností.

So adding more beta-testers may notreduce the complexity of the current``deepest'' bug from the developer'spoint of view, but it increases theprobability that someone's toolkit willbe matched to the problem in such away that the bug is shallow to thatperson.

Takže s přibývajícím počtemtestovatelů se sice nemusí zmenšitkomplexita té nejobtížnější chyby zpohledu vývojáře, ale stoupá šance, ženěkomu jinému se podaří chybuodhalit.

Linus coppers his bets, too. In casethere are serious bugs, Linux kernelversion are numbered in such a waythat potential users can make a choiceeither to run the last versiondesignated ``stable'' or to ride thecutting edge and risk bugs in order toget new features. This tactic is not yet

Linus je také obezřetný. V případě, žese vyskytnou vážné problémy,Linuxové jádro je číslováno takovýmzpůsobem, že potenciální uživatelmůže buďto používat poslední verzi,která je označena jako stabilní, a nebosledovat vývoj a mít nové možnosti, aleto vše za cenu rizika chyb v programu.


6 z 7 22.2.2010 15:00

formally imitated by most Linuxhackers, but perhaps it should be; thefact that either choice is availablemakes both more attractive.

Tuto taktiku ještě neuplatňuje většinaLinuxových hackerů, ale asi by měla.Dostupnost obou alternativ přispívá katraktivitě programu..



7 z 7 22.2.2010 15:00

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T5. When Is A Rose Not ARose?

5. Když růže není růží

Having studied Linus's behavior andformed a theory about why it wassuccessful, I made a conscious decision totest this theory on my new (admittedlymuch less complex and ambitious)project.

Poté, co jsem studoval Linusovochování a zformuloval teorii, pročbylo úspěšné, vědomě jsem serozhodl tuto teorii otestovat namém vlastním (ačkoliv zdaleka netak komplexním) projektu.

But the first thing I did was reorganizeand simplify popclient a lot. Carl Harris'simplementation was very sound, butexhibited a kind of unnecessarycomplexity common to many Cprogrammers. He treated the code ascentral and the data structures as supportfor the code. As a result, the code wasbeautiful but the data structure designad-hoc and rather ugly (at least by thehigh standards of this old LISP hacker).

Ale první věc, kterou jsem učinil,byla reorganizace a zjednodušenípopclienta. Carlova implementacebyla velmi rozumná, ale vykazovalanepotřebnou složitost, která jeběžná u mnoha C programátorů.Považoval kód za jádro a strukturudat jako podporu pro kód.Výsledkem bylo, že kód bylnádherný, ale struktura datnáhodná a dosti ošklivá (alespoňpodle vysokého standardu tohotozkušeného LISP hackera).

I had another purpose for rewritingbesides improving the code and the datastructure design, however. That was toevolve it into something I understoodcompletely. It's no fun to be responsiblefor fixing bugs in a program you don'tunderstand.

K přepisování jsem měl i dalšídůvod než vylepšení kódu adatových struktur. Potřeboval jsemprogram zcela pochopit. Není tožádná legrace, opravovat chyby vprogramu, kterému nerozumíte.

For the first month or so, then, I wassimply following out the implications ofCarl's basic design. The first seriouschange I made was to add IMAP support. Idid this by reorganizing the protocolmachines into a generic driver and threemethod tables (for POP2, POP3, andIMAP). This and the previous changesillustrate a general principle that's goodfor programmers to keep in mind,especially in languages like C that don't

Během prvého měsíce jsem sedržel základního Carlova plánu.První vážnou změnou bylo přidáníprotokolu IMAP. To jsem učinil tak,že jsem program rozčlenil naobecnou část a specifické metody.Toto a předchozí změny ilustrujíobecný princip, kterého by se měliprogramátoři přidržovat, zejménapak v jazycích, jako je C.


1 z 3 22.2.2010 15:01

naturally do dynamic typing:

9. Smart data structures and dumbcode works a lot better than the otherway around.

9. Promyšlené datové strukturya průměrný kód fungujímnohem lépe než při obrácenékonfiguraci

Brooks, Chapter 9: ``Show me your [code]and conceal your [data structures], and Ishall continue to be mystified. Show meyour [data structures], and I won't usuallyneed your [code]; it'll be obvious.''

Brooks, kapitola 9: Ukaž mi svůj[kód] a skryj [datové struktury] anebudu rozumět. Ukaž mi [datovéstruktury] a obyčejně nebudupotřebovat tvůj [kód], většinou mibude jasný.

Actually, he said ``flowcharts'' and``tables''. But allowing for thirty years ofterminological/cultural shift, it's almostthe same point.

Ve skutečnosti řekl diagramy atabulky. Ale po 30 letechkulturních a terminologickýchzměn to znamená téměř to samé.

At this point (early September 1996,about six weeks from zero) I startedthinking that a name change might be inorder -- after all, it wasn't just a POPclient any more. But I hesitated, becausethere was as yet nothing genuinely new inthe design. My version of popclient hadyet to develop an identity of its own.

V tu dobui (začátek září 1996, asi6 týdnů od času nula) jsem začalpřemýšlet o změně jména. Koneckonců, už to nebyl jenom POPklient. Ale váhal jsem, protožedosud v programu nebylo nicopravdu původního. Moje verzepopclienta si teprve muselavytvořit vlastní identitu.

That changed, radically, when fetchmaillearned how to forward fetched mail tothe SMTP port. I'll get to that in amoment. But first: I said above that I'ddecided to use this project to test mytheory about what Linus Torvalds haddone right. How (you may well ask) did Ido that? In these ways:

Vše se změnilo velmi radikálně,když se fetchmail naučilpřesměrovávat poštu na SMTPport. K tomu se dostanu zaokamžik. Jak jsem se již zmínil,rozhodl jsem se použít svůj projektjako test toho, co Linus Torvaldsudělal dobře. Jak jsem tedytestoval? Takto:

I released early and often (almost neverless often than every ten days; duringperiodsof intense development, once aday).

Publikoval jsem časně a často,téměř vždy alespoň jednou za 10dnů, při intenzivní práci jednoudenně

I grew my beta list by adding to iteveryone who contacted me aboutfetchmail.

Zvětšoval jsem seznam testerů okaždého, kdo mne kontaktovalohledně fetchmailu


2 z 3 22.2.2010 15:01

I sent chatty announcements to the betalist whenever I released, encouragingpeople to participate.

. Všem jsem rozesílal vzkazy,kdykoliv jsem něco publikoval, apovzbuzoval jsem je k spoluúčasti

And I listened to my beta testers, pollingthem about design decisions and strokingthem whenever they sent in patches andfeedback.

A naslouchal jsem jim, dával si odnich schvalovat rozhodnutí achválil je, když mi poslali nějakouopravu nebo komentář.

The payoff from these simple measureswas immediate. From the beginning ofthe project, I got bug reports of a qualitymost developers would kill for, often withgood fixes attached. I got thoughtfulcriticism, I got fan mail, I got intelligentfeature suggestions. Which leads to:

Tato jednoduchá opatření sevyplatila téměř okamžitě. Odzačátku projektu jsem dostávalhlášení o chybách ve kvalitě, prokterou by většina vývojářů bylaschopna zabít, a často bylopřiloženo i dobré řešení. Dostávaljsem poštu, kterou byla zábavačíst, promyšlenou kritiku arozumné návrhy na nové možnosti.Takže:

10. If you treat your beta-testers as ifthey're your most valuable resource, theywill respond by becoming your mostvaluable resource.

10. Pokud zacházíte s Vašimitestovateli, jako by byli vašímnejcennějším kapitálem, oni sevaším nejcennějším kapitálemskutečně stanou.

One interesting measure of fetchmail'ssuccess is the sheer size of the projectbeta list, fetchmail-friends. At time ofwriting it has 249 members and is addingtwo or three a week.

Jedno zajímavé měřítko úspěchufetchmailu je velikost seznamutestovatelů, přátel fetchmailu. Vdobě, kdy tento text píši, má 249členů a dva až tři členové přibývajíkaždý týden.

Actually, as I revise in late May 1997 thelist is beginning to lose members from itshigh of close to 300 for an interestingreason. Several people have asked me tounsubscribe them because fetchmail isworking so well for them that they nolonger need to see the list traffic! Perhapsthis is part of the normal life-cycle of amature bazaar-style project.

Ve skutečnosti, při revizi na koncikvětna 1997 tento seznam jižztrácí ze svého maximálního počtutéměř 300 členů ze zajímavéhodůvodu. Několik lidí mne požádalo,abych je odhlásil ze seznamu,protože fetchmail už pracuje takdobře, že nepotřebují sledovat, coje nového. Možná to patří knormálnímu životnímu cykluvyspělého projektu ve stylu tržiště.



3 z 3 22.2.2010 15:01

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T6. Popclient becomesFetchmail

6. Popclient se stáváfetchmailem

The real turning point in the projectwas when Harry Hochheiser sent mehis scratch code for forwarding mail tothe client machine's SMTP port. Irealized almost immediately that areliable implementation of this featurewould make all the other deliverymodes next to obsolete.

Skutečně klíčovým okamžikem vprojektu byl okamžik, když mi HarryHochheiser poslal svůj návrh kódu propřesměrování pošty na SMPT počítačeklienta. Já si téměř okamžitěuvědomil, že spolehlivá implementacetéto funkce učiní ostatní způsobydoručení zastaralé.

For many weeks I had been tweakingfetchmail rather incrementally whilefeeling like the interface design wasserviceable but grubby -- inelegant andwith too many exiguous optionshanging out all over. The options todump fetched mail to a mailbox file orstandard output particularly botheredme, but I couldn't figure out why.

Mnoho týdnů jsem měnil fetchmailspíše po částech a cítil jsem, žeuživatelské rozhraní slouží svémuúčelu, ale je nepříjemné aneelegantní. Zejména záplavanastavení pro export stažené pošty dosouboru nebo na standardní výstupmě obzvláště tížila, ale já nevědělproč.

What I saw when I thought about SMTPforwarding was that popclient hadbeen trying to do too many things. Ithad been designed to be both a mailtransport agent (MTA) and a localdelivery agent (MDA). With SMTPforwarding, it could get out of theMDA business and be a pure MTA,handing off mail to other programs forlocal delivery just as sendmail does.

Když jsem přemýšlel o SMPTpřesměrování, tak se ukazovalo, žepopclient se pokoušel dělat přílišmnoho věcí. Byl navržen zároveň jakomail transport agent (MTA) a localdelivery agent (MDA). S SMTPpřesměrováním se z něj mohl státčistý MTA a předávat poštu jinýmprogramům, tak jak to dělá sendmail.

Why mess with all the complexity ofconfiguring a mail delivery agent orsetting up lock-and-append on amailbox when port 25 is almostguaranteed to be there on anyplatform with TCP/IP support in thefirst place? Especially when this meansretrieved mail is guaranteed to looklike normal sender-initiated SMTPmail, which is really what we want

Proč si přidělávat práci s celousložitostí konfigurace MDA, když port25 je téměř určitě přítomen na všechplatformách podporujících TCP/IP?


1 z 5 22.2.2010 15:01

anyway.

There are several lessons here. First,this SMTP-forwarding idea was thebiggest single payoff I got fromconsciously trying to emulate Linus'smethods. A user gave me this terrificidea -- all I had to do was understandthe implications.

Zde se můžeme naučit několik lekcí.Zaprvé, nápad se SMPT, to bylanejvětší odměna za to, že jsem sepokoušel napodobit Linusovi metody.Tento skvělý nápad mi poskytl jeden zuživatelů, já pouze musel pochopitjeho důsledky.

11. The next best thing to having goodideas is recognizing good ideas fromyour users. Sometimes the latter isbetter.

11. Skoro stejně důležité, jako mítdobré nápady, je schopnostrozeznat dobré nápady vašichuživatelů. Občas je to druhédokonce lepší.

Interestingly enough, you will quicklyfind that if you are completely andself-deprecatingly truthful about howmuch you owe other people, the worldat large will treat you like you didevery bit of the invention yourself andare just being becomingly modestabout your innate genius. We can allsee how well this worked for Linus!

Je zajímavé, že pokud jste opravdu ksobě upřímní, rychle zjistíte, jakmnoho dlužíte ostatním lidem, ačkolivokolní svět vás bude považovat zapůvodce všeho. Vy sami paknásledkem toho začnete býtskromnější v pohledu na vlastníschopnosti a Linus je toho dokonalýmpříkladem.

(When I gave this paper at the Perlconference in August 1997, Larry Wallwas in the front row. As I got to thelast line above he called out, religious-revival style, ``Tell it, tell it, brother!''.The whole audience laughed, becausethey knew it had worked for theinventor of Perl too.)

(Když jsem tento článek četl nakonferenci o Perlu v roce 1997, LarryWall seděl v řadě přede mnou. Kdyžjsem se dostal k řádkům výšeuvedeným, zavolal hlasem starýchkazatelů "Jen to řekni, řekni bratře!".Celé publikum se smálo, protoževědělo, že vše fungovalo stejně i vpřípadě vynálezce Perlu.

After a very few weeks of running theproject in the same spirit, I began toget similar praise not just from myusers but from other people to whomthe word leaked out. I stashed awaysome of that email; I'll look at it againsometime if I ever start wonderingwhether my life has been worthwhile:-).

Jen několik málo týdnů po té, co jsemprojekt rozběhl, jsem začal získávatpodobnou chválu nejen od uživatelů,ale i od dalších lidí, ke kterým sezpráva donesla. Schoval jsem siněkteré e-maily. Podívám se ně, jestliněkdy budu pochybovat, že můj životmá smysl.

But there are two more fundamental,non-political lessons here that are

Jsou zde ovšem ještě dvě základnější,nepolitické lekce, které jsou společné


2 z 5 22.2.2010 15:01

general to all kinds of design. veškerému designu.

12. Often, the most striking andinnovative solutions come fromrealizing that your concept of theproblem was wrong.

12. Často to nejzajímavější anejoriginálnější řešení se zrodí ztoho, že si uvědomíte, že vašechápání problému bylo mylné.

I had been trying to solve the wrongproblem by continuing to developpopclient as a combined MTA/MDAwith all kinds of funky local deliverymodes. Fetchmail's design needed tobe rethought from the ground up as apure MTA, a part of the normalSMTP-speaking Internet mail path.

Já se pokoušel vyřešit nesprávnýproblém tím, že jsem chtěl popclientajako kombinovaný MTA/MDA.Fetchmail musel být znovukoncipován od základu jako čistýMTA, součást normálního SMTP.

When you hit a wall in development --when you find yourself hard put tothink past the next patch -- it's oftentime to ask not whether you've got theright answer, but whether you'reasking the right question. Perhaps theproblem needs to be reframed.

Když při vývoji narazíte do zdi, kdyžzjistíte, že vás zajímá jen příští oprava,je často okamžik se zeptat ne na to,zda máte správnou odpověď, ale jestlikladete správnou otázku. Možná jetřeba problém reformulovat.

Well, I had reframed my problem.Clearly, the right thing to do was (1)hack SMTP forwarding support intothe generic driver, (2) make it thedefault mode, and (3) eventually throwout all the other delivery modes,especially the deliver-to-file anddeliver-to-standard-output options.

Já jsem tedy problém reformuloval. Jejasné, že správné bylo 1. přenéstpodporu SMTP do generickéhodriveru, 2. učinit z něj výchozí mód a3. nakonec přestat podporovat ostatnímožnosti přenosu.

I hesitated over step 3 for some time,fearing to upset long-time popclientusers dependent on the alternatedelivery mechanisms. In theory, theycould immediately switch to .forwardfiles or their non-sendmail equivalentsto get the same effects. In practice thetransition might have been messy.

Nad krokem 3 jsem nějaký čas váhal,obával jsem se, že si rozzlobím svéstaré uživatele, kteří závisejí na těchtomechanismech. Teoreticky jim stačilopřejít na .forward soubory nebo jejichne-sendmail alternativy, aby získali to,co potřebují. Ve skutečnosti všakmohl být tento přechod komplikovaný.

But when I did it, the benefits provedhuge. The cruftiest parts of the drivercode vanished. Configuration gotradically simpler -- no more grovellingaround for the system MDA and user'smailbox, no more worries about

Ale když jsem to učinil, zisk bylohromný. Nejpracnější část kóduzmizela. Konfigurace byla mnohemjednodušší, už žádné starosti o MDAuživatele a jeho poštovní schránku.Žádné starosti s tím, jestli operační


3 z 5 22.2.2010 15:01

whether the underlying OS supportsfile locking.

systém umožňuje uzamykání souborů.

Also, the only way to lose mailvanished. If you specified delivery to afile and the disk got full, your mail gotlost. This can't happen with SMTPforwarding because your SMTP listenerwon't return OK unless the messagecan be delivered or at least spooled forlater delivery.

Rovněž zmizelo jediné riziko ztrátypošty. Pokud jste určili za příjemcepošty soubor a disk se zaplnil, poštujste ztratili. Se SMTP se to státnemůže.

Also, performance improved (thoughnot so you'd notice it in a single run).Another not insignificant benefit ofthis change was that the manual pagegot a lot simpler.

Zlepšila se i rychlost a významné byloi zjednodušení manuálu.

Later, I had to bring delivery via auser-specified local MDA back in orderto allow handling of some obscuresituations involving dynamic SLIP. But Ifound a much simpler way to do it.

Později jsem musel doplnit některénestandardní podmínky, ale to už bylomnohem jednodušší.

The moral? Don't hesitate to throwaway superannuated features whenyou can do it without loss ofeffectiveness. Antoine de Saint-Exupery(who was an aviator and aircraftdesigner when he wasn't being theauthor of classic children's books) said:

Morální poučení? Neváhejte serozloučit se vším, co vám nezvyšujeefektivitu. Antoine de Saint-Exupery(což byl letec a letecký konstruktér,když nepsal klasické dětské knihy)řekl:

13. ``Perfection (in design) is achievednot when there is nothing more to add,but rather when there is nothing moreto take away.''

13. Konstrukční dokonalosti nenídosaženo tehdy, když už není copřidat, ale tehdy, když užnemůžete nic odebrat.

When your code is getting both betterand simpler, that is when you know it'sright. And in the process, thefetchmail design acquired an identityof its own, different from the ancestralpopclient.

Když se Váš kód zároveň zlepšuje astává jednodušším, potom víte, že jstena správné cestě.

It was time for the name change. Thenew design looked much more like adual of sendmail than the old popclienthad; both are MTAs, but wheresendmail pushes then delivers, the new

Nastal čas pro změnu jména. Novýprogram vypadal mnohem více jakodvojník sendmailu než starýpopclient, a tak jsem jej po dvouměsících přejmenoval na fetchmail.


4 z 5 22.2.2010 15:01

popclient pulls then delivers. So, twomonths off the blocks, I renamed itfetchmail.



5 z 5 22.2.2010 15:01

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T7. Fetchmail Grows Up 7. Fetchmail dospívá

There I was with a neat and innovativedesign, code that I knew worked wellbecause I used it every day, and aburgeoning beta list. It graduallydawned on me that I was no longerengaged in a trivial personal hackthat might happen to be useful to fewother people. I had my hands on aprogram every hacker with a Unixbox and a SLIP/PPP mail connectionreally needs.

V ruce jsem měl uspořádanou aoriginální konstrukci, kód, o kterémjsem věděl, že funguje, neboť jsem hopoužíval každý den a rostoucí seznamtestovatelů. Postupně mi docházelo, žeuž se nezabývám programovánímněčeho jednoduchého, co může býtužitečné pro několik dalších lidí. Měljsem v rukou program, který potřebujekaždý hacker s Unixem a SLIP/PPPpoštovním připojením.

With the SMTP forwarding feature, itpulled far enough in front of thecompetition to potentially become a``category killer'', one of those classicprograms that fills its niche socompetently that the alternatives arenot just discarded but almostforgotten.

Se SMTP přesměrováním se fetchmaildostal daleko do čela konkurence a stalse potenciálním vládcem kategorie,takovým, který vyplní svůj prostor takdokonale, že alternativy nejsou pouzeodmítnuty, ale i téměř zapomenuty.

I think you can't really aim or plan fora result like this. You have to getpulled into it by design ideas sopowerful that afterward the resultsjust seem inevitable, natural, evenforeordained. The only way to try forideas like that is by having lots ofideas -- or by having the engineeringjudgment to take other peoples' goodideas beyond where the originatorsthought they could go.

Myslím si, že takový výsledek skutečněnemůžete plánovat. Musí Vás k němudovést vývojový plán tak silný, že přizpětném pohledu se zdají výsledkynevyhnutelné, téměř předpověditelné.Jedinou možností, jak dostat takovýnápad, je mít mnoho nápadů, nebo mítinženýrský úsudek a dovést nápadyněkoho jiného až za hranici toho, co siautor původní myšlenky dokázalpředstavit.

Andrew Tanenbaum had the originalidea to build a simple native Unix forthe 386, for use as a teaching tool.Linus Torvalds pushed the Minixconcept further than Andrewprobably thought it could go -- and itgrew into something wonderful. Inthe same way (though on a smaller

Andrew Tanenbaum přišel s původnímyšlenkou vystavět jednoduchý Unixpro 386 jako učební pomůcku. LinusTorvalds dotáhl koncept Minixu dále,než si zřejmě Andrew mohl představit avzniklo z něj něco úžasného. Stejnýmzpůsobem (ačkoliv v menším měřítku),jsem převzal nápady Carl Harrise a


1 z 4 22.2.2010 15:01

scale), I took some ideas by CarlHarris and Harry Hochheiser andpushed them hard. Neither of us was`original' in the romantic way peoplethink is genius. But then, mostscience and engineering and softwaredevelopment isn't done by originalgenius, hacker mythology to thecontrary.

Harry Hochheisera a dotáhl jsem je dokonce. Vždyť většina vědy, inženýrství asoftwarového vývoje není vytvářenanějakým originálním geniem, ač tohackerské bájesloví tvrdí.

The results were pretty heady stuffall the same -- in fact, just the kind ofsuccess every hacker lives for! Andthey meant I would have to set mystandards even higher. To makefetchmail as good as I now saw itcould be, I'd have to write not just formy own needs, but also include andsupport features necessary to othersbut outside my orbit. And do thatwhile keeping the program simpleand robust.

Výsledky byly přesto fantastické, veskutečnosti to byl právě takový úspěch,po kterém každý hacker touží. A toznamenalo, že si musím sám pro sebenastavit ještě náročnější kritéria. Abychučinil fetchmail tak dobrý, jak jen jsemsi byl schopen představit, musel jsempsát nejen pro své vlastní potřeby, alerovněž zahrnout podporu, kterou jsemnepotřeboval sám, ale jiní uživatelé. Apři tom všem jsem musel udržetprogram jednoduchý a stabilní.

The first and overwhelmingly mostimportant feature I wrote afterrealizing this was multidrop support-- the ability to fetch mail frommailboxes that had accumulated allmail for a group of users, and thenroute each piece of mail to itsindividual recipients.

První a zdaleka nejdůležitější funkcí,kterou jsem přidal poté, co jsem si všeuvědomil, byla podpora vícenásobnéhostahování, možnost stáhnout poštu zpoštovních schránek, které obsahovalipoštu více uživatelů a poté jidistribuovat jednotlivým příjemcům.

I decided to add the multidropsupport partly because some userswere clamoring for it, but mostlybecause I thought it would shakebugs out of the single-drop code byforcing me to deal with addressing infull generality. And so it proved.Getting RFC 822 parsing right tookme a remarkably long time, notbecause any individual piece of it ishard but because it involved a pile ofinterdependent and fussy details.

Rozhodl jsem se tuto funkci přidat,protože někteří uživatelé po ní toužili,ale zejména proto, že mě to přinutířádně prohlédnout současnou verzi aobjevit chyby, které ve snaze napsatmnohem obecnější postup vyplavou napovrch.


2 z 4 22.2.2010 15:01

But multidrop addressing turned outto be an excellent design decision aswell. Here's how I knew:

Ukázalo se, že se také jednalo avýborné konstrukční rozhodnutí.

14. Any tool should be useful in theexpected way, but a truly great toollends itself to uses you neverexpected.

14. Jakýkoliv nástroj by měl býtužitečný očekávaným způsobem, aleopravdu velké nástroje se hodí napoužití, které jste nikdy neočekával

The unexpected use for multi-dropfetchmail is to run mailing lists withthe list kept, and alias expansiondone, on the client side of theSLIP/PPP connection. This meanssomeone running a personal machinethrough an ISP account can manage amailing list without continuing accessto the ISP's alias files.

Tak tento přepsaný fetchmail bylneočekávaně využit při správědiskuzních skupin.

Another important change demandedby my beta testers was support for8-bit MIME operation. This was prettyeasy to do, because I had been carefulto keep the code 8-bit clean. Notbecause I anticipated the demand forthis feature, but rather in obedienceto another rule:

Další důležitou změnou, kterou odemne požadovali moji testovatelé, bylapodpora 8-bit MIME. To bylo docelasnadné, neboť jsem si dával pozor,abych nijak nepozměnil 8 bit. Nebylo toproto, že bych předvídal tentopožadavek, spíše jsem se řídil dalšímpravidlem:

15. When writing gateway softwareof any kind, take pains to disturbthe data stream as little aspossible -- and *never* throw awayinformation unless the recipientforces you to!

15. Pokud píšetezprostředkovatelský softwarejakéhokoliv druhu, snažte se vlastnídata nijak neměnit a nikdy senezbavujte žádné informace, pokudvás k tomu nedonutí příjemce.

Had I not obeyed this rule, 8-bitMIME support would have beendifficult and buggy. As it was, all Ihad to do is read RFC 1652 and add atrivial bit of header-generation logic.

Kdybych se tímto neřídil, podpora8-bitového MIME by byla obtížná a schybami. Takto mi stačilo přečíst sistandard a přidat něco triviální logikypři generaci hlaviček.

Some European users bugged me intoadding an option to limit the numberof messages retrieved per session (sothey can control costs from theirexpensive phone networks). I resistedthis for a long time, and I'm still notentirely happy about it. But if you're

Někteří evropští uživatelé mnepřemlouvali, abych přidal omezenípočtu vzkazů stáhnutelných při jednomsezení (aby mohli kontrolovat cenusvých drahých telefonních linek).Dlouho jsem tomu vzdoroval a stále stím nejsem zcela spokojen. Pokud ale


3 z 4 22.2.2010 15:01

writing for the world, you have tolisten to your customers -- this doesn'tchange just because they're notpaying you in money.

píšete pro celý svět, musíte naslouchatsvým zákazníkům, to se nemění jenomproto, že nejste placen penězi.



4 z 4 22.2.2010 15:01

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T8. A Few More LessonsFrom Fetchmail

8. Několik dalších lekcíz fetchmailu

Before we go back to generalsoftware-engineering issues, there area couple more specific lessons fromthe fetchmail experience to ponder.

Než se vrátíme k obecným problémůmsoftwarového inženýrství, je třeba sepoučit z několika specifických lekcí,které přinesl fetchmail.

The rc file syntax includes optional`noise' keywords that are entirelyignored by the parser. TheEnglish-like syntax they allow isconsiderably more readable than thetraditional terse keyword-value pairsyou get when you strip them all out.

Rc syntax zahrnuje nepovinnýparametr 'noise', které parser zcelaignoruje. Takováto anglicky znějícísyntax je mnohem čitelnější nežtradiční zhuštěné páryparametr=hodnota.

These started out as a late-nightexperiment when I noticed how muchthe rc file declarations were beginningto resemble an imperativeminilanguage. (This is also why Ichanged the original popclient `server'keyword to `poll').

Toto začalo jako noční experiment,když jsem si všiml, jak mnohodeklarace rc souborů připomínajípříkazový minimalistický jazyk. (Protojsem také změnil jeden z původníchparametrů popclienta "server" na"poll")

It seemed to me that trying to makethat imperative minilanguage morelike English might make it easier touse. Now, although I'm a convincedpartisan of the ``make it a language''school of design as exemplified byEmacs and HTML and many databaseengines, I am not normally a big fan of``English-like'' syntaxes.

Zdálo se mi, že pokud tento jazykbude více připomínat angličtinu, budesnáze použitelný. Ačkoliv jsempřesvědčený zastánce designerskéškoly, která se snaží učinit z příkazůjazyk, jako v případě HTML, Emacsu ařady databází, obvykle nemám přílišrád poangličtělou syntax.

Traditionally programmers havetended to favor control syntaxes thatare very precise and compact and haveno redundancy at all. This is a culturallegacy from when computingresources were expensive, so parsingstages had to be as cheap and simpleas possible. English, with about 50%redundancy, looked like a very

Tradičně programátoři dávají přednostsyntaxi, která je velmi přesná akompaktní. Toto je dědictví z doby,kdy výpočetní zdroje byly drahé, takžeprocházení souborů muselo být levné aco nejjednodušší. Tehdy se zdálaangličtina s 50% přebytkem slov zcelanevhodná.


1 z 3 22.2.2010 15:02

inappropriate model then.

This is not my reason for normallyavoiding English-like syntaxes; Imention it here only to demolish it.With cheap cycles and core, tersenessshould not be an end in itself.Nowadays it's more important for alanguage to be convenient for humansthan to be cheap for the computer.

To ovšem není můj důvod, proč setakovéto anglické syntaxi obvyklevyhýbám. Já ho zmiňuji pouze proto,abych jej vyvrátil. V dnešní době by užstručnost neměla být cílem kvůli soběsamé. Je důležitější, aby jazyk bylpohodlný pro uživatele, ne aby byllevný pro počítač.

There are, however, good reasons tobe wary. One is the complexity cost ofthe parsing stage -- you don't want toraise that to the point where it's asignificant source of bugs and userconfusion in itself. Another is thattrying to make a language syntaxEnglish-like often demands that the``English'' it speaks be bent seriouslyout of shape, so much so that thesuperficial resemblance to naturallanguage is as confusing as atraditional syntax would have been.(You see this in a lot of so-called``fourth generation'' and commercialdatabase-query languages.)

Existují ovšem důvody k obezřetnosti.Jedním z nich je složitost parsingu.Nechcete její složitost zvýšit naúroveň, kdy se stává zdrojem častýchchyb a začne plést i samotné uživatele.Dalším důvodem je, že pokud chcete,aby Váš jazyk zněl jako angličtina,musíte angličtinu značně pokroutit, ato natolik, že tento zpitvořený jazyk jestejně zmatečný, jako tradičnínesrozumitelná syntax. (Typickýmpříkladem jsou tzv. jazyky čtvrtégenerace a komerční jazyky propřístup k databázím.)

The fetchmail control syntax seems toavoid these problems because thelanguage domain is extremelyrestricted. It's nowhere near a general-purpose language; the things it sayssimply are not very complicated, sothere's little potential for confusion inmoving mentally between a tiny subsetof English and the actual controllanguage. I think there may be a widerlesson here:

Kontrolní systém fetchmailu se vyhnultěmto potížím proto, že jeho jazykováoblast je nesmírně omezená. Není tozdaleka jazyk obecný, to co říká, nenívůbec složité, takže je zde jen malýprostor pro zmatek při myšlenkovémpřechodu od jeho miniaturnípodmnožiny angličtiny k skutečnémuřídícímu jazyku. Možná nás to učídalší lekci:

16. When your language is nowherenear Turing-complete, syntactic sugarcan be your friend.

16. Pokud Váš jazyk není zdalekakompletní (Turing-complete),syntaktický cukr může být přítelem

Another lesson is about security byobscurity. Some fetchmail users askedme to change the software to store

Další lekce je o bezpečnosti přesutajení. Několik uživatelů mnepožádalo, abych pozměnil program


2 z 3 22.2.2010 15:02

passwords encrypted in the rc file, sosnoopers wouldn't be able to casuallysee them.

tak, aby ukládal hesla zašifrovaná v rcsouboru a tím zabránil příležitostnýmčumilům v jejich náhodném odkrytí.

I didn't do it, because this doesn'tactually add protection. Anyone who'sacquired permissions to read your rcfile will be able to run fetchmail asyou anyway -- and if it's your passwordthey're after, they'd be able to rip thenecessary decoder out of the fetchmailcode itself to get it.

Já to neudělal, protože tím veskutečnosti nezískáte žádnou ochranu.Každý, kdo získá přístupová práva kečtení vašeho rc souboru bude mocisám spustit fetchmail, a pokud chcevaše heslo, získá potřebný dekodér zkódu fetchmailu.

All .fetchmailrc password encryptionwould have done is give a false senseof security to people who don't thinkvery hard. The general rule here is:

Zašifrování hesla v .fetchmailrc bypouze dalo falešný pocit jistoty lidem,kteří o všem důkladně nepřemýšlejí.

17. A security system is only as secureas its secret. Beware of pseudo-secrets.

Bezpečnostní systém je pouze takbezpečný jako jeho tajemství.Mějte se na pozoru před pseudotajemstvími.



3 z 3 22.2.2010 15:02

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T9. NecessaryPreconditions for theBazaar Style

9. Nutné podmínkypro styl tržiště

Early reviewers and test audiences forthis paper consistently raised questionsabout the preconditions for successfulbazaar-style development, including boththe qualifications of the project leaderand the state of code at the time onegoes public and starts to try to build aco-developer community.

První čtenáři tohoto článku seneustále dotazovali na podmínky,které je třeba splnit pro úspěšnývývoj ve stylu tržiště. Ptali se, jakémusí mít kvality vůdce projektu a vjakém stavu musí být kód ve chvíli,kdy je zpřístupněn veřejnosti asnaží se získat další vývojáře.

It's fairly clear that one cannot code fromthe ground up in bazaar style. One cantest, debug and improve in bazaar style,but it would be very hard to originate aproject in bazaar mode. Linus didn't tryit. I didn't either. Your nascent developercommunity needs to have somethingrunnable and testable to play with.

Je celkem jasné, že není možnéprogramovat od počátku ve stylutržiště. Je možné testovat, hledatchyby a vylepšovat na tržišti, alebylo by velmi obtížné projektzahájit ve stylu tržiště. Linus se oto nepokusil a já také ne. Vaševznikající společenství vývojářůpotřebuje něco, co může testovat a sčím si může hrát.

When you start community-building,what you need to be able to present is aplausible promise. Your programdoesn't have to work particularly well. Itcan be crude, buggy, incomplete, andpoorly documented. What it must not failto do is convince potential co-developersthat it can be evolved into somethingreally neat in the foreseeable future.

Když začnete hledatspolupracovníky, potřebujete jimpředstavit uskutečnitelný cíl. Vášprogram nemusí pracovat přílišdobře, může být nepohodlný,obsahovat chyby a špatnědokumentován. Musí všakpřesvědčit budoucí vývojáře o tom ,že se v dohledné budoucnosti můževyvinout v něco skutečněužitečného.

Linux and fetchmail both went publicwith strong, attractive basic designs.Many people thinking about the bazaarmodel as I have presented it havecorrectly considered this critical, thenjumped from it to the conclusion that a

Linux i fetchmail měly již v doběprvého zpřístupnění silnou aatraktivní konstrukci. Mnoho lidí,kteří přemýšlejí o programování vestylu tržiště, toto považují zcelasprávně za základ úspěchu. Z tohoto


1 z 4 22.2.2010 15:02

high degree of design intuition andcleverness in the project leader isindispensable.

faktu však zbrkle docházejí kzávěru, že další nutnou podmínkouje konstrukční intuice vedoucíhoprojektu a jeho chytrost.

But Linus got his design from Unix. I gotmine initially from the ancestralpopclient (though it would later change agreat deal, much more proportionatelyspeaking than has Linux). So does theleader/coordinator for a bazaar-styleeffort really have to have exceptionaldesign talent, or can he get by onleveraging the design talent of others?

Linus ale převzal svoji konstrukci odUnixu a já tu svoji z předchůdcepopclienta (ačkoliv ta se potompodstatně změnila, procentuálněvzato mnohem více než v případěLinuxu). Takže musí mítvedoucí/koordinátor pro projekt vestylu tržiště neobyčejnýkonstrukční talent nebo mu stačívyužívat talent ostatních?

I think it is not critical that thecoordinator be able to originate designsof exceptional brilliance, but it isabsolutely critical that the coordinator beable to recognize good design ideasfrom others.

Já se domnívám, že není zcelanutné, aby koordinátor byl schopentvořit dokonalé konstrukce, ale jenaprosto nutné, aby byl schopenrozeznat dobré nápadyostatních.

Both the Linux and fetchmail projectsshow evidence of this. Linus, while not(as previously discussed) a spectacularlyoriginal designer, has displayed apowerful knack for recognizing gooddesign and integrating it into the Linuxkernel. And I have already described howthe single most powerful design idea infetchmail (SMTP forwarding) came fromsomebody else.

Linux i fetchmail to potvrzují.Linus, ačkoliv není (jak jsme jiždiskutovali) neobyčejně originálníkonstruktér, prokázal svojivýbornou schopnost rozpoznatdobré nápady a integrovat je dojádra Linuxu. A já jsem již popsal,že s tím nejlepším nápademohledně fetchmailu (SMTPpřesměrování) přišel někdo jiný.

Early audiences of this papercomplimented me by suggesting that Iam prone to undervalue designoriginality in bazaar projects because Ihave a lot of it myself, and therefore takeit for granted. There may be some truthto this; design (as opposed to coding ordebugging) is certainly my strongestskill.

Moji první čtenáři se mi snažilipodbízet tím, že tvrdili, že jsemnáchylný podceňovat originalitukonstrukce u projektů tržiště, neboťjá sám jsem jí obdařen, a proto jipovažuji za samozřejmou. V tommůže být něco pravdy, konstrukce(narozdíl od kódování nebo hledáníchyb) je mojí nejsilnější stránkou.

But the problem with being clever andoriginal in software design is that it getsto be a habit -- you start reflexively

S originalitou při konstrukciprogramů je ale problém. Začnetepodvědomě hledat původní a složitá


2 z 4 22.2.2010 15:02

making things cute and complicatedwhen you should be keeping them robustand simple. I have had projects crash onme because I made this mistake, but Imanaged not to with fetchmail.

řešení tam, kde je na místě použítněco robustního a jednoduchého.Některé mé projekty dříve selhaly,protože jsem se dopustil podobnýchchyb, v případě fetchmailu se mijich ale podařilo vyvarovat.

So I believe the fetchmail projectsucceeded partly because I restrained mytendency to be clever; this argues (atleast) against design originality beingessential for successful bazaar projects.And consider Linux. Suppose LinusTorvalds had been trying to pull offfundamental innovations in operatingsystem design during the development;does it seem at all likely that theresulting kernel would be as stable andsuccessful as what we have?

Já se domnívám, že projektfetchmail uspěl částečně proto, žejsem omezil svoje tendence hledatchytrá řešení. To ale argumentujeproti tvrzení o nutnosti originality vprojektu ve stylu tržiště. A vezmětesi Linux. Řekněme, že by se LinusTorvalds snažil zakomponovatoriginální nápady během vývojesystému. Je pravděpodobné, že byvzniklé jádro systému bylo takstabilní a úspěšné?

A certain base level of design and codingskill is required, of course, but I expectalmost anybody seriously thinking oflaunching a bazaar effort will already beabove that minimum. The open-sourcecommunity's internal market inreputation exerts subtle pressure onpeople not to launch development effortsthey're not competent to follow throughon. So far this seems to have workedpretty well.

Je zapotřebí mít jistou úroveňkonstrukčních schopností iprogramátorského umění, nicméněsi myslím, že prakticky každý, kdo oněčem takovém uvažuje bude napatřičné úrovni. Vnitřní trhotevřeného společenství tlačí navšechny, aby nezačínali projekty,které nejsou schopni uskutečnit.Dosud se zdá, že vše funguje.

There is another kind of skill notnormally associated with softwaredevelopment which I think is asimportant as design cleverness to bazaarprojects -- and it may be more important.A bazaar project coordinator or leadermust have good people andcommunications skills.

Existuje ale další schopnost, kteráse obvykle nespojuje s rozvojemsoftware a která je stejně důležitá,jako je schopnost konstruovat, amožná ještě důležitější. Vedoucíprojektu tržiště musí být schopnýkomunikovat a zacházet s lidmi.

This should be obvious. In order to builda development community, you need toattract people, interest them in whatyou're doing, and keep them happy aboutthe amount of work they're doing.Technical sizzle will go a long way

To by mělo být samozřejmé. Abystemohli stavět vývojářskou společnost,musíte přitáhnout lidi, získat jejichzájem o to, co děláte a snažit se, abybyli spokojení s prací, kterou dělají.Technické zapálení hodně pomáhá,


3 z 4 22.2.2010 15:02

towards accomplishing this, but it's farfrom the whole story. The personality youproject matters, too.

ale zdaleka není vším. Vaše povahaje také důležitá.

It is not a coincidence that Linus is a niceguy who makes people like him and wantto help him. It's not a coincidence thatI'm an energetic extrovert who enjoysworking a crowd and has some of thedelivery and instincts of a stand-upcomic. To make the bazaar model work,it helps enormously if you have at least alittle skill at charming people.

Není náhodné, že Linus je příjemnýchlapík, kterého mají lidé rádi achtějí mu pomoci. Není náhodné, žejá jsem energický extrovert, kterýrád pracuje v davu a má některéinstinkty a způsoby komika. Abyprojekt ve stylu tržiště uspěl, velmipomáhá, pokud dokážete alespoňtrochu okouzlit lidi.



4 z 4 22.2.2010 15:02

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T10. The Social Contextof Open-SourceSoftware

10. Společenskýkontext otevřenéhosoftware

It is truly written: the best hacks startout as personal solutions to theauthor's everyday problems, andspread because the problem turns outto be typical for a large class of users.This takes us back to the matter ofrule 1, restated in a perhaps moreuseful way:

Je velkou pravdou, že nejlepšíprogramy začínají tak, že autor sámpotřebujete vyřešit své každodenníproblémy, a šíří se proto, že se ukáže,že takový problém trápí mnohoostatních uživatelů. To nás vede zpět kpravidlu 1, které je přeformulováno domožná užitečnější podoby:

18. To solve an interesting problem,start by finding a problem that isinteresting to you.

18. Pokud chcete pracovat nazajímavém problému, začněte tím,že naleznete problém, který zajímávás osobně.

So it was with Carl Harris and theancestral popclient, and so with meand fetchmail. But this has beenunderstood for a long time. Theinteresting point, the point that thehistories of Linux and fetchmail seemto demand we focus on, is the nextstage -- the evolution of software in thepresence of a large and activecommunity of users and co-developers.

Tak začal i Carl Harris s popclientem ajá s fetchmailem. To se ale ví už dávno.To zajímavé, co nám Linux a fetchmailpřinesl, je další krok. Vývoj programůve velké skupině vývojářů a uživatelů.

In ``The Mythical Man-Month'', FredBrooks observed that programmertime is not fungible; adding developersto a late software project makes itlater. He argued that the complexityand communication costs of a projectrise with the square of the number ofdevelopers, while work done only riseslinearly. This claim has since becomeknown as ``Brooks's Law'' and iswidely regarded as a truism. But ifBrooks's Law were the whole picture,Linux would be impossible.

V knize The Mythical Man-Month,Fred Brooks tvrdí, že programátorůvčas není nastavitelný. Pokud přidáteprogramátory do projektu, který seopožďuje, opozdí se ještě více.Dokazuje, že složitost a problémy skomunikací se zvyšují se čtvercempočtu programátorů, zatímco množstvípráce stoupá pouze lineárně. Tototvrzení se později stalo Brookovýmzákonem, který je často považován zapředmět víry. Kdyby ale tento zákonplatil beze zbytku, Linux by nemohl


1 z 7 22.2.2010 15:02

existovat.

Gerald Weinberg's classic ``ThePsychology Of ComputerProgramming'' supplied what, inhindsight, we can see as a vitalcorrection to Brooks. In his discussionof ``egoless programming'', Weinbergobserved that in shops wheredevelopers are not territorial abouttheir code, and encourage otherpeople to look for bugs and potentialimprovements in it, improvementhappens dramatically faster thanelsewhere.

Klasická kniha Geralda Weinberga :"`The Psychology Of ComputerProgramming'', obsahuje něco, comůžeme při zpětném pohledupovažovat za nesmírně důležitouopravu Brookova tvrzení. V jehodiskuzi "nesobeckého programování"Weinberg tvrdí, že ve skupinách, vekterých si vývojáři nechrání svůj kód avybízejí ostatní, aby jim pomohlivyhledávat chyby a navrhovatvylepšení, projekty probíhají mnohemrychleji než jinde.

Weinberg's choice of terminology hasperhaps prevented his analysis fromgaining the acceptance it deserved --one has to smile at the thought ofdescribing Internet hackers as``egoless''. But I think his argumentlooks more compelling today thanever.

Weinbergova terminologie možnázabránila tomu, aby jeho analýzazískala takové přijetí, jaké sizasluhovala, člověk se musí usmát přimyšlence, že Internetovští hackeřijsou "nesobečtí". Nicméně, myslím, žejeho argumenty nebyly nikdy takaktuální jako dnes.

The history of Unix should haveprepared us for what we're learningfrom Linux (and what I've verifiedexperimentally on a smaller scale bydeliberately copying Linus's methods).That is, that while coding remains anessentially solitary activity, the reallygreat hacks come from harnessing theattention and brainpower of entirecommunities. The developer who usesonly his or her own brain in a closedproject is going to fall behind thedeveloper who knows how to create anopen, evolutionary context in whichbug-spotting and improvements getdone by hundreds of people.

Historie Unixu nás měla připravit nato, co se nyní učíme z Linuxu (a cojsem v menším měřítku ověřilexperimentálně tak, že jsem úmyslněkopíroval Linusovy metody). Tedy to,že zatímco kódování zůstává víceméněsamotářskou aktivitou, opravdu velkémyšlenky se uskutečňují tehdy, pokudje využita pozornost a mozky celéspolečnosti. Vývojář, který využívápouze vlastní mozek v uzavřenémprojektu musí zaostat za vývojářem,který dokáže iniciovat otevřenýevoluční projekt, ve kterém seodhalování chyb a vylepšení věnujístovky lidí.

But the traditional Unix world wasprevented from pushing this approachto the ultimate by several factors. Onewas the legal contraints of variouslicenses, trade secrets, and

Tradičnímu Unixovému světu bylozabráněno v dotažení tohoto přístupuněkolika faktory. Jedním z nich bylaprávní omezení, různé licence,obchodní tajemství a zájmy. Další


2 z 7 22.2.2010 15:02

commercial interests. Another (inhindsight) was that the Internet wasn'tyet good enough.

překážkou (při zpětném pohledu) byloto, že Internet ještě nebyl nadostatečné úrovni.

Before cheap Internet, there weresome geographically compactcommunities where the cultureencouraged Weinberg's ``egoless''programming, and a developer couldeasily attract a lot of skilled kibitzersand co-developers. Bell Labs, the MITAI Lab, UC Berkeley -- these becamethe home of innovations that arelegendary and still potent.

Před levným Internetem existovalaprostorově omezená společenství,jejichž kultura podporovalaWeinbergovo "nesobecképrogramování", ve kterých mohlprogramátor snadno přilákat mnohodiváků a spolupracovníků. Bellovylaboratoře, MIT AI laboratoře, UCBerkeley se staly legendárnímidomovy vynálezů a jsou stále velmiplodné.

Linux was the first project to make aconscious and successful effort to usethe entire world as its talent pool. Idon't think it's a coincidence that thegestation period of Linux coincidedwith the birth of the World Wide Web,and that Linux left its infancy duringthe same period in 1993-1994 that sawthe takeoff of the ISP industry and theexplosion of mainstream interest in theInternet. Linus was the first personwho learned how to play by the newrules that pervasive Internet madepossible.

Linux byl prvým projektem, kterývědomě a úspěšně využil celý světjako svoji studnici talentů. Nemyslímsi, že je náhodné, že Linux vznikal vdobě zrodu WWW a že Linux opustilsvá batolecí léta se začátkem nástupuInternetu do běžnéhopovědomí(1993-1994). Linus bylprvní, který se naučil hrát podlenových pravidel, které nastolilvšudypřítomný Internet.

While cheap Internet was a necessarycondition for the Linux model toevolve, I think it was not by itself asufficient condition. Another vitalfactor was the development of aleadership style and set of cooperativecustoms that could allow developers toattract co-developers and getmaximum leverage out of the medium.

Zatimco levný Internet byl nutnoupodmínkou pro to, aby se Linuxovýmodel uplatnil, myslím, že to nebylapodmínka dostačující. Dalšímnesmírně důležitým faktorem bylvývoj stylu vedení a vytvoření zvyků,které umožnily vývojářům získat dalšíspolupracovníky a využít všechnymožnosti tohoto media.

But what is this leadership style andwhat are these customs? They cannotbe based on power relationships -- andeven if they could be, leadership bycoercion would not produce the resultswe see. Weinberg quotes the

Ale jaký je styl vedení a jaké jsou tytozvyky? Tyto zvyklosti nemohou býtzaloženy na síle, a i pokud by byly, takby vedení z pozice síly nemohlopřinést výsledky, které vidíme.Weinberg cituje z autobiografie


3 z 7 22.2.2010 15:02

autobiography of the 19th-centuryRussian anarchist Pyotr AlexeyvichKropotkin's ``Memoirs of aRevolutionist'' to good effect on thissubject:

"Memoáry revoluce", kterou v 19.století napsal ruský anarchista PetrAlexejevič Kropotkin.

``Having been brought up in aserf-owner's family, I entered activelife, like all young men of my time,with a great deal of confidence in thenecessity of commanding, ordering,scolding, punishing and the like. Butwhen, at an early stage, I had tomanage serious enterprises and to dealwith [free] men, and when eachmistake would lead at once to heavyconsequences, I began to appreciatethe difference between acting on theprinciple of command and disciplineand acting on the principle of commonunderstanding. The former worksadmirably in a military parade, but itis worth nothing where real life isconcerned, and the aim can beachieved only through the severe effortof many converging wills.''

"Jelikož jsem se narodil v rodině, kterávlastnila nevolníky, započal jsem svůjaktivní život, jako všichni mladí muži vmém věku, s pevnou vírou v nutnostpovelů, příkazů, trestů atd. Brzy jsemale musel řídit důležité záležitosti ajednat se [svobodnými] muži, a zdeměla každá chyba závažné následky.Začal jsem oceňovat rozdíl mezičinností na základě příkazů adisciplíny a činností na základěspolečného porozumění. To prvéobdivuhodně funguje při vojensképřehlídce, ale nemá žádnou cenu veskutečném životě, kde cíle může býtdosaženo pouze úsilím mnohaspolupracujících myslí.

The ``severe effort of many convergingwills'' is precisely what a project likeLinux requires -- and the ``principle ofcommand'' is effectively impossible toapply among volunteers in theanarchist's paradise we call theInternet. To operate and competeeffectively, hackers who want to leadcollaborative projects have to learnhow to recruit and energize effectivecommunities of interest in the modevaguely suggested by Kropotkin's``principle of understanding''. Theymust learn to use Linus's Law.

"Velké úsilí mnoha spolupracujícíchmozků, to je přesně to, co projekt jakoLinux vyžaduje, a model řízenízaložený na povelech je zcela nemožnýv prostředí dobrovolníků vanarchistickém ráji, který nazývámeInternet. Aby mohli pracovat asoutěžit efektivně, programátoři, kteříchtějí vést projekty založené naspolupráci, se musí naučit, jak získata povzbuzovat skupiny lidí sespolečným zájmem, jak neurčitěnaznačuje Kropotkin svým "principemporozumění". Musí se naučit využívatLinusův zákon.

Earlier I referred to the ``Delphieffect'' as a possible explanation forLinus's Law. But more powerful

Dříve jsem se zmínil o "Delphi efektu"jako o možném vysvětlení Linusovazákona. Ještě silnější analogie s


4 z 7 22.2.2010 15:02

analogies to adaptive systems inbiology and economics also irresistablysuggest themselves. The Linux worldbehaves in many respects like a freemarket or an ecology, a collection ofselfish agents attempting to maximizeutility which in the process produces aself-correcting spontaneous ordermore elaborate and efficient than anyamount of central planning could haveachieved. Here, then, is the place toseek the ``principle ofunderstanding''.

přizpůsobivými systémy ale nabízíbiologie a ekonomie. Linusův svět se vmnoha ohledech chová jako volný trhnebo ekologie, společnost sobeckýchindividuí, která se snaží maximalizovatužitek a při tomto ději vznikásebeopravující se spontánní řád vícepropracovaný a účinnější, než můžedosáhnout jakékoliv centrálníplánování. Zde bychom měli hledat"princip porozumění".

The `ùtility function'' Linux hackersare maximizing is not classicallyeconomic, but is the intangible of theirown ego satisfaction and reputationamong other hackers. (One may calltheir motivation `àltruistic'', but thisignores the fact that altruism is itself aform of ego satisfaction for thealtruist). Voluntary cultures that workthis way are not actually uncommon;one other in which I have longparticipated is science fiction fandom,which unlike hackerdom explicitlyrecognizes `ègoboo'' (theenhancement of one's reputationamong other fans) as the basic drivebehind volunteer activity.

"Užitková funkce, kterou linuxovýprogramátoři maximalizují neníklasicky ekonomická, ale lze ji spojit suspokojením vlastního já a získánímdobré reputace mezi ostatnímiprogramátory. (Někdo by mohl nazvattoto chování altruistické, ale tentopohled ignoruje fakt, že altruismus jesám o sobě formou uspokojenívlastního já pro altruistu). Dobrovolnáspolečenství, která pracují podobnýmzpůsobem nejsou ve skutečnostivzácná, podobným, ve kterém jsemzapojen již velmi dlouho je okruhpřátel science fiction, ve kterém jevýslovně uznáváno, že hlavnímmotivem pro spolupráci je zvýšenívlastní reputace mezi ostatními.

Linus, by successfully positioninghimself as the gatekeeper of a projectin which the development is mostlydone by others, and nurturing interestin the project until it becameself-sustaining, has shown an acutegrasp of Kropotkin's ``principle ofshared understanding''. This quasi-economic view of the Linux worldenables us to see how thatunderstanding is applied.

Linus tím, že se úspěšně postavil dorole ochránce projektu, který je zvelké části rozvíjen někým jiným atím, že získával podporu pro projektdokud se projekt nestalsebeudržujícím, ukázal, že plněpochopil Kropotkinovo pravidlosdíleného porozumění. Kvasi-ekonomický pohled na Linuxův světnám umožňuje pochopit, jak se tentoprincip uplatňuje.


5 z 7 22.2.2010 15:02

We may view Linus's method as a wayto create an efficient market in``egoboo'' -- to connect the selfishnessof individual hackers as firmly aspossible to difficult ends that can onlybe achieved by sustained cooperation.With the fetchmail project I haveshown (albeit on a smaller scale) thathis methods can be duplicated withgood results. Perhaps I have even doneit a bit more consciously andsystematically than he.

Můžeme nahlížet na Linusovy metodyjako na způsob, jak vytvořit účinný trhv uspokojování vlastního já, tím, žepřipoutá sobectví individuelníchprogramátorů co nejpevněji kobtížným cílům, které mohou býtdosaženy pouze vytrvalou spoluprací.V projektu fetchmailu jsem ukázal(ačkoli v menším měřítku), že tatometoda může být napodobena sdobrými výsledky. Možná, že jsem všedělal s plnějším vědomím asystematičtěji než Linus sám.

Many people (especially those whopolitically distrust free markets) wouldexpect a culture of self-directedegoists to be fragmented, territorial,wasteful, secretive, and hostile. Butthis expectation is clearly falsified by(to give just one example) the stunningvariety, quality and depth of Linuxdocumentation. It is a hallowed giventhat programmers hate documenting;how is it, then, that Linux hackersgenerate so much of it? EvidentlyLinux's free market in egoboo worksbetter to produce virtuous, other-directed behavior than the massively-funded documentation shops ofcommercial software producers.

Mnoho lidí, zejména těch, kteřípoliticky nedůvěřují volnému trhu,očekávají, že společnost sebeřídícíchegoistů bude fragmentována, budeochraňovat svá území, bude plýtvatzdroji, vše tajit a bude k soběnepřátelská.Ale toto očekávání jejasně vyvráceno napříkladpřekvapující různorodostí, kvalitou ahloubkou dokumentace Linuxu. Je tozázrak, když si uvědomíme, jakprogramátoři nenávidí psanídokumentace. Jak je tedy možné, žeprogramátoři Linuxu ji produkujítolik? Je zřejmé, že Linuxův volný trh vsebeuspokojování funguje lépe přinastolení ctnostného chování nežmasivně financované dokumentačníútvary poskytovatelů komerčníhosoftware.

Both the fetchmail and Linux kernelprojects show that by properlyrewarding the egos of many otherhackers, a strongdeveloper/coordinator can use theInternet to capture the benefits ofhaving lots of co-developers withouthaving a project collapse into a chaoticmess. So to Brooks's Law I counter-propose the following:

Fetchmail i Linux ukázaly, že pokuddostatečně odměním ego mnohajiných programátorů, silný vývojář-koordinátor může využít Internet, abyzískal mnoho spolupracovníků, aniž seprojekt zhroutí v chaotický zmatek.Takže já navrhuji následujícíprotiargument k Brookově zákonu.


6 z 7 22.2.2010 15:02

19: Provided the developmentcoordinator has a medium at leastas good as the Internet, and knowshow to lead without coercion, manyheads are inevitably better thanone.

19. Pokud má koordinátor projektuk dispozici medium alespoň takdobré jako Internet a dokáže véstbez příkazů, mnoho hlav jenevyhnutelně lepší než jedna.

I think the future of open-sourcesoftware will increasingly belong topeople who know how to play Linus'sgame, people who leave behind thecathedral and embrace the bazaar.This is not to say that individual visionand brilliance will no longer matter;rather, I think that the cutting edge ofopen-source software will belong topeople who start from individual visionand brilliance, then amplify it throughthe effective construction of voluntarycommunities of interest.

Myslím si, že budoucnost otevřenéhosoftware bude stále více patřit lidem,kteří vědí, jak se chovat v Linusověhře, lidem, kteří opustí katedrálu avezmou si tržiště za své. Tím nechciříci, že už nezáleží na individuálníchvizích a velkých schopnostech. Spíše simyslím, že budoucnost patří lidem,kteří začnou s individuální vizí avelkými schopnostmi a ty potomzmnohonásobí ve vytvořenýchskupinách se společným zájmem.

And perhaps not only the future ofopen-source software. No closed-source developer can match the pool oftalent the Linux community can bringto bear on a problem. Very few couldafford even to hire the more than twohundred people who have contributedto fetchmail!

A možná nejen budoucnostotevřeného software. Žádný vývojářv uzavřeném projektu nemůže míttakovou nabídku talentů pro vyřešeníproblému, jako se nachází vespolečenství Linuxu. Jen málokdo simůže dovolit najmout více než 200lidí, kteří přispívali do fetchmailu.

Perhaps in the end the open-sourceculture will triumph not becausecooperation is morally right orsoftware ``hoarding'' is morally wrong(assuming you believe the latter, whichneither Linus nor I do), but simplybecause the closed-source worldcannot win an evolutionary arms racewith open-source communities thatcan put orders of magnitude moreskilled time into a problem.

Možná že nakonec kultura otevřenéhosoftware zvítězí ne proto, že jemorálně správná, nebo že hamouněnísoftware je morálně špatné (zapředpokladu, že tomu druhému věříte,já ani Linus ne), ale jednoduše proto,že uzavřené projekty nemohou vyhrátv evolučním zápase s otevřenýmsystémem, který může vynaložit oněkolik řádů více kvalifikovaného časuna řešení problémů.



7 z 7 22.2.2010 15:02

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T11. Acknowledgements 11. Poděkování

This paper was improved by conversations with alarge number of people who helped debug it.Particular thanks to Jeff Dutky<[email protected]>, who suggested the``debugging is parallelizable'' formulation, andhelped develop the analysis that proceeds from it.Also to Nancy Lebovitz<[email protected]> for her suggestionthat I emulate Weinberg by quoting Kropotkin.Perceptive criticisms also came from JoanEslinger <[email protected]>and Marty Franz <[email protected]> of theGeneral Technics list. I'm grateful to themembers of PLUG, the Philadelphia Linux User'sgroup, for providing the first test audience forthe first public version of this paper. Finally,Linus Torvalds's comments were helpful and hisearly endorsement very encouraging.

Tento článek byl vylepšendíky diskuzím s mnohalidmi. Zejména děkujiJeffovi Dutkymu, kterýnavrhl termín "hledáníchyb je paralelizovatelné" apomohl vyvinout analýzu,která z něj vychází. Rovněžděkuji Nancy Lebovitz zajejí návrh emulaceWeinberga citací zKropotkina. Vnímavoukritikou rovněž přispěliJoan Eslinger a MartyFranz. Jsem vděčný členůmPLUG(Skupina uživatelůLinuxu ve Philadelphii),kteří se stali mým prvnímtestovacím publikem proprvou veřejnou verzičlánku. A nakonec, děkujiLinusovi Torvaldovi za jehocenné připomínky a zapovzbuzení, které se midostalo od samého počátku.



1 z 1 22.2.2010 15:03

<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T12. For FurtherReading

12. K dalšímu čtení

I quoted several bits from Frederick P.Brooks's classic The MythicalMan-Month because, in manyrespects, his insights have yet to beimproved upon. I heartily recommendthe 25th Anniversary edition fromAddison-Wesley (ISBN 0-201-83595-9),which adds his 1986 ``No SilverBullet'' paper.

Několikrát jsem citoval z klasicképráce Frederika P. Brooka "TheMythical Man-Month". Vřeledoporučuji edici k 25 výročí (ISBN0-201-83595-9), ke které je přidánčlánek z roku 1986 ``No SilverBullet''.

The new edition is wrapped up by aninvaluable 20-years-later retrospectivein which Brooks forthrightly admits tothe few judgements in the original textwhich have not stood the test of time. Ifirst read the retrospective after thispaper was substantially complete, andwas surprised to discover that Brooksattributes bazaar-like practices toMicrosoft! (In fact, however, thisattribution turned out to be mistaken.In 1998 we learned from theHalloween Documents thatMicrosoft's internal developercommunity is heavily balkanized, withthe kind of general source accessneeded to support a bazaar not eventruly possible.)

Tato nová edice je doplněnaneocenitelným zpětným pohledem nauplynulých 20 let, ve kterém se Brookupřímně přiznává k tvrzením, kteránebyla potvrzena dalším vývojem. Jájsem toto zpětné ohlédnutí poprvé četlve chvíli, kdy tento článek byl z velkéčásti hotov a překvapilo mne, žeBrooks přičítá principz tržištěMicrosoftu!.(Ve skutečnosti se ale tototvrzení ukázalo mylné. V roce 1998jsme se z uniklých dokumenů, tzv.Halloween Documents dozvěděli, ževnitřní vývojářská komunitaMicrosoftu je balkanizovaná, bezmožností obecného přístupu kezdrojům, které styl tržiště vyžaduje.

Gerald M. Weinberg's The PsychologyOf Computer Programming (NewYork, Van Nostrand Reinhold 1971)introduced the rather unfortunately-labeled concept of ``egolessprogramming''. While he was nowherenear the first person to realize thefutility of the ``principle ofcommand'', he was probably the firstto recognize and argue the point in

Gerald M. Weinberg's v knize ThePsychology Of ComputerProgramming (New York, VanNostrand Reinhold 1971)zavedlponěkud nešťastně označený pojem"nesobecké programování". Ačkolivnebyl zdaleka prvým, kdo si uvědomilnedostatečnost "principu založenémna příkazech", byl pravděpodobněprvní, který rozpoznal a zdůvodňoval


1 z 3 22.2.2010 15:03

particular connection with softwaredevelopment.

toto stanovisko s ohledem na vývojsoftware.

Richard P. Gabriel, contemplating theUnix culture of the pre-Linux era,reluctantly argued for the superiorityof a primitive bazaar-like model in his1989 paper Lisp: Good News, BadNews, and How To Win Big. Thoughdated in some respects, this essay isstill rightly celebrated among Lispfans (including me). A correspondentreminded me that the section titled``Worse Is Better'' reads almost as ananticipation of Linux. The paper isaccessible on the World Wide Web athttp://www.naggum.no/worse-is-better.html.

Richard P. Gabriel, který přemýšlelnad Unixovou kulturou v období předLinuxem, váhavě argumentoval opřednostech jednoduchých stylůtržiště ve svém článku z roku 1989Lisp: Dobré zprávy, špatné zprávy ajak zvítězit. Ačkoliv již v některýchohledech zastaralá, tento esej je stáleuctíván mezi příznivci Lispu (včetněmne). Byl jsem upozorněn, že částnazvaná "Horší je lepší" lze vyložitjako předpověď Linuxu. Tento článekje přístupný na WWW na adresehttp://www.naggum.no/worse-is-better.html

De Marco and Lister's Peopleware:Productive Projects and Teams(New York; Dorset House, 1987; ISBN0-932633-05-6) is anunderappreciated gem which I wasdelighted to see Fred Brooks cite in hisretrospective. While little of what theauthors have to say is directlyapplicable to the Linux or open-sourcecommunities, the authors' insight intothe conditions necessary for creativework is acute and worthwhile foranyone attempting to import some ofthe bazaar model's virtues into acommercial context.

Kniha De Marca a ListeraPeopleware: Productive Projectsand Teams (New York; Dorset House,1987; ISBN 0-932633-05-6) jenedoceněný klenot. Byl jsem velmipotěšen, když Fred Brooks jej citovalve své retrospektivě. Ačkoliv málo ztoho, co autoři píší je přímoaplikovatelné na Linux, jejich náhledna nutné podmínky pro tvořivou prácije přesný a cenný pro každého, kterýchce přenést některé přednosti tržištědo komerčního prostředí.

Finally, I must admit that I very nearlycalled this paper ``The Cathedral andthe Agora'', the latter term being theGreek for an open market or publicmeeting place. The seminal ``agoricsystems'' papers by Mark Miller andEric Drexler, by describing theemergent properties of market-likecomputational ecologies, helpedprepare me to think clearly aboutanalogous phenomena in the

Na závěr musím připustit, že jsemčlánek téměř nazval "Katedrála aAgora". Agora je řecký výraz prootevřený trh nebo místo veřejnýchsetkání. Články Marka Millera a EricaDrexlera popisující vlastnosti tržníchpočítačových ekologií, mne pomohlyujasnit si analogické jevy v otevřenémspolečenství, když jsem narazil naLinux o pět let později. Tyto článkyjsou dostupné na síti na adrese


2 z 3 22.2.2010 15:03

open-source culture when Linuxrubbed my nose in them five yearslater. These papers are available on theWeb at http://www.agorics.com/agorpapers.html.

http://www.agorics.com/agorpapers.html.



3 z 3 22.2.2010 15:03

<<< TOC / OBSAH EN CS EN/CS ZVON P/T

13. Epilog: NetscapeEmbraces the Bazaar!

13. Epilog:Netscape přijalatržiště

It's a strange feeling to realize you'rehelping make history....

Je to zvláštní pocit, když siuvědomíte, že pomáháte vytvářethistorii ...

On January 22 1998, approximately sevenmonths after I first published this paper,Netscape Communications, Inc. announcedplans to give away the source forNetscape Communicator. I had had noclue this was going to happen before theday of the announcement.

26.ledna 1998, asi sedm měsícůpoté, co jsem poprvé publikovaltento článek, NetscapeCommunications, Inc. oznámilsvé plány zveřejnit zdrojovýkód Netscape Communicator.Neměl jsem žádné tušení o tom,že se k tomu schyluje do dneoznámení.

Eric Hahn, Executive Vice President andChief Technology Officer at Netscape,emailed me shortly afterwards as follows:``On behalf of everyone at Netscape, I wantto thank you for helping us get to this pointin the first place. Your thinking andwritings were fundamental inspirations toour decision.''

Eric Hahn, náměstek ředitele ahlavní technolog v Netscape mikrátce poté napsal tento email:"Jménem nás všech v NetscapeVám chci poděkovat za to, že jstenás k tomuto nápadu přivedl.Vaše myšlenky a články bylyzákladní inspirací pro našerozhodnutí."

The following week I flew out to SiliconValley at Netscape's invitation for a day-longstrategy conference (on Feb 4 1998) withsome of their top executives and technicalpeople. We designed Netscape's source-release strategy and license together, andlaid some more plans that we hope willeventually have far-reaching and positiveimpacts on the open-source community. As Iwrite, it is a bit too soon to be morespecific; but details should be forthcomingwithin weeks.

Následující týden jsem bylpozván společností Netscape doSilicon Valley na celodennístrategickou konferenci s jejichhlavními manažery a techniky.Navrhli jsme strategii prozveřejnění zdrojů a pro licence apřipravili další plány, keré, jakdoufáme, budou mít dalekosáhléa kladné účinky.

Netscape is about to provide us with a large-scale, real-world test of the bazaar model in

Netscape nám poskytuje velkýreálný test modelu ve stylu


1 z 2 22.2.2010 15:03

the commercial world. The open-sourceculture now faces a danger; if Netscape'sexecution doesn't work, the open-sourceconcept may be so discredited that thecommercial world won't touch it again foranother decade.

tržiště v komerčním světě.Stojíme před velkýmnebezpečím. Pokud tento projektselže, může být celý koncept takzdiskreditován, že komerčnímsvět na něj zanevře na dalšídesetiletí.

On the other hand, this is also a spectacularopportunity. Initial reaction to the move onWall Street and elsewhere has beencautiously positive. We're being given achance to prove ourselves, too. If Netscaperegains substantial market share throughthis move, it just may set off a long-overduerevolution in the software industry.

Na druhé straně je to také skvělápříležitost. Počáteční reakce WallStreetu i jinde byla obezřetněkladná. Byla nám dána šance seosvědčit. Pokud získá Netscapedíky tomuto tahu podstatný podílna trhu, může to způsobit dlouhoočekávanou revoluci vsoftwarovém průmyslu.

The next year should be a very instructiveand interesting time.

Příští rok bude velmi zajímavý.

<<< TOC / OBSAH EN CS EN/CS ZVON P/T


2 z 2 22.2.2010 15:03