Kaynak kodunu kaybetmek ne kadar ciddi? [kapalı]


9

Bir yazılım şirketi sattıkları ürünlerden birine kaynak kodunu kaybederse, bir meslekten olmayanlara ne kadar ciddi bir açıklama yapabilirdiniz? "Ağır ihmal" terimi çok güçlü olur mu? Veya "kaba yetersizlik"? Açıkçası hiç kimse öldürülmedi, ancak insanların hapse girmesi bazı finansal ihmaller kadar ciddi değil mi?

EDIT: Diyelim ki bir disk sürücüsü çökmesi, doğal afet ya da bunun gibi bir durum söz konusu değil. Sadece yanlış yerleştirdiler.


37
Bu sorunun arkasında bir hikaye var ve bunu duymak istiyorum. Günlük WTF'de görünmesini bekleyeceğim.
BlairHippo

4
@Josh K - Kötü benzetme! Bir çocuk değiştirilemez. Kaynak kodu olabilir. (ve source_code == kid olduğunu düşünüyorsanız ciddi şekilde sarsılıyorum). Ama sanırım (henüz) bir tane yok.
Kale

6
@Rook: Neden kötü bir benzetme? Kaynak kodu tam olarak değiştirilemez, sadece benzer şekilde çoğaltılabilir. Bu bir çocuğu kaybetmek kadar aşırı değil, ama benzetme hala sağlam.
Josh K

6
@Rook: Birinin (çocuklar) kaynak kodundan çok daha önemli olmasına rağmen, her ikisine de sahip olmak hala çok değerli. Analojimi işten çıkarıyorsunuz çünkü çocuklar kaynak kodundan daha önemliyken Yahoo! çünkü Google çok daha büyük. Demek istediğim, her ikisinin de çok büyük olması, birisinin diğerinden anlamlı / önemli olduğu kadar ~ 10x olması önemli değil. Ne söyleyeyim, şirketinizin ana uygulaması için depoyu (ve kodun tüm kopyalarını) kaybedip 5-10'da bana geri dönün.
Josh K

5
İlk etapta "yanlış yerleştirilecek" tek bir kopya nasıl olabilir anlamıyorum? Genellikle en az iki veya üç kopyasını var kendim düzeltmeleri, güncellemeler ve ben üzerinde çalışıyorum o yamalar çeşitli aşamalarında. Meslektaşlarımın kendi kopyaları olurdu. En kötüsü, kaynak deponuzdaki geçmişi kaybedebilirsiniz (yedeklemesiz merkezi bir depo kullanıyorsanız) ... Bunun nasıl mümkün olduğunu görmüyorum ...
Dean Harding

Yanıtlar:


27

Diyelim ki MS, Windows Phone 7'nin kaynağını kaybediyor ... insanlar, waaaaay için, geliştirilmesinin maliyeti 400 milyon dolardan az bir şekilde öldürüldü .

Ürüne bağlı olarak, bunun 'çok güçlü' olduğunu düşünebileceğim bir terim yok.


1
Yazılım satıyorlarsa ve bunun için kaynak kodları yoksa, evet, yetersizdir. Bununla birlikte, özel bir yazılım geliştiricisi olarak, geliştirmelerini dışarıdan tedarik eden ve sattıkları yazılımın kaynak kodunun oluşturulabilir kopyalarına sahip olmayan, programcı olmayan kişiler tarafından işletilen küçük şirketlerle ne sıklıkta karşılaştığım şaşırtıcı.
Bob Murphy

1
Bunu yapan sadece küçük şirketler değil. Danışmanlık firmam eskiden Oracle için uygun bir rakip olan Informix için çok çalışıyordu. Projelerimizden birini bir Hintli dış kaynak firmasına kaydırmaya karar verdiler ve bir gün müdür bizi çağırdı: "Bize kaynak göndermedin!" "Evet yaptık, X tarihindeydi (yaklaşık bir yıl önce) ve işte FedEx takip numarası. Kaybettin mi?" "Hayır tabii değil." "Eğer yaptıysanız sorun değil, çünkü arşivlerimizden alabiliriz, ama bir ücret olacak." "Hayır, rahatsız etme." Sonradan öğrendik ki gerçekten kaybetmişlerdi.
Bob Murphy

18

Bir şirket için bu taç mücevherlerini kaybetmek gibidir. Gömülü işlemcili bir ürünse, ürünü "olduğu gibi" yapmaya devam edebilirler, ancak geliştirme veya herhangi bir sorunu çözme yeteneğini kaybederler.

Bugünün pazarlarda bir şirket IS 's IP. Kaybetmek ve iş biter.


13

Diğerlerinin de belirttiği gibi, bu büyük olasılıkla "her şeye bağlıdır" başlığı altına girer, bu yüzden birkaç senaryo:

Disk tabanlı, konsollu bir video oyunu için kaynak - Diske yazıldıktan sonra oyunda herhangi bir değişiklik yapma eğiliminde olmadıkları için şirket üzerinde çok az etkisi olacaktır. Yeniden geliştirmek zorunda oldukları kütüphane kodları varsa zaman kaybedebilirler, o kadar da kötü olmaz.

İndirilebilir bir video oyunu kaynağı - Müşteriler büyük olasılıkla hataların yamalacağını bekleyeceklerinden, bu durum kötü olacaktır çünkü bunu yapmamak müşterilerin gelecekteki sürümleri olumsuz etkileyebilecek şirkete olan inancını kaybetmelerine neden olabilir.

Geliştirilmekte olan bir oyunun kaynağı - Çoğu video oyunu şirketi, geliştirme döngüsünde (yani günler, belki de haftalar içinde) çok erken olmadığı sürece şu anda geliştirilmekte olan bir oyunun kodunu kaybetmeyi göze alamaz. amiral gemilerinin serbest bırakılması işlerini bitirmelerine neden olabilir.

Sınırlı sürüm izleyicisine sahip küçük bir işletme uygulaması için kaynak - Birkaç müşteri kaybedebilmelerine rağmen, şirket için herhangi bir soruna neden olma olasılığı düşüktür .

Sınırlı sürüm izleyici ile büyük bir iş uygulaması için kaynak - Müşterilerinin inanç kaybı nedeniyle şirketin işten çıkmasına neden olabileceği başka bir durum. Çoğu küçük pazarda bile, birden fazla şirket faaliyet göstermektedir ve bu durum, işletmenin bir rakibe geçmesi için yeterli olabilir.

Büyük bir şirketten büyük bir uygulama için kaynak - Burada her şey gerçekten çok bağlıdır ve büyük olasılıkla duruma göre çok dar bir temelde olacaktır. Amiral gemisi ürünleri (örneğin Microsoft Windows) genellikle kendileriyle ilişkili destek sözleşmelerine sahiptir ve ürünü destekleyememek, sözleşme davalarının ihlaline neden olabilir. Bir tahmin vermek zorunda kalsaydım, bu insanların üst düzey liderliğine kadar olan kod kaybına karışan insanların çoğunun yeni bir iş araması gerekebilir.

Yine de, yönetim kurulu genelinde, kodu kaybeden kişinin yeni bir iş aradığını söyleyebilirim (ve bir tane bulmak zor olabilir!) Ve ayrıca şirketten davalarla karşı karşıya kalabilirler.


Bir sonraki oyunu geliştirirken daha önce yayınlanmış bir oyunun kaynak kodunun büyük bölümlerini yeniden kullanmak yaygındır - özellikle de devam filmini geliştirirken. Bununla birlikte, oyun stüdyolarının nispeten kısa ömürleri göz önüne alındığında, son yıllarda oyun kaynaklarındaki kayıpları duymak nadir değildir.
çalışması devam ediyor

3

Kesinlikle felaket olabileceği durumlar olsa da, bence olmadığı yerde çok var (en azından yazılım şirketinin bakış açısından).

Herhangi bir yasal yansıma olup olmadığına dair kapsamlı bir cevap vermek için çok fazla değişken olduğunu düşünüyorum, ancak aşağıdakileri belirlerken dikkate alınması gereken birkaç soru:

  • Programın doğası nedir? Eğer kaybettikleri bir şeyse, bunun gibi uygulamalar bir düzine düzine ve önemli değil , ne olacak? Şirketin en önemli ticari ürünü ise, sadece kendilerine gerçekten zarar verdiler. Yapmaları için sözleşmeli özel yazılımlarsa, ilginç olabilecekleri yer burası, ancak sormanız gerekenler ...
  • Kodun telif hakkına kim sahipti? (Müşteri telif hakkına sahipse, mülkü tartışmalı olarak kaybolmuştur / yok edilmiştir)
  • Müşteri kodun kaybolması nedeniyle aktif olarak zarar görüyor mu?
  • Kodun kaybolması sonucunda gelecekteki gelişimine ilişkin sözleşmeler yapıldı mı?
  • Mevcut yazılımı yeniden oluşturabilmek ne kadar önemli? Bakım görevleri yapmak bir kabuk betiği gibi bir şeyse, yazılım şirketi aynı şeyleri yapan yeni bir tane yapmak için gereken zamanı yiyor. Bu bir ofis paketi ise, özgeçmiş tozunu.

Ve eminim ki dikkate alınması gereken birçok başka faktör var. Eklemek için çekinmeyin.

Şimdi, "yazılım şirketi açısından" dedim. Değişiklikler, geliştirmeler ya da başka bir şey için yaptıkları planlar nedeniyle müşterinin zihninde hala felaket olabilir. Bununla birlikte, bu tür şeyler veya telif hakkının mülkiyeti için yapılan bir sözleşme, müşteriye ciddi bir şekilde öfkelenebilir, ancak iyi müşteri ilişkilerini sürdürmek için ellerinden geleni yapmanın yanı sıra geliştiricinin herhangi bir yükümlülüğü olmadan.


Ve "müşterinin bakış açısı" bitini daha da genişletmek için, ele aldığım şey, sorunun ardındaki hikayenin ne olduğunu bilmiyorum, ancak müşterinin, sahip olduklarını düşünmesi duyulmayacaktır. müşteri dağıtımdan bu yana üç yıl içinde herhangi bir değişiklik ya da ek iş istemediğinde geliştirici kodun bir "atmak" olduğunu düşünürken kaynak kodunun Fort Knox gibi korunmasını bekleme hakkı.
Blumer

Bir müşteriyi ciddi şekilde kızdıran şeyleri yapmanın da sözleşmenin ihlali olabileceğini ve yasal olarak işlem yapılabileceğini unutmayın. Ayrıca müşterinin aleni şikâyet etmesine de neden olabilir.
David Thornley

3

Ah, sizden bu açıklama verildiğinde (yorumlarda):

Uzun zaman önce geliştirildi, kaynak kontrolü olmadan, tüm bunları satıyorlardı ve şimdi aniden güncellemeleri gerekiyor

Gelen bu özel durumu , muhtemelen dünyanın sonu değil söyleyebilirim. Kaynak koduna ihtiyaç duymadan yazılımı yıllardır sattıkları göz önüne alındığında, bu müşteriye güncellemeyi isteyen "müşteriye yapamayacağım özür dilerim" diyebilirsiniz.

Şimdi beni yanlış anlamayın, kodu kaybetmek iyi değildir. Şirketinizin orijinal sürümü yeniden yazması veya tersine mühendislik yapması çok pahalı olacaktır (yapmaya karar verdiyse). Ama bu dünyanın sonu değil. Açıkçası bu uzun süre koda ihtiyaç duymadan hayatta kaldılar, bu yüzden muhtemelen onsuz hayatta kalmaya devam ediyorlar.

Bu, elbette, sattıkları yazılımın işlerinin sadece küçük bir kısmı olduğunu varsayar. Sanırım durum böyle olmalı ...


Evet, sattıkları birçok üründen sadece biri
JoelFan

Sadece 1 müşteri değil ... işletim sisteminin en son sürümünde artık çalışmayacak
JoelFan

1

Ürünü hala satabildikleri sürece, başlarının belada olduğunu sanmıyorum. Şimdi, bir müşteriye ürünü genişletmek ve bir sonraki sürümde bazı yeni özellikler sağlamak için sözleşme yapılıyorsa, bu çok daha ciddi çünkü sözleşme cezalarını ihlal etmek için onları kuruyor. Ancak kodun kendisini kaybetmeyle ilgili yasal bir sorun olduğunu düşünmüyorum.

Bu , şirket için mutlak bir felaket olmadığı anlamına gelmez . Ama bu bir finansal felaket; yasal değil. Muhtemelen "kaba beceriksizlik" terimiyle başlayıp oradan yukarı çıkarım.


-1: "Sorun yaşadıklarını sanmıyorum" Microsoft işletim sistemini "yükselttiğinde" hata düzeltme, düzeltme eki veya değişiklik yapamazlar. Tamamen hızla azalan bir müşteri tabanına mahkumlar ve sadece yeni satışlar salakları tamamlamak olacak. (Sıfır olmayan bir popülasyon, ancak sfotware için harcayacak çok parası olmayan biri.)
S.Lott

@ S.Lott: Daha önemli ne olabilir, yeniden derleyemezler. Müşterinin ortamında herhangi bir değişiklik olursa, yazılım çalışmaz.
David Thornley

1

Dürüst olmak gerekirse, bence kullanılan dile bağlı. Bir C # kod tabanını kaybederseniz, son derece kolay bir şekilde ayrıştırılabilir, ancak bir C ++ kod tabanını kaybederseniz, bu çok daha kötüdür.


Hala inşa edilebildiği ve çalıştırılabileceği noktaya ayrıştırıldı, ancak yine de korunabilir mi?
Jay

3
İyi kodlama pratiğini izlediyseniz, elbette, evet . Tüm yöntem ve alan adları, özel olanlar bile korunur. Yöntemler kısaysa, yerel değişkenlerin amacı açık olmalıdır. Anonim yöntemler ve yineleyiciler gibi derleyici hileleri korkutucu görünebilir, ancak bazı çalışmalarla tersine çevrilebilir. Ve meclis gizlenmiş olsa bile, hala bir yere yerleştirilmiş bir hata ayıklama versiyonu olmalı .
Kendine not -

Sahip olduğunuz tek kod gizlenmedikçe, bu durumda biraz acı çekecektir.
MIA

1

Eğer bu kelime ortaya çıkarsa, kaynak kodunu oldukça yaygın bir felaket dışında herhangi bir yolla kaybedebilecek herhangi bir tedarikçi, açıkça ses geliştirme uygulamaları gibi bir şey izlemiyor ve güvenilmeyecek. Bunu gayet güçlü kurumsal yetersizliğin çok güçlü bir prima facie kanıtı olarak görüyorum.

"İnanılmaz aptallık" nasıl olur?


0

Bir öğenin yapımını gerektiren diğer işlere benzetirim. Muhtemelen fiziksel bir şey. Örneğin bir mimar inşa edilmiş bir bina için planlarını kaybetmişse; Bir otomobil şirketi bir otomobil modeli için planlarını kaybetmişse; Eğer bir terzi yapmış oldukları bir kıyafetin şeklini kaybetmişse; vb.

Yazılım oluşturmaya benzetmek için fiziksel karşılaştırmalar yapan birçok iş var.


Ancak planlar genellikle o kadar önemli değildir. Mimar planları kaybederse, bir başkası hala binadaki değişiklikleri denetleyebilir. Bir otomobil şirketi planlarını kaybederse, arabaları yeni geliştirilen kaldırımla yollarda sürülebilir. Kaynak kodunu kaybedersem, programı önemli bir şekilde değiştiremiyorum ve yeni bir işletim sisteminde veya kitaplığın daha yeni bir sürümünde çalışmasını sağlamak için yeniden derleyemiyorum.
David Thornley

@David: Analojimi anladığınızı sanmıyorum. Bir mimar planları bir binaya kaybederse, yeni bir bina inşa etmek için planları yeniden yapmak zorundadır. Ayrıca, başka bir mimarın binadan çıkmayı planlamamışsa değişiklikleri nasıl denetleyebileceğini de görmüyorum. Siz, otomobil benzetmesini tamamen yanlış kullandınız. Yine de, bunun zayıf bir paralellik olduğuna işaret ettiniz.
frogstarr78

@ frogstarr78: Orijinal planlar olmadan bir binada değişiklik yapmak mümkündür. Orada gözlemlenebilecek bir bina var. Yeni bir bina inşa etmek eski planlara dayanabilmelerine rağmen muhtemelen yeni planlar gerektirecektir. Bir araba modeli için planlar sadece bir model yılı için gerekli olacaktır; bundan sonra, gerekli bilgi için arabayı incelemek mümkündür. Fiziksel nesnelere plan kaybetmek iyi değildir, ancak kullanılabilirliği neredeyse kaynak kodunu kaybetmek kadar etkilemez.
David Thornley

@David: Kabul etmiyorum.
frogstarr78

@David: Bana, bir ev veya araba için planların yeniden çizimini, çalışan bir programı görmek ve değiştirebilmeniz kadar basit karşılaştırmak gibi geliyor. Program derlenmişse (ve evet oldukça platformlar arası uyumluysa) veya bir araba zaten oluşturulmuşsa veya zaten bir ev inşa edilmişse, hepsini kullanabilirsiniz. Ancak, bunlardan herhangi birini değiştirmeniz gerektiğinde (arabanın burada en haftalık örnek olduğunu söylediğim gibi), bunu yapmak için planlara ihtiyacınız olacak. Bu örneklerin mükemmel olduğunu söylemiyorum, ancak konsepti çoğu insan için fiziksel ve tanıdık bir şeyin alanına koyuyorlar.
frogstarr78

0

Kodun ayrıştırılması seçeneğinin yanı sıra, şirketin yazılım ürününü pazarlamaya devam etmeyi amaçladığı varsayılarak oldukça büyük bir sorun olacağını düşünüyorum. Şirket içi bir uygulama olsaydı aynı şey daha az derecede doğrudur.

Kaynak kodu geri yükleyemiyorsanız, uygulama şimdi statik olması için bakım (hata düzeltme) ve geliştirmeler gerçekleştirilemez. Microsoft veya Apple veya Apache veya işletim platformunuz kim olursa olsun kodlarını değiştirir veya yükseltirse, eski derlenmiş kodunuz çalışmayabilir ve düzeltemezsiniz. Bu uygulamayı harici istemcilere satıyorsanız, Windows, MAC OSX, iPhone, Web Tarayıcılarını ne zaman yükselteceklerini kontrol edemezsiniz, böylece şirketinizin itibarı için oldukça büyük bir risk ve bir bakım sözleşmeniz varsa muhtemelen yasal riskiniz vardır. müşterileri ile.

İkinci olarak kaynak kodu şirket için bir varlıktır. Yani bir yazılım şirketi için bu kitaplar üzerinde bir varlıktır. Bir ürün olarak satabileceğiniz veya kaynak kodu ve tüm hakları başka bir yazılım şirketine satabileceğiniz bir şeydir. Kaynak kodunu kaybettiğimden koruyamadığımı bildiğim müşterilere bir yazılım ürünü satmaya devam etmem. Ayrıca, ürünü daha fazla geliştiremezlerse başka bir yazılım şirketinin uygulamayı ve tüm hakları satın alacağından şüpheliyim. Bu nedenle, bu uygulamanın varlık değeri azaltılmalıdır.

Dahili bir şirket içi uygulama için, uygulamanız için işletim platformu üzerinde daha fazla kontrole sahip olabilirsiniz, ancak yine de kaynak kodu bakım için kullanılabilir bir kod tabanına ayrıştırılamazsa bu uygulamayı değiştirmeye çalışırım.

Alkış,

Kevin

PS: Umarım bu sadece teorik bir soru ... :)


-1

Eğer herhangi bir hatayı düzeltmeleri gerekmiyorsa, büyük olasılıkla bu kadar büyük bir anlaşma değildir. Örneğin, şirket özel ActiveX denetimleri yaparsa ve eski ürünlerinden birinin kaynağını kaybederse, gerçekten kimin umurunda? Ürün muhtemelen aktif olarak korunmuyor ve muhtemelen agresif bir şekilde pazarlanmıyor. İnsanlar hala 32-bit ActiveX kullandıkları sürece satarlar ve unuturlar.

Bununla birlikte, onu hala büyük bir ihmal olarak sınıflandırırdım. Açıkçası, bir yazılım evi için profesyonel yetersizlik olan hiçbir kaynak kodu yönetim sistemi yoktur.


-1: "Eğer herhangi bir hata düzeltmek zorunda değilsiniz" Ne kıskanılacak bir mükemmellik seviyesi. Kim bu kadar iyi bir yazılıma sahip? Kimse?
S.Lott

1
"Hataları düzeltmek zorunda değilsiniz"! = "Hata yok". Birçok şirket, tamir etme niyetinde olmadıkları bilinen hataların bir listesi ile EOL'd yazılımını satmaya devam ediyor. Win98 için bir USB sürücüsü gibi - oradalar, muhtemelen mükemmel değiller, ancak herkesin hata düzeltmeleri uyguladığından şüpheliyim.
TMN
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.