Seberapa serius kehilangan kode sumber? [Tutup]


9

Jika sebuah perusahaan perangkat lunak kehilangan kode sumber ke salah satu produk yang mereka jual, seberapa seriuskah itu, dalam hal yang bisa Anda jelaskan kepada orang awam? Apakah istilah "kelalaian" terlalu kuat? Atau "ketidakmampuan kotor"? Jelas tidak ada yang terbunuh tetapi bukankah ini seserius kelalaian finansial yang membuat orang dipenjara?

EDIT: Katakanlah itu bukan kasus disk drive menabrak, bencana alam atau semacamnya. Hanya saja mereka salah meletakkannya.


37
Ada cerita di balik pertanyaan ini, dan saya sangat ingin mendengarnya. Saya hanya akan menunggu sampai muncul di Daily WTF.
BlairHippo

4
@ Josh K - Analogi buruk! Seorang anak tidak bisa diganti. Kode sumber bisa. (dan saya sangat terguncang jika Anda berpikir bahwa source_code == kid). Tapi, saya kira Anda belum memilikinya.
Benteng

6
@Rook: Mengapa analogi yang buruk? Kode sumber tidak dapat diganti dengan tepat, hanya dapat direplikasi dengan cara yang sama. Memang ini tidak seekstrim kehilangan anak, tetapi perumpamaannya masih bagus.
Josh K

6
@Rook: Anda melewatkan poin bahwa sementara satu (anak-anak) jelas jauh lebih penting daripada kode sumber, kepemilikan keduanya masih sangat berharga. Anda mengabaikan analogi saya karena anak-anak lebih penting daripada kode sumber akan seperti mengabaikan Yahoo! sebagai perusahaan pencarian karena Google jauh lebih besar. Maksud saya adalah keduanya sangat besar, fakta bahwa satu ~ 10x bermakna / penting maka yang lain tidak masalah. Begini, lepas repositori (dan semua salinan kode) untuk aplikasi utama perusahaan Anda dan kembali kepada saya dalam 5-10.
Josh K

5
Saya tidak mengerti bagaimana mungkin hanya ada satu salinan yang "salah tempat"? Saya biasanya memiliki setidaknya dua atau tiga salinan sendiri dalam berbagai tahap perbaikan, pembaruan, dan tambalan yang sedang saya kerjakan. Rekan-rekan saya akan memiliki salinan mereka sendiri. Paling buruk, Anda mungkin kehilangan riwayat dalam repositori sumber Anda (jika Anda menggunakan repositori pusat tanpa cadangan) ... Saya hanya tidak melihat bagaimana ini mungkin ...
Dean Harding

Jawaban:


27

Katakanlah MS kehilangan sumber untuk Windows Phone 7 ... orang telah terbunuh untuk waaaaay kurang dari perkiraan $ 400 juta biaya untuk mengembangkannya.

Bergantung pada produknya, tidak ada istilah yang bisa saya pikirkan yang terlalu kuat.


1
Jika mereka menjual perangkat lunak dan tidak memiliki kode sumber untuk itu, ya, itu tidak kompeten. Namun, sebagai pengembang perangkat lunak khusus, sungguh menakjubkan betapa sering saya menjalankan perusahaan kecil yang dijalankan oleh non-programmer yang mengalihdayakan pengembangan mereka, dan bahkan tidak memiliki salinan kode sumber yang dapat dibangun untuk perangkat lunak yang mereka jual.
Bob Murphy

1
Dan bukan hanya perusahaan kecil yang melakukan itu. Perusahaan konsultan saya dulu melakukan banyak pekerjaan untuk Informix, yang pada hari itu adalah pesaing yang layak untuk Oracle. Mereka memutuskan untuk mengalihkan salah satu proyek kami ke perusahaan outsourcing India, dan suatu hari manajer memanggil kami: "Anda tidak mengirimi kami sumber!" "Ya, sudah, pada tanggal X (sekitar setahun sebelumnya), dan ini nomor pelacakan FedEx. Apakah Anda kehilangan nomor itu?" "Tidak, tentu saja tidak." "Tidak apa-apa jika kamu melakukannya, karena kita dapat mengambilnya dari arsip kita, tetapi akan ada biaya." "Tidak, jangan repot-repot." Kami menemukan kemudian mereka memang kehilangan itu.
Bob Murphy

18

Bagi sebuah perusahaan, ini seperti kehilangan perhiasan mahkota. Jika itu adalah produk dengan prosesor tertanam maka mereka dapat terus membuat produk "apa adanya" tetapi mereka kehilangan kemampuan untuk memperbaikinya atau untuk memperbaiki masalah.

Di pasar saat ini perusahaan IS itu IP. Kalah itu dan itu keluar dari bisnis.


13

Seperti yang telah dicatat oleh yang lain, ini kemungkinan berada di bawah tajuk "semuanya tergantung", jadi beberapa senarios:

Sumber untuk gim video konsol berbasis disk - Ini kemungkinan akan berdampak kecil pada perusahaan karena mereka cenderung tidak membuat perubahan apa pun pada gim setelah gim tersebut dibakar ke disk. Memang mereka mungkin kehilangan waktu jika ada kode perpustakaan yang harus mereka kembangkan, tidak akan seburuk itu.

Sumber untuk gim video yang dapat diunduh - Ini kemungkinan besar akan buruk karena pelanggan kemungkinan akan berharap bahwa bug akan ditambal, tidak dapat melakukannya dapat menyebabkan pelanggan kehilangan kepercayaan pada perusahaan yang dapat berdampak buruk pada rilis mendatang.

Sumber untuk gim dalam pengembangan - Sebagian besar perusahaan gim video tidak dapat kehilangan kode untuk gim yang saat ini dalam pengembangan kecuali jika sangat awal dalam siklus pengembangan (yaitu berhari-hari, mungkin berminggu-minggu ke dalamnya.) Untuk perusahaan kecil, kehilangan sumbernya karena rilis andalan mereka dapat menyebabkan mereka gulung tikar.

Sumber untuk aplikasi bisnis kecil dengan audiens rilis terbatas - Tidak mungkin menyebabkan masalah bagi perusahaan, meskipun mereka mungkin kehilangan beberapa pelanggan.

Sumber untuk aplikasi bisnis besar dengan audiens rilis terbatas - Situasi lain di mana itu dapat menyebabkan perusahaan keluar dari bisnis karena hilangnya kepercayaan dari pelanggan mereka. Bahkan di sebagian besar pasar kecil cenderung ada lebih dari satu perusahaan yang beroperasi dan ini bisa cukup bagi bisnis untuk pindah ke pesaing.

Sumber untuk aplikasi utama dari sebuah perusahaan besar - Di sinilah semua tergantung dan kemungkinan akan sangat sempit, berdasarkan kasus per kasus. Produk unggulan (mis. Microsoft Windows) umumnya memiliki kontrak dukungan yang terkait dengannya dan tidak dapat mendukung produk dapat menyebabkan pelanggaran tuntutan hukum kontrak. Jika saya harus memberikan perkiraan, saya akan mengatakan bahwa sebagian besar orang yang terlibat dalam kehilangan kode hingga kepemimpinan senior orang-orang mungkin perlu mencari pekerjaan baru.

Namun, di seluruh papan, saya mungkin akan mengatakan bahwa orang yang kehilangan kode akan mencari pekerjaan baru (dan mungkin merasa sulit untuk menemukannya!) Dan mereka mungkin juga menghadapi tuntutan hukum dari perusahaan.


Adalah umum untuk menggunakan kembali sebagian besar kode sumber game yang dirilis sebelumnya ketika mengembangkan game berikutnya - terutama ketika mengembangkan sekuelnya. Namun mengingat kehidupan studio game yang relatif singkat, belum jarang terdengar tentang kehilangan sumber game selama beberapa dekade terakhir.
usap

3

Meskipun ada beberapa kasus di mana itu bisa menjadi bencana besar, saya pikir ada banyak hal yang tidak (setidaknya dari perspektif perusahaan perangkat lunak).

Saya pikir ada terlalu banyak variabel untuk memberikan jawaban, apakah ada dampak hukum, tetapi beberapa pertanyaan untuk dipertimbangkan dalam menentukan yang akan mencakup:

  • Apa sifat dari program ini? Jika itu sesuatu yang mereka hilang karena aplikasi seperti itu adalah selusin sepeser pun dan itu tidak penting , lalu apa? Jika itu adalah produk komersial andalan perusahaan, mereka hanya merugikan diri mereka sendiri. Jika itu adalah perangkat lunak khusus yang mereka kontrak untuk bangun, di situlah ia bisa menjadi menarik, tetapi mereka harus Anda tanyakan ...
  • Siapa yang memiliki hak cipta kode? (Jika pelanggan memegang hak cipta, maka propertinya telah hilang / hancur)
  • Apakah pelanggan secara aktif dirugikan oleh hilangnya kode?
  • Apakah ada kontrak tentang pengembangan di masa depan yang akan dilanggar sebagai akibat dari hilangnya kode?
  • Seberapa pentingkah untuk dapat membuat ulang perangkat lunak yang ada? Jika sesuatu seperti skrip shell untuk melakukan tugas perawatan, perusahaan perangkat lunak memakan waktu yang diperlukan untuk membuat yang baru yang melakukan hal yang sama. Jika ini adalah office suite, bersihkan resumenya.

Dan saya yakin ada banyak faktor lain yang harus dipertimbangkan. Jangan ragu untuk menambahkan.

Sekarang, saya memang mengatakan "dari perspektif perusahaan perangkat lunak." Mungkin masih menjadi bencana di benak pelanggan karena rencana mereka untuk perubahan, peningkatan, atau yang lainnya. Meskipun demikian, sebuah kontrak untuk hal-hal seperti itu atau kepemilikan hak cipta, itu dapat membuat marah pelanggan, tetapi tanpa kewajiban apa pun dari pihak pengembang selain melakukan apa yang mereka bisa untuk menjaga hubungan pelanggan yang baik.


Dan untuk lebih memperluas pada "perspektif pelanggan", apa yang saya maksudkan adalah, saya tidak tahu apa cerita di balik pertanyaan itu, tetapi tidak akan pernah terdengar bagi pelanggan untuk berpikir bahwa mereka telah mendapatkan hak untuk mengharapkan kode sumber dijaga seperti Fort Knox sementara pengembang menganggapnya "membuang" ketika pelanggan belum meminta modifikasi atau pekerjaan tambahan dalam tiga tahun sejak penempatan.
Blumer

Perhatikan bahwa melakukan hal-hal yang membuat marah pelanggan mungkin juga merupakan pelanggaran kontrak dan dapat ditindaklanjuti secara hukum. Ini juga dapat menyebabkan pelanggan mengeluh di depan umum.
David Thornley

3

Ah, diberikan klarifikasi ini dari Anda (di komentar):

Ini dikembangkan sejak lama, tanpa kontrol sumber, mereka telah menjualnya selama ini dan sekarang tiba-tiba mereka perlu memperbaruinya

Dalam situasi khusus ini , saya akan mengatakan itu mungkin bukan akhir dari dunia. Mengingat bahwa mereka telah menjual perangkat lunak selama bertahun-tahun tanpa perlu kode sumber, maka Anda dapat mengatakan kepada pelanggan yang meminta pembaruan ini, "maaf tidak dapat dilakukan".

Sekarang jangan salah paham, kehilangan kodenya tidak baik. Akan sangat mahal bagi perusahaan Anda untuk menulis ulang atau merekayasa balik versi aslinya (jika itu yang mereka putuskan untuk dilakukan). Tapi ini bukan akhir dunia. Mereka jelas bertahan selama ini tanpa perlu kode, jadi mereka mungkin terus bertahan tanpa itu.

Tentu saja ini mengasumsikan bahwa perangkat lunak yang mereka jual hanya sebagian kecil dari bisnis mereka. Yang saya duga pasti demikian ...


Ya, itu hanya satu dari banyak produk yang mereka jual
JoelFan

Ini bukan hanya 1 pelanggan ... itu tidak akan lagi bekerja pada rilis terbaru dari OS
JoelFan

1

Selama mereka masih bisa menjual produk, saya tidak berpikir mereka dalam masalah. Sekarang, jika mereka terikat kontrak dengan klien untuk memperluas produk dan menyediakan fitur-fitur baru tertentu di versi berikutnya, itu jauh lebih serius karena itu mengatur mereka untuk pelanggaran hukuman kontrak. Tapi saya tidak berpikir ada masalah hukum dengan kehilangan kode itu sendiri.

Ini tidak berarti bahwa itu bukan bencana mutlak bagi perusahaan. Tapi ini adalah bencana keuangan; bukan yang legal. Saya mungkin akan mulai dengan istilah "ketidakmampuan kotor" dan mulai bekerja dari sana.


-1: "Saya tidak berpikir mereka dalam masalah" Mereka tidak dapat memperbaiki bug, menambal, atau membuat perubahan ketika Microsoft "meningkatkan" sistem operasi. Mereka benar-benar ditakdirkan untuk basis pelanggan yang semakin menipis dan satu-satunya penjualan baru adalah menyelesaikan orang-orang bodoh. (Populasi bukan nol, tetapi satu tanpa banyak uang untuk dibelanjakan pada sfotware.)
S.Lott

@ S.Lott: Apa yang lebih penting, mereka bahkan tidak bisa mengkompilasi ulang. Jika ada perubahan di lingkungan pelanggan, perangkat lunak tidak akan berfungsi.
David Thornley

1

Sejujurnya, saya pikir itu tergantung pada bahasa yang digunakan. Jika Anda kehilangan basis kode C #, itu bisa didekompilasi dengan sangat mudah, tetapi jika Anda kehilangan basis kode C ++, itu jauh lebih buruk.


Didekompilasi ke titik di mana ia masih bisa dibangun dan dijalankan, tetapi apakah itu masih dapat dipertahankan?
Jay

3
Jika Anda mengikuti praktik pengkodean yang baik, maka tentu saja, ya . Semua nama metode dan bidang dipertahankan, bahkan yang pribadi. Jika metode pendek, maka tujuan variabel lokal harus jelas. Trik kompiler seperti metode anonim dan iterator mungkin terlihat menakutkan, tetapi dapat dibalik (jika perlu) dengan beberapa pekerjaan. Dan bahkan jika perakitan itu dikaburkan, masih harus ada versi debug berbaring di suatu tempat .
Catatan untuk diri sendiri - pikirkan nama

Kecuali jika satu-satunya kode yang Anda miliki dikaburkan, dalam hal ini akan sedikit sakit.
MIA

1

Jika kabar itu keluar, yah, vendor mana pun yang bisa kehilangan kode sumbernya dengan cara apa pun selain bencana yang cukup luas jelas tidak mengikuti apa pun seperti praktik pengembangan yang baik, dan tidak bisa dipercaya. Saya akan menganggap itu sebagai bukti prima facie yang sangat kuat tentang ketidakmampuan perusahaan.

Bagaimana dengan "kebodohan luar biasa"?


0

Saya akan menyamakannya dengan pekerjaan lain yang membutuhkan konstruksi suatu barang. Mungkin sesuatu yang fisik. mis. Jika seorang arsitek kehilangan rencana untuk bangunan yang dibangun; Jika sebuah perusahaan mobil kehilangan rencana untuk sebuah model mobil; Jika penjahit kehilangan pola pakaian yang mereka buat; dll.

Ada banyak pekerjaan yang memiliki perbandingan fisik untuk disamakan dengan membuat perangkat lunak.


Kecuali bahwa rencana biasanya tidak sepenting itu. Jika arsitek kehilangan rencana, yang lain masih bisa mengawasi perubahan pada bangunan. Jika sebuah perusahaan mobil kehilangan rencana, mobilnya masih dapat dikendarai di jalan dengan trotoar yang baru dikembangkan. Jika saya kehilangan kode sumber, saya tidak dapat mengubah program dengan cara yang signifikan, dan saya tidak dapat mengkompilasi ulang untuk menjalankannya pada sistem operasi baru atau dengan versi perpustakaan yang lebih baru.
David Thornley

@ David: Saya pikir Anda tidak mengerti analogi saya. Jika seorang arsitek kehilangan rencana ke sebuah bangunan, ia harus membuat kembali rencana untuk membangun yang baru. Saya juga tidak melihat bagaimana arsitek lain dapat mengawasi perubahan pada sebuah bangunan jika mereka tidak berencana untuk melakukannya. Anda, benar-benar salah menerapkan analogi mobil. Meskipun, Anda memang menunjukkan bahwa itu sedikit paralel yang lemah pula.
frogstarr78

@ frogstarr78: Layak untuk membuat perubahan pada bangunan tanpa rencana semula. Ada sebuah bangunan di sana yang bisa diamati. Membangun gedung baru mungkin akan membutuhkan rencana baru, meskipun mereka dapat didasarkan pada yang lama. Rencana untuk model mobil hanya akan diperlukan untuk satu model tahun; setelah itu, mungkin untuk memeriksa mobil untuk informasi yang diperlukan. Kehilangan rencana ke objek fisik tidak baik, tetapi itu tidak mempengaruhi kegunaan hampir sebanyak kehilangan kode sumber.
David Thornley

@ David: Saya tidak setuju.
frogstarr78

@ David: Kedengarannya bagi saya seperti Anda membandingkan penyusunan ulang rencana untuk rumah, atau mobil, sesederhana melihat program yang sedang berjalan, dan mampu mengubahnya. Jika program ini dikompilasi (dan ya cukup lintas platform), atau mobil sudah dibangun, atau rumah sudah dibangun, Anda dapat menggunakan semuanya. Namun, ketika Anda perlu mengubah salah satu dari hal-hal ini (seperti yang saya katakan mobil adalah contoh paling minggu di sini), Anda perlu rencana untuk melakukannya. Saya tidak mengatakan contoh-contoh ini sempurna, tetapi mereka meletakkan konsep itu dalam bidang sesuatu yang fisik dan akrab bagi kebanyakan orang.
frogstarr78

0

Saya pikir terlepas dari opsi untuk mendekompilasi kode, ini akan menjadi masalah yang cukup besar dengan asumsi perusahaan bermaksud untuk terus memasarkan produk perangkat lunak. Jika itu adalah aplikasi in-house, hal yang sama akan berlaku pada tingkat yang lebih rendah.

Jika Anda tidak dapat mengembalikan kode sumber maka perawatan (perbaikan bug) dan peningkatan tidak dapat dilakukan sehingga aplikasi sekarang statis. Jika Microsoft atau Apple atau Apache atau siapa pun platform operasi Anda mengubah atau meningkatkan kodenya, maka kode kompilasi lama Anda mungkin tidak berfungsi dan Anda tidak dapat memperbaikinya. Jika Anda menjual aplikasi ini ke klien eksternal, Anda tidak dapat mengontrol kapan mereka akan memutakhirkan Windows, MAC OSX, iPhone, Browser Web Anda sehingga Anda memiliki risiko yang cukup besar di sini untuk reputasi perusahaan Anda dan kemungkinan risiko hukum juga jika Anda memiliki kontrak pemeliharaan dengan klien.

Kedua, kode sumber mewakili aset bagi perusahaan. Jadi untuk perusahaan perangkat lunak itu adalah aset di buku. Ini adalah sesuatu yang dapat Anda jual sebagai produk atau menjual kode sumber dan semua hak kepada perusahaan perangkat lunak lain. Saya tidak akan terus menjual produk perangkat lunak kepada klien yang saya tahu tidak dapat saya pertahankan karena saya kehilangan kode sumbernya. Lebih lanjut saya ragu perusahaan perangkat lunak lain akan membeli aplikasi dan semua hak jika mereka tidak dapat mengembangkan produk lebih lanjut. Jadi nilai aset aplikasi ini harus dikurangi.

Untuk aplikasi internal internal, Anda mungkin memiliki kontrol lebih besar atas platform operasi untuk aplikasi Anda, tetapi saya masih akan mencari untuk mengganti aplikasi ini jika kode sumber tidak dapat didekompilasi menjadi basis kode yang dapat digunakan untuk pemeliharaan.

Bersulang,

Kevin

PS Saya harap ini hanya pertanyaan teoretis ... :)


-1

Jika mereka tidak harus memperbaiki bug, maka itu mungkin bukan masalah besar. Misalnya, jika perusahaan membuat kontrol ActiveX khusus, dan mereka kehilangan sumber ke salah satu produk lawas mereka, lalu siapa yang benar-benar peduli? Produk mungkin tidak dipelihara secara aktif, dan kemungkinan juga tidak dipasarkan secara agresif. Mereka akan menjualnya selama orang masih menggunakan ActiveX 32-bit, dan kemudian melupakannya.

Karena itu, saya masih akan mengklasifikasikannya sebagai kelalaian. Jelas tidak ada sistem manajemen kode sumber di tempat, yang merupakan ketidakmampuan profesional untuk rumah perangkat lunak.


-1: "Jika mereka tidak harus memperbaiki bug" Tingkat kesempurnaan yang patut ditiru. Siapa yang punya perangkat lunak sebaik itu? Siapa saja?
S.Lott

1
"Tidak harus memperbaiki bug"! = "Tidak ada bug". Banyak perusahaan terus menjual perangkat lunak EOL'd dengan daftar bug yang diketahui yang tidak ingin mereka perbaiki. Seperti driver USB untuk Win98 - mereka ada di luar sana, mereka mungkin tidak sempurna, tapi saya ragu ada yang menerapkan perbaikan bug.
TMN
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.