> Kod źródłowy sam w sobie faktycznie może mało kogo interesować w czasach
> pokoju - ale fakt jego publicznej obecności oraz możliwość dokonania w
> nim zmian są, dla wielu firm, niezwykle istotne.

Sam tak kiedyś myślałem. I nadal tak uważam w odniesieniu do bibliotek - powinny być
rozprowadzane z kodem.
Natomiast w przypadku pełnych programów (Word, Excel, ...) lub nawet w przypadku
platform sam dostrzegłem, że tego oczekiwania nie przestrzegam. Co więcej, nie
przestrzegam go również w przypadku platform deweloperskich. I to nie tylko tych,
które instaluję na komputerze, ale również tych, których tylko używam (powiedzmy, że
w chmurze, chociaż nie lubię tego określenia).
W tej kategorii mamy w zasadzie wszystko od Windowsa, przez iOS/Android, po
przykładowo AWS, Azure, czy co tam kto lubi i jest teraz modne.

> Optując za rozwiązaniem zamkniętym (niezależnie od tego czy jest płatne
> czy nie), stajemy się zależni od producenta.

Dlatego warto uzależniać się od tych, którzy już udowodnili swoją długofalową chęć
istnienia.

> Jeśli ten za pół roku
> splajtuje

Właśnie po to mu płacimy, żeby nie splajtował.
Zauważ, że w ostatnim czasie o "plajtach" (czy ogólnie: o zakończeniu działalności)
słyszeliśmy w odniesieniu do mniej lub bardziej darmowych serwisów. Właściwie co
chwilę coś się zamyka.

> Nasz projekt umiera

Dlaczego? Dlaczego mój projekt w (przykładowo) Pythonie ma umrzeć tylko dlatego, że
się jego twórcy rozeszli? Mój projekt żyje sobie dalej. Tak samo jak dalej żyją sobie
projekty np. w COBOLu.

Taką natychmiastową tragedią jest natomiast wyłączenie serwisu w chmurze - ale
właśnie dlatego w tej dziedzinie warto (o ile w ogóle warto) wiązać się z tymi,
którzy udowodnili długofalowe działanie. I z tymi, którym płacimy pieniędzmi a nie
jakimś bardziej ulotnym walorem w stylu informacji o swoich gustach.

> Przy rozwiązaniu OSS natomiast możemy w sytuacji kryzysowej zacisnąć
> zęby, zajrzeć w kod i naprawić to, co przestało działać.

A dlaczego coś miało przestać działać skoro działało? Programy w COBOLu cały czas
działają.

> Do tego nie
> zostajemy z problemem sami: inni prawdopodobnie też nadziali się na ten
> sam problem co my i istnieje niezerowa możliwość połączenia sił.

Możliwość jest dokładnie zerowa. Przy dzisiejszej dynamice i dostępności alternatyw
wszyscy rozejdą się każdy w inną stronę, pierwszego dnia. I jeszcze się pokłócą o to,
która alternatywa była lepsza.

Generalnie, retoryka OSS jest mi dobrze znana. Z obu stron:
1. co złego się może stać gdy nie będę używał OSS
2. co dobrego zyskam gdy będę używał OSS

Problem w tym, że o ile 1. jest realny i czasami faktycznie się dzieje, to 2. się nie
dzieje. To jest teoria, która się w sensownej globalnie skali nie dzieje.

Przykład: AdaCore jest producentem kompilatora GNAT (do Ady). To jest OSS. Niestety
nie ma nikogo, kto podjąłby temat dalszego rozwoju tego kompilatora i jeśli AdaCore
się zwinie, to zwinie się cały ekosystem.
Dlatego nie martwi mnie, że Wolfram nie jest OSS. Bo w przypadku fakapu na jedno
wyjdzie. A w praktyce jestem nawet gotów obstawiać, że Wolfram przetrwa dłużej.

--
Maciej Sobczak * http://www.inspirel.com