Ukrywać czy ujawniać?

Nie wiem skąd wzięło się przekonanie, że udostępnienie kodu źródłowego oprogramowania ma wpływ na polepszenie jego jakości. Powiedziałbym raczej, że jawność w tym zakresie może poprawić jedynie relacje zaufania pomiędzy wytwórcami oprogramowania a jego użytkownikami i to nierzadko na zasadzie psychicznego komfortu wynikającego z potencjalnych możliwości wglądu do źródeł.

Nie wiem skąd wzięło się przekonanie, że udostępnienie kodu źródłowego oprogramowania ma wpływ na polepszenie jego jakości. Powiedziałbym raczej, że jawność w tym zakresie może poprawić jedynie relacje zaufania pomiędzy wytwórcami oprogramowania a jego użytkownikami i to nierzadko na zasadzie psychicznego komfortu wynikającego z potencjalnych możliwości wglądu do źródeł.

Bo tak naprawdę trzeba niezłego samozaparcia i niezwykle giętkiego umysłu, aby analizować (a nie daj Boże cokolwiek modyfikować) w produkcie obcego autorstwa.

Wielu ludzi szermujących błogosławieństwem jawności kodu źródłowego jest przekonanych o jego wyższości nad kodem ukrytym, tylko dlatego, że tak głoszą obiegowe opinie. Ogromna większość popleczników jawności nie zhańbiła się nigdy analizą jakiegokolwiek fragmentu oprogramowania, a ci, którzy coś w tej mierze uczynili, ograniczali się zazwyczaj do przeglądania prostych procedur w językach skryptowych.

Kod programu nie jest treścią książki, gdzie każdy z nas może wkleić do tekstu skomponowany przez siebie fragment i nie zaburzy to logiki dzieła w sposób uniemożliwiający korzystanie z niego. Osoby nieparające się programowaniem i niewyznające się na tej dziedzinie mają zdaje się takie mniemanie w tej mierze, które twórczość programistyczną czynią technicznie pokrewną z działalnością literacką. Jest to o tyle tylko poprawne myślenie, że w jednym i drugim przypadku trzeba mieć koncepcję, a także tu i tam korzysta się z edytorów, aczkolwiek zupełnie odmiennych.

Wszelkie układy przetwarzania informacji, analogowe czy dyskretne, sprzętowe czy software'owe, stosowane w różnych dziedzinach, zawsze były i są "czarnymi skrzynkami", gdzie wartości wejściowe powodują pojawienie się określonych wartości wyjściowych. Nikt jednak nie rości sobie pretensji do rozhermetyzowania tych układów, aby wgląd do nich i możliwość zmiany zasad działania miał każdy tylko dlatego, że tak chce. Spróbujmy zmienić własnym sumptem zasady pracy chociażby programatora pralki lub komputera w samochodzie. Ciekawe, co z tego wyjdzie. A może by tak opowiadać się również za "otwartością" wszelkich układów elektronicznych? Wszak one także są elementami przetwarzania o różnym poziomie złożenia i nigdy do końca nie wiadomo jaki diabeł tam siedzi.

Istniejący kod programowy zawsze da się wzbogacić o własne biblioteki, które następnie można przekazać do powszechnego użytku. Nie wymaga to jednak wglądu do istniejącego już oprogramowania, a jedynie znajomości jego parametrów pozwalających na integrację. Gdyby każdy programista chciał analizować "od podszewki" to, co już stworzyli poprzednicy, przypuszczam, że nadal tkwilibyśmy w erze kalkulatorów zamiast w rozwiniętym do obecnej postaci systemie informacji cyfrowej.

Dwa razy konieczność zawodowa zmusiła mnie do ingerencji w cudze kody o objętości kilkudziesięciu tysięcy linii. Raz nawet musiałem gruntownie takie oprogramowanie przerabiać. Kto czegoś takiego w życiu nie wykonywał, nie powinien głosić tez o wyższości kodu otwartego. Fakt, że w przypadku jawności istnieje możliwość kontroli oraz ingerencji, ale ile wysiłku to kosztuje, ten tylko wie, kto to czynił. Co innego usprawnić niedużą procedurę o klarownej strukturze i przeznaczeniu, a co innego "mieszać" w złożonych regułach algorytmicznych. Ja w każdym razie definitywnie zamknąłem już ten rozdział działalności zawodowej. Wolę budować przyszłość na istniejących cegiełkach, ufając ich producentom.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200