Jak poważna jest utrata kodu źródłowego? [Zamknięte]


9

Jeśli firma programistyczna traci kod źródłowy jednego z produktów, które sprzedaje, jak poważnie by to było, pod względem, który można wyjaśnić laikowi? Czy termin „rażące zaniedbanie” byłby zbyt silny? A może „rażąca niekompetencja”? Oczywiście nikt nie zginął, ale czy nie jest to tak poważne, jak jakieś finansowe zaniedbanie, za które ludzie dostają więzienie?

EDYCJA: Powiedzmy, że nie chodzi o awarię dysku, katastrofę naturalną lub coś podobnego. Po prostu zgubili to.


37
Za tym pytaniem kryje się historia, więc bardzo chcę ją usłyszeć. Poczekam, aż pojawi się na Daily WTF.
BlairHippo

4
@Josh K - Zła analogia! Dzieciaka nie można zastąpić. Kod źródłowy może. (i jestem poważnie wstrząśnięty, jeśli myślisz, że kod_źródłowy == dziecko). Ale zgaduję, że nie masz (jeszcze).
Rook

6
@Rook: Dlaczego to zła analogia? Kodu źródłowego nie można dokładnie zastąpić, można go replikować tylko w podobny sposób. To prawda, że ​​nie jest to tak ekstremalne jak utrata dziecka, ale podobieństwo jest nadal solidne.
Josh K

6
@Rook: Nie rozumiesz, że chociaż jedno (dzieci) jest oczywiście o wiele ważniejsze niż kod źródłowy, posiadanie obu jest wciąż bardzo cenne. Odrzucasz moją analogię, ponieważ dzieci są ważniejsze, niż kod źródłowy byłby jak odrzucenie Yahoo! jako firma wyszukiwania, ponieważ Google jest o wiele większy. Chodzi mi o to, że oba są ogromne, fakt, że jedno jest ~ 10 razy tak znaczące / ważne, a drugie nie ma znaczenia. Wiesz co, stracisz repozytorium (i wszystkie kopie kodu) dla głównej aplikacji twojej firmy i wrócisz do mnie w 5-10.
Josh K

5
Nie rozumiem, w jaki sposób może być tylko jedna kopia, która może zostać „zgubiona”? I zazwyczaj mają co najmniej dwa lub trzy kopie sobie w różnych stadiach poprawki, aktualizacje i łatki, że ja pracuję. Moi koledzy mieliby własne kopie. W najgorszym wypadku możesz stracić historię w swoim repozytorium źródłowym (jeśli używasz centralnego repozytorium bez kopii zapasowych) ... Po prostu nie rozumiem, jak to możliwe ...
Dean Harding

Odpowiedzi:


27

Powiedzmy, że stwardnienie rozsiane traci źródło dla Windows Phone 7 ... ludzie zostali zabici za waaaaaa, mniej niż szacowane 400 milionów dolarów, które kosztowało opracowanie.

W zależności od produktu nie ma takiego określenia, które mogłoby być „zbyt mocne”.


1
Jeśli sprzedają oprogramowanie i nie mają kodu źródłowego, tak, jest niekompetentny. Jednak jako twórca oprogramowania niestandardowego zdumiewające jest to, jak często natrafiam na małe firmy prowadzone przez nie-programistów, którzy zlecili ich programowanie, a nawet nie mieli możliwych do zbudowania kopii kodu źródłowego oprogramowania, które sprzedawali.
Bob Murphy

1
I robią to nie tylko małe firmy. Moja firma konsultingowa wykonywała wiele pracy dla firmy Informix, która w tamtych czasach była konkurencyjnym konkurentem dla Oracle. Postanowili przenieść jeden z naszych projektów do indyjskiej firmy outsourcingowej i pewnego dnia kierownik zadzwonił do nas: „Nie wysłałeś nam źródła!” „Tak, zrobiliśmy to, było w dniu X (około rok wcześniej), a oto numer śledzenia FedEx. Zgubiłeś go?” "Nie, oczywiście nie." „Jeśli tak, to w porządku, ponieważ możemy odzyskać go z naszych archiwów, ale będzie opłata”. „Nie, nie przejmuj się”. Dowiedzieliśmy się później, że rzeczywiście go zgubili.
Bob Murphy

18

Dla firmy jest to jak utrata klejnotów koronnych. Jeśli jest to produkt z wbudowanym procesorem, mogą kontynuować tworzenie produktu „takim, jakim jest”, ale tracą możliwość jego ulepszenia lub rozwiązania jakichkolwiek problemów.

Na dzisiejszych rynkach firma JEST to IP. Stracić to i przestaje działać.


13

Jak zauważyli inni, prawdopodobnie mieści się to w rubryce „wszystko zależy”, więc kilka senarios:

Źródło gry wideo na konsolę na dyskach - prawdopodobnie nie miałoby to większego wpływu na firmę, ponieważ zwykle nie wprowadzają żadnych zmian w grze po jej wypaleniu na dysk. To prawda, że ​​mogą stracić trochę czasu, jeśli istnieje kod biblioteki, który muszą przebudować, nie byłoby tak źle.

Źródło gry wideo do pobrania - prawdopodobnie byłoby to złe, ponieważ klienci prawdopodobnie będą oczekiwać, że błędy zostaną załatane, ponieważ brak możliwości może spowodować, że klienci stracą wiarę w firmę, co może mieć negatywny wpływ na przyszłe wydania.

Źródło gry w fazie rozwoju - większość firm z branży gier wideo nie może sobie pozwolić na utratę kodu dla gry, która jest obecnie opracowywana, chyba że jest to wyjątkowo wczesny etap cyklu rozwoju (tj. Dni, a może tygodnie). ponieważ ich flagowe wydanie może spowodować, że przestaną działać.

Źródło aplikacji dla małych firm z ograniczoną liczbą odbiorców - prawdopodobnie nie spowoduje żadnych problemów dla firmy, chociaż mogą stracić kilku klientów.

Źródło dla dużej aplikacji biznesowej z ograniczoną liczbą odbiorców - kolejna sytuacja, w której może ona spowodować, że firma przestanie działać z powodu utraty wiary od klientów. Nawet na większości małych rynków działa zwykle więcej niż jedna firma i może to wystarczyć, aby firma mogła przejść do konkurencji.

Źródło dla dużej aplikacji z dużej firmy - tutaj naprawdę wszystko zależy i prawdopodobnie byłoby bardzo wąskie, w poszczególnych przypadkach. Produkty flagowe (np. Microsoft Windows) zazwyczaj wiążą się z umowami o pomoc techniczną, a brak możliwości wsparcia produktu może prowadzić do naruszenia procedur sądowych. Gdybym miał podać szacunek, powiedziałbym, że większość osób zaangażowanych w utratę kodu aż do kierownictwa tych osób może potrzebować poszukiwania nowej pracy.

Ogólnie rzecz biorąc, prawdopodobnie powiedziałbym, że osoba, która zgubiła kod, szukałaby nowej pracy (i może mieć trudności z jej znalezieniem!), A także może stanąć w obliczu procesów sądowych z firmy.


Powszechne jest ponowne wykorzystywanie dużych części kodu źródłowego poprzednio wydanej gry podczas opracowywania kolejnej gry - szczególnie podczas opracowywania jej kontynuacji. Jednak biorąc pod uwagę stosunkowo krótkie okresy studiów gier, nierzadko można było usłyszeć o stratach źródeł gier w ciągu ostatnich dziesięcioleci.
wytrzyj

3

Chociaż z pewnością istnieją przypadki, w których może to być kataklizm, myślę, że jest ich wiele (przynajmniej z punktu widzenia firmy produkującej oprogramowanie).

Myślę, że jest zbyt wiele zmiennych, aby dać ogólną odpowiedź na pytanie, czy są jakieś reperkusje prawne, ale garść pytań do rozważenia przy określaniu, które obejmowałyby:

  • Jaki jest charakter programu? Jeśli coś stracili, bo takie aplikacje to dziesiątka i nie jest to ważne , co z tego? Jeśli jest to sztandarowy produkt komercyjny firmy, naprawdę tylko sobie wyrządzili krzywdę. Jeśli jest to oprogramowanie niestandardowe, na budowę którego zostało zlecone, może być interesujące, ale musisz zapytać ...
  • Kto był właścicielem praw autorskich do kodu? (Jeśli klient jest właścicielem praw autorskich, jego własność została prawdopodobnie utracona / zniszczona)
  • Czy zniknięcie kodu powoduje aktywną szkodę dla klienta?
  • Czy istniały umowy dotyczące przyszłego rozwoju, które zostaną naruszone w wyniku zniknięcia kodu?
  • Jak ważna jest możliwość odtworzenia istniejącego oprogramowania? Jeśli jest to coś w rodzaju skryptu powłoki do wykonywania zadań konserwacyjnych, firma programistyczna zużywa czas potrzebny na stworzenie nowego, który robi te same rzeczy. Jeśli jest to pakiet biurowy, odkurz CV.

I jestem pewien, że istnieje wiele innych czynników, które należy wziąć pod uwagę. Zapraszam do dodania.

Teraz powiedziałem „z perspektywy firmy produkującej oprogramowanie”. Klient może nadal mieć katastrofalne skutki ze względu na plany dotyczące zmian, udoskonaleń itp. Umowa na takie rzeczy lub własność praw autorskich może jednak poważnie rozgniewać klienta, ale bez żadnych zobowiązań ze strony dewelopera, oprócz robienia tego, co w jego mocy, aby utrzymać dobre relacje z klientami.


I aby dalej rozwinąć nieco „perspektywę klienta”, chodzi mi o to, że nie wiem, jaka jest historia tego pytania, ale klient nie pomyślałby, że ma prawo oczekiwać, że kod źródłowy będzie chroniony jak Fort Knox, podczas gdy deweloper uważa to za „wyrzucenie”, gdy klient nie poprosił o żadne modyfikacje ani dodatkowe prace w ciągu trzech lat od wdrożenia.
Blumer

Pamiętaj, że robienie rzeczy, które poważnie złościć klienta, mogą również stanowić naruszenie umowy i być prawnie uzasadnione. Może to również skutkować publicznym zażaleniem klienta.
David Thornley,

3

Ach, biorąc pod uwagę to wyjaśnienie od ciebie (w komentarzach):

Został opracowany dawno temu, bez kontroli źródła, sprzedawali go przez cały czas, a teraz nagle muszą go zaktualizować

W tej konkretnej sytuacji powiedziałbym, że to prawdopodobnie nie koniec świata. Biorąc pod uwagę, że sprzedają oprogramowanie od lat bez potrzeby używania kodu źródłowego, możesz po prostu powiedzieć temu klientowi, który prosi o aktualizację, „przepraszam, że nie można tego zrobić”.

Nie zrozum mnie źle, utrata kodu nie jest dobra. Ponowne napisanie lub ponowne zaprojektowanie oryginalnej wersji (jeśli zdecydują się to zrobić) będzie bardzo kosztowne dla Twojej firmy. Ale to nie koniec świata. Najwyraźniej przetrwali tak długo, nie potrzebując kodu, więc prawdopodobnie przetrwają bez niego.

Zakłada się oczywiście, że oprogramowanie, które sprzedają, to tylko niewielka część ich działalności. Zgaduję, że tak musi być ...


Tak, to tylko jeden z wielu produktów, które sprzedają
JoelFan

To nie tylko 1 klient ... nie będzie już działać w najnowszej wersji systemu operacyjnego
JoelFan

1

Dopóki są w stanie sprzedawać produkt, nie sądzę, aby mieli kłopoty. Teraz, jeśli mają umowę z klientem na rozszerzenie produktu i zapewnienie pewnych nowych funkcji w następnej wersji, jest to o wiele poważniejsze, ponieważ wiąże się to z naruszeniem kar umownych. Ale nie sądzę, że istnieje problem prawny z utratą samego kodu.

To nie znaczy, że nie jest to absolutna katastrofa dla firmy. Ale to katastrofa finansowa; nie legalny. Najprawdopodobniej zacznę od terminu „rażąca niekompetencja” i zacznę od tego.


-1: „Nie sądzę, aby mieli kłopoty”. Nie mogą naprawiać błędów, łatać ani wprowadzać zmian, gdy Microsoft „uaktualnia” system operacyjny. Są całkowicie skazani na szybko malejącą bazę klientów, a jedyną nową sprzedażą będzie dopełnianie idiotów. (Niezerowy populacja, ale bez dużo pieniędzy na sfotware.)
S.Lott

@ S.Lott: Co może być ważniejsze, nie mogą nawet dokonać ponownej kompilacji. Jeśli coś zmieni się w środowisku klienta, oprogramowanie nie będzie działać.
David Thornley

1

Szczerze mówiąc, myślę, że zależy to od używanego języka. Jeśli stracisz bazę kodu C #, można ją bardzo łatwo zdekompilować, ale jeśli stracisz bazę kodu C ++, jest to o wiele gorsze.


Zdekompilowany do tego stopnia, że ​​nadal można go budować i uruchamiać, ale czy nadal będzie można go utrzymać?
Jay

3
Jeśli przestrzegałeś dobrej praktyki kodowania, to na pewno, tak . Wszystkie nazwy metod i pól są zachowane, nawet te prywatne. Jeśli metody są krótkie, to cel zmiennych lokalnych powinien być oczywisty. Sztuczki kompilatora, takie jak anonimowe metody i iteratory, mogą wyglądać zastraszająco, ale można je odwrócić (w razie potrzeby) przy pewnej pracy. I nawet jeśli zestaw był zaciemniony, nadal powinna istnieć gdzieś wersja debugowania .
Uwaga dla siebie - wymyśl imię

Chyba że jedyny kod, który masz, jest zaciemniony, w takim przypadku będzie to niewielki ból.
MIA

1

Jeśli się o tym dowie, cóż, każdy sprzedawca, który mógłby stracić swój kod źródłowy w jakikolwiek inny sposób niż dość powszechna katastrofa, oczywiście nie postępuje zgodnie z praktykami rozwoju dźwięku i nie można mu ufać. Uważam to za bardzo silny dowód prima facie na rażącą niekompetencję korporacyjną.

Co powiesz na „niesamowitą głupotę”?


0

Porównałbym to do innych prac wymagających budowy przedmiotu. Prawdopodobnie coś fizycznego. np. jeśli architekt utracił plany budynku, który został zbudowany; Jeśli firma samochodowa straciła plany dotyczące modelu samochodu; Jeśli krawcowa straci wzór dla stworzonego przez siebie stroju; itp.

Istnieje wiele zadań, które mają fizyczne porównania, które można porównać do tworzenia oprogramowania.


Tyle że plany zwykle nie są tak ważne. Jeśli architekt straci plany, inny może nadal nadzorować zmiany w budynku. Jeśli firma samochodowa straci plany, jej samochody mogą nadal jeździć po drogach z nowo opracowaną nawierzchnią. Jeśli zgubię kod źródłowy, nie mogę zmienić programu w żaden znaczący sposób i nie mogę go ponownie skompilować, aby działał w nowym systemie operacyjnym lub w nowszej wersji biblioteki.
David Thornley,

@David: Nie sądzę, że zrozumiałeś moją analogię. Jeśli architekt straci plany na budynku, musi ponownie wykonać plany, aby zbudować nowy. Nie widzę też, jak inny architekt może nadzorować zmiany w budynku, jeśli nie planuje odejść. Całkowicie źle zastosowałeś analogię samochodową. Chociaż zauważyłeś, że i tak była to nieco słaba równoległość.
frogstarr78

@ frogstarr78: Możliwe jest wprowadzanie zmian w budynku bez oryginalnych planów. Jest tam budynek, który można obserwować. Budowa nowego budynku prawdopodobnie wymagałaby nowych planów, chociaż mogłyby być oparte na starych. Plany dotyczące modelu samochodu będą konieczne tylko na jeden rok modelowy; po tym można sprawdzić samochód w celu uzyskania niezbędnych informacji. Utrata planów na obiektach fizycznych nie jest dobra, ale nie wpływa tak bardzo na użyteczność, jak utrata kodu źródłowego.
David Thornley,

@David: Nie zgadzam się.
frogstarr78

@David: Wydaje mi się, że porównujesz ponowne rysowanie planów domu lub samochodu, tak proste jak obejrzenie działającego programu i możliwość jego zmiany. Jeśli program jest skompilowany (i tak jest zgodny z wieloma platformami), lub samochód jest już zbudowany, lub dom jest już zbudowany, możesz korzystać z nich wszystkich. Jednak, gdy musisz zmienić którąkolwiek z tych rzeczy (jak powiedziałem, że samochód jest tutaj najbardziej tygodniowym przykładem), będziesz musiał to zrobić. Nie twierdzę, że te przykłady są idealne, ale umieszczają koncepcję w dziedzinie czegoś fizycznego i znanego większości ludzi.
frogstarr78

0

Myślę, że oprócz opcji dekompilacji kodu byłby to dość duży problem, zakładając, że firma zamierza nadal sprzedawać oprogramowanie. Gdyby była to aplikacja wewnętrzna, to samo byłoby w mniejszym stopniu prawdziwe.

Jeśli nie możesz przywrócić kodu źródłowego, nie można wykonać konserwacji (naprawy błędów) i ulepszeń, aby aplikacja była teraz statyczna. Jeśli Microsoft, Apple, Apache lub ktokolwiek na twojej platformie operacyjnej zmieni lub zaktualizuje swój kod, stary skompilowany kod może nie działać i nie możesz go naprawić. Jeśli sprzedajesz tę aplikację klientom zewnętrznym, nie możesz kontrolować, kiedy będą aktualizować system Windows, MAC OSX, iPhone, przeglądarkę internetową, więc masz tutaj dość duże ryzyko dla reputacji firmy i możliwe ryzyko prawne, także jeśli masz umowę serwisową z klientami.

Po drugie, kod źródłowy stanowi zasób dla firmy. Tak więc dla firmy programistycznej jest to zaleta książek. Jest to coś, co możesz sprzedać jako produkt lub sprzedać kod źródłowy i wszystkie prawa innej firmie zajmującej się oprogramowaniem. Nie kontynuowałbym sprzedaży oprogramowania klientom, o których wiedziałem, że nie jestem w stanie, ponieważ straciłem kod źródłowy. Ponadto wątpię, aby inna firma oprogramowania kupiłaby aplikację i wszystkie prawa, gdyby nie mogła dalej rozwijać produktu. Dlatego wartość aktywów tej aplikacji musi zostać zmniejszona.

W przypadku wewnętrznej aplikacji wewnętrznej możesz mieć większą kontrolę nad platformą operacyjną aplikacji, ale nadal chciałbym zastąpić tę aplikację, jeśli kodu źródłowego nie można zdekompilować na użyteczną bazę kodu w celu konserwacji.

Twoje zdrowie,

Kevin

PS Mam nadzieję, że to tylko teoretyczne pytanie ... :)


-1

Jeśli nie muszą naprawiać żadnych błędów, to prawdopodobnie nie jest to taka wielka sprawa. Na przykład, jeśli firma tworzy niestandardowe formanty ActiveX i traci źródło jednego ze swoich starszych produktów, to kogo tak naprawdę to obchodzi? Produkt prawdopodobnie nie jest aktywnie konserwowany i prawdopodobnie nie jest agresywnie sprzedawany. Będą sprzedawać tak długo, jak długo ludzie będą używać 32-bitowego ActiveX, a potem o tym zapomną.

Mimo to nadal klasyfikowałbym to jako rażące niedbalstwo. Oczywiście nie ma systemu zarządzania kodem źródłowym, który jest profesjonalną niekompetencją w domu oprogramowania.


-1: „Jeśli nie muszą naprawiać żadnych błędów” Cóż za godny pozazdroszczenia poziom doskonałości. Kto ma tak dobre oprogramowanie? Ktoś?
S.Lott,

1
„Nie trzeba naprawiać błędów”! = „Brak błędów”. Wiele firm nadal sprzedaje oprogramowanie EOL z listą znanych błędów, których nie zamierzają naprawiać. Jak sterownik USB dla Win98 - są tam, prawdopodobnie nie są idealne, ale wątpię, czy ktoś stosuje poprawki błędów.
TMN
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.