Menambal perangkat lunak sumber terbuka ketika meningkatkan bukan suatu pilihan?

Baru-baru ini saya menemukan bug yang agak mengganggu (dikonfirmasi) dalam paket perangkat lunak sumber terbuka yang telah saya integrasikan ke dalam aplikasi saya. Menurut pelacak masalah publik, bug ini telah diatasi dalam rilis perangkat lunak terbaru.

Kadang-kadang Anda PERLU perbaikan bug untuk menghindari refactor mahal dari modul tertentu, namun karena alasan teknis dan / atau politik, Anda tidak akan dapat meningkatkan ke rilis terbaru.

Saat memeriksa perubahan kode yang dibuat, perbaikannya tampaknya cukup sederhana sehingga saya merasa opsi yang mungkin adalah menambal kode sendiri dan mengkompilasi ulang versi perangkat lunak yang disetujui saat ini, namun pencela ingin memperdebatkan kasus bahwa ini hampir selalu merupakan ide yang buruk dalam hal ini berisiko dan memperkenalkan kompleksitas yang merepotkan.

Di mata mereka karena perubahan kode ini dilakukan oleh kami semata-mata untuk penggunaan kami, itu harus menjadi bagian dari basis kode kami, yang berarti bahwa alih-alih memperkenalkan perangkat lunak sumber terbuka sebagai ketergantungan pihak ketiga, kita harus memperkenalkannya sebagai proyek baru dan menggabungkan build otomatisnya ke dalam proses build kami.

Bagi saya, saya pikir ini salah tuju, karena kita akan menarik kode mereka dari repositori kontrol sumber mereka ke kita, dan kita kehilangan sejarah di balik setiap perubahan kode yang terjadi sebelum itu. Juga sepertinya sesuatu yang terlalu rumit untuk perubahan kode kecil yang perlu dibuat.

Apakah itu ide yang buruk untuk melakukan hal di atas dalam kasus ini? Jika demikian, lalu bagaimana situasi ideal ketika open source perlu diubah, tetapi hanya untuk keuntungan Anda sendiri?

Jika Anda tidak dapat menggunakan versi yang lebih baru yang tidak memiliki masalah yang Anda hadapi, satu-satunya opsi yang Anda miliki adalah untuk keduanya

• hidup dengan masalah dan temukan solusinya
• bercabang perpustakaan dan memperbaikinya dalam versi pribadi Anda (yang akan Anda lakukan secara efektif)
• menyerah dan beri tahu manajer Anda bahwa masalahnya tidak dapat diatasi (yang akan bohong, karena Anda memiliki dua opsi lain yang terbuka untuk Anda).

Saya sudah berada di posisi Anda, opsi 2 (membuat garpu khusus) seringkali merupakan solusi paling enak yang tersedia. Itulah kehidupan ketika berurusan dengan perpustakaan open source, terutama yang berkembang dengan cepat dan memiliki kebiasaan buruk untuk memundurkan kompatibilitas antara rilis (yang menurut pengalaman saya adalah alasan paling umum untuk melakukan hal-hal seperti ini).
Untuk lebih dari beberapa perpustakaan OSS itu membuat saya dan tim saya menjadi bagian dari mandat pembungkus di sekitar semua dan semua dari mereka dan mengakses fungsi perpustakaan pihak ke-3 secara eksklusif melalui pembungkus itu. Dengan begitu, jika kita perlu mengganti perpustakaan pihak ke-3 dengan versi yang sangat berbeda sehingga akan merusak kode kita, perubahan setidaknya sebagian besar terbatas pada pembungkus itu. Ini bukan yang terbaik (menambahkan kode, dapat menambah kompleksitas dan kinerja biaya) tetapi kadang-kadang itu satu-satunya cara untuk mempertahankan kewarasan Anda.

Apa yang akan Anda lakukan adalah ide yang buruk dalam kasus yang lebih umum di mana Anda menggabungkan perangkat lunak pihak ketiga dan bermaksud untuk melacak rilis mereka . Biasanya orang melakukan itu karena mereka menginginkan fitur dalam komponen pihak ketiga yang tidak ingin diterapkan oleh pengelola, atau untuk diterapkan dengan cara yang Anda butuhkan.

Namun, Anda secara eksplisit mengatakan bahwa Anda tidak akan memutakhirkan kode yang dibundel. Itu membuat Anda secara efektif mengelola komponen pihak ketiga. Oleh karena itu, apakah menambal itu adalah ide yang baik atau tidak hanya tergantung pada apakah Anda memahami kode itu dengan cukup baik untuk yakin akan efek yang diinginkan. Tes integrasi Anda harus cukup untuk memverifikasi bahwa itu, pada kenyataannya, melakukan apa yang Anda anggap. Karena itu, ketika Anda menceritakan situasinya, bagi saya tampaknya pengulas Anda salah.

Benar-benar tidak ada yang salah dengan melakukan itu selama semua orang dapat menanggung biaya, manfaat dan risiko.

... perbaikannya tampaknya cukup sederhana ... untuk menambal kode sendiri

Ketika Anda memiliki pekerjaan yang harus dilakukan, sempurna (memiliki perpustakaan pihak ketiga yang persis apa yang Anda inginkan) adalah musuh yang cukup baik (menambalnya sendiri), dan kadang-kadang Anda harus melakukan hal-hal seperti itu. Saya telah melakukan sejumlah proyek di mana kami telah membeli lisensi sumber untuk perpustakaan komersial sehingga kami dapat memperbaiki masalah sebelum vendor mendapatkannya.

... pencela ingin memperdebatkan kasus bahwa ini hampir selalu merupakan ide yang buruk karena berisiko dan memperkenalkan kompleksitas yang merepotkan.

Itu ide yang buruk jika Anda tidak memiliki daging untuk menangani pembedahan kode orang lain, mengidentifikasi masalah dan menulis perbaikan. Itu benar apakah kodenya di rumah atau pihak ketiga; satu-satunya perbedaan adalah apakah itu dilemparkan di atas bilik atau dinding bangunan sebelum mendarat di pangkuan Anda.

Jika pencela Anda hanya menyisihkan ide tanpa mempertimbangkan biaya untuk tidak melakukan patch ini, mereka tidak melakukan pekerjaan rumah mereka. Jika Anda memiliki banyak kode internal yang dipengaruhi oleh bug yang akan diperbaiki oleh tambalan Anda, Anda harus melewati dan mengubahnya untuk mengatasinya dan menguji kembali semuanya untuk memastikannya berfungsi dengan benar. Kemudian, jika Anda pernah memutakhirkan paket ke versi bug-diperbaiki, Anda mungkin harus menemukan dan menghapus solusi Anda dan menguji lagi. Ada risiko untuk melakukan itu juga, seperti melewatkan kasus yang Anda ubah atau pengujian yang tidak memadai. Secara pribadi, jika saya memiliki kesempatan untuk memperbaiki bug pada sumbernya, saya lebih suka melakukannya di sana daripada mengejar sisa kode dengan pemukul lalat dan berharap saya mendapatkan semuanya.

... perubahan kode dilakukan oleh kami ... itu harus menjadi bagian dari basis kode kami ... kami harus memperkenalkannya sebagai proyek baru dan memasukkan build otomatisnya ke dalam proses build kami.

Jika Anda melakukan tambalan, tambalan itu adalah bagian dari kode Anda sendiri, yang berarti Anda harus menjadikannya bagian dari proses Anda. Ini tidak ada bedanya dengan menambahkan sesuatu yang 100% kode Anda ke sistem Anda. Perlakukan distribusi pihak ketiga sebagai sakral dan masukkan ke dalam modul seperti itu adalah kode sumber. Setiap tambalan yang Anda tulis disimpan dengannya dalam file terpisah dan diterapkan sebagai bagian dari proses pembuatan. Dengan begitu Anda selalu beralih dari sumber bersih ke sumber yang ditambal ke produk yang dibuat dan dapat menunjukkan dengan tepat apa yang terjadi. (Beberapa orang membongkar, menambal tangan, mengemas ulang dan menyimpannya dalam kontrol versi. Itu buruk.)

... kami akan menarik kode mereka dari repositori kontrol sumber mereka ke dalam kode kami, dan kami kehilangan sejarah di balik setiap perubahan kode ...

Jika Anda memperlakukan perpustakaan pihak ketiga sebagai ketergantungan pihak ketiga, Anda tidak memiliki sejarah untuk memulai dan Anda tidak kehilangan apa-apa. Jika Anda memiliki akses berkelanjutan ke repositori pihak ketiga, Anda dapat berkonsultasi yang harus Anda lakukan. Rilis pihak ketiga harus diperlakukan seperti gumpalan amorf yang Anda periksa di sistem Anda sendiri tanpa diubah. Jika Anda perlu melihat perubahan antara rilis yang Anda gunakan dan rilis yang lebih baru, Anda bisa melakukan itu dan, jika Anda mau, buat tambalan ke versi lama yang memasukkan perubahan yang Anda inginkan.

Juga sepertinya sesuatu yang terlalu rumit untuk perubahan kode kecil yang perlu dibuat.

Jika proses pembuatan Anda cukup canggih, menambahkan ini seharusnya tidak lebih sulit daripada menambahkan kode Anda sendiri. Ada sejumlah kecil tenaga kerja untuk membawanya ke titik di mana proses unpack / patch / build adalah automagic, tetapi setelah selesai, itu dilakukan selamanya. Mungkin ada satu bug sekarang, tetapi mungkin ada dua puluh di masa depan. Jika ada, Anda akan jauh lebih bahagia karena meletakkan dasar untuk mendukung semua itu sekarang, karena itu akan membuat berurusan dengan 19 pekerjaan berikutnya jauh lebih sedikit.

Apa yang ingin Anda lakukan tampaknya cukup masuk akal, tetapi sepertinya ada (suara?) Alasan proses untuk menentangnya. Saya tidak akan membandingkan solusi yang diusulkan, tapi mungkin ada cara Anda bisa mendapatkan kue dan memakannya juga:

Jika proyek open source yang dipermasalahkan memungkinkannya, kontribusikan bugfix porting kembali Anda ke repositori mereka. Artinya, jika Anda menggunakan versi 1.5.2 dan versi stabil saat ini adalah 1.6.1, berkontribusi tambalan ke 1.5.2. Jika diadopsi, Anda dapat mengambil sumber tetap langsung dari repositori (mungkin sebagai versi 1.5.3) dan membuat semua orang senang.

Dengan kata lain: Tempelkan untuk orang lain yang ada dalam situasi Anda juga. Tentu saja ini hanya mungkin jika proyek mendukung (atau setidaknya memungkinkan) pembaruan untuk versi yang dirilis. Tapi itu tentu praktik standar yang cukup hari ini.