10.18 Kantor program sumber terbuka (OSPO) dan kontribusi hulu

Tinjauan dan motivasi

Organisasi Anda sudah berjalan di atas perangkat lunak sumber terbuka: sistem operasi, bahasa, basis data, dan pustaka yang menopang produk Anda sebagian besar ditulis orang yang tidak bekerja untuk Anda. Bab 10.3 membahas pengadaan dan kepatuhan lisensi, dan bab 10.12 membahas keputusan terbuka-versus-tertutup. Bab ini tentang fungsi yang membuat semua itu koheren: kantor program sumber terbuka (OSPO), tim yang memiliki bagaimana perusahaan mengonsumsi, berkontribusi pada, dan merilis sumber terbuka. OSPO adalah pusat gravitasi bagi hubungan yang kalau tidak tersebar di setiap insinyur yang mengetik import.

Kebanyakan organisasi masuk ke sumber terbuka satu dependensi demi satu dependensi, lalu menemukan paparan terakumulasi sekaligus: pertanyaan lisensi saat uji tuntas akuisisi, pustaka kritis dengan satu pemelihara yang kelelahan, advisori keamanan pada kode yang tak diketahui siapa pun dikirimnya. OSPO mengubah kerepotan itu menjadi kapabilitas terkelola. Ia menetapkan kebijakan konsumsi yang memungkinkan alih-alih memblokir, memutuskan kapan berkontribusi ke hulu melayani bisnis, mengurus proyek yang Anda rilis, dan menerapkan kolaborasi terbuka di dalam perusahaan lewat InnerSource. Ini fungsi strategis, terhubung dengan nilai rekayasa perangkat lunak Anda (bab 1.1), bukan kotak centang kepatuhan.

Bagi enterprise pendorongnya skala: ribuan dependensi, kewajiban ekspor dan lisensi lintas yurisdiksi, dan ratusan insinyur yang masing-masing membuat keputusan sumber terbuka kecil setiap hari. Satu kantor memberi sebaran itu tulang punggung. Bagi pemerintah pendorongnya kebijakan dan kepercayaan publik. “Sumber terbuka secara bawaan” dan “public money, public code” makin menjadi hukum, sehingga badan publik butuh seseorang yang dapat menerbitkan kode dengan aman, memakai ulang lintas lembaga, dan menahan vendor pada standar terbuka. Di kedua pengaturan, OSPO membayar dirinya sendiri dengan mengubah risiko tak terlihat dan tak berharga menjadi kerja yang disengaja dan teranggarkan.

Prinsip utama

Sumber terbuka adalah hubungan dua arah, bukan gudang gratis. Anda mengonsumsi, berkontribusi, dan merilis, dan OSPO memiliki ketiganya.
Kontribusi adalah strategi, bukan amal. Mengunggah ke hulu mengurangi biaya membawa tambalan privat dan membeli pengaruh.
Mudahkan jalur cepat, jangan jaga gerbang. Kebijakan yang lebih lambat daripada menyalin kode akan diabaikan, jadi jadikan jalur patuh yang tercepat.
Danai pemelihara yang Anda andalkan. Commons tidak menopang dirinya sendiri, dan pustaka paling kritis Anda mungkin punya satu penulis tak dibayar.
Urus apa yang Anda rilis, atau jangan rilis. Proyek terbengkalai merugikan reputasi Anda lebih daripada tak punya proyek sama sekali.
Ukur keterlibatan agar dapat memperbaikinya. Hitung kontribusi, kesehatan dependensi, dan waktu-ke-persetujuan, bukan siaran pers.
Di pemerintah, buka secara bawaan dan terbitkan secara bawaan. Keterbukaan adalah norma; ketertutupan adalah pengecualian terdokumentasi.

Rekomendasi

Dirikan OSPO yang berukuran sesuai kenyataan Anda

Anda tidak butuh tim besar untuk memulai. Di startup OSPO bisa satu insinyur dengan mandat tertulis dan beberapa jam seminggu. Di enterprise ia kelompok pusat kecil plus jaringan federasi juara yang tertanam di tim produk. Berapa pun ukurannya, beri ia piagam jelas yang mencakup empat tanggung jawab: kebijakan konsumsi dan kepatuhan, kontribusi hulu, merilis dan mengurus proyek Anda sendiri, serta hubungan komunitas dan pendanaan. Tempatkan di mana ia dapat melihat baik rekayasa maupun hukum, sering melapor ke CTO atau VP rekayasa dengan garis putus-putus ke hukum dan keamanan. Mode kegagalannya adalah OSPO yang sepenuhnya hidup di dalam hukum dan menjadi rem; perbaikannya adalah mengisinya dengan insinyur yang mengirim, agar panduannya membawa kredibilitas pada tim yang dilayaninya.

Konsumsi dengan bertanggung jawab, dan jadikan jalur aman jalur mudah

Konsumsi adalah tempat sebagian besar risiko masuk, jadi buat perilaku baik tanpa upaya. Sediakan katalog internal terkurasi berisi komponen yang sudah diperiksa, pemindaian lisensi dan kerentanan otomatis di pipeline, dan bawaan jelas yang dapat diikuti developer tanpa mengajukan tiket. Bersandarlah pada disiplin lisensi di bab 10.3 dan praktik rantai pasok serta kesehatan dependensi di bab 2.18: sematkan versi, hasilkan software bill of materials, awasi rantai pasok perangkat lunak untuk paket yang dibobol atau terbengkalai, dan lacak akhir masa pakai sebelum memaksa migrasi. Tugas OSPO bukan menyetujui setiap dependensi dengan tangan. Melainkan membangun pagar pengaman sehingga sembilan puluh lima persen pilihan aman secara otomatis dan hanya kasus yang benar-benar tidak biasa mencapai manusia.

Berkontribusilah ke hulu karena itu menguntungkan, bukan karena itu baik

Perlakukan kontribusi hulu sebagai keputusan ekonomi. Setiap tambalan privat yang Anda bawa terhadap dependensi adalah pajak yang Anda bayar pada setiap peningkatan, selamanya, sampai perubahan mendarat di hulu atau fork menyimpang begitu jauh sehingga Anda memilikinya sepenuhnya. Menyumbangkan perbaikan kembali menghapus pajak itu. Kontribusi hulu juga membeli pengaruh atas arah, sehingga peta jalan komponen yang Anda andalkan melengkung ke kebutuhan Anda, dan memberi sinyal kompetensi kepada insinyur yang ingin Anda rekrut. Beri developer Anda jalur cepat terdokumentasi: perjanjian lisensi kontributor atau developer certificate of origin yang sudah dibersihkan, persetujuan ringan yang memastikan perubahan aman dibagikan, dan waktu manajemen yang dianggarkan untuk kerja itu. Ketika alternatifnya memelihara fork permanen dari proyek yang tidak Anda kendalikan, berkontribusi kembali hampir selalu lebih murah.

Rilis proyek Anda sendiri dengan tata kelola nyata

Ketika Anda membuka sumber perangkat lunak yang Anda bangun, lakukan dengan sengaja atau jangan sama sekali. Putuskan dulu apakah kode itu komoditas yang layak dibagikan atau pembeda yang layak dijaga tertutup, memakai penalaran di bab 10.12. Jika Anda merilis, pilih lisensi yang cocok dengan maksud Anda (permisif untuk memaksimalkan adopsi, copyleft untuk menjaga ekosistem timbal balik), dokumentasikan siapa memutuskan apa lewat model tata kelola tertulis, dan daftarkan merek dagang pada nama proyek agar Anda dapat melindunginya dari penyalahgunaan sambil menjaga kodenya bebas. Berkomitmenlah pada pengurusan nyata: pelacak isu publik, panduan kontribusi, kode etik, dan kebijakan keamanan dengan pengungkapan terkoordinasi agar pelapor tahu cara menjangkau Anda (bab 4.2). Namai pemelihara dan anggarkan waktunya. Proyek yang Anda luncurkan dengan gembar-gembor dan terbengkalai dalam setahun lebih merusak reputasi Anda daripada yang tak pernah Anda kirim.

Terapkan InnerSource untuk berkolaborasi di dalam perusahaan

Kebiasaan yang membuat sumber terbuka berfungsi (repositori publik, panduan kontribusi jelas, tinjauan berdasarkan merit, hambatan rendah untuk tambalan pertama) berfungsi sama baiknya di balik tembok api. InnerSource berarti setiap insinyur dapat menemukan, memakai, dan memperbaiki proyek internal mana pun, mengirim pull request melintasi batas tim alih-alih mengajukan tiket dan menunggu. Ini meruntuhkan silo, menyebarkan penggunaan ulang kode, dan melatih orang Anda dalam alur kerja persis yang akan mereka pakai saat berkontribusi secara eksternal. OSPO adalah rumah alami InnerSource karena ia sudah memiliki perkakas dan buku panduan budaya. Mulai dengan beberapa pustaka bersama bernilai tinggi, terbitkan panduan kontribusi mereka secara internal, dan beri imbalan tim yang menerima tambalan dari luar dengan anggun.

Danai dan pertahankan pemelihara yang Anda andalkan

Sistem produksi Anda mungkin bertumpu pada pustaka yang dipelihara satu orang di waktu luangnya. Itu risiko rantai pasok, dan respons jujurnya adalah membantu memikul beban. Identifikasi dependensi paling kritis dari bill of materials Anda, temukan yang berbasis pemelihara tipis, dan pilih respons untuk masing-masing: sponsori pemelihara secara langsung, sumbangkan waktu rekayasa, bergabunglah dengan yayasan yang mendanai proyek, atau, sebagai pilihan terakhir, bersiaplah untuk mem-fork atau mengganti. Mendanai commons lebih murah daripada keadaan darurat yang menyusul keruntuhannya, dan menjaga komponen yang Anda andalkan tetap sehat dan bergerak ke arah yang dapat Anda pengaruhi.

Tetapkan kebijakan kontribusi yang menyetujui dengan cepat

Kebijakan kontribusi ada untuk mengatakan ya dengan cepat, bukan mengatakan tidak dengan lambat. Rinci apa yang boleh disumbangkan insinyur tanpa bertanya (perbaikan bug, dokumentasi, fitur kecil untuk proyek yang sudah Anda pakai), apa yang butuh pemeriksaan ringan (apa pun yang menyentuh pembeda atau paten), dan bagaimana kekayaan intelektual serta perjanjian kontributor ditangani sekali, secara terpusat, alih-alih per kontribusi. Otomatiskan bagian membosankan: pemeriksaan lisensi, perjanjian kontributor korporat yang sudah ditandatangani, dan bot yang menandai pengajuan langka yang butuh mata manusia. Ukur waktu-ke-persetujuan dan perlakukan antrean lambat sebagai bug dalam kebijakan.

Trade-off: kelebihan dan kekurangan

Pendekatan	Kelebihan	Kekurangan
OSPO pusat	Kebijakan konsisten, keahlian mendalam, kepemilikan jelas	Dapat menjadi hambatan jika hanya menggerbangi dan tak pernah memungkinkan
OSPO federasi (juara di tim)	Berskala, menjaga keputusan dekat dengan insinyur	Butuh koordinasi kuat atau kebijakan menyimpang
Berkontribusi ke hulu	Menghapus pajak tambalan privat, membeli pengaruh, membantu rekrutmen	Upaya berkelanjutan, tinjauan IP, kerja menurut jadwal orang lain
Membawa fork privat	Kendali penuh, kirim menurut jadwal Anda	Pajak pemeliharaan permanen, menyimpang dari perbaikan keamanan hulu
Merilis proyek Anda sendiri	Ekosistem, reputasi, pemeliharaan bersama	Biaya pengurusan nyata; pengabaian merusak reputasi
Mendanai pemelihara	Melindungi dependensi kritis, membeli niat baik	Biaya langsung, dan memilih siapa yang didanai itu politis
Tanpa OSPO (ad hoc)	Biaya penyiapan nol	Utang hukum, keamanan, dan keberlanjutan yang tak terlihat

Ketegangan sentralnya antara kendali dan pemberdayaan. OSPO yang meninjau setiap dependensi dan setiap kontribusi dengan tangan terasa aman, tetapi menjadi hal yang dihindari insinyur, yang menghasilkan dependensi bayangan tak terlihat yang hendak Anda cegah. OSPO yang hanya menerbitkan panduan ceria tanpa penegakan otomatis diabaikan begitu tenggat mengancam. Resolusinya sama dengan yang mengalir di bab 10.3: otomatiskan kasus umum agar jalur patuh jalur tercepat, dan cadangkan penilaian manusia untuk yang benar-benar baru. Dapatkan keseimbangan itu dan kantor menjadi pengali kekuatan; salah di kedua arah dan ia rem atau hiasan.

Pertanyaan untuk didiskusikan dengan tim Anda

Siapa yang memiliki hubungan Anda dengan sumber terbuka hari ini, dan dapatkah mereka menjawab pertanyaan sulit besok? Jika pengacara calon pengakuisisi meminta inventaris lisensi Anda, atau wartawan bertanya pustaka tak terpelihara mana yang duduk di jalur pembayaran Anda, adakah nama yang melekat pada jawabannya? Bagi kebanyakan organisasi jawaban jujurnya “tidak ada,” yang berarti setiap insinyur diam-diam membuat kebijakan dan tak ada yang akuntabel atas totalnya. Bawa bukti ke rapat: coba hasilkan daftar lisensi yang disetujui, software bill of materials, dan orang yang akan menangani pertanyaan copyleft saat uji tuntas. Jika artefak itu tidak ada atau menunjuk ke tak seorang pun, Anda telah menemukan tugas OSPO pertama Anda. Keputusan yang harus dibuat bukan apakah memiliki fungsi itu tetapi siapa yang memilikinya dan mandat apa yang dibawanya, bahkan jika kantornya satu orang untuk satu hari seminggu.
Apakah Anda membawa tambalan privat yang dapat Anda unggah ke hulu, dan berapa biayanya bagi Anda? Banyak tim memelihara tumpukan diam modifikasi lokal terhadap dependensi mereka, menerapkannya ulang dengan tangan pada setiap peningkatan dan menyerap nyeri merge seolah itu hukum alam. Setiap tambalan itu adalah pajak berulang, dan masing-masing kandidat untuk disumbangkan kembali agar pajaknya hilang. Bawa spesifiknya: daftar fork dan tambalan lokal yang benar-benar dibawa build Anda, estimasi jam rekayasa yang dimakan masing-masing per tahun, dan catat proyek hulu mana yang kemungkinan menerima perubahan itu. Pertimbangan yang bersaing nyata, karena mengunggah ke hulu memakan upaya sekarang dan berjalan menurut jadwal pemelihara, tetapi perbandingannya adalah membayar pajak tambalan selamanya. Jawabannya harus mengubah “kami selalu hanya menerapkan ulang” menjadi pilihan sengaja, dengan jalur kontribusi cukup cepat sehingga insinyur memakainya.
Dependensi mana yang paling menyakitkan jika pemeliharanya pergi, dan apa yang akan Anda lakukan tentangnya? Di suatu tempat dalam tumpukan Anda ada komponen yang akan menghentikan layanan kritis pendapatan atau misi jika rusak, dipelihara satu orang atau segelintir orang yang tak pernah Anda danai atau ucapkan terima kasih. Commons terasa gratis tepat sampai saat ia tidak, dan versi mahal pelajaran itu adalah kerepotan setelah pengabaian atau kerentanan yang tak ditambal. Bawa bill of materials Anda dan ranking dependensi menurut radius ledakan, lalu catat jumlah pemelihara dan status pendanaan beberapa teratas. Untuk setiap yang kritis dan berstaf tipis, putuskan di muka apakah Anda akan mensponsori, menyumbang waktu, bergabung dengan yayasan, atau bersiap mengganti. Itu mengubah titik kegagalan tunggal laten menjadi hubungan terkelola, ditahan pada standar yang sama dengan risiko operasional lain (bab 2.18).
Sebelum Anda membuka sumber perkakas internal berikutnya, apakah Anda siap mengurusnya bertahun-tahun, atau Anda mengirim peluncuran dan permintaan maaf pada akhirnya? Rilis publik adalah komitmen tetap: pelacak isu yang harus dipilah seseorang, kotak masuk keamanan yang harus diawasi seseorang, dan nama yang harus dibela seseorang. Tim meraih pembukaan sumber untuk membantu rekrutmen atau niat baik, lalu menemukan bahwa proyek terbengkalai dengan isu usang merusak reputasi yang diharapkan mereka bangun, lebih daripada tidak mengirim apa pun. Bawa bukti: daftar proyek yang sudah Anda rilis, dan untuk masing-masing tunjukkan usia isu terbukanya, apakah pemelihara bernama punya jam teranggarkan, apakah ia punya model tata kelola, merek dagang terdaftar, dan kebijakan pengungkapan terkoordinasi, dan apakah kodenya komoditas yang layak dibagikan atau pembeda yang harus Anda jaga tertutup (bab 10.12). Pertimbangan yang bersaing adalah pengurusan nyata memakan waktu rekayasa yang dapat Anda habiskan untuk produk, jadi pilihan jujur sering merilis lebih sedikit hal dan mengurusnya dengan benar. Untuk enterprise ini berarti tinjauan hukum dan merek sebelum peluncuran; untuk pemerintah ini berarti merek dagang, kanal pengungkapan, dan proses pengecualian terbit-secara-bawaan diselesaikan sebelum repositori menjadi publik.
Berapa lama sebenarnya insinyur butuh untuk mendapat dependensi disetujui atau kontribusi dibersihkan, dan apakah itu lebih lambat daripada menghindari Anda? Kebijakan sumber terbuka bersaing langsung dengan jalan pintas tercepat yang dapat ditemukan insinyur, dan proses apa pun yang lebih lambat daripada menyalin kode akan dilewati, menghasilkan dependensi bayangan tak terlihat yang hendak dicegah kantor. Ketegangannya kendali terhadap pemberdayaan: setiap tinjauan manual menambah jejak audit dan menangkap masalah sejati yang langka, tetapi juga menambah latensi yang mendorong kasus median keluar dari jalur patuh. Bawa angkanya ke rapat: waktu-ke-persetujuan terukur untuk dependensi standar dan kontribusi standar, pangsa keputusan yang ditangani otomatis versus oleh manusia, dan jumlah pengecualian yang benar-benar butuh penilaian kuartal lalu. Di enterprise dengan ratusan insinyur yang masing-masing membuat keputusan kecil setiap hari, antrean dua hari diam-diam menjadi ribuan tinjauan yang dilewati; di pemerintah, latensi yang sama berbenturan dengan kewajiban pengadaan dan audit yang membutuhkan jejak kertas yang dilewati jalan pintas, sehingga perbaikannya adalah mengotomatiskan kasus umum alih-alih mengisi staf gerbang yang lebih besar.
Proyek internal mana yang paling diuntungkan InnerSource, dan apa yang menghalangi tim lain mengirim Anda pull request hari ini? Praktik yang membuat sumber terbuka berfungsi (repositori publik, panduan kontribusi, tinjauan berdasarkan merit, hambatan rendah untuk tambalan pertama) membuahkan hasil di balik tembok api dengan meruntuhkan silo, menyebarkan penggunaan ulang, dan melatih orang dalam alur kerja persis yang akan mereka pakai untuk berkontribusi secara eksternal. Pertimbangan yang bersaing adalah membuka proyek internal menuntut panduan kontribusi, kapasitas tinjauan cadangan, dan keputusan kode mana yang harus tetap dibatasi demi keamanan atau regulasi. Bawa spesifiknya: namai pustaka bersama bernilai tinggi, catat mana yang sudah menerbitkan panduan kontribusi internal, dan jelaskan bagaimana pull request lintas tim ditangani hari ini, apakah disambut atau hilang dalam antrean. Untuk enterprise imbal hasilnya diukur dalam pembangunan internal duplikat yang dihindari di banyak tim; untuk pemerintah, kebiasaan yang sama meluas melintasi batas lembaga sebagai penggunaan ulang lintas lembaga, sehingga terbit-secara-bawaan dan komponen bersama mengurangi belanja publik duplikat alih-alih melipatgandakannya.

Lensa sektor

Startup. Serahkan kantor kepada satu insinyur bernama untuk beberapa jam seminggu dengan piagam satu halaman, bukan komite. Pilih lisensi permisif secara bawaan dengan pemindai di pipeline, unggah ke hulu hanya segelintir tambalan privat yang benar-benar menyakitkan pada setiap peningkatan, dan siapkan sponsor bulanan kecil untuk pustaka berpemelihara tunggal yang benar-benar tak dapat Anda hidupi tanpanya. Kecepatan lebih penting daripada cakupan di sini: jalur patuh yang lebih cepat daripada menyalin kode mengalahkan kebijakan menyeluruh yang tak diikuti siapa pun.

Bisnis kecil. Anda tidak akan mengisi staf OSPO khusus, jadi beli kapabilitas yang tertanam dalam perkakas yang sudah Anda jalankan: pemindai yang menandai masalah lisensi dan kerentanan, dan katalog terkurasi komponen yang sudah diperiksa. Bingkai kerja sebagai kebersihan kepatuhan lisensi dan kesehatan dependensi alih-alih program: ketahui apa yang ada dalam software bill of materials Anda, ketahui apa yang diwajibkan tiap lisensi, dan ketahui dependensi berpemelihara tunggal mana yang akan menyakitkan jika lenyap. Pilih membeli pemindaian dan katalogisasi daripada membangun sendiri.

Enterprise. Jalankan kantor pusat kecil plus jaringan federasi juara yang tertanam di tim produk, agar kebijakan tetap konsisten sementara keputusan tetap dekat dengan insinyur. Otomatiskan pemindaian lisensi, kerentanan, dan ekspor, cakup setiap insinyur dengan perjanjian kontributor yang sudah dibersihkan, dan lacak waktu-ke-persetujuan sebagai metrik yang dilaporkan. Danai yayasan di balik dependensi kritis Anda, jalankan InnerSource di banyak repositori, dan kelola seluruh properti sebagai portofolio dengan metrik kesehatan dan keterlibatan alih-alih sebaran keputusan individual.

Pemerintah. Beroperasilah di bawah sumber-terbuka-secara-bawaan dan public-money-public-code: terbitkan layanan baru di repositori publik kecuali pengecualian keamanan atau privasi terdokumentasi berlaku. Jalankan katalog lintas lembaga agar tim memakai ulang sebelum membangun, tulis persyaratan sumber terbuka dan standar terbuka ke dalam pengadaan agar vendor menyampaikan kode yang dapat dipakai ulang dengan hak tetap dipertahankan, dan tangani pengungkapan terkoordinasi untuk apa yang Anda terbitkan. Danai pemeliharaan pustaka bersama yang diandalkan beberapa lembaga, agar tak ada satu tim pun yang diam-diam memiliki infrastruktur yang diandalkan seluruh pemerintah.

Contoh

Startup. Startup dua puluh orang menjadikan insinyur platform utamanya pemilik OSPO paruh waktu dengan piagam satu halaman. Ia menetapkan kebijakan konsumsi sederhana (lisensi permisif disetujui di muka, copyleft ditinjau, pemindai di pipeline), dan memperhatikan tim membawa tiga tambalan privat terhadap pustaka antrean sumber terbuka, diterapkan ulang dengan nyeri pada setiap peningkatan. Ia mengunggah ketiganya ke hulu; dua diterima dalam sebulan, menghapus pajak peningkatan untuk selamanya. Ia membuka sumber satu perkakas internal kecil dengan README nyata, lisensi, dan kontak keamanan, sebagian besar untuk menarik insinyur, dan menyiapkan sponsor bulanan untuk parser berpemelihara tunggal yang diandalkan produk. Tak satu pun ini butuh penambahan staf, hanya pemilik bernama dan mandat jelas.

Enterprise. Sebuah bank global menjalankan OSPO pusat enam orang plus jaringan federasi juara sumber terbuka yang tertanam di setiap grup produk. Tim pusat memiliki kebijakan, pemindaian kepatuhan lisensi dan ekspor otomatis, dan perjanjian lisensi kontributor yang mencakup setiap insinyur sejak hari pertama. Para juara menangani tinjauan lokal dan membimbing tim mereka dalam berkontribusi. Bank mendanai beberapa yayasan yang proyeknya mendasari sistem perdagangannya, menyumbang perbaikan ke hulu pada kerangka data yang dipakai luas agar berhenti memelihara fork, dan menjalankan InnerSource di dua ratus repositori internal agar tim mana pun dapat mengirim pull request ke tim lain. Waktu-ke-persetujuan untuk kontribusi standar kurang dari dua hari, dilacak sebagai metrik yang dilaporkan OSPO setiap kuartal.

Pemerintah. Sebuah lembaga digital nasional beroperasi di bawah mandat “sumber terbuka secara bawaan” dan public-money-public-code. OSPO-nya menerbitkan layanan baru di repositori publik kecuali pengecualian terdokumentasi berlaku untuk keamanan atau privasi, menjalankan katalog lintas pemerintah agar lembaga memakai ulang kode sebelum membangunnya, dan menulis persyaratan sumber terbuka serta standar terbuka ke dalam pengadaan agar vendor menyampaikan kode yang dapat dipakai ulang dan terdokumentasi baik dengan pemerintah mempertahankan hak. Kantor juga menangani pengungkapan keamanan terkoordinasi untuk kode yang diterbitkannya dan mendanai pemeliharaan pustaka identitas bersama yang kini diandalkan beberapa lembaga, agar tak ada satu tim pun yang diam-diam memiliki komponen yang diandalkan seluruh pemerintah.

Kasus bisnis: motivasi, ROI, dan TCO

Imbal hasil paling jelas adalah penghapusan kejutan mahal yang dapat dihindari. Sumber terbuka yang tak terkelola menghasilkan krisis yang tiba menurut jadwalnya sendiri: pelanggaran copyleft yang muncul saat uji tuntas akuisisi, migrasi darurat dari komponen mati, pembobolan yang ditelusuri ke dependensi yang tak terdaftar inventaris mana pun. OSPO mengubah peristiwa berprobabilitas rendah berbiaya tinggi itu menjadi kerja mantap yang teranggarkan. Tambahkan penghematan berulang dari kontribusi hulu: setiap tambalan privat yang Anda pensiunkan berhenti memajaki setiap peningkatan mendatang, dan di properti besar itu berlipat menjadi kapasitas rekayasa nyata yang dikembalikan ke kerja produk.

Pada buku besar total biaya kepemilikan, kantor itu murah relatif terhadap apa yang dilindunginya. Biayanya tim kecil, sedikit perkakas pemindaian dan katalog, dan pendanaan pemelihara yang sederhana. Bandingkan dengan biaya tidak memilikinya: liabilitas hukum, uji tuntas gagal atau tertunda, insiden keamanan, pembangunan internal duplikat dari hal yang sudah ada sebagai sumber terbuka, dan pendarahan lambat fork yang tak dipilih siapa pun untuk dipertahankan. Ada juga imbal hasil sisi atas yang lebih sulit diberi harga tetapi nyata: pengaruh atas arah komponen yang Anda andalkan, keunggulan rekrutmen dan reputasi dari kehadiran sumber terbuka yang kredibel, dan penyampaian lebih cepat karena insinyur memakai ulang alih-alih membangun ulang. Ketika Anda mengajukan kasus kepada pimpinan, bingkai OSPO sebagai manajemen rantai pasok untuk mayoritas basis kode Anda, dengan dividen strategis di atasnya. Di pemerintah, tambahkan dimensi kepatuhan, karena keterbukaan sering diwajibkan dan melakukannya dengan baik menghindari baik ketidakpatuhan maupun belanja publik duplikat.

Anti-pola dan jebakan

OSPO sebagai gerbang. Kantor yang hanya meninjau dan memblokir, tak pernah memungkinkan, dihindari, menghasilkan dependensi bayangan yang hendak dicegahnya.
Teater kontribusi. Mengumumkan strategi sumber terbuka sambil membuat proses persetujuan begitu lambat sehingga tak ada yang benar-benar berkontribusi.
Rilis terbengkalai. Menerbitkan proyek dengan pos blog peluncuran, lalu tak pernah memilah satu isu pun, merusak reputasi Anda lebih daripada diam.
Fork-lalu-lupa. Mem-fork dependensi untuk satu perbaikan lalu membawanya selamanya, menyimpang dari tambalan keamanan hulu.
Membonceng pemelihara rapuh. Bergantung pada pustaka kritis berpemelihara tunggal dan tak pernah mendanai, berterima kasih, atau membantu orang di baliknya.
Mengabaikan merek dagang. Merilis proyek tanpa melindungi namanya, lalu menyaksikan fork atau vendor memperdagangkan reputasi Anda.
Kepemilikan hanya hukum. Menempatkan OSPO sepenuhnya di hukum sehingga panduannya tak membawa kredibilitas rekayasa dan tim mengabaikannya.
Metrik kesombongan. Menghitung bintang dan sebutan pers alih-alih kesehatan dependensi, waktu-ke-persetujuan, dan tambalan privat yang dipensiunkan.

Model kematangan

Tingkat 1, Memulai: Insinyur menambah, menambal, dan sesekali menerbitkan sumber terbuka tanpa kebijakan dan tanpa pemilik. Konsumsi, kontribusi, dan rilis reaktif dan ad hoc, digerakkan inisiatif individu. Fork privat menumpuk tanpa disadari, tak ada yang mendanai proyek hulu mana pun, dan tak ada yang dapat menjawab pertanyaan lisensi saat uji tuntas.
Tingkat 2, Mengembangkan: Praktik dasar muncul tetapi bervariasi per tim. Kebijakan konsumsi kasar dan daftar lisensi yang disetujui ada, dan seseorang longgar bertanggung jawab, namun kontribusi lambat dan kasus-demi-kasus dan sebagian kelompok melakukan jauh lebih banyak daripada yang lain. Beberapa dependensi kritis diketahui, tetapi keberlanjutan, rilis, dan pengurusan tetap tidak konsisten.
Tingkat 3, Membakukan: OSPO bercharter memiliki konsumsi, kontribusi, rilis, dan komunitas, dan praktik didokumentasikan serta ditegakkan di seluruh organisasi. Pemindaian dan software bill of materials otomatis, perjanjian kontributor yang sudah dibersihkan dan jalur persetujuan cepat ada, proyek terrilis membawa tata kelola nyata, merek dagang, dan kebijakan keamanan, dan InnerSource menyebar. Tim pemerintah menerbitkan secara bawaan.
Tingkat 4, Mengelola: Fungsi sumber terbuka diukur dan dikendalikan terhadap garis dasar. Waktu-ke-persetujuan dilacak terhadap target, volume kontribusi dan laju penerimaan hulu dilaporkan, dasbor kesehatan dependensi dan jumlah pemelihara menandai titik kegagalan tunggal, cakupan pemelihara terdanai atas dependensi berisiko tertinggi dipantau, dan inventaris tambalan privat serta fork menurun kuartal demi kuartal. Proyek terrilis punya waktu respons isu terukur, pengecualian ditinjau pada irama, dan metrik kesombongan seperti bintang dibuang demi ini.
Tingkat 5, Mengorkestrasi: Sumber terbuka adalah kapabilitas strategis terkelola, terintegrasi dengan perencanaan rekayasa, hukum, keamanan, dan pengadaan serta diadaptasi terus-menerus. Kontribusi rutin, pemelihara kritis dan yayasan didanai, organisasi mengurus proyek yang dijalankan baik dan mengarahkan ekosistem yang diandalkannya, dan InnerSource adalah norma. Metrik keterlibatan dan kesehatan memberi makan perbaikan berkelanjutan, dan portofolio diseimbangkan ulang seiring dependensi, risiko, dan mandat bergeser.

Gagasan untuk didiskusikan

Di mana garis antara OSPO yang memungkinkan dan yang menggerbangi, dan bagaimana Anda tahu dari luar yang mana yang telah Anda bangun?
Fork atau tambalan privat Anda yang mana yang Anda bawa karena kebiasaan alih-alih kebutuhan, dan apa yang dibutuhkan untuk mengunggah tiga teratas ke hulu?
Bagaimana Anda memutuskan pemelihara dan yayasan mana yang didanai ketika daftar dependensi kritis lebih panjang daripada anggaran?
Apa yang benar-benar akan berubah pada rilis berikutnya jika Anda harus menerbitkannya dengan tata kelola nyata, merek dagang, dan kebijakan pengungkapan terkoordinasi sejak hari pertama?
Untuk pembaca sektor publik, apa proses yang dapat dipertahankan untuk mengecualikan kode dari terbit-secara-bawaan tanpa diam-diam mengikis prinsipnya?
Pustaka internal mana yang paling diuntungkan InnerSource, dan apa yang menghalangi tim lain mengirim Anda pull request hari ini?

Poin-poin utama

OSPO memiliki seluruh hubungan dengan sumber terbuka: mengonsumsi dengan bertanggung jawab, berkontribusi ke hulu, merilis proyek Anda sendiri, dan mempertahankan pemelihara yang Anda andalkan.
Berkontribusi ke hulu adalah strategi, bukan amal; ia menghapus pajak berulang tambalan privat, membeli pengaruh atas arah, dan membantu Anda merekrut.
Jadikan jalur patuh jalur tercepat lewat otomasi dan kurasi, agar kantor memungkinkan insinyur alih-alih menggerbanginya.
Rilis proyek Anda sendiri hanya dengan tata kelola nyata, lisensi terpilih, merek dagang terlindungi, dan pengungkapan keamanan terkoordinasi, atau jangan rilis sama sekali.
Danai dan bantu pemelihara kritis tempat sistem produksi Anda bertumpu, karena commons tidak menopang dirinya sendiri.
Terapkan InnerSource untuk membawa kolaborasi sumber terbuka ke dalam perusahaan, dan di pemerintah, buka secara bawaan, terbitkan secara bawaan, dan pakai ulang sebelum membangun.

Referensi dan bacaan lanjutan

Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Nadia Eghbal, Roads and Bridges: The Unseen Labour Behind Our Digital Infrastructure
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Danese Cooper dan Klaas-Jan Stol (editor), Adopting InnerSource: Principles and Case Studies
The Linux Foundation dan TODO Group, OSPO guides and Open Source Program Office resources
The Linux Foundation dan TODO Group, State of OSPOs and Open Source Management (seri survei tahunan)
Heather Meeker, Open (Source) for Business
Open Source Initiative, The Open Source Definition dan daftar lisensi yang disetujui
Free Software Foundation Europe, materi kampanye Public Money, Public Code
U.S. Federal Source Code Policy dan panduan Code.gov