Разуменне механізмаў кіравання вашым расце праектам

Ваш праект расце, людзі ўцягнутыя ў яго, і вы поўныя рашучасці падтрымліваць яго. На гэтым этапе вы, магчыма, задаецца пытаннем, як уключыць пастаянных удзельнікаў праекта ў свой працоўны працэс, няхай гэта будзе прадастаўленне камусьці доступу да праўкі кода (commit) або мадэрацыю дэбатаў у супольнасці. Калі ў вас ёсць пытанні, у нас ёсць адказы.

Якія прыклады фармальных роляў выкарыстоўваюцца ў праектах з адкрытым зыходным кодам?

Многія праекты маюць падобную структуру размеркавання роляў і прызнання заслуг удзельнікаў.

Аднак што на самай справе азначаюць гэтыя ролі, залежыць толькі ад вас. Вось некалькі тыпаў роляў, якія вы можаце даведацца:

  • Суправаджалы (maintainer)
  • Удзельнік (contributor)
  • Правіцель (committer)

Для некаторых праектаў “суправаджаючыя” - гэта адзіныя людзі ў праекце, якія маюць доступ да праўках (commit). У іншых праектах гэта проста людзі, якія пазначаны ў README як суправаджаюць.

Суправаджалы не абавязкова павінен быць тым, хто піша код для вашага праекта. Гэта можа быць чалавек, які зрабіў вялікую працу па прапагандзе вашага праекта або напісаў дакументацыю, якая зрабіла праект больш даступным для іншых. Незалежна ад таго, чым ён займаецца штодня, суправаджалы-гэта чалавек, які адчувае адказнасць за кірунак развіцця праекта і імкнецца яго палепшыць.

  • Удзельнікам” можа быць любы, хто каментуе праблему (issue) або запыт на перанос (pull request), людзі, якія дадаюць каштоўнасць праекту (няхай гэта будзе ліквідацыю праблем, напісанне кода або арганізацыя мерапрыемстваў), або любы, у каго ёсць прыняты запыт на перанос (магчыма, гэта самае вузкае вызначэнне ўдзельніка).

Тэрмін “Праўнік” можа быць выкарыстаны для таго, каб адрозніць доступ да праўкі, які з’яўляецца асаблівым відам адказнасці, ад іншых формаў ўкладу.

Хоць вы можаце вызначаць ролі ў праекце як заўгодна, разгледзьце магчымасць выкарыстання больш шырокіх азначэнняў, каб натхніць людзей на большую колькасць разнавіднасцяў ўкладу. Вы можаце выкарыстоўваць лідэрскія ролі для афіцыйнага прызнання людзей, якія ўнеслі выдатны ўклад у ваш праект, незалежна ад іх тэхнічных навыкаў.

Як фармалізаваць гэтыя лідэрскія ролі?

Фармалізацыя лідэрскіх роляў дапамагае людзям адчуць сваю датычнасць і падказвае іншым членам супольнасці, да каго звяртацца па дапамогу.

У невялікіх праектах прызначэнне лідэраў можа быць простым - дастаткова дадаць іх імёны ў README або тэкставы файл CONTRIBUTORS.

Для больш буйнога праекта, калі ў вас ёсць вэб-сайт, Стварыце старонку каманды або пералічыце на ёй кіраўнікоў праекта. Напрыклад ,у Postgres ёсць старонка поўнай каманды з кароткімі профілямі для кожнага ўдзельніка.

Калі ваш праект мае вельмі актыўны супольнасць удзельнікаў, вы можаце сфармаваць “ядро” суправаджаюць (maintainers) або нават групы людзей, якія будуць адказваць за розныя вобласці праблем (напрыклад, бяспека, ліквідацыя праблем або паводзіны супольнасці). Дазвольце людзям самаарганізавацца і стаць добраахвотнікамі на тыя ролі, якія ім больш за ўсё падабаюцца, а не прызначайце іх.

Каманды кіраўнікоў могуць захацець стварыць спецыяльны канал (напрыклад, на IRC) або рэгулярна сустракацца для абмеркавання праекта (напрыклад, на Gitter або Google Hangout). Вы нават можаце зрабіць гэтыя сустрэчы публічнымі, каб іншыя людзі маглі паслухаць. Напрыклад, Cucumber-ruby праводзіць офісныя гадзіны кожны тыдзень.

Пасля таго як вы ўсталявалі кіруючыя ролі, не забудзьцеся задакументаваць, як людзі могуць іх атрымаць! Усталюйце выразны працэс таго, як хто-то можа стаць суправаджаюць або далучыцца да групы ў вашым праекце, і запішыце яго ў файле GOVERNANCE.md.

Такія інструменты, як Vossibility, могуць дапамагчы вам Публічна адсочваць, хто ўносіць (ці не ўносіць) ўклад у праект. Дакументаванне гэтай інфармацыі дазваляе пазбегнуць ўспрымання супольнасцю таго, што суправаджаюць - гэта кліку, якая прымае рашэнні ўпотай ад усіх.

Нарэшце, калі ваш праект знаходзіцца на GitHub, падумайце аб пераносе праекта з асабістага акаўнта ў арганізацыю і даданні хоць бы аднаго рэзервовага адміністратара. GitHub Organizations палягчаюць кіраванне дазволамі і некалькімі сховішчамі і абараняюць спадчыну вашага праекта дзякуючы агульнаму валоданню.

Калі я павінен даць каму-то доступ на праўкі (commit)?

Некаторыя людзі лічаць, што вы павінны прадастаўляць доступ на праўкі ўсім, хто ўносіць свой уклад. Гэта можа спрыяць таму, што больш людзей будуць адчуваць сябе датычнымі да вашага праекту.

З іншага боку, асабліва для вялікіх, больш складаных праектаў, вы можаце захацець даць commit доступ толькі тым людзям, якія прадэманстравалі сваю прыхільнасць. Не існуе адзіна правільнага спосабу-рабіце тое, што вам зручней за ўсё!

Калі ваш праект знаходзіцца на GitHub, вы можаце выкарыстоўваць абароненыя галінкі, каб кіраваць тым, хто і пры якіх абставінах можа адпраўляць праўкі (push) у пэўную галінку.

Якія існуюць структуры кіравання для праектаў з адкрытым зыходным кодам?

Існуюць тры агульныя структуры кіравання, звязаныя з праектамі з адкрытым зыходным кодам.

  • BDFL: (Benevolent dictator for life) - “пажыццёвы добразычлівы дыктатар”. Пры такой структуры адзін чалавек (звычайна першапачатковы аўтар праекта) мае права канчатковага голасу пры прыняцці ўсіх асноўных рашэнняў па праекце. Python - класічны прыклад. Невялікія праекты, верагодна, па змаўчанні З’ЯЎЛЯЮЦЦА BDFL, таму што ў іх ёсць толькі адзін ці два суправаджаюць (maintainer). Праект, створаны ў кампаніі, таксама можа трапіць у катэгорыю BDFL.

  • Меритократия: (Заўвага: тэрмін “меритократия” нясе негатыўныя канатацыі для некаторых супольнасцяў і мае складаную сацыяльную і палітычную гісторыю.) пры мерытакратыі актыўным удзельнікам праекта (тым, хто дэманструе “заслугі”) адводзіцца фармальная роля ў прыняцці рашэнняў. Рашэнні звычайна прымаюцца на аснове чыстага кансенсуснага галасавання. Канцэпцыя меритократии была ўпершыню прапанавана Apache Foundation; усе праекты Apache з’яўляюцца мерытакратыямі. Уклад можа быць зроблены толькі людзьмі, якія прадстаўляюць саміх сябе, а не кампанію.

  • Ліберальны ўклад: паводле мадэлі ліберальнага ўкладу, найбольш уплывовымі прызнаюцца людзі, якія робяць больш за ўсё працы, але гэта заснавана на бягучай працы, а не на гістарычным укладзе. Асноўныя рашэнні па праекце прымаюцца на аснове працэсу пошуку кансенсусу (абмеркаванне асноўных прэтэнзій), а не прамога галасавання, і імкнуцца ахапіць як мага больш пунктаў гледжання супольнасці. Папулярныя прыклады праектаў, якія выкарыстоўваюць ліберальную мадэль ўкладу, ўключаюць Node.js і Rust.

Які з іх выкарыстоўваць? Гэта залежыць ад вас! У кожнай мадэлі ёсць свае перавагі і кампрамісы. І хоць спачатку яны могуць здацца зусім рознымі, усе тры мадэлі маюць больш агульнага, чым здаецца. Калі вы зацікаўлены ў прыняцці адной з гэтых мадэляў, азнаёмцеся з гэтымі шаблонамі:

Ці патрэбна мне дакументацыя па кіраванні, калі я запускаю свой праект?

Не існуе падыходнага часу для напісання дакументацыі для вашага праекта, але яго значна лягчэй вызначыць, калі вы ўбачыце дынаміку развіцця вашага супольнасці. Самае лепшае (і самае цяжкае) у кіраванні адкрытым зыходным кодам - гэта тое, што яно фармуецца супольнасцю!

Аднак некаторая ранняя дакументацыя непазбежна будзе спрыяць кіраванню праектам, таму пачынайце запісваць усё, што можна. Напрыклад, вы можаце вызначыць выразныя чакання ў дачыненні да паводзін або таго, як працуе ваш працэс прыцягнення ўдзельнікаў, яшчэ на этапе запуску праекта.

Калі вы з’яўляецеся часткай кампаніі, якая запускае праект з адкрытым зыходным кодам, варта правесці ўнутранае абмеркаванне перад запускам аб тым, як ваша кампанія збіраецца падтрымліваць праект і прымаць рашэнні па яго далейшаму развіццю. Магчыма, вы таксама хочаце Публічна растлумачыць усе асаблівасці таго ,як ваша кампанія будзе (ці не будзе!) удзельнічаць у праекце.

Што рабіць, калі супрацоўнікі карпарацыі ўдзельнічаюць у праекце?

Паспяховыя праекты з адкрытым зыходным кодам выкарыстоўваюцца многімі людзьмі і кампаніямі, і некаторыя кампаніі ў канчатковым выніку могуць мець патокі даходаў, звязаныя з праектам. Напрыклад, кампанія можа выкарыстоўваць код праекта ў якасці аднаго з кампанентаў камерцыйнага прапановы паслуг.

Па меры таго як праект атрымлівае ўсё больш шырокае распаўсюджванне, людзі, якія валодаюць вопытам у гэтай галіне, становяцца больш запатрабаванымі-вы можаце быць адным з іх! - і часам будуць атрымліваць грошы за працу, якую яны выконваюць у праекце.

Важна ставіцца да камерцыйнай дзейнасці як да нормы і як да яшчэ адной крыніцы энергіі для развіцця. Вядома, платныя распрацоўшчыкі не павінны атрымліваць асаблівае стаўленне да сябе ў параўнанні з бясплатнымі; кожны ўклад павінен ацэньвацца па яго тэхнічных вартасцяў. Аднак людзі павінны адчуваць сябе камфортна, займаючыся камерцыйнай дзейнасцю, і не саромецца прыводзіць свае прыклады выкарыстання, аргументуючы сваю пазіцыю на карысць таго ці іншага ўдасканалення або функцыі.

“Камерцыйнае” цалкам сумяшчальна з “адкрытым зыходным кодам”. “Камерцыйны” азначае толькі тое, што дзесьці ўцягнутыя грошы-што праграмнае забеспячэнне выкарыстоўваецца ў камерцыі, што становіцца ўсё больш верагодным па меры таго, як праект атрымлівае распаўсюд. (Калі праграмнае забеспячэнне з адкрытым зыходным кодам выкарыстоўваецца як частка прадукту без адкрытага зыходнага кода, агульны прадукт усё роўна з’яўляецца” прапрыетарным “ праграмным забеспячэннем, хоць, як і адкрыты зыходны код, ён можа выкарыстоўвацца ў камерцыйных або некамерцыйных мэтах).

Як і любы іншы чалавек, камерцыйна матываваныя распрацоўшчыкі набываюць уплыў у праекце за кошт якасці і колькасці свайго ўкладу. Відавочна, што распрацоўшчык, якому плацяць за яго час, можа зрабіць больш, чым той, каму не плацяць, але гэта нармальна: аплата - гэта толькі адзін з многіх магчымых фактараў, якія могуць паўплываць на тое, як шмат хто-то робіць. Абмяркоўваючы праект, Засяродзьцеся на ўкладзе, а не на знешніх фактарах, якія дазваляюць людзям рабіць гэты ўклад.

Ці трэба мне юрыдычная асоба для падтрымкі майго праекта?

Вам не трэба юрыдычная асоба для падтрымкі вашага праекта з адкрытым зыходным кодам, калі толькі вы не працуеце з грашыма.

Напрыклад, калі вы хочаце стварыць камерцыйны бізнес, вам трэба будзе заснаваць C Corp або LLC (калі вы знаходзіцеся ў ЗША). Калі вы проста выконваеце кантрактную працу, звязаную з вашым праектам з адкрытым зыходным кодам, вы можаце прымаць грошы як індывідуальны прадпрымальнік або заснаваць LLC (калі вы знаходзіцеся ў ЗША).

Калі вы хочаце прымаць ахвяраванні для вашага праекта з адкрытым зыходным кодам, вы можаце ўсталяваць кнопку для ахвяраванняў (напрыклад, з дапамогай PayPal або Stripe), але грошы не будуць падлягаць падаткаабкладанню, калі вы не з’яўляецеся кваліфікаванай некамерцыйнай арганізацыяй (501c3, калі вы знаходзіцеся ў ЗША).

Многія праекты не хочуць займацца стварэннем некамерцыйнай арганізацыі, таму замест гэтага яны знаходзяць фіскальнага спонсара некамерцыйнай арганізацыі. Фіскальны спонсар прымае ахвяраванні ад вашага імя, звычайна ў абмен на працэнт ад ахвяраванні. Software Freedom Conservancy, Apache Foundation, Eclipse Foundation, Linux Foundation і Open Collective з’яўляюцца прыкладамі арганізацый, якія выступаюць у якасці фіскальных спонсараў праектаў з адкрытым зыходным кодам.

Калі ваш праект цесна звязаны з пэўнай мовай або экасістэмай, можа існаваць і адпаведны фонд праграмнага забеспячэння, з якім вы можаце працаваць. Напрыклад, Python Software Foundation дапамагае падтрымліваць PyPI, менеджэр пакетаў Python, а Node.JS Foundation дапамагае падтрымліваць Express.js, фреймворк на аснове Node.