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

Zvon: T he Cathedral and the Bazaar

START

EN CS

http://www.zvon.org/ZvonHT ML/T ranslations/cath...

EN/CS

TISK

P/T

ZVON

Original location: http://www.netaxs.com/~esr/writings/cathedralbazaar/ Copyright: Eric Raymond

Eric Raymond

Eric Raymond

The Cathedral and the Bazaar

Katedrá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 Podrobně rozebírám úspěšný otevřený project, fetchmail, that was run as a projekt, fetchmail. Tento projekt cíleně deliberate test of some surprising theories testoval některé překvapivé teorie o about software engineering suggested by softwarovém in�enýrství. Tyto teorie, the history of Linux. I discuss these theories inspirované historií Linuxu, jsou in terms of two fundamentally different zasazeny do kontextu dvou různých development styles, the ``cathedral'' model vývojových stylů, modelu "katedrály" , of most of the commercial world versus the kterou pou�ívá většina komerčního ``bazaar'' model of the Linux world. I show světa a Linuxového modelu "tr�iště". that these models derive from opposing Ukazuji, �e tyto modely vycházejí z assumptions about the nature of the protikladných představ o vývoji softwaredebugging task. I then make a software. Na základě zkušeností sustained argument from the Linux získaných s Linuxem poté dokazuji, �e experience for the proposition that ``Given "Pokud máte dostatek očí, všechny enough eyeballs, all bugs are shallow'', chyby jsou průhledné", nabízím analogie suggest productive analogies with other s jinými sebeopravujícími systémy a selfcorrecting systems of selfish agents, článek končím diskuzí o tom, jaké and conclude with some exploration of the implikace tato fakta mají pro implications of this insight for the future of budoucnost software. software.

1z2

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.

22.2.2010 14:57

Zvon: T he Cathedral and the Bazaar

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 Fetchmail

Několik dalších lekcí z fetchmailu

Necessary Preconditions for the Bazaar Style

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

The Social Context of Open-Source Software

Společenský kontext otevřeného software

Acknowledgements

Poděkování

For Further Reading

K dalšímu čtení

Epilog: Netscape Embraces the Bazaar!

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

START

2z2


EN CS

EN/CS

TISK

P/T

ZVON

22.2.2010 14:57

Zvon:


TOC / OBSAH >>> EN CS EN/CS ZVON P/T 1. The Cathedral and 1. Katedrála a tržiště the Bazaar Linux is subversive. Who would have thought even five years ago that a world-class operating system could coalesce as if by magic out of part-time hacking by several thousand developers scattered all over the planet, connected only by the tenuous strands of the Internet? Certainly not I. By the time Linux swam onto my radar screen in early 1993, I had already been involved in Unix and open-source development for ten years. I was one of the first GNU contributors in the mid-1980s. I had released a good deal of open-source software onto the net, developing or co-developing several programs (nethack, Emacs VC and GUD modes, xlife, and others) that are still in wide use today. I thought I knew how it was done. Linux overturned much of what I thought I knew. I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important software (operating systems and really large tools like Emacs) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its

1z3

Kdo by si pomyslel ještě před pěti lety, že prvotřídní operační systém může vzniknout 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. Já určitě ne. Počátkem roku 1993, kdy se Linux poprvé objevil na mé radarové obrazovce, jsem se již 10 let zabýval Unixem a otevřeným vývojem . V polovině osmdesátých letl jsem patřil k prvým přispěvatelům GNU, přes Internet jsem zpřístupnil řadu otevřeného software, vyvinul jsem nebo se 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 postavil na hlavu mnohé z toho, co jsem znal. Léta jsem šířil Unixovou ví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í je již vyžadován více centralizovaný přístup. Věřil jsem, že nejdůležitější software (operační systémy a opravdu velké nástroje jako Emacs) musí být stavěny stejně jako katedrály, pečlivě opracovávány jednotlivými čaroději nebo malými skupinami kouzelníků pracujících v příjemném osamění a publikujícími prvé výsledky své práce až ve vhodný čas. 22.2.2010 14:58

Zvon:


time. Linus Torvalds's style of development release early and often, delegate everything you can, be open to the point of promiscuity - came as a surprise. No quiet, reverent cathedralbuilding here -- rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who'd take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles. The fact that this bazaar style seemed to work, and work well, came as a distinct shock. As I learned my way around, I worked hard not just at individual projects, but also at trying to understand why the Linux world not only didn't fly apart in confusion but seemed to go from strength to strength at a speed barely imaginable to cathedral-builders. By mid-1996 I thought I was beginning to understand. Chance handed me a perfect way to test my theory, in the form of an open-source project which I could consciously try to run in the bazaar style. So I did -and it was a significant success. In the rest of this article, I'll tell the story of that project, and I'll use it to propose some aphorisms about effective open-source development. Not all of these are things I first learned in the Linux world, but we'll see how the Linux world gives them particular point. If I'm correct, they'll help you understand exactly what it is 2z3

Vývoj ve stylu Linuse Torvalda publikuj brzy a často, přenes na ostatní vše co můžeš, buď otevřený až téměř k bodu promiskuity, to bylo velké překvapení.. Linuxové společenství více připomíná velké hlučné tržiště různých metod a postupů než tichou, oddanou práci na stavbě katedrály. Linuxové archivy, které přijímají příspěvky od kohokoliv, jsou toho důkazem. Zdálo by se, že z něčeho takového se může koherentní a stabilní systém vynořit pouze sérií zázraků. Fakt, že tento styl tržiště fungoval a fungoval dobře, to bylo velké překvapení. Když jsem se naučil v tomto světě orientovat, pracoval jsem usilovně nejen na jednotlivých projektech, ale také jsem se pokoušel porozumět, jak je možné, že se svět Linuxu nejen že nerozletí na kusy v naprostém zmatku, ale naopak neustále sílí rychlostí, kterou si umí stavitelé katedrál stěží představit. V polovině roku 1996 se mi zdálo, že jsem systému porozuměl. Náhoda mi přihrála do cesty výborný způsob, jak své teorie otestovat formou otevřeného projektu, který jsem mohl cíleně rozběhnout ve stylu tržiště. Využil jsem šance a projekt skončil velkým úspěchem. Ve zbytku článku vám budu vyprávět příběh tohoto projektu a na jeho základě navrhnu několik algoritmů pro efektivní 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ět klade na některé věci obzvláštní důraz. Pokud se nemýlím, pomůže vám přesně pochopit, co činí z Linuxového 22.2.2010 14:58

Zvon:


that makes the Linux community such společenství takovou studnici dobrého a fountain of good software -- and help software a pomůže i vám zvýšit you become more productive yourself. produktivitu.

TOC / OBSAH

3z3

>>> EN CS EN/CS ZVON P/T

22.2.2010 14:58

Zvon:


<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T 2. The Mail Must Get 2. Pošta musí projít Through Od roku 1993 jsem měl na starosti Since 1993 I'd been running the technické zabezpečení malého technical side of a small free-access poskytovatele bezplatného přístupu k ISP called Chester County InterLink Internetu (Chester County InterLink (CCIL) in West Chester, Pennsylvania CCIL , West Chester, Pennsylvania). (I co-founded CCIL and wrote our Patřím k zakladatelům CCIL a napsal unique multiuser bulletin-board jsem pro něj unikátní mnohauživatelský software -- you can check it out by buletinový software, který si můžete telnetting to locke.ccil.org. Today it prohlédnout přes telnet na adrese supports almost three thousand users locke.ccil.org. V dnešní době on thirty lines.) The job allowed me podporuje téměř 3000 uživatelů na 30 24-hour-a-day access to the net linkách. Tato práce mi umožnila 24 through CCIL's 56K line -- in fact, it hodinový přístup na Internet přes 56K practically demanded it! linku CCIL, pro moji práce byl takový přístup nutností. Accordingly, I had gotten quite used Díky tomu jsem si zvykl na okamžitý to instant Internet email. For přístup k e-mailu. Z různých složitých complicated reasons, it was hard to důvodů bylo obtížné zprovoznit SLIP get SLIP to work between my home mezi mým domácím počítačem machine (snark.thyrsus.com) and (snark.thyrsus.com) a CCIL. Když se mi CCIL. When I finally succeeded, I to konečně podařilo, pravidelné found having to periodically telnet logování a kontrola pošty přes telnet mě over to locke to check my mail začalo obtěžovat. Potřeboval jsem nějak annoying. What I wanted was for my přesunout poštu na můj domácí počítač mail to be delivered on snark so that snark tak, abych byl upozorněn při I would be notified when it arrived jejím přijetí. Poštu jsem pak chtěl dálei and could handle it using all my local zpracovávat s pomocí různých tools. programů na mém osobním počítači. Simple sendmail forwarding wouldn't Jednoduché přesměrování pošty work, because my personal machine programem sendmail nepřipadalo v isn't always on the net and doesn't úvahu, protože můj počítač není vždy have a static IP address. What I připojen k síti a nemá stálou IP adresu. needed was a program that would Potřeboval jsem program, který by mne reach out over my SLIP connection připojil přes SLIP a poté přenesl poštu. and pull across my mail to be Věděl jsem, že takové programy existují delivered locally. I knew such things a že většina z nich využívá jednoduchý existed, and that most of them used a aplikační protokol, nazývaný POP

1z6

22.2.2010 14:59

Zvon:


simple application protocol called POP (Post Office Protocol). And sure (poštovní protokol). A skutečně, náš enough, there was already a POP3 BSD/OS operační systém v sobě server included with locke's BSD/OS obsahoval i POP3 server. operating system. Potřeboval jsem tedy POP3 klienta. I needed a POP3 client. So I went out Rozhlédl jsem se po síti a jeden jsem on the net and found one. Actually, I našel. Tedy ve skutečnosti jsem jich found three or four. I used pop-perl nalezl několik. Po nějaký čas jsem for a while, but it was missing what používal pop-perl, ale tomu chyběla seemed an obvious feature, the funkce, kterou jsem považoval za ability to hack the addresses on podstatnou, nebyl totiž schopen fetched mail so replies would work pozměnit adresy přicházející pošty tak, properly. abych mohl na obdrženou poštu přímo odpovídat. The problem was this: suppose Problém spočíval v tomto: řekněme, že someone named `joe' on locke sent někdo se jménem "joe" my poslal me mail. If I fetched the mail to e-mail. Pokud jsem si jej stáhl na snark snark and then tried to reply to it, a poté se na něj pokusil odpovědět, můj my mailer would cheerfully try to poštovní klient se snažil poslat odpověď ship it to a nonexistent `joe' on neexistujícímu joeovi na snarku. Ruční snark. Hand-editing reply addresses editace adres mne ale brzy začala to tack on `@ccil.org' quickly got to unavovat. be a serious pain. This was clearly something the Toto byla věc, kterou mohl počítač dělat computer ought to be doing for me. za mne. Žádný z existujících klientů ale But none of the existing POP clients nevěděl jak. A to nám přináší prvé knew how! And this brings us to the ponaučení: first lesson: 1. Every good work of software 1. Každý dobrý program začíná tím, starts by scratching a developer's že řeší potíže samotného personal itch. programátora. Perhaps this should have been Možná, že by to mělo být samozřejmé obvious (it's long been proverbial that (existuje staré přísloví: "Nutnost je ``Necessity is the mother of matka pokroku"), ale až příliš často invention'') but too often software vývojáři traví svůj čas prací na developers spend their days grinding programech, za které jsou placeni, ale away for pay at programs they které ani nemilují ani nepotřebují. To neither need nor love. But not in the však neplatí ve světě Linuxu a snad Linux world -- which may explain právě proto je průměrná kvalita why the average quality of software software vyvinutého v Linuxovém originated in the Linux community is společenství tak vysoká.

2z6

22.2.2010 14:59

Zvon:


so high. So, did I immediately launch into a furious whirl of coding up a brand-new POP3 client to compete with the existing ones? Not on your life! I looked carefully at the POP utilities I had in hand, asking myself ``which one is closest to what I want? 2. Because good programmers know what to write. Great ones know what to rewrite (and reuse). While I don't claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it's almost always easier to start from a good partial solution than from nothing at all. Linus Torvalds, for example, didn't actually try to write Linux from scratch. Instead, he started by reusing code and ideas from Minix, a tiny Unix-like OS for 386 machines. Eventually all the Minix code went away or was completely rewritten -but while it was there, it provided scaffolding for the infant that would eventually become Linux. In the same spirit, I went looking for an existing POP utility that was reasonably well coded, to use as a development base. The source-sharing tradition of the Unix world has always been friendly to code reuse (this is why the GNU project chose Unix as a base OS, in spite of serious reservations about the OS itself). The Linux world has taken this tradition nearly to its technological limit; it has terabytes

3z6

Takže, vrhl jsem se okamžitě do horečného programování a začal psát zcela nového POP3 klienta, který by mohl soutěžit s existujícími programy? V žádném případě! Pečlivě jsem prostudoval známé POP programy a hledal takový, který nejvíce odpovídal mým představám. 2. Protože dobří programátoři vědí co psát. Velcí vědí, co přepsat (a znovu použít) Ačkoli o sobě netvrdím, že jsem velký programátor, snažím se ty velké napodobit. Důležitým rysem velkých programá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ždy snažší začít od dobrých částečných řešení než od úplého počátku. Linus Torvalds také nezačal psát Linux od prvé řádky. Místo toho použil kód a nápady Minixu, malého operačního systému napodobujícího Unix, který byl určen pro počítače řady 386. Dnes již veškerý původní kód Minixu buďto zmizel zcela nebo byl od základu přepsán, ale na počátku vytvářel lešení podpírající batole, které se nakonec stalo Linuxem. Veden stejnými motivy jsem prohlížel existující POP programy a hledal takové, které byly vhodné jako základ pro další vývoj. Tradice sdílení zdrojových souborů Unixového světa byla vždy nakloněna recyklování starších kódů (proto také GNU zvolil Unix jako svůj základní operační systém). Linux dovedl tuto tradici téměř k jejímu technologickému limitu. V jeho světě jsou přístupné terabyty volných zdrojů. Jestliže zde

22.2.2010 14:59

Zvon:


of open sources generally available. So spending time looking for some else's almost-good-enough is more likely to give you good results in the Linux world than anywhere else. And it did for me. With those I'd found earlier, my second search made up a total of nine candidates -fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail and upop. The one I first settled on was `fetchpop' by Seung-Hong Oh. I put my header-rewrite feature in it, and made various other improvements which the author accepted into his 1.9 release. A few weeks later, though, I stumbled across the code for `popclient' by Carl Harris, and found I had a problem. Though fetchpop had some good original ideas in it (such as its daemon mode), it could only handle POP3 and was rather amateurishly coded (Seung-Hong was a bright but inexperienced programmer, and both traits showed). Carl's code was better, quite professional and solid, but his program lacked several important and rather tricky-to-implement fetchpop features (including those I'd coded myself). Stay or switch? If I switched, I'd be throwing away the coding I'd already done in exchange for a better development base. A practical motive to switch was the presence of multiple-protocol support. POP3 is the most commonly used of the post-office server protocols, but not the only one. 4z6

hledáte téměř vyhovující program, máte větší šanci na úspěch než kdekoliv jinde. Obdobně vše fungovalo i v mém případě. Spolu s tím, co jsem nalezl již dříve, můj druhý průzkum odkryl celkem 9 kandidátů: fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail a upop. Nejdříve jsem se rozhodl pro `fetchpop' od Seung-Hong Oh. Vložil jsem do něho moji funkci na přepisování adres a učinil několik dalších změn, které autor později zařadil do verze 1.9. Několik týdnů později jsem ale narazil na zdroj programu `popclient', který napsal Carl Harris, a zjistil jsem, že stojím před problémem. Ačkoliv fetchpop obsahoval několik dobrých původních nápadů (například mód démon), dokázal pouze spravovat POP3 a byl programován poněkud amatérsky (Seung-Hong byl schopný, ale nezkušený programátor, a obě tyto charakteristiky se na kódu projevily). Carlův kód byl lepší, na profesionální úrovni a stabilní, ale jeho programu chybělo několik důležitých funkcí, které je celkem obtížné naprogramovat, včetně těch, které jsem programoval já sám. Zůstat při starém nebo volit změnu? Pokud bych se rozhodl pro změnu, musel bych obětovat všechen dosud napsaný kód, získal bych ale lepší vývojovou základnu. Praktickým argumentem, který doporučoval změnu, byla podpora řady protokolů. POP3 je nejběžněji používaný protokol, ale není jediný. Fetchpop a další podobné programy neuměly POP2, 22.2.2010 14:59

Zvon:


Fetchpop and the other competition didn't do POP2, RPOP, or APOP, and RPOP nebo APOP a já již začínal I was already having vague thoughts přemýšlet o přidání IMAPu of perhaps adding IMAP (Internet (nejnovějšího a nejvšestrannějšího Message Access Protocol, the most poštovního protokolu). recently designed and most powerful post-office protocol) just for fun. But I had a more theoretical reason Měl jsem ale i další, teoretický důvod, to think switching might be as good proč přemýšlet o změně. Bylo to něco, an idea as well, something I learned co jsem se naučil dlouho před Linuxem. long before Linux. 3. ``Plan to throw one away; you Počíteje s tím, že alespoň jednou will, anyhow.'' (Fred Brooks, ``The budete muset vše přepsat, stejně Mythical Man-Month'', Chapter vás to nemine ((Fred Brooks, ``The 11) Mythical Man-Month'', Chapter 11) Or, to put it another way, you often Nebo, řečeno jinými slovy, tak dlouho don't really understand the problem problému doopravdy neporozumíte, until after the first time you pokud se ho nepokusíte nějak vyřešit. implement a solution. The second Podruhé už budete možná vědět, jak na time, maybe you know enough to do to. Takže pokud chcete najít správné it right. So if you want to get it right, řešení, buďte připraveni začít alespoň be ready to start over at least once. jednou znovu. Well (I told myself) the changes to Dobře( řekl jsem si), úpravy fetchpopu fetchpop had been my first try. So I byly mým prvním pokusem a změnil switched. jsem programovou základnu. After I sent my first set of popclient Poté, co jsem 25. června 1996 poslal patches to Carl Harris on 25 June opravy popclienta Carl Harrisovi, zjistil 1996, I found out that he had jsem, že on sám již ve své podstatě basically lost interest in popclient ztratil o projekt zájem. Kód už byl some time before. The code was a bit trochu zaprášený a bylo v něm několik dusty, with minor bugs hanging out. drobných, snadno opravitelných chyb. I had many changes to make, and we Já potřeboval učinit řadu změn a tak quickly agreed that the logical thing jsme se rychle dohodli na tom, že for me to do was take over the projekt převezmu. program. Without my actually noticing, the Aniž jsem si to sám uvědomil, projekt project had escalated. No longer was nabral na tempu. Nepracoval jsem již I just contemplating minor patches to pouze na drobných změnách an existing POP client. I took on existujícího POP klienta. Převzal jsem maintaining an entire one, and there vývoj celého programu a v mé hlavě se were ideas bubbling in my head that rojily nápady, od kterých jsem očekával, I knew would probably lead to major že pravděpodobně povedou k velkým

5z6

22.2.2010 14:59

Zvon:


changes.

změnám.

In a software culture that encourages code-sharing, this is a natural way for a project to evolve. I was acting out this: 4. If you have the right attitude, interesting problems will find you. But Carl Harris's attitude was even more important. He understood that 5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor. Without ever having to discuss it, Carl and I knew we had a common goal of having the best solution out there. The only question for either of us was whether I could establish that I was a safe pair of hands. Once I did that, he acted with grace and dispatch. I hope I will act as well when it comes my turn.

Ve společenstvích programátorů, ve kterých je podporováno sdílení kódu, je takovýto vývoj projektu přirozený. Jednal jsem podle následujícího pravidla: 4. Pokud máte správný přístup, zajímavé problémy si Vás najdou sami. Ale přístup Carla Harrise byl ještě důležitější. Věděl že:

<<< TOC / OBSAH

6z6

5. Když ztratíte zájem o program, vaší poslední povinností je předat jej schopnému nástupci. Aniž jsme o tom museli diskutovat, Carl i já jsme věděli, že máme společný cíl, nalézt to nejlepší možné řešení. Jedinou otázkou pro oba zůstalo, jak prokázat, že jsem vhodný následovník. Jakmile se mi to podařilo, zachoval se úctyhodně, a přenechal mi své místo. Doufám, že budu jednat stejně, až přijde můj čas.


22.2.2010 14:59

Zvon:


<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T 3. The Importance of 3. Je důležité mít Having Users uživatele. And so I inherited popclient. Just as importantly, I inherited popclient's user base. Users are wonderful things to have, and not just because they demonstrate that you're serving a need, that you've done something right. Properly cultivated, they can become co-developers.

A tak jsem zdědil popclienta. Rovněž, a to bylo stejně důležité, jsem zdědil jeho uživatele. Mít uživatele, to je bezvadná věc, a nejen proto, že můžete prokázat, že děláte něco užitečného. Pokud si jich řádně hledíte, mohou se z nich stát vaši spolupracovníci. Další silnou stránkou tradice Unixu, Another strength of the Unix tradition, kterou Linux dotlačil až do extrému, one that Linux pushes to a happy je to, že mnoho uživatelů je zároveň extreme, is that a lot of users are programátory. Protože je zdrojový kód hackers too. Because source code is dostupný, mohou se i oni stát available, they can be effective efektivními hackery. To může být hackers. This can be tremendously neocenitelné pro zkrácení vývojového useful for shortening debugging time. cyklu. Pokud se jim dostane alespoň Given a bit of encouragement, your malého povzbuzení, vaši uživatelé users will diagnose problems, suggest naleznou problémy, navrhnou řešení a fixes, and help improve the code far pomohou vylepšit kód mnohem more quickly than you could unaided. rychleji, než vy sám bez jejich pomoci. 7. Pokud jednáte s uživateli jako 6. Treating your users as se spolupracovníky, je to ta co-developers is your least-hassle nejsnažší cesta k rychlému route to rapid code improvement vylepšení kódu a efektivnímu and effective debugging. odstraňování chyb. Sílu tohoto efektu je velmi snadné The power of this effect is easy to podcenit. Ve skutečnosti asi všichni z underestimate. In fact, pretty well all nás pohybujících se v otevřeném of us in the open-source world prostředí drasticky podceňovali, jak drastically underestimated how well it snadno je udržován systém v chodu would scale up with number of users při zvyšujícím se množství uživatelů a and against system complexity, until při jeho narůstající složitosti, dokud Linus Torvalds showed us differently. nám Linus Torvalds neukázal, jak na to.

1z3

22.2.2010 14:59

Zvon:


In fact, I think Linus's cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development model. When I expressed this opinion in his presence once, he smiled and quietly repeated something he has often said: `Ì'm basically a very lazy person who likes to get credit for things other people actually do.'' Lazy like a fox. Or, as Robert Heinlein might have said, too lazy to fail. In retrospect, one precedent for the methods and success of Linux can be seen in the development of the GNU Emacs Lisp library and Lisp code archives. In contrast to the cathedralbuilding style of the Emacs C core and most other FSF tools, the evolution of the Lisp code pool was fluid and very user-driven. Ideas and prototype modes were often rewritten three or four times before reaching a stable final form. And loosely-coupled collaborations enabled by the Internet, a la Linux, were frequent. Indeed, my own most successful single hack previous to fetchmail was probably Emacs VC mode, a Linux-like collaboration by email with three other people, only one of whom (Richard Stallman, the author of Emacs and founder of the FSF) I have met to this day. It was a front-end for SCCS, RCS and later CVS from within Emacs that offered `òne-touch'' version control operations. It evolved from a tiny, crude sccs.el mode somebody else had written. And the development of VC succeeded because, unlike Emacs itself, Emacs Lisp code could go through release/test/improve generations very quickly.

2z3

Ve skutečnosti se domnívám, že Linusů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 jeho přítomnosti, usmál se a tiše zopakoval něco, co často říká: "Já jsem ve skutečnosti velmi líný a rád jsem chválen za věci, které udělá někdo jiný". Líný jako liška. Nebo, jak by mohl říct Robert Heinlein, příliš líný na to, abych mohl selhat. Když se ohlédneme do minulosti, nalezneme zde precedens využivající metody Linuxu a to vývoj Lisp knihoven GNU Emacs a archívů Lisp kódů. Na rozdíl od katedrálního stylu práce na Emacs-C a většině ostatních FSF programů, vývoj Lisp zdrojů byl velmi 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. A volné spojení spolupracovníků přes Internet a la Linux bylo časté. Ovšem, i můj vlastní nejúspěšnější příspěvek před fetchmailem byl s velkou pravděpodobností Emacs VC mód, spolupráce se třemi dalšími lidmi ve stylu Linuxu, z nichž dodnes osobně znám pouze Richarda Stallmana FSF, autora Emacsu a zakladatele FSF. Jednalo se o front end pro SCCS, RCS a později CVS, pro které Emacs nabízel jednoduchou kontrolu 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 od samotného Emacsu, Lisp kód mohl velmi rychle procházet cykly publikuj/otestuj/vylepši .

22.2.2010 14:59

Zvon:


<<< TOC / OBSAH

3z3


22.2.2010 14:59

Zvon:


<<< TOC / OBSAH 4. Release Early, Release Often

>>> EN CS EN/CS ZVON P/T 4. Publikuj brzy, publikuj často

Early and frequent releases are a critical part of the Linux development model. Most developers (including me) used to believe this was bad policy for larger than trivial projects, because early versions are almost by definition buggy versions and you don't want to wear out the patience of your users. This belief reinforced the general commitment to a cathedral-building style of development. If the overriding objective was for users to see as few bugs as possible, why then you'd only release one every six months (or less often), and work like a dog on debugging between releases. The Emacs C core was developed this way. The Lisp library, in effect, was not -because there were active Lisp archives outside the FSF's control, where you could go to find new and development code versions independently of Emacs's release cycle. The most important of these, the Ohio State elisp archive, anticipated the spirit and many of the features of today's big Linux archives. But few of us really thought very hard about what we were doing, or about what the very existence of that archive suggested about problems in FSF's cathedralbuilding development model. I made one serious attempt around 1992 to get a lot of the Ohio code formally merged into the official Emacs Lisp library. I ran into political trouble and

1z7

Časné a časté publikování vykonané práce patří ke kritickým částem vývojového modelu Linuxu. Většina vývojářů, včetně mne, dříve věřila, že je to špatný postup pro všechny větší projekty, protože prvé verze mají téměř určitě řadu chyb a vy nechcete pokoušet trpělivost svých uživatelů. Tato víra posilovala obecnou důvěru ve styl stavění katedrál. Pokud bylo základní podmínkou, aby uživatelé viděli co nejméně chyb, pak je nejlepší publikovat maximálně jednou za půl roku a dřít do úmoru na odstraňování chyb v mezidobí. Emacs C byl vyvíjen tímto způsobem. Lisp knihovny ale vznikaly rozdílně. Jednalo se o aktivní archivy mimo kontrolu FSF, ve kterých jste mohli nalézt nové a experimentální verze i v obdobích, kdy samotný Emacs nebyl publikován. Nejdůležitější z těchto archívů, Ohio state elisp archív, vykazoval ducha a mnoho rysů dnešních velkých Linuxových archívů. Ale jen málo z nás tehdy opravdu důsledně přemýšlelo o tom, co děláme, nebo o tom, co samotná jejich existence naznačovala o problémech modelu stavitelů katedrál, který FSF využíval. V roce 1992 jsem se vážně pokoušel zahrnout velkou část Ohio archívu do oficiální Emacs Lisp knihovny, ale narazil jsem na řadu politických problémů a tento pokus

22.2.2010 15:00

Zvon:


was largely unsuccessful. But by a year later, as Linux became widely visible, it was clear that something different and much healthier was going on there. Linus's open development policy was the very opposite of cathedral-building. The sunsite and tsx-11 archives were burgeoning, multiple distributions were being floated. And all of this was driven by an unheard-of frequency of core system releases. Linus was treating his users as co-developers in the most effective possible way: 7. Release early. Release often. And listen to your customers. Linus's innovation wasn't so much in doing this (something like it had been Unix-world tradition for a long time), but in scaling it up to a level of intensity that matched the complexity of what he was developing. In those early times (around 1991) it wasn't unknown for him to release a new kernel more than once a day! Because he cultivated his base of co-developers and leveraged the Internet for collaboration harder than anyone else, this worked.

byl z velké části neúspěšný. Ale během roku, jak se Linux stával známým, bylo jasné, že probíhá něco jiného a mnohem zdravějšího. Linusova otevřená vývojová politika byla přesným protikladem výstavby katedrál. Sunsite a tsx-11 archívy překypovaly, byla rozšiřována řada distribucí. A to vše doprovázela předtím nevídaná frekvence publikací nových verzí jádra systému. Linus jednal se svými uživateli jako se spolupracovníky tím nejefektivnějším způsobem 7. Publikuj brzy. Publikuj často. A naslouchej svým zákazníkům. Linusova inovace nespočívala ani tak v tom, ž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 do rozměrů a složitosti samotného Linuxu. V této ranné epoše (okolo roku 1991), byly běžné publikace nového jádra i několikrát denně. Protože si kultivoval svoji základnu spolupracovníků a využíval Internet pro spolupráci více než kdokoliv jiný, tak vše pracovalo.

Ale jak to všechno mohlo pracovat? A bylo to něco, co jsem já sám mohl kopírovat nebo vše spočívalo na nenapodobitelné genialitě Linuse Torvalda? I didn't think so. Granted, Linus is a Já si to nemyslel. Je pravda, že Linus je damn fine hacker (how many of us zatraceně dobrý programátor, vždyť could engineer an entire production- kolik z nás by dokázalo vytvářet celé quality operating system kernel?). But jádro operačního systému v produkční Linux didn't represent any awesome kvalitě? Ale Linux nepředstavoval conceptual leap forward. Linus is not žádný ohromný koncepční skok vpřed. (or at least, not yet) an innovative Linus není, tedy alespoň zatím, But how did it work? And was it something I could duplicate, or did it rely on some unique genius of Linus Torvalds?

2z7

22.2.2010 15:00

Zvon:


genius of design in the way that, say, Richard Stallman or James Gosling (of NeWS and Java) are. Rather, Linus seems to me to be a genius of engineering, with a sixth sense for avoiding bugs and development dead-ends and a true knack for finding the minimum-effort path from point A to point B. Indeed, the whole design of Linux breathes this quality and mirrors Linus's essentially conservative and simplifying design approach. So, if rapid releases and leveraging the Internet medium to the hilt were not accidents but integral parts of Linus's engineering-genius insight into the minimum-effort path, what was he maximizing? What was he cranking out of the machinery? Put that way, the question answers itself. Linus was keeping his hacker/users constantly stimulated and rewarded -- stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement in their work. Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this:

inovační genius designu, takový, jako je třeba Richard Stallman nebo James Gosling (NeWS, Java). Linus má spíše inženýrský génius, má šestý smysl pro obchá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 ve své podstatě konzervativní a zjednodušující přístup.

Takže, pokud rychlé publikování a využívání Internetu nebylo náhodné, ale představovalo integrální součást Linusova inženýrského genia pro nalezení nejsnažší cesty, co se snažil maximalizovat? Co dostával z celého soustrojí? Pokud je otázka položena takto, sama nabízí odpověď. Linus udržoval své uživatele/spoluautory neustále stimulované a odměňované. Stimulované tím, že mají neustále před sebou nějakou uspokující práci, odměňované tím, že vidí neustálá (dokonce denní) vylepšení své práce. Linus se pokoušel maximalizovat počet hodin, které jsou věnovány na odstraňování chyb a na rozvoj, ačkoliv hrozilo možné riziko nestability kódu a vyhoření uživatelské báze, pokud by se nějaká vážná chyba ukázala neodstranitelnou.Linus se choval tak, jako by věřil v něco jako: 8. Pokud máte dostatečně velkou 8. Given a large enough beta-tester základnu spolupracovníků a and co-developer base, almost testovatelů, téměř každý problém every problem will be characterized bude rychle charakterizován a jeho quickly and the fix obvious to řešení bude pro někoho someone. jednoduché

3z7

22.2.2010 15:00

Zvon:


Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.

Nebo, méně formálně "Pokud máte dostatek očí, všechny chyby jsou průhledné". Já to nazývám Linusovým zákonem.

My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, `ànd somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.'' But the point is that both things tend to happen quickly.

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

V tom je, myslím, základní rozdíl mezi stylem stavitelů katedrál a stylem tržiště. Z pohledu stavitelů katedrál, programové chyby a vývojové problémy jsou náročné a komplikované jevy. Trvá měsíce pečlivého zkoumání několika zasvěcených, než získáte jistotu, že jste vše vyhladili. Proto dlouhé intervaly mezi publikacemi a nevyhnutelná zklamání, že dlouho očekávaný program není zdaleka dokonalý. In the bazaar view, on the other hand, Z pohledu tržiště naopak you assume that bugs are generally předpokládáte, že chyby jsou obvykle shallow phenomena -- or, at least, that snadno řešitelné, nebo alepoň, že se they turn shallow pretty quick when takovými rychle stanou, když se na ně exposed to a thousand eager zaměří tisíce dychtivých co-developers pounding on every spolupracovníků, nedočkavě single new release. Accordingly you očekávajících další verzi. Proto release often in order to get more publikujete často, abyste získali více corrections, and as a beneficial side oprav a jako prospěšný vedlejší efekt effect you have less to lose if an ztrácíte méně, pokud občas dojde k occasional botch gets out the door. nějakému problému. Here, I think, is the core difference underlying the cathedral-builder and bazaar styles. In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.

4z7

22.2.2010 15:00

Zvon:


And that's it. That's enough. If ``Linus's Law'' is false, then any system as complex as the Linux kernel, being hacked over by as many hands as the Linux kernel, should at some point have collapsed under the weight of unforseen bad interactions and undiscovered ``deep'' bugs. If it's true, on the other hand, it is sufficient to explain Linux's relative lack of bugginess. And maybe it shouldn't have been such a surprise, at that. Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than that of a single randomly-chosen one of the observers. They called this the ``Delphi effect''. It appears that what Linus has shown is that this applies even to debugging an operating system -- that the Delphi effect can tame development complexity even at the complexity level of an OS kernel.

A to je vše. To opravdu stačí. Pokud je "Linusův zákon" nepravdivý, potom jakýkoliv systém tak komplexní, jako je jádro Linuxu, na kterém se spolupodílelo tolik autorů, by se musel v nějaký okamžik zhroutit pod tíhou nepředvídaných špatných interakcí a nenalezených, hluboko ukrytých chyb. Pokud je ale pravdivý, pak postačuje na vysvětlení, proč Linux obsahuje tak málo programových chyb. A možná by to ani nemělo být takové překvapení. Sociologové již před lety objevili, že průměrný názor velkého množství stejně dobrých (nebo špatných) pozorovatelů je podstatně spolehlivější než názor jakékohokoliv náhodně zvoleného pozorovatele. To se nazývá Delphi efektem. Zdá se, že Linus prokázal, že tento jev se týká i tvorby operačního systému, že Delphi efekt dokáže zkrotit i tak komplexní záležitost, jako je konstrukce jádra OS..

Jsem vděčen Jeffovi Dutky I am indebted to Jeff Dutky , který for pointing upozornil na to, že Linusův zákon out that Linus's Law can be rephrased může být přeložen jako "debugování je as ``Debugging is parallelizable''. Jeff paralelizovatelné". Jeff si všiml, že observes that although debugging ačkoliv odstraňování chyb vyžaduje, requires debuggers to communicate aby jednotliví spolupracovnící with some coordinating developer, it komunikovali s nějakým doesn't require significant koordinátorem, nevyžaduje významnou coordination between debuggers. Thus spolupráci mezi jednotlivými it doesn't fall prey to the same spolupracovníky. Proto nepadá za oběť quadratic complexity and kvadratickému zvyšování komplexity a management costs that make adding nárokům na administraci, která v developers problematic. jiných případech znesnadňuje zapojení více vývojářů. In practice, the theoretical loss of Ve skutečnosti se teoretická ztráta efficiency due to duplication of work účinnosti způsobená duplikací práce by debuggers almost never seems to nezdá být problémem ve světě Linuxu. 5z7

22.2.2010 15:00

Zvon:


be an issue in the Linux world. One Jeden z výsledků časného a častého effect of a ``release early and often publikování je fakt, že případné policy'' is to minimize such duplication duplikace jsou brzy odhaleny. by propagating fed-back fixes quickly. Brooks even made an off-hand observation related to Jeff's: ``The Brooks dokonce učinil následující total cost of maintaining a widely used pozorování: "Celková cena údržby program is typically 40 percent or běžně používaného programu je okolo more of the cost of developing it. 40 % nebo i více z ceny jeho vývoje. Je Surprisingly this cost is strongly překvapující, že tato cena je značně affected by the number of users. More ovlivněna počtem uživatelů. Více users find more bugs.'' (my uživatelů nalezne více chyb. emphasis). More users find more bugs because adding more users adds more Více uživatelů nalezne více chyb, different ways of stressing the neboť s počtem uživatelů přibývá program. This effect is amplified when způsobů, kterým jsou programy the users are co-developers. Each one testovány. Tento efekt je zesílen, approaches the task of bug pokud se uživatelé zároveň podílejí na characterization with a slightly vývoji programu. Každý z nich vnímá different perceptual set and analytical problémy při detekci chyb z jiného toolkit, a different angle on the úhlu pohledu. Delphi efekt funguje, problem. The ``Delphi effect'' seems to jak se zdá, právě díky této work precisely because of this rozmanitosti. Ve specifickém kontextu variation. In the specific context of odhalování chyb tento styl rovněž debugging, the variation also tends to snižuje množství duplikátních činností. reduce duplication of effort. So adding more beta-testers may not reduce the complexity of the current Takže s přibývajícím počtem ``deepest'' bug from the developer's testovatelů se sice nemusí zmenšit point of view, but it increases the komplexita té nejobtížnější chyby z probability that someone's toolkit will pohledu vývojáře, ale stoupá šance, že be matched to the problem in such a někomu jinému se podaří chybu way that the bug is shallow to that odhalit. person. Linus coppers his bets, too. In case Linus je také obezřetný. V případě, že there are serious bugs, Linux kernel se vyskytnou vážné problémy, version are numbered in such a way Linuxové jádro je číslováno takovým that potential users can make a choice způsobem, že potenciální uživatel either to run the last version může buďto používat poslední verzi, designated ``stable'' or to ride the která je označena jako stabilní, a nebo cutting edge and risk bugs in order to sledovat vývoj a mít nové možnosti, ale get new features. This tactic is not yet to vše za cenu rizika chyb v programu. 6z7

22.2.2010 15:00

Zvon:


formally imitated by most Linux Tuto taktiku ještě neuplatňuje většina hackers, but perhaps it should be; the Linuxových hackerů, ale asi by měla. fact that either choice is available Dostupnost obou alternativ přispívá k makes both more attractive. atraktivitě programu..

<<< TOC / OBSAH

7z7


22.2.2010 15:00

Zvon:


<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T 5. When Is A Rose Not A 5. Když růže není růží Rose? Having studied Linus's behavior and Poté, co jsem studoval Linusovo formed a theory about why it was chování a zformuloval teorii, proč successful, I made a conscious decision to bylo úspěšné, vědomě jsem se test this theory on my new (admittedly rozhodl tuto teorii otestovat na much less complex and ambitious) mém vlastním (ačkoliv zdaleka ne project. tak komplexním) projektu. Ale první věc, kterou jsem učinil, But the first thing I did was reorganize byla reorganizace a zjednodušení and simplify popclient a lot. Carl Harris's popclienta. Carlova implementace implementation was very sound, but byla velmi rozumná, ale vykazovala exhibited a kind of unnecessary nepotřebnou složitost, která je complexity common to many C běžná u mnoha C programátorů. programmers. He treated the code as Považoval kód za jádro a strukturu central and the data structures as support dat jako podporu pro kód. for the code. As a result, the code was Výsledkem bylo, že kód byl beautiful but the data structure design nádherný, ale struktura dat ad-hoc and rather ugly (at least by the náhodná a dosti ošklivá (alespoň high standards of this old LISP hacker). podle vysokého standardu tohoto zkušeného LISP hackera). I had another purpose for rewriting K přepisování jsem měl i další besides improving the code and the data důvod než vylepšení kódu a structure design, however. That was to datových struktur. Potřeboval jsem evolve it into something I understood program zcela pochopit. Není to completely. It's no fun to be responsible žádná legrace, opravovat chyby v for fixing bugs in a program you don't programu, kterému nerozumíte. understand. For the first month or so, then, I was Během prvého měsíce jsem se simply following out the implications of držel základního Carlova plánu. Carl's basic design. The first serious První vážnou změnou bylo přidání change I made was to add IMAP support. I protokolu IMAP. To jsem učinil tak, did this by reorganizing the protocol že jsem program rozčlenil na machines into a generic driver and three obecnou část a specifické metody. method tables (for POP2, POP3, and Toto a předchozí změny ilustrují IMAP). This and the previous changes obecný princip, kterého by se měli illustrate a general principle that's good programátoři přidržovat, zejména for programmers to keep in mind, pak v jazycích, jako je C. especially in languages like C that don't 1z3

22.2.2010 15:01

Zvon:


naturally do dynamic typing: 9. Promyšlené datové struktury 9. Smart data structures and dumb a průměrný kód fungují code works a lot better than the other mnohem lépe než při obrácené way around. konfiguraci Brooks, kapitola 9: Ukaž mi svůj Brooks, Chapter 9: ``Show me your [code] [kód] a skryj [datové struktury] a and conceal your [data structures], and I nebudu rozumět. Ukaž mi [datové shall continue to be mystified. Show me struktury] a obyčejně nebudu your [data structures], and I won't usually potřebovat tvůj [kód], většinou mi need your [code]; it'll be obvious.'' bude jasný. Actually, he said ``flowcharts'' and Ve skutečnosti řekl diagramy a ``tables''. But allowing for thirty years of tabulky. Ale po 30 letech terminological/cultural shift, it's almost kulturních a terminologických the same point. změn to znamená téměř to samé. V tu dobui (začátek září 1996, asi At this point (early September 1996, 6 týdnů od času nula) jsem začal about six weeks from zero) I started přemýšlet o změně jména. Konec thinking that a name change might be in konců, už to nebyl jenom POP order -- after all, it wasn't just a POP klient. Ale váhal jsem, protože client any more. But I hesitated, because dosud v programu nebylo nic there was as yet nothing genuinely new in opravdu původního. Moje verze the design. My version of popclient had popclienta si teprve musela yet to develop an identity of its own. vytvořit vlastní identitu. Vše se změnilo velmi radikálně, That changed, radically, when fetchmail když se fetchmail naučil learned how to forward fetched mail to přesměrovávat poštu na SMTP the SMTP port. I'll get to that in a port. K tomu se dostanu za moment. But first: I said above that I'd okamžik. Jak jsem se již zmínil, decided to use this project to test my rozhodl jsem se použít svůj projekt theory about what Linus Torvalds had jako test toho, co Linus Torvalds done right. How (you may well ask) did I udělal dobře. Jak jsem tedy do that? In these ways: testoval? Takto: I released early and often (almost never Publikoval jsem časně a často, less often than every ten days; during téměř vždy alespoň jednou za 10 periodsof intense development, once a dnů, při intenzivní práci jednou day). denně I grew my beta list by adding to it Zvětšoval jsem seznam testerů o everyone who contacted me about každého, kdo mne kontaktoval fetchmail. ohledně fetchmailu

2z3

22.2.2010 15:01

Zvon:


I sent chatty announcements to the beta list whenever I released, encouraging people to participate.

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

And I listened to my beta testers, polling them about design decisions and stroking them whenever they sent in patches and feedback.

A naslouchal jsem jim, dával si od nich schvalovat rozhodnutí a chválil je, když mi poslali nějakou opravu nebo komentář. Tato jednoduchá opatření se vyplatila téměř okamžitě. Od začátku projektu jsem dostával hlášení o chybách ve kvalitě, pro kterou by většina vývojářů byla schopna zabít, a často bylo přiloženo i dobré řešení. Dostával jsem poštu, kterou byla zábava číst, promyšlenou kritiku a rozumné návrhy na nové možnosti. Takže: 10. Pokud zacházíte s Vašimi testovateli, jako by byli vaším nejcennějším kapitálem, oni se vaším nejcennějším kapitálem skutečně stanou. Jedno zajímavé měřítko úspěchu fetchmailu je velikost seznamu testovatelů, přátel fetchmailu. V době, kdy tento text píši, má 249 členů a dva až tři členové přibývají každý týden. Ve skutečnosti, při revizi na konci května 1997 tento seznam již ztrácí ze svého maximálního počtu téměř 300 členů ze zajímavého důvodu. Několik lidí mne požádalo, abych je odhlásil ze seznamu, protože fetchmail už pracuje tak dobře, že nepotřebují sledovat, co je nového. Možná to patří k normálnímu životnímu cyklu vyspělého projektu ve stylu tržiště.

The payoff from these simple measures was immediate. From the beginning of the project, I got bug reports of a quality most developers would kill for, often with good fixes attached. I got thoughtful criticism, I got fan mail, I got intelligent feature suggestions. Which leads to:

10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. One interesting measure of fetchmail's success is the sheer size of the project beta list, fetchmail-friends. At time of writing it has 249 members and is adding two or three a week. Actually, as I revise in late May 1997 the list is beginning to lose members from its high of close to 300 for an interesting reason. Several people have asked me to unsubscribe them because fetchmail is working so well for them that they no longer need to see the list traffic! Perhaps this is part of the normal life-cycle of a mature bazaar-style project.

<<< TOC / OBSAH 3z3

>>> EN CS EN/CS ZVON P/T 22.2.2010 15:01

Zvon:


<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T 6. Popclient becomes 6. Popclient se stává Fetchmail fetchmailem The real turning point in the project was when Harry Hochheiser sent me his scratch code for forwarding mail to the client machine's SMTP port. I realized almost immediately that a reliable implementation of this feature would make all the other delivery modes next to obsolete. For many weeks I had been tweaking fetchmail rather incrementally while feeling like the interface design was serviceable but grubby -- inelegant and with too many exiguous options hanging out all over. The options to dump fetched mail to a mailbox file or standard output particularly bothered me, but I couldn't figure out why. What I saw when I thought about SMTP forwarding was that popclient had been trying to do too many things. It had been designed to be both a mail transport agent (MTA) and a local delivery agent (MDA). With SMTP forwarding, it could get out of the MDA business and be a pure MTA, handing off mail to other programs for local delivery just as sendmail does. Why mess with all the complexity of configuring a mail delivery agent or setting up lock-and-append on a mailbox when port 25 is almost guaranteed to be there on any platform with TCP/IP support in the first place? Especially when this means retrieved mail is guaranteed to look like normal sender-initiated SMTP mail, which is really what we want 1z5

Skutečně klíčovým okamžikem v projektu byl okamžik, když mi Harry Hochheiser poslal svůj návrh kódu pro přesměrování pošty na SMPT počítače klienta. Já si téměř okamžitě uvědomil, že spolehlivá implementace této funkce učiní ostatní způsoby doručení zastaralé. Mnoho týdnů jsem měnil fetchmail spíše po částech a cítil jsem, že uživatelské rozhraní slouží svému účelu, ale je nepříjemné a neelegantní. Zejména záplava nastavení pro export stažené pošty do souboru nebo na standardní výstup mě obzvláště tížila, ale já nevěděl proč. Když jsem přemýšlel o SMPT přesměrování, tak se ukazovalo, že popclient se pokoušel dělat příliš mnoho věcí. Byl navržen zároveň jako mail transport agent (MTA) a local delivery agent (MDA). S SMTP přesměrováním se z něj mohl stát čistý MTA a předávat poštu jiným programům, tak jak to dělá sendmail.

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

22.2.2010 15:01

Zvon:


anyway. There are several lessons here. First, this SMTP-forwarding idea was the biggest single payoff I got from consciously trying to emulate Linus's methods. A user gave me this terrific idea -- all I had to do was understand the implications. 11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. Interestingly enough, you will quickly find that if you are completely and self-deprecatingly truthful about how much you owe other people, the world at large will treat you like you did every bit of the invention yourself and are just being becomingly modest about your innate genius. We can all see how well this worked for Linus! (When I gave this paper at the Perl conference in August 1997, Larry Wall was in the front row. As I got to the last line above he called out, religiousrevival style, ``Tell it, tell it, brother!''. The whole audience laughed, because they knew it had worked for the inventor of Perl too.) After a very few weeks of running the project in the same spirit, I began to get similar praise not just from my users but from other people to whom the word leaked out. I stashed away some of that email; I'll look at it again sometime if I ever start wondering whether my life has been worthwhile :-). But there are two more fundamental, non-political lessons here that are

2z5

Zde se můžeme naučit několik lekcí. Zaprvé, nápad se SMPT, to byla největší odměna za to, že jsem se pokoušel napodobit Linusovi metody. Tento skvělý nápad mi poskytl jeden z uživatelů, já pouze musel pochopit jeho důsledky. 11. Skoro stejně důležité, jako mít dobré nápady, je schopnost rozeznat dobré nápady vašich uživatelů. Občas je to druhé dokonce lepší. Je zajímavé, že pokud jste opravdu k sobě upřímní, rychle zjistíte, jak mnoho dlužíte ostatním lidem, ačkoliv okolní svět vás bude považovat za původce všeho. Vy sami pak následkem toho začnete být skromnější v pohledu na vlastní schopnosti a Linus je toho dokonalým příkladem. (Když jsem tento článek četl na konferenci o Perlu v roce 1997, Larry Wall seděl v řadě přede mnou. Když jsem se dostal k řádkům výše uvedeným, zavolal hlasem starých kazatelů "Jen to řekni, řekni bratře!". Celé publikum se smálo, protože vědělo, že vše fungovalo stejně i v případě vynálezce Perlu. Jen několik málo týdnů po té, co jsem projekt rozběhl, jsem začal získávat podobnou chválu nejen od uživatelů, ale i od dalších lidí, ke kterým se zpráva donesla. Schoval jsem si některé e-maily. Podívám se ně, jestli někdy budu pochybovat, že můj život má smysl. Jsou zde ovšem ještě dvě základnější, nepolitické lekce, které jsou společné

22.2.2010 15:01

Zvon:

3z5


general to all kinds of design.

veškerému designu.

12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. I had been trying to solve the wrong problem by continuing to develop popclient as a combined MTA/MDA with all kinds of funky local delivery modes. Fetchmail's design needed to be rethought from the ground up as a pure MTA, a part of the normal SMTP-speaking Internet mail path. When you hit a wall in development -when you find yourself hard put to think past the next patch -- it's often time to ask not whether you've got the right answer, but whether you're asking the right question. Perhaps the problem needs to be reframed. Well, I had reframed my problem. Clearly, the right thing to do was (1) hack SMTP forwarding support into the generic driver, (2) make it the default mode, and (3) eventually throw out all the other delivery modes, especially the deliver-to-file and deliver-to-standard-output options. I hesitated over step 3 for some time, fearing to upset long-time popclient users dependent on the alternate delivery mechanisms. In theory, they could immediately switch to .forward files or their non-sendmail equivalents to get the same effects. In practice the transition might have been messy. But when I did it, the benefits proved huge. The cruftiest parts of the driver code vanished. Configuration got radically simpler -- no more grovelling around for the system MDA and user's mailbox, no more worries about

12. Často to nejzajímavější a nejoriginálnější řešení se zrodí z toho, že si uvědomíte, že vaše chápání problému bylo mylné. Já se pokoušel vyřešit nesprávný problém tím, že jsem chtěl popclienta jako kombinovaný MTA/MDA. Fetchmail musel být znovu koncipován od základu jako čistý MTA, součást normálního SMTP. 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 jestli kladete správnou otázku. Možná je třeba problém reformulovat. Já jsem tedy problém reformuloval. Je jasné, že správné bylo 1. přenést podporu SMTP do generického driveru, 2. učinit z něj výchozí mód a 3. nakonec přestat podporovat ostatní možnosti přenosu. 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ěchto mechanismech. Teoreticky jim stačilo přejít na .forward soubory nebo jejich ne-sendmail alternativy, aby získali to, co potřebují. Ve skutečnosti však mohl být tento přechod komplikovaný. Ale když jsem to učinil, zisk byl ohromný. Nejpracnější část kódu zmizela. Konfigurace byla mnohem jednodušší, už žádné starosti o MDA uživatele a jeho poštovní schránku. Žádné starosti s tím, jestli operační

22.2.2010 15:01

Zvon:


whether the underlying OS supports file locking.

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

Also, the only way to lose mail vanished. If you specified delivery to a Rovněž zmizelo jediné riziko ztráty file and the disk got full, your mail got pošty. Pokud jste určili za příjemce lost. This can't happen with SMTP pošty soubor a disk se zaplnil, poštu forwarding because your SMTP listener jste ztratili. Se SMTP se to stát won't return OK unless the message nemůže. can be delivered or at least spooled for later delivery. Also, performance improved (though not so you'd notice it in a single run). Zlepšila se i rychlost a významné bylo Another not insignificant benefit of i zjednodušení manuálu. this change was that the manual page got a lot simpler. Later, I had to bring delivery via a user-specified local MDA back in order Později jsem musel doplnit některé to allow handling of some obscure nestandardní podmínky, ale to už bylo situations involving dynamic SLIP. But I mnohem jednodušší. found a much simpler way to do it. The moral? Don't hesitate to throw Morální poučení? Neváhejte se away superannuated features when rozloučit se vším, co vám nezvyšuje you can do it without loss of efektivitu. Antoine de Saint-Exupery effectiveness. Antoine de Saint-Exupery (což byl letec a letecký konstruktér, (who was an aviator and aircraft když nepsal klasické dětské knihy) designer when he wasn't being the řekl: author of classic children's books) said: 13. ``Perfection (in design) is achieved 13. Konstrukční dokonalosti není not when there is nothing more to add, dosaženo tehdy, když už není co but rather when there is nothing more přidat, ale tehdy, když už to take away.'' nemůžete nic odebrat. When your code is getting both better and simpler, that is when you know it's Když se Váš kód zároveň zlepšuje a right. And in the process, the stává jednodušším, potom víte, že jste fetchmail design acquired an identity na správné cestě. of its own, different from the ancestral popclient. It was time for the name change. The Nastal čas pro změnu jména. Nový new design looked much more like a program vypadal mnohem více jako dual of sendmail than the old popclient dvojník sendmailu než starý had; both are MTAs, but where popclient, a tak jsem jej po dvou sendmail pushes then delivers, the new měsících přejmenoval na fetchmail. 4z5

22.2.2010 15:01

Zvon:


popclient pulls then delivers. So, two months off the blocks, I renamed it fetchmail.

<<< TOC / OBSAH

5z5


22.2.2010 15:01

Zvon:


<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T 7. Fetchmail Grows Up 7. Fetchmail dospívá There I was with a neat and innovative design, code that I knew worked well because I used it every day, and a burgeoning beta list. It gradually dawned on me that I was no longer engaged in a trivial personal hack that might happen to be useful to few other people. I had my hands on a program every hacker with a Unix box and a SLIP/PPP mail connection really needs. With the SMTP forwarding feature, it pulled far enough in front of the competition to potentially become a ``category killer'', one of those classic programs that fills its niche so competently that the alternatives are not just discarded but almost forgotten. I think you can't really aim or plan for a result like this. You have to get pulled into it by design ideas so powerful that afterward the results just seem inevitable, natural, even foreordained. The only way to try for ideas like that is by having lots of ideas -- or by having the engineering judgment to take other peoples' good ideas beyond where the originators thought they could go. Andrew Tanenbaum had the original idea to build a simple native Unix for the 386, for use as a teaching tool. Linus Torvalds pushed the Minix concept further than Andrew probably thought it could go -- and it grew into something wonderful. In the same way (though on a smaller

1z4

V ruce jsem měl uspořádanou a originální konstrukci, kód, o kterém jsem věděl, že funguje, neboť jsem ho používal každý den a rostoucí seznam testovatelů. Postupně mi docházelo, že už se nezabývám programováním něčeho jednoduchého, co může být užitečné pro několik dalších lidí. Měl jsem v rukou program, který potřebuje každý hacker s Unixem a SLIP/PPP poštovním připojením. Se SMTP přesměrováním se fetchmail dostal daleko do čela konkurence a stal se potenciálním vládcem kategorie, takovým, který vyplní svůj prostor tak dokonale, že alternativy nejsou pouze odmítnuty, ale i téměř zapomenuty. Myslím si, že takový výsledek skutečně nemůžete plánovat. Musí Vás k němu dovést vývojový plán tak silný, že při zpětném pohledu se zdají výsledky nevyhnutelné, téměř předpověditelné. Jedinou možností, jak dostat takový nápad, je mít mnoho nápadů, nebo mít inženýrský úsudek a dovést nápady někoho jiného až za hranici toho, co si autor původní myšlenky dokázal představit. Andrew Tanenbaum přišel s původní myšlenkou vystavět jednoduchý Unix pro 386 jako učební pomůcku. Linus Torvalds dotáhl koncept Minixu dále, než si zřejmě Andrew mohl představit a vzniklo z něj něco úžasného. Stejným způsobem (ačkoliv v menším měřítku), jsem převzal nápady Carl Harrise a

22.2.2010 15:01

Zvon:


scale), I took some ideas by Carl Harris and Harry Hochheiser and pushed them hard. Neither of us was òriginal' in the romantic way people think is genius. But then, most science and engineering and software development isn't done by original genius, hacker mythology to the contrary. The results were pretty heady stuff all the same -- in fact, just the kind of success every hacker lives for! And they meant I would have to set my standards even higher. To make fetchmail as good as I now saw it could be, I'd have to write not just for my own needs, but also include and support features necessary to others but outside my orbit. And do that while keeping the program simple and robust. The first and overwhelmingly most important feature I wrote after realizing this was multidrop support -- the ability to fetch mail from mailboxes that had accumulated all mail for a group of users, and then route each piece of mail to its individual recipients. I decided to add the multidrop support partly because some users were clamoring for it, but mostly because I thought it would shake bugs out of the single-drop code by forcing me to deal with addressing in full generality. And so it proved. Getting RFC 822 parsing right took me a remarkably long time, not because any individual piece of it is hard but because it involved a pile of interdependent and fussy details.

2z4

Harry Hochheisera a dotáhl jsem je do konce. Vždyť většina vědy, inženýrství a softwarového vývoje není vytvářena nějakým originálním geniem, ač to hackerské bájesloví tvrdí.

Výsledky byly přesto fantastické, ve skutečnosti to byl právě takový úspěch, po kterém každý hacker touží. A to znamenalo, že si musím sám pro sebe nastavit ještě náročnější kritéria. Abych učinil fetchmail tak dobrý, jak jen jsem si byl schopen představit, musel jsem psát nejen pro své vlastní potřeby, ale rovněž zahrnout podporu, kterou jsem nepotřeboval sám, ale jiní uživatelé. A při tom všem jsem musel udržet program jednoduchý a stabilní. První a zdaleka nejdůležitější funkcí, kterou jsem přidal poté, co jsem si vše uvědomil, byla podpora vícenásobného stahování, možnost stáhnout poštu z poštovních schránek, které obsahovali poštu více uživatelů a poté ji distribuovat jednotlivým příjemcům.

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 a objevit chyby, které ve snaze napsat mnohem obecnější postup vyplavou na povrch.

22.2.2010 15:01

Zvon:


But multidrop addressing turned out Ukázalo se, že se také jednalo a to be an excellent design decision as výborné konstrukční rozhodnutí. well. Here's how I knew: 14. Any tool should be useful in the 14. Jakýkoliv nástroj by měl být expected way, but a truly great tool užitečný očekávaným způsobem, ale lends itself to uses you never opravdu velké nástroje se hodí na expected. použití, které jste nikdy neočekával The unexpected use for multi-drop fetchmail is to run mailing lists with the list kept, and alias expansion done, on the client side of the Tak tento přepsaný fetchmail byl SLIP/PPP connection. This means neočekávaně využit při správě someone running a personal machine diskuzních skupin. through an ISP account can manage a mailing list without continuing access to the ISP's alias files. Another important change demanded Další důležitou změnou, kterou ode by my beta testers was support for mne požadovali moji testovatelé, byla 8-bit MIME operation. This was pretty podpora 8-bit MIME. To bylo docela easy to do, because I had been careful snadné, neboť jsem si dával pozor, to keep the code 8-bit clean. Not abych nijak nepozměnil 8 bit. Nebylo to because I anticipated the demand for proto, že bych předvídal tento this feature, but rather in obedience požadavek, spíše jsem se řídil dalším to another rule: pravidlem: 15. When writing gateway software 15. Pokud píšete of any kind, take pains to disturb zprostředkovatelský software the data stream as little as jakéhokoliv druhu, snažte se vlastní possible -- and *never* throw away data nijak neměnit a nikdy se information unless the recipient nezbavujte žádné informace, pokud forces you to! vás k tomu nedonutí příjemce. Had I not obeyed this rule, 8-bit Kdybych se tímto neřídil, podpora MIME support would have been 8-bitového MIME by byla obtížná a s difficult and buggy. As it was, all I chybami. Takto mi stačilo přečíst si had to do is read RFC 1652 and add a standard a přidat něco triviální logiky trivial bit of header-generation logic. při generaci hlaviček. Some European users bugged me into Někteří evropští uživatelé mne adding an option to limit the number přemlouvali, abych přidal omezení of messages retrieved per session (so počtu vzkazů stáhnutelných při jednom they can control costs from their sezení (aby mohli kontrolovat cenu expensive phone networks). I resisted svých drahých telefonních linek). this for a long time, and I'm still not Dlouho jsem tomu vzdoroval a stále s entirely happy about it. But if you're tím nejsem zcela spokojen. Pokud ale

3z4

22.2.2010 15:01

Zvon:


writing for the world, you have to píšete pro celý svět, musíte naslouchat listen to your customers -- this doesn't svým zákazníkům, to se nemění jenom change just because they're not proto, že nejste placen penězi. paying you in money.

<<< TOC / OBSAH

4z4


22.2.2010 15:01

Zvon:


<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T 8. A Few More Lessons 8. Několik dalších lekcí From Fetchmail z fetchmailu Before we go back to general Než se vrátíme k obecným problémům software-engineering issues, there are softwarového inženýrství, je třeba se a couple more specific lessons from poučit z několika specifických lekcí, the fetchmail experience to ponder. které přinesl fetchmail. The rc file syntax includes optional Rc syntax zahrnuje nepovinný `noise' keywords that are entirely parametr 'noise', které parser zcela ignored by the parser. The ignoruje. Takováto anglicky znějící English-like syntax they allow is syntax je mnohem čitelnější než considerably more readable than the tradiční zhuštěné páry traditional terse keyword-value pairs parametr=hodnota. you get when you strip them all out. These started out as a late-night Toto začalo jako noční experiment, experiment when I noticed how much když jsem si všiml, jak mnoho the rc file declarations were beginning deklarace rc souborů připomínají to resemble an imperative příkazový minimalistický jazyk. (Proto minilanguage. (This is also why I jsem také změnil jeden z původních changed the original popclient `server' parametrů popclienta "server" na keyword to `poll'). "poll") It seemed to me that trying to make Zdálo se mi, že pokud tento jazyk that imperative minilanguage more bude více připomínat angličtinu, bude like English might make it easier to snáze použitelný. Ačkoliv jsem use. Now, although I'm a convinced přesvědčený zastánce designerské partisan of the ``make it a language'' školy, která se snaží učinit z příkazů school of design as exemplified by jazyk, jako v případě HTML, Emacsu a Emacs and HTML and many database řady databází, obvykle nemám příliš engines, I am not normally a big fan of rád poangličtělou syntax. `Ènglish-like'' syntaxes. Traditionally programmers have tended to favor control syntaxes that Tradičně programátoři dávají přednost are very precise and compact and have syntaxi, která je velmi přesná a no redundancy at all. This is a cultural kompaktní. Toto je dědictví z doby, kdy výpočetní zdroje byly drahé, takže legacy from when computing resources were expensive, so parsing procházení souborů muselo být levné a stages had to be as cheap and simple co nejjednodušší. Tehdy se zdála angličtina s 50% přebytkem slov zcela as possible. English, with about 50% nevhodná. redundancy, looked like a very

1z3

22.2.2010 15:02

Zvon:


inappropriate model then. This is not my reason for normally avoiding English-like syntaxes; I mention it here only to demolish it. With cheap cycles and core, terseness should not be an end in itself. Nowadays it's more important for a language to be convenient for humans than to be cheap for the computer. There are, however, good reasons to be wary. One is the complexity cost of the parsing stage -- you don't want to raise that to the point where it's a significant source of bugs and user confusion in itself. Another is that trying to make a language syntax English-like often demands that the `Ènglish'' it speaks be bent seriously out of shape, so much so that the superficial resemblance to natural language is as confusing as a traditional syntax would have been. (You see this in a lot of so-called ``fourth generation'' and commercial database-query languages.) The fetchmail control syntax seems to avoid these problems because the language domain is extremely restricted. It's nowhere near a generalpurpose language; the things it says simply are not very complicated, so there's little potential for confusion in moving mentally between a tiny subset of English and the actual control language. I think there may be a wider lesson here: 16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend. Another lesson is about security by obscurity. Some fetchmail users asked me to change the software to store

2z3

To ovšem není můj důvod, proč se takovéto anglické syntaxi obvykle vyhý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 byl pohodlný pro uživatele, ne aby byl levný pro počítač. 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ých chyb 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, a to natolik, že tento zpitvořený jazyk je stejně zmatečný, jako tradiční nesrozumitelná syntax. (Typickým příkladem jsou tzv. jazyky čtvrté generace a komerční jazyky pro přístup k databázím.) Kontrolní systém fetchmailu se vyhnul těmto potížím proto, že jeho jazyková oblast je nesmírně omezená. Není to zdaleka jazyk obecný, to co říká, není vůbec složité, takže je zde jen malý prostor pro zmatek při myšlenkovém př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. Pokud Váš jazyk není zdaleka kompletní (Turing-complete), syntaktický cukr může být přítelem Další lekce je o bezpečnosti přes utajení. Několik uživatelů mne požádalo, abych pozměnil program

22.2.2010 15:02

Zvon:


passwords encrypted in the rc file, so snoopers wouldn't be able to casually see them. I didn't do it, because this doesn't actually add protection. Anyone who's acquired permissions to read your rc file will be able to run fetchmail as you anyway -- and if it's your password they're after, they'd be able to rip the necessary decoder out of the fetchmail code itself to get it. All .fetchmailrc password encryption would have done is give a false sense of security to people who don't think very hard. The general rule here is:

tak, aby ukládal hesla zašifrovaná v rc souboru a tím zabránil příležitostným čumilům v jejich náhodném odkrytí. Já to neudělal, protože tím ve skutečnosti nezískáte žádnou ochranu. Každý, kdo získá přístupová práva ke čtení vašeho rc souboru bude moci sám spustit fetchmail, a pokud chce vaše heslo, získá potřebný dekodér z kódu fetchmailu. Zašifrování hesla v .fetchmailrc by pouze dalo falešný pocit jistoty lidem, kteří o všem důkladně nepřemýšlejí.

Bezpečnostní systém je pouze tak 17. A security system is only as secure bezpečný jako jeho tajemství. as its secret. Beware of pseudoMějte se na pozoru před pseudo secrets. tajemstvími.

<<< TOC / OBSAH

3z3


22.2.2010 15:02

Zvon:


<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T 9. Necessary 9. Nutné podmínky Preconditions for the pro styl tržiště Bazaar Style Early reviewers and test audiences for this paper consistently raised questions about the preconditions for successful bazaar-style development, including both the qualifications of the project leader and the state of code at the time one goes public and starts to try to build a co-developer community. It's fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode. Linus didn't try it. I didn't either. Your nascent developer community needs to have something runnable and testable to play with.

When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is convince potential co-developers that it can be evolved into something really neat in the foreseeable future. Linux and fetchmail both went public with strong, attractive basic designs. Many people thinking about the bazaar model as I have presented it have correctly considered this critical, then jumped from it to the conclusion that a

1z4

První čtenáři tohoto článku se neustá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 v jakém stavu musí být kód ve chvíli, kdy je zpřístupněn veřejnosti a snaží se získat další vývojáře. Je celkem jasné, že není možné programovat od počátku ve stylu tržiště. Je možné testovat, hledat chyby a vylepšovat na tržišti, ale bylo by velmi obtížné projekt zahájit ve stylu tržiště. Linus se o to nepokusil a já také ne. Vaše vznikající společenství vývojářů potřebuje něco, co může testovat a s čím si může hrát. Když začnete hledat spolupracovníky, potřebujete jim př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šak přesvědčit budoucí vývojáře o tom , že se v dohledné budoucnosti může vyvinout v něco skutečně užitečného. Linux i fetchmail měly již v době prvého zpřístupnění silnou a atraktivní konstrukci. Mnoho lidí, kteří přemýšlejí o programování ve stylu tržiště, toto považují zcela správně za základ úspěchu. Z tohoto

22.2.2010 15:02

Zvon:


faktu však zbrkle docházejí k závěru, že další nutnou podmínkou je konstrukční intuice vedoucího projektu a jeho chytrost. Linus ale převzal svoji konstrukci od But Linus got his design from Unix. I got Unixu a já tu svoji z předchůdce mine initially from the ancestral popclienta (ačkoliv ta se potom popclient (though it would later change a podstatně změnila, procentuálně great deal, much more proportionately vzato mnohem více než v případě speaking than has Linux). So does the Linuxu). Takže musí mít leader/coordinator for a bazaar-style vedoucí/koordinátor pro projekt ve effort really have to have exceptional stylu tržiště neobyčejný design talent, or can he get by on konstrukční talent nebo mu stačí leveraging the design talent of others? využívat talent ostatních? I think it is not critical that the Já se domnívám, že není zcela coordinator be able to originate designs nutné, aby koordinátor byl schopen of exceptional brilliance, but it is tvořit dokonalé konstrukce, ale je absolutely critical that the coordinator be naprosto nutné, aby byl schopen able to recognize good design ideas rozeznat dobré nápady from others. ostatních. Both the Linux and fetchmail projects Linux i fetchmail to potvrzují. show evidence of this. Linus, while not Linus, ačkoliv není (jak jsme již (as previously discussed) a spectacularly diskutovali) neobyčejně originální original designer, has displayed a konstruktér, prokázal svoji powerful knack for recognizing good výbornou schopnost rozpoznat design and integrating it into the Linux dobré nápady a integrovat je do kernel. And I have already described how jádra Linuxu. A já jsem již popsal, the single most powerful design idea in že s tím nejlepším nápadem fetchmail (SMTP forwarding) came from ohledně fetchmailu (SMTP somebody else. přesměrování) přišel někdo jiný. Early audiences of this paper Moji první čtenáři se mi snažili complimented me by suggesting that I podbízet tím, že tvrdili, že jsem am prone to undervalue design náchylný podceňovat originalitu originality in bazaar projects because I konstrukce u projektů tržiště, neboť have a lot of it myself, and therefore take já sám jsem jí obdařen, a proto ji it for granted. There may be some truth považuji za samozřejmou. V tom to this; design (as opposed to coding or může být něco pravdy, konstrukce debugging) is certainly my strongest (narozdíl od kódování nebo hledání skill. chyb) je mojí nejsilnější stránkou. But the problem with being clever and S originalitou při konstrukci original in software design is that it gets programů je ale problém. Začnete to be a habit -- you start reflexively podvědomě hledat původní a složitá high degree of design intuition and cleverness in the project leader is indispensable.

2z4

22.2.2010 15:02

Zvon:


řešení tam, kde je na místě použít něco robustního a jednoduchého. Některé mé projekty dříve selhaly, protože jsem se dopustil podobných chyb, v případě fetchmailu se mi jich ale podařilo vyvarovat. So I believe the fetchmail project Já se domnívám, že projekt succeeded partly because I restrained my fetchmail uspěl částečně proto, že tendency to be clever; this argues (at jsem omezil svoje tendence hledat least) against design originality being chytrá řešení. To ale argumentuje essential for successful bazaar projects. proti tvrzení o nutnosti originality v And consider Linux. Suppose Linus projektu ve stylu tržiště. A vezměte Torvalds had been trying to pull off si Linux. Řekněme, že by se Linus fundamental innovations in operating Torvalds snažil zakomponovat system design during the development; originální nápady během vývoje does it seem at all likely that the systému. Je pravděpodobné, že by resulting kernel would be as stable and vzniklé jádro systému bylo tak successful as what we have? stabilní a úspěšné? A certain base level of design and coding Je zapotřebí mít jistou úroveň skill is required, of course, but I expect konstrukčních schopností i almost anybody seriously thinking of programátorského umění, nicméně launching a bazaar effort will already be si myslím, že prakticky každý, kdo o above that minimum. The open-source něčem takovém uvažuje bude na community's internal market in patřičné úrovni. Vnitřní trh reputation exerts subtle pressure on otevřeného společenství tlačí na people not to launch development efforts všechny, aby nezačínali projekty, they're not competent to follow through které nejsou schopni uskutečnit. on. So far this seems to have worked Dosud se zdá, že vše funguje. pretty well. There is another kind of skill not Existuje ale další schopnost, která normally associated with software se obvykle nespojuje s rozvojem development which I think is as software a která je stejně důležitá, important as design cleverness to bazaar jako je schopnost konstruovat, a projects -- and it may be more important. možná ještě důležitější. Vedoucí A bazaar project coordinator or leader projektu tržiště musí být schopný must have good people and komunikovat a zacházet s lidmi. communications skills. This should be obvious. In order to build To by mělo být samozřejmé. Abyste a development community, you need to mohli stavět vývojářskou společnost, attract people, interest them in what musíte přitáhnout lidi, získat jejich you're doing, and keep them happy about zájem o to, co děláte a snažit se, aby the amount of work they're doing. byli spokojení s prací, kterou dělají. Technical sizzle will go a long way Technické zapálení hodně pomáhá, making things cute and complicated when you should be keeping them robust and simple. I have had projects crash on me because I made this mistake, but I managed not to with fetchmail.

3z4

22.2.2010 15:02

Zvon:


towards accomplishing this, but it's far ale zdaleka není vším. Vaše povaha from the whole story. The personality you je také důležitá. project matters, too. It is not a coincidence that Linus is a nice guy who makes people like him and want to help him. It's not a coincidence that I'm an energetic extrovert who enjoys working a crowd and has some of the delivery and instincts of a stand-up comic. To make the bazaar model work, it helps enormously if you have at least a little skill at charming people.

<<< TOC / OBSAH

4z4

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


22.2.2010 15:02

Zvon:


<<< TOC / OBSAH >>> EN CS EN/CS ZVON P/T 10. The Social Context 10. Společenský of Open-Source kontext otevřeného Software software It is truly written: the best hacks start out as personal solutions to the author's everyday problems, and spread because the problem turns out to be typical for a large class of users. This takes us back to the matter of rule 1, restated in a perhaps more useful way: 18. To solve an interesting problem, start by finding a problem that is interesting to you.

1z7

Je velkou pravdou, že nejlepší programy začínají tak, že autor sám potřebujete vyřešit své každodenní problémy, a šíří se proto, že se ukáže, že takový problém trápí mnoho ostatních uživatelů. To nás vede zpět k pravidlu 1, které je přeformulováno do možná užitečnější podoby: 18. Pokud chcete pracovat na zají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 the ancestral popclient, and so with me and fetchmail. But this has been understood for a long time. The interesting point, the point that the histories of Linux and fetchmail seem to demand we focus on, is the next stage -- the evolution of software in the presence of a large and active community of users and co-developers.

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

In ``The Mythical Man-Month'', Fred Brooks observed that programmer time is not fungible; adding developers to a late software project makes it later. He argued that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly. This claim has since become known as ``Brooks's Law'' and is widely regarded as a truism. But if Brooks'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áte programátory do projektu, který se opožďuje, opozdí se ještě více. Dokazuje, že složitost a problémy s komunikací se zvyšují se čtvercem počtu programátorů, zatímco množství práce stoupá pouze lineárně. Toto tvrzení se později stalo Brookovým zákonem, který je často považován za předmět víry. Kdyby ale tento zákon platil beze zbytku, Linux by nemohl

22.2.2010 15:02

Zvon:


existovat. Gerald Weinberg's classic ``The Psychology Of Computer Programming'' supplied what, in hindsight, we can see as a vital correction to Brooks. In his discussion of `ègoless programming'', Weinberg observed that in shops where developers are not territorial about their code, and encourage other people to look for bugs and potential improvements in it, improvement happens dramatically faster than elsewhere. Weinberg's choice of terminology has perhaps prevented his analysis from gaining the acceptance it deserved -one has to smile at the thought of describing Internet hackers as `ègoless''. But I think his argument looks more compelling today than ever. The history of Unix should have prepared us for what we're learning from Linux (and what I've verified experimentally on a smaller scale by deliberately copying Linus's methods). That is, that while coding remains an essentially solitary activity, the really great hacks come from harnessing the attention and brainpower of entire communities. The developer who uses only his or her own brain in a closed project is going to fall behind the developer who knows how to create an open, evolutionary context in which bug-spotting and improvements get done by hundreds of people. But the traditional Unix world was prevented from pushing this approach to the ultimate by several factors. One was the legal contraints of various licenses, trade secrets, and 2z7

Klasická kniha Geralda Weinberga : "`The Psychology Of Computer Programming'', obsahuje něco, co můžeme při zpětném pohledu považovat za nesmírně důležitou opravu Brookova tvrzení. V jeho diskuzi "nesobeckého programování" Weinberg tvrdí, že ve skupinách, ve kterých si vývojáři nechrání svůj kód a vybízejí ostatní, aby jim pomohli vyhledávat chyby a navrhovat vylepšení, projekty probíhají mnohem rychleji než jinde. Weinbergova terminologie možná zabránila tomu, aby jeho analýza získala takové přijetí, jaké si zasluhovala, člověk se musí usmát při myšlence, že Internetovští hackeři jsou "nesobečtí". Nicméně, myslím, že jeho argumenty nebyly nikdy tak aktuální jako dnes. Historie Unixu nás měla připravit na to, co se nyní učíme z Linuxu (a co jsem v menším měřítku ověřil experimentá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, pokud je využita pozornost a mozky celé společnosti. Vývojář, který využívá pouze vlastní mozek v uzavřeném projektu musí zaostat za vývojářem, který dokáže iniciovat otevřený evoluční projekt, ve kterém se odhalování chyb a vylepšení věnují stovky lidí. Tradičnímu Unixovému světu bylo zabráněno v dotažení tohoto přístupu několika faktory. Jedním z nich byla právní omezení, různé licence, obchodní tajemství a zájmy. Další 22.2.2010 15:02

Zvon:


commercial interests. Another (in překážkou (při zpětném pohledu) bylo hindsight) was that the Internet wasn't to, že Internet ještě nebyl na yet good enough. dostatečné úrovni. Before cheap Internet, there were some geographically compact communities where the culture encouraged Weinberg's `ègoless'' programming, and a developer could easily attract a lot of skilled kibitzers and co-developers. Bell Labs, the MIT AI Lab, UC Berkeley -- these became the home of innovations that are legendary and still potent.

Před levným Internetem existovala prostorově omezená společenství, jejichž kultura podporovala Weinbergovo "nesobecké programování", ve kterých mohl programátor snadno přilákat mnoho diváků a spolupracovníků. Bellovy laboratoře, MIT AI laboratoře, UC Berkeley se staly legendárními domovy vynálezů a jsou stále velmi plodné.

Linux was the first project to make a conscious and successful effort to use Linux byl prvým projektem, který the entire world as its talent pool. I vědomě a úspěšně využil celý svět don't think it's a coincidence that the jako svoji studnici talentů. Nemyslím gestation period of Linux coincided si, že je náhodné, že Linux vznikal v with the birth of the World Wide Web, době zrodu WWW a že Linux opustil and that Linux left its infancy during svá batolecí léta se začátkem nástupu the same period in 1993-1994 that saw Internetu do běžného the takeoff of the ISP industry and the povědomí(1993-1994). Linus byl explosion of mainstream interest in the první, který se naučil hrát podle Internet. Linus was the first person nových pravidel, které nastolil who learned how to play by the new všudypřítomný Internet. rules that pervasive Internet made possible. While cheap Internet was a necessary Zatimco levný Internet byl nutnou condition for the Linux model to podmínkou pro to, aby se Linuxový evolve, I think it was not by itself a model uplatnil, myslím, že to nebyla sufficient condition. Another vital podmínka dostačující. Dalším factor was the development of a nesmírně důležitým faktorem byl leadership style and set of cooperative vývoj stylu vedení a vytvoření zvyků, customs that could allow developers to které umožnily vývojářům získat další attract co-developers and get spolupracovníky a využít všechny maximum leverage out of the medium. možnosti tohoto media. But what is this leadership style and Ale jaký je styl vedení a jaké jsou tyto what are these customs? They cannot zvyky? Tyto zvyklosti nemohou být be based on power relationships -- and založeny na síle, a i pokud by byly, tak even if they could be, leadership by by vedení z pozice síly nemohlo coercion would not produce the results přinést výsledky, které vidíme. we see. Weinberg quotes the Weinberg cituje z autobiografie 3z7

22.2.2010 15:02

Zvon:


autobiography of the 19th-century Russian anarchist Pyotr Alexeyvich "Memoáry revoluce", kterou v 19. Kropotkin's ``Memoirs of a století napsal ruský anarchista Petr Revolutionist'' to good effect on this Alexejevič Kropotkin. subject: ``Having been brought up in a serf-owner's family, I entered active "Jelikož jsem se narodil v rodině, která life, like all young men of my time, vlastnila nevolníky, započal jsem svůj with a great deal of confidence in the aktivní život, jako všichni mladí muži v necessity of commanding, ordering, mém věku, s pevnou vírou v nutnost scolding, punishing and the like. But povelů, příkazů, trestů atd. Brzy jsem when, at an early stage, I had to ale musel řídit důležité záležitosti a manage serious enterprises and to deal jednat se [svobodnými] muži, a zde with [free] men, and when each měla každá chyba závažné následky. mistake would lead at once to heavy Začal jsem oceňovat rozdíl mezi consequences, I began to appreciate činností na základě příkazů a the difference between acting on the disciplíny a činností na základě principle of command and discipline společného porozumění. To prvé and acting on the principle of common obdivuhodně funguje při vojenské understanding. The former works přehlídce, ale nemá žádnou cenu ve admirably in a military parade, but it skutečném životě, kde cíle může být is worth nothing where real life is dosaženo pouze úsilím mnoha concerned, and the aim can be spolupracujících myslí. achieved only through the severe effort of many converging wills.'' "Velké úsilí mnoha spolupracujících The ``severe effort of many converging mozků, to je přesně to, co projekt jako wills'' is precisely what a project like Linux vyžaduje, a model řízení Linux requires -- and the ``principle of založený na povelech je zcela nemožný command'' is effectively impossible to v prostředí dobrovolníků v apply among volunteers in the anarchistickém ráji, který nazýváme anarchist's paradise we call the Internet. Aby mohli pracovat a Internet. To operate and compete soutěžit efektivně, programátoři, kteří effectively, hackers who want to lead chtějí vést projekty založené na collaborative projects have to learn spolupráci, se musí naučit, jak získat how to recruit and energize effective a povzbuzovat skupiny lidí se communities of interest in the mode společným zájmem, jak neurčitě vaguely suggested by Kropotkin's naznačuje Kropotkin svým "principem ``principle of understanding''. They porozumění". Musí se naučit využívat must learn to use Linus's Law. Linusův zákon. Earlier I referred to the ``Delphi Dříve jsem se zmínil o "Delphi efektu" effect'' as a possible explanation for jako o možném vysvětlení Linusova Linus's Law. But more powerful zákona. Ještě silnější analogie s 4z7

22.2.2010 15:02

Zvon:


analogies to adaptive systems in biology and economics also irresistably suggest themselves. The Linux world behaves in many respects like a free market or an ecology, a collection of selfish agents attempting to maximize utility which in the process produces a self-correcting spontaneous order more elaborate and efficient than any amount of central planning could have achieved. Here, then, is the place to seek the ``principle of understanding''.

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

"Užitková funkce, kterou linuxový programátoři maximalizují není klasicky ekonomická, ale lze ji spojit s uspokojením vlastního já a získáním dobré reputace mezi ostatními programátory. (Někdo by mohl nazvat toto chování altruistické, ale tento pohled ignoruje fakt, že altruismus je sám o sobě formou uspokojení vlastního já pro altruistu). Dobrovolná společenství, která pracují podobným způsobem nejsou ve skutečnosti vzácná, podobným, ve kterém jsem zapojen již velmi dlouho je okruh přátel science fiction, ve kterém je výslovně uznáváno, že hlavním motivem pro spolupráci je zvýšení vlastní reputace mezi ostatními. Linus, by successfully positioning Linus tím, že se úspěšně postavil do himself as the gatekeeper of a project role ochránce projektu, který je z in which the development is mostly velké části rozvíjen někým jiným a done by others, and nurturing interest tím, že získával podporu pro projekt in the project until it became dokud se projekt nestal self-sustaining, has shown an acute sebeudržujícím, ukázal, že plně grasp of Kropotkin's ``principle of pochopil Kropotkinovo pravidlo shared understanding''. This quasisdíleného porozumění. Kvasieconomic view of the Linux world ekonomický pohled na Linuxův svět enables us to see how that nám umožňuje pochopit, jak se tento understanding is applied. princip uplatňuje. The `ùtility function'' Linux hackers are maximizing is not classically economic, but is the intangible of their own ego satisfaction and reputation among other hackers. (One may call their motivation `àltruistic'', but this ignores the fact that altruism is itself a form of ego satisfaction for the altruist). Voluntary cultures that work this way are not actually uncommon; one other in which I have long participated is science fiction fandom, which unlike hackerdom explicitly recognizes `ègoboo'' (the enhancement of one's reputation among other fans) as the basic drive behind volunteer activity.

5z7

22.2.2010 15:02

Zvon:


Můžeme nahlížet na Linusovy metody jako na způsob, jak vytvořit účinný trh v uspokojování vlastního já, tím, že připoutá sobectví individuelních programátorů co nejpevněji k obtížným cílům, které mohou být dosaženy pouze vytrvalou spoluprací. V projektu fetchmailu jsem ukázal (ačkoli v menším měřítku), že tato metoda může být napodobena s dobrými výsledky. Možná, že jsem vše dělal s plnějším vědomím a systematičtěji než Linus sám. Mnoho lidí, zejména těch, kteří politicky nedůvěřují volnému trhu, Many people (especially those who očekávají, že společnost sebeřídících politically distrust free markets) would egoistů bude fragmentována, bude expect a culture of self-directed ochraňovat svá území, bude plýtvat egoists to be fragmented, territorial, zdroji, vše tajit a bude k sobě wasteful, secretive, and hostile. But nepřátelská.Ale toto očekávání je this expectation is clearly falsified by jasně vyvráceno například (to give just one example) the stunning překvapující různorodostí, kvalitou a variety, quality and depth of Linux hloubkou dokumentace Linuxu. Je to documentation. It is a hallowed given zázrak, když si uvědomíme, jak that programmers hate documenting; programátoři nenávidí psaní how is it, then, that Linux hackers dokumentace. Jak je tedy možné, že generate so much of it? Evidently programátoři Linuxu ji produkují Linux's free market in egoboo works tolik? Je zřejmé, že Linuxův volný trh v better to produce virtuous, othersebeuspokojování funguje lépe při directed behavior than the massivelynastolení ctnostného chování než funded documentation shops of masivně financované dokumentační commercial software producers. útvary poskytovatelů komerčního software. Both the fetchmail and Linux kernel projects show that by properly Fetchmail i Linux ukázaly, že pokud rewarding the egos of many other dostatečně odměním ego mnoha hackers, a strong jiných programátorů, silný vývojářdeveloper/coordinator can use the koordinátor může využít Internet, aby Internet to capture the benefits of získal mnoho spolupracovníků, aniž se having lots of co-developers without projekt zhroutí v chaotický zmatek. having a project collapse into a chaotic Takže já navrhuji následující mess. So to Brooks's Law I counterprotiargument k Brookově zákonu. propose the following: We may view Linus's method as a way to create an efficient market in `ègoboo'' -- to connect the selfishness of individual hackers as firmly as possible to difficult ends that can only be achieved by sustained cooperation. With the fetchmail project I have shown (albeit on a smaller scale) that his methods can be duplicated with good results. Perhaps I have even done it a bit more consciously and systematically than he.

6z7

22.2.2010 15:02

Zvon:


19: Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. I think the future of open-source software will increasingly belong to people who know how to play Linus's game, people who leave behind the cathedral and embrace the bazaar. This is not to say that individual vision and brilliance will no longer matter; rather, I think that the cutting edge of open-source software will belong to people who start from individual vision and brilliance, then amplify it through the effective construction of voluntary communities of interest. And perhaps not only the future of open-source software. No closedsource developer can match the pool of talent the Linux community can bring to bear on a problem. Very few could afford even to hire the more than two hundred people who have contributed to fetchmail! Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software ``hoarding'' is morally wrong (assuming you believe the latter, which neither Linus nor I do), but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem.

<<< TOC / OBSAH

7z7

19. Pokud má koordinátor projektu k dispozici medium alespoň tak dobré jako Internet a dokáže vést bez příkazů, mnoho hlav je nevyhnutelně lepší než jedna. Myslím si, že budoucnost otevřeného software bude stále více patřit lidem, kteří vědí, jak se chovat v Linusově hře, lidem, kteří opustí katedrálu a vezmou si tržiště za své. Tím nechci říci, že už nezáleží na individuálních vizích a velkých schopnostech. Spíše si myslím, že budoucnost patří lidem, kteří začnou s individuální vizí a velkými schopnostmi a ty potom zmnohonásobí ve vytvořených skupinách se společným zájmem. A možná nejen budoucnost otevřeného software. Žádný vývojář v uzavřeném projektu nemůže mít takovou nabídku talentů pro vyřešení problému, jako se nachází ve společenství Linuxu. Jen málokdo si může dovolit najmout více než 200 lidí, kteří přispívali do fetchmailu. Možná že nakonec kultura otevřeného software zvítězí ne proto, že je morálně správná, nebo že hamounění software je morálně špatné (za předpokladu, že tomu druhému věříte, já ani Linus ne), ale jednoduše proto, že uzavřené projekty nemohou vyhrát v evolučním zápase s otevřeným systémem, který může vynaložit o několik řádů více kvalifikovaného času na řešení problémů.


22.2.2010 15:02

Zvon:


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

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

<<< TOC / OBSAH

1z1

Tento článek byl vylepšen díky diskuzím s mnoha lidmi. Zejména děkuji Jeffovi Dutkymu, který navrhl termín "hledání chyb je paralelizovatelné" a pomohl vyvinout analýzu, která z něj vychází. Rovněž děkuji Nancy Lebovitz za její návrh emulace Weinberga citací z Kropotkina. Vnímavou kritikou rovněž přispěli Joan Eslinger a Marty Franz. Jsem vděčný členům PLUG(Skupina uživatelů Linuxu ve Philadelphii), kteří se stali mým prvním testovacím publikem pro prvou veřejnou verzi článku. A nakonec, děkuji Linusovi Torvaldovi za jeho cenné připomínky a za povzbuzení, které se mi dostalo od samého počátku.


22.2.2010 15:03

Zvon:


<<< TOC / OBSAH 12. For Further Reading


I quoted several bits from Frederick P. Brooks's classic The Mythical Man-Month because, in many respects, his insights have yet to be improved upon. I heartily recommend the 25th Anniversary edition from Addison-Wesley (ISBN 0-201-83595-9), which adds his 1986 ``No Silver Bullet'' paper. The new edition is wrapped up by an invaluable 20-years-later retrospective in which Brooks forthrightly admits to the few judgements in the original text which have not stood the test of time. I first read the retrospective after this paper was substantially complete, and was surprised to discover that Brooks attributes bazaar-like practices to Microsoft! (In fact, however, this attribution turned out to be mistaken. In 1998 we learned from the Halloween Documents that Microsoft's internal developer community is heavily balkanized, with the kind of general source access needed to support a bazaar not even truly possible.) Gerald M. Weinberg's The Psychology Of Computer Programming (New York, Van Nostrand Reinhold 1971) introduced the rather unfortunatelylabeled concept of `ègoless programming''. While he was nowhere near the first person to realize the futility of the ``principle of command'', he was probably the first to recognize and argue the point in

1z3

12. K dalšímu čtení

Několikrát jsem citoval z klasické práce Frederika P. Brooka "The Mythical Man-Month". Vřele doporučuji edici k 25 výročí (ISBN 0-201-83595-9), ke které je přidán článek z roku 1986 ``No Silver Bullet''. Tato nová edice je doplněna neocenitelným zpětným pohledem na uplynulých 20 let, ve kterém se Brook upřímně přiznává k tvrzením, která nebyla potvrzena dalším vývojem. Já jsem toto zpětné ohlédnutí poprvé četl ve chvíli, kdy tento článek byl z velké části hotov a překvapilo mne, že Brooks přičítá principz tržiště Microsoftu!.(Ve skutečnosti se ale toto tvrzení ukázalo mylné. V roce 1998 jsme se z uniklých dokumenů, tzv. Halloween Documents dozvěděli, že vnitřní vývojářská komunita Microsoftu je balkanizovaná, bez možností obecného přístupu ke zdrojům, které styl tržiště vyžaduje. Gerald M. Weinberg's v knize The Psychology Of Computer Programming (New York, Van Nostrand Reinhold 1971)zavedl poněkud nešťastně označený pojem "nesobecké programování". Ačkoliv nebyl zdaleka prvým, kdo si uvědomil nedostatečnost "principu založeném na příkazech", byl pravděpodobně první, který rozpoznal a zdůvodňoval

22.2.2010 15:03

Zvon:

2z3


particular connection with software development.

toto stanovisko s ohledem na vývoj software.

Richard P. Gabriel, contemplating the Unix culture of the pre-Linux era, reluctantly argued for the superiority of a primitive bazaar-like model in his 1989 paper Lisp: Good News, Bad News, and How To Win Big. Though dated in some respects, this essay is still rightly celebrated among Lisp fans (including me). A correspondent reminded me that the section titled ``Worse Is Better'' reads almost as an anticipation of Linux. The paper is accessible on the World Wide Web at http://www.naggum.no/worseis-better.html. De Marco and Lister's Peopleware: Productive Projects and Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6) is an underappreciated gem which I was delighted to see Fred Brooks cite in his retrospective. While little of what the authors have to say is directly applicable to the Linux or open-source communities, the authors' insight into the conditions necessary for creative work is acute and worthwhile for anyone attempting to import some of the bazaar model's virtues into a commercial context. Finally, I must admit that I very nearly called this paper ``The Cathedral and the Agora'', the latter term being the Greek for an open market or public meeting place. The seminal `àgoric systems'' papers by Mark Miller and Eric Drexler, by describing the emergent properties of market-like computational ecologies, helped prepare me to think clearly about analogous phenomena in the

Richard P. Gabriel, který přemýšlel nad Unixovou kulturou v období před Linuxem, váhavě argumentoval o přednostech jednoduchých stylů tržiště ve svém článku z roku 1989 Lisp: Dobré zprávy, špatné zprávy a jak zvítězit. Ačkoliv již v některých ohledech zastaralá, tento esej je stále uctíván mezi příznivci Lispu (včetně mne). Byl jsem upozorněn, že část nazvaná "Horší je lepší" lze vyložit jako předpověď Linuxu. Tento článek je přístupný na WWW na adrese http://www.naggum.no/worseis-better.html Kniha De Marca a Listera Peopleware: Productive Projects and Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6) je nedoceněný klenot. Byl jsem velmi potěšen, když Fred Brooks jej citoval ve své retrospektivě. Ačkoliv málo z toho, co autoři píší je přímo aplikovatelné na Linux, jejich náhled na nutné podmínky pro tvořivou práci je 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í. Na závěr musím připustit, že jsem článek téměř nazval "Katedrála a Agora". Agora je řecký výraz pro otevřený trh nebo místo veřejných setkání. Články Marka Millera a Erica Drexlera popisující vlastnosti tržních počítačových ekologií, mne pomohly ujasnit si analogické jevy v otevřeném společenství, když jsem narazil na Linux o pět let později. Tyto články jsou dostupné na síti na adrese 22.2.2010 15:03

Zvon:


open-source culture when Linux rubbed my nose in them five years http://www.agorics.com later. These papers are available on the /agorpapers.html. Web at http://www.agorics.com /agorpapers.html.

<<< TOC / OBSAH

3z3


22.2.2010 15:03

Zvon:


<<< TOC / OBSAH

EN CS EN/CS ZVON P/T 13. Epilog: 13. Epilog: Netscape Netscape přijala Embraces the Bazaar! tržiště Je to zvláštní pocit, když si uvědomíte, že pomáháte vytvářet historii ... 26.ledna 1998, asi sedm měsíců On January 22 1998, approximately seven poté, co jsem poprvé publikoval months after I first published this paper, tento článek, Netscape Netscape Communications, Inc. announced Communications, Inc. oznámil plans to give away the source for své plány zveřejnit zdrojový Netscape Communicator. I had had no kód Netscape Communicator. clue this was going to happen before the Neměl jsem žádné tušení o tom, day of the announcement. že se k tomu schyluje do dne oznámení. Eric Hahn, náměstek ředitele a Eric Hahn, Executive Vice President and hlavní technolog v Netscape mi Chief Technology Officer at Netscape, krátce poté napsal tento email: emailed me shortly afterwards as follows: "Jménem nás všech v Netscape `Òn behalf of everyone at Netscape, I want Vám chci poděkovat za to, že jste to thank you for helping us get to this point nás k tomuto nápadu přivedl. in the first place. Your thinking and Vaše myšlenky a články byly writings were fundamental inspirations to základní inspirací pro naše our decision.'' rozhodnutí." The following week I flew out to Silicon Valley at Netscape's invitation for a day-long Následující týden jsem byl strategy conference (on Feb 4 1998) with pozván společností Netscape do some of their top executives and technical Silicon Valley na celodenní people. We designed Netscape's sourcestrategickou konferenci s jejich release strategy and license together, and hlavními manažery a techniky. laid some more plans that we hope will Navrhli jsme strategii pro eventually have far-reaching and positive zveřejnění zdrojů a pro licence a impacts on the open-source community. As I připravili další plány, keré, jak write, it is a bit too soon to be more doufáme, budou mít dalekosáhlé specific; but details should be forthcoming a kladné účinky. within weeks. Netscape is about to provide us with a large- Netscape nám poskytuje velký scale, real-world test of the bazaar model in reálný test modelu ve stylu It's a strange feeling to realize you're helping make history....

1z2

22.2.2010 15:03

Zvon:


tržiště v komerčním světě. Stojíme před velkým nebezpečím. Pokud tento projekt selže, může být celý koncept tak zdiskreditován, že komerčním svět na něj zanevře na další desetiletí. Na druhé straně je to také skvělá On the other hand, this is also a spectacular příležitost. Počáteční reakce Wall opportunity. Initial reaction to the move on Streetu i jinde byla obezřetně Wall Street and elsewhere has been kladná. Byla nám dána šance se cautiously positive. We're being given a osvědčit. Pokud získá Netscape chance to prove ourselves, too. If Netscape díky tomuto tahu podstatný podíl regains substantial market share through na trhu, může to způsobit dlouho this move, it just may set off a long-overdue očekávanou revoluci v revolution in the software industry. softwarovém průmyslu. The next year should be a very instructive Příští rok bude velmi zajímavý. and interesting time. the commercial world. The open-source culture now faces a danger; if Netscape's execution doesn't work, the open-source concept may be so discredited that the commercial world won't touch it again for another decade.

<<< TOC / OBSAH

2z2

EN CS EN/CS ZVON P/T

22.2.2010 15:03

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

Recommend Documents