오픈소스 소프트웨어를 설명하기에 앞서, 다른 곳에서 개발된 소프트웨어를 채택하는 방법, 어떤 프로젝트에 기여하는 방법, 자신의 오픈소스 프로젝트를 시작하는 방법 등 세 관점에서 오픈소스 소프트웨어에 대한 몇몇 오해를 풀어보고자 합니다.
오픈소스 소프트웨어는 품질이 낮거나 보안성이 떨어진다.
주요 소프트웨어 기업들이 오픈소스에 참여하면서, 이제 이 같은 오해는 자주 언급되지 않지만, 직접 이야기하지는 않더라도 아직 그렇게 생각하는 경우가 있습니다. 상용 소프트웨어 구매에 익숙한 사람들에게는 무료로 얻을 수 있는 소프트웨어가 높은 품질을 가질 수 있다는 점을 믿기 어려울 것입니다. 그러나 실제로 오픈소스 프로젝트는 다양한 자금 지원 전략으로 라이선스 비용을 대체해 왔습니다. 핵심은 오픈소스 프로젝트들이 당신의 회사에서도 도입하면 이득이 될 수 있는 수준의 엄격한 품질 프로세스를 채택하여 고품질의 소프트웨어 개발 프로세스를 가지고 있다는 것입니다. 보안에 대한 결함은 오픈소스와 그렇지 않은 소프트웨어 모두에서 발생합니다. 누구도 이를 피할 수 있다고 장담할 수 없습니다. 우리가 경험한 바로는 투명하고 큰 규모의 개발 커뮤니티를 가진 오픈소스가 보다 신속한 수정과 수정된 버전의 배포를 할 수 있다는 것입니다.
오픈소스 소프트웨어는 기술 지원이 부족하다.
많이 사용되는 오픈소스 프로젝트들은 조직과 개인 개발자들 양쪽으로부터 기술 지원을 받고 있습니다. 기술 지원이 한 회사에 종속되지 않는다는 점이 코드가 오픈되어 있다는 것의 큰 장점이기도 합니다. 작거나 시작한지 얼마 안 된 프로젝트의 경우에는 아직 지원 생태계가 충분히 활성화되지 않을 수 있어서 개발자들이 더 많은 시간을 쓰거나 커뮤니티로부터의 비공식적인 도움이 필요할 수도 있습니다. 당신이 즉시 수정이 필요한 치명적인 버그를 발견한 상황에서, 오픈소스가 아닌 소프트웨어라면 무관심한 벤더가 버그를 고쳐줄 때까지 기다리려야 하는 반면, 오픈소스의 경우 내부의 개발자가 고치거나 해당 코드를 잘 아는 외부 개발자를 고용하여 수정할 수 있다는 점이 감사할 수도 있습니다.
오픈소스 소프트웨어 프로젝트는 관리되지 않고 혼란스럽고 무료이다.
이 책을 읽어가면서 점점 명확해지겠지만, 성공적인 오픈소스 프로젝트들은 의사 결정, 코드 리뷰, 사용자 대응을 위한 프로세스를 보통의 조직들처럼 잘 정의하고 있습니다. 다른 사람들이 개발한 코드를 사용할 때는 정해진 규칙을 따라야 합니다. 코드에는 거의 항상 라이선스가 있지만 상용 코드와는 다릅니다. 개발자가 인터넷에 있는 코드를 자신의 제품에 복사해 사용하는 것은 거의 확실히 라이선스를 위반하는 것이며 법적으로 또는 다른 이유로 좋은 방법이 아닙니다. 오픈소스 이니셔티브 (Open Source Initiative)와 소프트웨어 자유보호협회 (Software Freedom Conservancy)에서 이에 관한 많은 토론이 이루지고 있습니다. 다음 섹션들에서 어떤 조직이 오픈소스 코드를 수용하기 위하여 최근에 사용되는 방법들에 대해 설명하려고 합니다.
오픈소스 소프트웨어를 사용하려면 내 코드도 공개하여야 한다.
이 부분은 앞의 오해와 반대됩니다. 분명히, 오픈소스 소프트웨어를 사용하기 전에 라이선스에 필요한 사항을 숙지하여야 합니다. 일부 라이선스에는 변경 사항들을 원 소스에 기여해야 한다는 규칙이 있으며, 나중에 이야기하겠지만 그 규칙이 없더라도 그렇게 하는 것이 이득으로 돌아옵니다. (때로 이러한 라이선스를 "바이러스 성"이라 일컫기도 하지만 해당 단어에 대한 부정적 의미 때문에 "카피-레프트, copy-left"가 보다 중립적인 용어입니다.) 변경한 부분을 기여해야한다는 규칙이 있는 경우를 포함하여 대부분 오픈소스 프로젝트는 라이브러리 형태로 배포되는데, 직접 개발한 코드를 그 라이브러리를 링크하는 경우에는 자신의 코드를 공개하지 않을 수도 있습니다 (예: GNU Lesser General Public License).
공개 저장소에 코드를 공개함으로써 사용자 기반과 커뮤니티를 확보할 수 있다.
아주 천천히 진화하는 오픈소스는 결코 잘 작동하지 않습니다. 오픈소스 프로젝트가 비즈니스 전략 상 의미있는 요소로 존재하는 경우에만 독점적인 프로젝트 대신에 채택될 것입니다. 오픈소스 프로젝트는 활성화된 커뮤니티의 일부로 존재할 때만 그 가치가 실현됩니다. 많은 경우에, 프로세스에 프로젝트 참여자들 사이의 상호 작용이 내재되어 있고, 그 상호 작용은 그 자체로 참여자들에게 매우 소중합니다. 이 같은 오픈소스의 역동성이 계속된 투자를 보상합니다. 책을 읽는 동안 이 부분이 어떻게 이루어지는 가에 대해 더 잘 알게 될 것입니다. 활성화되지 않은 프로젝트는 시간이 지남에 따라 정체 비용이 증가하여 혜택이 줄어듭니다.
오픈소스로 프로젝트를 하면 회사의 개발자들이 기술지원을 하는데 대부분의 시간을 쓰게 만든다.
오픈소스에서는 자신이 기술지원에 사용한 시간을 다른 사람이 커뮤니티에 기여한 결과로 보상받습니다. 물론 지원을 위해 쓸 수 있는 시간을 미리 정해야하지만, 회사는 내부 프로젝트의 데드라인을 맞추거나 과도한 지원 비용을 관리하기 위해 기술지원에 투입하는 시간을 조절할 수 있습니다. 성공적인 오픈소스 커뮤니티에서는 모든 멤버들이 교육이나 지원을 분담하며 한 회사가 전적으로 책임을 지지는 않습니다.
무시할 수 있는 수준의 몇 예외 사항을 제외하면 자유 소프트웨어의 정의에 해당하는 모든 내용은 오픈소스의 정의에도 해당되고 그 반대의 경우도 마찬가지이기 때문에 자유 및 오픈소스라는 용어를 이 책에서는 서로 바꿔가며 사용합니다. 자유, 프라이버시 및 공유의 측면을 강조하려는 사람들이 자유 소프트웨어라는 용어를 사용하는 반면, 실용적이고 비지니스 관점의 이득을 강조하는 사람들이 오픈소스라는 용어를 사용합니다.
개발자가 소스코드를 공개하지 않으면서 무료로 배포하는 프로그램을 의미하는 프리웨어라는 용어는 더 이상 사용하지 말아야 합니다. 그런 소프트웨어는 지금 통용되는 프리 소프트웨어 분류에 속하지 않습니다. 진정으로 프리(또는 오픈소스)가 되려면 사용자가 소스코드를 수정하고 재배포 할 수 있는 라이선스 형태로 소스코드가 공개되어야 합니다.