Yang pertama memasuki model open source adalah masalah rantai pasokan.

Begitu topik tersebut ditulis sebagai “tersegel”, perhatian akan tertuju pada gambaran yang terlalu dramatis. Perubahan yang lebih umum dalam proyek ini kurang dramatis: sumber unduhan publik menjadi tidak stabil, situs mirror mulai bermunculan, versi tertentu dihapus dari rak, ritme pembaruan terus-menerus terganggu, dan rantai penalaran di tangan tim tiba-tiba harus berpegang pada dirinya sendiri.

Lapisan hosting mengambil tekanan terlebih dahulu

Semakin banyak model open source dibahas, semakin mudah untuk melihat satu hal dengan jelas: apa yang dapat secara langsung dipengaruhi oleh kebijakan, kontrol ekspor, dan aturan platform sering kali bukan dokumen berbobot yang telah didistribusikan, namun hosting publik, inferensi online, distribusi versi, dan pintu masuk default.

Artinya meski terasa “tersegel”, namun jalur yang justru terputus seringkali merupakan jalur yang paling mudah. Apa yang dulunya merupakan proses sederhana untuk mengambil URL, menyiapkan antarmuka hosting, dan memanggilnya tiba-tiba berubah menjadi menemukan gambar, menambahkan tanda tangan, memeriksa hash, memeriksa lisensi, dan mengonfirmasi versi rollback. Tindakan-tindakan tersebut mungkin tampak kecil, namun ketika dihubungkan, tindakan-tindakan tersebut membentuk rantai pasokan yang lengkap.

Setelah versinya di-fork, namanya tidak lagi menjelaskan masalahnya.

Bagian tersulit dari model open source bukanlah “apakah ada”. Setelah bobot menyebar ke beberapa gambar, beberapa gudang organisasi, dan beberapa cabang penyesuaian, perilaku berbeda akan tumbuh dengan nama yang sama.

Saat ini tidak cukup lagi membicarakan “apakah modelnya masih ada”. Pertanyaan yang lebih menyusahkan adalah: mana jalur utama, mana yang hanya bayangan cermin, mana yang sudah dilatih dua kali, dan mana yang masih mempertahankan perilaku penalaran aslinya. Namanya mungkin masih menunjuk pada proyek yang sama, tetapi keluarannya sudah mulai berbeda. Pada titik ini, jika tim masih menganggap “nama yang sama” sebagai “hal yang sama”, cepat atau lambat hasil online akan menyimpang.

Ini juga merupakan perbedaan terbesar antara model sumber terbuka dan API sumber tertutup. API sumber tertutup terputus, dan kinerjanya sangat mudah; model open source terbagi dua, dan di permukaan layanan masih berjalan, namun di balik layar versi, dependensi, dan batasan perilaku telah diubah. Yang benar-benar meresahkan sering kali bukanlah kegagalan, melainkan “kelihatannya masih berhasil”.

Yang benar-benar perlu diperbaiki adalah source, rollback dan offline recurrence.

Ketika perubahan semacam ini terjadi pada proyek, hal pertama yang harus diperbaiki bukanlah emosi, tetapi tiga hal: sumber, rollback, dan pengulangan offline.

Sumbernya harus dapat ditelusuri ke gudang tertentu, penyerahan tertentu, dan dokumen berat tertentu. Rollback harus dapat kembali ke versi perilaku sebelumnya, bukan hanya nama. Reproduksi offline harus dapat menjalankan putaran eksperimen yang sama lagi ketika jaringan mengalami jittering, mirror hilang, atau paket upstream dihapus.

Banyak tim yang biasanya merasa hal-hal tersebut jauh dari mereka. Sampai suatu hari pembaruan upstream mengubah gaya keluaran, atau sinkronisasi gambar tertentu lambat, mereka menemukan bahwa masalahnya bukan pada kemampuan model sama sekali, tetapi pada rantai ketergantungan yang tidak dikelola sebagai warga negara kelas satu. Semakin open source modelnya, semakin jelas hal ini. Karena apa yang dibawa oleh open source bukanlah “pintu masuk gratis” yang selalu stabil, namun rantai pasokan yang semakin panjang.

Bagian paling fisik biasanya bukan badan model.

Ketika berbicara tentang lingkungan produksi, kesalahan yang paling mungkin terjadi biasanya bukan ontologi bobot, tetapi entri default, pembaruan otomatis, dan ketergantungan implisit.

Jika sebuah tim menganggap portal online tertentu sebagai satu-satunya sumber, tim tersebut masih dapat menghubunginya hari ini, namun mungkin harus mencari penggantinya untuk sementara besok; jika ia menganggap stasiun cermin sebagai kebenaran default, penyimpangan versi akan diam-diam menyelinap ke dalam pelatihan dan evaluasi; jika ritme pembaruan terlalu ketat, stabilitas perilaku hari ini tidak jelas, dan versi baru besok akan online.

Jadi masalah seperti ini terlihat seperti politik internasional, namun jika menyangkut teknik, lebih terlihat seperti tata kelola rantai pasokan. Siapa yang mengontrol entri, siapa yang bertanggung jawab untuk penandatanganan, siapa yang menentukan rollback, siapa yang menyimpan versi lama, dan siapa yang dapat membangun kembali secara offline, ini adalah batasan yang akan terus mempengaruhi pengiriman. Setelah model itu dipublikasikan, ruang yang tersisa untuk tindakan eksternal akan menjadi lebih kecil; ruang yang tersisa bagi tim untuk membuat pelajaran mereka sendiri akan menjadi lebih besar.

Apakah model open source akan “disegel” adalah pertanyaan sempit. Penilaian yang lebih realistis adalah: semakin open source, semakin sulit untuk menahannya dengan satu tindakan; namun semakin open source, semakin banyak pula kebutuhan untuk mengelola versi, sumber, rollback, dan pengulangan offline. Jika rantai pasokan ini tidak dibendung, fluktuasi eksternal apa pun akan diperkuat menjadi sebuah kecelakaan yang tampak seperti “kecelakaan model”.