Open Source co bym zmienił, co mnie rozjusza

Mimo, że cały czas korzystam z oprogramowania otwartoźródłego i staram się go ulepszać poprzez zgłaszanie błędów czy tworzenie prymitywnych poprawek, to jest kilka rzeczy które w niektórych projektach mnie denerwują(pewnie można by to powiedzieć o wszystkich projektach, nie tylko open source)

- Nie korzystanie z Clang Format lub podobnych programów do poprawy wyglądu kodu - Wiele projektów nie posiada własnego stylu pisania kodu jakim się powinni deweloperzy kierować np.

if((far/boo)*24)for(;;)wait();

jest dużo trudniej zrozumieć niż

if( ( far / boo) * 24) {
  for(;;) {
    wait();
}

Również część projektów np. Wine mimo, że wymaga stosowania określonego stylu(różnego dla różnego rodzaju plików), to nie udostępnia narzędzi do automatycznego sprawdzania i poprawiania wyglądu kodu.

- Listy mailingowe - przeżytek z czasów kamienia łupanego, używany ciągle przez niewielką ilość projektów. Pewnie w kilku z nich jest ciągle potrzebny z racji wielkości(np. Linux), ale wiele prawdopodobnie obyłoby się bez tego(np. Wine) co przyczyniłoby się do ułatwienia tworzenia poprawek przez nieco mniej zaawansowanych użytkowników.

- Wysoki próg wejścia - Wiele projektów wymaga aby przed zgłoszeniem błędu lub stworzeniem PR, zapoznać się z długą i zawierającą często niezrozumiałe zwroty instrukcją. Przydają się wtedy szablony, które jednak czasami również bywają zbyt wielkie i trudne do zrozumienia.

- Pliki hostowane na innych platformach niż Gitlab, Github czy Gitea - Większość programistów używa w swojej pracy jedynie wcześniej wymienionych serwisów, dlatego użycie innych stron do hostowania kodu wymaga od użytkowników dodatkowej nauki, przez co niektórzy z nich mogą zrezygnować z pomocy rozwoju oprogramowania.

- Osobne strony dla kodu, błędów, dyskusji itp. - Takie serwisy jak Github, Gitlab czy Gitea wspierają zgłaszanie błędów, dlatego(zwykle) nie ma potrzeby tworzyć osobnych serwisów dla każdej z funkcjonalności. Powoduje to dodatkowe problemy z koniecznością tworzenia osobnych kont do każdego serwisu, co jest bardzo denerwujące dla osób wielu osób zwłaszcza tych co chcą jedynie jednorazowo zgłosić błąd czy małą poprawkę

Dobry przykład - Assimp https://github.com/assimp/assimp - wszystko skoncentrowane wokół Githuba

Zły przykład(wiem, że plusem jest scentralizowanie raportów o błędach i konieczność posiadania tylko jednego konta, ale i tak wolałbym aby wszystko było zintegrowane z Gitlabem) https://bugs.kde.org/describecomponents.cgi?product=krita - Błędy https://invent.kde.org/kde/krita - Gitlab - Tylko PR

Bardzo zły przykład - Cppcheck https://github.com/danmar/cppcheck - Tylko PR https://trac.cppcheck.net/ - Zgłoszenia błędów https://sourceforge.net/p/cppcheck/discussion/ - Zgłoszenia błędów i dyskusje

- Nie korzystanie ze statycznej analizy kodu - Wielu błędów można by uniknąć, albo szybciej je znaleźć i naprawić, jeśliby projekty korzystały z statycznej analizy kodu w CI. Wielokrotnie w różnych projektach napotykałem na błędy które jest bardzo łatwo naprawić, ale trudno zauważyć np.

a[0] = 1;
a[1] = 2;
a[1] = 3;
a[3] = 4;

Istnieje szereg darmowych programów typu Cppcheck czy Infer oraz serwisów tj. Sonarcloud czy Coverity Scan, które umożliwiają darmowe wyszukiwanie błędów w kodzie dla projektów otwartoźródłowych.

Przykładowy raport Cppcheck - https://gnome.pages.gitlab.gnome.org/-/gimp/-/jobs/702802/artifacts/report/index.html

- Brak testów jednostkowych i nie używanie Fuzzera - Wiele projektów open source, zwłaszcza tych mniej popularnych, korzysta z bardzo prostych testów lub ich nie ma wcale głównie z powodu zbyt małej ilości czasu/programistów. Już nie raz w wielu projektach open source byłem świadkiem, że nawet z pozoru niegroźnie wyglądające zmiany mogą powodować widoczne od razu lub co gorsza po pewnym czasie błędy. Bardzo często tych błędów można by uniknąć tworząc proste testy jednostkowe. Mimo, że na początku ilość pracy do stworzenia testów lub kodu potrzebnego do fuzzingu jest niewspółmierna do korzyści, to z czasem może się to zmienić ilość testów ręcznych może zostać zmniejszona.

- Brakujące buildy wydań niestabilnych - Bardzo wiele projektów open source zapewnia do pobrania tylko stabilne wersje produktów, podczas gdy wiele osób dla chce sprawdzić jak działa najnowsza wersja programu wraz z poprawkami błędów czy nowymi funkcjami. Według mnie każdy commit oraz PR powinien dostarczać pliki w postaci skompilowanej, tak aby każdy mógł przetestować dane zmiany bez konieczności żmudnej kompilacji. Dodatkowo powinny być dla deweloperów przygotowane specjalne wersje zawierające symbole debugowania oraz wsparcie dla Address i Leak Sanitizers.

Mimo tej listy zmian o które chętnie postuluje, aby poprawić wiele aspektów oprogramowania open source, nie da się zaprzeczyć że zawojowało ono cały świat i jest używane wszędzie i przez wszystkich a wiele projektów z otwartymi źródłami jest wyznacznikami świetnej jakości kodu i nowatorstwa.