오픈소스 소프트웨어는 무엇을 의미할까요? 다른 사람에게 설명해야 할 때, 오픈소스의 가치와 핵심을 어떻게 쉽고 효율적으로 전달할 수 있을까요? 오픈소스라는 용어가 1997년 처음 제안된 이래, 업계는 오픈소스 분야에서 많은 어렵게 얻은 경험과 교훈을 얻었으며, 우리는 이러한 경험과 교훈을 잊어서는 안 됩니다.
이를 위해 저는 12개의 문화적 유전자를 수집했습니다. 제 생각에 이들은 역사를 공유하고 무대를 설정하며, 오픈소스의 정의와 전체 소프트웨어 산업에 대한 의미에 맥락을 제공하는 데 도움이 됩니다.
처음 몇 개의 문화적 유전자는 소프트웨어 구축과 관련이 있습니다. 저는 이들이 우리가 성공적인 오픈소스 프로젝트라고 생각하는 것을 정의한다고 생각합니다. 왜냐하면 이들은 소프트웨어 자체와 관련된 기본적인 측면이기 때문입니다. 이러한 문화적 유전자를 이해하는 프로젝트만이 성공할 수 있습니다. 관대한 라이선스와 커뮤니티 중심의 소프트웨어는 우리가 우수한 소프트웨어를 구축하고 유지 관리하는 데 사용하는 가장 뛰어나고 효율적인 소프트웨어 재사용 메커니즘일 수 있습니다.
첫 번째 문화적 유전자: 우리가 소프트웨어를 작성한 이래 소프트웨어를 공유해 왔습니다.
1950년대 후반, IBM은 오늘날까지 계속되는 컴퓨터 컨퍼런스인 SHARE를 시작했습니다. DEC는 60년대에 시작하여 DECUS 커뮤니티를 지원했으며, 회의에서 다른 사람이 작성하고 기여한 소프트웨어가 담긴 테이프를 구매할 수 있었습니다. USENIX는 70년대에 시작되었으며, 당시 초기 UNIX 버전을 테이프로 배포했습니다. 하지만 이러한 공유 관행은 40년대 프린스턴 고등연구소의 첫 번째 프로그래밍 가능한 컴퓨터에서의 개발 작업까지 거슬러 올라갈 수 있습니다.
두 번째 문화적 유전자: 우수한 소프트웨어를 작성하는 것은 힘든 작업입니다.
저는 공유가 이러한 단순한 현실로 귀결된다고 생각합니다. 우수한 소프트웨어를 작성하는 것은 어렵습니다. 소프트웨어 개발 분야에는 두 가지 주요 비율이 있습니다. 개발자가 하루 평균 작성할 수 있는 코드 라인 수와 합리적인 개발 프로세스에서 나오는 천 줄당 코드의 오류 수입니다. 언어 진화에서 아키텍처 재사용에 이르는 모든 소프트웨어 분야의 발전은 더 적은 코드 라인으로 더 많고 우수한 소프트웨어를 작성한다는 중심 생각을 중심으로 합니다. 소프트웨어 구축 신뢰성, 구성 관리, 검토 도구 및 프로세스, 테스트 분야의 발전은 모두 합리적인 소프트웨어 전달 프로세스에서 나오는 오류 수를 줄이는 것을 목표로 합니다.
세 번째 문화적 유전자: 무질서한 규모 확장은 없습니다.
우수한 소프트웨어를 작성하는 것은 규율 없이는 불가능합니다. 성공적인 제품이나 오픈소스 프로젝트로서의 소프트웨어를 보면, 구축 시 일반적으로 동료 검토를 받고, 버전 관리와 구성 관리를 실시하며, 빌드 자동화와 테스트 프레임워크가 소프트웨어와 함께 완성됩니다. 검토, 구성 관리, 빌드 및 테스트 자동화가 없다면 소프트웨어는 사용자 커뮤니티 내에서 확장될 수 없으며, 제품으로서도 수천 명의 사용자 사이에서 확장될 수 없습니다. 소프트웨어를 유지 관리해야 하는 핵심 그룹은 “소프트웨어가 무엇을 실행하는가”라는 질문에 답할 수 있어야 합니다.
리누스의 법칙은 “충분한 관심이 주어지면 모든 코드 오류가 드러날 것이다”라고 대략적으로 표현할 수 있습니다. 저는 이것이 실제로 커밋 검토 과정의 중요성을 나타낸다고 생각합니다. 연구에 따르면 검토 단계에서 발견된 오류가 테스트 단계에서 발견된 것보다 많습니다. 건강한 커뮤니티는 코드 체크인(check-in)에 엄격한 검토 프로세스가 있어야 합니다.
네 번째 문화적 유전자: 소프트웨어는 본질적으로 동적입니다.
프로그램은 사용을 통해 완성됩니다. 오류가 발견되면 수정됩니다. 새로운 용도가 발견되어 새로운 기능을 추진합니다. 프로그램은 계속해서 다듬어지고 강화됩니다. 프로그램은 한 환경에서 다른 환경으로 이식됩니다. 안타깝게도 저작권은 1980년에 소프트웨어 배포 파이프라인을 “보호”하는 메커니즘이 되었습니다. 사람들은 소프트웨어가 얼마나 빨리 발전하는지, 파생 버전의 개발이 얼마나 빠른지, 또는 사물인터넷과 월드와이드웹이 등장한 후 이러한 동적성이 얼마나 빨라질지 모를 수 있습니다. 우리의 공유 네트워크 대역폭은 테이프 크기의 주머니, 회의 일정표, 잡지 출판 지연에서 연중무휴 24시간 실시간 글로벌 빌드, 릴리스, 유지 관리로 바뀌었습니다.
오픈소스 소프트웨어의 커뮤니티 측면과 관련된 몇 가지 문화적 유전자를 살펴보겠습니다.
다섯 번째 문화적 유전자: 당신은 항상 주는 것보다 더 많이 받습니다.
이것은 커뮤니티 협업 개발의 경제적 효율성입니다. 지속적인 기여는 프로젝트 소프트웨어 발전의 생명선입니다. 기여자가 코드를 기여하거나 수정 버전을 제공하는 것은 큰 위험이 없지만, 얻는 이점은 전체 소프트웨어를 기여자가 적합하다고 생각하는 방식으로 사용할 수 있다는 것입니다. 그리고 지나가는 기여의 경우, 이것은 개발자가 제공하는 유일한 중요한 기여일 수 있으며, 그들의 경험과 전문성에 관계없습니다.
기여보다 더 많은 보상을 받는 것은 개인과 회사 모두에 적용됩니다. Red Hat, Intel, IBM 등 몇몇 대기업의 전용 리소스와 투자는 그들이 전체 Linux 운영 체제를 활용하여 다양한 비즈니스 전략을 실행할 수 있게 합니다. 회사는 우수한 소프트웨어 프로젝트를 고객 문제를 해결하는 제품으로 만들 수 있습니다.
여섯 번째 문화적 유전자: 무임승차자가 있는 것은 성공의 핵심입니다.
업계에서는 오픈소스 프로젝트의 사용자 1000명 중 100명이 소프트웨어 오류를 보고할 수 있고, 그중 10명이 잠재적인 수정 버전을 기여하며, 그중 단 1명만이 기여 지침을 주의 깊게 읽는다고 합니다. 실제로 커뮤니티 성공에는 세 가지 경로가 있습니다(커뮤니티 성공의 척도는 코드 기여). 하나는 소프트웨어가 설치하고 사용하기가 비정상적으로 쉬워야 프로젝트가 많은 사용자를 확보할 수 있다는 것입니다. 두 번째는 사용자 그룹 중에 개발자가 있어야 한다는 것입니다. 소프트웨어는 구축하고 테스트하기가 비정상적으로 쉬워야 자신의 이익을 위해 변경하려는 개발자가 쉽게 변경할 수 있습니다. 세 번째는 프로젝트에 변경 사항을 다시 기여하기가 비정상적으로 쉬워야 기여가 계속해서 이어진다는 것입니다. 많은 무임승차자가 있다는 것은 당신이 잘하고 있다는 것을 의미합니다. 이렇게 하면 많은 사용자가 있으면 개발자에게 큰 잠재력이 있고 기여 가능성도 따라옵니다. 하지만 프로젝트의 책임은 쉽게 만드는 것입니다.
오픈소스 프로젝트를 구축하려는 회사들은 종종 커뮤니티를 이해하기 어려워합니다. 그들은 누군가가 자신을 위해 무언가를 제공해야 한다고 생각합니다. 그들은 커뮤니티(예: 개발자 웹사이트)에 명령을 내리는 데 익숙하지 협업에는 익숙하지 않습니다. 회사와 오픈소스에 적용되는 세 가지 문화적 유전자가 있습니다.
일곱 번째 문화적 유전자: 제품과 프로젝트를 혼동하지 마십시오.
프로젝트는 실제로 설치하고 실행한 후 어떤 문제를 해결할 수 있는 실행 가능한 소프트웨어 세트입니다. 이것은 코드로 말하는 협업과 교류입니다. 프로젝트가 제품이 아니라는 것을 이해해야 합니다. 제품은 고객의 문제를 해결하여 수익을 내는 것입니다. 많은 우수한 소프트웨어가 잘 운영되어 엔지니어링 기술의 일부 작업을 줄여주는 오픈소스 프로젝트에서 나오지만, 고객에게 문제를 해결하는 제품으로 만들기 위해서는 여전히 힘든 작업이 필요합니다. 예를 들어 Linux 커널은 프로젝트이고, Fedora는 배포판 프로젝트이지만, RHEL은 제품입니다. 제품은 고객의 가치 기대를 충족하여 수익을 냅니다. 제품은 기본적으로 설치, 실행, 보증 및 배상이 있으며, 서비스(지원, 업그레이드, 교육 및 컨설팅)와 특정 제품에 대한 문서도 있습니다. 이들은 하드웨어와 서비스를 포함한 더 큰 제품 포트폴리오의 일부일 수 있습니다.
이 문화적 유전자의 한 가지 추론은 “아무도 당신을 위해 당신의 제품을 구축하지 않을 것입니다”일 수 있습니다.
여덟 번째 문화적 유전자: 고객과 커뮤니티를 혼동하지 마십시오.
일곱 번째 문화적 유전자가 엔지니어링 기술과 비즈니스 모델에 관한 것이라면, 여덟 번째 문화적 유전자는 메시지와 판매에 관한 것입니다. 커뮤니티와 고객의 가치는 다릅니다. 고객은 문제 해결을 가속화하고 위험을 제거하기 위해 돈을 지불하지만, 커뮤니티(및 커뮤니티의 개인)는 협력을 통해 자신의 솔루션을 구축합니다. 오픈소스 소프트웨어를 사용하는 일부 회사는 프로젝트 커뮤니티가 제품 파이프라인의 일부라고 생각합니다. 그들은 커뮤니티 포럼에서 고객을 찾을 때 더욱 그렇게 생각합니다. 그들은 심지어 커뮤니티 프로젝트가 먼저 사용해 본 후 구매하는 것이라고 생각할 수도 있습니다. 하지만 이 모든 것은 잘못된 것입니다.
회사는 관련 커뮤니티와의 교류가 유료 고객과의 교류와 다릅니다. 각 교류에는 특정 도구와 교전 규칙, 기록하고 고려해야 할 측정 지표가 있습니다. 커뮤니티 구성원은 매우 가치 있지만, 그들은 고객이 아닙니다.
아홉 번째 문화적 유전자: 오픈소스 정의 이전에 회사는 관대한 라이선스 소프트웨어를 공유했습니다.
Project Athena(X11, Kerberos)는 1983년에 시작되었습니다. 개방 시스템 재단(OSF/Motif, OSF/1)은 1988년에 시작되었습니다. DEC와 Sun은 초기 BSD 버전에서 각각 Ultrix와 SunOS를 개발했습니다. 이것은 새로운 행동이 아닙니다.
마지막으로 몇 가지 문화적 유전자는 오픈소스 소프트웨어 분야의 라이선스 및 법적 논의와 관련이 있습니다.
열 번째 문화적 유전자: 소프트웨어 자유와 오픈소스 라이선스는 다른 논의 주제입니다.
소프트웨어 자유와 오픈소스 소프트웨어를 논쟁하는 것은 민주주의가 자본주의보다 더 나은지 논쟁하거나, 언론의 자유가 자유 시장보다 더 중요한지 논쟁하는 것과 같습니다. 이들은 모두 중요한 논의이며, 사람들은 종종 특정 주제에 자연스러운 경향이 있지만, 이들은 다른 논의입니다. 소프트웨어 자유 언어는 사용자 권리로 정의되며, 오픈소스 소프트웨어 언어는 라이선스의 속성으로 정의됩니다. 이들은 다른 논의입니다.
열한 번째 문화적 유전자: 모든 오픈소스 프로젝트에는 라이선스가 필요합니다.
라이선스는 다른 사람이 소프트웨어를 어떻게 사용할 수 있는지 정의합니다. 소프트웨어는 저작권법으로 보호되며, OSI 승인 라이선스를 선택해야 합니다. 당신이 선택한 라이선스는 커뮤니티에서 원하는 사회적 계약을 선언합니다. 최근 몇 년간 많은 사람들이 Apache 소프트웨어 라이선스를 “비즈니스 친화적”인 라이선스로 기본 선택했지만, 반드시 그렇지는 않습니다. 상호 라이선스가 자유 라이선스인지는 자유 소프트웨어와 오픈소스 소프트웨어를 논의하는 것이 아닙니다. 상호 라이선스는 생태계 친화적인 최고의 라이선스일 수 있습니다.
열두 번째 문화적 유전자: 재단은 자리가 있습니다.
비영리 조직은 공정한 경쟁의 장과 IP(지적 재산권) 소유권의 중립성을 제공하여 회사가 잘 운영되는 오픈소스 프로젝트에 전념할 수 있게 합니다.
맺음말
1990년대 중반에서 후반에 저와 동료들은 관대한 라이선스 소프트웨어를 사용하여 소프트웨어 회사를 시작했습니다. 당시에는 오픈소스 소프트웨어라는 용어가 아직 없었습니다. 이것은 실제로 큰 신비가 없습니다. 우리는 약 250개의 25가지 다른 라이선스 프로그램 패키지를 수집하고 이식했습니다(이러한 라이선스에는 버클리 라이선스, MIT 라이선스, GPLv2가 포함됨). 우리는 자체 소프트웨어와 결합했으며, 일부 중요한 소프트웨어는 Microsoft가 소유했으며 그 라이선스가 우리의 사용을 허용했습니다. 우리는 이것을 우리 회사가 전적으로 지원하는 제품으로 개발했으며, 이 제품은 우리 자체 제품의 라이선스를 사용했습니다. 우리는 다양한 방식으로 그 다양한 협업 커뮤니티에 참여했습니다. 엔지니어와 사업가 그룹으로서 우리는 오랜 협업과 공유 역사를 통해 UNIX 시스템 커뮤니티에서 계속 성장할 수 있었습니다.
이러한 문화적 유전자를 돌아보면, 저는 그들이 20년 전에 제가 적었을 문화적 유전자와 똑같다고 생각합니다.
당신은 어떤 문화적 유전자를 추가하겠습니까? 당신은 어떤 경험담이 있습니까? 댓글로 교환해 주시기를 환영합니다.
재게시 출처: 개발자 관계 »
