Katedrála a tržiště

Transkript

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
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:
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
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
<[email protected]>, který
<[email protected]> 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:
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
22.2.2010 15:01
Zvon:
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:
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:
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:
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:
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:
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
<[email protected]>, who suggested the
``debugging is parallelizable'' formulation, and
helped develop the analysis that proceeds from it.
Also to Nancy Lebovitz
<[email protected]> 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

Katedrála a tržiště

Transkript

Podobné dokumenty

THERE WAS A TREE (POHÁDKA O STROMĚ) THERE WAS A

hallelujah

U2794S