A növekvő projekt irányításának megértése

A projekt egyre növekszik, az emberek elkötelezettek, és te is elkötelezted magad, hogy ezt a dolgot csinálod. Ebben a szakaszban felmerül a kérdés, hogy hogyan kell a rendszeres résztvevőket beépíteni a munkafolyamatba, függetlenül attól, hogy valaki kódot ad hozzá, vagy épp megoldja a közösségi vitákat. Ezeket a kérdéseket válaszoljuk most meg.

Milyen példák vannak a nyílt forráskódú projektekben használt formális szerepekre?

Sok projekt hasonló struktúrát követ a résztvevői szerepek és a szerep azonosítása szempontjából.

Hogy ezek a szerepek valójában mit jelentenek, teljesen rajtad múlik. Íme néhány szerepkör:

  • Karbantartó (Maintainer)
  • Résztvevő (Contributor)
  • Commiter (Committer)

Néhány projektnél a “karbantartók” azok az emberek akiknek kód módosítási joguk van. Más projektekben, egyszerűen csak hétköznapi résztvevők, akik a README állományban fel vannak sorolva.

A karbantartó nem feltétlen szükséges, hogy olyan ember legyen aki kódot ír a projektben. Lehet olyan, aki nagyon sok munkát fektet a projekt ismertté tételébe, vagy rengeteg dokumentációt ír, hogy könnyebben érthető legyen a projekt mások számára. Függetlenül attól, hogy mit csinál nap mint nap, a karbantartó valószínűleg olyan ember, aki felelősséget érez a projektért, és elkötelezett amellett, hogy jobbá tegye azt.

“Résztvevő” akárki lehet aki kommentez egy hibát vagy egy beolvasztási kérelmet, vagy más értéket ad a projekthez (megold egy hibát, kódot ír, vagy eseményeket szervez), vagy bárki, akinek a módosítását beolvasztották a projektbe (talán ez a legszűkebb definíció).

A “committer” fogalma segít abban, hogy megkülönböztethessük a kódhoz való hozzáférést, mint speciális felelősséget attól, amelyet más résztvevői típusok képviselnek.

Bármilyen szerepkört definiálhatsz a projektedben, de fontold meg a tágabb definíciók használatát hogy a közreműködés más formáit is ösztönözd. Használhatsz vezetői szerepeket, hogy hivatalosan elismerd azokat a személyeket, akik kiemelkedő mennyiségű munkát fektettek a projektbe, függetlenül a technikai készségeiktől.

Hogyan formalizálhatom ezeket a vezetői szerepeket?

A vezetői szerepek formalizálása segít abban, hogy az emberek magukénak érezzék a projektet, és jelzi a többi közösségi tag számára, hogy kitől várhat segítséget.

Kisebb projekt esetén a vezetők kijelölése annyiból áll, hogy a README vagy a CONTRIBUTORS szövegfájlba beírod a nevüket.

Nagyobb projekt esetén, ha van weboldala, hozz létre egy csapatoldalt, ahol bemutathatod a vezetőket. Például, Postgres projektnek van egyátfogó csapatoldala rövid bemutatkozással minden résztvevő esetén.

Ha a projektben nagyon aktív a közreműködő közösség, akkor a “karbantartók” szűkebb köre vagy akár albizottságok alakulhatnak ki, akik a különböző problémakörök (például biztonsági, problémamegoldó vagy közösségi magatartás) kezelését vállalják. Hagyd, hogy az emberek önszerveződjenek és önkéntesek jelentkezzenek azokért a szerepekért, amelyeket a legjobban szeretnének.

A vezetői csapatok egy kijelölt csatornát hozhatnak létre (például IRC) vagy találkozhatnak rendszeresen egyéb projekt megbeszéléseken (mint a Gitter vagy Google Hangout). Akár nyilvánosak is lehetnek ezek, így a többi résztvevő is láthatja. Cucumber-ruby, például, minden héten időt biztosít erre.

Miután létrehoztad a vezetői szerepeket, ne felejtsd el dokumentálni, hogyan érhetik el őket az emberek! Határozz meg egy világos folyamatot arra vonatkozóan, hogy valaki hogyan válhat karbantartóvá, vagy csatlakozhat egy albizottsághoz a projektben, és írd le a GOVERNANCE.md-ben.

Az olyan eszközök, mint a Vossibility segíthetnek nyilvánosan nyomon követni, hogy ki, mennyivel járul hozzá a projekthez. Az ilyen információk dokumentálása és publikálása megakadályozza azt, hogy a közösség úgy tekintsen a karbantartókra, mint egy szűk, zárt csoportra, akik önkényesen döntenek.

És végül, ha a projekted a GitHub-on van, gondolkozz el azon, hogy a projektedet a személyes fiókodból egy szervezeti fiókba (Organization account) migrálod, legalább még egy helyettes adminisztrátor felvételével. A GitHub szervezeti fiók segít abban, hogy könnyebben kezeld a jogosultságokat, a kód tárolókat, és több társtulajdonost beállítva segít megőrizni a projekt örökségét.

Mikor kell valakinek commit jogot adnom?

Néhányan azt gondolják, hogy mindenkinek, aki hozzájárul a projekthez. Ha ezt teszed, akkor növeled az emberek felelősség érzetét a projekted iránt.

Másrészről, különösen komplex és nagy projektek esetén, csak azoknak az embereknek célszerű ilyen jogot adni, akik bizonyították elkötelezettségüket a projekt felé. Nincs aranyszabály, hogy melyik a jobb, neked kell eldöntened, hogy számodra mi a megfelelő.

Ha a projekt a GitHub-on van, használhatsz védett kód ágakat (branch), melyekkel szabályozni tudod, hogy kik és milyen feltételekkel olvaszthatnak be kódot egy kód ágra.

Melyek a nyílt forráskódú projektek közös irányítási struktúrái?

A nyílt forráskódú projektekhez általában három közös irányítási struktúra tartozik.

  • BDFL: BDFL rövidítés a “Benevolent Dictator for Life” rövidítése (Jóindulatú diktátor). Ebben a struktúrában minden fontosabb döntésnél a végső szó egy emberé, általában a projekt létrehozójáé, vagy tulajdonosáé. A Python egy klasszikus példa. A kisebb projektek alapértelmezetten BDFL struktúrán alapulnak, mert csak egy-két karbantartó van. Azok a projektek is ebbe a kategóriába esnek, amelyeket egy cég felügyel.

  • Meritokrácia: (Megjegyzendő, hogy a “meritokrácia” fogalma negatív felhangú néhány közösség vagy kultúra számára, amelynek összetett társadalmi és politikai története van.) A meritokráciában az aktív karbantartók, akikről köztudott a szakértelmük, formálisan is jogot kapnak a döntések meghozatalára. Általában a döntés ekkor is konszenzuson alapul, egyszerű többséggel. A meritokrácia úttörője az Apache Foundation; minden Apache projekt meritokrácia. Csak egyének járulhatnak hozzá a kódhoz, cégek vagy cég nevében eljáró egyének nem.

  • Liberális hozzájárulás: A liberális hozzájárulás modellje szerint a legtöbb munkát végző embereket elismerik a legbefolyásosabbnak, de ez a jelenlegi munkán és nem a történelmi hozzájárulásokon alapul. A főbb projekt döntéseket a konszenzus-keresési folyamat jellemzi (a főbb ellentétek feloldása), nem pedig pusztán a szavazás, és arra törekszenek, hogy minél több közösségi igényt figyelembe vegyenek eközben. Ilyen projekt a Node.js és a Rust.

Hogy melyiket kell használnod? Tőled függ! Mindegyik modellnek vannak előnyei és hátrányai. És bár elsőre teljesen másnak tűnhetnek, mindhárom modellben több közös vonás van. Ha érdekel valamelyiknek a használata, nézd meg ezeket a sablonokat:

Szükségem van-e irányítási dokumentumokra, amikor elindítom a projektemet?

Nincs szabály arra, hogy mikor kell a projekt irányítási dokumentumát elkészíteni. Sokkal könnyebb megalkotni, miután láttad a közösség dinamikájának működését. A nyílt forráskódú irányítás legszebb (és egyben legnehezebb) része az, hogy a közösség formálja azt!

Néhány korai dokumentáció azonban elkerülhetetlenül hozzásegít a projekt stabil irányításához, ezért érdemes az alapokat leírnod. Például meghatározhatod a viselkedésre vonatkozó egyértelmű elvárásokat vagy a részvételi folyamat működését, akár a projekt indulásakor is.

Mielőtt olyan nyílt forráskódú projektet indítasz, amelyet a céged kezdeményez, mindenképpen érdemes megvitatni és tisztázni a céges elvárásokat a karbantartással és döntéshozatallal kapcsolatosan, hogy a projekt gördülékenyen haladjon. Célszerű nyilvánosan elmagyarázni, hogy a vállalat hogyan (vagy épp nem) fog részt venni a projektben.

Mi történik, ha vállalati alkalmazottaktól érkezik hozzájárulás?

A sikeres nyílt forráskódú projekteket sok ember és cég használja, és egyes vállalatok a projekthez köthető bevételi forrással is rendelkezhetnek. Például egy vállalat kereskedelmi szolgáltatásának részeként felhasználhatja egy ilyen projekt kódját.

Ahogy a projekt egyre szélesebb körben kerül felhasználásra, a hozzáértő emberekre egyre nagyobb lesz az igény - lehet, hogy te leszel az egyik! - és néha fizetnek majd a projektben végzett munkájukért.

Fontos, hogy az üzleti tevékenységet normálisnak tekintsük, és csak egy fejlesztést ösztönző lehetőségként kezeljük. Természetesen a fizetett fejlesztőknek nem szabad különleges bánásmódot kapniuk azokkal szemben, akinek ezért nem fizetnek; minden hozzájárulást technikai szempontból kell értékelni. Az üzletileg támogatott embereknek nem szabad kényelmetlenül érezni magukat, még akkor sem, ha a saját használati esetüket képviselik egy adott továbbfejlesztés vagy új funkció megvitatása során.

Az “Üzlet” teljesen kompatibilis a “Nyílt Forráskóddal”. Az “Üzlet” csak azt jelenti, hogy valahol megjelenik a pénz - az üzleti élet használja a kódot, ami a projekt ismertségével és elfogadottságával egyre valószínűbbé válik. (Bár amikor a nyílt forráskódú szoftvert nem-nyílt forrású termék részeként használják, az egész termék továbbra is “saját tulajdonú” szoftver marad, a nyílt forráskódú szoftverhez hasonlóan, kereskedelmi- vagy nem kereskedelmi célokra is használható.)

Mint bárki más, az üzletileg motivált fejlesztők is a minőségi és mennyiségi hozzájáruláson keresztül érvényesülhetnek a projektben. Nyilvánvaló, hogy egy olyan fejlesztő, aki fizetést kap, többet tud tenni, mint az, aki nem kap érte fizetséget, de ezzel nincs probléma: a fizetés csak egy, a sok lehetséges tényező közül, amely befolyásolhatja, hogy valaki mennyire vesz részt a projektben. A projekt megbeszélések fókuszában a résztvevők álljanak, ne pedig azok a külső tényezők, amelyek azt befolyásolják, hogy valaki milyen közegben járult hozzá a projekthez.

Szükségem van egy jogi személyre a projektem támogatásához?

Hacsak nem kezelsz pénzt, nincs szükséged jogi személyre, hogy támogasd a nyílt forráskódú projektedet.

Ha például vállalkozást akarsz alapozni a projektedre, akkor ennek megfelelő céget kell alapítanod. Ha csak a projektedhez kapcsolódó szerződéses munkát végzel és ezért pénzt kapsz, akkor akár egyéni vállalkozóként, akár Kft-ként működsz, a helyi adó- és jogszabályoknak megfelelő módon kell eljárnod.

Ha adományokat szeretnél kapni a nyílt forráskódú projektedért, elhelyezhetsz egy adomány gombot a weboldalon (PayPal, Stripe, stb. segítségével), de a bevétel kezelésénél ekkor is a helyi adó- és jogszabályoknak megfelelő módon kell eljárnod.

Számos projekt nem vállalja a non-profit szervezet létrehozásával járó bonyodalmakat, ezért olyan támogatókat keresnek akik már non-profit jogi személyek. Ezek a szervezetek a te nevedben fogadhatnak el adományokat, általában némi részesedésért cserébe. A Software Freedom Conservancy, Apache Foundation, Eclipse Foundation, Linux Foundation és Open Collective jó példák az ilyen non-profit támogató szervezetre.

Ha a projekted egy adott programnyelvhez, vagy ökoszisztémához tartozik, akkor ezen területeken kell keresned a non-profit támogatókat. Például, a Python Software Foundation támogatja a PyPI, nevű Python csomagkezelőt, és a Node.js Foundation támogatja az Express.js nevű Node.js alapú webes keretrendszert.