Jak się dowiedzieć, czy projekt Open Source jest wystarczająco dojrzały, aby go użyć w produkcie?

Istnieje kilka projektów typu open source, które chciałbym włączyć do produktu w pracy. Nie mamy przepustowości ani wiedzy merytorycznej, aby zrobić to sami. Znalazłem je, wyszukując w Google. Nie znam żadnych „głównych graczy”, którzy wykorzystują projekty, ale jestem bardzo zachęcony tym, co widzę.

Teraz jestem trochę zaniepokojony ryzykiem, na jakie jestem narażony, korzystając z projektu open source Joe-Blow. Jeśli zajmie mi to 95% drogi, być może pozostałe 5% można łatwo dodać lub naprawić. Być może jest to nietrywialne.

Jak ludzie decydują o tym, czy projekt typu open source jest wystarczająco dojrzały, aby go użyć w produkcie?

To nie jest projekt hobbystyczny, więc stabilność, łatwość konserwacji itp. Są najważniejsze.

Kryteria, które stosuję, pod warunkiem, że projekt spełnia moje wymagania:

1. Czy istnieje aktywna społeczność, w której ludzie mogą udzielać pomocy?
2. Czy licencja jest odpowiednia do mojego rozwoju?
3. Czy produkt jest ciągle w fazie rozwoju?
4. Czy to powszechnie używany framework?
5. Czy mogę znaleźć jakieś recenzje / posty na blogu / etc produktu i jak ludzie się z nim zintegrowali?

4 i 5 tak naprawdę nie pomagają w niszowych projektach, które brzmią jak twoje.

Najważniejszą rzeczą jest to, czy spełnia twoje wymagania? Jeśli czujesz, że tak się dzieje, następną rzeczą jest zrobienie uprzęży do przetestowania projektu i sprawdzenie, czy możesz zrobić to, co chcesz. Daje to wyczucie interfejsu API (jeśli jest biblioteką) i sposobu działania.

Na koniec, jeśli istnieje coś open source, które robi 90% tego, co robisz, rozwidlaj je, dodaj dodatkową funkcjonalność i zwróć społeczności. Robiłem to wcześniej w projektach komercyjnych.

1. W przypadku frameworku generalnie używam tylko dużego i dojrzałego frameworka z dużą ilością wstępnie napisanych modułów i dużej społeczności. Ogólnie rzecz biorąc, wybranie jednego frameworka w stosunku do drugiego tak naprawdę nie zmniejszyłoby dużo pracy, którą musisz poświęcić na własny kod, niektóre frameworki mogą zachęcać do piękniejszego kodu, inne mogą ułatwić pewne operacje, ale ogólnie rzecz biorąc mała różnica w stosunku do całkowitego wysiłku rozwojowego. Jednak popularne frameworki miałyby więcej wstępnie napisanych modułów, które można wykorzystać i w ten sposób zwykle można zaoszczędzić znacznie więcej czasu i wysiłku.
2. W przypadku małej biblioteki innej niż frameworku, ogólnie możesz samodzielnie wprowadzić modyfikacje, jeśli zajdzie taka potrzeba, bez większego problemu, więc zwykle uważam społeczność za dodatkowy bonus. Większość małych bibliotek jest zarządzana tylko przez jedną osobę, ale nadal są lepsze niż budowanie siebie. Jednak w przypadku dużych bibliotek posiadanie dojrzałej, aktywnej społeczności i dokumentacji jest niezbędne, ponieważ prawdopodobnie nie będziesz w stanie samodzielnie wprowadzić zmian.
3. Licencja jest niezbędna. W przypadku bibliotek jednoosobowych prawdopodobne jest, że będziesz musiał wprowadzić zmiany w bibliotece, dlatego ważne jest, aby ich licencja na to pozwalała na warunkach, z którymi się zgadzasz.

W przypadku małych bibliotek należy zawsze zakładać, że konieczne będzie rozwidlenie i że projekt jest już porzucony. Zwykle nie stanowi to problemu, szczególnie jeśli projekt jest hostowany na Github lub BitBucket, ponieważ sprawiają, że rozwiązywanie projektów innych ludzi jest głupio łatwe. W przypadku małych bibliotek zawsze możesz samodzielnie przejąć utrzymanie projektu, jeśli oryginalny opiekun zniknie lub jeśli planują obrać kierunek projektu w miejsca, do których nie chcesz iść.

Nie interesuję się aktywnością projektu, dojrzała biblioteka, która osiągnęła poczucie „doskonałości”, zwykle musiałaby tylko naprawiać błędy, więc ich aktywność spowolniła. Aktywność projektu jest ważna tylko wtedy, gdy biblioteka obejmuje cel, który aktywnie się rozwija, na przykład opakowanie usługi zewnętrznej musiałoby być stale aktualizowane w miarę ewolucji usługi zewnętrznej, więc aktywny rozwój jest niezbędny, ale biblioteka matematyczna nie potrzebowałaby wiele nowy program, gdy będzie miał wszystkie potrzebne funkcje.

W przypadku większych bibliotek sprawy stają się trudniejsze. Przejęcie jest znacznie bardziej zaangażowane, na szczęście większe biblioteki zwykle nie poruszają się tak szybko, ponieważ są na ogół bardziej dojrzałe.

Jak powiedział @Sam w swojej odpowiedzi, zgadzam się, że najważniejszą rzeczą w ocenie biblioteki open source jest to, jak bardzo pasuje ona do twoich wymagań. Po rozwiązaniu problemu z licencją rzadko korzysta się z biblioteki typu open source, ponieważ zawsze można rozwidlić, jeśli wszystko pójdzie na południe.

Sprawdź w narzędziu do śledzenia błędów projektu. Jeśli widzisz wiele zgłoszeń złożonych przez wiele różnych osób, a także odpowiedzi pochodzące od różnych osób, to dobry znak. Więcej zgłoszeń błędów == większa społeczność użytkowników == istnieje większe prawdopodobieństwo, że będziesz gotowy do użytku produkcyjnego.

Wiadomość nie jest dobra, ale to nie znaczy, że jest niepoprawna: nie wiesz.

Gdyby w produkcji były analogiczne implementacje, wiedziałbyś, że jest to wykonalne, ale jak powiedziałeś, żaden z głównych graczy nie korzysta z projektów.

Gdybyś rozwijał się w domu, to byś wiedział, ale jak powiedziałeś, nie masz zasobów.

Rozsądnie jest chcieć wiedzieć, ale ... nie wiesz.

Mam nadzieję, że ta odpowiedź pomoże, ponieważ powinieneś mieć plany awaryjne wyciągnięcia wtyczki z dowolnej technologii, na której polegasz, ale której nie kontrolujesz ... a wiedza, że ​​nie wiesz, czy jest niezawodna, jest krokiem w tym kierunku.

Pytanie należy ująć inaczej. To, o co tak naprawdę pytasz, to skorzystanie z tego projektu typu open source, najlepszym sposobem na rozwój produktu?

To koniecznie obejmuje nie tylko omawiany projekt open source, ale także inne opcje. Jeśli jedyną inną opcją jest pisanie wszystkiego samemu, to lepiej korzystać z projektu, jeśli rozumiesz, że jest to wystarczający kod, aby go zmodyfikować.

Oczywiście powstaje drugie pytanie, czy Twój projekt jest w ogóle opłacalny. Tj. Musisz oszacować wysiłek, w tym wszelkie ryzyko związane z koniecznością naprawy lub uzupełnienia funkcjonalności, którą, jak masz nadzieję, zapewnia kod typu open source. Jeśli projekt nie jest powszechnie używany, będziesz musiał przejrzeć kod w tym celu.