Notes
Huomautukset
[JB] In Programing Pearls, the noted computer-science aphorist Jon Bentley comments on Brooks's observation with If you plan to throw one away, you will throw away two.. He is almost certainly right. The point of Brooks's observation, and Bentley's, isn't merely that you should expect first attempt to be wrong, it's that starting over with the right idea is usually more effective than trying to salvage a mess.
[JB] Kirjassaan Programming Pearls tunnettu IT-kirjailija Jon Bentley huomautti Brooksin päätelmästä: "Jos aiot hylätä yhden, hylkäät myös toisen". Bentley on melko varmasti oikeassa. Brooksin ja Bentleyn viesti ei ole pelkästään se, että ensimmäisen yrityksen voi odottaakin epäonnistuvan. Kyse on siitä, että kun aloittaa uudestaan alusta ja kun silloin tietää mitä on tekemässä, pääsee parempaan tulokseen kuin jos jää selvittelemään ensimmäisen version sotkuja.
Nopeasti tehty hatara käännös. Parannelkaa ihmeessä.
[QR] Examples of successful open-source, bazaar development predating the Internet explosion and unrelated to the Unix and Internet traditions have existed. The development of the info-Zip compression utility during 1990–x1992, primarily for DOS machines, was one such example. Another was the RBBS bulletin board system (again for DOS), which began in 1983 and developed a sufficiently strong community that there have been fairly regular releases up to the present (mid-1999) despite the huge technical advantages of Internet mail and file-sharing over local BBSs. While the info-Zip community relied to some extent on Internet mail, the RBBS developer culture was actually able to base a substantial on-line community on RBBS that was completely independent of the TCP/IP infrastructure.
[QR] Joitakin onnistuneita avoimeen lähdekoodin ja basaarityylin hankkeita toteutettiin Unixin ja internetin ulkopuolella ennen internetin läpimurtoa. Yksi niistä on vuosina 1990-1992 lähinnä DOS-koneille kehitetty info-Zip -pakkaustyökalu. Toinen oli niin ikään DOS:lle laadittu RBBS-ilmoitustaulujärjestelmä. Työ aloitettiin vuonna 1983 ja sen kehittäjäyhteisö kasvoi niin vahvaksi, että järjestelmästä on valmistunut uusia versioita melko säännöllisesti nykyaikoihin (vuoden 1999 puoliväliin) asti. Kehitystyö jatkui, vaikka internetissä sähköposti ja tiedostonjako tarjosivat ilmoitustaulujärjestelmään verrattuna valtavia etuja. Info-Zip-yhteisö hyödynsi jossain määrin sähköpostia, mutta RBBS:n kehittäjäkulttuuri kukoisti ilmoitustaulujärjestelmän varassa eli tukeutumatta TCP/IP-infrastruktuuriin.
Nopeasti tehty hatara käännös. Parannelkaa ihmeessä.
[CV] That transparency and peer review are valuable for taming the complexity of OS development turns out, after all, not to be a new concept. In 1965, very early in the history of time-sharing operating systems, Corbat� and Vyssotsky, co-designers of the Multics operating system, wrote
[CV] Käyttöjärjestelmien kehitystyössä läpinäkyvyys ja vertaisarviointi eivät kuitenkaan ole uusia asioita. Vuonna 1965, osituskäyttöjärjestelmien varhaisessa kehitysvaiheessa Multics-käyttöjärjestelmän kehittäjät F.J. Corbató ja V.A. Vyssotsky kirjoittivat:
Ks. http://en.wikipedia.org/wiki/Multics - Jopi.
It is expected that the Multics system will be published when it is operating substantially... Such publication is desirable for two reasons: First, the system should withstand public scrutiny and criticism volunteered by interested readers; second, in an age of increasing complexity, it is an obligation to present and future system designers to make the inner operating system as lucid as possible so as to reveal the basic system issues.
"Tarkoitus on, että Multics-järjestelmä julkaistaan, kun se on kohtuullisessa toimintakunnossa. ... Julkaiseminen on tarkoituksenmukaista kahdesta syystä. Ensiksikin järjestelmän on kestettävä julkista arviointia ja kiinnostuneiden lukijoiden vapaaehtoisesti lähettämää kritiikkiä. Toiseksi kasvavan monimutkaisuuden aikakautena on välttämätöntä, että nykypolven ja tulevat järjestelmäsuunnittelijat tekevät käyttöjärjestelmän toiminnasta mahdollisimman selkeää, jotta järjestelmän perusrakenteeseen liittyvät kysymykset paljastuvat."
[JH] John Hasler has suggested an interesting explanation for the fact that duplication of effort doesn't seem to be a net drag on open-source development. He proposes what I'll dub "Hasler's Law": the costs of duplicated work tend to scale sub-qadratically with team size—that is, more slowly than the planning and management overhead that would be needed to eliminate them.
[JH] John Hasler on ehdottanut kiinnostavaa selitystä sille, miksi avoimen lähdekoodin kehitystyössä päällekkäinen työ ei näytä aiheuttavan suhteellista haittaa. Kutsuttakoon sitä "Haslerin laiksi": päällekkäisen työn aiheuttamat kustannukset kasvavat hitaammin kuin suhteessa työryhmän jäsenmäärän neliöön. Toisin sanoen haitat kasvavat hitaammin kuin ne suunnittelun ja työnjohdon yleiskulut, joita päällekkäisen työn eliminoinnissa tarvittaisiin.
This claim actually does not contradict Brooks's Law. It may be the case that total complexity overhead and vulnerability to bugs scales with the square of team size, but that the costs from duplicated work are nevertheless a special case that scales more slowly. It's not hard to develop plausible reasons for this, starting with the undoubted fact that it is much easier to agree on functional boundaries between different developers' code that will prevent duplication of effort than it is to prevent the kinds of unplanned bad interactions across the whole system that underly most bugs.
Haslerin laki ei ole ristiriidassa Brooksin lain kanssa. Voi olla, että työn monimutkaistumiseen liittyvät yleiskulut ja virheiden aiheuttamat haitat kasvavat suhteessa työryhmän jäsenmäärän neliöön. Silti nimenomaan päällekkäisestä työstä johtuvat kulut eivät ehkä kasvakaan yhtä nopeasti. On helppoa keksiä uskottavia selityksiä tälle. Päällekkäistä työtä voidaan ehkäistä ennakolta esimerkiksi sopimalla rajoista, joita eri kehittäjät eivät ylitä kirjoittaessaan ohjelmakoodia. On vaikeampaa eliminoida etukäteen sellaisia ohjelmiston sisäisiä ikäviä riippuvuusvaikutuksia, jotka ovat useimpien ohjelmisto-ongelmien syynä.
The combination of Linus's Law and Hasler's Law suggests that there are actually three critical size regimes in software projects. On small projects (I would say one to at most three developers) no management structure more elaborate than picking a lead programmer is needed. And there is some intermediate range above that in which the cost of traditional management is relatively low, so its benefits from avoiding duplication of effort, bug-tracking, and pushing to see that details are not overlooked actually net out positive.
Kun Linuksen ja Haslerin lait yhdistetään, voidaan päätellä, että ohjelmistoprojekteissa on itse asiassa kolme kokoluokkaa, joiden hallintaperiaatteisiin liittyvät erot ovat merkittäviä. Pienissä hankkeissa (sanoisin yhdestä enintään kolmeen kehittäjää) ei tarvitse muuta kuin valita hankkeen vetäjä. Hieman suuremmissakaan hankkeissa tavanomainen johtamistapa ei tule vielä kovin kalliiksi, joten siitä saatavat hyödyt päällekkäisen työn välttämisessä, virheiden korjaamisessa ja yksityiskohtaisessa laadunvarmistuksessa johtavaan positiiviseen nettotulokseen.
Above that, however, the combination of Linus's Law and Hasler's Law suggests there is a large-project range in which the costs and problems of traditional management rise much faster than the expected cost from duplication of effort. Not the least of these costs is a structural inability to harness the many-eyeballs effect, which (as we've seen) seems to do a much better job than traditional management at making sure bugs and details are not overlooked. Thus, in the large-project case, the combination of these laws effectively drives the net payoff of traditional management to zero.
Linuksen ja Haslerin laista kuitenkin seuraa, että on suuren mittakaavan projekteissa tavanomaisen johtamistavan aiheuttamat kustannukset ja ongelmat kasvavat paljon nopeammin kuin päällekkäisen työn aiheuttamat haitat. Yksi merkittävistä tavanomaisen johtamistyylin haitoista on kyvyttömyys käyttää hyväksi monien silmäparien havaintokykyä. Kuten olemme nähneet, monien silmäparien vaikutus auttaa havaitsemaan ongelmia ja huomiota kaipaavia yksityiskohtia paremmin kuin perinteinen johtamistyyli. Lopputulos on, että suurissa hankkeissa lakien yhteisvaikutus painaa tavanomaisesta johtamistavasta saadun hyödyn nollaksi.
En tainnut ymmärtää oikein käsitettä duplication of effort. Edellisessä kappaleessa voi siis myös olla asiavirhe. Muutenkin suomentelin kohtuullisen vapaasti.
[HBS] The split between Linux's experimental and stable versions has another function related to, but distinct from, hedging risk. The split attacks another problem: the deadliness of deadlines. When programmers are held both to an immutable feature list and a fixed drop-dead date, quality goes out the window and there is likely a colossal mess in the making. I am indebted to Marco Iansiti and Alan MacCormack of the Harvard Business School for showing me me evidence that relaxing either one of these constraints can make scheduling workable.
[HBS] Linux-käyttöjärjestelmän kokeellisen ja vakaan version ero liittyy toisellakin tavalla riskien hallintaan. Erolla ratkaistaan ongelma, joka liittyy määräaikojen ja laadun tasapainottamiseen. Jos ohjelmoijien on ehdottomasti toteutettava tietyt ominaisuudet ja samaan aikaan noudatettava ehdottomasti jotain määräaikaa, laadulla joudutaan heittämään vesilintua ja tuloksena voi olla massiivinen sotku. Haluan kiittää Harvardin kauppakorkeakoulun Marco Iansitia ja Alan MacCormackia siitä, että he esittivät minulle tutkimusaineistoa, jonka mukaan jomman kumman tavoitteen höllentäminen voi tehdä aikataulutuksesta toimivan.
One way to do this is to fix the deadline but leave the feature list flexible, allowing features to drop off if not completed by deadline. This is essentially the strategy of the "stable" kernel branch; Alan Cox (the stable-kernel maintainer) puts out releases at fairly regular intervals, but makes no guarantees about when particular bugs will be fixed or what features will beback-ported from the experimental branch.
Yksi ratkaisu on pitää kiinni määräajasta, mutta olla joustava ohjelmiston ominaisuuksien suhteen. Silloin ominaisuuksia voidaan jättää pois, jos niitä ei saada valmiiksi määräaikaan mennessä. Tätä strategiaa noudatetaan Linuxin "vakaan" ytimen kehitystyössä, josta vastaa Alan Cox. Hän julkaisee uusia versioita melko säännöllisesti, mutta hän ei anna mitään takuita siitä, milloin mikin ongelma ratkaistaan tai mitkä kokeellisen version ominaisuudet otetaan vakaaseen versioon.
The other way to do this is to set a desired feature list and deliver only when it is done. This is essentially the strategy of the "experimental" kernel branch. De Marco and Lister cited research showing that this scheduling policy ("wake me up when it's done") produces not only the highest quality but, on average, shorter delivery times than either "realistic" or "aggressive" scheduling.
Toinen ratkaisu on pitää kiinni halutuista ominaisuuksista ja julkaista vasta, kun ne on toteutettu. Se on "kokeellista" ydintä kehittävän joukon strategia. De Marco ja Lister ovat viitanneet tutkimuksiin, joissa on osoitettu, että tämä "herätä minut, kun se on valmis" -malli tuottaa sekä parasta laatua että nopeampia tuloksia kuin "realistinen" tai "vaativa" aikataulutus.
I have come to suspect (as of early 2000) that in earlier versions of this essay I severely underestimated the importance of the "wake me up when it's done" anti-deadline policy to the open-source community's productivity and quality. General experience with the rushed GNOME 1.0 release in 1999 suggests that pressure for a premature release can neutralize many of the quality benefits open source normally confers.
Nyt (vuoden 2000 alussa) minusta tuntuu, että tämän kirjoituksen edellisissä versioissa aliarvioin pahasti määräaikojen vastaisen "herätä minut kun se on valmis" -mallin vaikutusta avoimen lähdekoodin yhteisön tuottavuuteen ja työn laatuun. Paineet joiden takia ohjelmistoja julkaistaan keskeneräisinä voivat syödä laatuetuja, joita avoimen lähdekoodin yhteistyö yleensä tuottaa. Tätä käsitystä tukevat kokemukset, joita syntyi, kun GNOME 1.0:n julkistusta kiirehdittiin vuonna 1999.
It may well turn out to be that the process transparency of open source is one of three co-equal drivers of its quality, along with "wake me up when it's done" scheduling and developer self-selection.
Voi hyvinkin olla, että avoimen kehitystyön läpinäkyvyys on yksi kolmesta, keskenään samanarvoisesta avoimen lähdekoodin laatutekijästä. Muut kaksi ovat "herätä minut kun se on valmis" -tyyppinen aikataulutus ja kehittäjien omaehtoinen valikoituminen projekteihin.
[SU] It's tempting, and not entirely inaccurate, to see the core-plus-halo organization characteristic of open-source projects as an Internet-enabled spin on Brooks's own recommendation for solving the N-squared complexity problem, the "surgical-team" organization—but the differences are significant. The constellation of specialist roles such as "code librarian" that Brooks envisioned around the team leader doesn't really exist; those roles are executed instead by generalists aided by toolsets quite a bit more powerful than those of Brooks's day. Also, the open-source culture leans heavily on strong Unix traditions of modularity, APIs, and information hiding—none of which were elements of Brooks's prescription.
[SU] On houkuttelevaa eikä aivan väärinkään pitää avoimen lähdekoodin projektien ydin-ja-kehä -organisaatiomallia internetin mahdolliseksi tekemänä muunnoksena Brooksin leikkaussaliryhmä-mallista, jonka Brooks toivoi ratkaisevan suhteessa osallistujien neliöön kasvavan monimutkaisuuden ongelman. Kuitenkin näiden kahden mallin erot ovat huomattavia. Brooks odotti, että projektin vetäjän ympärille muodostuisi erikoisosaajien kehä, mutta esimerkiksi ohjelmistokirjastojen hoitamiseen erikoistuneita osallistujia ei juuri ole. Erikoisosaajien sijasta meillä on yleisihmisiä, joilla on paljon tehokkaampia työkaluja kuin ne, joita oli käytössä Brooksin aikoina. Lisäksi avoimen lähdekoodin kulttuuri tukeutuu sellaisiin perinteisiin Unix-ilmiöihin, kuten modulaarisuus, APIt ja tiedon salailu. Mitään niistä Brooks ei ottanut huomioon.
[RJ] The respondent who pointed out to me the effect of widely varying trace path lengths on the difficulty of characterizing a bug speculated that trace-path difficulty for multiple symptoms of the same bug varies "exponentially" (which I take to mean on a Gaussian or Poisson distribution, and agree seems very plausible). If it is experimentally possible to get a handle on the shape of this distribution, that would be extremely valuable data. Large departures from a flat equal-probability distribution of trace difficulty would suggest that even solo developers should emulate the bazaar strategy by bounding the time they spend on tracing a given symptom before they switch to another. Persistence may not always be a virtue...
[RJ] Osallistuja, joka osoitti minulle sen, miten paljon virheiden määrittelyn vaikeus johtuu virheiden vaikutusketjujen pituudesta, arvaili että jos yhteen virheeseen liittyy useita oireita, niiden jäljittämisen hankaluudet noudattavat "eksponentiaalista" jakaumaa. Tulkitsen sen tarkoittavan Gaussin tai Poissonin jakaumaa ja luullakseni arvelu osuu oikeaan. Jos jakauman muodosta saataisiin empiiristä aineistoa, se olisi hyvin arvokasta. Sikäli kuin jäljittämisen vaikeutta kuvaama jakauma poikkeaisi paljon tasaisesta jakaumasta, myös yksin toimivien kehittäjien kannattaisi matkia basaarimallia niin, että kunkin virheen korjaamiseen varataan vain rajallinen määrä aikaa. Jos ratkaisua ongelmaan ei löydy siinä ajassa, kannattaa siirtyä seuraavaan. Kärsivällisyys ei ole aina hyve.
[IN] An issue related to whether one can start projects from zero in the bazaar style is whether the bazaar style is capable of supporting truly innovative work. Some claim that, lacking strong leadership, the bazaar can only handle the cloning and improvement of ideas already present at the engineering state of the art, but is unable to push the state of the art. This argument was perhaps most infamously made by the Halloween Documents, two embarrassing internal Microsoft memoranda written about the open-source phenomenon. The authors compared Linux's development of a Unix-like operating system to "chasing taillights", and opined "(once a project has achieved "parity" with the state-of-the-art), the level of management necessary to push towards new frontiers becomes massive."
[IN] Voidaanko basaarityylillä aloittaa uusia hankkeita nollasta? Vastaus riippuu siitä, pystytäänkö basaarityylillä saavuttamaan todella innovatiivisia tuloksia. Jotkut väittävät, että koska työtapaan ei kuulu vahvaa projektinjohtoa, basaarimallissa pystytään vain kopioimaan ja parantelemaan ideoita, jotka ovat tuttua alan osaamista, mutta vanhojen suoritusten rajoja ei pystytä ylittämään. Ehkä kyseenalaisin yhteys, jossa tällaista on väitetty, ovat kaksi Microsoftin sisäiseen käyttöön laadittua ns. Halloween-asiakirjaa, joissa käsiteltiin avoimen lähdekoodin ilmiötä. Kirjoituksissa verrattiin Unixin kaltaisen Linuxin kehittämistä "edellä kulkevan auton valojen seuraamiseen" ja väitettiin, että kunhan Linuxin kehitystyössä on saavutettu Unixin taso, tarvitaan massiivista panostusta johtamiseen, jotta voidaan saavuttaa jotain uutta.
There are serious errors of fact implied in this argument. One is exposed when the Halloween authors themseselves later observe that "often [...] new research ideas are first implemented and available on Linux before they are available / incorporated into other platforms."
Tällaiseen päättelyyn sisältyy vakavia asiavirheitä. Yksi virhe paljastuu, kun Halloween-asiakirjan myöhemmässä osassa huomautetaan, että "usein [...] uusia tutkimusideoita toteutetaan ja tarjotaan Linuxissa ennen kuin niitä on käytettävissä muilla alustoilla."
If we read "open source" for "Linux", we see that this is far from a new phenomenon. Historically, the open-source community did not invent Emacs or the World Wide Web or the Internet itself by chasing taillights or being massively managed—and in the present, there is so much innovative work going on in open source that one is spoiled for choice. The GNOME project (to pick one of many) is pushing the state of the art in GUIs and object technology hard enough to have attracted considerable notice in the computer trade press well outside the Linux community. Other examples are legion, as a visit to Freshmeat on any given day will quickly prove.
Jos "Linux" korvataan edellisessä "avoimella lähdekoodilla" käy ilmi, että kyseessä ei ole ollenkaan uusi ilmiö. Avoimen lähdekoodin historiassa keksityt Emacs, World Wide Web tai internet eivät syntyneet muiden takavalojen seurailusta eikä niiden kehitystyön johtamisessa nyt tarvita massiivista johtamispanostusta. Avoimen lähdekoodin puolella on runsaudenpulaa innovatiivisista hankkeista. Otetaan esimerkiksi vaikka GNOME-projekti, jossa tehdään uraauurtavaa työtä graafisten käyttöliittymien kehittämisessä ja objektiteknologiassa siinä määrin, että asia on herättänyt huomiota alan lehdistössä Linux-yhteisön ulkopuolellakin. Muita esimerkkejä löytyy joka päivä pilvin pimein osoitteesta Freshmeat.
But there is a more fundamental error in the implicit assumption that the cathedral model (or the bazaar model, or any other kind of management structure) can somehow make innovation happen reliably. This is nonsense. Gangs don't have breakthrough insights—even volunteer groups of bazaar anarchists are usually incapable of genuine originality, let alone corporate committees of people with a survival stake in some status quo ante. Insight comes from individuals. The most their surrounding social machinery can ever hope to do is to be responsive to breakthrough insights—to nourish and reward and rigorously test them instead of squashing them.
On perustavaa laatua oleva virhe olettaa, että että katedraalimalli, basaarimalli tai mikä tahansa johtamisjärjestelmä voi luotettavalla tavalla johtaa innovaatioiden syntymiseen. Se on pötyä. Läpimurtoihin johtavaa näkemystä ei synny työryhmissä. Aitoa omaperäisyyttä ei ole yleensä edes basaarin vapaaehtoisilla anarkistiryhmillä. Vielä vähemmän sitä on yritysmaailman komiteoilla, joiden osallistujien ura riippuu jonkin lähtökohtatilan säilyttämisestä. Tarvittava näkemys on yksilöillä. Ympäröivät sosiaaliset koneistot voivat enintään suhtautua läpimurtoihin vastaanottavasti - murskaamisen sijasta ravita, palkita ja tiukasti testata niitä.
Some will characterize this as a romantic view, a reversion to outmoded lone-inventor stereotypes. Not so; I am not asserting that groups are incapable of developing breakthrough insights once they have been hatched; indeed, we learn from the peer-review process that such development groups are essential to producing a high-quality result. Rather I am pointing out that every such group development starts from—is necessarily sparked by—one good idea in one person's head. Cathedrals and bazaars and other social structures can catch that lightning and refine it, but they cannot make it on demand.
Joidenkin mielestä tämä kanta voi edustaa romanttista käsitystä ja merkitä paluuta vanhentuneeseen yksinäisen keksijän stereotyyppiin. Niin ei kuitenkaan ole. En väitä että ryhmät eivät pysty parantelemaan läpimurtoideoita sen jälkeen, kun joku on synnyttänyt ne. Vertaisarvioinnin prosessi osoittaa, että sellaiset kehittäjäryhmät ovat olennaisen tärkeitä korkealaatuisten tulosten saavuttamiselle. Sen sijaan esitän, että jokaisen sellaisen ryhmän saavuttama kehitysaskel alkaa väistämättä jonkin yksilön saamasta hyvästä ideasta. Katedraalit, basaarit muut sosiaaliset rakenteet voivat napata tuollaisen salamana syntyneen oivalluksen ja jalostaa sitä, mutta ryhmät eivät pysty tuottamaan sellaista aina haluttaessa.
Therefore the root problem of innovation (in software, or anywhere else) is indeed how not to squash it—but, even more fundamentally, it is how to grow lots of people who can have insights in the first place.
Ohjelmistojen kehityksessä ja muilla aloilla innovaatiotoiminnan perusongelma on varmistaa, että innovaatioita ei murskata. Ja vielä perustavampaa laatua oleva kysymys on, kuinka kasvatetaan paljon yksilöitä, jotka pystyvät tuottamaan ideoita.
To suppose that cathedral-style development could manage this trick but the low entry barriers and process fluidity of the bazaar cannot would be absurd. If what it takes is one person with one good idea, then a social milieu in which one person can rapidly attract the cooperation of hundreds or thousands of others with that good idea is going inevitably to out-innovate any in which the person has to do a political sales job to a hierarchy before he can work on his idea without risk of getting fired.
Olisi mieletöntä väittää, että katedraalityylisessä ohjelmistokehityksessä pystyttäisiin ratkaisemaan nämä ongelmat, mutta basaarissa ei, vaikka siellä yhteistyön esteet ovat matalia ja prosessit mukautuvia. Jos innovaatioiden tuottamisessa tarvitaan yksilöitä ja heidän hyviä ideoitaan, silloin sosiaalinen ympäristö, jossa yksilö voi nopeasti saada tukea sadoilta tai tuhansilta muilta ideansa toteuttamisessa, tulee väistämättä tuottamaan enemmän innovaatioita kuin ympäristö, jossa yksilön on saatava ideansa myydyksi hierarkisille organisaatioille, ennen kuin hän voi käydä työstämään ideaansa pelkäämättä potkujen saamista.
And, indeed, if we look at the history of software innovation by organizations using the cathedral model, we quickly find it is rather rare. Large corporations rely on university research for new ideas (thus the Halloween Documents authors' unease about Linux's facility at coopting that research more rapidly). Or they buy out small companies built around some innovator's brain. In neither case is the innovation native to the cathedral culture; indeed, many innovations so imported end up being quietly suffocated under the "massive level of management" the Halloween Documents' authors so extol.
Ja todellakin jos tarkastellaan katedraalimallia käyttävien organisaatioiden ohjelmistoinnovaatioita, huomataan että niitä on aika harvassa. Suuret yritykset nojautuvat uusien ideoiden hankinnassa yliopistoissa tehtävään tutkimukseen, mikä selittää Halloween-asiakirjojen huolen siitä, että Linux voi pystyä hyödyntämään akateemista tutkimusta niitä nopeammin. Suuret yritykset voivat myös ostaa pieniä, yksittäisten innovaattorien hengentuotteiden ympärille rakennettuja firmoja. Kummassakaan tapauksessa innovaatiot eivät ole katedraalikulttuurin tuotoksia. Monet ulkoa hankitut ideat kuitenkin lopulta tukehtuvat Halloween-asiakirjoissa suositellun "massiivisten johtamispanostuksen" painon alla.
That, however, is a negative point. The reader would be better served by a positive one. I suggest, as an experiment, the following:
Ilmaisin asian kielteisesti, mutta lukija ansaitsee rakentavamman näkökulman. Ehdotan sen vuoksi seuraavankaltaista koetta:
- Pick a criterion for originality that you believe you can apply consistently. If your definition is "I know it when I see it", that's not a problem for purposes of this test.
- Pick any closed-source operating system competing with Linux, and a best source for accounts of current development work on it.
- Watch that source and Freshmeat for one month. Every day, count the number of release announcements on Freshmeat that you consider 'original' work. Apply the same definition of `original' to announcements for that other OS and count them.
- Thirty days later, total up both figures.
- Valitse jokin kriteeri, jolla voi arvioida ohjelmistotuotteiden omaperäisyyttä ja jota voi soveltaa johdonmukaisesti. Jos valitset kriteeriksi "Tuote on omaperäinen, kun se näyttää semmoiselta", se kelpaa tässä hyvin.
- Valitse mikä tahansa Linuxin kanssa kilpaileva, suljettu käyttöjärjestelmä ja paras lähde, jossa ilmoitetaan sille laadituista uusista ohjelmista.
- Seuraa kyseistä lähdettä ja Freshmeat-sivustoa kuukauden ajan. Laske, kuinka monesta kriteerisi mukaisesta 'omaperäisestä' ohjelmistotuotteesta kummassakin lähteessä ilmoitetaan kunakin päivänä.
- Kuukauden kuluttua laske yhteen kunkin päivän tulokset.
The day I wrote this, Freshmeat carried twenty-two release announcements, of which three appear they might push state of the art in some respect, This was a slow day for Freshmeat, but I will be astonished if any reader reports as many as three likely innovations a month in any closed-source channel.
Sinä päivänä, kun kirjoitin tämän, Linuxin Freshmeat-sivustolle kertyi 22 uutta ilmoitusta, ja niistä kolme vaikutti sellaiselta, että niissä ylitettiin alan aiempi osaamistaso. Oli hiljaista Freshmeatin normaalipäivään verrattuna, mutta hämmästyisin, jos kukaan lukija pystyy havaitsemaan edes kolmea todennäköistä innovaatiota kuukaudessa missä tahansa suljettua käyttöjärjestelmää koskevassa lähteessä.
[EGCS] We now have history on a project that, in several ways, may provide a more indicative test of the bazaar premise than fetchmail; EGCS, the Experimental GNU Compiler System.
[EGCS] Nyt käytettävissä on tiedot projektista, joka voi monella tapaa olla parempi testi basaarimallin toimivuudesta kuin Fetchmail. Kyseessä on EGCS (Experimental GNU Compiler System) eli GNU-projektin alkujaan kokeellinen kääntäjäohjelmisto.
This project was announced in mid-August of 1997 as a conscious attempt to apply the ideas in the early public versions of The Cathedral and the Bazaar. The project founders felt that the development of GCC, the Gnu C Compiler, had been stagnating. For about twenty months afterwards, GCC and EGCS continued as parallel products—both drawing from the same Internet developer population, both starting from the same GCC source base, both using pretty much the same Unix toolsets and development environment. The projects differed only in that EGCS consciously tried to apply the bazaar tactics I have previously described, while GCC retained a more cathedral-like organization with a closed developer group and infrequent releases.
Projekti julkaistiin vuoden 1997 elokuun puolivälissä. Tarkoituksena oli tietoisesti soveltaa ideoita, joita oli esitetty esseen Katedraali ja basaari varhaisissa versioissa. Kääntäjää kehitettiin jo GCC-projektissa (Gnu C Compiler), mutta uuden projektin perustajien mielestä sen kehitys oli jämähtänyt paikoilleen. Noin 20 kuukauden ajan GCC ja EGCS -projektit toimivat rinta rinnan. Molemmissa hyödynnettiin internetin piirissä toimivaa kehittäjäyhteisöä, molemmissa lähtökohtana oli GCC:n alkuperäinen lähdekoodi, ja molemmissa Unix-työkalut ja kehitysympäristöt olivat samantapaisia. Ainoa ero oli, että EGCS-projektissa käytettiin tietoisesti kuvaamaani basaarimenetelmää, kun taas GCC:ssä työ oli organisoitu katedraalin tapaan. Siinä kehitysryhmä oli suljettu ja julkistukset epäsäännöllisiä.
This was about as close to a controlled experiment as one could ask for, and the results were dramatic. Within months, the EGCS versions had pulled substantially ahead in features; better optimization, better support for FORTRAN and C++. Many people found the EGCS development snapshots to be more reliable than the most recent stable version of GCC, and major Linux distributions began to switch to EGCS.
Syntyi tilanne, jota lähemmäksi ei koetta suunnitellen juuri voisi päästä, ja tulokset olivat hätkähdyttäviä. Muutamassa kuukaudessa EGCS-versiot olivat ohittaneet kilpailijan ohjelmiston ominaisuuksien, optimoinnin sekä FORTRAN- ja C++ -tuen suhteen. Uusimmatkin EGCS-versiot vaikuttivat monesta luotettavammilta kuin GCC:n vakaiksi luokitellut versiot. Tärkeimmissä Linux-jakeluissa alettiin siirtyä käyttämään EGCS:ä.
In April of 1999, the Free Software Foundation (the official sponsors of GCC) dissolved the original GCC development group and officially handed control of the project to the the EGCS steering team.
Vuoden 1999 huhtikuussa GCC:n virallinen sponsori Free Software Foundation hajotti GGC-projektiryhmän ja siirsi kääntäjän kehitystyön EGCS:n ohjausryhmälle.
[SP] Of course, Kropotkin's critique and Linus's Law raise some wider issues about the cybernetics of social organizations. Another folk theorem of software engineering suggests one of them; Conway's Law—commonly stated as "If you have four groups working on a compiler, you'll get a 4-pass compiler". The original statement was more general: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." We might put it more succinctly as "The means determine the ends", or even "Process becomes product".
[SP] Kropotkinin esittämän kritiikin ja Linuksen lain perusteella voidaan nostaa esille laajoja kysymyksiä sosiaalisten organisaatioiden kybernetiikasta. Yksi kysymys liittyy ohjelmistotekniikan kansanteoreemaan, joka tunnetaan Conwayn lakina. Se esitetään yleensä muodossa "Jos kääntäjää kehittää neljä työryhmää, saadaan kääntäjä, joka tekee työn neljä kertaa". Alun perin laki ilmaistiin yleisemmässä muodossa: "Järjestelmiä suunnittelevat organisaatiot ohjautuvat tuottamaan järjestelmiä, joiden rakenne on organisaatioiden vuorovaikutusrakenteen kopio." Lyhyemmin sanottuna "keinot määrittelevät päämäärän" tai jopa "prosessista tulee tuote".
It is accordingly worth noting that in the open-source community organizational form and function match on many levels. The network is everything and everywhere: not just the Internet, but the people doing the work form a distributed, loosely coupled, peer-to-peer network that provides multiple redundancy and degrades very gracefully. In both networks, each node is important only to the extent that other nodes want to cooperate with it.
Kannattaa vastaavasti huomata, että avoimen lähdekoodin ympäristössä työn organisointimuoto ja tehtävät vastaavat toisiaan monella tasolla. Yhteistyön verkosto on kaikki ja kaikkialla. Se ei ole ainoastaan internet. Työhön osallistuvat yksilöt muodostavat hajautetun, löyhästi yhdistävän, keskenään tasavertaisten osallistujien verkoston, joka luo pelivaraa ja tarvittaessa purkaantuu ongelmitta. Molemmissa verkostoissa silmulla on merkitystä vain, jos muut haluavat tehdä yhteistyötä sen kanssa.
The peer-to-peer part is essential to the community's astonishing productivity. The point Kropotkin was trying to make about power relationships is developed further by the 'SNAFU Principle': "True communication is possible only between equals, because inferiors are more consistently rewarded for telling their superiors pleasant lies than for telling the truth." Creative teamwork utterly depends on true communication and is thus very seriously hindered by the presence of power relationships. The open-source community, effectively free of such power relationships, is teaching us by contrast how dreadfully much they cost in bugs, in lowered productivity, and in lost opportunities.
Tasavertaisten osallistujien yhteistyö on avoimen lähdekoodin yhteisön hämmästyttävän tuottavuuden on olennainen tekijä. Kropotkin yritti ilmaista valtasuhteista jotain, mistä kertoo periaate 'Tilanne normaali - kaikki pielessä' (engl. SNAFU): "Totuudenmukainen kommunikointi on mahdollista vain tasavertaisten välillä, koska alaisia palkitaan johdonmukaisemmin miellyttävien valheiden kuin totuuden kertomisesta ylemmilleen." Luova tiimityö on täysin riippuvaista totuudenmukaisesta vuorovaikutuksesta, joten valtasuhteet haittaavat sitä vakavasti. Avoimen lähdekoodin yhteisössä valtasuhteita ei itse asiassa ole, ja sen antama vertailukohta auttaa ymmärtämään, kuinka kalliiksi valtasuhteet tulevat virheiden, vähentyneen tuottavuuden ja menetettyjen mahdollisuuksien takia.
Further, the SNAFU principle predicts in authoritarian organizations a progressive disconnect between decision-makers and reality, as more and more of the input to those who decide tends to become pleasant lies. The way this plays out in conventional software development is easy to see; there are strong incentives for the inferiors to hide, ignore, and minimize problems. When this process becomes product, software is a disaster.
SNAFU-periaate ennustaa, että autoritaarisissa organisaatioissa kuilu päättäjien todellisuuden välillä kasvaa jatkuvasti, kun yhä suurempi osa päätöksentekijöiden saamasta tiedosta on miellyttävää valetta. On helppo nähdä, että tämä pätee tavanomaisessa ohjelmistonkehityksessä. Alaisilla on hyviä syitä piilottaa, jättää huomiotta ja vähätellä ongelmia. Kun tällaisesta prosessista tulee ohjelmistotuote, tuloksena on katastrofi.