Jak (ne)dělat opensource (diskuse)

[blizzz]

ked je clovek mlady tak vacsinou nevie nic vlastne vytvorit len mechanicky kopiruje napady inych. cim je starsi tym je kreativnejsi, tym viac ma originalnych napadov, by mu mohli zarobit velke peniaze, ale zaroven ma menej casu ich realizovat.

[Martin Tůma]

Nemyslim si, že by opensource bylo o tom, vydělat velké peníze, tomu snad nevěří ani v Redhatu.

Problém s originálníma nápadama je ten, že jejich "kvalitu" zjistíš až když je zrealizuješ, což znamená dost značný úsilý. V poslední době jsem například "měl nápad" (tzn. hodily by se mi) na dvě další podobně složitý aplikace jako je Hypercube. Jenomže pustit se do něčeho takovýho s vidinou, že to kromě mě s vysokou pravděpodobností bude nakonec používat pár desítek lidí...

[daks]

>>úsilý<< ?

[Grunt]

Jenomže pustit se do něčeho takovýho s vidinou, že to kromě mě s vysokou pravděpodobností bude nakonec používat pár desítek lidí...

V první řadě to člověk píše sám pro sebe a ne pro ostatní. Zveřejnění je jen služba ostatním aby nemuseli začínat na zelené louce v případě, že se ocitnou v podobné situaci, aby si mohli opsat nějaký nápad (moderně se to opisování zove sdílení), atd.

[Franta]

+1

[Tomáš Bžatek]

Ano, tak koncipuju sve projekty i ja, nakonec to stejnak dopada tak, ze na prani uzivatelu neni cas

[Grunt]

A na tom je něco špatně?

[Grunt]

Jo? A není ta pravda úplně naopak. Tedy že čím je člověk starší a starší, tim víc kopíruje a kopíruje aby aspoň vypadal, že drží krok s ostatníma? U mě je to teda přesně naopak.

[psholty2]

Mam asi desiatku opensource projektov kade tade po webe ktore by mohol okrem mna este niekto pouzit, mam dalsiu desiatku opensource projektov kade tade po webe ktore nikto nikdy okrem mna nepouzije. V oboch pripadoch ma zaujima najme aspekt bezplatneho distribuovaneho zalohovania mojich zdrojakov na web. Sem tam sa niekto ozve, ale nijak ma to netrapi. Viem ze zdrojaky su tam a v pripade fatalneho zlyhania si ich mozem kedykolvek stiahnut.

To ze sa ale nikto neozve neznamena ze vas projekt nikto nepouziva, casto krat mam problem s pouzitime nejakej funkcie, dam to do googlu, najdem nejaky projekt ktory ju pouziva, pozriem ako sa dana funkcia vola, jake parametre, co a ako sa inicializuje, okopirujem a idem dalej. Ma teda zmysel zverejnovat kod aj ked sa nikto nikdy neozve.

[peter]

účelom toho programu malo byť vizualizovať dáta podľa Vašich požiadaviek, alebo urobiť Vás slávnym? :) Samozrejme, najlepšie je, ak sa podarí oboje, ale na to, aby mal projekt zmysel úplne stačí aj to prvé.

[Martin Tůma]

Účelem mého konkrétního projektu bylo si vyzkoušet, co všechno obnáší vytvořit a spravovat vlastní "reálný" opensource projekt. Což se myslim povedlo, protože mi to mimo jiné dalo odpověď na otázky typu: "Proč sakra k tomuhle projektu není žádná dokumentace, žádné příklady, a v případě GUI aplikací ani pitomý screenshot? Proč to sakra nejde skompilovat a poslední balíček/instalátor je k verzi co vyšla před rokem a půl?", který si pokládám vždy když hledám nějaký speciální tool/knihovnu.

Není zrovna potřeba stát se díky svému projektu slavným, ale některé (nezábavné) věci vás prostě donutí udělat až zájem lidí (nebo peníze, ale o těch se v opensource jenom mluví a nikdo je ještě nikdy neviděl ). Projektů ve stavu "pro mě dobrý" je na internetu mraky, ale když dojde na to to použít, začnete chápat, kde se v lidech bere ta implikace opensource => nepoužitelnej bastl.

[User682]

Na prvni misto, co delat, bych dal dokumentace, API a nejake priklady.

gf

[Luboš Doležel (Doli)]

Je to váš projekt. Jestli to člověk nepotřebuje sám pro sebe, tak co s tím. To je ta hlavní věc: děláte to pro sebe.

[User682]

Hodne veci, co clovek "jakoby nepotrebuje", tak po par letech jakoby najde. Ono, kdyz se vratite po par letech (treba i roce) k necemu, tak potom menite priority....

Zacina to tim, ze se divite, ze pri praci dvou lidi na projektu delate tak na 130% oba. Nebo, ze delate znovu analyzu Vaseho kodu. Nebo, ze to casem zabalite.

Prijde mi trochu u vyvoje divny, ze kdyz jeden "projde cestu", tak si ji musi projit i Ti dalsi misto toho, aby uz neco rozumneho podle Te dokumentace,..../* doplnte treba dale testy*/ delali.

gf

[Grunt]

LOL. Jsem jen čekal kdy. API, dokumentace a API, po tom touží především zloději a manipulátoři (všimněte si prosím, že jsem nikde nezmínil „jako vy“). V reálném projektu je to až ta úplně poslední věc.

[jarin]

Já mám zkušenost takovou, že pokud je to poslední věc v projektu, tak je nejlepší co nejdřív odejít. Nemám nervy na to účastnit se projektů, kde vývojáři nejsou ochotní formulovat svoje myšlenky jinak než kódem.

[Grunt]

Jakože jeden nebo pár lidí se bude obtěžovat s API nebo dokumentací pro to aby mohli komunikovat místo třeba jabberu nebo papíru a tužky? Ano. Samožejmostí je nějaké README nebo man stránka, ale proč se cpát s něčím takovým? Ti co znají kód komunikoují především pomocí kódu (někdy je těžké rozluštit i ten a pak je lepší použít hubu).

[Sten]

Dokumentaci: potřebná od začátku, nejlépe něco jako Doxygen nebo Javadoc. Bez ní totiž velmi těžko seženete někoho dalšího do týmu (stále se bavíme o open source), navíc je dost problematické se v tom vyznat, když ve svém vlastním kódu třeba o půl roku později budete ladit nějaký problém. I ty grafy kreslené Doxygenem hodně zlepšují orientaci v kódu (samozřejmě, spoust IDE umí tyhle grafy kreslit taky, ale pořád vám tam budou chybět komentáře).

API: to se opravdu dělá později, tak někdy krátce před beta verzí to stačí, hlavně je potřeba to dělat, teprve když už je jasné, co to vlastně bude dělat

Příklady: nějaké základní příklady, jak to používat, se rozhodně hodí, aby se projekt prosadil. Detailní příklady se stejně dělají, až když je API, aby se nemusely pořád přepisovat.

[xkucf03]

nejlépe něco jako Doxygen nebo Javadoc

Na tom IMHO vůbec nesejde. Důležité jsou spíš komentáře v kódu* – z nich si ten JavaDoc/Doxygen může každý vygenerovat sám, to je minimum práce (nebo spíš v případě Javy ani nic generovat nebude a prostě se na to koukne v IDE).

Spíš než tahle nízkoúrovňová dokumentace je důležitější nějaký celkový obrázek, architektura – rozepsat to v pár odstavcích a pár diagramech – mnohem cennější než automaticky generovaná dokumentace.

*) samozřejmostí by měl být popis u každé třídy a metody, k čemu slouží, jaký je její smysl (ne co dělá, to si přečtu v kódu). Bohužel na to spousta lidí kašle…

[Josef Kufner]

Komentáře v kódu a dokumentace generovaná Doxygenem je totéž. Tedy pokud na to vývojáři nekašlou. Přibalit pak ke zdojákům konfigurák pro Doxygen je drobnost a hodit na web vygenerovanou dokumentaci také. A nechat dokumentaci automaticky přegenerovat po každé aktualizaci repositáře jen všem ulehčí práci.

[Sten]

Na tom IMHO vůbec nesejde. Důležité jsou spíš komentáře v kódu* – z nich si ten JavaDoc/Doxygen může každý vygenerovat sám, to je minimum práce (nebo spíš v případě Javy ani nic generovat nebude a prostě se na to koukne v IDE).

Doxygen a Javadoc jsou komentáře v kódu

Spíš než tahle nízkoúrovňová dokumentace je důležitější nějaký celkový obrázek, architektura – rozepsat to v pár odstavcích a pár diagramech – mnohem cennější než automaticky generovaná dokumentace

To lze samozřejmě v Doxygenu popsat taky. A i ta automaticky generovaná dokumentace umí udělat hodně cenných diagramů.

[xkucf03]

Ano, vygenerovat lidem dokumentaci, aby to nemuseli dělat sami, je fajn… Ale snažil jsem se tím říct, že často jsou ty nejcennější informace schované v hlavách autorů a z kódu je nelze automaticky extrahovat – obecně jsou to odpovědi na otázky: „proč je tohle tak a tak?“ – zatímco z toho kódu si vyčteš jen „je to tak a tak“. Proto bych se přimlouval za to, aby autoři strávili v první řadě trochu času popsáním globální analýzy a nějaké vize, kam bude program směřovat – to je nenahraditelné (zatímco ten JavaDoc/Doxygen si přinejhorším každý vygeneruje sám).

[petr_p]

Když jsem začínal libisds, tak jsem přemýšlel, jak psát dokumentaci. Díval jsem se po všelijakých extraktorech komentářů, ale žádný mi nevyhovoval. Třeba taková věc, jako je dokumentace hodnot výčtového typu, je pro ně nemožný úkol. Aby z toho lezlo něco na úrovni, jako jsou manuálové stránky se synopsí, popisem a křížovými odkazy, je zcela nemožné. Takže jsem zatím skončil s komentáři v hlavičkovém souboru a adresářem drobných prográmků ukazujících použítí funkcí. Časem to asi přesunu do ručně psaných manualových stránek / DocBooku.

[xkucf03]

Taky se na to dá jít obráceně – primární zdroj dat mít třeba nějaké XML a z něj generovat jak soubory v daném jazyce s výčtovými typy, tak dokumentaci. Tímhle způsobem se dá pohodlně uchovávat víc strukturovaných metadat než by se vešlo do obyčejných komentářů v kódu (prostý text).

[Sten]

Doxygen je hodně mocný nástroj. Hodonty výčtového typu se dokumentují docela jednoduše:

/**
 * @brief Smoothness enumeration
 * @see someFunctionUsingIt
 */
enum Smoothness {
    SMOOTH_DEFAULT = 0, ///< Default smoothness
    SMOOTH_DRAFT = 0, ///< Draft smoothness
    SMOOTH_NORMAL, ///< Normal smoothness
    SMOOTH_FINEST ///< Finest smoothness
};

Křížové odkazy umí dělá @see, hodně složité stránky jde dělat třeba pomocí @subpage nebo @section, nakonec tam můžete použít i LaTeX.

[petr_p]

Je možné, že už se něco zlepšilo. Budu se muset na doxygen znovu podívat. Ale pořád mi něco vrtá v hlavě, že tam něco nešlo. Třeba ten tvůj kus není C99, protože C++ komentáře. Nebo jestli to byly víceřádkové komentáře u těch hodnot. Nebo enum type {} alias; a pak neschopnost pochopit alias ve void fce(alias identifier);. Fakt si už nevzpomínám.

[Ash]

s/C99/C89/

[xxxxxxxxxxx]

Většinu programu děláš pro sebe. Je nás míň jak Buzerantů tak se nediv že nění takovej zájem. Klasická mediální mrdka potřebuje konzumovat a na to potřebuješ prachy. Když je nemáš máš hovno. Jediný zbývá si budovat malé komunity lidí kteří mají o program zájem a furt dřít a dřít a dřít do umoru... J áto beru tak že je to takovj muj osobní "Džihád"! )

[GeoRW]

heh, no neviem, ci zaujem a popularita projektu u inych ludi je to, co daneho cloveka vedie k tomu vytvorit nejaky vlastny projekt. Dolezite je, ze to daneho cloveka bavi a ten program/projekt je uzitocny pre neho samotneho. Ze o to ma zaujem aj niekto iny a pripadne niecim prispeje, je len bonus navyse.

[huhla]

Sam delam celkem uspesny OS program. Nedelal jsem zadnou "kampan", lide si me na githubu nasli sami. Po dvou letech mam 80 forku a 3 stale prispivatele. Nedavno jsem ho prezentoval na konferenci.

Zakladni podle me je:

• Resit problem ktery jeste nebyl vyresen
• Minimalni ale velmi dobra dokumentace (readme)
• Pro knihovnu hodne prikladu, pro program podcast demonstrujuci pouziti
• Hackovatelnost, kdokoliv muze program pochopit a modifikovat behem jednoho vecera
• Standardni zavislosti a mainstream jazyk (u me Java)
• Dobry support v mail listu (ci v mem pripade na StackOverflow). Tohle je dulezite pro rychly rust.

Myslim ze v tomhle pripade je problem v prvnim bode. Autor napsal program, protoze se mu nechtelo instalovat Javu.

[Martin Tůma]

Myslim ze v tomhle pripade je problem v prvnim bode.

Ano, problém je v tomhle případě zcela jistě v prvním bodě, konec konců je o tom celý ten zápisek

Autor napsal program, protoze se mu nechtelo instalovat Javu.

Ano, ale takhle právě funguje opensource. Ten nemá rád Javu, tak začne dělat variantu v C++. Ten zas nemá rád GTK, tak začne dělat variantu v QT. A další opačně...

[Ivan]

Zrovna planarni kresleni grafu by se nam hodilo. Akorat bych to potreboval jako komponentu do naseho OS projektu a ne jako samostatnou aplikaci. Graphwiz uz je bohuzel prestarlej a moc se neudrzuje. Navic ma dost divoky API. Na druhou strnu toho jeste porad umi hodne. Nakonec jsem vzal zdrojaky programu kgraphviewer, vykuchal jsem z nich cca 25K radek a udelal jsem z toho QTckovou "komponentu". Do budoucna bych se ale rad zavislosti na dot-u zbavil, minimalne proto, ze Eclipse licence neni kompatibilni s GPL.

BTW: Nejdrazsi komponenta pro C# jakou jsem kdy videl byla prave na planarni kresleni, neomezena programatorska licence stala okolo 200K E. Takze v tyhle sfere urcite nejaky "trh" existuje.

PS: pokud jde o nas projekt, tak jsem zjistil, ze to balickovani je naprosto klicova vec. Jinak bude vetsina vyhrad uzivatelu spocivat v tom, ze to proste nezvadli nainstalovat a nakonfigurovat. A hlavne je jedno jestli vyvijis pro Linux anebo pro Wokna, vetsinu uzivatelu budou stejne Woknari - je to smutny, ale je to tak.

[Aleš Kapica]

Tak mě napadá, že požadavek - hledáme maintainera instalačních balíčků pro náš software - jsem v pracovních nabídkách zatím neviděl.

[petr_p]

Okamžitě se hlas v Red Hatu v Brně. Baličů je pořád nedostatek.

[Aleš Kapica]

Asi ne.. a ani se tomu nedivím.

[s0]

tak už přestaň kňourat, nějak to dohromady dáme ;) Navíc u nás je zásadní problém v tom, že nikdo neví, jestli můžeme distribuovat proprietární knihovny nebo ne. U jiných OSS problém odpadá. A to, že nejdou spustit je opravdu jen lenost tvůrce.

hlavní problém s balíčkováním je v tom, že je to hrozně nudná a nevděčná práce.

[Ivan]

Vono je to fakt dost velkej opruz. Pro Debian anebo Fedoru se tu a tam najde nejakej nadsenec, kterej balik udela. Horsi je to s woknama. MS vyresil problem dll hell tim, ze zaved Manifest hell. Takze je to ve vysledku jeste horsi. XPcka uz nenacitaji knihovny jen z aktualniho adresare, ale datavaji prednost "zaregistrovanym" knihovnam. Takze ja zkompiluju aplikaci oproti Qt 4.8.2 a prilozim k ni QCore4.dll verze (4.8.2) a funguje to jen to do doby nez si uzivatel nainstaluje nejakou jinou aplikaci, ktera navrdo nas*re starsi QCore4.dll nekam do Windows/system32. Ono to pak "funguje" akorat je to desne nestabilni. Ja zase tak moc neknouram, tahle nevdecna prace je proste soucast open-source. Kdybych delal jachting, tak bych zase musel surovat palubu.

PS: uz mas instalator pro Mac-a?

[Martin Tůma]

PS: uz mas instalator pro Mac-a?

Na instalátor se vám každej macista vykašle. Pokuď to nejde přetáhnout z dmg do Applications, tak je to pro něj bastl. Nicméně alespoň co se týče QT aplikací, tak macdeployqt to řeší celkem dobře.

[s0]

instalátor pro maca = dmg. A macdeployqt nefunguje 100%. Mám na to několika aplikacemi ověřený skript do cmake. Bohové, ten os x mne tak sere...

[s0]

nejdřív to musím vůbec slinkovat ;)

[psholty2]

Moja skusenost na windows je taka, ze pokial vo volani LoadLibrary pouzijem uplnu cestu k dll vo formate 8.3, tak sa ta kniznica skutocne nacita a pouzije.

[Ivan]

Tojo tohle funguje. Pokud ale primo spusteni aplikace zavisi na nejake knihovne tak na woknach je porad jeste problem. Navic QTcko muze byt zkompilovano pomoci MinGW anebo MSVC - vysledne jmeno knihovny je stejne, ale ABI se lisi. Proste QTcko jako "multiplatformni" framework nema jeste nektere veci doresene a jedna z nich je samotna instalace.

[Jardík]

nativní na dané platformě včetně look & feel

Qt má do nativního looku na Win co dohánět, ale snaží se. V Linuxu nativní look ... tam je nativní snad všechno.

[Martin Tůma]

Qt má do nativního looku na Win co dohánět, ale snaží se.

Na Windows XP IMHO QT zapadá líp, než na Windows 7, ale v zásadě to jsou jenom drobnosti. Když to srovnám s GTK nebo obskurnostma typu TCL/TK tak je to úplně někde jinde.

[pedro]

No, ja tomu extra nerozumim, ale...

1. Delam to pro sebe a mimochodem to necham jako OSS (protoze mam pocit, ze by se to treba mohlo nekomu hodit);

2. Tim padem mi odpada polovina vyse uvedenych pozadavku - asi to nemusim mit multiplatformni, asi se to nemusim ovladat z GUI atd.

3. Kdyz vidim zajem zvenci, tak to ev. zacnu dal vyvijet pro sirsi verejnost (podle chuti).

Planovite vytvorit "velky" a pouzivany OSS projekt neni az tak principialne odlisne od vytvoreni komercne uspesneho SW. A jeden clovek bez zdroju to asi fakt neda.

[deda.jabko]

Jestli chces, aby ti na stranku s projektem chodili lidi, hod to na freshmeat, nebo jak se to dneska jmenuje. Kazdy release ti pritahne hromadu lidi.

[Grunt]

Všude je něco. Není to tak dávno co jsem potřeboval real-time spektrograf pro audio v Linuxu (ve Windows jsem byl zvyklí za starých časů používat CoolEdit2000) a naprosto jsem hleďel kolik a v jakých období existuje alternativ. Teda alternativ…oni většinou neměli ani vlastní stránku, README a na kód se nesáhlo tak deset let (fungovalo to na dost obskurních toolkitech), ale i to je potřeba. Lepší než začínat od FFTW. To určitě není chyba. Chyba je jen distribuce. Spousta užitečného (a především zajímavého) kódu časem v internetu zapadne. Chtělo by to holt jen nějakou platformu i pro něco takového.

nechce se vám zkoumat DOT formát Graphvizu a psát si export.

Moje zkušenost je taková, že podobné programy vyžadují sice větší prvotní investici než běžné klikátory, ale velmi štědře se za snahu odvděčí. Sám to mám v plánu.

Dokonale multiplatformní program, nativní na dané platformě včetně look & feel

Chtělo by to jen nějakou šablonu.

Žádné závislosti na mraky nejrůznějších knihoven, nedej bože virtuální stroje nebo interprety

To je těžké. Samotného mě vždycky štvalo když si jedna mini-aplikace při instalaci vyžádala tisíc závislostí o velikosti 10× nebo když jsem mi pro kompilaci něčeho jednoduchého musel zkompilovat dvacet kravin (v Gentoo hodně, při ruční kompilaci ještě víc), jenže čim víc jsem si na to zvykl tím víc mě takové Firefoxy nebo Thunderbirdy štvaly. Holt je potřeba si uvědomit, že aplikace není jen aplikace sama, ale vše včetně závislostí. Některé moderní kodeky např používají FFTW jako stěžejní knihovnu. Vždycky když jsem viděl aktualizaci FFTW, tak se mi oči rozzářili (za dobu své existence zrychlilo několikrát). Jako autor bych byl asi taky radši, kdybych se o tu komponentu nemusel starat (obecný přínos to má taky). A že ve Firefoxu není podporován JPEG2000? Pche…

[Josef Kufner]

nechce se vám zkoumat DOT formát Graphvizu a psát si export.

Moje zkušenost je taková, že podobné programy vyžadují sice větší prvotní investici než běžné klikátory, ale velmi štědře se za snahu odvděčí. Sám to mám v plánu.

Jo, studium Graphvizu už se mi vrátilo mnohonásobně.

[Grunt]

Sakra, já si ho spletl s gnuplotem.

[Josef Kufner]

V Gnuplotu jsem dělal grafy do protokolů na měření. Fajn věc to je.

[Grunt]

Zdá se být. Proto to chci umět.

[petr_p]

Není to tak dávno co jsem potřeboval real-time spektrograf pro audio

Na to jsem používal eXtace. Bohužel jede přes esound, což prý už není moderní, a tak všechny distribuce jeho podporu vyhodily.

[Grunt]

Ten se mi nepodařilo rozjet, tak jsem se dostal myslím až k baudline. Ale jinak vypadá velice dobře.

[Martin Tůma]

To je těžké. Samotného mě vždycky štvalo když si jedna mini-aplikace při instalaci vyžádala tisíc závislostí o velikosti 10× nebo když jsem mi pro kompilaci něčeho jednoduchého musel zkompilovat dvacet kravin (v Gentoo hodně, při ruční kompilaci ještě víc), jenže čim víc jsem si na to zvykl tím víc mě takové Firefoxy nebo Thunderbirdy štvaly. Holt je potřeba si uvědomit, že aplikace není jen aplikace sama, ale vše včetně závislostí.

Problém je ten, že na linuxu to ještě za mohutného skřípění a dření jde. Ale v okamžiku, kdy potřebuješ takovou aplikaci pro Windows nebo Mac OS X a musíš si sám tyhle závislosti poshánět na internetu (a často i zkompilovat) už to není jenom o zvyku.

[jarin]

Poprvé co někdo na abclinuxu veřejně napsal, že forma je minimálně stejně důležitá jako obsah.

[s0]

ale prd. To je jasná věc. Alespoň každému, kdo není polodementní opice. Na druhou stranu chápu, že je někomu putna, jestli jeko SW někdo používá nebo ne.

[Franta]

Prezentace projektu je důležitější než projekt samotný.

???

[Martin Tůma]

Ano. Napíšeš-li opensource Autocad (tak dokonalej, aby k němu ani USAMA neměl žádný výhrady ) bude to úplně k ničemu, pokuď se o něm lidi nedozvědí.

[chrono]

Projekty, pri ktorých bola prezentácia dôležitejšia ako samotný projekt nebolo zrovna málo (KDE4, Pulseaudio...) a zlú mienku musa u ľudí odstraňovať už dosť veľa rokov.

[Franta]

nechce se vám zkoumat DOT formát Graphvizu ... Další adepty pak zavrhnete proto, že jsou v Javě...

Komu není rady... musí si napsat vlastní software

Nehledě na to, že pravděpodobně nemáte vůbec žádnou prezentaci vašeho projektu ale pouze zdrojáky na sourceforge či githubu

To je zásadní chyba*. Založit "projekt" na Githubu nebo něčem podobném je strašně snadné -- a v důsledku toho je i průměrná kvalita strašně nízko. Když pak narazím na takový "projekt", kde se autor ani neobtěžoval vytvořit stránky, napsat srozumitelný popis a nafotit obrazovky... obvykle jdu jinam. Málokdy se začtu do kódu nebo začnu hlouběji zkoumat, protože takového odpadu jsou všude kolem spousty.

Brzy však zjistíte, že to je zcela suveréně největší opruz z celého projektu, při každé nové verzi sestavovat vždy nový produkt.

Stejný problém řeší mnoho jiných lidí a je to vyřešené a zautomatizované. V podstatě jde jen o tu prvotní investici, pak už se další verze dělají (skoro) samy. Nicméně pro začátek bych to klidně nechal na někom jiném, kdo danou distribuci používá, ať udělá neoficiální balíčky (časem je můžeš převzít a udělat z nich oficiální). K tomu je důležité, aby šel program snadno zkompilovat a měl dobře zdokumentované závislosti.

Vymyslety si něco pro masy.

Záleží, jaká je tvoje motivace. Často naopak člověk nehledá slávu a oblíbenost, ale řeší nějaký vlastní problém -- a zveřejněné je to pro případ, že by to náhodou někdo mohl potřebovat, nebo by mohl pomoci s vývojem.

Hosting projektu zvolte tam, kde je to neprofláknutější

Základem je dobrý (přehledný, obsažný) web -- kde je hostovaný, je jedno (potřeba je vlastní nebo stabilní doména). Pak je potřeba být v různých katalozích, ohlohu atd. Zařídit, aby o tobě vycházely zprávičky (nové verze) nebo ideálně články a recenze. (jestli máš momentálně zdrojáky na SF nebo Gitoriousu nebo jinde, je irelevantní)

Prezentace projektu je důležitější než projekt samotný.

S tímhle přístupem můžeš jít prodávat nějaký proprietární shit -- tam taky obvykle převládá marketing nad kvalitou a užitečností.

Minete-li s vaším projektem zcela zájem uživatelů, zabalte to radši dřív než později.

Opět záleží na motivaci. Na rozdíl od proprietárního softwaru píší svobodný software obvykle lidé, kteří ho zároveň používají a potřebují -- takže v první řadě to děláš pro sebe. Tak proč s tím přestávat?

A hlavně se nenechte od nikoho odradit

+1 kritiku je potřeba filtrovat. Z té konstruktivní si vzít co nejvíc, tu ostatní naopak ignorovat.

*) pokud autor hledá uživatele/testery/přispěvatele

[jkb]

..píší svobodný software obvykle lidé, kteří ho zároveň používají a potřebují

to si myslim neni pravda. Ne, dokonce dokonce jsem si jist, ze to neni pravda.

[Franta]

Pokud je to tvoje zaměstnání, tak ho třeba osobně nepoužíváš/nepotřebuješ, ale zase ho používá tvůj zaměstnavatel. A co se týče amatérských/nezávislých projektů, tak proč jinak by to ti lidé dělali, kdyby ten software sami nepotřebovali?

[Martin Tůma]

Protože je to zajímavý problém k vyřešení? Protože se u toho spoustu věcí naučí? Protože mají pocit, že tím mají možnost splatí svůj "dluh" vůči opensource?

[Franta]

"Splácet dluh" se dá i něčím, co je z mého oboru (a čemu rozumím) a co je pro mne samotného užitečné. Proč bych si měl vybrat něco úplně jiného?

Totéž platí pro ty zajímavé problémy -- takových jsou spousty a všechny člověk za život vyřešit nestihne -- proto je přirozené si vybírat a vybírat ty, které jsou i k užitku. Na nějaké nepraktické intelektuální onanie má člověk čas tak na škole nebo pak v důchodu

[Martin Tůma]

Prezentace projektu je důležitější než projekt samotný.

S tímhle přístupem můžeš jít prodávat nějaký proprietární shit -- tam taky obvykle převládá marketing nad kvalitou a užitečností.

Mám zkušenost, že dobrý projekt je jen a pouze používaný projekt. Pokuď projekt má zanedbatelnou uživatelskou základnu, bude obsahovat spoustu chyb, které nikdo nebude hlásit. Testování skutečnými uživately se zkrátka nedá ničím nahradit i kdyby se evangelisti unit testů na hlavu stavěli.

Na rozdíl od proprietárního softwaru píší svobodný software obvykle lidé, kteří ho zároveň používají a potřebují.

Jak už tady někdo zmínil, toto je IMHO mýtus. A to nesoudím jenom podle sebe, kdy jsem projekt dostal do plně použitelného stavu v okamžiku, kdy už jsem jej dávno nepotřeboval...

[xkucf03]

O přínosu uživatelské základny není pochyb. Ale s tím, že „prezentace projektu je důležitější než projekt samotný“ prostě nesouhlasím. Dobrý projekt (resp. produkt, program) si cestu k uživatelům nakonec najde a bude k užitku. Ale špatný program s dobrým marketingem je tak akorát k napálení lidí, kteří pak budou naštvaní a zklamaní.

[Josef Kufner]

Ještě se může stát, že špatný program, který má dobrou dokumentaci a marketing, přitáhne zájem dalších lidí, kteří z něj udělají dobrý program. Dobrý program bez prezentace naopak může velmi lehce upadnout v zapomnění a bude se na něj jen prášit někde v koutě.

[Franta]

Možné to je. Třeba přinést hovno na stříbrném tácku a počkat, až z ho komunita předělá tak, že z něj bude dort nebo nějaká jinou pochoutku. Ale sympatičtější je mi ten druhý případ (začít s dobrým programem/myšlenkou a postupně přidat marketing/dokumentaci).

[Miloslav Ponkrác]

Já jsem svůj projekt založil na dotaženosti. Napsal jsem si kdysi WAMP server, a dotáhl ho do jednoduchosti, příjenosti, bezchybnosti a přitom bez omezení jakékoli možnosti.

Complex Web Server se masově používá a používají ho i firmy.

Podle mě největší slabinou většiny open source projektů je nedotaženost. Funguje to napůl. A složitě.

Nesouhlasím s tím, že člověk by měl dělat projekt pro sebe, protože pouze tato motivace stvoří obecně špatně použitelný projekt. Protože pro ostatní musíte udělat – dokumentaci, user friendly rozhraní, otestovat to na počítačových/platformových konfiguracích, které ani nezamýšlíte kdy v životě použít. Pak odpovídat lidem, udělat nějakou webovou stránku pro projekt.

Dál je nutné promyslet licenci. Licence musí být jasná ve dvou větách. Complex Web Server je volně pro jakékoli komerční i nekomerční použití, lze ho používat do komerčních projektů, jediné co musí být, že on sám musí být vždy zdarma.

Můj projekt není open source, přesněji nikdo mě o zdrojáky nepožádal.

Pokud uděláte projekt open source, přibudou vám další starosti. Udržovat nějaké sestavovací nástroje pro lidi. Udržovat systém zdrojáků, třeba ve formě veřejného VCS/SVN/Mercurial/Bazaar/GIT, cokoli. Napsat příručku pro instalaci/kompilaci/vnitřní architektuře.

Všiml jsem si, že v poslední době je velký zájem o open source projekty s nekomplikovanou licencí blízkou public domain. Sám ignoruji GPL projekty, protože s nimi nelze rozumně nakládat pro jejich virovost. Tedy z hlediska zdrojáků, pokud je mám jako hotový program je mi to fuk. Ale taková MIT, BSD a podobná licence velmi zvyšuje zájem o projekt.

Zkrátka, pokud někdo dělá open source projekt, nebo i closed source tak, že napíši to pro sebe a zveřejném – výsledkem je debakl jako kráva.

Buďte exhibicionisti, dělejte to pro slávu, dejte si za cíl, že to prosadíte. A nebo se na to vykašlete, protože to nemá smysl – i když náhoda občas prosadí i toto.

Miloslav Ponkrác

[xkucf03]

Ale taková MIT, BSD a podobná licence velmi zvyšuje zájem o projekt.

Pozor, tyto licence ale (na rozdíl např. od GPLv3) nijak neřeší patenty – takže uživatel podstupuje riziko, že ho autor může kdykoli zažalovat kvůli „duševnímu vlastnictví“ (ne kvůli samotnému autorskému dílu, ale kvůli softwarovým patentům v něm použitým).

[Miloslav Ponkrác]

GPL3 to také neřeší.

Nikdo na světě, zvláště v tomto bláznivém právním pojetí, nemůže dát záruku, že v GPL kódu není problém s patenty. Pokud nějaký „contributor“ bude ignorant a pošle dál jako GPL kód s patenty, nebo se zjistí, že nějaká blbost, o které nikdo netušil, že je možné jí patentovat (ála Apple idiot) je patentována, co se stane?

GPL 3 nejmenuje nikoho, kdo Vám dá záruku za patent – pouze popisuje, že tu záruku s licencí dostáváte. Ale nemůžete říct od koho jste jí dostal.

To bude veselé, pokud se do toho pustí soud u někoho, kdo v GPL 3 kód má patenty a neví se od koho kód je.

Stejně tak si dokáži představit svinské jednání, kdy jako autor pustím GPL 3 kód se svými patenty a po čase je začnu vymáhat. V žádné licenci GPL 3 není uveden, kdo je autor či kdo uvádí do světa GPL 3 kód. Takže to klidně může být i autor a nikdo to nedokáže – dá si pozor, aby nezanechal nikde své jméno.

Následně autor začne soudně vymáhat po uživatelích GPL kód poplatky za patenty a bude tvrdit, že nikdy žádné svolení do GPL kódu nedal. A teď chci vidět tu ochranu proti patentům a patentovým poplatkům. Je nulová a uživatelé GPL 3 kódu si to vyžerou až do dna i s pokutami.

Dokud nebude v GPL licenci jasně dané, kdo poskytuje licenci a kdo tedy dává záruku za patenty – pak ochrana GPL 3 proti tomu co píšete je nulová a velmi chabá.

[psholty2]

Blbost!

> Stejně tak si dokáži představit svinské jednání, kdy jako autor pustím GPL 3 kód se svými patenty a po čase je začnu vymáhat.

Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.

Ak by to urobil tak ti spolu s GPL odovzda prava pouzivat zadarmo tie patenty. Ak to nechce, nema pouzivat GPL 3.

> Pokud nějaký „contributor“ bude ignorant a pošle dál jako GPL kód s patenty,

Pokial by pouzil vami zminovany MIT alebo BSD kod, ma problem. Ak pouzije GPL 3 kod a prida ho do vasho GPL 3 kodu, nema ziaden problem, vid prvy odstavec.

> Následně autor začne soudně vymáhat po uživatelích GPL kód poplatky za patenty a bude tvrdit, že nikdy žádné svolení do GPL kódu nedal.

Dal. Je to v GPL 3 jasne napisane ze dava neobmedzene celosvetove bezplatne povolenie na pouzivanie, predaj, zmenu, sirenie atd...

Chod trolovat niekam inam.

[Miloslav Ponkrác]

Je to blbost do té doby, než se ocitnete u soudu. První soud ukáže, jak GPL3 „dává jistotu ohledně patentů“.

Kód s GPL3 licencí nijak NEJMENUJE toho, kdo vám dává záruku ohledně patentů.

Když si stáhnete GPL3 kód, nemusí tam být vůbec nikdo jmenován. Prostě máte kód, k tomu soubor s GPL3 licencí. Předpokládejme, že není tam jediné jméno, nevíte, kdo je autor.

Stanete před soudem za porušení patentů, který byl nalezen v GPL3 zdrojovém kódu, který jste si stáhnul. Pak se nasmějete, protože jste za to odpovědný vy, že jste použil patenty. Co odpovíte soudu, kdo vám dal práva na patenty? Kdo konkrétně? To bude smíchu.

Já vám klidně dám papír, že vám patři Karlštejn. Stejně jako GPL3 vám dá v písmenkách, že máte bezplatné povolení na patenty. U soudu bude obojí stejně k ničemu. Pokud to nebudete schopen prokázat poněkud konkrétněji.

Klidně si věřte čemu chcete. Nazvěte mě trolem. To, že jste fanatik a nesnesete, když někdo poukáže na problém v GPL3, říká něco o vás.

GPL3 se stává to, co prohibici. Je čím dál restriktivnější, a stejně je děravá jako řešeto, kdyby přišlo do tuhého.

[Franta]

Kód s GPL3 licencí nijak NEJMENUJE toho, kdo vám dává záruku ohledně patentů.

Záruku poskytuje ten, kdo do kódu přispěl -- je to ochrana před tím, aby tě pak nežaloval kvůli patentům.

Samozřejmě tě to neochrání před patentovým trolování někoho třetího (nepřispěvatele), ale to nedokáže žádná softwarová licence. Každopádně GPLv3 řeší alespoň část problému (tu řešitelnou), zatímco BSD/MIT neřeší nic.

[GeoRW]

Podle mě největší slabinou většiny open source projektů je nedotaženost.

To neni slabina, to je sila open source. Akoby povedal klasik: "Release early, release often."

To, ze sa mnohe open source projekty neuchytia je uplne normalne. Je to jeden velky kotol, v ktorom sa to vsetko vari a z ktoreho raz za cas vylezie nieco velmi dobre.

[Miloslav Ponkrác]

Řada projektů by se uchytila spíše, kdyby byly dotáhnuté.

To už můžete rovnou dělat přednost z mentální retardace mezi lidmi.

[GeoRW]

ak ste necital The Cathedral and the Bazaar od Eric S. Raymonda, tak si to precitajte. Tam aj najdete vysvetlenie pre "Release early, release often." a v com je jeho vyhoda oproti tradicnemu modelu

[miso]

Su tam vysvetlene aj ine veci, ktore M.Ponkracovi davaju za pravdu. Bazar nie je smetisko

[GeoRW]

ja som reagoval na jednu konkretnu vetu z jeho prispevku, viz. diskusiu vyssie

[Josef Kufner]

Kdepak. Je to slabina.

"Release early, release often." je o tom, aby autor věci zveřejnil radši dřív než později. Nijak to neřeší kvalitu.

Kdežto pokud autor tvoří program, který je pouze nástrojem pro vyřešení daného problému a nemá žádnou motivaci k údržbě a dalšímu rozvoji, bude z toho odpad i když to zveřejní hned a pak i každou změnu, jakmile ji udělá. Takový autor totiž ukončí práci na projektu v okamžiku, kdy je problém vyřešen, v lepším případě si napíše malou nápovědu a pár poznámek na později. Výsledkem je polofunkční nedodělek s hromadou chyb a pochybnou kvalitou. Přitom "Release early, release often." nebylo nijak porušeno.

Teprve v okamžiku, kdy autor použvá svůj program delší dobu na řešení mnoha instancí daného problému, se program rozvíjí a udržuje. Šance jsou lepší, pokud takový program je součástí činnosti generující zisk. V tom případě je zájem na údržbě a dříve či později bude potřeba přibrat dalšího programátora a tím vznikne poptávka po dokumentaci a dalších klíčových věcech. A teprve v tu chvíli se program stává užitečným pro ostatní a má slušnou šanci na přežití.

[GeoRW]

Ked je to raz zverejnene, tak to moze ktokolvek zobrat a vylepsit a nemusi uz zacinat na zelenej luke. Keby open source fungoval tak, ze by ten svoj program bol kazdy nuteny vylepsovat a testovat na vlastnu past dovtedy, kym to nebude perfektne a az potom by to releasol, tak by sme tu mali velmi malo open souce programov. Aj ked dany program plni len jednu konkretnu funkciu a je v nom mnozstvo bugov, tak pre niekoho ineho moze mat hodnotu prave ta funkcia, ktora potrebnu ulohu splni. Ten niekto potom moze program vylepsit o nejaku dalsiu funkciu, pripadne opravit nejake bugy, na ktore narazi. Takto proste funguje open source, kde ma malokto velke mnozstvo casu a prostriedkov nato, aby vytvoril dokonaly program a az potom ho releasol. Vacsinou by skoncil este predtym, nez by sa k releasu dostal a cela praca by vysla na zmar. Cim skorej clovek releasne, tym je aj vacsia sanca, ze si jeho pracu niekto vsimne a ked je to dobry napad, tak aj s niecim pomoze. Su ludia, ktori napriklad robia len dokumentaciu, technicky hackovat kod nedokazu. Dalej ludia, ktori vedia spravit artwork (napr. ikony a pod.). "Release early, release often" samozrejme z pohladu zvonka znamena, ze je mnozstvo nedorobenych programov, ale to je vysledkom toho, ze open source komunita ma obmedzene zdroje a cely vyvoj funguje takto otvorene. No napriek tomu dokazala vytvorit mnozstvo kvalitnych programov a dalsie su stale vytvarane a vylepsovane.

[Josef Kufner]

Přečti si to ještě jednou

[GeoRW]

to je dobry argument

[GeoRW]

inak ak myslis to tvoje kategoricke, ze je nieco podla teba odpad, tak anglicania/americania maju jedno prislovie, ze "One man's trash is another man's treasure".
Takisto co sa tyka kvality, viz. z wikipedie

"Advocates argue that this allows the software development to progress faster, enables the user to help define what the software will become, better conforms to the users' requirements for the software, and ultimately results in hiher quality software."

a to som na tu wikipediu nepisal ja

[Ash]

Zkrátka, pokud někdo dělá open source projekt, nebo i closed source tak, že napíši to pro sebe a zveřejném – výsledkem je debakl jako kráva.

Pokud bylo cílem něco pro sebe napsat, a dát to k dispozici ostatním, potom cíle bylo dosaženo. Debakl je něco jiného. Debakl by to byl, kdyby cíle dosaženo nebylo, a to výrazně.

Buďte exhibicionisti, dělejte to pro slávu, dejte si za cíl, že to prosadíte. A nebo se na to vykašlete, protože to nemá smysl – i když náhoda občas prosadí i toto.

Věřím, že vás moci lidí neposlechne, a že ti, kteří si pro sebe něco napsali, to také zveřejní, klidně nedotažené a bez dokumentace, stačí fakt jen zdrojáky

Víte co se říká - zastřelím všechny, Bůh si je už přebere. Stejně tak s projekty - zveřejnit všechno, komunita si to už přebere.

A když z toho někdo bude chtít udělat úspěšný projekt, a bude ho to bavit, může směle začít! Představa, že by to musel dělat autor projektu, který o to nejen nestojí, ale ani by ho to nebavilo, je mimo realitu ve stylu "dělejte to tak, protože já bych to tak dělal". IMHO je lepší, když lidé dělají to, co je baví, a ne to, co si jiní lidé myslí, že by je mělo bavit.

Na dotahování a prosazování je potřeba hodně času a energie (20/80), a je otázka, jestli to vůbec někdo bude chtít. To si může dovolit komerční firma, tlačit lidem něco co (možná) vlastně ani nepotřebují, marketing udělá své. Neumím si představit, že by takhle někdo něco lidem tlačil pod frňák, ve svém volném čase dotažené do (téměř) dokonalosti. To mu zabrání napsat 4 další zajímavé věci, z nichž některá by se mohla uchytit.

[Martin Tůma]

Problém je ten, že pokuď projekt nedosáhne alespoň určité míry "dotaženosti", nikdo z komunity se ho nechopí. Pokuď už člověk takovej projekt vůbec najde, tak ho s největší pravděpodobností ani nezkusí, protože pravděpodobnost, že program, kterej nemá žádnou dokumentaci (nemyslím teď kódu, ale popis aplikace samotné), screenshoty ani ukázky je v drtivé většině případů jenom smetí.

[Ash]

Stačí název a dvěma větami co program dělá. Pokud je to něco zajímavého, stačí už jen ta myšlenka samotná k tomu, aby se někomu hodila a rozvinul ji.

Jinak souhlasím, je vždy lepší když jde program nainstalovat a demonstrovat nějakou základní funkčnost. Ale nelze automaticky čekat, že to je "produkt", a "produkt" požadovat. Tohle není bussiness.

[xkucf03]

Myšlenka samotná nestačí – resp. někdo jiný ji možná rozvine, ale ve svém projektu, nebude přispívat do něčeho, co vlastně ani neexistuje – podívej se na SourceForge nebo jiné hostingy, jsou tam spousty projektů s hezkou vizí, ale nedotažené, resp. nikdy ani nezačaly, není tam ani řádek kódu. A i když ta myšlenka může být dobrá, nikdo se k tomu nepřipojí – buď začneš na svém rovnou nebo nad tím budeš chvíli přemýšlet a pak dojdeš k závěru, že asi nemá cenu kontaktovat někoho, kdo na to roky nesáhl a neudělal žádnou práci.

Chce to prostě tu dotaženost/kvalitu programu a kvalitu/velkolepost prezentace a dokumentace držet nějak v rovnováze – nic se nemá přehánět a mělo by to zhruba odpovídat: když najdu projekt s pěkným webem a slušnou dokumentací, tak čekám, že odvedli i kus dobré práce v kódu, jinak budu nepříjemně překvapený. A naopak když je dobrý program, tak je škoda, aby zapadl kvůli mizerné prezentaci a tomu, že autor byl líný udělat pár snímků obrazovek nebo popsat dva tři příklady.

[Grunt]

když najdu projekt s pěkným webem a slušnou dokumentací, tak čekám, že odvedli i kus dobré práce v kódu

Vadný předpoklad.

[Franta]

U proprietárního komerčního softwaru ano (chtějí prodat licence, tak je tam jasná motivace), ale u svobodného softwaru? Jasně, někdo může chtít ošálit uživatele a nalákat je na hezkou prezentaci, ale podle mého to není pravidlem -- spíš to většinou bývá naopak: relativně dobrý program s mizernou prezentací a dokumentací.

[Grunt]

Spíš jde o takové ty prezentace co se strašně otevřeně snaží tvářit (a že je jich jak hub po dešti), ale přitom jsou výsledky otevřené jako moje kalhoty.

[Ash]

Jojo, projekt už je do detailu naplánován, prezentace a web hotový, ale programátora do týmu ještě hledají :D

[Ash]

Myšlenka samotná stačí, protože jedním z cílů FLOSS je nejen šířit kód, ale i myšlenky. Takže pokud jeden projekt umožní vznik jiného projektu, koho zajímá, že původní projekt, který nota bene autor dělal jen pro sebe, se nerozvinul? Přece nikoho. On se rozvinul ve svém následovníkovi o generaci později. Máš děti? :D

Proč pořád myslíš jako v bussiness sféře, kde komerční neúspěch produktu a úspěch konkurenčního s téže myšlenkou je sakra velký problém? Nechápeš, že jsi úplně v jiném světě? Tady to problém není. Žádný. Když někde nevznikne použitelný kód pro základ projektu, nevadí. Prostě nevznikl, autor si to psal pro sebe, není charita nebo komunista aby ho psal pro ostatní. Někdo jiný se myšlenky uchopil, a udělal z toho projekt, který třeba úspěšný i mezi jinými lidmi bude, protože autor ambice pro takovýto vývoj má, myšlenkou se nedchnul a podobně.