Nagrody za kod źródłowy

Mam bibliotekę dla R (pakiet statystyk open source) zmapowaną na papierze. Zacząłem kodować różne funkcje, ale zdaję sobie sprawę, że nie mam czasu potrzebnego na ukończenie tego w rozsądnym czasie. Wiem, że mogę po prostu rzucić kod na repo i wezwać innych do wypełnienia pustych miejsc. Ale chciałbym trochę zachęcić. Zastanawiam się nad przyznaniem nagrody za każdą funkcję, powiedzmy, 5–20 USD. Nie ma mowy, aby 20 USD zapewniło programistom odpowiedni zwrot na czas dla każdej funkcji. Ale uważam, że gotówka (lub bony upominkowe Amazon) byłyby pomysłem dla ludzi, którzy faktycznie pracowaliby nad projektem. Pozwoliłoby mi to zdobyć wyższe nagrody za funkcje, które najbardziej mnie interesują.

Mam kilka pytań z tym związanych:

1. Dobry pomysł?
2. Mam zamiar przyspieszyć lub przyspieszyć programowanie? Przeczytałem Przewidywalnie nieracjonalny i martwię się, że oferując wynagrodzenie za funkcje, faktycznie mogę zniechęcić programistów.
3. Czy są witryny poświęcone tego rodzaju działalności? Czy możesz polecić na podstawie osobistych doświadczeń?
4. Czy poleciłbyś zupełnie inne podejście? Jestem otwarty na pomysły!

Moim zdaniem nie jest to dobry pomysł. Żaden programista OSS, którego znam, nie zareagowałby na taką nagrodę.

Co zatem motywuje ludzi? Według Dan Pink ludzie są motywowani przez:

• Autonomia
• Mistrzostwo
• Cel, powód

Następnie, aby przyciągnąć dobrych programistów, znajdź sposób na dostarczenie niektórych lub wszystkich tych elementów.

Drugim podejściem, które można zastosować jednocześnie z pierwszym, jest wyświetlenie strony głównej, która śledzi postęp projektu, pokazując status każdej z funkcji wraz z osobą, która udostępniła funkcję, która jako pierwsza przeszła testy jednostkowe (robisz to mieć testy, prawda?).

Wreszcie, z mojego doświadczenia wynika, że ​​przekonujący projekt nie potrzebuje dużej pomocy w przyciąganiu współpracowników. Spójrz na to, co robisz, a jeśli masz trudności z przyciągnięciem i utrzymaniem programistów do pracy nad tym, pomyśl o tym, co mówi ci o przydatności twojego projektu.

https://www.bountysource.com

Ze strony o:

BountySource został pierwotnie stworzony w 2004 roku z nadzieją na zwiększenie i poprawę rozwoju społeczności oprogramowania typu open source. Pierwsza iteracja BountySource dostarczyła różnorodne narzędzia, które pozwoliły na łatwe zarządzanie projektami typu open source. Niektóre z tych narzędzi obejmowały moduł do śledzenia zadań, repozytorium kodów SVN i system zarządzania treścią.

BountySource wyprzedził swój czas ... chcielibyśmy myśleć o nim jak o poprzedniku GitHub.

Po długiej przerwie wróciliśmy z tą samą wizją - ogólną poprawą w zakresie rozwoju oprogramowania typu open source - ale z zupełnie innym systemem.

Przenosimy naszą uwagę z hostingu projektów - repozytoriów, śledzenia problemów i wszystkich - na aspekt finansowania społecznościowego oryginalnego pomysłu BountySource.

Pamiętam, że widziałem kilka witryn w dniach com, które były dokładnie takie, jak to opisujesz. Ludzie umieszczali małe zadania kodowania, które chcieli wykonać, za pewną kwotę, a ludzie mogli się zarejestrować, aby wykonać to zadanie - były pewne odmiany tego tematu, ale to był podstawowy pomysł. Będąc świeżo po szkole i szukając dodatkowej moolah, często grzebałem wokoło i szukałem dobrego do zrobienia. Wynik? Nigdy nie zrobiłem ani jednego. Niezmiennie patrzyłem na zadania (które mogłem wykonać) i robiłem sobie w głowie stosunek ceny do wydajności i zdałem sobie sprawę, że to naprawdę nie było warte mojego czasu, aby się tym przejmować (dokładnie to, co robisz w punkcie 2). Innym problemem było to, że prawie wszystkie z nich nie były nieodpartymi problemami - był powód, dla którego je hodowano :)

Zgadzam się z KevDogiem, że jeśli masz fajny projekt i przyzwoity PR (zdobywając słowo), ludzie cię znajdą i wykonają pracę za darmo. Chociaż nigdy nie poszedłem drogą najemników, z pewnością przyczyniłem się tu i tam do projektów OSS, które budzą moją wyobraźnię.

Nie sądzę, że pomysł jest całkowicie poza zasięgiem możliwości, jednak paradygmat kosztu zadania nie działa, ponieważ nie jest opłacalny dla programisty ani proporcjonalnie skalowalny.

Myślę, że lepszym systemem może być $ / Line Of Code, w którym wspomniany loc znajduje się w kontroli wersji przez x czasu i nie jest popełniany z powodu niekompetencji (np. Błędu).