Karl Fogel

TVORBA OPEN SOURCE SOFTWARU

Jak řídit úspěšný projekt svobodného softwaru

Vydavatel:

CZ.NIC, z. s. p. o.

Americká 23, 120 00 Praha 2

Edice CZ.NIC

www.nic.cz

1. vydání, Praha 2012

Kniha vyšla jako 5. publikace v Edici CZ.NIC.

ISBN 978‒80‒88168‒03‒4

© 2005–2010 Karl Fogel

V licenci CreativeCommons Attribution-ShareAlike (3.0).

Karl Fogel

Tvorba open source softwaru

Jak řídit úspěšný projekt svobodného softwaru

Edice CZ.NIC

Obsah

Předmluva vydavatele

Předmluva

Proč byla tato kniha napsána?

Kdo by měl tuto knihu číst?

Zdroje

Poděkování

Prohlášení

1. Úvod

Historie

Vzestup proprietárního softwaru a svobodného softwaru

Vědomé hnutí odporu

Neúmyslné hnutí odporu

„Free“ versus „open source“

Současná situace

2. Zahájení projektu

Nejdříve se ale rozhlédněte

Začněte od toho, co máte k dispozici

Vyberte dobré jméno

Určete jasné cíle projektu

Uveďte, že jde o svobodný projekt

Seznam funkcí a požadavků

Stav vývoje

Stahování

Zpřístupnění systémů správy verzí a sledování chyb

Komunikační kanály

Pokyny pro vývojáře

Dokumentace

Dostupnost dokumentace

Dokumentace pro vývojáře

Vzorový výstup a snímky obrazovky

Kompletní hosting

Výběr licence a její uplatnění

Licence typu „vše je povoleno“

GPL

Jak licenci aplikovat

Udávání tónu

Vyhněte se soukromým diskuzím

Nezdvořilé chování potlačte hned v zárodku

Kontrolujte kód veřejně

Když otvíráte dosud uzavřený projekt, uvědomte si rozsah změn

Oznamování

3. Technická infrastruktura

Co je třeba pro projekt zajistit

Mailing listy

Ochrana před nežádoucími zprávami

Filtrování příspěvků

Skrývání adres v archivech

Identifikace a správa hlaviček

Velká debata o Reply-to

Dvě ideální řešení

Archivace

Software

Správa verzí

Slovníček pojmů správy verzí

Výběr systému pro správu verzí

Používání systému pro správu verzí

Sledujte verze u všeho

Možnost prohlížení

E-maily oznamující commit

Používejte větve, abyste nezpomalovali vývoj

Jedinečnost informace

Autorizace

Systém pro sledování chyb

Interakce s mailing listy

Předběžné filtrování v bug trackeru

IRC a jiné systémy pro diskuzi v reálném čase

Roboti

Archivace IRC

RSS

Wiki

Webové stránky

Kompletní hosting

Jak si vybrat kompletní hosting

Anonymita a zapojení se do projektu

4. Společenská a politická infrastruktura

Schopnost vytvářet odnože

Benevolentní diktátoři

Kdo může být dobrým benevolentním diktátorem?

Demokracie založená na konsenzu

Řízení verzí znamená, že můžete být v pohodě

Když nelze dosáhnout konsenzu, hlasujte

Kdy hlasovat

Kdo hlasuje?

Ankety versus hlasování

Veto

Jak to všechno zapsat

5. Peníze

Typy zapojení do projektu

Pracovníky najímejte na dlouhodobý úvazek

Vystupujte jako jednotlivci, nikoli jako celek

Otevřeně hovořte o své motivaci

Lásku si za peníze nekoupíte

Dodavatelské smlouvy

Kontrola a přijetí změn

Případová studie: protokol pro ověřování hesla CVS

Financování neprogramovacích činností

Zajišťování kvality (tj. Profesionální testování)

Právní poradenství a ochrana

Dokumentace a použitelnost

Poskytování hostingu/síťové propustnosti

Marketing

Pamatujte na to, že jste sledováni

Nekritizujte konkurenční open source produkty

6. Komunikace

Jste to, co píšete

Struktura a formátování

Obsah

Tón

Jak rozeznat hrubost

Tvář

Jak předejít častým potížím

Nepřispívejte zbytečně

Produktivní a neproduktivní vlákna

Čím jednodušší téma, tím delší debata

Vyvarujte se svatých válek

Efekt „hlučné minority“

Obtížní lidé

Jak se s obtížnými lidmi vypořádat

Případová studie

Jak se vyrovnat s růstem

Nápadné využívání archivů

Se všemi zdroji zacházejte jako s archivy

Kodifikace tradic

Nediskutujte v bug trackeru

Publicita

Ohlášení bezpečnostních chyb

Přijměte report

Opravu vyvíjejte potichu

Čísla CAN/CVE

Předběžné oznámení

Distribuujte opravu veřejně

7. Vytváření balíčků, vydávání releasů a každodenní práce na vývoji

Číslování verzí

Z čeho se číslo verze skládá

Jednoduchá strategie

Strategie sudá / lichá

Release větve

Jak release větve fungují

Stabilizace release

Diktatura vlastníka release

Hlasování o změnách

Spolupráce na stabilizaci release a jak ji řídit

Správce release

Vytváření balíčků

Formát

Jméno balíčku a adresářový strom

Velká nebo malá písmena

Pre-release

Kompilace a instalace

Binární balíčky

Testování a releasing

Release kandidát

Oznamování release

Udržování více release řad

Bezpečnostní release

Vydávání releasů a každodenní práce

Plánování releasů

8. Řízení dobrovolníků

Jak dostat z dobrovolníků to nejlepší

Delegování

Jasně rozlišujte mezi poptáváním a zadáváním

Postup po delegování

Všímejte si, o co se lidé zajímají

Pochvala a kritika

Zabraňte teritorialitě

Poměr automatizace

Automatizované testování

Ke všem uživatelům se chovejte jako k potenciálním dobrovolníkům

Podělte se o řídící i technické úkoly

Patch Manager (manažer záplat)

Translation Manager (manažer překladu)

Documentation Manager (manažer dokumentace)

Issue manager (manažer problémů)

FAQ Manager (manažer sekce s nejčastěji kladenými otázkami)

Personální změny

Committeři

Volba committerů

Odebrání commit access

Částečný commit access

Nečinní committeři

Nedělejte s ničím tajnosti

Uvádění tvůrců a spoluautorů (Credit)

Odnože (Forks)

Zvládání odnoží

Iniciování odnože

9. Licence, autorská práva a patenty

Terminologie

Aspekty licence

GPL a kompatibilita licence

Volba licence

MIT / X Window System License

GNU General Public License

Je GPL svobodná licence, či nikoli?

A co licence BSD?

Převod a vlastnictví autorských práv

Nedělat nic

Licenční smlouvy s přispěvatelem (CLA)

Převod autorských práv

Systém dvojitých licencí

Patenty

Další zdroje

A. Svobodné systémy pro správu verzí

B. Volně přístupné bug trackery (záznamníky chyb)

C. Měl bych se starat o to, jakou barvu má přístřešek pro kola?

D. Vzorové pokyny pro hlášení chyb (bugů)

E. Copyright

Licenční ujednání

Upozornění Creative Commons

Věnování

Tato kniha je věnována dvěma drahým přátelům, bez nichž by nemohla vzniknout:

Karen Underhillové a Jimovi Blandymu.

Předmluva vydavatele

Vážení čtenáři,

naše předchozí publikace v Edici CZ.NIC byly orientovány na nějakou konkrétní technologii, od technologie IPv6 přes programování v Pythonu po používání elektronických podpisu. Touto knihou jsme se vydali do trochu jiné oblasti. Přeložili jsme pro vás knihu, která se zabývá tím, jak produkovat otevřený (open-source) software. Kniha pro vás může být zajímavá ať už jste začínající programátor s dobrým nápadem nebo zavedená firma produkující již existující software.

V Edici CZ.NIC vycházejí především knihy, které jsou blízké vám ale i nám, a není tomu jinak ani v případě této knihy. Centrální registr pro správu domén FRED byl od počátku vydáván pod svobodnou licencí a díky tomu je používán i na dalších místech naší zeměkoule. Mezi poslední přírůstky mezi národními registry používající FRED můžeme zmínit například Estonsko. Stejně se chováme i k dalšímu softwaru, který je vyvíjen ve sdružení CZ.NIC – alternativní klient pro přístup do datových schránek – Datovka, velmi úspěšný projekt směrovacího daemona Bird, nebo náš poslední projekt rychlého autoritativního DNS serveru – Knot DNS.

Autor této publikace Karl Fogel není ve světě otevřeného a svobodného softwaru žádným nováčkem. Kromě psaní o otevřeném softwaru také přispívá do významných projektů jako je Launchpad, Subversion nebo GNU Emacs.

Doufáme, že tato kniha bude přínosná pro Vás a přeneseně i pro celou komunitu okolo otevřeného softwaru, protože po přečtení této knihy bude Váš další projekt pod otevřenou licencí. Přeji Vám příjemnou četbu.

Ondřej Surý

Praha, 17. ledna 2012

Předmluva

Předmluva

Proč byla tato kniha napsána?

Kdo by měl tuto knihu číst?

Zdroje

Poděkování

Prohlášení

Proč byla tato kniha napsána?

Když dnes na nějakém večírku řeknu, že píšu svobodný software, už se nesetkávám jen s prázdnými pohledy. „Aha, open source – takže něco jako Linux?“ říkají. Horlivě přikyvuji. „Přesně tak. To je můj obor.“ Je příjemné, když už vaše práce není úplně neznámá. Dříve se dalo i docela dobře předvídat, jaká otázka bude následovat: „Jak se tím dají vydělat peníze?“ Na tohle se dá odpovědět jenom shrnutím celé ekonomické situace svobodného softwaru: že existují organizace, v jejichž zájmu je, aby určitý software existoval, ale které jej nepotřebují prodávat; chtějí mít pouze jistotu, že je tento software dostupný a udržovaný – jako nástroj a ne jako zboží.

V poslední době se to ale změnilo a další otázka se ne vždy týká peněz. Obchodní stránka open source softwaru[1] už není tolik záhadná a velká část neprogramátorské veřejnosti chápe nebo přinejmenším není překvapena tím, že je možné mít v tomto oboru zaměstnání na plný úvazek. Ta otázka, která následuje, poslední dobou stále častěji zní: „To je zajímavé, ale jak to vlastně funguje?“

A na to jsem žádnou uspokojivou odpověď dlouho neměl. Čím víc jsem se snažil nějakou najít, tím víc jsem zjišťoval, jak složité téma to vlastně je. Řízení projektu svobodného softwaru je něco trochu jiného než běžné podnikání – představte si, že byste se o podobě svého produktu museli neustále dohadovat se skupinou dobrovolníků, z nichž jste většinu nikdy osobně nepotkali! Z různých důvodů se to nepodobá ani vedení klasické neziskové organizace, ani řízení vlády. Všem těmto věcem se to sice v něčem podobá, ale časem jsem dospěl k závěru, že svobodný software je entitou sui generis. Najdete mnoho věcí, k nimž jej lze celkem výstižně přirovnat, ale nic, co by bylo stejné. Ostatně už samotné tvrzení, že by bylo možné projekt svobodného softwaru nějak „řídit“, je celkem odvážné. Projekt svobodného softwaru může být nepochybně spuštěn; může být také ovlivněn zainteresovanými stranami, často velmi silně. Ale výsledky jeho práce se nemohou stát vlastnictvím žádného jednotlivce, a dokud se někde – a to naprosto kdekoliv – najdou lidé, kteří mají zájem v něm pokračovat, nemůže jej ani nikdo zastavit. Všichni mají neomezenou moc a zároveň nikdo nemá žádnou. A to vytváří zajímavou dynamiku.

Proto jsem se tedy rozhodl napsat tuto knihu. Projekty svobodného softwaru daly vzniknout jedinečné kultuře, étosu, v němž je hlavní zásadou svoboda psát software, který dělá, cokoliv budete chtít, ale kde tato zásada nevede k tomu, že by si každý psal svůj vlastní kód zcela nezávisle na ostatních, ale k nadšené spolupráci. Ostatně schopnost dobře spolupracovat s ostatními je v oblasti svobodného softwaru jednou z dovedností, které se cení nejvíc. K řízení takovýchto projektů je nutné zapojit se do jakési hypertrofní formy spolupráce, při níž může softwaru výrazně prospět jak schopnost pracovat s ostatními, tak i objevování nových způsobů takové spolupráce. Tato kniha se pokouší popsat techniky, jimiž toho lze dosáhnout. Neklade si ambice celé téma vyčerpat, ale přinejmenším je to dobrý začátek.

Dobrý svobodný software je sám o sobě hodnotným cílem a já doufám, že čtenáři, kteří hledají způsob, jak jej dosáhnout, budou s obsahem této knihy spokojeni. Ale kromě toho také doufám, že se mi podaří předat něco z té čiré radosti, jež vzniká ze spolupráce v motivovaném týmu open source vývojářů a ze sympaticky přímého kontaktu s uživateli, který se v open source projektech často objevuje. Účast na úspěšném projektu svobodného softwaru je totiž velká zábava, což je koneckonců ten hlavní důvod, proč celý systém může fungovat.

Kdo by měl tuto knihu číst?

Tato kniha je určena vývojářům softwaru a těm, kdo softwarové projekty řídí, a to ať už v situaci, kdy o spuštění projektu svobodného softwaru teprve uvažují, nebo když už nějak začali a teď si nejsou jisti, jak dál. Měla by pomoci také lidem, kteří by se do nějakého open source projektu chtěli zapojit, ale nikdy předtím nic takového nedělali.

Čtenář této knihy nemusí být nutně programátor, ale měl by znát základní koncepty softwarového inženýrství, jako je zdrojový kód, kompilátory a záplaty (patche).

Není potřeba ani mít předchozí zkušenost s open source softwarem, a to ani jako uživatel, ani jako vývojář. Těm, kteří již v projektech svobodného softwaru někdy pracovali, budou některé části knihy připadat celkem samozřejmé, takže je možná budou chtít přeskočit. Protože jsem se snažil psát pro potenciálně velmi široké spektrum čtenářů, dal jsem všem podkapitolám srozumitelné nadpisy a vždy zdůraznil, které části mohou ti zkušenější bez obav vynechat.

Zdroje

Mnoho zdrojového materiálu pro tuto knihu pochází z pěti let práce na projektu Subversion (subversion.tigris.org/). Subversion je open source systém pro správu a verzování zdrojových kódů, který byl napsán zcela od nuly; byl zamýšlen jako náhrada pro CVS, jehož použití bylo v té době v celé open source komunitě de facto standardem. Projekt byl zahájen na začátku roku 2000 mým zaměstnavatelem, společností CollabNet (www.collab.net/), která naštěstí už od začátku pochopila, že je třeba jej vést v duchu spolupráce a distribuované činnosti. Velmi záhy se k projektu začalo přidávat mnoho dobrovolníků; dnes se jej účastní kolem 50 vývojářů, z nichž jenom několik je zaměstnáno v CollabNet.

V mnoha ohledech je Subversion zcela klasickým příkladem open source projektu a nakonec jsem z něj čerpal víc, než jsem původně očekával. Do určité míry je to proto, že to pro mě bylo nejjednodušší – když jsem potřeboval příklad nějakého konkrétního jevu, obvykle se mi hned vybavil nějaký, který jsme zažili při práci na Subversion. Je to ale také zdroj pro porovnávání informací. Ačkoliv se v různé míře účastním i jiných projektů svobodného softwaru a hovořím s přáteli a známými, kteří jsou aktivní v mnoha dalších, při psaní textu určeného k vydání si člověk rychle uvědomí, že by si všechna svá tvrzení měl ověřit. Nechtěl jsem se vyjadřovat k událostem, které se staly v jiných projektech, jen na základě toho, co jsem si mohl přečíst v archivech veřejných diskuzních skupin.Věděl jsem totiž, že pokud by se někdo o něco takového pokusil u Subversion, dospěl by ke správnému závěru jen asi v polovině případů, zatímco v té druhé by se mýlil. Takže když jsem čerpal inspiraci nebo příklady z projektu, s kterým jsem neměl přímou zkušenost, zkusil jsem nejdříve oslovit někoho, kdo je o něm lépe informovaný a komu můžu věřit, že mi řekne, jak to skutečně bylo.

Subversion byl mým zaměstnáním posledních pět let, ale svobodným softwarem se zabývám už delší dobu – dohromady 12 let. Mezi další projekty, které obsah této knihy ovlivnily, patří:

• Projekt textového editoru GNU Emacs nadace Free Software Foundation, ve kterém udržuji několik malých balíčků.

• Concurrent Versions System (CVS), na kterém jsem intenzivně pracoval v letech 1994–1995 s Jimem Blandym, ale do nějž jsem se od té doby zapojoval jen příležitostně.

• Sbírka open source projektů známá jako Apache Software Foundation, zejména Apache Portable Runtime (APR) a Apache HTTP Server.

• OpenOffice.org, Berkeley Database od Sleepycat a databáze MySQL – těchto projektů jsem se osobně neúčastnil, ale sledoval jsem je a v některých případech jsem hovořil s jejich tvůrci.

• GNU Debugger (GDB) (totéž).

• The Debian Project (totéž).

Tento seznam samozřejmě není úplný. Podobně jako většina open source programátorů i já zdálky sleduji mnoho různých projektů, abych měl přehled o celkovém stavu věcí. Nebudu je tady všechny vyjmenovávat, ale na příslušných místech se o nich v této knize zmiňuji.

Poděkování

Psaní této knihy zabralo čtyřikrát víc času, než jsem si původně myslel, a často jsem při tom měl pocit, jako by mi pořád viselo nad hlavou koncertní křídlo. Za to, že jsem ji dokázal dokončit a zachovat si zároveň své duševní zdraví, vděčím mnoha lidem.

Andy Oram z O’Reilly je typem redaktora, o němž všichni autoři knih sní. Kromě toho, že celou problematiku důvěrně zná (a navrhl mnohá z témat knihy), má i vzácný dar rozpoznat, co jste chtěli říci, a pomoci vám najít ten správný způsob, jak to říci. Práce s ním pro mě byla ctí. Děkuji také Chucku Toporkovi za to, že můj návrh rovnou přesměroval na Andyho.

Brian Fitzpatrick recenzoval téměř veškerý text knihy hned po jeho napsání, což nejen zvýšilo jeho kvalitu, ale také mě udrželo při psaní ve chvílích, kdy jsem chtěl být kdekoliv jinde, jen ne u počítače. Ben Collins-Sussman a Mike Pilato také dohlíželi, zda práce pokračují, a vždycky se mnou ochotně diskutovali – někdy docela dlouze – o jakémkoliv tématu, které jsem se v daném týdnu snažil popsat. Všímali si také, když jsem začínal zpomalovat, a když to bylo nutné, jemně mě postrkovali. Díky.

Biella Colemanová psala svou dizertační práci ve stejné době, kdy jsem dával tuto knihu dohromady i já. Ví, jaké to je každý den sednout a psát, a byla mi inspirujícím příkladem a chápavou posluchačkou. Na hnutí svobodného softwaru také aplikuje svůj fascinující pohled antropologa, čímž mi poskytla jak zajímavé nápady, tak i odkazy na další materiál, který jsem v knize mohl použít. Alex Golub, další antropolog, který je jednou nohou ve světě svobodného softwaru a jenž zároveň také dokončoval svou dizertační práci, mě v počátcích mimořádně podporoval, což mi hodně pomohlo.

Micah Anderson vždycky vypadal, že ho jeho vlastní psaní nijak zvlášť nezatěžuje, což pro mě bylo velkou inspirací (i když přiznávám, že jsem mu to spíš záviděl); hlavně byl ale vždy připraven poskytnout přátelskou radu nebo (přinejmenším při jedné příležitosti) technickou podporu. Díky, Micahu!

Jon Trowbridge a Sander Striker mi dodali jak povzbuzení, tak i konkrétní pomoc. Jejich rozsáhlé zkušenosti v oblasti svobodného softwaru mi poskytly materiál, k němuž bych se jinak jen těžko dostal.

Děkuji Gregu Steinovi nejen za přátelství a za dobře načasovanou podporu, ale i za to, že v projektu Subversion ukázal, jak jsou pravidelné revize kódu důležité pro budování programátorské komunity. Děkuji také Brianu Behlendorfovi, který nám taktně vtloukal do hlav, jak důležité je vést diskuze na veřejnosti. Doufám, že se tento princip odráží v celé knize.

Děkuji také Benjaminu „Makovi“ Hillovi a Sethu Schoenovi za rozličné rozpravy o svobodném softwaru a o jeho politických aspektech. Děkuji Zackovi Urlockerovi a Louisi Suarez-Pottsovi za to, že si ve svých nabitých plánech našli čas na rozhovor se mnou. Děkuji Shaneovi ze skupiny Slashcode za to, že svolil k citaci svých příspěvků, a Haggenovi So za jeho nesmírně užitečné srovnání serverů nabízejících kompletní hosting projektů.

Děkuji Alle Dekhtyar, Polině a Soni za jejich neustálé a trpělivé povzbuzování. Jsem velmi rád, že už nebudu muset ukončovat (nebo se spíš neúspěšně pokoušet ukončit) naše společné večery předčasně, abych mohl jít domů a pracovat na „té knize“.

Děkuji Jackovi Repenningovi za přátelství, mnohé rozhovory a tvrdohlavé odmítání přijmout jednoduchou chybnou analýzu, pokud je k dispozici analýza obtížnější, ale správná. Doufám, že se alespoň něco z jeho dlouhodobých zkušeností s vývojem softwaru a se softwarovým průmyslem jako takovým na této knize nějak odrazilo.

Společnost CollabNet prokázala mimořádnou velkorysost, když mi při psaní povolila velmi pružný harmonogram a nestěžovala si, když to trvalo mnohem déle, než se původně plánovalo. Nevím, jak přesně vypadá proces, jímž vedení společnosti k takovým závěrům dospěje, ale řekl bych, že v tom měli prsty Sandhya Kluteová a později Mahesh Murthy – za což jim oběma děkuji.

Celý vývojový tým projektu Subversion mi byl v uplynulých pěti letech velkou inspirací a mnohé z toho, co jsem napsal v této knize, jsem se naučil právě při práci s ním. Nebudu jim zde děkovat jmenovitě, protože je jich příliš mnoho, ale vyzývám každého čtenáře, který někdy narazí na přispěvatele projektu Subversion, aby ho pozval na nápoj podle jeho vlastní volby. Já osobně to dělat určitě budu.

Rachel Scollonovou jsem mnohokrát otravoval nekonečnými stížnostmi na aktuální stav knihy. Vždycky mi ochotně naslouchala a nějak dokázala, že mi po našem rozhovoru všechny problémy rázem připadaly menší. Moc mi to pomohlo – díky.

Děkuji (opět) Noelu Taylorovi, který se určitě musel divit, proč chci psát další knihu, když jsem si u té minulé tolik stěžoval, ale jehož přátelství a vedení sboru Golos pro mě znamenalo, že ani v okamžicích největší pracovní vytíženosti se z mého života nevytratila hudba a dobré vztahy s lidmi. Děkuji také Matthewovi Deanovi a Dorothei Samtlebenové, přátelům a dlouhodobě trpícím hudebním partnerům, kteří projevili velké pochopení pro mé stále se hromadící výmluvy, že nebyl čas cvičit. Megan Jenningsová mě neustále podporovala a upřímně se zajímala o zpracovávané téma, ačkoliv pro ni bylo neznámé – což je pro nejistého autora velká posila. Díky, Megan!

Knihu přečetli čtyři zasvěcení a pilní recenzenti: Yoav Shapira, Andrew Stellman, Davanum Srinivas a Ben Hyde. Kdybych byl schopen do knihy začlenit všechny jejich skvělé návrhy, byla by lepší. Časová omezení mě donutila vybrat si jen některé, které ale přesto celému textu výrazně prospěly. Za všechny chyby, které v knize zůstaly, jsem zodpovědný pouze já.

Mí rodiče, Frances a Henry, pro mě jako vždy byli báječnou oporou, a protože tato kniha je méně technická než ta předchozí, doufám, že pro ně bude i čitelnější.

Nakonec bych rád poděkoval těm, kterým jsem knihu věnoval – Karen Underhillové a Jimovi Blandymu. Karenino přátelství a pochopení pro mě znamenalo vše – nejen během psaní této knihy, ale také během posledních sedmi let. Bez její pomoci bych ji nikdy nemohl dokončit. Podobné je to s Jimem, opravdovým přítelem a skvělým hackerem, který mě jako první učil o svobodném softwaru – asi tak, jako by pták učil letadlo létat.

Prohlášení

Myšlenky a názory vyjádřené v této knize jsou mé vlastní. Nemusí nezbytně reprezentovat pohled společnosti CollabNet nebo projektu Subversion.

[1]Termíny „open source“ a „svobodný“ (free) software jsou v tomto kontextu v podstatě synonymní. Podrobněji budou probírány v části „Free“ versus „open source“ v kapitole 1. Úvod.

1. Úvod

1. Úvod

Historie

Vzestup proprietárního softwaru a svobodného softwaru

Vědomé hnutí odporu

Neúmyslné hnutí odporu

„Free“ versus „open source“

Současná situace

1. Úvod

Většina projektů svobodného softwaru ztroskotá.

O těchto selháních ale obvykle není moc slyšet. Jednak proto, že pozornost přitahují pouze ty úspěšné, a jednak proto, že projektů svobodného softwaru existuje tak velké množství[2], že i když uspěje jen malé procento z nich, pořád to bude vytvářet navenek zcela opačný dojem. O krachu projektů se obvykle také nedozvíme proto, že jejich selhání se nedá popsat jako událost. Nelze poukázat na konkrétní okamžik, kdy nějaký projekt ztratil svou životaschopnost – lidé se od něj zkrátka časem nějak odklonili a přestali na něm pracovat. Existuje sice moment, kdy byla do projektu zanesena poslední změna, ale ti, kteří ji provedli, obvykle ještě netušili, že dál už nic nebude. Neexistuje dokonce ani jednoznačná definice toho, kdy projekt zanikl. Je to tehdy, když se na něm aktivně nepracovalo po dobu šesti měsíců? Když jeho uživatelská základna přestala růst, aniž by převýšila počet vývojářů? Co když jej vývojáři opustili, protože zjistili, že existuje jiný projekt se stejným cílem? A co když se pak k tomuto druhému projektu připojili a rozšířili jej o mnohé z toho, co vytvořili dříve? Skončil vůbec ten první projekt, nebo se jen přestěhoval?

Z těchto a podobných důvodů není možné přesně zjistit, kolik procent projektů uspěje a kolik ne. Různé přibližné informace, které jsem nashromáždil za svých více než deset let v open source, posbíral na SourceForge.net a našel pomocí Googlu, naznačují všechny zhruba totéž: že počet těch, které selžou, je obrovský, pravděpodobně v řádu 90–95 %. Toto číslo pak ještě naroste, pokud započítáme i ty projekty, které sice dosud přežívají, ale už nefungují, tedy takové, které stále ještě produkují funkční software, ale jejichž pracovní prostředí je nepříjemné, nebo jež se nevyvíjejí tak rychle nebo tak spolehlivě, jak by mohly.

Tato kniha pojednává o tom, jak se selhání vyhnout. Nezkoumá jen to, jak dělat věci správně, ale také to, jak se dělají špatně, abyste mohli problémy včas rozpoznat a napravit. Doufám, že po jejím přečtení budete mít k dispozici řadu technik, které vám umožní nejen vyhnout se častým nástrahám vývoje open source softwaru, ale také vypořádat se s růstem a údržbou jakéhokoliv úspěšného projektu. Úspěch není hra s nulovým součtem a tato kniha se nezabývá tím, jak vyhrát nebo jak předběhnout vaši konkurenci. Koneckonců jednou z důležitých součástí vedení open source projektu je i dobrá spolupráce s ostatními souvisejícími projekty. Z dlouhodobé perspektivy přispívá každý úspěch svým dílem k prosperitě veškerého svobodného softwaru světa.

Bylo by lákavé říct, že projekty svobodného softwaru selhávají ze stejných důvodů jako projekty proprietárního softwaru. Nepochybně platí, že svobodný software nemá monopol na nerealistické požadavky, nejasné specifikace, špatné řízení zdrojů, nedostatky ve fázích návrhu i všechny ty ostatní strašáky, kteří jsou v softwarovém průmyslu již dobře známí. Těmito tématy se už zabývalo mnoho knih, proto se jim zde pokusím vyhnout. Místo toho se budu snažit popsat problémy, které se objevují jen ve světě svobodného softwaru. Pokud takový projekt selže, je to často proto, že jeho vývojáři (nebo vedoucí) podcenili specifické problémy spojené s vývojem open source – třebaže na ty známější obtíže spojené s vývojem closed source mohli být dobře připraveni.

Jednou z nejběžnějších chyb jsou nerealistická očekávání výhod open source přístupu jako takového. Otevřená licence nezaručí, že se na váš projekt hned vrhnou davy aktivních vývojářů a začnou mu dobrovolně věnovat svůj čas; to, že otevřete zdrojový kód problematického projektu, neznamená automatické vyřešení všech jeho potíží. Ve skutečnosti je to přesně naopak – otevřením projektu vytváříte celou řadu nových problémů a v krátkodobém horizontu vás to může stát více, než kdyby projekt zůstal uzavřený. Otevření projektu znamená, že je kód potřeba uspořádat tak, aby byl srozumitelný i těm, kdo ho vidí poprvé, že se musí vytvořit webové stránky a diskuzní skupiny (mailing listy) pro vývojáře a často i že je potřeba napsat vůbec první verzi dokumentace. To všechno představuje spoustu práce. A pokud se přece jen objeví vývojáři se zájmem o věc, bude to nějakou dobu znamenat zase jenom další zátěž – předtím, než začnou projektu jakkoliv přispívat, bude nutné nějakou dobu odpovídat na všechny jejich otázky. Jak řekl vývojář Jamie Zawinski o problematických začátcích projektu Mozilla:

Open source funguje, ale v žádném případě to není všelék. Pokud z toho všeho plyne nějaké poučení, je to fakt, že nemůžete vzít skomírající projekt, pokropit jej živou vodou zvanou „open source“, a vše tak zázračně vyřešit. Psát software je těžké. Jednoduchá řešení tu neexistují.

(citováno z www.jwz.org/gruntle/nomo.html)

S tím souvisí i další chyba, kterou je odbývání prezentace a přípravy instalačních balíčků s odůvodněním, že to přece můžeme dodělat později, až se projekt lépe rozjede. Prezentace a příprava instalačních balíčků v sobě zahrnují celou řadu úkolů, které mají společný cíl: snížit bariéru, jež brání vstupu. Pokud má být projekt přístupný pro nezasvěcené, je potřeba napsat dokumentaci pro uživatele a pro vývojáře, vytvořit webové stránky s informacemi pro nováčky, co nejvíc zautomatizovat kompilaci a instalaci softwaru atd. Mnozí programátoři, bohužel, považují uvedené práce za druhořadé – důležitější je podle nich kód samotný. Mají k tomu několik důvodů. Zaprvé jim to může připadat jako zbytečná námaha, protože tato činnost nejvíc prospívá těm, kdo projekt znají nejméně, a naopak. Koneckonců ti, kteří píšou zdrojový kód projektu, instalační balíčky vůbec nepotřebují. To, jak daný software nainstalovat, spravovat a používat, už dávno vědí, protože jej sami napsali. Zadruhé na to, abyste prezentaci a vytváření balíčků dělali dobře, potřebujete mít schopnosti, které se často značně liší od těch, které musí mít dobrý programátor. Lidé se obvykle zaměřují na to, v čem jsou dobří, a to i v případech, kdy by projektu lépe posloužilo, kdyby svůj čas věnovali i něčemu, co jim zas tolik nesedí. V kapitole 2. Zahájení projektu se budeme zabývat prezentací a vytvářením balíčků podrobněji a vysvětlíme si, proč je zcela zásadní, aby jim byla dána priorita už od samého začátku projektu.

Často se také objevuje mylný názor, že open source projekty potřebují řídit jen velmi málo, popřípadě vůbec, nebo zcela naopak, že je lze spravovat s použitím stejných metod, jaké se používají při uzavřeném vývoji. Řízení open source projektů nemusí být navenek příliš vidět, ale u úspěšných projektů se přesto děje – obvykle v nějaké formě v zákulisí. Abychom si uvědomili, proč tomu tak je, stačí si představit následující situaci: Každý open source projekt je tvořen náhodným seskupením programátorů (a tato kategorie lidí, jak známo, bývá často poněkud nonkonformní), kteří se velmi pravděpodobně nikdy nesetkali a kteří prací na projektu mohou sledovat různé osobní cíle. Teď si představte, co by se stalo, kdyby taková skupina nebyla vůbec žádným způsobem řízena. Pokud by se nestal nějaký zázrak, buď by se okamžitě zhroutila, nebo rychle rozutekla. I kdybychom si to přáli sebevíc, věci se samy spravovat nebudou. I když může být projekt řízen celkem aktivně, děje se to často neformálními, jemnými a poměrně nenápadnými způsoby. Jediná věc, která drží skupinu vývojářů pohromadě, je společná víra, že dohromady toho zvládnou víc než každý zvlášť. Hlavním cílem vedení je tedy zajistit, aby této myšlence nepřestávali věřit, a to vytvořením zásad komunikace, zabraňováním tomu, aby byli užiteční vývojáři vytlačeni na okraj projektu jen kvůli svým osobnostním rozdílům, a obecně tím, že projekt bude místem, kam se vývojáři budou chtít vracet. O tom, jak přesně těchto věcí dosáhnout, pojednává zbytek této knihy.

Nakonec existuje ještě obecná kategorie problémů, kterou bychom mohli pojmenovat jako „kulturní nedorozumění“. Před deseti, možná i před pěti lety by bylo poněkud předčasné mluvit o něčem jako globální kultuře svobodného softwaru; to se ale změnilo. Pomalu se zde vyvinula skutečná, jedinečná kultura, která sice rozhodně není jednolitá – k vnitřním rozporům a k vytváření frakcí je přinejmenším stejně náchylná jako libovolná kultura vymezená geograficky –, ale jejíž jádro je v zásadě soudržné. Většina úspěšných open source projektů sdílí některé nebo všechny charakteristiky tohoto jádra. Tyto kultury odměňují určité typy chování a trestají jiné a vytvářejí atmosféru, která podněcuje neplánovanou spoluúčast, i když někdy za cenu centrálního řízení. Mají své vlastní pojetí toho, co je nezdvořilé a co se naopak sluší, které se může podstatně lišit od toho, co je běžné jinde. A co je nejdůležitější, dlouhodobí účastníci tyto standardy většinou přijali za své, takže v názoru na to, jaké chování se v této kultuře očekává, se zhruba shodují. Neúspěšné projekty se od tohoto jádra obvykle výrazným způsobem odchylují, třebaže možná neúmyslně, a často v nich nepanuje shoda, jak by rozumné standardní chování mělo vypadat. To znamená, že pokud se objeví jakýkoliv problém, může se situace začít prudce zhoršovat, protože účastníci nemají dostatečně zažité kulturní reflexy, které by se pro řešení takových rozporů daly použít.

Tato kniha je praktická příručka a ne antropologická studie nebo historický výklad. Nicméně alespoň základní povědomí o původu současné kultury svobodného softwaru je pro to, abychom mohli poskytnout nějaké praktické rady, zcela nezbytné. Člověk, který této kultuře rozumí, se ve světě open source může dostat na lecjaká místa, kde sice najde řadu místních odlišností ve zvycích a v dialektu, ale kde se přesto bude moct bez větších problémů a efektivně zapojit do spolupráce. Naproti tomu člověku, jenž tuto kulturu nechápe, bude připadat proces organizace projektu nebo účasti na něm obtížný a plný překvapení. Protože počet lidí vyvíjejících svobodný software stále prudce roste, mnoho z nich spadá do té druhé kategorie; celou kulturu zatím do velké míry tvoří čerství přistěhovalci a tenhle stav ještě nějakou dobu potrvá. Pokud si myslíte, že byste mohli být jedním z nich, poskytne vám další podkapitola základní informace pro pochopení diskuzí, s nimiž se setkáte později – jak v této knize, tak na internetu. (Na druhou stranu pokud v open source už nějakou dobu pracujete, je možné, že už o jeho historii víte dost, takže následující oddíl klidně přeskočte.)

Historie

Sdílení softwaru je tak staré jako software sám. V době, kdy počítače začínaly, byli výrobci přesvědčeni, že jejich konkurenční výhoda spočívá hlavně v inovaci hardwaru, a možnostem, jak zpeněžit software, proto nevěnovali příliš velkou pozornost. Většina lidí, kteří tyto první počítače kupovali a používali, byli vědci nebo technici, kteří byli schopni software dodávaný spolu s počítači upravovat a rozšiřovat sami. Tito zákazníci někdy nejen že posílali své úpravy zpět k výrobci, ale nabízeli je i ostatním vlastníkům podobných počítačů. Výrobci to často tolerovali a někdy k tomu dokonce i vybízeli – vylepšení softwaru, ať už ho provedl kdokoliv, činilo jejich počítače přitažlivějšími pro další potenciální zákazníky.

Ačkoliv toto rané období současnou kulturu svobodného softwaru v mnohém připomínalo, lišilo se od ní ve dvou zásadních ohledech. Zaprvé byl hardware dosud jen velmi málo standardizován – byla to doba mnoha zářných inovací v návrhu počítačů, ale tato rozmanitost výpočetních architektur znamenala, že všechno bylo nekompatibilní se vším. Takže software napsaný pro jeden počítač obvykle nefungoval na druhém. Programátoři se obvykle stávali odborníky na konkrétní architekturu nebo rodinu architektur (zatímco dnes by se spíš zdokonalovali v programovacím jazyce nebo v rodině jazyků a spoléhali by na to, že jejich odborné znalosti budou přenositelné na jakýkoliv počítačový hardware, se kterým kdy budou pracovat). Protože obvykle uměli opravdu dobře pracovat jen s určitým typem počítače, měla tato jejich specializace za následek to, že byl tento počítač pro ně a pro jejich kolegy přitažlivější. Bylo tedy v zájmu výrobců, aby se co nejvíce šířil kód závislý na jejich konkrétním produktu.

Zadruhé ještě neexistoval internet. Ačkoliv právních předpisů omezujících sdílení dat bylo mnohem méně než dnes, existovalo nesrovnatelně více technických překážek: prostředky pro přenos dat z místa na místo byly poměrně složité a nepraktické. Existovaly sice malé lokální sítě, které se daly používat pro sdílení informací mezi zaměstnanci ve stejné výzkumné laboratoři nebo ve firmě, ale pokud jste chtěli něco sdílet se všemi bez ohledu na to, kde se nacházejí, narazili jste na značné potíže. V mnoha případech lidé našli způsoby, jak tyto bariéry překonat. Někdy se různé skupiny navzájem kontaktovaly a posílaly si pak disky nebo pásky poštou, někdy fungovali jako středisko pro výměnu úprav samotní výrobci. Věci pomohlo i to, že v době prvních počítačů mnozí vývojáři pracovali na univerzitách, kde se očekávalo, že budou své znalosti publikovat. Ale způsoby, jimiž přenos dat fyzicky probíhal, znamenaly, že proti sdílení působil značný odpor, přímo úměrný vzdálenosti (ať už geografické nebo organizační), kterou musel software překonat. Celosvětové, okamžité sdílení dat, jaké známe dnes, nebylo jednoduše možné.

Vzestup proprietárního softwaru a svobodného softwaru

Jak počítačový průmysl dozrával, došlo k několika vzájemně souvisejícím změnám. Divoká rozmanitost hardwarových návrhů byla postupně vytlačena několika jasnými vítězi – ať už za jejich vítězství mohla lepší technologie, lepší marketing nebo obojí dohromady. Zároveň, a to nejen shodou okolností, se začaly vyvíjet takzvané „vyšší programovací jazyky“, což znamenalo, že bylo možné napsat program jednou, v jednom jazyce, a nechat jej automaticky přeložit („zkompilovat“) tak, aby mohl běžet na různých typech počítačů. Výrobci hardwaru si dobře uvědomili, jaké důsledky bude tento vývoj mít: jejich zákazníci se teď mohli pouštět i do velkých softwarových projektů, aniž by se museli nezbytně vázat na konkrétní počítačovou architekturu. Jak byly z trhu postupně vytlačovány méně efektivní návrhy, začaly se snižovat i výkonnostní rozdíly mezi různými počítači, což znamenalo, že těm, kteří by obchodovali pouze s hardwarem, by začaly v blízké budoucnosti výrazně klesat zisky. Z hrubé výpočetní síly se stalo zaměnitelné zboží; jazýčkem na vahách se stal software. Prodávání softwaru, nebo přinejmenším jeho akceptování jako nedílné součásti prodeje hardwaru, se najednou stalo dobrou strategií.

To znamenalo, že výrobci museli začít dbát na přísnější dodržování autorských práv spojených se svými programy. Pokud by je uživatelé mezi sebou dál neomezeně sdíleli a upravovali, mohli by nezávisle implementovat některá zlepšení, která dodavatel začal prodávat jako „přidanou hodnotu“. A co by bylo ještě horší, sdílený zdrojový kód by se mohl dostat do rukou konkurence. Ironií všeho bylo, že se toto vše dělo přibližně ve stejné době, kdy se začal šířit internet. Právě v době, kdy začalo být neomezené sdílení softwaru konečně technicky možné, se stalo následkem změn v celém počítačovém průmyslu ekonomicky nežádoucím – přinejmenším z pohledu jednotlivých firem. Dodavatelé přitvrdili buď tím, že uživatelům odmítali přístup ke zdrojovému kódu, který na jejich počítačích běžel, nebo tím, že trvali na podepsání dohod o zachování důvěrnosti, které sdílení zamezovaly.

Vědomé hnutí odporu

Ve stejné době, kdy začal svět neomezované výměny kódu zvolna mizet, začala v hlavě přinejmenším jednoho programátora uzrávat myšlenka, jak se tomu vzepřít. Richard Stallman pracoval v sedmdesátých a raných osmdesátých letech minulého století v Laboratoři umělé inteligence (Artificial Intelligence Lab) na Massachusetts Institute of Technology – tedy při zpětném pohledu přímo uprostřed zlatého věku a v ideálním prostředí pro sdílení programů. V Laboratoři umělé inteligence se vyznávala přísná „hackerská etika“[3] a lidé zde nejen že byli vybízeni, aby se o svá zlepšení systému podělili s ostatními, ale dokonce se to od nich očekávalo. Jak Stallman později napsal:

Našemu softwaru jsme neříkali „svobodný software“, protože tento pojem ještě neexistoval, ale v zásadě to bylo totéž. Kdykoliv si chtěl někdo z jiné univerzity nebo nějaké firmy zkopírovat náš program, aby jej mohl u sebe používat, s radostí jsme mu ho poskytli. Pokud jste viděli, že někdo používá nějaký vám neznámý a zajímavý program, vždycky jste mohli požádat o zdrojový kód. Mohli jste si jej prostudovat, změnit jej, nebo z něj vykousnout nějaké části a použít je pro nový program.

(citováno z www.gnu.org/gnu/thegnuproject.html)

Změny, které se děly ve zbytku počítačového průmyslu, ale nakonec nedlouho po roce 1980 dostihly i Laboratoř umělé inteligence a celá rajská komunita kolem Stallmana se rozpadla. Jedna začínající společnost přetáhla z laboratoře mnoho programátorů, aby u ní pracovali na vývoji operačního systému. Ten se podobal tomu, na němž pracovali v laboratoři, ale měl velmi přísnou licenci. Ve stejné době Laboratoř umělé inteligence samotná získala nové zařízení, které bylo dodáno s proprietárním operačním systémem.

Stallman v tom, co se dělo, začal vnímat širší souvislosti:

Moderní počítače té doby, jako byl VAX nebo 68020, měly své vlastní operační systémy, ale žádný z nich nebyl svobodným softwarem – předtím, než jste mohli získat pouhou spustitelnou kopii programu, jste museli podepsat dohodu o důvěrnosti.

To znamená, že prvním krokem při používání počítače byl slib, že nebudete ostatním pomáhat. Jakákoliv spolupráce v rámci komunity byla zakázána. Pravidlo, jež vlastníci proprietárního softwaru vyhlásili, znělo: „Pokud sdílíte s někým jiným, jste pirát. Pokud chcete nějaké změny, požádejte nás, abychom je provedli.“

Něco v Stallmanovi se tomu ale vzpíralo; rozhodl se proto celému trendu postavit. Místo toho, aby pokračoval v práci v teď už téměř nefunkční Laboratoři umělé inteligence nebo aby přijal místo programátora v jedné z nových firem, kde by výsledky jeho práce ležely zamčené v trezoru, z laboratoře odešel a založil Projekt GNU a Free Software Foundation (FSF; Nadace svobodného softwaru). Cílem GNU[4] bylo vyvinout zcela svobodný a otevřený počítačový operační systém a balík aplikačního softwaru, v němž uživatelům nikdy nebude bráněno cokoliv měnit nebo své úpravy šířit. V podstatě začal Stallman znovu vytvářet to, co bylo v Laboratoři umělé inteligence zničeno, ale tentokrát v celosvětovém měřítku a bez slabin, kvůli nimž se kultura laboratoře nakonec rozpadla.

Kromě prací na novém operačním systému Stallman vymyslel autorskou licenci, jejíž znění zaručovalo, že jeho kód zůstane trvale svobodný. Celá GNU General Public License (GPL) je velmi rafinovaný právnický výkon. Říká, že kód může být kopírován a upravován bez omezení a že jak kopie, tak odvozená díla (tedy upravené verze) musí být distribuovány se stejnou licencí jako originál, bez jakýchkoliv dalších omezení. Používá tedy zákon o autorském právu tak, aby dosáhl zcela opačného efektu, než tradiční copyright má mít – místo toho, aby distribuci softwaru nějak omezoval, zabraňuje všem, dokonce i svému autorovi samotnému, aby jakékoliv omezení ustanovil. Pro Stallmana byl tento postup lepší, než kdyby jednoduše prohlásil svůj kód za volně šiřitelný. V takovém případě by totiž mohla být jakákoliv jeho kopie začleněna do proprietárního programu (což se u programů s tolerantními autorskými licencemi stávalo). I když by takové zabudování žádným způsobem nesnížilo dostupnost původního kódu, znamenalo by to, že by ze Stallmanova úsilí mohl těžit jeho nepřítel – proprietární software. O GPL lze uvažovat jako o jisté formě protekcionismu vztahující se na svobodný software, protože nesvobodnému softwaru zabraňuje naplno využít výhod kódu vydaného pod GPL. Na licenci GPL a její vztah k ostatním licencím svobodného softwaru se podíváme podrobněji v kapitole 9. Licence, autorská práva a patenty.

S pomocí mnoha programátorů, z nichž někteří Stallmanovu ideologii sdíleli a někteří jednoduše chtěli, aby existovalo velké množství dostupného svobodného kódu, začal projekt GNU vydávat svobodné náhrady pro mnoho z těch nejdůležitějších komponent operačního systému. Vzhledem k tomu, že standardizace počítačového hardwaru i softwaru v té době už značně pokročila, bylo možné tyto náhrady z projektu GNU používat i v systémech, jež jinak svobodné nebyly, což také mnoho lidí dělalo. Zvlášť úspěšnými výstupy projektu GNU byly jeho textový editor Emacs a kompilátor jazyka C (GCC), které si získaly velkou a oddanou skupinu následovníků ne na základě ideologie, ale pro jejich technické kvality. Kolem roku 1990 GNU vytvořil již většinu komponent svobodného operačního systému s výjimkou jádra – tedy té části, kterou počítač zavádí při startu (boot) a která je zodpovědná za správu paměti, diskového prostoru a dalších systémových zdrojů.

Naneštěstí si projekt GNU zvolil návrh jádra, který se z hlediska implementace ukázal obtížnější, než se očekávalo. Celý vývoj se začal zpožďovat, a kvůli tomu to tedy nakonec nebyla Free Software Foundation, kdo vytvořil první zcela svobodný operační systém. Poslední chybějící kus skládanky místo nich dodal Linus Torvalds, finský student informatiky, který s pomocí dobrovolníků z celého světa dokončil svobodné jádro vycházející z konzervativnějšího návrhu. Dal mu název Linux; poté, co bylo toto jádro zkombinováno s existujícími programy GNU, vznikl zcela svobodný operační systém. Poprvé v historii jste mohli nastartovat počítač a pracovat bez použití jakéhokoliv proprietárního softwaru.[5]

Velká část softwaru tohoto nového operačního systému nepocházela z projektu GNU. Ve skutečnosti dokonce GNU nebyla jedinou skupinou, která by se snažila vytvořit svobodný operační systém – ve stejné době už byl například vyvíjen kód, z nějž se časem staly systémy NetBSD a FreeBSD. Význam Free Software Foundation nespočívá jen v tom, že psali programy, ale také v jejich politické rétorice. Tím, že svobodný software brali jako svůj hlavní program a nejen jako něco, co může být celkem užitečné, bylo pro programátory obtížné si na celou věc neudělat nějaký názor. Dokonce i ti, kteří s FSF nesouhlasili, se celým problémem museli zabývat, už jen proto, aby mohli vyjádřit svůj odlišný názor. Úspěch FSF jako šiřitelů propagandy spočívá v tom, že svůj zdrojový kód svázali prostřednictvím GPL a dalších textů i s jasným politickým poselstvím. Jak se jejich programy šířily dál, šířilo se s nimi i toto poselství.

Neúmyslné hnutí odporu

Na rodící se scéně svobodného softwaru se děla spousta dalších věcí, ale málo z nich bylo tak výrazně ideologických jako Stallmanův projekt GNU. Jedním z nejdůležitějších byl systém Berkeley Software Distribution (BSD) vytvořený programátory University of California v Berkeley jako postupná reimplementace operačního systému Unix, jenž byl až do konce 70. let víceméně proprietárním výzkumným projektem společnosti AT&T. Skupina BSD nečinila žádná otevřeně politická prohlášení o tom, že se programátoři musí sjednotit a vzájemně sdílet svou práci, ale v praxi tuto myšlenku realizovala, a to s velkým nadšením, při koordinaci celého masivního distribuovaného vývoje; v rámci projektu byly od základů přepsány unixové programy pro příkazový řádek, jeho knihovny a nakonec i samotné jádro operačního systému, a to převážně díky dobrovolníkům. Projekt BSD se stal ukázkovým příkladem neideologického vývoje svobodného softwaru a byl také místem, kde načerpala své první zkušenosti řada vývojářů, kteří pak zůstali v open source světě aktivní.

Další zatěžkávací zkouškou kooperativního vývoje byl X Window System, svobodné, síťově transparentní grafické výpočetní prostředí vyvinuté v polovině 80. let na MIT ve spolupráci s prodejci hardwaru, kteří měli společný zájem na tom, aby byli svým zákazníkům schopni nabídnout systém pracující s okny. Zdaleka nešlo o odpor vůči proprietárnímu softwaru – licence pro X dokonce záměrně dovolovala proprietární rozšiřování svobodného jádra systému, protože každý člen celého sdružení chtěl mít možnost základní distribuci X vylepšit, a získat tím konkurenční výhodu oproti těm ostatním. Samotné X Windows[6] byly sice svobodným softwarem, ale především proto, aby existovaly rovné podmínky pro vzájemný souboj obchodních zájmů, a ne ve snaze ukončit převahu proprietárního softwaru. Dalším příkladem, který projekt GNU o pár let předběhl, byl TeX Donalda Knuthe, svobodný systém pro sázení dokumentů, jenž kvalitou svých výstupů odpovídal požadavkům nakladatelství. TeX byl vydán s licencí, která komukoliv umožňovala kód upravovat a šířit, ale výsledek těchto úprav se nesměl nazývat „TeX“, pokud nesplnil velmi přísnou sadu testů kompatibility (je to tedy příklad svobodné licence „chránící obchodní značku“; tento typ probereme podrobněji v kapitole 9. Licence, autorská práva a patenty). Knuth se vůbec nesnažil zaujmout nějaké stanovisko v debatě svobodný versus proprietární software. Potřeboval zkrátka lepší sázecí systém, aby mohl dokončit to, co bylo jeho primárním cílem, totiž kniha o počítačovém programování, a neviděl žádný důvod, proč by svůj systém neměl po dokončení zveřejnit.

Aniž bychom jmenovali každý projekt a každou licenci, můžeme bezpečně říct, že na konci 80. let již existovalo velké množství svobodného softwaru s celou řadou různých licencí. Rozmanitost těchto licencí odpovídala tomu, jak různorodé byly i motivace těchto projektů. Dokonce i někteří z programátorů, kteří si zvolili GNU GPL, byli ideologicky mnohem méně vyhranění než projekt GNU samotný. Třebaže mnoho z těchto vývojářů práce na svobodném softwaru bavila, nechápali proprietární software jako společenské zlo. Našli se sice tací, kteří považovali za svou morální povinnost zbavit svět „softwarového hamounění“ („software hoarding“ – Stallmanův pojem pro nesvobodný software), ale existovali i jiní, které pohánělo jejich technické zaujetí nebo radost ze spolupráce s podobně smýšlejícími lidmi, či dokonce obyčejná lidská touha po slávě. Přesto ale obvykle nedocházelo k tomu, že by se tyto nesourodé motivace nějakým způsobem tloukly. To je dáno částečně tím, že na rozdíl od ostatních tvůrčích forem, jako je literatura nebo výtvarné umění, musí software k tomu, aby mohl být považován za úspěšný, splnit několik částečně objektivních testů: musí fungovat a být do rozumné míry prostý chyb. To všem účastníkům projektu automaticky dává jakýsi společný základ, důvod a rámec pro vzájemnou spolupráci, aniž by se museli příliš starat o jinou než technickou způsobilost.

K tomu, aby vývojáři drželi pospolu, pak měli ještě další důvod – ukázalo se totiž, že ve světě svobodného softwaru vzniká někdy zdrojový kód velmi vysoké kvality. V některých případech byly tyto programy prokazatelně technicky dokonalejší než jejich nejbližší proprietární alternativa, zatímco v dalších byly přinejmenším srovnatelné; vždy ale byly samozřejmě levnější. Pro pár lidí mohla mít motivace k používání svobodného softwaru čistě filozofický základ, ale většina lidí jej používala prostě proto, že byl lepší. A z těch, kteří ho používali, bylo vždy určité procento ochotné věnovat svůj čas a schopnosti tomu, aby jej pomohli udržovat a zlepšovat.

Tendence psát dobré programy se rozhodně neprojevovala všude, ale u projektů svobodného softwaru celého světa se dala pozorovat stále častěji. Toho si postupně začaly všímat firmy, které byly na svém softwaru výrazně závislé. Mnohé z nich zjistily, že svobodný software už při své každodenní práci používají a neví o tom – protože vedení společnosti nemusí vždy tušit, co přesně jejich IT oddělení dělá. Různé společnosti začaly k projektům svobodného softwaru i na veřejnosti zaujímat stále aktivnější postoj. Dávaly jim k dispozici svůj čas a své vybavení a v některých případech dokonce vývoj svobodných programů přímo financovaly. Podobné investice se jim totiž v nejlepších případech mohou i několikanásobně vrátit. Sponzor platí pouze malé množství odborníků, kteří se díky tomu mohou projektu naplno věnovat; přitom ale sklízí plody práce všech zúčastněných, tedy včetně neplacených dobrovolníků a programátorů, kteří jsou placeni jinými organizacemi.

„Free“ versus „open source“

S tím, jak začaly společnosti světa svobodnému softwaru věnovat čím dál tím větší pozornost, vyvstaly před programátory nové problémy – tentokrát s prezentací. Jedním z nich bylo samotné slovo „free“, které v angličtině může znamenat „svobodný“, ale také „zdarma“. Když lidé slyší pojem „free software“ poprvé, mnoho z nich se mylně domnívá, že to znamená „software zadarmo“. Pravda je taková, že veškerý svobodný software je sice dostupný zdarma,[7]ale to, že je nějaký software zadarmo, ještě neznamená, že je svobodný. Například během války prohlížečů v 90. letech poskytly jak Netscape, tak Microsoft při rvačce o získání podílu na trhu své konkurenční webové prohlížeče veřejnosti zdarma. Ani jeden z nich však nebyl svobodný software. Nebylo možné získat jejich zdrojový kód; i kdyby se vám to podařilo, neměli jste právo jej upravovat a šířit dál.[8] Jedinou věcí, kterou jste mohli udělat, bylo stáhnout a spustit zkompilovaný program. Tyto prohlížeče nebyly o nic víc svobodné než software, jenž jste si koupili v obchodě v krabici – jenom byly levnější.

Tento zmatek kolem slova „free“ je způsoben výhradně jeho nešťastnou dvojznačností v anglickém jazyce. Většina jiných jazyků rozlišuje nízkou cenu od svobody (například mluvčím románských jazyků je ihned jasný rozdíl mezi gratis a libre). Ale protože je angličtina de facto hlavním komunikačním jazykem internetu, znamená to, že její problémy jsou do jisté míry problémy všech. Nedorozumění kolem slova „free“ bylo tak časté, že programátoři svobodného softwaru časem vytvořili tuto standardní formulku: „Je to free jako freedom (svoboda) – tedy ve smyslu free speech (svoboda slova) a ne free beer (pivo zdarma).“ To ale nic nemění na tom, že je poněkud unavující to pořád dokola vysvětlovat. Mnozí programátoři měli pocit – a to ne bezdůvodný –, že nejednoznačnost slova „free“ brání tomu, aby veřejnost pochopila, o jaký software jde.

Ale ukázalo se, že problém je ještě závažnější. Slovo „free“ totiž nese ještě další význam, tentokrát morální: pokud měla být cílem svoboda jako taková, pak nezáleželo na tom, zda byl shodou okolností tento svobodný software také lepší nebo pro nějaký podnik ekonomicky výhodnější. To byl jen příjemný vedlejší účinek; primární motivace zde ale nebyla v jádru ani technická, ani ekonomická, ale filozofická. Zastávání svobody softwaru navíc poukazovalo na to, že se často objevuje značný rozpor u společností, které sice v rámci své obchodní činnosti chtějí podporovat konkrétní svobodné programy, ale jinak dál pokračují v nabízení proprietárního softwaru.

A tak stálo před komunitou, která už tak mířila ke krizi identity, další dilema. Sami programátoři, kteří svobodný software píší, se nikdy neshodli na tom, jaký cíl tohoto hnutí vlastně je, pokud tedy vůbec nějaký existuje. Bylo by dokonce zavádějící tvrdit, že se zde objevuje celá škála názorů od jednoho extrémního postoje k druhému, protože taková lineární osa tu jednoduše neexistuje; místo toho panuje obrovská roztříštěnost názorů na mnoho dílčích aspektů věci. Pokud ale na chvíli odhlédneme od detailů, uvidíme zde v zásadě dvě velké skupiny uvažujících. Jedna z nich zastává Stallmanovo stanovisko, podle nějž je hlavním cílem svoboda sdílet a upravovat; pokud přestanete mluvit o svobodě, znamená to, že jste zapomněli na to nejdůležitější. Jiní mají pocit, že nejdůležitějším argumentem, který pro jakýkoliv software hovoří, je tento software samotný, a odmítají prohlásit, že veškerý proprietární software je ze své podstaty špatný. Někteří, ale ne všichni programátoři svobodného softwaru věří, že právo na to, určit podmínky pro distribuci softwaru, by měl mít jeho autor (nebo v případě placené práce jeho zaměstnavatel) a že volba licence nemusí nutně poukazovat na nějaké morální stanovisko.

Tyto rozdíly nebylo dlouho nutné nijak zvlášť zkoumat nebo se k nim vyjadřovat, ale rostoucí úspěch svobodného softwaru v podnikatelské sféře si to časem vynutil. V roce 1998 byl jako alternativa k termínu „svobodný software“ (free software) vytvořen pojem open source. Zasloužila se o to skupina programátorů, kteří časem vytvořili The Open Source Initiative (Iniciativa open source, OSI).[9] Členové OSI měli pocit, že to není jen spojení „free software“, které způsobuje potíže, ale že zde existuje větší problém, jehož je slovo „free“ jako takové jen symptomem – totiž že celé hnutí potřebuje marketingový program, který by se dal představit světu obchodních společností, protože hovory o tom, jaké jsou morální a společenské výhody sdílení, na obchodních jednáních nikdo poslouchat nebude. Sdružení OSI celou věc vyjádřilo takto:

The Open Source Initiative je marketingový program pro svobodný software. Je to způsob, jak propagovat celou myšlenku svobodného softwaru postaveného na pevných pragmatických základech a ne na ideologickém zápalu. Podstata, a tedy i největší síla našeho softwaru se nemění; co se mění, je jeho symbolický rozměr a celý poraženecký přístup, který tato komunita má. …

Většinu technicky založených lidí není nutné přesvědčovat o výhodách konceptu open source, ale o jeho jméně. Proč bychom neměli dál používat zavedený termín „svobodný software“?

Jedním z důvodů je to, že pojem „free software“ lze snadno chápat nesprávně, což často vede ke konfliktům. …

Ale tím hlavním, co nás k této změně označení vede, je marketing. Svou koncepci chceme nabídnout obchodnímu světu. Máme produkt, s nímž lze zvítězit, ale způsob jeho uvádění na trh byl dosud zcela špatný. Pojem „free software“ byl v podnikatelské sféře špatně pochopen; touha sdílet byla brána jako boj proti kapitalismu nebo ještě hůře jako krádež.

Ředitelé velkých obchodních společností a jejich technologických oddělení na koncept „svobodného softwaru“ nikdy slyšet nebudou. Ale co když vezmeme stejné tradice, stejné lidi, stejné licence, které známe jako „svobodný software“, a změníme nálepku na „open source“? To už je něco, o čem se budou ochotni bavit.

Někteří hackeři tomuhle odmítají uvěřit, ale to je dané tím, že jsou to technicky orientovaní lidé, kteří uvažují v konkrétních a reálných pojmech; nedokážou pochopit, jak je při prodeji čehokoliv důležitý celkový dojem, vaše image.

Ve světě marketingu jste tím, čím vypadáte, že jste. Pokud vyvoláme dojem, že jsme ochotni slézt z barikád a spolupracovat se světem podnikání, bude to zrovna tak důležité jako naše skutečné chování, naše zásady a náš software.

(citováno z www.opensource.org/. Přesněji řečeno z dřívější podoby těchto stránek. OSI je od té doby zřejmě stáhla, ale stále je lze najít na web.archive.org/web/20021204155057/www.opensource.org/advocacy/faq.php a web.archive.org/web/20021204155022/www.opensource.org/advocacy/case_for_hackers.php#marketing.)

V tomto textu se objevují náznaky mnoha sporných otázek. Zmiňuje se o „našich zásadách“, ale chytře se vyhýbá tomu říct, o jaké zásady přesně jde. Pro některé se může jednat o přesvědčení, že programy vyvinuté v rámci otevřeného procesu budou lepší; jiní těmito zásadami budou rozumět princip, že by se všechny informace měly sdílet. Používá se zde slovo „krádež“ (patrně) ve smyslu nelegálního kopírování – proti čemuž mnozí namítají, že pokud přitom původní vlastník o nic nepřišel, nemůže už z principu jít o krádež. Naznačuje se zde, že by hnutí za svobodný software mohlo být vnímáno jako antikapitalismus, ale tomu, zda je takové obvinění ve skutečnosti něčím podloženo, se pečlivě vyhýbá.

Tím ale nechci říct, že by byly stránky OSI nekonzistentní nebo úmyslně zavádějící. To rozhodně nejsou. Spíše jde o skvělý příklad toho, co podle OSI v hnutí za svobodný software chybělo, tedy dobrého marketingu; „dobrý“ zde znamená „životaschopný v obchodním světě“. Iniciativa open source tak dala řadě lidí přesně to, co hledali – způsob, jak mluvit o svobodném softwaru jako o metodologii vývoje a obchodní strategii a ne jako o filozofickém hnutí.

Vznik Iniciativy změnil celou situaci svobodného softwaru. OSI zde podala definici rozporu, který dlouho zůstával nepojmenován, čímž celé hnutí donutila připustit, že se nestačí zabývat politikou jen navenek, ale také uvnitř. Následkem toho je, že obě strany musely najít společnou řeč, protože většina projektů zahrnuje programátory z obou táborů i účastníky, které do žádné kategorie jednoznačně zařadit nelze. To neznamená, že by přestali mluvit o svých morálních zásadách – pokud se například někdo dopustí prohřešku vůči tradiční „hackerské etice“, bývá mu to někdy vyčteno. Jen málokdy ale nějaký vývojář svobodného nebo open source softwaru zpochybní motivaci ostatních účastníků projektu. Příspěvek je důležitější než jeho autor. Pokud někdo píše dobrý zdrojový kód, neptáte se ho, zda to dělá z morálních důvodů, zda jej za to někdo platí, zda si vylepšuje svůj profesní životopis nebo cokoliv jiného. Jeho příspěvek hodnotíte z technického hlediska a reagujete na technickém základě. Dokonce i explicitně politické organizace, jako je projekt Debian, jenž si dal za cíl nabídnout stoprocentně svobodné výpočetní prostředí, se k integraci nesvobodného kódu staví celkem otevřeně a spolupracují s programátory, kteří stejné cíle nesdílejí.

Současná situace

Při řízení projektu svobodného softwaru není potřeba řešit tyto závažné filozofické záležitosti každý den. Programátoři nebudou trvat na tom, aby všichni ostatní účastníci projektu plně souhlasili s jejich pohledem na věc – a ti, kteří na tom trvat budou, rychle zjistí, že pak nemůžou pracovat prakticky nikde. Musíte si ale být vědomi toho, že debata „svobodný“ versus „open source“ existuje, a to jak proto, abyste nechtěně neřekli něco, co by někteří účastníci mohli vnímat jako nepřátelské, tak proto, že pochopení motivace vašich vývojářů je tím nejlepším a do určité míry vlastně i jediným způsobem, jak projekt řídit.

Rozhodnutí se pro svobodný software je volbou každého jednotlivce. Abyste byli v této kultuře úspěšní, musíte pochopit, proč lidé tuto volbu učinili. Donucovací techniky zde nefungují. Pokud se vývojáři v jednom projektu necítí dobře, pak jednoduše odejdou jinam. Svobodný software je výjimečný i mezi jinými skupinami dobrovolníků, protože jejich osobní investice je zde jen velmi malá. Většina lidí zapojených v projektu se s těmi ostatními nikdy osobně nesetká; projektu věnují kousky svého času zkrátka tehdy, když se jim chce. Běžné způsoby, kterými se lidé dávají dohromady a vytvářejí trvalé skupiny, jsou omezeny jen na uzounký kanál – psané slovo přenášené elektronicky. Z tohoto důvodu může trvat poměrně dlouho, než vznikne skupina, která opravdu drží pohromadě a jde za stejným cílem. A naopak je velmi snadné, aby projekt ztratil potenciálního dobrovolníka už během prvních pěti minut. Pokud nebude jeho první dojem z projektu dobrý, pak mu jen málokdy dá i druhou šanci.

Pomíjivost nebo přesněji řečeno potenciální pomíjivost vztahů je možná tím vůbec nejtěžším problémem, kterému musí nový projekt čelit. Jak všechny tyto lidi přesvědčit, aby zůstali pohromadě dost dlouho na to, aby vzniklo něco užitečného? Odpověď na tuto otázku je natolik složitá, že zabere prakticky celý zbytek této knihy. Pokud bychom ale měli odpovědět jednou větou, vypadala by asi takto:

Lidé by měli mít pocit, že míra jejich zapojení do projektu a jejich vliv na projekt jsou přímo úměrné jejich přínosu.

Žádná skupina vývojářů (nebo potenciálních vývojářů) by neměla mít pocit méněcennosti nebo diskriminace z jiných než technických důvodů. Je jasné, že projekty sponzorované firmami nebo takové, v nichž existují i placení vývojáři, musí být v tomto ohledu zvlášť opatrné, jak podrobněji popíšeme v kapitole 5. Peníze. To ale samozřejmě neznamená, že pokud není projekt sponzorovaný žádnou firmou, není se čeho bát. Peníze jsou jen jedním z mnoha faktorů, které mohou úspěšnost projektu ovlivnit. Jsou tu i další otázky: jaký programovací jazyk, jakou licenci a jaký vývojový proces bude nejlepší, jakou infrastrukturu je potřeba vytvořit, jak efektivně oznámit zahájení projektu a mnoho dalších. Tomu, jak při startu projektu vykročit tou správnou nohou, se věnuje následující kapitola.

[2]SourceForge.net, jeden z populárních hostingových serverů, měl v polovině dubna 2004 registrováno 79 225 projektů. Tohle číslo ale samozřejmě ani zdaleka neodpovídá celkovému počtu projektů svobodného softwaru na internetu – jsou v něm pouze ty, které si vybraly SourceForge.

[3]Stallman používá slovo „hacker“ ve smyslu „někdo, kdo rád programuje a koho těší, že je v tom dobrý“, a ne v relativně novém významu „někdo, kdo se nabourává do počítačů“.

[4]Název projektu je zkratka z „GNU’s Not Unix“ („GNU není Unix“), přičemž „GNU“ v této delší verzi je zkratka pro… přesně to samé.

[5]Technicky vzato nebyl Linux úplně první. Nedlouho před Linuxem se objevil jiný svobodný operační systém pro počítače kompatibilní s IBM; nazýval se 386BSD. Tento systém ale bylo mnohem obtížnější spustit a udržet v provozu. Význam Linuxu spočíval nejen v tom, že byl svobodný, ale také v tom, že u něj byla celkem vysoká pravděpodobnost, že se na vašem počítači po instalaci skutečně i rozběhne.

[6]Projekt sám má raději název „X Window System“, ale v praxi se obvykle používá „X Windows“, protože to je kratší.

[7]Za šíření kopií svobodného softwaru si sice můžete účtovat nějaký poplatek, ale protože nelze zabránit tomu, aby příjemce pokračoval v dalším šíření zdarma, klesá vaše cena prakticky okamžitě k nule.

[8]Zdrojový kód Netscape Navigatoru byl nakonec v roce 1998 přece jen zveřejněn s open source licencí a stal se základem webového prohlížeče sdružení Mozilla. Viz www.mozilla.org/.

[9]Domácí stránka OSI se nachází na www.opensource.org/.

2. Zahájení projektu

2. Zahájení projektu

Nejdříve se ale rozhlédněte

Začněte od toho, co máte k dispozici

Vyberte dobré jméno

Určete jasné cíle projektu

Uveďte, že jde o svobodný projekt

Seznam funkcí a požadavků

Stav vývoje

Stahování

Zpřístupnění systémů správy verzí a sledování chyb

Komunikační kanály

Pokyny pro vývojáře

Dokumentace

Dostupnost dokumentace

Dokumentace pro vývojáře

Vzorový výstup a snímky obrazovky

Kompletní hosting

Výběr licence a její uplatnění

Licence typu „vše je povoleno“

GPL

Jak licenci aplikovat

Udávání tónu

Vyhněte se soukromým diskuzím

Nezdvořilé chování potlačte hned v zárodku

Kontrolujte kód veřejně

Když otvíráte dosud uzavřený projekt, uvědomte si rozsah změn

Oznamování

2. Zahájení projektu

Klasický model toho, jak projekty svobodného softwaru začínají, popsal Eric Raymond ve svém proslulém eseji o procesech používaných v open source, který má název The Cathedral and the Bazaar (Katedrála a bazar). Napsal:

Veškerý dobrý software začal tak, že se nějaký vývojář potřeboval podrbat tam, kde jej něco svědilo.

(citováno z www.catb.org/~esr/writings/cathedral-bazaar/)

Povšimněte si, že Raymond neřekl, že open source projekty vznikají jen tehdy, když někoho něco svědí. Řekl něco trochu jiného: že dobrý software vzniká tehdy, když má programátor osobní zájem na tom, aby byl nějaký problém vyřešen; ukázalo se, že právě to bývá skutečně i tou nejčastější motivací pro založení projektu svobodného softwaru.

Pro většinu z nich to platí dodnes, ale už jich není tolik jako v roce 1997, kdy Raymond článek napsal. V současnosti můžeme pozorovat fenomén, kdy řada organizací – včetně klasických společností orientovaných na zisk – spouští velké, centrálně řízené open source projekty vyvíjené od základů. Zdrojem značné části svobodného softwaru nadále zůstává osamělý programátor, který napíše kód, jenž řeší jeho vlastní problém, a pak si uvědomí, že se výsledek jeho práce dá použít i jinde, ale existují i jiné varianty.

Raymondův postřeh nicméně stále platí. Základní podmínkou je, aby tvůrci softwaru měli přímý zájem na jeho úspěchu, protože jej sami používají. Pokud software nedělá to, co by měl, pak osoba, popřípadě organizace, která jej vytváří, bude při své každodenní práci nespokojen. Vezměme si například projekt OpenAdapter (www.openadapter.org/), který spustila investiční banka Dresdner Kleinwort Wasserstein jako open source framework pro integraci několika různých finančních informačních systémů; jen těžko bychom mohli tvrdit, že tento projekt řešil problém nějakého jednotlivého programátora. Byla to instituce, která něco potřebovala vyřešit. Tento problém ale přímo vyplýval ze zkušeností této instituce samotné a jejích partnerů, takže pokud by projekt nesplnil svůj úkol, nepochybně si toho všimnou. V takovémto uspořádání vzniká dobrý software, protože zpětná vazba míří tím správným směrem. Není to program, který by byl napsán proto, aby mohl být prodáván někomu jinému a řešil cizí problémy. Byl napsán jako reakce na řešení něčího problému a pak sdílen s ostatními, jako kdyby tento problém byla nějaká nakažlivá nemoc a software byl lékem šířeným proto, aby zabránil epidemii.

Nejdříve se ale rozhlédněte

Než spustíte libovolný open source projekt, nezapomínejte udělat jednu velmi důležitou věc:

Začněte od toho, co máte k dispozici

Co teď?

Vyberte dobré jméno

Dobré jméno:

Určete jasné cíle projektu

Uveďte, že jde o svobodný projekt

Seznam funkcí a požadavků

Vlastnosti:

• Vyhledávání slov a frází

Požadavky:

Stav vývoje

Alfa a beta

Stahování

Zpřístupnění systémů správy verzí a sledování chyb

Komunikační kanály

Pokyny pro vývojáře

Dokumentace

Údržba FAQ

Dostupnost dokumentace

Dokumentace pro vývojáře

Vzorový výstup a snímky obrazovky

Snímky obrazovky

Kompletní hosting

Výběr licence a její uplatnění

Licence typu „vše je povoleno“

GPL

Jak licenci aplikovat

Udávání tónu

Vyhněte se soukromým diskuzím

Nezdvořilé chování potlačte hned v zárodku

Kontrolujte kód veřejně

Když otvíráte dosud uzavřený projekt, uvědomte si rozsah změn

Oznamování

Děkuji,