Ako spustiť projekt Open Source

Volám sa Dima a som vývojár z Ruby. Dnes sa chcem podeliť o svoje skúsenosti s vytváraním riešenia otvoreného zdroja. Poviem o tom, aké kroky by mal projekt podniknúť, ako zvoliť správnu funkčnosť pre prvé vydanie a s akými chybami som sa osobne stretol pri vytváraní svojho open source projektu.

Pred pol rokom som dostal nápad, že by bolo dobré vytvoriť projekt open source. Namiesto testovacích úloh na pohovor by mi stačilo poslať odkaz na úložisko. Vyhliadka na pomoc kolegom pri riešení ich každodenných problémov ma inšpirovala.

Vždy som nemal rád drahokamy na vytváranie administračných panelov. Akýkoľvek pohyb navyše musí predefinovať triedu a pre zmeny polí je potrebné vykonať zmeny v súboroch. Po premyslení a rozhovoroch s kolegami som sa rozhodol vytvoriť novú knižnicu, ktorá by bola flexibilná a nevyžadovala by dashboardy ani konfiguračné súbory.

Stanovte si ciele

Každý open source projekt rieši konkrétny problém. Porozprávajte sa s kolegami, chatujte, na fórach a podeľte sa o svoj nápad. To všetko vám pomôže pri prvých krokoch pochopiť dôležité veci, napríklad to, aké riešenia už existujú, a vypočuť si kritiku. Porozprávajte sa s ľuďmi, ktorí už majú otvorené projekty. Môžu vám poskytnúť veľmi cenné rady, takže sa nebojte opýtať a prevziať iniciatívu.

Jednou z dôležitých rád, ktorú som v tejto fáze dostal, je venovať pozornosť predovšetkým dokumentácii projektu. Môžete mať veľmi dobrý projekt, ale nikto nebude tráviť čas, aby pochopil, ako to funguje.

Najdôležitejším aspektom, bez ktorého nie sú možné ďalšie kroky, je motivácia. Myšlienka projektu by vás mala predovšetkým inšpirovať. Ľudia si najčastejšie zvyknú na nástroje, s ktorými pracujú, a spadajú do komfortnej zóny, takže vonkajšie názory môžu byť nejednoznačné.

Plánovanie

Výber určitého správcu úloh je vecou vkusu. Mal by mať jasný obraz o úlohách a etapách vášho projektu.

Rozdeľte úlohy na čiastkové úlohy. V ideálnom prípade, ak jedna úloha netrvá dlhšie ako 3–4 hodiny, je dôležité potešiť sa z implementácie malých úloh. Pomôže to zabrániť vyhoreniu a strate motivácie.

Používam otočný sledovač. Hlavnou výhodou je bezplatná verzia pre projekty s otvoreným zdrojovým kódom, kde môžete úlohy triediť podľa typu (vlastnosť, chyba, fuška, vydanie) a zoskupovať ich do vydaní a určených termínov.

Dokumentácia

Každý projekt s otvoreným zdrojom by mal obsahovať tieto veci:

  • PREČÍTAJ MA
  • Licencia Open Source
  • Sprievodné pokyny
  • Zoznam zmien

Súbor README nielen vysvetľuje, ako používať váš projekt, ale aj účel vášho projektu. Ak neviete, ako správne napísať súbor README, môžete sa pozrieť na ďalšie známe projekty otvoreného zdroja alebo použiť šablónu.

Licencia zaručuje, že ostatní môžu používať, kopírovať a upravovať zdrojový kód projektu. Tento súbor musíte pridať do každého úložiska so svojím projektom otvoreného zdroja. MIT a Apache 2.0 GPLv3 sú najobľúbenejšie licencie pre open source projekty. Ak si nie ste istí, čo si vybrať, môžete využiť túto pohodlnú službu.

Súbor CONTRIBUTING pomôže ostatným vývojárom prispieť do projektu. V prvých krokoch projektu nie je potrebné tomuto súboru venovať osobitnú pozornosť. Môžete použiť už pripravenú šablónu z iného projektu.

Zoznam zmien obsahuje podporovaný chronologicky usporiadaný zoznam významných zmien pre každú verziu. Rovnako ako v prípade súboru CONTRIBUTING, ani v tomto prípade sa neodporúča venovať tomu osobitnú pozornosť.

Verziovanie

Na sledovanie dôležitých zmien pre používateľov a prispievateľov existuje sémantická verzia. Číslo verzie obsahuje čísla a dodržiava nasledujúci vzor XYZ

  • X hlavné vydanie
  • Y menšie vydanie
  • Uvoľnenie záplaty Z.

Nepretržitá integrácia / nepretržité doručovanie

Na automatické spustenie testov a zostavenie používam Travis CI. Je tiež dobré pridať odznaky, ktoré zobrazia úspešné zostavenie zostavy v sprievodcovi, pokrytie testu (Codecov) a dokumentáciu (Inch CI).

Po každom novom potvrdení alebo zlúčení v hlavnej jednotke mám automaticky nasadenie na Heroku (veľmi pohodlná integrácia s GitHub). Všetky nástroje sú pre projekt open source úplne zadarmo.

Moje chyby

Na analýzu počiatočnej fázy som mal predstavu, ale neexistoval jasný plán. Rozhodol som sa, že to chcem urobiť bez toho, aby som mal jasnú predstavu o tom, koľko času to bude trvať, alebo o konkrétne zastúpenie funkcií, ktoré budú v prvej verzii knižnice. Mal som len veľa túžby a nedostatok jasného plánu.

Tiež som si po prečítaní histórie ďalších projektov (nielen open source) všimol, že v ranom štádiu sú niektoré plány príliš optimistické. Potrebujú prehodnotiť svoje silné stránky a schopnosti. Nie je však ľahké nájsť si každý deň čas na napísanie novej funkcie v projekte. Väčšina úloh sa nakoniec musela vykompenzovať, takže pre MVP zostalo nevyhnutné minimum.

Momentálne je môj jednoduchý administrátorský projekt v alfa verzii. Ďalšie plány zahŕňajú vytvorenie samostatnej verzie knižnice pre Hanami.