Înțelegerea guvernării pentru proiectul tău în creștere

Proiectul tău este în creștere, oamenii sunt angajați, și ești angajat să ții acest lucru tot așa. În această etapă, s-ar putea să te întrebi cum să încorporezi contributori obișnuiți ai proiectului în fluxul tău de lucru, fie că este vorba de a da cuiva permisiunea de a face commit-uri sau rezolvarea dezbaterilor comunității. Dacă tu ai întrebări, noi avem răspunsuri.

Care sunt exemplele de roluri formale utilizate în proiecte cu sursă deschisă?

Multe proiecte urmează o structură similară pentru rolurile și recunoașterea contributorilor.

Ce aceste roluri înseamnă de fapt, totuși, depinde doar de tine. Iată câteva tipuri de roluri pe care le-ai putea recunoaște:

  • Întreținător
  • Contributor
  • Committer

Pentru unele proiecte, „întreținătorii” sunt singurele persoane din proiect cu acces de commit. În alte proiecte, ei sunt pur și simplu oamenii care sunt listați în README ca întreținători.

Un întreținător nu trebuie să fie neapărat cineva care scrie cod pentru proiectul tău. Poate fi cineva care a făcut multă muncă promovându-ți proiectul, sau a scris documentație care a făcut proiectul mai accesibil altora. Indiferent de ce face zi de zi, un întreținător este probabil cineva care simte responsabilitate asupra direcției proiectului și este angajat la îmbunătățirea lui.

Un „contributor” ar putea fi oricine care comentează la o problemă sau la o cerere de pull, oameni care adaugă valoare proiectului (fie că este trierea de probleme, scrierea de cod, sau organizarea de evenimente), sau oricine cu o cerere de pull îmbinată (poate cea mai restrânsă definiție a unui contributor).

Termenul „committer” poate fi folosit pentru a distinge accesul la commit, care este un tip specific de responsabilitate, de alte forme de contribuție.

În timp ce poți defini rolurile proiectului tău în orice fel îți place, consideră folosirea de definiții mai largi pentru a încuraja mai multe forme de contribuție. Poți folosi roluri de conducere pentru a recunoaște în mod oficial pe oamenii care au făcut contribuții remarcabile la proiectul tău, indiferent de abilitățile lor tehnice.

Cum formalizez aceste roluri de conducere?

Formalizarea rolurilor de conducere ajută oamenii să se simtă proprietari și spune celorlalți membri ai comunității pe cine să caute pentru ajutor.

Pentru un proiect mai mic, desemnarea liderilor poate fi atât de simplă ca adăugarea numelor lor la fișierul tău text README sau CONTRIBUTORS.

Pentru un proiect mai mare, dacă ai un site web, creează o pagină a echipei sau listează liderii proiectului tău acolo. De exemplu, Postgres are o pagină cuprinzătoare a echipei cu profiluri scurte pentru fiecare contributor.

Dacă proiectul tău are o comunitate de contributori foarte activă, ai putea să formezi o „echipă de bază” a întreținătorilor, sau chiar subcomitete ale oamenilor care preiau conducerea unor domenii de probleme diferite (de exemplu, securitate, trierea problemelor, sau conduita comunității). Lasă oamenii să se autoorganizeze și să aplice pentru voluntariat în rolurile de care sunt cei mai încântați, în loc să li le atribui.

Echipele de conducere ar putea dori să creeze un canal desemnat (cum ar fi pe IRC) sau să se întâlnească periodic să discute despre proiect (cum ar fi pe Gitter sau Google Hangouts). Poți chiar face aceste întâlniri publice astfel încât alți oameni pot asculta. Cucumber-ruby, de exemplu, găzduiește ore de lucru săptămânal.

Odată ce ai stabilit roluri de conducere, nu uita să documentezi modul în care oamenii pot să le atingă! Stabilește un proces clar pentru cum cineva poate deveni un întreținător sau să se alăture unui subcomitet în cadrul proiectului tău, și scrie aceasta în GOVERNANCE.md-ul tău.

Unelte cum ar fi Vossibility pot să te ajute să urmărești în mod public cine face (sau nu) contribuții la proiect. Documentarea acestor informații evită percepția comunității că întreținătorii sunt o clică ce își ia deciziile în privat.

În cele din urmă, dacă proiectul tău este pe GitHub, consideră mutarea proiectului tău din contul personal într-o organizație și adăugarea a cel puțin unui administrator de rezervă. Organizațiile GitHub ușurează gestionarea permisiunilor și multiplelor depozite și protejează moștenirea proiectului tău prin proprietate comună.

Când ar trebui să dau cuiva acces de commit?

Unii oameni gândesc că ar trebui să dea acces de commit la oricine face o contribuție. Făcând astfel ar putea încuraja mai mulți oameni să se simtă proprietari asupra proiectului tău.

Pe de altă parte, în special pentru proiectele mai mari, mai complexe, ai putea vrea să dai acces de commit doar oamenilor care și-au demonstrat angajamentul. Nu există o singură cale corectă de a face aceasta - fă ce te face cel mai confortabil!

Dacă proiectul tău este pe GitHub, poți folosi ramuri protejate pentru a gestiona cine poate face push spre o anumită ramură, și în care circumstanțe.

Care sunt unele dintre structurile obișnuite de guvernanță pentru proiectele cu sursă deschisă?

Există trei structuri obișnuite de guvernanță asociate cu proiectele cu sursă deschisă.

  • BDFL: BDFL înseamnă “Benevolent Dictator for Life” (Dictator binevoitor pentru viață). În cadrul acestei structuri, o persoană (de obicei autorul inițial al proiectului) are ultimul cuvânt asupra tuturor deciziilor majore legate de proiect. Python este un exemplu clasic. Proiectele mai mici sunt probabil BDFL în mod implicit, deoarece există doar unul sau doi întreținători. Un proiect care își are originea la o companie ar putea de asemenea intra în categoria BDFL.

  • Meritocrația: (Notă: termenul „meritocrație” are conotații negative pentru unele comunități și are o istorie socială și politică complexă.) În cadrul unei meritocrații, contributorii activi ai proiectului (aceia care demonstrează „merit”) primesc un rol oficial de luare a deciziilor. Deciziile sunt de obicei luate bazat pe consens pur votat. Conceptul de meritocrație o are ca pionieră pe Fundația Apache; toate proiectele Apache sunt meritocrații. Contribuțiile pot fi făcute doar de indivizi care se reprezintă pe sine, nu printr-o companie.

  • Contribuție liberală: În cadrul unui model de contribuție liberală, oamenii care fac cea mai multă muncă sunt recunoscuți ca cei mai influenți, dar aceasta se bazează pe munca din prezent și nu pe contribuții istorice. Deciziile majore legate de proiect sunt făcute pe baza unui proces de căutare de consens (discută plângerile majore) în loc de votare pură, și se străduiesc să includă cât mai multe perspective posibil din comunitate. Exemple populare de proiecte care folosesc un model de contribuție liberală includ Node.js și Rust.

Pe care dintre ele ar trebui să o folosești? Depinde de tine! Fiecare model are avantaje și compromisuri. Și chiar dacă ele ar putea să-ți pară destul de diferite la început, toate cele trei modele au mai mult în comun decât pare. Dacă ești interesat în a adopta una dintre aceste modele, aruncă o privire la aceste șabloane:

Am nevoie de documente de guvernare atunci când lansez proiectul meu?

Nu există moment potrivit să notezi guvernarea proiectului tău, dar este mult mai ușor să o definești odată ce ai văzut acea dinamică a comunitații jucând. Cea mai bună (și cea mai grea) parte despre guvernarea open source este faptul că este modelată de comunitate!

Totuși unele documente inițiale vor contribui la guvernarea proiectului tău în mod inevitabil, deci începe să notezi ce poți. De exemplu, poți defini așteptări clare privind comportamentul, sau cum funcționează procesul tău de contribuire, chiar la lansarea proiectului tău.

Dacă ești parte dintr-o companie care lansează un proiect cu sursă deschisă, merită să aveți o discuție internă înainte de lansare despre cum compania voastră se așteaptă să mențină și să facă decizii cu privire la proiectul care merge înainte. Poate ați dori de asemenea să explicați în mod public oricare detaliu cu privire la cum compania va fi (sau nu va fi!) implicată în proiect.

Ce se întâmplă dacă angajați din companii încep să trimită contribuții?

Proiectele open source de succes sunt folosite de mulți oameni și companii, și unele companii pot avea în cele din urmă fluxuri de venit eventual legate de proiect. De exemplu, o companie ar putea folosi codul proiectului ca o componentă într-o ofertă de serviciu comercial.

Pe măsură ce proiectul este utilizat pe scară mai largă, oamenii care au experiență în acest domeniu devin mai solicitați - tu ai putea fi unul dintre ei! - și câteodată vor fi plătiți pentru munca pe care o fac în cadrul proiectului.

Este important să tratezi activitatea comercială ca normală și exact ca pe o altă sursă de energie de dezvoltare. Dezvoltatorii plătiți nu ar trebui să primească tratament special în comparație cu cei neplătiți, de sigur; fiecare contribuție trebuie să fie evaluată pe baza meritelor ei tehnice. Totuși, oamenii ar trebui să se simtă confortabil cu angajarea în activitate comercială, și să se simtă confortabil când își afirmă cazurile de utilizare când argumentează în favoarea unei anumite îmbunătățiri sau facilități.

„Comercial” este complet compatibil cu „sursă deschisă”. „Comercial” doar înseamna că acolo undeva sunt bani implicați - că softul este folosit în comerț, ceea ce este din ce în ce mai probabil pe măsură ce un proiect devine mai adoptat. (Când un soft cu sursă deschisă este folosit ca parte dintr-un produs cu sursă nedeschisă, produsul în ansamblu este încă soft „proprietar”, totuși, la fel ca sursa deschisă, el poate fi folosit pentru scopuri comerciale sau necomerciale.)

La fel ca oricine altcineva, dezvoltatorii motivați comercial câștigă influență în proiect prin calitatea și cantitatea contribuțiilor lor. În mod evident, un dezvoltator care este plătit pentru timpul său ar putea să facă mai mult decât cineva care nu este plătit, dar asta este OK: plata este doar unul dintre posibilii factori care ar putea afecta cât face cineva. Păstrează-ți discuțiile de proiect concentrate pe contribuții, nu pe factorii externi care dau posibilitatea oamenilor să facă aceste contribuții.

Am nevoie de o entitate juridică pentru a-mi susține proiectul?

Nu ai nevoie de o entitate juridică pentru a-ți susține proiectul cu sursă deschisă decât dacă lucrezi cu bani.

De exemplu, dacă dorești să creezi o afacere comercială, vei dori să înființezi un C Corp sau LLC (dacă ești stabilit în SUA). Dacă faci doar muncă cu contract legată de proiectul tău cu sursă deschisă, poți accepta bani ca unic proprietar, sau să înființezi un LLC (dacă ești stabilit în SUA).

Dacă vrei să accepți donații pentru proiectul tău cu sursă deschisă, poți crea un buton de donație (folosind PayPal sau Stripe, de exemplu), dar banii nu vor fi deductibili fiscal decât dacă ești o organizație nonprofit calificată (un 501c3, dacă ești în SUA).

Multe proiecte nu doresc să treacă prin dificultățile de înființare a unei organizații nonprofit, deci ele găsesc în schimb un sponsor fiscal nonprofit. Un sponsor fiscal acceptă donații în numele tău, de obicei în schimbul unui procent din donație. Software Freedom Conservancy, Apache Foundation, Eclipse Foundation, Linux Foundation și Open Collective sunt exemple de organizații care servesc drept sponsori fiscali pentru proiecte cu sursă deschisă.

Dacă proiectul tău este strâns legat de un anumit limbaj sau ecosistem, ar putea de asemenea exista o fundație software cu care poți lucra. De exemplu, Python Software Foundation ajută la sprijinirea PyPI, gestionarul de pachete Python, și Node.js Foundation ajută la sprijinirea Express.js, un cadru de lucru bazat pe Node.