소스 코드를 잃어 버리는 것이 얼마나 심각한가요? [닫은]

소프트웨어 회사가 판매하는 제품 중 하나에 대한 소스 코드를 잃어버린 경우 평신도에게 설명 할 수 있다는 점에서 얼마나 심각합니까? "중과실"이라는 용어가 너무 강합니까? 아니면 "총 무능"? 분명히 아무도 살해 당하지 않았지만 사람들이 감옥에 갈 시간을내는 재정적 태만만큼 심각하지 않습니까?

편집 : 디스크 드라이브 충돌, 자연 재해 또는 이와 유사한 경우가 아니라고 가정 해 봅시다. 그들은 단지 그것을 잘못 배치했습니다.

MS가 Windows Phone 7의 소스를 잃어 버렸다고 가정 해 봅시다 . 개발 비용이 4 억 달러 에 미치지 못하는 사람들이 사망 했습니다.

제품에 따라 '너무 강하다'고 생각할 수있는 용어는 없습니다.

회사의 경우 이것은 왕관 보석을 잃는 것과 같습니다. 프로세서가 내장 된 제품인 경우 계속 "있는 그대로"제품을 만들 수 있지만 제품을 개선하거나 문제를 해결할 수있는 능력을 잃게됩니다.

오늘날의 시장에서 회사 는 IP입니다. 그것을 잃으면 그것은 사업에서 사라집니다.

다른 사람들이 지적했듯이, 이것은 "모두 의존적"이라는 제목에 속할 가능성이 있으므로 몇 가지 시나리오가 있습니다.

디스크 기반 콘솔 비디오 게임 소스 -디스크에 구운 후에는 게임을 변경하지 않는 경향이 있기 때문에 회사에 거의 영향을 미치지 않을 것입니다. 다시 개발해야하는 라이브러리 코드가 있으면 시간을 잃을 수도 있지만 그렇게 나쁘지는 않습니다.

다운로드 가능한 비디오 게임의 출처 -고객이 버그가 패치 될 것으로 예상하고, 그렇게하지 않으면 고객이 회사에 대한 믿음을 잃어 향후 릴리스에 악영향을 줄 수 있기 때문에 이는 나쁠 것입니다.

개발중인 게임의 소스 -대부분의 비디오 게임 회사는 개발주기의 초기 단계 (예 : 며칠, 몇 주일이 지나지 않은 경우)가 아니라면 현재 개발중인 게임의 코드를 잃어 버릴 수 없습니다. 그들의 주력 해제로 인해 사업이 중단 될 수 있습니다.

출시 대상이 제한된 소기업 응용 프로그램의 소스 -회사에 문제가 발생할 가능성은 적지 만 몇 명의 고객을 잃을 수도 있습니다.

출시 대상이 제한된 대기업 응용 프로그램의 출처 -고객의 신뢰 상실로 인해 회사가 사업을 중단 할 수있는 또 다른 상황. 대부분의 소규모 시장에서도 둘 이상의 회사가 운영되는 경향이 있으며 이는 비즈니스가 경쟁 업체로 이전하기에 충분할 수 있습니다.

대기업의 주요 응용 프로그램에 대한 출처 -여기에 실제로 모든 것이 의존하고 있으며 매우 좁은 경우가 있습니다. 주력 제품 (예 : Microsoft Windows)은 일반적으로 해당 제품과 관련된 지원 계약을 가지고 있으며 제품을 지원할 수 없으면 계약 소송을 위반할 수 있습니다. 내가 견적을 주어야한다면, 코드를 잃어버린 사람들의 대부분은 그 사람들의 고위 리더십까지 새로운 일자리를 찾아야한다고 말할 것입니다.

하지만 전반적으로 코드를 잃어버린 사람은 새로운 일자리를 찾고있을 것입니다 (그리고 일자리를 찾기가 어려울 수 있습니다!). 또한 회사의 소송에 직면 할 수도 있습니다.

그것이 대격변이 될 수있는 경우는 확실히 있지만, (적어도 소프트웨어 회사의 관점에서) 그렇지 않은 곳이 많이 있다고 생각합니다.

법적인 영향이 있는지 여부에 대한 담요 답변을 제공하기에는 너무 많은 변수가 있다고 생각하지만 다음과 같은 결정에 고려해야 할 몇 가지 질문이 있습니다.

• 프로그램의 성격은 무엇입니까? 그것이 같은 앱이 십여 개이고 중요 하지 않기 때문에 그들이 잃어버린 것이라면 무엇입니까? 회사의 주력 제품인 경우 실제로 피해를 입었을뿐입니다. 그것이 커스텀 소프트웨어라면 구축 계약을 맺었을 때, 그것이 흥미로울 수있는 곳이지만, 그들은 당신이 물어봐야합니다 ...
• 코드의 저작권은 누구에게 있습니까? (고객이 저작권을 보유한 경우, 재산이 손실 / 파기 된 것 같습니다)
• 코드가 사라져 고객이 적극적으로 피해를 받고 있습니까?
• 코드의 소실로 인해 위반 될 향후 개발에 관한 계약이 있었습니까?
• 기존 소프트웨어를 재생성하는 것이 얼마나 중요합니까? 유지 관리 작업을 수행하는 것이 쉘 스크립트와 같은 경우 소프트웨어 회사는 동일한 작업을 수행하는 새로운 스크립트를 만드는 데 걸리는 시간을 소비합니다. 사무실 스위트 인 경우 이력서를 먼지에서 제거하십시오.

그리고 고려해야 할 다른 많은 요소가 있다고 확신합니다. 자유롭게 추가하십시오.

이제 저는 "소프트웨어 회사의 관점에서"라고 말했습니다. 변경, 개선 또는 기타 사항에 대한 계획으로 인해 고객의 마음에는 여전히 치명적일 수 있습니다. 그럼에도 불구하고 그러한 것들 또는 저작권의 소유권에 대한 계약은 고객을 심각하게 화나게 할 수 있지만 개발자의 입장에서 좋은 고객 관계를 유지하기 위해 할 수있는 일을 할 의무는 없습니다.

아, 당신의 설명이 주어지면 (댓글로) :

소스 컨트롤없이 오래 전에 개발 되었기 때문에 그들은 이번에 팔아서 갑자기 업데이트해야합니다.

에서 이 특정 상황 , 나는 아마 세상의 끝이 아니야 말할 것입니다. 그들이 소스 코드없이 몇 년 동안 소프트웨어를 판매 해왔다면, 업데이트를 요청하는이 고객에게 "죄송합니다"라는 말을 할 수 있습니다.

이제 코드를 잃어 버리는 것은 좋지 않습니다. 회사에서 원래 버전을 다시 작성하거나 리버스 엔지니어링하는 데 비용이 많이 듭니다 (그렇게 결정한 경우). 그러나 그것은 세상의 끝이 아닙니다. 그들은 코드가 필요없이 오랫동안 오랫동안 살아 남았으므로 아마도 코드없이 계속 살아남을 것입니다.

물론, 그들이 판매하는 소프트웨어는 사업의 일부일 뿐이라고 가정합니다. 내가 추측하고있는 것은 ...

그들이 여전히 제품을 판매 할 수있는 한, 그들이 문제가 있다고 생각하지 않습니다. 이제 고객이 제품을 확장하고 다음 버전에서 특정 새로운 기능을 제공하기 위해 계약을 체결 한 경우 계약 위약금을 위반하도록 설정되어 있기 때문에 훨씬 더 심각합니다. 그러나 코드 자체를 잃어 버리는 데 법적 문제가 있다고 생각하지 않습니다.

그렇다고 해서 회사에 절대적인 재앙 이되는 것은 아닙니다 . 그러나 재정적 인 재앙입니다. 합법적 인 것이 아닙니다. 아마도 "중요한 무능"이라는 용어로 시작해서 거기서부터 시작됩니다.

솔직히 말해서, 그것은 사용되는 언어에 달려 있다고 생각합니다. C # 코드베이스를 잃어 버리면 매우 쉽게 디 컴파일 될 수 있지만 C ++ 코드베이스를 잃어 버리면 훨씬 나빠집니다.

잘 알려졌다면, 상당히 광범위한 재난이 아닌 다른 방법으로 소스 코드를 잃을 수있는 벤더는 분명히 건전한 개발 관행과 같은 것을 따르지 않으며 신뢰할 수 없습니다. 나는 기업의 무능함에 대한 매우 강력한 기본 증거라고 생각합니다.

"어리석은 어리 석음"은 어떻습니까?

아이템 제작이 필요한 다른 직업에 비유하고 싶습니다. 아마도 물리적 인 것 같습니다. 예 : 건축가가 건축 된 건물의 계획을 잃어버린 경우; 자동차 회사가 자동차 모델에 대한 계획을 잃은 경우; 재 봉사자가 그들이 만든 복장의 패턴을 잃어 버린 경우; 기타

소프트웨어 작성과 비교할 수있는 물리적 비교가 많은 작업이 있습니다.

코드를 디 컴파일하는 옵션과는 별개로, 회사가 소프트웨어 제품을 계속 판매하려고한다고 가정하면 상당히 큰 문제가 될 것입니다. 사내 응용 프로그램 인 경우에도 마찬가지입니다.

소스 코드를 복원 할 수없는 경우 유지 관리 (버그 수정) 및 개선 사항을 수행 할 수 없으므로 이제 응용 프로그램이 정적입니다. Microsoft, Apple 또는 Apache 또는 운영 플랫폼이 코드를 변경하거나 업그레이드하는 경우 이전 컴파일 코드가 작동하지 않아 수정할 수 없습니다. 이 응용 프로그램을 외부 클라이언트에 판매하는 경우 Windows, MAC OSX, iPhone, 웹 브라우저를 업그레이드 할시기를 제어 할 수 없으므로 유지 관리 계약이있는 경우 회사의 명성에 크게 위험을 초래할 수 있으며 법적 위험에 노출 될 수 있습니다 클라이언트와.

둘째, 소스 코드는 회사의 자산을 나타냅니다. 따라서 소프트웨어 회사의 경우 책의 자산입니다. 제품으로 판매하거나 소스 코드 및 모든 권리를 다른 소프트웨어 회사에 판매 할 수 있습니다. 소스 코드를 잃어 버렸기 때문에 유지 관리 할 수없는 고객에게 소프트웨어 제품을 계속 판매하지는 않을 것입니다. 또한 다른 소프트웨어 회사가 제품을 더 이상 개발할 수 없다면 응용 프로그램과 모든 권리를 구매할 것입니다. 따라서이 애플리케이션의 자산 가치를 줄여야합니다.

내부 사내 응용 프로그램의 경우 응용 프로그램의 운영 플랫폼을 더 많이 제어 할 수 있지만 유지 관리를 위해 소스 코드를 사용 가능한 코드베이스로 디 컴파일 할 수없는 경우이 응용 프로그램을 대체하려고합니다.

건배,

케빈

추신 : 나는 이것이 이론적 인 질문 일뿐입니다 ... :)

그들이 버그를 고칠 필요가 없다면, 그렇게 큰 문제는 아닐 것입니다. 예를 들어, 회사에서 사용자 지정 ActiveX 컨트롤을 만들고 레거시 제품 중 하나의 소스를 잃어버린 경우 누가 정말로 관심을 가져야합니까? 제품이 적극적으로 유지 관리되지 않고 적극적으로 판매되지 않을 수도 있습니다. 사람들이 여전히 32 비트 ActiveX를 사용하는 한 판매 한 다음 잊어 버리게됩니다.

즉, 나는 여전히 그것을 과실로 분류합니다. 분명히 소스 코드 관리 시스템이 없으며 소프트웨어 하우스에 대한 전문적인 무능력입니다.