Hogyan lehet elindítani az Open Source projektet

A nevem Dima és Ruby fejlesztő vagyok. Ma szeretném megosztani tapasztalataimat egy nyílt forráskódú megoldás létrehozásával kapcsolatban. Beszélek arról, hogy milyen lépéseket kell megtennie a projektnek, hogyan kell kiválasztani a megfelelő funkcionalitást az első kiadáshoz, és milyen hibákkal szembesültem személyesen a nyílt forráskódú projekt létrehozásakor.

Fél évvel ezelőtt felmerült bennem az ötlet, hogy jó lenne egy nyílt forráskódú projektet létrehozni. Az interjú tesztfeladatai helyett elegendő lenne egy linket elküldeni az adattárhoz. Az a lehetőség, hogy segítsek a kollégáknak a mindennapi problémáik megoldásában, inspirált.

Mindig nem szerettem a drágaköveket adminisztrációs panelek létrehozásakor. Bármely extra mozgásnak újra kell definiálnia az osztályt, és a mezők módosításához meg kell változtatnia a fájlokat. Gondolkodás és beszélgetés után a kollégákkal úgy döntöttem, hogy létrehozok egy új könyvtárat, amely rugalmas lenne, és nem igényelne irányítópultokat vagy konfigurációs fájlokat.

Határozza meg a célokat

Minden nyílt forráskódú projekt megold egy adott problémát. Beszéljen kollégáival, beszélgetésekkel, fórumokkal és ossza meg ötleteit. Mindez segít az első lépésekben a fontos dolgok megértésében, például a már létező megoldásokban és a kritikák meghallásában. Beszéljen olyan emberekkel, akik már rendelkeznek nyílt forráskódú projektekkel. Nagyon értékes tanácsokkal szolgálhatnak, ezért ne féljen kérdezni és kezdeményezni.

Az egyik fontos tanács, amelyet abban a szakaszban kaptam, az, hogy először figyeljek a projekt dokumentációjára. Nagyon jó projekted lehet, de senki nem fogja eltölteni az idejét, hogy megértse, hogyan működik.

A legfontosabb szempont, amely nélkül a további lépések lehetetlenek, a motiváció. A projekt ötletének elsősorban inspirálnia kell. Leggyakrabban az emberek megszokják az eszközöket, amelyekkel dolgoznak, és kényelmi zónába esnek, így a külső vélemények kétértelműek lehetnek.

Tervezés

Egy bizonyos feladatkezelő kiválasztása ízlés kérdése. Világos képet kell adnia a projekt feladatairól és szakaszairól.

A feladatokat ossza fel részfeladatokra. Ideális esetben, ha egy feladat nem tart tovább 3-4 óránál, akkor fontos, hogy élvezze a kis feladatok végrehajtását. Ez segít elkerülni a kiégést és a motiváció elvesztését.

Pivotal trackert használok. A legfőbb előny a nyílt forráskódú projektek ingyenes verziója, ahol a feladatokat típusok szerint rendezheti (szolgáltatás, hiba, házimunka, kiadás), és csoportosíthatja kiadásokra és meghatározott határidőkre.

Dokumentáció

Minden nyílt forráskódú projektnek tartalmaznia kell a következőket:

  • README
  • Nyílt forráskódú licenc
  • Hozzájáruló irányelvek
  • Változási napló

A README fájl nemcsak a projekt használatát, hanem a projekt célját is elmagyarázza. Ha nem tudja, hogyan kell helyesen írni a README fájlt, megnézhet más ismert nyílt forráskódú projekteket, vagy használhat sablont.

A licenc garantálja, hogy mások is használhatják, másolhatják és módosíthatják a projekt forráskódját. Hozzá kell adnia ezt a fájlt a nyílt forráskódú projekt minden tárházához. Az MIT és az Apache 2.0 GPLv3 a legnépszerűbb licencek a nyílt forráskódú projektekhez. Ha nem tudja biztosan, mit válasszon, igénybe veheti ezt a kényelmes szolgáltatást.

A CONTRIBUTING fájl segít más fejlesztőknek hozzájárulni a projekthez. A projekt első lépéseinél nem szükséges különös figyelmet fordítani erre a fájlra. Használhatja a már elkészített sablont egy másik projektből.

A Changelog az egyes verziók támogatott, időrendi sorrendben tartalmazza a jelentős változások listáját. Csakúgy, mint a HOZZÁJÁRULÁS fájlnál, én sem tanácsolom, hogy erre korai szakaszban különös figyelmet fordítsak.

Verziózás

A felhasználók és a közreműködők számára fontos változások nyomon követésére van egy szemantikus változat. A verziószám számokat tartalmaz, és ragaszkodik a következő XYZ mintához

  • X nagyobb kiadás
  • Y-moll kiadás
  • Z patch kiadás

Folyamatos integráció / folyamatos szállítás

A tesztek és a build automatikus futtatásához a Travis CI-t használom. Célszerű kitűzők hozzáadása a build varázslóban történő sikeres összeszerelésének, a teszt lefedettségének (Codecov) és a dokumentáció (Inch CI) megjelenítéséhez.

Minden új elkötelezettség vagy egyesítés után a masterben automatikusan telepítem a Heroku-t (nagyon kényelmes integráció a GitHub-hoz). Minden eszköz teljesen ingyenes egy nyílt forráskódú projekt számára.

Az én hibáim

A kezdeti szakasz elemzéséhez volt egy ötletem, de nem volt világos terv. Úgy döntöttem, hogy ezt úgy akarom megtenni, hogy nincs világos elképzelésem arról, hogy mennyi időbe telik, vagy a könyvtár első verziójában található funkciók konkrét ábrázolása. Nagyon sok vágyam volt és nem volt világos tervem.

Továbbá, miután elolvastam más projektek történetét (nem csak nyílt forráskódú), észrevettem, hogy korai szakaszban egyes tervek túl optimisták. Újra kell értékelniük erősségeiket és képességeiket. De nem könnyű naponta időt találni egy új funkció megírására a projektben. A feladatok nagy részét végül ki kellett gyomlálni, így az MVP-hez szükséges minimumot meg kellett hagyni.

Jelenleg az egyszerű admin-projektem alfa verzióban van. További tervek között szerepel a könyvtár külön verziójának létrehozása a Hanami számára.