상용 소프트웨어 제품에서 오픈 소스 코드 사용의 지혜

ASP.NET 웹 응용 프로그램 (특히 dapper ) 에서 일부 오픈 소스 코드를 사용하려고 합니다. 오픈 소스는 이전에 우리를 물리 친 위험으로 여겨지기 때문에 관리는 팬이 아닙니다. 분명히 이전 개발자는 오픈 소스 구성 요소에 장애가 발생한 후 내용을 다시 작성해야했습니다.

장점은 다음과 같습니다.

• 그렇지 않으면 많은 상용구 코드 또는 Microsoft의 권장하지만 느린 솔루션 (Entity Framework)이 필요합니다.

단점 :

• 생산에 갑자기 실패하면 문제를 해결하기가 쉽지 않을 정도로 복잡합니다. 그러나 그것은 내 것보다 훨씬 높은 트래픽 사이트에서 사용되므로 프로젝트의 위험이 높은 부분은 아닐 것이라고 생각합니다.

여기서 합의는 무엇입니까? 내 프로젝트에서 오픈 소스 코드를 사용하고 모르거나 이해하지 못하는 것이 현명하지 않은가?

특정 상황에 따라 선택해야합니다. 다음을 통해 위험을 완화 할 수 있습니다.

• 프로덕션 환경에서 사용자를 물리 칠 수있는 놀라운 놀라움을 피하면서 프레임 워크를 철저히 테스트하고
• 느슨한 결합을 사용하여 프레임 워크에 직접 의존하는 코드의 양을 최소화하므로 전체 제품을 다시 작성하지 않고도 자체 구현으로 변경할 수 있습니다.

궁극적으로 사용량이 많은 오픈 소스 프로젝트를 사용하면 몇 가지 문제를 해결하는 것보다 자신의 글을 쓰는 데 더 많은 시간을 할애 할 수 있습니다.

나는 당신의 초기 반응이 다른 누군가가 그것을 작성했는지 보지 않고 스스로 무언가를 작성하는 것이라면, 당신은 실패 할 운명이라고 말할 것입니다. 주류 오픈 소스 프로젝트에 들어간 모든 인력과 버그 수정을 가볍게하지 마십시오.

비즈니스 도메인에 들어가기 시작하면 필요에 맞는 OSS를 찾기가 더 어려워집니다. 그러나 또 다른 ORM 제품을 다시 구현할 필요는 없습니다. dapper가 복잡하여 코드를 디버깅하고 수정할 수 없을 정도로 복잡하다면 처음부터 작성하는 데 모든 인력을 소비하는 것을 어떻게 정당화 할 수 있습니까? 게다가, NoSQL 솔루션은 항상 상자 밖에서 볼 수 있어야합니다.

Linus조차도 Git을 개발하기 전에 모든 기준을 충족하는 SCM 솔루션을 찾으려고 시도했습니다. 적어도 기존 솔루션 중 어느 것도 충분하지 않은 이유를 설명 할 수있었습니다.

내 인생의 어느 시점에서 나는 모든 것을 스스로 다시 쓰고 싶지 않고 실제 문제를 해결하는 데 집중하고 싶었습니다. 비즈니스에서 해결해야하는 대부분의 문제는 도메인별로 다릅니다. 더 적은 코드를 작성하는 방법을 찾으십시오.

참고 : 저는 Microsoft 직원이 아닙니다. 의견은 완전히 개인적인 것입니다. 지난 5 ~ 7 년 동안 오픈 소스를 개발자와 함께 대규모 공급 업체와 함께 사용하는 것에 대한 많은 생각이있었습니다.

단일 문화가 좋다 : ASP.NET에 대한 나의 개인적인 규칙은 Microsoft를 선호하고 다른 선택이없는 한 타사 코드 (오픈 소스 여부)를 선택하지 않는 것입니다. 단일 공급 업체는 큰 공급 업체에 의해 운영되고 있으며 동일한 경험을 반복하는 사용자의 수는 도움을 받고 해결 방법을 찾을 수있을만큼 큰 시간입니다.

유령 도시 : 2012 년 오픈 소스의 문제점은 더 이상 2000 년이나 2005 년이 아니라는 것입니다. 사용자 수, 입양 자, 기여자가 몇 년 전과 거의 같을 때 프로젝트 수는 계속 증가하고 있습니다. 청중은 가늘어졌습니다. 많은 흥미로운 프로젝트들이 오래되고 버려졌습니다. 오픈 소스 프로젝트 예산과 같은 것은 없습니다. 따라서 관심이 끝날 때, 지원이 끝났다고 솔직하게 발표 할 사람은 없습니다. 이 프로젝트는 대중의 관심을 더 좋고 새로운 것에 집중하기 위해 결코 죽지 않습니다. 따라서 오픈 소스는 항상 계속 커지고 조각화됩니다. 금전적 보상이나 재정적 죽음의 형태로 피드백을받지 못하는 이들은 영원한 영광을 위해 존재하는 불멸의 존재입니다.

20도 분리 : 새로운 라이브러리를 채택 할 때마다 주류와 분리되어 소수의 엣지 케이스로 전환됩니다. 특정 버전, 프레임 워크, 플러그인 등을 사용하여 보안 구성 선택과 같은 20 단계를 거친 후 솔루션은 전 세계적으로 고유 한 세부 정보 조합이됩니다. 인터넷 검색은 문제가 얼마나 드물거나 고유한지 증명하는 데 도움이됩니다. 그것은 항상 기술적 인 자체 문제입니다. 실제 비즈니스와는 관련이 없습니다.

품질은 초점에서 비롯되고 돈은 관련이 없습니다. 상업용 소프트웨어와 오픈 소스의 차이는 없습니다. Devellopers의 전체 커뮤니티는 항상 그렇듯이 하나의 커뮤니티입니다. 대규모 공급 업체는 오픈 소스 그룹보다 더 많은 대상을 가진 더 나은 조건에서 코드를 더 오래 노화시킬 수 있다는 장점이 있습니다.

합의 : 합의가 있는지 묻습니다. 아마 아닐 것입니다. 불행히도 많은 양의 오픈 소스 사용자가 너무 정치화되었습니다. 모든 오픈 소스는 사회 운동입니다. 오픈 소스는 비판에 영향을받지 않습니다. 종종 부정적인 의견이 반 공학적 개인 공격으로 인식되기 때문입니다. 내 개인적인 합의 : Microsoft를 고수하십시오.

나는 상당한 양의 오픈 소스 소프트웨어를 사용하는 대기업을 위해 수많은 성공적인 프로젝트를 수행했습니다. 특히 Curl, SQLite 및 Webkit을 최종 사용자에게 제공 한 성공적인 프로젝트에서 대규모 회사에 사용했습니다. 다른 사람들이 말했듯이, 라이센스에주의를 기울이고 이상적으로 변호사가 살펴 보는 것이 문제입니다.

수백 개의 오픈 소스 라이센스가 있지만 일반적으로 BSD 스타일과 GPL 스타일의 두 가지 범주로 나뉩니다. BSD 스타일 라이센스는 자신의 코드를 오픈 소스 할 필요가 없으며 일반적으로 일종의 귀속 조항이 있습니다. GPL 스타일 라이센스를 사용하려면 자체 코드를 오픈 소스해야합니다. 대부분의 회사 (내 회사 포함)는 일반적으로 이에 대해 묻기 때문에 GPL 스타일을 피하고 싶을 것입니다. Dapper는 BSD 스타일 인 Apache 라이센스를 사용하는 것으로 보입니다. 코딩을 시작하기 전에 항상 일반 라이센스 조건이 무엇인지 파악하십시오.

LGPL도 있는데, 이진 경계에 대한 액세스를 제한하면 자신의 코드를 열지 않고도 사용할 수 있다는 흥미로운 경계 사례가 있습니다. (즉, 라이브러리를 동적 라이브러리로만 액세스합니다.) LGPL 라이브러리 사용은 매우 가능하므로 더주의해야합니다.

필자의 경험에 따르면 오픈 소스 코드는 더 이상 유료 솔루션이나 문제에 대한 자체 솔루션보다 버그가 많거나 실패 할 가능성이 없습니다. 보다 유명한 오픈 소스 도구를 살펴보면 품질이 매우 높습니다.

작거나 완료되지 않은 프로젝트를 피하고 싶을 것입니다. 그것은 당신의 필요를 충족시키는 것처럼 보이는 것을 사로 잡을 수 있습니다. 그러나 그들이 두 사람에 의해 모여서 완성되고 지원되지 않는 무언가라면, 노력할 가치가 없을 것입니다. (코드를 직접 작성하려고하지 않는 한)

독점적 인 구성 요소가 실패한 적이 있습니까? 크고 작은 회사의 소프트웨어에서 많은 버그가 발생했습니다. 이 문제는 오픈 소스 자체의 문제가 아니라 프로젝트 성숙도에 관한 문제입니다.

지원을 제공하는 성숙한 프로젝트를 사용하려는 것 같습니다. 일부 오픈 소스 프로젝트는 유료 지원을 제공하거나 공개 포럼에서 답변을 얻을 수있는 충분한 커뮤니티를 보유하고 있습니다. 라이브러리를 닫을 때 또는 공개 소스인지에 관계없이 라이브러리를 선택할 때 성숙도와 지원 기준 우선 순위를 지정해야합니다.

미성숙 한 프로젝트 또는 제한된 지원이 필요한 프로젝트를 사용하기로 결정한 경우 더 많은 위험을 감수하고 있음을 인정해야합니다. 따라서 위험 완화 계획이 무엇인지 결정해야합니다. 예를 들어 타사 소프트웨어에 대한 추가 테스트를 수행 할 수 있습니다.

라이센스 문제가 여기에 문제가 없다고 가정하면 Dapper를 간단히 살펴보면 2255 줄의 잘 문서화되고 읽을 수있는 코드 만 있음을 알았습니다 . 그건

• 동일한 일을하는 비슷한 품질의 코드를 생성하기 위해 며칠 또는 몇 주를 투자 할 수있을만큼 충분히 큰
• 작게 작동하는 것을 이해하고 해당 코드의 버그가 프로덕션에 나타나는 경우 수정할 수있을 정도로 작습니다.

이와 같은 것을 직접 작성하고 "바퀴를 재창조"하려는 경우 자체 코드에서 프로덕션에 버그가 표시 될 위험이 훨씬 높아지고 실제로 "고정하기 위해 압박을 가해 야합니다".

당신은 당신의 프로젝트에 오픈 소스의 그런 부분을 소개하면, 그러나, 여기에 무엇을해야 다음, 당신은 가지고 가야 전체 책임 은 스스로를 쓴 것처럼, 그 코드를. 필요한 경우 코드가 유지할 수있는 상태인지 확인하십시오. 예상대로 작동하지 않는 경우 해당 코드의 "저자"를 비난하지 마십시오.

우리 프로젝트 중 하나에서 Dapper와 같은 작은 크기부터 약 20K ~ 30K 코드 라인을 가진 라이브러리에 이르기까지 일부 오픈 소스 구성 요소를 소개했습니다. 우리는 항상 약간의 변경을하고 버그를 고치며 무언가를 축소해야했습니다. 오픈 소스를 사용하는 디버깅 시간도 포함되어 많은 작업이 필요했습니다.

여기서 고려해야 할 한 가지 : 귀하의 경우 큰 공급 업체 (MS Entity Framework, 추가 라이센스 비용을 지불 할 필요가 없음)에서 광범위하게 허용되는 대안이 있다고 언급했습니다. 성능을 고려하여 사용하고 싶지 않습니다. 성능이 유일하게 고려되는 것이 아니라는 것을 진지하게 권장합니다. 여기서 물어봐야 할 질문들 : Dapper에 현재 필요한 모든 기능과 소프트웨어의 예상 수명 기간이 있습니까? 또는 Dapper의 한계에 빨리 도달 할 것이라고 예상 할 수 있으며, EF를 처음 사용하기로 결정한 경우 필요없는 많은 기능을 추가해야 할 것입니까? 후자의 경우 Dapper를 사용하지 않는 것이 좋습니다. 또한 스스로에게 물어보십시오 : EF는 귀하의 응용 프로그램에 대해 충분히 빠르지 않습니다.

내가 알다시피, 그것은 균형 잡기 행동입니다.

공급 업체에 의존하게되면 지원이 오래 전에 사라질 것입니다.

• 그들은 프로그래머가 지불해야하기 때문에 계속해서 새로운 버전을 만들고 기존 버전을 구할 수없고 더 이상 (새로운 플랫폼에서) 작동하지 않도록해야 새로운 버전이 시장에 출시됩니다.

• 비즈니스 모델을 정당화 할만큼 충분히 판매 할 수없는 경우, 회사 A에서 회사 B로 C로 전달합니다. 각 모델은 다시 충분히 변경되므로 다시 프로그래밍하지 않고도 새 모델을 사용할 수 없습니다. 작동하는 오래된 것을 얻지 마십시오.

• 그들은 문제가 너무 많고 돈이 없기 때문에 더 이상 지원하지 않기로 결정합니다. 모든 돈은 새로운 앱에 있습니다.

따라서 몇 년마다 계속해서 다시 작성하지 않아도되는 것을 만들고 싶다면 오픈 소스가 친구가 될 수 있습니다.

충분한 실사를 마치면 현명하다고 생각하며 특정 프로젝트의 역사와 활동과 관련하여 이미 숙제를 한 것으로 보입니다. 소스 코드에서 기능을 확장 / 추가하는 기능도 큰 장점입니다. 충분한 테스트를 통해 고려할 위험을 최소화 할 수 있습니다. 코드의 모든 종속성을 완전히 이해하기는 어렵지만 최소한이 경우에는 필요한 경우 코드를 완전히 디버그하고 볼 수 있습니다.

경영진에게 왜 이전에 실패했는지, 충분한 실사를 했습니까?

jquery에는 MIT 라이센스를 사용할 수있는 옵션이 있으므로 많은 상용 및 정부 웹 사이트에서도 jquery를 사용합니다. Microsoft 웹 사이트에서도 jquery를 사용합니다! 따라서 문제는 라이센스입니다. GPL / LGPL을 사용하지 마십시오.

"보고 된 결함을 수정하는 데 얼마나 걸립니까?" 버그를보고 한 후 몇 분, 몇 시간 또는 며칠 내에 수정 될 수 있습니다. 긴급 상황의 경우, 직원은 단순히 소스를 가져 와서 직접 컴파일하기 위해 "git pull"을 사용할 수 있습니다. 그는 단순히 "v1.2.3-101-gd62fdae"와 같은 버전을 관리에게보고합니다.

오픈 소스는 실제로 코드 품질이 아닌 합법성에 관한 것입니다. 좋고 나쁜 폐쇄 소스 제품이있는 것처럼 좋고 나쁜 오픈 소스 제품이 있습니다. 여러분의 딜레마는 자원 봉사자 커뮤니티가 개발 한 프로젝트의 사용 여부입니다.

관리 문제가 기술적 인 문제인지 확인하십시오.

OS와 상업 활동을 혼합하는 것은 합법적 인 광산 분야이며, 한 명 이상의 관리자가 법무 팀 / CEO 또는 다른 조직의 "제발 설명하십시오"라고 말합니다. 내가 아는 대부분의 관리자, 심지어 OS 소프트웨어를 적극적으로 수용하는 관리자조차도 그들이 출처를 드러내는 법적 상황을 완전히 이해하는 것은 매우 신중합니다. OS 소프트웨어를 채택하고 변경하는 경우 해당 변경 사항을 커뮤니티에 반환해야합니다. 어떤 경우에는이 의무가 합법적이며 다른 경우에는 도덕적입니다. 일부 OS 라이센스에서는 사용자가하는 모든 작업이 그와 연결되어 OS가됩니다.

기술적 인 관점에서 볼 때, 경쟁 제품 간의 결정일뿐입니다.-기본적인 질문을하십시오-선택한 패키지에 필요한 지원을받을 수 있습니까?,보고 된 결함을 수정하는 데 걸리는 시간, 비용은 어느 정도입니까? 개발자, 매년 또는 한 번의 오프 등. OS는 $ 열에 많은 0을 가지고 있지만 종종 다른 사람들에게는 빈칸을 가지고 있습니다. 오직 당신과 당신의 상사가 빈칸의 무게를 0으로 결정합니다.

또 다른 점은 "아무도 IBM을 구매하지 않았다"는 점을 기억해야합니다. (즉, 경영진은 "많은 돈을 소비한다면 무료 인 제품보다 더 나은 제품이어야한다"고 말합니다