The Importance of Having Users
Käyttäjillä on väliä
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.
Olin siis perinyt POP-asiakasohjelman kehitysvastuun. Samalla olin saanut kontolleni ohjelman käyttäjäkunnan. Käyttäjät ovat hieno asia. He ovat merkki siitä, että tehdylle työlle on tarvetta ja että on tehnyt ainakin jotain oikein. Oikein vaalittuina käyttäjistä voi tulla yhteistyökumppaneita.
'Käyttäjien merkittävä asema' olisi otsikolle kankea käännös; käyttäjistä puhutaan alkuperäisessä tekstissä ystävällisen ironiseen sävyyn, niin myös alkuperäisessä otsikossa joka viittaa Oscar Wilden näytelmään. Alla kommentteja aikaisempaan versioon - Jopi.
Kultivointi tiputettu pois.. Tein mahdollisimman sanatarkan käännöksen, tässä vaiheessa ei ymmärtääkseni ollut vielä tarkoituskaan tehdä muuta?; "Properly cultivated" - oikein vaalittu, kohdeltu, koulittu; nyt käännös on koko lailla alkutekstin kaltainen, mutta silti suomea 5.12.2008 (JP)
Muuttaisin: "...että he antavat merkin siitä" muotoon "...että he osoittavat sen"
Another strength of the Unix tradition, one that Linux pushes to a happy extreme, is that a lot of users are hackers too. Because source code is available, they can be effective hackers. This can be tremendously useful for shortening debugging time. Given a bit of encouragement, your users will diagnose problems, suggest fixes, and help improve the code far more quickly than you could unaided.
Monet käyttäjät ovat myös itse hakkereita. Se on yksi Unix-perinteen vahvuus, jota Linux hyödyntää äärimmäisyyksiin asti. Jos lähdekoodi on saatavilla, käyttäjistä voi tulla aikaansaavia hakkereita. Tämä on valtavan hyödyllistä ohjelmistovirheiden korjaamisessa. Kun käyttäjiä hieman rohkaisee, heiltä syntyy ongelmien diagnooseja, korjausehdotuksia ja koodin parannusehdotuksia paljon nopeammin kuin yksin toimivalta koodinkehrääjältä.
Another = ei aina 'toinen' vaan 'vielä yksi' - Jopi.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
6. Käyttäjien kohteleminen yhteistyökumppaneina on nopein tie parantaa ohjelmistojen laatua ja korjata niiden virheitä.
Suomessa ei taida olla suoraa käännöstä co-developer -sanalle, mutta suomessa on samaa tarkoittava sana yhteistyökumppani.
The power of this effect is easy to underestimate. In fact, pretty well all of us in the open-source world drastically underestimated how well it would scale up with number of users and against system complexity, until Linus Torvalds showed us differently.
Yhteistyön voimaa tulee helposti aliarvioineeksi. Meistä avoimen lähdekoodin tekijöistä tuskin kukaan ymmärsi, kuinka hyvin yhteistyö toimii silloinkin, kun käyttäjien määrä on suuri ja ohjelmisto monimutkaista. Sitten Linus Torvalds todisti sen.
Alla kommentti aiempaan versioon: - Jopi. open-source-maailmassa => open-source -maailmassa
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: I'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 famously wrote of one of his characters, too lazy to fail.
Ehkäpä Linuksen fiksuin ja merkittävin keksintö ei ollutkaan Linux-ytimen rakentaminen, vaan Linuxin kehitysmallin luominen. Kun kerran esitin tämän arvion Linuksen ollessa paikalla, hän hymyili ja sanoi hiljaa jotain, jota hän on usein esittänyt: "Olen pohjimmiltani laiska ihminen, mutta minusta on kiva ottaa kunnia muiden tekemästä työstä." Laiska kuin kettu. Tai liian laiska epäonnistumaan, kuten Robert Heinlein kirjoitti eräästä henkilöhahmostaan.
Alla kommentteja vanhaan versioon - Jopi. enpä keksi parempaa taivutusta sanalle 'hack' - hakki on kyllä huono käännös, kursivoitu hack kelvannee? - korvasin hack-sanan keksinnöllä, sillä tuntuisi sopivan tuohon kohtaan
yhdyssanavirhe: läsnä ollessaan => läsnäollessaan
Olisiko enemmän suomea "laiska kuin laiskamato"?
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 cathedral-building style of the Emacs C core and most other GNU 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.
Linuxin menetelmien ja menestyksen edeltäjänä voi pitää GNU Emacsin Lisp-kirjaston ja koodiarkiston kehitystyötä. Vastakohtana Emacsin C-ytimen sekä useimpien muiden GNU-työkalujen katedraali-tyyppiselle rakennustyylille Lispin kehitys oli epämuodollista ja käyttäjävetoista. Ideat prototyypitettiin usein kolmeen tai neljään kertaan ennen kuin päästiin vakaaseen, lopulliseen muotoon. Internetin mahdollistamat väljät yhteistyösuhteet olivat yleisiä.
Alla kommentti vanhaan versioon: - Jopi. 'And loosely-coupled collaborations' en kyllä saa tuota käännettyä järkevästi. "Väljälti toimiva yhteistyö"?
Indeed, my own most successful single hack previous to fetchmail was probably Emacs VC (version control) 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 Free Software Foundation) I have met to this day. It was a front-end for SCCS, RCS and later CVS from within Emacs that offered "one-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.
Menestyksekkäin tuotokseni ennen Fetchmailia oli luultavasti juuri Emacsin VC- eli versionhallintatila. Se syntyi sähköpostiyhteistyönä kolmen muun kehittäjän kanssa. Tähän mennessä olen tavannut heistä vain yhden, Richard Stallmanin. Hän on Emacsin luoja ja Free Software Foundationin perustaja. Kyseinen ohjelma toimi edustana SCCS:lle, RCS:lle sekä CVS:lle, joihin Emacs tämän ohjelman avulla tarjosi yksinkertaisen käyttöliittymän. Ohjelma muokkautui jonkun muun tekemästä pienestä, karkeasta sccs.el-ohjelmasta. VC:n kehitystyö onnistui, koska Emacsin Lisp -koodi läpäisi kehitys-, testaus-, ja julkaisuvaiheet nopeasti, mihin ei ollut mahdollisuutta Emacsin rakentamisessa.
The Emacs story is not unique. There have been other software products with a two-level architecture and a two-tier user community that combined a cathedral-mode core and a bazaar-mode toolbox. One such is MATLAB, a commercial data-analysis and visualization tool. Users of MATLAB and other products with a similar structure invariably report that the action, the ferment, the innovation mostly takes place in the open part of the tool where a large and varied community can tinker with it.
Emacsin tarina ei ole ainutkertainen. On muitakin ohjelmistotuotteita, joiden arkkitehtuuri on kaksikerroksinen ja käyttäjäkunta kaksitahoinen. Näissä tuotteissa on sekä katedraali-tyyppinen ydin että basaari-tyyppisiä työkaluja. Yksi esimerkki on MATLAB, joka on mm. datan analysointiin ja visualisointiin tarkoitettu kaupallinen tuote. Tällaisten ohjelmistojen kehityksessä säpinä ja innovaatiot saavat yleensä alkunsa avoimen yhteistyön piirissä kehitetyissä työkaluissa, joiden koodia pääsee näpräämään laaja ja monialainen käyttäjäkunta.
Voisiko olla "jotka yhdistivät katedraali-tilan ja basaari-tilan työkalupakit." sijaan "joissa yhdistyi katedraali-tavan ydin basaari-tavan työkalupakkiin."