Programujem od univerzity. Takmer všetok kód bol verejný: kontribúcie do upstream open source komunít, kde je práca viditeľná, spätná väzba reálna a používatelia sú často cudzinci z celého sveta, ktorých kód závisí na tom vašom.
Niekde po ceste som si však začal všímať niečo nepríjemné. Open source závisí od dvoch skupín ľudí: kontribútorov, ktorí kód píšu, a maintainerov, ktorí ho musia schváliť, mergnúť a udržiavať celý projekt konzistentný. Existovali bounty platformy, kde firmy alebo jednotlivci mohli stanoviť odmeny na GitHub issues. Odmena vždy patrila kontribútorovi. Maintainer, ktorý musel prečítať každý riadok, otestovať ho, zvážiť okrajové prípady a nakoniec prevziať zodpovednosť za merge? Nedostal nič.
Prežité z oboch strán
Bol som Project Team Lead pre upstream projekty OpenStack Quality Assurance. Moja každodenná realita bol Gerrit: čítanie patchov, reviews, kladenie otázok, čakanie na nové verzie patchsetov a potom celé znova. Dobrá review si vyžaduje skutočné úsilie. Musíte pochopiť zmenu, pochopiť kontext, zachytiť problémy, ktoré kontribútor možno nevidí, a napísať spätnú väzbu, ktorá je užitočná, nie odrádzajúca.
A potom je tu samotný merge. Vo veľkom projekte so stovkami používateľov a desiatkami CI jobov bežiacich proti každému commitu mergnutie zlého kódu rozbije veci pre všetkých. Táto zodpovednosť zostane s vami. Kontribútor ide ďalej, maintainer nesie zodpovednosť.
Nebol to jeden konkrétny moment, ktorý ma priviedol k myšlienke, že niečo nie je v poriadku. Bolo to pomalé hromadenie rovnakej frustrácie, na oboch stranách. Ako PTL som mal obdobia, keď som review-oval rovnaký patch tri alebo štyrikrát, pretože kontribútor sa stále vracal s malými úpravami a zakaždým som musel znova načítať celý kontext, aby som dal zmysluplnú review. Toto úsilie nie je viditeľné v git logu. Commit message zaznamenáva, kto napísal kód. Nezaznamenáva, kto strávil popoludnie tým, aby sa uistil, že je bezpečné ho mergnuť.
Ale strávil som aj roky na druhej strane, ako inžinier, ktorý písal patche a čakal na review. Viem, aké to je, keď niečo zverejníte a potom čakáte. Niekedy aj týždne. Kontext vybledne. Presuniete sa k iným taskom. Keď review konečne príde, vrátiť sa do myšlienkového rámca toho patchu si vyžaduje čas s ktorým ste nepočítali. Omeškanie nespomalí len tento jeden príspevok. Postupne oslabuje vašu motiváciu prispievať ďalej.
Nikto nie je na vine. Open source práca jednoducho nie je odmeňovaná spôsobom, ktorý by uľahčoval rýchlu reakciu. Ľudia sú zaneprázdnení. Reviews sa dejú, keď sa dejú. To však problém nerobí menej reálnym ani menej hodným riešenia.
Medzera, ktorú nikto nevypĺňal
Bounty platformy neboli nové, keď som o tom začal premýšľať. Ale každá, na ktorú som sa pozrel, mala rovnaký dizajn: niekto zverejní odmenu na GitHub issue, kontribútor to vyrieši, kontribútor dostane zaplatené. Koniec.
Tento model zaobchádza s mergnutým PR, akoby prispievateľ bol jediná osoba, ktorá to umožnila. Nie je. Maintainer, ktorý patch pozorne prečítal, dal spätnú väzbu, čakal na úpravy a nakoniec prevzal zodpovednosť za jeho zaradenie do codebase, tiež odviedol skutočnú prácu. Neodmenenú prácu, v každom modeli, ktorý som našiel.
To sa zdalo nespravodlivé. Nie len principiálne, ale aj z pohľadu niekoho, kto strávil roky robením tejto práce a sledovaním, ako ju robia iní.
Delenie 80/20
Model, s ktorým som začal, bolo rozdeliť odmenu 80/20. 80 % by šlo kontribútorovi, ktorý kód implementoval a 20 % maintainerovi, ktorý ju skontroloval a mergol. Paretov princíp sa objavuje všade a myslím, že tu funguje tiež.
Delenie by bolo nastavené tak, aby motivovalo obe strany. Kontribútori dostávajú väčší podiel, pretože nesú implementačné úsilie. Maintaineri dostávajú zmysluplný podiel, pretože ich práca je nevyhnutná a momentálne neviditeľná. Osemdesiat percent je dosť na to, aby stálo za to issue riešiť. Dvadsať percent je dosť na to, aby stálo za to recenziu uprednostniť.
Keď som bol v maintainer roli, jeden z najfrustrujúcejších zážitkov bolo dať niekomu review a potom čakať týždne na reakciu. Medzitým som samozrejme zabudol polovicu kontextu a musel som všetko znova prečítať od začiatku. Keď som bol zase v roli kontribútora, ekvivalentná frustrácia pramenila rovnako z dlhého čakania na review. Oba problémy majú rovnaký menovateľ: žiadna silná motivácia reagovať. Preto je navrhnuté delenie odmeny.
Prečo časové limity majú zmysel
Každá odmena na OtterSource má dátum expirácie. Ak je firma alebo jednotlivec ochotný dať peniaze na GitHub issue, je to preto, lebo to potrebujú vyriešiť v rozumnom čase. Majú produkt, ktorý treba odovzdať, alebo blocker, ktorý treba odblokovať.
Časový limit to robí explicitným. Každý si ho je vedomý. Kontribútori vedia, kedy odmena vyprší. Maintaineri vedia, do kedy musia kód skontrolovat a mergnúť. Osoba, ktorá zverejnila odmenu, vie, na čo sa zaväzuje. Transparentne, jasne a plánovateľne.
Kde sa model skomplikoval
Budovanie platobnej architektúry odhalilo ťažší problém, ako som čakal. Presúvanie peňazí medzi financovateľmi, kontribútormi a maintainermi zaraďuje marketplace do inej regulačnej kategórie ako SaaS produkt: licencovanie platobných inštitúcií podľa PSD2 v EÚ, DAC7 reportovanie príjmov pre európskych prispievateľov, pravidlá e-money pri ponuke kreditov a ekonomika poplatkov, ktorá sa rozpadá pri malých odmenách, keď sa zarátajú skutočné náklady na platobnú infraštruktúru.
Žiadna z týchto výziev samo o sebe nie je smrteľná. Spolu opisujú iný produkt, ako som navrhol, alebo oveľa väčší biznis, taký, ktorý potrebuje vážny kapitál a licencovací priestor, než môže vôbec držať prostriedky pre tretie strany. Práve prehodnocujem mechanizmus. Problém a princíp sa nezmenili: open source práca musí platiť ľuďom, ktorí ju skutočne robia, kontribútorom aj maintainerom. Už stačí len vyriešiť ako presne sa budú pohybovať peniaze tak, aby to bolo v súlade so zákonom a reguláciami.
Čo je OtterSource
OtterSource je marketplace, kde ktokoľvek (jednotlivec, tím, firma) môže zverejniť časovo obmedzenú odmenu na ľubovoľnú verejnú GitHub issue. Keď je issue vyriešená a PR mergnutý, kontribútor aj maintainer dostanú zaplatené. Presný model sa stále je TBA, ale princíp je pevný: osoba, ktorá napísala kód, a osoba, ktorá sa uistila, že je bezpečné ho mergnúť, si obe zaslúžia uznanie.
Prečo OtterSource? Názov sa riadi rovnakou logikou ako pri mojom druhom projekte, OtterSay: slovná hračka na "open source". Navyše vydry sú obľúbeným zvieraťom mojej partnerky a s touto slovnou hračkou bolo ľahšie nájsť voľnú .com doménu.
Na čom to stojí
V momente písania tohto článku, je OtterSource v ranom vývoji. Myšlienka ma sprevádza dlho, implementácia to teraz len doháňa. Ak využívate na open source, ako vývojár, maintainer alebo firma s open source vo svojom stacku, navštívte ottersource.com.
Aktualizácia, máj 2026: Platobná architektúra a obchodný model sa prehodnocujú. OtterSource je stále live na ottersource.com a môžete sa prihlásiť na odber noviniek. Smer sa zmenil. Poslanie nie.