Ładnie rozwidlać projekt open source

Już czas.

Pracowałeś długo i ciężko, aby dodać swoją wizję do projektu open source, który kochasz, nad którym pracowałeś, debatowałeś i do którego wniósłeś nieocenioną ilość kodu i wiedzy.

Ale to nie zadziała z istniejącymi programistami.

W końcu musisz rozwidlić kod.

Jak to zrobić i zachować jak najlepsze warunki w ramach istniejącego projektu? Jak można nie powiedzieć, „ Oh Yeah? Fork ty! ”

Oprócz mechaniki polaryzacji krzyżowej i zakładania, że ​​uzasadnienie rozwidlania jest rozsądne, logiczne i dopuszczalne, jakie pojawiają się problemy?

Zawody? Zasób zasobów? Kłusownictwo użytkowników?

Jak przechodzisz przez ten prawdopodobnie trudny i długi proces, dopóki nie zdywersyfikujesz się na tyle, aby nie były już postrzegane jako problemy?

Zamiast omawiać uzasadnienie tej decyzji, proszę założyć, że już jesteś przekonany, że rozwidlenie kodu jest najlepszym ogólnym rozwiązaniem, a teraz chodzi o to, aby iść naprzód w najlepszy możliwy możliwy sposób.

-Adam

Chcesz pracować nad własnym rozwidleniem kodu, czy chcesz rozdrobnić społeczność?

Rozwinęliśmy wewnętrznie kilka projektów. Dokonamy zmiany, wyślemy to do właścicieli, powiedzą „nie, dziękuję”, wzruszymy ramionami, przyniesiemy ją wewnętrznie i sami ją utrzymamy.

Nie były to ogromne projekty, ale tak właśnie jest. Nie opublikowaliśmy niczego, nie prowadziliśmy witryny ani nic takiego. Po prostu przekazujemy źródło do naszych klientów wraz z resztą bazy kodu.

Po prostu nie było żadnego wezwania do „promowania” naszych zmian w sposób bardziej publiczny niż lista dyskusyjna deweloperów.

Jeśli chcesz zachować równość z oryginałem, będziesz musiał być agresywny w zarządzaniu łatkami, łączeniu i cokolwiek innego.

Jeśli nie chcesz zawracać sobie głowy, to ... nie rób tego. Nie ma powodu upubliczniać tego, chyba że jest to ogólna intencja, zamiast po prostu potrzebować rozwidlonej wersji do własnych projektów.

Można użyć źródła, więc skorzystaj z niego.

W większości projektów o otwartym kodzie źródłowym słowo „widelec” nie jest często tak ciepło postrzegane. Osobiście skorzystałem z tego, że proszenie o pracę nad „gałęzią tematów” w celu opracowania określonego zestawu funkcji jest o wiele bardziej mile widziane.

Ma to tylko sens: „widelce” są z natury potencjalnymi konkurentami, podczas gdy „gałęzie tematyczne” są - przynajmniej według projektu - przeznaczone do ostatecznego połączenia / wniesienia z powrotem do projektu.

Najpierw powiedz, że chcesz po prostu przeprowadzić eksperymentalne refaktoryzowanie. Wiesz, tylko kilka pomysłów, z którymi chcesz się bawić. Ale zmiany te mogą wymagać zerwania wstecznej kompatybilności z główną gałęzią projektu, więc nie chcesz tam zatwierdzać zmian.

Następnie utwórz widelec. Oczywiście jesteś odpowiedzialnym programistą, więc cały kod poddajesz kontroli wersji. Użyj Launchpad lub SourceForge lub Google Code lub cokolwiek innego.

Połóż się na chwilę i po prostu popracuj nad tym sam. Następnie poproś kogoś, komu ufasz, aby „spojrzał” na to, co stworzyłeś. Potem jeszcze ktoś. Jakiś czas później stwórz prostą stronę internetową projektu, gdziekolwiek trzymasz swoje źródło.

Do tego czasu ludzie, o których myślałeś, że nie pracują nad oryginalnym projektem, prawdopodobnie już przeszli, więc nie będzie nikogo, kto mógłby się obrazić. Aktywność oryginalnego projektu spadnie, gdy nowy projekt zyska obserwujących.

Komentarz Re codelogic:

Dobrze; Zakładałem, że ludzie, których OP chce zostawić, nie są w stanie samodzielnie utrzymać projektu.

Słyszałem, że „organizacje przetrwają, ludzie nie”. Oznacza to, że żadna osoba nie jest tak krytyczna dla projektu, że pozostały zespół nie jest w stanie zrekompensować próżni pozostawionej przez odejście tej osoby.

Jednak w otwartym oprogramowaniu czasami jest prawdą, że nikt nie ma woli, talentu i czasu na prowadzenie projektu bez założyciela.