Tym, co tak naprawdę jako pierwsze pojawia się w modelu open source, jest kwestia łańcucha dostaw.

Gdy taki temat zostanie zapisany jako „zapieczętowany”, uwaga zostanie zwrócona na zbyt dramatyczny obraz. Częściej spotykane zmiany w projekcie są mniej dramatyczne: publiczne źródło pobierania staje się niestabilne, zaczynają pojawiać się witryny lustrzane, określona wersja jest usuwana z półek, rytm ciągłych aktualizacji zostaje przerwany, a łańcuch rozumowania w rękach zespołu nagle musi się utrzymać.

Warstwa hostująca najpierw przejmuje presję

Im częściej omawia się model open source, tym łatwiej jest wyraźnie dostrzec jedną rzecz: polityka, kontrola eksportu i zasady platformy często mogą bezpośrednio dotyczyć nie rozpowszechnianych dokumentów ważonych, ale hostingu publicznego, wnioskowania online, dystrybucji wersji i domyślnych wejść.

Oznacza to, że chociaż wydaje się, że jest „zapieczętowana”, ścieżka, która w rzeczywistości jest odcięta, jest często najłatwiejszą ścieżką. To, co kiedyś było prostym procesem pobrania adresu URL, skonfigurowania interfejsu hostingowego i jednorazowego wywołania, nagle zmieniło się w znalezienie obrazu, dodanie podpisu, sprawdzenie skrótu, sprawdzenie licencji i potwierdzenie wersji wycofanej. Działania mogą wydawać się niewielkie, ale po połączeniu tworzą kompletny łańcuch dostaw.

Po rozwidleniu wersji nazwa nie wyjaśnia już problemu.

Najtrudniejszą częścią modelu open source nigdy nie jest pytanie „czy taki istnieje”. Gdy ciężar rozłoży się na wiele obrazów, wiele magazynów organizacyjnych i wiele gałęzi dostrajania, pod tą samą nazwą będą pojawiać się różne zachowania.

W tym momencie nie wystarczy już dyskusja o tym, „czy model jeszcze istnieje”. Bardziej kłopotliwe pytanie brzmi: która z nich jest główną linią, która jest tylko lustrzanym odbiciem, która została dwukrotnie przeszkolona, ​​a która nadal zachowuje pierwotne zachowanie rozumowania. Nazwa może nadal wskazywać na ten sam projekt, ale wyniki zaczęły się różnić. W tym momencie, jeśli zespół nadal uważa „to samo imię” za „tą samą rzecz”, wyniki online prędzej czy później będą się różnić.

Jest to również największa różnica między modelami open source a interfejsami API o zamkniętym kodzie źródłowym. Zamknięty interfejs API źródła jest odłączony, a działanie jest bardzo proste; model open source jest podzielony i na pozór usługa nadal działa, ale za kulisami zmieniono wersję, zależności i granice zachowania. To, co naprawdę niepokoi, często nie jest porażką, ale „wydaje się, że to wciąż działa”.

To, co naprawdę wymaga naprawy, to źródło, wycofywanie i powtarzanie w trybie offline.

Kiedy w projekcie dochodzi do tego rodzaju zmian, pierwszą rzeczą, którą należy nadrobić, nie są emocje, ale trzy rzeczy: źródło, wycofanie i powtarzanie offline.

Źródło musi być identyfikowalne i powiązane z konkretnymi magazynami, konkretnymi zgłoszeniami i dokumentami dotyczącymi określonej wagi. Wycofanie musi umożliwiać powrót do poprzedniej wersji zachowania, a nie tylko nazwy. Odtwarzanie w trybie offline musi umożliwiać ponowne przeprowadzenie tej samej serii eksperymentów, gdy w sieci występują drgania, kopia lustrzana zostanie utracona lub pakiet nadrzędny zostanie usunięty.

Wiele zespołów zwykle uważa, że ​​te rzeczy są od nich odległe. Dopiero pewnego dnia aktualizacja poprzedzająca zmienia styl wyjściowy lub synchronizacja niektórych obrazów jest powolna i odkrywają, że problem nie leży w możliwościach modelu, ale w łańcuchu zależności, który nie jest zarządzany jak obywatel pierwszej klasy. Im bardziej otwarty jest model, tym bardziej jest to oczywiste. Ponieważ to, co przynosi open source, to nie zawsze stabilne „darmowe wejście”, ale coraz dłuższy łańcuch dostaw.

Najbardziej fizyczną częścią zwykle nie jest ciało modelu.

Jeśli chodzi o środowisko produkcyjne, najbardziej prawdopodobnym miejscem, w którym można popełnić błąd, nie jest zazwyczaj ontologia wag, ale domyślny wpis, automatyczne aktualizacje i ukryte zależności.

Jeśli zespół uważa określony portal internetowy za jedyne źródło, może jeszcze dziś zadzwonić do niego, ale jutro może być konieczne tymczasowe znalezienie zastępstwa; jeśli uzna stację lustrzaną za domyślną, zmiana wersji po cichu wkradnie się do szkolenia i oceny; jeśli rytm aktualizacji jest zbyt napięty, dzisiejsza stabilność zachowania nie jest jasna i jutrzejsza nowa wersja będzie dostępna online.

Zatem tego rodzaju problem przypomina politykę międzynarodową, ale jeśli chodzi o inżynierię, bardziej przypomina zarządzanie łańcuchem dostaw. Kto kontroluje wpis, kto jest odpowiedzialny za podpisanie, kto definiuje wycofanie, kto zapisuje starą wersję i kto może odbudować w trybie offline – oto granice, które nadal będą miały wpływ na dostarczanie. Po upublicznieniu samego modelu przestrzeń pozostawiona na działania zewnętrzne zmniejszy się; przestrzeń pozostawiona zespołowi na samodzielne odrabianie lekcji powiększy się.

To, czy model open source będzie „zapieczętowany”, jest dość wąskim pytaniem. Bardziej realistyczna ocena jest taka: im bardziej otwarte jest źródło, tym trudniej jest je zatrzymać jednym działaniem; ale im bardziej jest to oprogramowanie typu open source, tym więcej potrzebuje zarządzania wersjami, źródłami, wycofywaniem i powtarzaniem w trybie offline. Jeżeli ten łańcuch dostaw nie zostanie zamknięty, wszelkie wahania zewnętrzne przekształcą się w wypadek, który będzie wyglądał jak „wypadek modelowy”.