Jarmark.org

Przeglądam zaległe RSSy i trafiłem na grudniowego (sic!) newsa o wypuszczeniu stabilnej wersji 2.0 Railsów. Prześliznąłem się okiem po liście ficzerów, a ponieważ wyżywałem się już na niej napiszę o pewnym bardziej ogólnym spostrzeżeniu które przyszło mi do głowy…

Kilka lat temu gdy otwarte oprogramowanie prowadziło nieśmiałą wojnę podjazdową z rozwiązaniami komercyjnymi jednym z haseł na sztandarach było uwolnienie od przywiązania do dostawcy (vendor lock-in). Hasło jak najbardziej słuszne, wszak wolność wyboru rozwiązania i sposobu jego rozwoju może wyjść rozwiązaniu tylko na dobre. Dziś gdy kurz bitewny opadł, a wolne oprogramowanie zagnieździło się już na dobre, mam wrażenie, że popadliśmy w inną patologię - nazwałem ją roboczo version lock-in.
Oto jej praktyczna manifestacja, wyobraźmy sobie, że tworzymy nowy killer-app. Stopień komplikacji dzisiejszych aplikacji wymaga skorzystania z przynajmniej kilku zewnętrznych bibliotek/modułów. Wybieramy oczywiście otwarte biblioteki w ich najnowszych wersjach kierując się zerowym kosztem, liberalną licencją oraz dostępem do kodu źródłowego. Stopniowo rozwijamy naszą aplikację dodając coraz to nowe możliwości. Na początku śledzimy zmiany wprowadzane przez twórców bibliotek z których korzystamy adaptując nasz killer-app do wprowadzonych zmian. Prędzej lub później dochodzimy jednak do momentu w którym dostosowywanie naszego kodu do wymagań rozwijającego się kodu bibliotek albo nie ma sensu (biblioteka rozwija się w niekorzystną dla nas stronę) albo są wręcz niemożliwe. Gorzej jeszcze gdy posługując się otwartym kodem bibliotek wprowadziliśmy w nich własne zmiany, specyficzne dla tworzonej aplikacji - sprawa wówczas zaczyna przypominać szukanie rozwiązania układu równań ze zbyt wielką liczbą niewiadomych…

Gdy jeszcze do tego biblioteki z których korzystamy są szczególnie popularne - nooo to jesteśmy w poważnych tarapatach. Większa popularność to przecież większa presja na autorów o nowe funkcje w krótszym czasie, a to zwykle odbywa się kosztem jakości. ‘Możesz zostać committerem’ powie ktoś z boku - to prawda… ale tylko częściowo, bo w ilu projektach na raz możemy uczestniczyć rozwijając jednocześnie własny killer-app? Ilu osobom będą przydatne nasze specyficzne zmiany w bibliotekach? W końcu dochodzimy do miejsca gdy dopada nas version lock-in i bardziej lub mniej świadomie oddajemy pola rezygnując z ciągłej pogoni za korzystaniem z najnowszej wersji zostajemy przy już zaadoptowanej wersji akceptując jej braki i przyszłą archaiczność, godząc się z własną porażką :)

Czy to źle? Moim zdaniem NIE. Wybierając rozwiązania dla własnej aplikacji warto po prostu pamiętać, że version lock-in jest to jedna z realnych cech otwartego oprogramowania.

Bardzo możliwe, że nasza aplikacja wraz z rozwojem popadnie w version lock-in, nie jest to jednak (zwykle) istotna wada z punktu widzenia tworzonej aplikacji - raczej cecha rzeczywistości :) Wsteczna zgodność, testy regresyjne, polityka migracji to wszystko są znane rozwiązania na opisaną tu przypadłość kłopot tylko w tym, że bieg ku nowemu-lepszemu jest bardziej atrakcyjny dla twórców opensource niż żmudne oglądanie się do tyłu - zwłaszcza gdy nikt za to nie płaci… Jak więc widać tytułowa mądrość Miltona Friedmana działa także w świecie oprogramowania.

PS: tak na marginesie szacowanie kosztu oprogramowania z uwzględnieniem tylko kosztu zakupu/pozyskania to niestety nadal bardzo często popełniany błąd.