To że jeden program wymaga do poprawnego działania innego programu może wydać się niezrozumiałe użytkownikom Domyślnego Systemu Operacyjnego. W artykule postaram się opisać bardzo skrótowo różnicę w powstawaniu wolnego i zamkniętego oprogramowania, która jest główną przyczyną powstania tzw. dependency hell, czyli piekła zależności między linuksowymi aplikacjami.

Programy możemy podzielić na dwie kategorie:

• wolne - z dostępnym ogólnie kodem żródłowym, najczęściej publikowane na licencji GPL i tworzone przez społeczności związane z Wolnym Oprogramowaniem
• zamknięte - czyli te, w których jedynym prawem użytkownika jest uruchomienia programu. I to również nie zawsze.

Proces powstawania obu typów programów jest zasadniczo odmienny i wymaga wyjaśnienia, ponieważ wpływa on w efekcie znacznie na sposób używania oprogramowania obu typów.

Programy z zamknięym kodem

Programy zamknięte powstają najczęściej w firmie programistycznej. Każda funkcjonalność jest pisane od zera. Programy takie stanowią monolit i nie umieją zazwyczaj współpracować z innymi aplikacjami konkurencji. Skutków takiego działania jest wiele. Programy zazwyczaj powstają wolniej, ale są za to bardziej spójne. Ważą też zwykle więcej, ponieważ każdy program musi dostarczać wszystkie niezbędne do jego funkcjonowania biblioteki. W efekcie użytkownik nieświadomie instaluje w systemie kilka silników do odtwarzania muzyki, filmów, wiele dekoderów i innych modułów o powtarzającej się funkcjonalności. System się rozrasta, użytkownik traci kontrolę.

Programy open-source

Tworzenie wolnego oprogramowania wygląda zazwyczaj zgoła inaczej. Grupa programistów pisze program, który dobrze wykonuje jedną zdefiniowaną czynność. Następnie inna grupa programistów, korzystając z nieskrępowanego dostępu do źródeł, pisze swój program, wykorzystując do specyficznych zadań program napisany przez pierwszą grupę. W ten sposób powstają aplikacje składające się z wielu modułów, z których każdy odpowiada za daną funkcjonalność. Większość programów w Linuksie zostało napisane w ten sposób.

Przykłady z życia wzięte:

• K3B i GnomeBaker – popularne aplikacje do nagrywania płyt CD i DVD, które tak naprawdę nie umieją same nagrywać płyt! Obie wykorzystują do tego inne programy, m.in. konsolowe cdrecord i cdrdao. Sam program jest więc tylko graficzną nakładką, interfejsem użytkownika do konsolowych narzędzi wykonujących tę samą czynność
• Mozilla Firefox, Epiphany czy Galleon - przeglądarki internetowe. Tak różne funkcjonalnie, ale do wyświetlania stron używają tego samego silnika: Gecko. Bez niego nie potrafiłyby wyświetlić nawet najprostszej strony WWW!
• Kaffeine i Totem – odtwarzacze multimediów dla konkurencyjnych środowisk KDE i Gnome. Różnią się wyglądem i funkcjonalnością, ale nie silnikiem odtwarzania. Oba mogą wykorzystywać zarówno Xine jak i Gstreamer!

Takich przykładów można by podać jeszcze setki. Praktycznie każdy program dla Linuksa korzysta z innych pomocniczych aplikacji. To właśnie stąd biorą się tzw. zależności – jedna aplikacja wymaga do poprawnego działania innej, ponieważ twórcy skorzystali z jej modułów podczas pisania swojego programu.

Zależności, jak wszystko, mają dobre i złe strony. Głównym plusem takiego podejścia znaczne jest zmniejszenie rozmiaru aplikacji, czyli po prostu oszczędność miejsca na dysku twardym. Minusem jest z kolei większe skomplikowanie systemu oraz możliwe konflikty w przypadku wymagania przez instalowane programy innych wersji zależnych aplikacji od tych dostępnych w systemie. Radą na problemy z zależnościami jest dobry menedżer pakietów, czyli program dbający o to, aby konflikty takie nie występowały.