Na jakim etapie projektu Open Source powinieneś zapraszać społeczność? [Zamknięte]

Zastanawiam się, czy nie mogę uzyskać wkładu w nowy produkt typu open source, który mój zespół będzie rozwijał. Zachęcamy nas do uzyskania jak największej pomocy ze strony szerszej społeczności, jak to możliwe, ale widzę też, że pochłania to dużo czasu, upewniając się, że firmy zewnętrzne zlokalizowane poza naszym biurem są na dobrej drodze, jeśli chodzi o jakość kodu. Również na początku projektu prawdopodobnie przeprowadzimy wiele nieformalnych dyskusji w zespole głównym na temat projektu systemu, skoków itp., A włączenie ich do sieci w celu umożliwienia zaangażowania społeczności będzie czasochłonne i mogę sobie wyobrazić, że dyskusja mniej skuteczna.

Jest w tym bardziej ludzka strona, którą prawdopodobnie należy wziąć pod uwagę: umożliwienie udziału społeczności w procesie projektowania może mieć również zalety w zakresie postrzeganej własności projektu, i zawsze istnieje szansa, że ​​wczesne zaangażowanie może wykryć problemy, które są podstawą zespół nie zauważył.

Pytanie: na jakim etapie projektu Open Source powinieneś zapraszać społeczność?

Już na samym początku! Chcesz, aby społeczność poczuła, że ​​ma prawdziwy udział w twoim projekcie, w przeciwnym razie poczuje się, jakby była wykorzystywana jako bezpłatna siła robocza.

Cała komunikacja powinna odbywać się za pośrednictwem publicznej listy mailingowej lub forum, co ponownie wzmacnia ideę społeczności.

Możesz złagodzić problem „projektu przez komisję”, przedstawiając jasną wizję w pierwszych postach na liście mailingowej, np

„Patrzymy na model domeny reprezentujący nasz sklep zoologiczny (zgodnie z JIRA-4). Czy ktoś widzi jakieś poważne problemy z tym modelem?”

Jeśli chodzi o akceptowanie rzeczywistych wkładów fizycznych, powinieneś zacząć od akceptowania poprawek i przeprowadzania na nich recenzji kodu publicznego. W ten sposób autorzy mogą już publicznie zobaczyć, jakiego rodzaju standardów kodowania muszą przestrzegać. Upewnij się, że twoje zatwierdzenia są również dostępne na liście mailingowej zatwierdzeń - musisz przestrzegać tych samych standardów!

Opłaca się także mieć standardy projektu na Wiki lub jakimś takim dokumencie.

Przeczytaj http://www.producingoss.org, aby uzyskać więcej informacji na temat prowadzenia udanego projektu open source.

Zostało to szczegółowo omówione w Google Talk IO Myth of genialnego programisty , autorstwa Briana Fitzpatricka i Bena Collinsa-Sussmana z Subversion. Krótko mówiąc, doszli do wniosku, że nie powinno być tak wcześnie, aby jeszcze nic nie było (tj. „Przyjrzyj się mojemu niesamowitemu projektowi! Naprawdę niewiele tu jeszcze jest, ale planuje się wiele niesamowitych rzeczy!”) Lub zbyt późno więc wszystkie decyzje zostały już podjęte (ciężko jest wyrazić opinię na temat solowego projektu).

I zgadzam się z Martijn Verburg . Powinieneś zacząć zabiegać o składki od samego początku. Pisałem już o tym trochę wcześniej.

Podsumowaniem tego postu jest to, że oprogramowanie gnije. Jeśli chcesz zachować świeżość, musisz przeprowadzić konserwację. Im bardziej popularny jest projekt, tym więcej błędów można znaleźć, tym więcej funkcji zostanie dodanych, a tym bardziej to zadanie związane z konserwacją może Cię zapaść.

W rzeczywistości jest to bardzo częsty problem. Jest świetna rozmowa Fat'a pod tytułem „ Co to jest Open Source i dlaczego czuję się tak winna”? W tym przemówieniu (które gorąco polecam do obejrzenia) opowiada historię jednego ze swoich projektów OSS i tego, jak z czasem spędził większość swojego wolnego czasu na segregowaniu biletów i zadaniach związanych z zarządzaniem. I mówi o tym, jak szkodliwe to było. Z czym mogę całkowicie się wczuć.

Rozwiązaniem jest oczywiście wczesne i częste dodawanie ludzi do projektu. Twój czas jest ograniczony i cenny. Zainwestuj w rozbudowę bazy współpracowników, a reszta twoich problemów zacznie same się zajmować.

Jak mówię na końcu mojego postu: „Co jest ważniejsze dla twojego projektu: funkcje czy przyszłość? Wybierz jeden i odpowiednio ustal priorytety swoich wysiłków”.