Jak zrujnować projekt open source. Poznaj kilka powodów

Jak zrujnować projekt open source. Poznaj kilka powodów

    przez -
    10 2088
    Open Source
    Istnieje kilka powodów aby zniszczyć projekt open source. Brandon Keepers, który przewodzi przedsięwzięciom open source na GitHub-ie przedstawił w swojej prezentacji mnóstwo sposobów na to co może pójść źle, gdy użytkownicy lub opiekunowie projektów podejmują niewłaściwe kroki. W trakcie trwania “O’Reilly Open Source Convention (OSCON)” w Portland w stanie Oregon, Keepers podał listę czynności, które są wykonywane by w rezultacie zrujnować projekt open source.

    Czytając prezentacje Pana Keepers’a jestem pod wrażeniem ilości czynności, które mogą się przyczynić do klapy projektu. Czasem są to błahe działania, które na pierwszy rzut oka mogą sprawiać wrażenie całkowicie nieszkodliwych. Zaskoczyła mnie najbardziej kwestia zadawania leniwych nic nie wnoszących pytań, aż jest dziwne, że użytkownicy danego projektu zamiast przeczytać dokumentacje ( o ile taka się znajduje razem z projektem) zadają pytanie “Jak ten projekt ma działać?”. Rozumiem sytuacje, gdy z winy projektanta takiej dokumentacji nie ma, ale gdy jest to się robi już troszkę zabawne. Również dziwnym pytaniem jest: “Jak to ma działać w technologii na przykład Java”, skoro programista specjalizuje się w języku np. Python, to może być mu trudno odpowiedzieć na to pytanie.

    Innym problemem są również użytkownicy danego projektu. Widząc błąd w kodzie nie informują o tym autora projektu, licząc na to, że ktoś inny zwróci na to uwagę. Innym powodem mogą być współpracownicy, którzy pracują przy tworzeniu oraz utrzymaniu danego projektu “przy życiu”. Problem z komunikacją pomiędzy współpracownikami oraz nie trzymanie się harmonogramu prac, sprawia, że praca nad projektem to istna męka i najczęściej jest tak, że jest on po prostu porzucany.

    Większość kategorii, w których rujnuje się projekt jest podobnych do kiepskich wydarzeń. Jednym z nich jest wspomniany już powyżej brak informacji dotyczącej projektu. Te “cięcia papieru” to takie małe przestępstwa, mimo których projekt może być nadal rozwijany. Ale z czasem ten brak wymiany informacji niszczy otoczenie projektu, a tym bardziej chęci głównego projektanta do dalszej współpracy nad projektem.

    • ewq

      Gdyby napisać ten artykuł po polsku to mógłby on być ciekawy.

    • kamyk

      Google translator zrobił ostatnio ogromne postępy. Podpisuje się nawet prawdziwym imieniem i nazwiskiem, żeby lepiej udawać człowieka.

    • Ollbi

      Przepraszamy za drobne błędy, które pojawiły się w tekście. Prosimy także o wyrozumiałość dla naszej Nowej Redaktor portalu. W następnych newsach nie będzie już chochlików :-)

      • Tomek

        Błędy zawsze jakieś będą. Nowej Pani Redaktor życzę wytrwałości w doskonaleniu warsztatu pisarskiego i dalszego podejmowania ciekawych tematów!

      • Agata Bublewicz

        Dziękuje :)

    • Roman

      Najłatwiej rozwalić projekt podając autorom masę świetnych pomysłów. Po czymś takim, większość niedoświadczonych twórców zje prokrastynacja. Stosuję to od dawna do zwalczania konkurencji.

      • o_O

        >do zwalczania konkurencji.
        Żałosne.

    • helloworld

      No niestety, developerzy z braku ruchu robią się już nie tylko wyglądem ale również mentalnie babami. Żali się jak baba. Kuźwa każdy rozgarnięty wie że jak chce sie zrobić mocną, dużą aplikację to metro/drewno/gastroseksualny sam już nie da rady. Potzrebna jest wpółpraca. Nadymanie się bo zostało się obrażonym w swojej piaskownicy już nie działa. Ludzie z open source muszą o tym wiedzieć. To już nie są programiki, które ogarnia jeden człowiek.

    • gosc

      Często problemem jest nie tyle brak, co nadmiar dokumentacji. I nigdy nie wiesz co jest aktualne i stosowane a co nie. Właściwie to ten problem mają chyba wszystkie projekty Open Source, którym nie napisano scentralizowanego helpa. Ale scentralizowany help nie zawsze się opłaca (patrz np. języki programowania lub biblioteki).

      • Roman

        Może nie chodzi o nadmiar, co o redagowanie dobrej dokumentacji. Nie wystarczy spisać funkcje. Trzeba to zrobić w sposób atrakcyjny i zrozumiały.