The Social Context of Open-Source Software
Avoimen lähdekoodin sosiaalinen puoli
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:
Kirjoitettu on, että hakkereiden parhaat luomukset syntyvät vastauksena tekijöidensä arkipäivän ongelmiin ja yleistyvät, jos samat ongelmat koskevat laajaa käyttäjäjoukkoa. Näin päästään takaisin 1. sääntöön, joka voidaan muotoilla paremmin näin:
"Hacks" - hakkeriniksit (ehdotus)
'Truly' tuo mieleen hieman raamatullista tyyliä, sen takia ehdotan käännökseksi 'Kirjoitettu on'. 'Hack' on vähän ironinen, joten käännökseksi voisi sopia 'luomus'. - Jopi
18. To solve an interesting problem, start by finding a problem that is interesting to you.
18. Jotta voisi ratkaista mielenkiintoisen ongelman, on etsittävä ongelma joka on lähellä omaa sydäntä.
Oheisessa kappaleessa mukava idea edeltäjiltä on käyttää ilmausta 'lähellä sydäntä'. - Jopi
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.
Tämä toteutui Carl Harrisin muinaisen POP-asiakasohjelman tapauksessa, samoin itseni ja Fetchmailin kohdalla. Se kaikki on jo yleistä tietoa. Linuxin ja Fetchmailin kehityshistoria kuitenkin pakottaa kiinnittämään huomiota siihen, mitä tapahtuu seuraavassa vaiheessa, kun ohjelmaa alkaa kehittää mittava ja aktiivinen käyttäjien ja kehittäjien yhteisö.
"Ancestral" - esi-isiltä peritty, ei niinkään muinainen; käänsin "esikuvallinen"; Mielestäni Fetchmail pitäisi kirjoittaa suomen oikeinkirjoitussääntöjen mukaan - isolla
Hyvä, tässä kuitenkin muinainen tuntuu sopivan tyyliin hyvin. - Jopi
In The Mythical Man-Month, Fred Brooks observed that programmer time is not fungible; adding developers to a late software project makes it later. As we've seen previously, 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. Brooks's Law has been widely regarded as a truism. But we've examined in this essay an number of ways in which the process of open-source development falsifies the assumptionms behind it—and, empirically, if Brooks's Law were the whole picture Linux would be impossible.
Fred Brookshan totesi 'myyttistä miestyökuukautta' koskevassa esseessään, että ohjelmointityössä kyse ei ole pelkästä määrästä. Jos myöhässä olevaan projektiin palkataan lisää kehittäjiä, syntyy vain lisäviivettä. Projektin monimutkaisuus ja tiedonvälityksen hankaluudet kasvavat suhteessa kehittäjien määrän neliöön, kun taas työn tulos kasvaa vain suorassa suhteessa siihen. Brooksin lakia on alettu pitää selviönä. Tässä kirjoituksessa on kuitenkin osoitettu, että on useita syitä, joiden takia lain taustaoletukset eivät päde avoimen lähdekoodin kehitystyössä. Empiirisen todisteen lain yleispätemättömyydestä tarjoaa Linux. Linux ei olisi mahdollinen, jos Brooksin laki olisi koko totuus.
Vakioteholla tehty työ kasvaa lineaarisesti, mikäli teho kasvaa, kasvaa tehty työ nopeammin.
Edellinen huomio pätee, jos puhutaan fysiikan työ- ja teho-käsitteestä. Inhimillisen työn tuottavuutta kuvaa paremmin tuotantofunktio. Tämänkin kappaleen käännöksessä Brooks oli kirjoitettu kahdesti väärin, joten muistetaan oikolukea huolellisesti. Ajattelin kääntää tähän Brooksin kirjan nimen epäsuorasti, niin lukijan ei tarvitse pähkäillä englanninkielisen nimen merkityksen kanssa. - Jopi.
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 "egoless 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. (Recently, Kent Beck's `extreme programming' technique of deploying coders in pairs looking over one anothers' shoulders might be seen as an attempt to force this effect.)
Brooksin lain pätevyyttä rajoitti jo havainto, jonka Gerald Weinberg esitti klassikossaan "The Psychology of Computer Programming". Käsitellessään 'itsekeskeisyydestä vapaata ohjelmointia' Weinberg totesi, että ympäristöissä, joissa kehittäjät eivät suhtaudu koodiinsa omistushaluisesti vaan rohkaisevat toisiaan etsimään virheitä ja esittämään parannusehdotuksia, ohjelmistojen laatu kohenee selvästi nopeammin kuin toisenlaisissa oloissa. Kent Beckin esittämässä 'ohjelmointi extreme-lajina' menetelmässä pyritään samaan suuntaan. Siinä koodia tuotetaan kahden ohjelmoijan pareissa, joissa ohjelmoijat seuraavat toistensa työtä.
Sulkeet auki
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 "egoless". But I think his argument looks more compelling today than ever.
Weinbergin sanavalinnat ovat saattaneet estää hänen näkemyksiään tulemasta niin laajalti hyväksytyksi kuin ne ansaitsisivat. Ei voi muuta kuin hymyillä ajatukselle itsekeskeisyydestä vapaasta hakkerista. Silti Weinbergin argumentointi on tänään vakuuttavampaa kuin koskaan.
-Internet-hakkeri? ehkä sujuvampi olisi puhua vain hakkerista, internet-viittaus tuntuu aika itsestäänselvältä...
The bazaar method, by harnessing the full power of the "egoless programming" effect, strongly mitigates the effect of Brooks's Law. The principle behind Brooks's Law is not repealed, but given a large developer population and cheap communications its effects can be swamped by competing nonlinearities that are not otherwise visible. This resembles the relationship between Newtonian and Einsteinian physics—the older system is still valid at low energies, but if you push mass and velocity high enough you get surprises like nuclear explosions or Linux.
Basaarimenetelmä valjastaa käyttöönsä epäitsekeskeisen ohjelmoinnin koko potentiaalin. Se laimentaa Brooksin lain vaikutusta. Lain periaate ei kumoudu, mutta laaja kehittäjäyhteisö ja halvat viestintämenetelmät vesittävät sen kielteisiä vaikutuksia. Basaarimallissa niitä vastaan toimii epälineaarisia voimia, joita olisi muussa yhteydessä vaikea havaita. Tilanne muistuttaa Newtonin ja Einsteinin fysiikan suhdetta. Vanha ajatusmalli pätee alhaisilla energiatasoilla, mutta kun massat ja nopeudet nousevat tarpeeksi suuriksi, syntyy ydinräjähdyksen tai Linuxin kaltaisia yllätyksiä.
Brooks oli jälleen kirjoitettu väärin, ollaan oikoluvussa tarkkana. -Jopi
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 [EGCS]). That is, 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 feedback exploring the design space, code contributions, bug-spotting, and other improvements come from from hundreds (perhaps thousands) of people.
Unixin historian olisi pitänyt valmistaa siihen, mitä olemme oppimassa Linuxista. Todensin tuloksen pätevyyden itsekin, kun sovelsin Linuksen menetelmiä käytäntöön pienessä mittakaavassa [EGCS]. Ohjelmointi on luonteeltaan yksinäistä puuhaa, mutta todella suuria luomuksia syntyy vasta, kun työhön valjastetaan kokonaisten yhteisöjen huomio ja ongelmanratkaisukyky. Ohjelmistokehittäjä, joka käyttää vain omia aivojaan muilta suljetussa projektissa ei pärjää kollegalle, joka osaa luoda satojen tai ehkä tuhansien ihmisten kehittäjäyhteisön. Se tuottaa palautetta, tutkii kehitysmahdollisuuksia, naputtaa ohjelmistokoodia, raportoi virheistä ja kehittää muita parannuksia.
Kirjoitin sulkeet auki; "Hack", hakki, olisi ehkä parempi suomentaa
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 commercial interests. Another (in hindsight) was that the Internet wasn't yet good enough.
Monien tekijöiden vaikutuksesta uutta työtapaa ei voitu toteuttaa täydessä mittakaavassa perinteisessä Unix-maailmassa. Yksi syy olivat lakitekniset esteet, joita erilaiset lisenssit, liikesalaisuudet ja kaupalliset etunäkökohdat synnyttivät. Jälkikäteen on nähtävissä, että myös internetin kehittymättömyys vaikutti.
Jätin "various" kääntämättä, koska monikko ilmaisee saman asian; "Licence" - lupaehto, lisenssi, sopimus
Before cheap Internet, there were some geographically compact communities where the culture encouraged Weinberg's "egoless" programming, and a developer could easily attract a lot of skilled kibitzers and co-developers. Bell Labs, the MIT AI and LCS labs, UC Berkeley—these became the home of innovations that are legendary and still potent.
Ennen halpojen internet-yhteyksien aikaa oli joitakin yksittäisiä paikkakuntia, joissa Weinbergin epäitsekeskeinen ohjelmointi kukoisti. Niissä ohjelmistohankkeeseen sai helposti mukaan touhuajia ja ammattitaitoisia kehittäjiä. Bellin Laboratorio, MIT:n tekoälylaboratorio ja tietokonelaboratorio sekä Kalifornian yliopiston Berkeleyn kampus tuottivat legendaarisia ja yhä käyttökelpoisia innovaatioita.
"Kibitzer" - käänsin näppisormeksi, takapiru vaikuttaa oudolta; jokin puolileikillinen ilmaisu käynee; avasin osan lyhenteistä Kokeilinpa vaihtaa näppisormen touhuajaksi, sekin lienee puolileikillinen ilmaisu; "Egoless" voisi kääntyä minäpakoiseksi tai minättömäksi, jolloin se pitäisi selittää ensimmäisellä kerralla
--minätön kuulostaa hyvältä
--Tuo kibitzer on kyllä niin outu ilmaus, että sen vois ottaa alaviitteenä mukaan lopulliseen.
Ks. en.wikipedia.org/wiki/Kibitzer - Jopi
Linux was the first project for which a conscious and successful effort to use the entire world as its talent pool was made. I don't think it's a coincidence that the gestation period of Linux coincided with the birth of the World Wide Web, and that Linux left its infancy during the same period in 1993–1994 that saw the takeoff of the ISP industry and the explosion of mainstream interest in the Internet. Linus was the first person who learned how to play by the new rules that pervasive Internet access made possible.
Linux oli ensimmäinen projekti, jossa yritettiin tietoisesti käyttää koko maailmaa kehittäjäyhteisönä ja onnistuttiin siinä. Ei liene sattuma, että Linux kypsyi samoihin aikoihin kuin World Wide Web syntyi, eikä sekään että Linux nousi jaloilleen vuosina 1993 - 1994, jolloin kaupalliset internet-yhtiöt lähtivät nousukiitoon ja suuri yleisö kiinnostui internetistä. Linus oppi ensimmäisenä, kuinka pelataan niillä uusilla säännöillä, joita yleistyneet internet-yhteydet toivat mukanaan.
"Talent pool" - voitaisiinko ajatella käännöstä "aivoriihi" vs. "kykypooli" (vaikka ei olekaan alkutekstissä brain storming)?; "Gestation period" - hautomisaika (kuin linnuilla, pingviineilläkin)
While cheap Internet was a necessary condition for the Linux model to evolve, I think it was not by itself a sufficient condition. Another vital factor was the development of a leadership style and set of cooperative customs that could allow developers to attract co-developers and get maximum leverage out of the medium.
Halvat internet-yhteydet olivat Linux-toimintamallin kehittymisen välttämätön, mutta eivät riittävä ehto. Tarvittiin myös sopivaa ohjelmistokehityksen johtamistyyliä ja yhteistyötapoja, joilla kehittäjät pystyivät vetämään mukaan apukehittäjiä ja käyttämään hyväkseen internetin tarjoamat mahdollisuudet.
But what is this leadership style and what are these customs? They cannot be based on power relationships—and even if they could be, leadership by coercion would not produce the results we see. Weinberg quotes the autobiography of the 19th-century Russian anarchist Pyotr Alexeyvich Kropotkin's Memoirs of a Revolutionist to good effect on this subject:
Mitä johtamistyyliä ja yhteistyötapoja tarvittiin? Perustana eivät voineet olla valtasuhteet. Jos pakottaminen olisikin ollut mahdollista, sillä ei olisi päästy toteutuneen kaltaisiin tuloksiin. Weinberg siteerasi sattuvasti 1800-luvun venäläisen anarkistin Pjotr Kropotkinin omaelämäkertaa Anarkistin muistelmat:
Having been brought up in a serf-owner's family, I entered active life, like all young men of my time, with a great deal of confidence in the necessity of commanding, ordering, scolding, punishing and the like. But when, at an early stage, I had to manage serious enterprises and to deal with [free] men, and when each mistake would lead at once to heavy consequences, I began to appreciate the difference between acting on the principle of command and discipline and acting on the principle of common understanding. The former works admirably in a military parade, but it is worth nothing where real life is concerned, and the aim can be achieved only through the severe effort of many converging wills.
"Minut oli kasvatettu maaorjia omistaneessa perheessä. Kun astuin työelämään, uskoin muiden sukupolveni nuorten miesten tapaan komentamisen, määräämisen, nuhtelemisen, rankaisemisen ja vastaavien keinojen tarpeellisuuteen. Varhaisessa vaiheessa jouduin kuitenkin johtamaan merkittäviä työhankkeita ja tulemaan toimeen vapaiden miesten kanssa. Mikä tahansa virhe olisi voinut aiheuttaa välittömästi vakavia seurauksia. Silloin aloin ymmärtää, mikä ero on toisaalta käskyttämiseen ja kuriin ja toisaalta yhteisymmärrykseen perustuvan toiminnan välillä. Edellinen tuottaa ihailtavia tuloksia sotilasparaatissa, mutta on arvotonta tosielämässä, jossa tavoitteisiin ylletään vain monien tahtojen yhteisten, ankarien ponnistusten tuloksena.
"Serf-owner" - maaorjien omistaja, käänsin maaorjat "torppareiksi"; palautin käännökseen maaorjat, koska olikin lainaus Kropotkinin kirjasta; muokkauskonflikti - otin mukaan olennaisen toisesta
The "severe effort of many converging wills" is precisely what a project like Linux requires—and the "principle of command" is effectively impossible to apply among volunteers in the anarchist's paradise we call the Internet. To operate and compete effectively, hackers who want to lead collaborative projects have to learn how to recruit and energize effective communities of interest in the mode vaguely suggested by Kropotkin's "principle of understanding". They must learn to use Linus's Law.[SP]
Linuxin kaltaisissa hankkeissa tarvitaan "monien tahtojen yhteisiä ankaria ponnistuksia", mutta anarkistien ihmemaan, internetin vapaaehtoisten käskyttäminen ei ole mahdollista. Kehittäjien jotka haluavat vetää yhteistyöprojekteja on opittava värväämään ja sähköistämään vapaaehtoisten yhteisöjä Kropotkinin kuvaamalla yhteisymmärryksen periaatteella. Kehittäjien on opittava soveltamaan Linuksen lakia. [SP]
Earlier I referred to the "Delphi effec" as a possible explanation for Linus's Law. But more powerful 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".
Aiemmin viittasin Delfoi-ilmiöön mahdollisena Linuksen lain selityksenä. Väistämättä mieleen tulee kuitenkin parempiakin esimerkkejä sopeutuvista järjestelmistä biologian ja talouden piiristä. Linux-maailma käyttäytyy monessa suhteessa vapaiden markkinoiden tai ekosysteemin tavoin. Joukko itsekkäitä toimijoita pyrkii maksimoimaan hyvinvointinsa, mutta prosessissa muodostuu itseään korjaava spontaani järjestys, joka on monitahoisempi ja tehokkaampi kuin mikään keskitettyyn suunnitteluun perustuva järjestelmä. Tässä onkin sopiva kohta tarkastella yhteisymmärryksen periaatetta.
The "utility 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 "altruistic", 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 has long explicitly recognized "egoboo" (ego-boosting, or the enhancement of one's reputation among other fans) as the basic drive behind volunteer activity.
Se "hyvinvointifunktio", jota Linuxin kehittäjät maksimoivat, ei kuulu klassisen taloustieteen piiriin, vaan se perustuu työn antamaan aineettomaan henkiseen tyydytykseen ja muiden kehittäjien piirissä saatuun maineeseen. (Joku voi sanoa tällaista motivaatiota epäitsekkääksi, mutta epäitsekkyys on henkisen tyydytyksen hankkimiskeino sille, joka on epäitsekäs.) Vapaaehtoisuus ei olekaan harvinaista; olen itse osallistunut pitkään myös tieteiskirjallisuuteen liittyvään fanitoimintaan. Sen piirissä toiminnan perimmäiseksi energianlähteeksi on jo kauan tunnustettu noste, jota oma ego ja maine muiden fanien keskuudessa saavat siitä.
Linus, by successfully positioning himself as the gatekeeper of a project in which the development is mostly done by others, and nurturing interest in the project until it became self-sustaining, has shown an acute grasp of Kropotkin's "principle of shared understanding". This quasi-economic view of the Linux world enables us to see how that understanding is applied.
Linus osoitti Kropotkinin yhteisymmärryksen periaatteen terävää hallintaa, kun hän asettui portinvartijaksi hankkeeseen, jossa kehitystyön tekevät pääasiassa muut. Linus varmisti, että projekti säilytti vetovoimansa, kunnes siitä tuli itseään ylläpitävä. Kun Linux-maailmaa tarkastellaan virtuaalitaloutena nähdään, miten yhteisymmärryksen periaatetta on sovellettava.
We may view Linus's method as a way to create an efficient market in "egoboo"—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.
Linuksen menetelmää voi pitää keinona luoda ego-nosteen markkinat. Menetelmässä kunkin kehittäjän kunnianhimo kytketään mahdollisimman lujasti tavoitteisiin, jotka ovat vaikeita ja jotka voidaan saavuttaa vain pitkäkestoisella yhteistyöllä. Fetchmail-projektissani osoitin - vaikkakin pienemmässä mittakaavassa - että Linuksen menetelmää voi matkia hyvin tuloksin. Taisinpa vielä soveltaa menetelmää hieman tietoisemmin ja järjestelmällisemmin kuin Linus.
Many people (especially those who politically distrust free markets) would expect a culture of self-directed egoists to be fragmented, territorial, wasteful, secretive, and hostile. But this expectation is clearly falsified by (to give just one example) the stunning variety, quality, and depth of Linux documentation. It is a hallowed given that programmers hate documenting; how is it, then, that Linux hackers generate so much documentation? Evidently Linux's free market in egoboo works better to produce virtuous, other-directed behavior than the massively-funded documentation shops of commercial software producers.
Itseään ohjaavien egoistien kulttuurin voi luulla muotoutuvan pirstaleiseksi, omistushaluiseksi, tuhlailevaksi, salailevaksi ja vihamieliseksi. Näin voivat odottaa etenkin ne, jotka suhtautuvat vapaisiin markkinoihin epäluuloisesti poliittisista syistä. Luulo voidaan kuitenkin helposti osoittaa vääräksi. Tarvitsee vain katsoa Linux-dokumentaation tyrmäävää moninaisuutta, laatua ja syvyyttä. Ohjelmoijat tunnetusti inhoavat dokumentointia. Kuinka on sitten mahdollista, että Linux-kehittäjät suoltavat dokumentaatiota niin paljon? Ilmeisesti Linux-markkinoiden ego-noste motivoi tehokkaammin hyveellistä, toisten etua palvelevaa toimintaa kuin kaupallisten yritysten dokumentaatioyksiköiden yltäkylläinen rahoitus.
Both the fetchmail and Linux kernel projects show that by properly rewarding the egos of many other hackers, a strong developer/coordinator can use the Internet to capture the benefits of having lots of co-developers without having a project collapse into a chaotic mess. So to Brooks's Law I counter-propose the following:
Sekä Fetchmail että Linuxin ytimen kehitystyö osoittavat, että vahva kehittäjä/koordinaattori voi sopivasti ruokkimalla yhteistyökumppaniensa kunnianhimoa hyödyntää internetiä niin, että työhön osallistuu suuri apukehittäjien joukko ilman että projekti kaatuu kaoottiseksi sotkuksi. Joten esitän seuraavan vastaehdotuksen Brooksin laille:
Tuolle co-developerille voisi keksiä käännöksen, jota käytetään aina. Nyt sitä on käännelty miten milloinkin.
Apukehittäjä tuntuu hyvältä. Huom. Brooks oli kirjoitettu käännöksessä väärin. - Jopi.
--Tässä mainittiin ensimmäisen ja viimeisen kerran kernel, vaatisiko selittelyä, vaikkapa alaviitteenä?
19: Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
19: Jos projektin vetäjällä on käytössään ainakin internetin tasoinen yhteydenpitokeino ja jos hän tietää, miten työtä voi johtaa ilman painostuskeinoja, monta päätä on väistämättä parempi kuin yksi.
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.
Käsitykseni mukaan avoimen lähdekoodin tulevaisuuden määräävät ne, jotka osaavat pelata Linuksen peliä. He tulevat ulos katedraalista ja suuntaavat basaariin. Tulevaisuudessakin yksilöiden visioilla ja kyvyillä on väliä. Ne ovat lähtökohta, josta lähdekoodin kärkisaavutuksia käydään rakentamaan luomalla vapaaehtoisten osallistujien yhteisöjä.
aika runollista, onko hyvä?
Perhaps this is not only the future of open-source software. No closed-source 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 200 (1999: 600, 2000: 800) people who have contributed to fetchmail!
Tällainen tulevaisuudenkuva pätee ehkä muuallakin kuin avoimien lähdekoodien ohjelmistoissa. Yksikään suljetun ohjelmiston kehittäjä ei voi asettaa peliin sellaista lahjakkuuden varantoa, jonka Linux-yhteisö voi marssittaa ratkaisemaan jotain ongelmaa. Harvalla on varaa palkata edes 200 kehittäjää, mutta vuonna 1999 Fetchmailin kehitykseen osallistui 600 ja seuraavana vuonna 800 ihmistä.
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.
Avoimen lähdekoodin kulttuuri saattaa lopulta viedä voiton. Ei siksi että talkootyö on jotenkin moraalisesti oikein, kun taas suljettu työ on väärin. Itse en edes usko että niin on, eikä usko Linuskaan. Asia on vain niin, että suljetun koodin maailma ei tule pärjäämään evolutiivisessa varustelukilvassa, koska avoimen lähdekoodin yhteisö pystyy käyttämään kertalukuja enemmän henkilötyöaikaa ongelmien ratkaisemiseen.
"Software hoarding" ohjelmistojen jemmaus, so. proprietary eli suljetut, ei-vapaat ja rajoitetut ohjelmistot; "Cooperation" - käänsin talkootyöksi vs. "yhteistyö"