🚀 go-pugleaf

> 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