IT/모바일
제공 : 한빛 네트워크
저자 : Simon Phipps
역자 : 한순보
원문 : Open source community collaboration strategies for the enterprise
비즈니스, 커뮤니티와 개발자를 위한 오픈 소스에 대한 중요 고려사항
지난해 OSCON의 주제는 "분열에서 기본으로(from disruption to default)"였다. 우리는 지난 십 년 동안 오픈 소스가 음지에서 양지로 이동하는 것을 봤다. 오늘날 여느 때보다 더 많은 비즈니스가 오픈 소스의 역할을 전략으로 고려하고 있다. 나는 수많은 비즈니스와 비즈니스 부문에서 처음으로 오픈 소스를 사용하는 이행 과정을 지켜보거나 참여할 기회가 있었고, 어떻게 신구의 모든 소프트웨어 비즈니스를 위해 오픈 소스 전략이 진화하는지도 목격했다.
다수 관점에서 오픈 소스는 리처드 스톨만의 GNU 프로젝트와 BSD 프로젝트 커뮤니티가 수십 년간 다양한 방식으로 설명했던 윤리적 생각인 "소프트웨어 자유"의 실용적인 표현이다. 오픈 소스와 자유 소프트웨어의 요소는 이해하기에 간단하다. 소프트웨어 자유는 어떤 목적으로든 소프트웨어를 사용, 연구, 수정, 배포할 권리를 제공한다. 오픈 소스 정의는 소프트웨어 자유를 지원하는 저작권 라이선스를 찾는 것을 돕는 실용적인 원칙을 가지고 윤리적인 구조의 한 부분을 명확히 설명한다. 하지만 간단한 LEGO 블록이 무한한 창조의 세계를 여는 것처럼 오픈 소스를 생성하는 블록은 다양한 사용 모델을 제공하며 여전히 진화하고 있다.
이 글은 소프트웨어 소비 기관과 소프트웨어 생산자 양 측면에서 오픈 소스 전략의 고려 사항과 구현에 관한 생각의 도구를 제공한다. 당신의 비즈니스 리더가 고려해야 할 개념에 대해 당신이 전달할 수 있을만한 설명을 준비할 수 있도록 하는 것을 목표로 한다. 이 글은 다음을 포함한다.
자유 소프트웨어 커먼즈는 일종의 저장소에 포함된 소프트웨어 몸체(body)인데, 보통은 버전 관리 시스템이지만 때때로 다운로드 디렉터리와 같이 단순하다. 그리고 이것은 저장소 내용물을 누가 수정할 수 있는지 결정하는 규칙과 함께 OSI 인증 오픈 소스 라이선스 하에 허가된다. 또한, 트레이드마크, 토론 포럼, 그리고 다른 자원의 사용에 관한 규칙, 누가 어떠한 규칙을 변경할 수 있고 그렇게 하는 권한을 사람들이 얻는 방법에 대한 규칙이 있기도 하다. 이러한 모든 규칙을 총괄하여 "커뮤니티 거버넌스(community governance)"라고 한다. 좋은 거버넌스란 매우 중요한 주제지만 이 섹션에서 다루지는 않겠다.
많은 회사와 개인의 다양한 커뮤니티 참여를 봤고 경험 많은 다양한 오픈 소스 파트너와 토론하면서, 나는 적어도 네 가지의 명확하게 차별화되는 소프트웨어 커먼즈 중심의 커뮤니티 타입이 두 부류로 있는 것 같다. 변치 않는 절대적인 분류가 아니고 대부분 커뮤니티가 두 타입에 걸쳐 있지만, 이 구별은 커뮤니티에 대해 의논할 때 기업에 도움이 된다.
계층화 모델
커뮤니티 계층에 대해 생각하는 다른 방법이 있기 때문에 이 모델이 모든 종류의 토론에 적합하지는 않다. 특히, 내가 제안하는 모델은 외부에서 커뮤니티 계층을 바라본다. 문맥이 커뮤니티 토론이라면 내부에서 바라보는 모델을 사용하는데도 적절하다. 그러나 단지 하나의 오픈 소스 커뮤니티만 있지도, 한 종류의 커뮤니티만 있는 것조차도 아님을 인식하는 것은 오픈 소스 협업 참여를 원하는 기업에 중대한 점진적인 단계이다.
기업 토론에 유용하다고 내가 발견한 모델에서 커뮤니티 타입은 자유 소프트웨어 커먼즈 주위에서 양파 꺼풀처럼 계층화된다.
중심에서 바깥으로, 커뮤니티 범주는 두 그룹이다.
공동 개발자 커뮤니티 - 프로젝트 코어 소스에 직접 관련된 사람들이 있다. 프로젝트 자체를 관심사가 중복된 부분 집합을 동기화하기로 한 다양한 사람들이 만드는 곳이다. 몇몇은 프로젝트 코드에 작업해서 돈을 받기도 하지만, 모두 그것이 그들이 원하는 코드이기 때문에 참여한다.
배포자 커뮤니티 - 코드와의 주요 관련성이 개발 환경 및 스택을 형성하는 다른 소프트웨어와 결합하여 커뮤니티 멤버가 설정하고 배포하는 실행 인스턴스(instance)를 포함하는 사람들이 있다. 그들은 버그 리포트, 테스트 케이스, 가끔 수정에 기여하지만, 프로젝트 코드 자체를 쓰지는 않는다. 설정, 배포와 사용에 전문가이다. 또한, 다른 사람을 그렇게 하도록 훈련하게 시킨다.
이들은 각각 두 하위 범주로 더 구분할 수 있다.
공동 개발자 커뮤니티:
나는 커뮤니티 타입을 위한 이 모델을 시간에 따라 점진적으로 개발해왔다. 이름을 붙이지 않았지만, 특별히 이 모델에서 발생한 다음의 주요 사항을 관찰했다.
1. 네 가지 뚜렷한 커뮤니티 타입이 있지만, 사람들이 다른 커뮤니티에서 다른 역할을 할 수도 있다. 예를 들어, 운영 체제 배포 작업을 하는 패키지 메인테이너(maintainer)는 다른 프로젝트로부터 패키징하는 그 코드에 대해서는 익스텐더이며 배포 자체에 관해서는 코어 공동 개발자이다. 배포자로서 버그 리포트를 제공하는 사람들은 다른 커뮤니티에서는 공동 개발자일 수도 있다.
2. 주어진 커뮤니티에서 여러 역할을 할 수도 있다. 예를 들어, 배포-개발자는 배포하는 내내 문제를 다룰 때 공동 개발자로서 코드에 기여할 수 있다. 테스터는 문서 작성자와 같이 여러 계층에 걸칠 수 있다. 네 계층 모두에서 많은 사람은 사용자이기도 하다.
3. 참여하는 동안에 커먼즈에 기여할 여러 방법이 있다. 사용자는 종종 문서화, 사례 연구, 버그 리포트, 기능 요청을 하는 중요한 원천이며, 사용자의 역할은 전혀 사소하지 않다. 성숙한 커뮤니티는 프로젝트에 기여하는 다양한 방법을 인정할 것이다.
4. 사람들이 보호할 필요가 있는 자유는 역할에 따라 다르다. 예를 들어, 사용자는 락인(lock-in)으로부터 보호받는 것을 중요한 자유로 생각하며 설계에 오픈 표준을 사용할 뿐만 아니라 자신들을 대신해 일하는 배포-개발자를 선택하기를 원하기 쉽다. 네 가지 원조 자유가 기준점을 제공하지만, 이들을 각각의 "계층"으로 신중하게 해석할 필요가 있어서 부드러운 운영에 필수적인 자유를 이해하고 존경해야 한다고 나는 점점 확신한다.
5. 상업적인 기관이 커뮤니티에 연관되는 방법은 커뮤니티 활동에서의 역할과 또한 영향을 미치고 싶은 사람들의 역할 둘 다 존중해야 한다. 예를 들어, 모두를 배포-개발자인 것처럼 대하면 공동 개발자 모두에게서 부정적인 반응을 얻을 것이다. 마케팅 메시지를 모두에게 널리 알리는 것보다 가장 영향력 있는 커뮤니티 멤버들을 소원하게 하는 더 빠른 방법은 없다.
6. 오픈 소스 커뮤니티를 모델화하는 많은 방법이 있지만 나는 Sun Microsystems에서 엔지니어링, 마케팅, 관리 팀에게 커뮤니티 참여를 조언할 때 이 모델을 광범위하게 사용했다. 역할 구별을 위한 공유된 용어 집합을 갖는 것은 모두가 "커뮤니티"라고 할 때 같은 것을 의미한다고 따로 가정할 필요가 없도록 하는 데 중요했다.
7. 소프트웨어 회사 사람들은 흔히 "커뮤니티"를 "시장"과 동의어로 생각한다. 기업 소프트웨어 소비자도 흔히 "커뮤니티"를 "무상 지원"의 동의어라고 생각한다. 둘 다 의미가 있지만, 커뮤니티 계층화의 올바른 이해가 이러한 잘못된 연상에서 오는 경력 제약(career-limiting) 결정과 회사 손상(company-damaging) 행위를 피하게 한다.
진정한 오픈 커뮤니티는 참여자의 프라이버시와 독립을 존중할 뿐만 아니라 투명성에 강력한 가치를 둔다. 결과적으로 그러한 커뮤니티가 상업적인 단체에 이로운 저작권 양도(assignment)을 하지도 않을 것이다. 이유는 다음과 같다.
관심사 동기화
사람들이 처음 커뮤니티에 참여하는 이유를 생각해 보는 것은 중요하다. 건강한 오픈 소스 커뮤니티에서 너그러움과 자선 활동이 대개 많이 있지만, 그것이 참여의 주요 이유는 아니다. 오픈 소스 커뮤니티는 많은 당사자의 개별 관심사를 동기화하면서 시작한다. 각 사람은:
기꺼이 개인 이익을 동기화하고 코드 협업을 하는 환경을 만들기 위해 투명성이 요구된다. 발생하는 각 행위는 그 자체의 가치에 기초해야 한다. 각 코드 커밋(commit)은 이해할 수 있어야 하며, 각 규칙은 이성적이고 정당해야 하며, 각 지출은 설명되고 적절해야 한다.
하지만 투명성을 커뮤니티 밖에 있는 참여자의 삶과 비즈니스 이익으로 확장할 필요는 없다. 커뮤니티에 관련한 당신의 동기는 내 기여와 직접적인 관련이 없다. 왜냐하면, 커뮤니티에서 우리 관계는 코드에 관한 것이며 코드 범위 밖 관계에 달린 것이 아니기 때문이다.
우리가 커뮤니티 밖에서 관계가 있다면 그 관계가 커뮤니티 멤버로서 행위에 몰래 영향을 미쳐서 아마도 우리 명성과 커뮤니티 안녕에 해를 끼친다는 것을 아는 것이 매우 중요하다. 오픈 소스 커뮤니티에서 본 최악의 문제 중 일부는 커뮤니티 멤버가 사적으로 협상한 후, 대개 커뮤니티 규칙과 관련한 법률주의에 근거하여 기정사실 혹은 거짓된 합리화를 커뮤니티에 결론으로서 가져와서 일어난다.
코드, 커뮤니티 그리고 그들이 상호작용하는 법은 투명하지만 참여하는 동기는 불투명하다. 내 이유는 내게 달려 있고, 당신 것은 당신에 달려 있다. 코드는 스스로 명백하므로 참여 동기는 직접적인 프로젝트의 범위 밖에 있다. 프로젝트 이름 안에서 당신 비즈니스 모델을 내가 수용하도록 강요할 권리가 당신에게는 없다는 점은 중요하다. 프로젝트를 당신이 시작했고 여전히 주요한 자금 출처라도 이것은 사실이다. 일단 오픈 소스 커뮤니티를 만들고 나면, 아무리 역사적으로 훌륭한 기여를 당신이 했더라도, 이것은 사실이다. 통제에 관한 어떤 시도도 역효과를 낳는다.
사적인 동기 부여, 투명한 커뮤니티
따라서 건강한 오픈 소스 커뮤니티에서는 원한다면 나의 동기와 재정을 둘러싼 프라이버시 유지가 자유롭다. 반면에, 모든 코드가 알려지고, 모든 원천이 알려지고, 모든 결점이 잠재적으로 알려지고, 모든 디자인 결정이 메일 리스트에 있는 투명한 환경에서 일할 수 있다. 내가 보기에는 프라이버시와 투명성의 결합이 실질적으로 오픈 소스 커뮤니티의 주요 특징이다. "공개 기록의 문제로서 일어나지 않았다면 일어나지 않은 것이다."라는 규칙이 없는 커뮤니티는 소프트웨어 라이선스와 관계없이 문을 닫는다.
오픈 소스는 커뮤니티 수준의 투명성뿐만 아니라 관련된 개인의 프라이버시에 관한 것이다. 둘 사이의 인터페이스에 공식적인 커뮤니티/기여 계약(agreement)이 관련된다. 신뢰를 유지하고 개발 투명성을 가능하게 하며 개인 프라이버시를 허락하기 위해 모든 참여자가 커뮤니티 규범을 받아들인다는 계약을 승인하도록 요청하는 것이 합당하다. 그 규범은 특히 기여의 독창성과 그것들의 병행 출원 특허 가능성과 관련한다.
하지만 그것은 (있다면 "프로젝트 스폰서"도 포함한) 모든 참여자여야 한다. 어떠한 참여자 계약도 커뮤니티 규범을 수용해야 한다. 오웰(Orwell)의 "동물농장"과 다르게, 한 참여자 혹은 참여자의 계층이 "다른 사람 이상"이 되는 기회는 없다.
특권 없음
분명히 한 참여자에게 사적으로 사용하도록 종합한 저작권의 독점적인 이익을 주는 것은 합당하지 않다. 그렇게 하는 것은 투명성-프라이버시 경계를 위반하고 커뮤니티 커먼즈에 불투명한 행위를 가능하게 하여 신뢰를 손상한다. 그리고 그것이 속하지 않은 커뮤니티에 사적인 비즈니스 모델 추론(reasoning)을 도입한다.
저작권 양도를 정당화하기 위한 "우리는 수익을 창출할 수 있어야 한다." 혹은 "우리는 원본 코드에 기여했다."와 같은 주장을 들었다. 하지만 이것들은 개인적이며 커뮤니티의 주장은 아니다. 수익에 대한 당신의 필요는 커뮤니티의 것이 아니며 당신의 것이다. 커뮤니티를 시작하기 전에 이를 바로잡지 않고 OSI 인증 라이선스 하에 코드를 철회할 수 없는 라이선스를 했다면 이는 당신의 문제이다. 당신의 비즈니스 상 필요는 나의 저작권을 당신에게 넘겨주는 이유가 되지 않으므로 제발 요구하지 마라. 나에게 어떤 것을 요구하기 위해 당신의 기여해야 할 양은 존재하지 않는다. 당신의 권리가 당신이 오픈 소스 커뮤니티에 기여하는 양에 비례하지는 않는다.
단순한 철학적 문제가 아니라 실질적이기도 한 문제이다. "오픈 소스 커뮤니티 스폰서 증가에 따른 참여 구조의 역할"에서 Joel West와 Siobhan O’Mahony는 오픈 소스 커뮤니티를 시작하려는 회사가 특권을 유지하려 한다면 결과를 망칠 것이라며 확신한다. 통제하려는 것은 커뮤니티가 당신이 바라는 대로 성장하지 못하게 한다. 또는 결국 당신이 만든 커뮤니티의 당신 주위에서 포킹(forking)하고 작업(working)하게 한다. 이는 전에도 일어났고 계속되며 또 일어날 것이다.
시스템의 게임화
이러한 관심사의 분류에는 물론 제한이 있다. 이러한 토대에서 아파치(Apache) 소프트웨어 재단을 십여 년간 잘 운영했다. 다양한 동료 커뮤니티가 그러한 규칙과 함께했을 때 매우 효과적이었다. 아파치 모델은 존재하는 최고의 범용 오픈 소스 커뮤니티 모델에 가깝다.
하지만 결과적으로 오용자(abusers)가 될 사람들을 자석처럼 끌어오기도 했다. 아파치가 이런 경우를 여러 차례 성공적으로 다루면서, "게임화 된" 높은 투명성과 높은 프라이버시의 결합을 몇 차례 봤다. 다양한 역사의 순간에서 아파치는 더 큰 커뮤니티에 좋지 않은 방법으로 프로젝트에 참여하는 참여사를 봤다. 아파치만의 문제도 아니다. 다른 오픈 소스 커뮤니티가 성숙해지며 그들 모델의 게임화에 직면하는 것이다.
이러한 일이 일어난다. 숙련되고 경험 있는 직원과 소프트웨어 시장의 정치적인 힘이 있는 경험 있고 잘 갖춰진 회사가 사적으로 계약할 수 있다. 이것은 그들 자신의 직원과 파트너 에코시스템의 멤버 사이일 수 있으며, 비공식적으로 표현될 수 있다. 그들은 이러한 규범을 바탕으로 오픈 소스 프로젝트 운영을 효과적으로 통제하지만, 공개(openness)의 모습을 띤다. 게다가 커뮤니티에 강요한 투명성은 오용자가 그들의 게임을 방해하기 위한 경쟁사 혹은 그들의 통제 밖의 개인 기여자의 어떤 시도를 재빨리 알게 되는 것을 의미한다.
반어적으로, 프라이버시 문화 또한 개입(intervention)을 어렵게 한다. 참여자의 개별 상태를 강조하고 그들의 외부 동기를 사적으로 다룸으로써, 회사의 동기에서 일어나는 문제에 관해 이야기하거나 대역 외(out-of-band) 계약을 보고하고 의논하는 것을 참여자에게 부탁하기 어렵다. 기여의 높은 가치도 게임화 된다. 기여할 수 있는 사람을 선호하고, 대신에 물러서고 철수할 수 없거나 않을 사람들이 있는 "행위주의(do-ocracy)" 문화는 커뮤니티에서 쉬쉬하거나 심지어 생각하지 않으려는 미묘한 문제를 알아보는 사람들이 생기게 한다.
아파치는 이를 다루려고 인큐베이터 프로젝트 도입을 조치했다. 인큐베이터는 새로운 프로젝트가 숙련된 멘토의 감독하에 놓이는 "컨테이너"이다. 들어오는 프로젝트를 아파치 방식으로 조정하는 것을 돕는데다가, 그들이 더 큰 커뮤니티의 자율적 당사자가 되기 전까지 문제를 자세히 살필 수도 있다. 더 크거나 범용적인 오픈 소스 커뮤니티가 모방을 고려해야 할 장치이다. 그렇기는 하지만, 프라이버시/투명성 역학 "게임"을 할 수 있는 능력이 남아있다. 시스템이 내부에 결국 그것을 이용할 게임을 포함하는 것은 불가피하다. 유일한 방어는 파울을 기꺼이 불 수 있는 다양하고, 열심이며, 자율적인 커뮤니티이다. 감사하게도, 아파치 역시 가지고 있는 어떤 것이다!
오픈 소스 소프트웨어 주위의 비즈니스 모델을 논의하는 위키피디아 글에서 보듯이 이 주제는 거대하며 논란을 일으킨다. 내가 추천하는 주제에 대해 연구원 Carlo Daffara가 훌륭한 연재물을 냈다. 아마도 오픈 소스에 관련된 모든 비즈니스 모델을 고려할 수는 없지만, 유용한 사례 연구 한가지는 있다. 특히 오픈 코어 비즈니스 모델은 벤처 자본가에 의해 새로운 기본 "오픈 소스 비즈니스 모델"로 주목받았다. 그래서 오픈 코어 모델이 있다는 점은 VC 자본이 새로운 회사를 지지하는 훌륭한 지표이다.
하지만 그것이 고객에게 비용 절감과 유연성을 제공하는 자유 소프트웨어 원칙을 전달하며 지속시키지는 않는다고 나는 주장한다. 결과적으로, 오픈 코어에 의해 살거나 죽는 비즈니스는 코드의 커뮤니티 포크(fork)에 의해 기반이 약화하여 사실상 파산한 Compiere ERP와 같은 운명을 각오해야 한다. 그들이 고객이 요구할 매우 정교한 균형을 관리할 수 없다면, 고객이 따지게 될 것이다.
오픈 코어의 아이디어는 충분히 단순하다. 오픈 코어 비즈니스 모델에 의존하는 회사의 비즈니스 리더의 말을 수정하여 인용한다. 다음과 같이 말했다.
소프트웨어 자유에서의 게임
모든 시스템은 허점이 있다. 이전 섹션에서 알아냈듯이 한 시스템은 그것을 이용할 게임을 암시적으로 내부에 포함한다. 허점을 이용하는 것은 대개는 시스템이 거의 의도치 않은 결과이다. 이는 다른 것에서와같이 오픈 소스에서도 사실이다. 오픈 코어 모델은 오픈 소스를 이용하고 소프트웨어 자유에서의 게임이다. 게임을 한다는 사실이 소프트웨어 자유를 무효로 하지는 않는다. 하지만 정의를 다시 논의하고 참여자 게임을 하기 더 어렵게 해야 함을 암시한다.
오픈 코어는 소프트웨어 자유의 정당한 표현이라기보다는 하나의 게임이다. 왜냐하면, 이것이 소프트웨어 사용자를 위하여 소프트웨어 자유를 구축하지는 않기 때문이다. 오픈 코어 비즈니스에는 오픈 소스이자 기본 기능을 전달하는 코어 패키지가 있다. 패키지를 오픈 소스 라이선스 조건에 자유롭게 사용할 수 있으며 이 점에 관한 문제는 없다. 이는 "오픈 코어"라는 용어를 만든 Andrew Lampitt가 주장한 다음과 같다.
이런 기능을 사용하려면 당신은 스폰서 회사만의 고객이 되어야 한다. 얻을 가치가 제반 비용을 정당화하지 못하거나 시간은 많은데 돈이 없다면 대안이 없고 스스로 할 도리도 없다. 더 나쁜 것은 패키지 사용이 당신을 그 공급자에게 얽매이게 한다는 점이다. 공급자로서 그들이 나쁜 선택으로 판명되거나 당신 비즈니스가 변화가 필요하면, "그것을 택하거나 그대로 둔다." 외의 현실적인 선택권이 없다. 많은 경우 공급자를 해지하는 것은 그 기업용 버전을 사용할 권리를 모두 잃는 것을 의미한다.
뻔히 보이는 곳에 문제 숨기기
오픈 코어 옹호자는 일반적으로 이 점을 완전히 건너뛴다. 그리고 나 같은 반대를 종교적 근본주의 탓으로 돌리기 좋아하고 뻔히 보이는 곳에 문제를 숨긴다. 그들은 이중 라이선스가 대부분의 "오픈 코어" 판매 회사가 판매하는 제한적인 애드온(closed add-ons)에 적용되지 않는 것을 모른다. 또한 (판매 회사가 그렇게 만들기로 선택한다면 고객 자유를 존중할 수 있는) "이중 라이선스"를 (그럴 수 없는) 오픈 코어와 혼동하게 한다.
"활기찬 커뮤니티"를 말하지만, 대부분은 그것들은 사용자 커뮤니티이지 제한적인 애드온의 대안을 제공하는 공동 개발자 커뮤니티가 아니다. "생기 넘치는 에코시스템"을 말하지만, 대안이 아닌 파트너가 에코시스템을 만드는 것을 보장하기 위해 오픈 코어 판매 회사 대부분이 힘을 코드에 들인다고 언급하지 않는다. 오픈 코어는 심지어 Compiere ERP와 같이 훌륭한 시스템이라도 성공을 보장 못 한다. Compiere 설립자 Jorg Janke은 다음과 같이 말했다.
나는 아파치 소프트웨어 재단의 전 재단장에 오픈 코어를 어떻게 바라보는지에 대해 물었다. 그는 대답했다.
유명한 전문가가 말했듯이, 누구는 돈은 있으나 시간이 필요하고, 누구는 시간은 있으나 돈이 필요하다. 오픈 소스는 두 경우 다 자유로운 참여를 허락한다. 하지만 오픈 코어는 그렇지 않다.
오픈 코어는 소프트웨어 사용자를 해친다
분석을 일반화하면, 오픈 코어의 문제는 소프트웨어 자유를 전달하고 구축하는 대신 오픈 코어 비즈니스 모델이 제한된 소프트웨어에 의존하고 판매 회사에의 구속되는 것이다. 오픈 코어 비즈니스는 당신의 자유를 실재하는 단기 이익 혹은 단지 "반짝임(shiny)"과 기꺼이 바꾸기 원한다.
그들은 당신을 구속해 엄청난 이익을 얻으려 존재한다. 당신의 자유를 그들의 이익과 맞바꾸려 한다. 오픈 소스 코어 비즈니스는 정말로 오픈 소스 코어 소프트웨어를 유지한다고 하지만, 실제 그들의 비즈니즈는 오픈 소스와 관련 없다. 이는 오픈 소스라는 깃발 아래에서 오랜 같은 구속에 얽매여 당신이 알아채지 못하기를 바라는 유인 판매(bait-and-switch)이다.
단지 철학적 게임은 아니다. "소프트웨어 자유"는 추상적으로 들릴지도 모른다. 하지만 수많은 비즈니스가 오픈 소스를 사용하게 한 매우 현실적이고 실재적인 이익의 배후를 고려하는 시스템이다. 내가 이전에 썼듯이, 네 가지 자유(소프트웨어를 제한 없이 사용, 연구, 수정, 배포)가 비용 절감과 유연성을 가능하게 함으로써 막대한 시장을 만들었다. 그렇지 않으면 관심 있는 척하지만 자유에 대한 무심한 무관심과 폐지를 일으키는 비즈니스 모델은 도전받을만하다.
소프트웨어 판매 회사라면, 제발 당신 고객의 자유를 존중해 주어라. 돈을 낼 가치가 있다는 것을 알게 하라. 그러지 않기로 했다면, 오픈 소스 주위에서 비즈니스를 하는 유일한 방법이 동일하게 해야 하는 것을 의미하지 않는다. 단지 당신 고객으로부터 소프트웨어 자유를 주지 않는다는 요구를 선택했기 때문임을 기억하라. 이익 낼 수 있는 것에 대해 인위적으로 쓸 수 있는 통제 욕구를 뻔한 좋은 말 뒤에 감추지 마라.
기업용 소프트웨어 소비자라면, 당신의 자유도를 키우는 것이 중요하다. 이것이 변화한 시장 상태에 반응하는 능력의 원천이다. 어떤 거래에서 벗어나게 하는 선택권을 항상 당신이 가져서 공급자와 강력히 협상하는 능력. 어떤 판매 회사의 통제 밖에서 자유 시장으로부터 참모(staff)를 고용하는 능력. 구매하는 시장이 경쟁적으로 남아있어 지속적인 새로운 혁신을 기대하는 능력. 궁극적으로, 자유를 포기함으로써 돈을 절약하는 것은 다시는 돈을 절약할 수 없음을 의미한다.
저작권 축적?
저작권 축적 논란이라는 주제는 오픈 소스 커뮤니티에서 필연적이다. 이것은 필수적이지 않다면 피해야 하는 거의 불필요한 예외적 도구라는 것이 나의 입장이다. 왜냐하면, 오픈 소스 커뮤니티 역학에 미치는 부정적인 영향 때문이다. 필요한 드문 경우에, 문제 되는 소프트웨어 커먼즈 주변 전체 커뮤니티의 커뮤니티 이익을 포함하는 법적 실체의 손길로 저작권을 축적해야 한다. 단지 한 회사의 이익을 위해서는 안 된다. 이는 커뮤니티를 해칠 불평등을 만든다.
마찬가지로 유명 해설자가 오픈 소스를 홍보하는 소프트웨어 회사는 돈을 벌려면 저작권 축적을 사용해야 한다고 주장하는 것을 들었다. 겉보기에 합리적으로 들리지만, 이 진술은 순환 논증이라고 생각한다. 저작권 축적이 필요한 모델을 따라 비즈니스를 만들기로 했다면, 그것이 가능한 기여자 계약이 필요하다. 하지만 그런 비즈니스 모델을 사용하는지 혹은 저작권 축적이 불필요한 다른 비즈니스 모델을 선택하는지는 선택의 문제이다. 여기서 한 사업가는 하나의 선택을 한다.
부족함
궁극적으로 비즈니스는 자신의 풍부함과 고객의 부족함을 마주치며 운영하여 서로 도움이 되는 (win-win) 이익을 낸다. 소프트웨어 비즈니스에서 부족함은 알아내기 더 어렵다. 세상은 여전히 산업 혁명에서 승계된 대도시 터미널 집중 방식(hub-and-spoke) 토폴로지로 운영되고 있다. 그럼에도 저작권을 제한적으로 라이선스하여 인공적인 부족함을 만든 것은 지불 수단으로 잘 동작했다. 하지만 직접 조정 수단(direct means mediation)을 연결하는 능력이 인위적인 간섭인 오늘날의 그물망 구조 사회에서 소프트웨어 사용 권리를 청구하는 것은 인터넷에 손상으로 나타나고 주변으로 전해진다. 이는 커뮤니티에 극복할 수 없는 장벽도 만든다.
자유로 가는 초기 단계에서 오픈 소스의 규범을 도입하려는 오래된 회사가 기여자 계약이 필요하다고 생각하는 이유를 알 수 있다. 하지만 인위적인 어제의 부족함으로부터 수익에 의지하는 오늘의 새로운 비즈니스를 시작하는 것은 무례하며 반대를 일으킨다. 오픈 소스 소프트웨어로의 관문에 적용하려는 필요 없이도 클라우드 기반시설, 운용 기술, 스택 통합, 사법권의 차이 등 돈을 벌 수 있는 많은 부족함이 있다. 인위적인 부족함을 만들기 위한 저작권 축적의 요구사항은 통제 욕구에 대한 유전적 표시이며, 인터넷이 생성하는 그물망 구조 사회에서 그것은 피하며 일해야 하는 손상의 표시이다.
참여 계약
명확히 하자면, 저작권 양도에 대한 이 경고가 커뮤니티 규범을 확인하고 모든 참여자가 일관된 방식으로 계약을 기록하도록 보장하는 참여자 계약을 하는 것을 금지하는 것은 아니다. 참여자 계약은 다양한 쓰임이 있다. 예를 들어, 아무것도 명시되지 않았을 때 기본 라이선스 조건을 설정할 수 있고, 모든 기여에 독창성을 약속하는 것을 보여줄 수 있다. 이러한 계약은 아주 흔하다.
일부 잠재적인 커뮤니티 멤버를 위해 참여에 장벽을 두기도 한다. 고용주의 법무 자문위원에게 허가받아야 하는 개발자는 그렇게 하려면 상당한 동기 부여가 필요하다. 필수라고 생각하는 참여에 대한 각 장벽을 극복하는 데 필요한 추가적인 커뮤니티를 생성하는 노력 비용을 포함하는 방식으로 비용 이익 분석을 할 필요가 있다.
커뮤니티를 저작권 축적으로 이끄는 필요 중 하나는 라이선스 변화에 대한 미래의 필요에 대해 보호하려는 바람이다. 기여자를 위한 저작권이 원본 기여자에 남아 있다면, 나중에 라이선스를 바꾸려고 허가를 받는 것이 악몽일 수 있다. 하지만 저작권 축적이 가능한 유일한 도구는 아니다. 권리를 아주 넓게 허락하여, 다르지만 보완적인 규범을 가진 다른 라이선스를 추가하기가 매우 쉬운 아파치 라이선스 버전 2와 같은 라이선스를 사용할 수 있다.
대신 프로젝트를 위해 "플러스 라이선스"를 선택할 수 있다. 같은 라이선스의 이후 버전 아래에서 재라이선스를 허락하는 말을 포함한다. "라이선스 업그레이드" 능력은 커뮤니티가 재라이선스하는 것을 원하는 가장 유효한 경우를 다룬다. 파일 수준의 카피레프트("약한 카피레프트")를 원하는 프로젝트는 모질라 퍼블릭 라이선스 버전 2가 현재 최고의 선택이다. 강한 카피레프트 라이선스를 원하는 프로젝트는 GNU 제너럴 퍼블릭 라이선스 버전 3을 원해도 좋고, "또는 이후 버전"이라는 표현을 사용하는 버전 2 라이선스를 택해도 좋다.
누구의 자유?
새로운 비즈니스 설계에서 최후 진단은 자유 소프트웨어의 이점을 누가 얻느냐이다. 당신 혹은 당신과 당신 고객? 오픈 소스를 전복시키는 "이중 라이선스"와 "오픈 코어"에 의한 비즈니스 모델에 근거하여 시작하고 자금을 얻는 새로운 회사의 "거품"이 실제로 끝난다. 더이상 오픈 소스에 관련된 용어의 진실 은폐 속임수에 의지하지 않는다. 왜냐하면, 뛰어난 스타트업의 브랜드화가 너무 많은 사람이 소프트웨어 자유의 일상 현실에 익숙하게 했기 때문이다. 그리고 모든 커뮤니티는 저작권 축적의 위험을 알게 되고 있다.
대신에 더 현명한 전략은 각 경우 각 커뮤니티가 혼자 힘으로 선택하는 방향으로 더 큰 영향력을 구하는 것이다. 인터넷의 디자인 원칙이 손상 주위를 따라 전달하는 것처럼 오픈 소스 커뮤니티도 같게 한다. 운용하는 오픈 소스 라이선스는 항상 누군가 코드를 다른 곳으로 가져가 당신 없이 작업하는 "포크(fork)"를 허락한다. 만약 그렇게 하는 것을 정당화한다면, 하나 이상의 커뮤니티 계층이 함께할 것이다.
아마도 포크에도 불구하고 오픈 소스 커뮤니티를 시뮬레이션하기 위해 파트너와 관계를 이용할 수 있는 부유하고 힘 있는 회사에서 당신이 왔을지도 모른다. 하지만 왜 그렇게 하는가? 대신에 투명성과 프라이버시의 지지자로 지내고 일하라. 다른 커뮤니티 멤버가 투명성을 전복하는 방식으로 행동하게 하는 사적인 계약을 피하라. 코드를 공개적으로 개발하라. 그들에게 얻을 수 있는 통제보다 그들에게 줄 수 있는 가치로 고객과 거래하라.
이렇게 할 때, 커뮤니티에서 당신의 영향력은 강력해질 것이다. 다른 참여자가 당신을 믿고 존경하기 때문에 영향력은 당신이 커뮤니티 결정을 이끌어 갈 수 있도록 한다. 도전에 대하여 다른 커뮤니티 멤버가 당신을 지지하고 변호하도록 한다. 이것이 오픈 소스 시대에서 성공적인 비즈니스를 위한 기반이다. 궁극적으로, 최고 커뮤니티 협업 전략은 영향력을 위해 통제권을 교환하는 것이다.
저자 : Simon Phipps
역자 : 한순보
원문 : Open source community collaboration strategies for the enterprise
비즈니스, 커뮤니티와 개발자를 위한 오픈 소스에 대한 중요 고려사항
지난해 OSCON의 주제는 "분열에서 기본으로(from disruption to default)"였다. 우리는 지난 십 년 동안 오픈 소스가 음지에서 양지로 이동하는 것을 봤다. 오늘날 여느 때보다 더 많은 비즈니스가 오픈 소스의 역할을 전략으로 고려하고 있다. 나는 수많은 비즈니스와 비즈니스 부문에서 처음으로 오픈 소스를 사용하는 이행 과정을 지켜보거나 참여할 기회가 있었고, 어떻게 신구의 모든 소프트웨어 비즈니스를 위해 오픈 소스 전략이 진화하는지도 목격했다.
다수 관점에서 오픈 소스는 리처드 스톨만의 GNU 프로젝트와 BSD 프로젝트 커뮤니티가 수십 년간 다양한 방식으로 설명했던 윤리적 생각인 "소프트웨어 자유"의 실용적인 표현이다. 오픈 소스와 자유 소프트웨어의 요소는 이해하기에 간단하다. 소프트웨어 자유는 어떤 목적으로든 소프트웨어를 사용, 연구, 수정, 배포할 권리를 제공한다. 오픈 소스 정의는 소프트웨어 자유를 지원하는 저작권 라이선스를 찾는 것을 돕는 실용적인 원칙을 가지고 윤리적인 구조의 한 부분을 명확히 설명한다. 하지만 간단한 LEGO 블록이 무한한 창조의 세계를 여는 것처럼 오픈 소스를 생성하는 블록은 다양한 사용 모델을 제공하며 여전히 진화하고 있다.
이 글은 소프트웨어 소비 기관과 소프트웨어 생산자 양 측면에서 오픈 소스 전략의 고려 사항과 구현에 관한 생각의 도구를 제공한다. 당신의 비즈니스 리더가 고려해야 할 개념에 대해 당신이 전달할 수 있을만한 설명을 준비할 수 있도록 하는 것을 목표로 한다. 이 글은 다음을 포함한다.
- 오픈 소스 코드 "커먼즈(commons)" 주위에 생성될 수 있는 다른 계층의 커뮤니티를 이해하는 모델과 그들에게 접근하는 방법 (그리고 해서는 안 되는 방법)
- 오픈 소스 커뮤니티의 투명성과 프라이버시의 공생 관계에 대한 설명
- 기업 오픈 소스에서 고객 가치가 나오는 곳에 대한 설명. 이는 커뮤니티와 고객을 위한 "오픈 코어" 전략에 관한 문제를 분명히 보여준다.
- "영향력을 위한 통제권의 교환"과 같이 모든 예에 작용하는 것으로 보일 수 있는 원칙의 모습
커뮤니티 타입
인터넷 이전의 소프트웨어 선정 모델에서부터 인터넷을 포함하는 모델까지 비즈니스를 위한 여정의 모든 단계에서, 나는 다양한 자유 소프트웨어 커먼즈 주변에서 계층화된 다른 커뮤니티 사이를 구분할 필요를 종종 느꼈다. 커뮤니티 멤버는 자주 ("오픈 소스" 진영이 종종 강조하는) "개발자" 혹은 ("자유 소프트웨어" 진영이 종종 강조하는) "사용자"로 특징지어진다. 그럼에도 "커뮤니티"라는 용어를 모든 방식의 모임에 적용하는 것은 혼란을 일으킨다. 특히 참여 동기 부여에 관하여 혼동을 준다.자유 소프트웨어 커먼즈는 일종의 저장소에 포함된 소프트웨어 몸체(body)인데, 보통은 버전 관리 시스템이지만 때때로 다운로드 디렉터리와 같이 단순하다. 그리고 이것은 저장소 내용물을 누가 수정할 수 있는지 결정하는 규칙과 함께 OSI 인증 오픈 소스 라이선스 하에 허가된다. 또한, 트레이드마크, 토론 포럼, 그리고 다른 자원의 사용에 관한 규칙, 누가 어떠한 규칙을 변경할 수 있고 그렇게 하는 권한을 사람들이 얻는 방법에 대한 규칙이 있기도 하다. 이러한 모든 규칙을 총괄하여 "커뮤니티 거버넌스(community governance)"라고 한다. 좋은 거버넌스란 매우 중요한 주제지만 이 섹션에서 다루지는 않겠다.
많은 회사와 개인의 다양한 커뮤니티 참여를 봤고 경험 많은 다양한 오픈 소스 파트너와 토론하면서, 나는 적어도 네 가지의 명확하게 차별화되는 소프트웨어 커먼즈 중심의 커뮤니티 타입이 두 부류로 있는 것 같다. 변치 않는 절대적인 분류가 아니고 대부분 커뮤니티가 두 타입에 걸쳐 있지만, 이 구별은 커뮤니티에 대해 의논할 때 기업에 도움이 된다.
계층화 모델
커뮤니티 계층에 대해 생각하는 다른 방법이 있기 때문에 이 모델이 모든 종류의 토론에 적합하지는 않다. 특히, 내가 제안하는 모델은 외부에서 커뮤니티 계층을 바라본다. 문맥이 커뮤니티 토론이라면 내부에서 바라보는 모델을 사용하는데도 적절하다. 그러나 단지 하나의 오픈 소스 커뮤니티만 있지도, 한 종류의 커뮤니티만 있는 것조차도 아님을 인식하는 것은 오픈 소스 협업 참여를 원하는 기업에 중대한 점진적인 단계이다.
기업 토론에 유용하다고 내가 발견한 모델에서 커뮤니티 타입은 자유 소프트웨어 커먼즈 주위에서 양파 꺼풀처럼 계층화된다.
중심에서 바깥으로, 커뮤니티 범주는 두 그룹이다.
공동 개발자 커뮤니티 - 프로젝트 코어 소스에 직접 관련된 사람들이 있다. 프로젝트 자체를 관심사가 중복된 부분 집합을 동기화하기로 한 다양한 사람들이 만드는 곳이다. 몇몇은 프로젝트 코드에 작업해서 돈을 받기도 하지만, 모두 그것이 그들이 원하는 코드이기 때문에 참여한다.
배포자 커뮤니티 - 코드와의 주요 관련성이 개발 환경 및 스택을 형성하는 다른 소프트웨어와 결합하여 커뮤니티 멤버가 설정하고 배포하는 실행 인스턴스(instance)를 포함하는 사람들이 있다. 그들은 버그 리포트, 테스트 케이스, 가끔 수정에 기여하지만, 프로젝트 코드 자체를 쓰지는 않는다. 설정, 배포와 사용에 전문가이다. 또한, 다른 사람을 그렇게 하도록 훈련하게 시킨다.
이들은 각각 두 하위 범주로 더 구분할 수 있다.
공동 개발자 커뮤니티:
- 코어 공동 개발자 - 커먼즈에서 코드를 구현하고, 진화시키고, 유지하면서 기여하는 사람들이다. 우수한 실적을 올리면 코드의 민감한 부분을 바꿀 수 있는 높은 퍼미션을 가질 것이다. 소프트웨어의 사용자 경험을 설계하는 전문가를 포함할 수도 있다. 다수는 자신의 고용주를 위해 일하기보다는 프로젝트를 위해 일한다고 말하고, 일부는 여러 다른 고용주를 위해 같은 코드에서 작업했을 수 있다. 당신이 존경하고 다가가고 싶어할 만한 강력한 문화를 가질 것 같다. 중요한 점은 심지어 당신 회사가 자금의 주요한 근원이라 해도 누구도 이 커뮤니티에 자동으로 가입하거나 혹은 존경을 받을 권리를 갖지 못한다. 당신의 스타 개발자 혹은 프로그램 매니저도 그 권리를 가질 때 다른 사람과 같게 가진다. 커뮤니티 계층의 어떤 점이라도 관리 통제하려는 시도는 가장 환영받지 못하고 손상(damage)으로 생각될 것이다. 게다가, 그들은 "개발자 프로그램"과 같은 마케팅 메시지를 환영하지 않을 것이다.
- 확장 공동 개발자 (익스텐더(extender)) - 커먼즈에서 작업을 만들고(build on), 향상하고, 종합하는 소프트웨어 및 다른 자원을 공동 개발하는 사람들이다. 코드를 지역화하고 다른 플랫폼에 이식하고, 다른 운영 체제 시스템 배포 등을 위해 패키지로 만든다. 익스텐젼, 플러그인, 새로운 기능의 프로토타입, 샘플 설정 등을 만든다. 문서화와 강의 자료에 대한 작업을 한다. 이러한 모든 것을 위한 도구에 관심은 있지만, 마케팅 활동 대상을 썩 환영할 것 같지는 않다.
- 배포-개발자 - 커먼즈의 콘텐츠를 가지고 배포하기 위하여 설정하고 개별화(customize)하는 사람들이다. 프로젝트의 열렬한 옹호자이며 특정 애플리케이션을 설치하는 법에 매우 익숙하다. 모든 설정 세부 사항, 설치에서 튜닝과 완벽함을 위한 비결, 소프트웨어를 안전하게 하고 보호하는 방법을 안다. 인하우스(in-house) 개발자를 특정한 기업 애플리케이션과 함께하는 프로젝트와 통합하는 것을 잘한다. 경쟁적인 제품과 상호보완적인 제품 모두에 관심이 많고, 개발자 프로그램을 잘 수용한다. 사용자 그룹에서 가장 만나기 쉬운 사람들이다.
- 사용자 - 배포-개발자의 작업을 주문, 명시, 사용하며 (그들 고용주가 임금을 지급하여) 이를 생산적으로 사용하는 사람들이다. 프로젝트를 도우려는 열렬한 옹호자이다. 서비스, 교육, 컨설팅, 보완적이고 경쟁적인 서비스를 제공하는 데 관심이 있다. 개발 기술이 없을 수 있다.
나는 커뮤니티 타입을 위한 이 모델을 시간에 따라 점진적으로 개발해왔다. 이름을 붙이지 않았지만, 특별히 이 모델에서 발생한 다음의 주요 사항을 관찰했다.
1. 네 가지 뚜렷한 커뮤니티 타입이 있지만, 사람들이 다른 커뮤니티에서 다른 역할을 할 수도 있다. 예를 들어, 운영 체제 배포 작업을 하는 패키지 메인테이너(maintainer)는 다른 프로젝트로부터 패키징하는 그 코드에 대해서는 익스텐더이며 배포 자체에 관해서는 코어 공동 개발자이다. 배포자로서 버그 리포트를 제공하는 사람들은 다른 커뮤니티에서는 공동 개발자일 수도 있다.
2. 주어진 커뮤니티에서 여러 역할을 할 수도 있다. 예를 들어, 배포-개발자는 배포하는 내내 문제를 다룰 때 공동 개발자로서 코드에 기여할 수 있다. 테스터는 문서 작성자와 같이 여러 계층에 걸칠 수 있다. 네 계층 모두에서 많은 사람은 사용자이기도 하다.
3. 참여하는 동안에 커먼즈에 기여할 여러 방법이 있다. 사용자는 종종 문서화, 사례 연구, 버그 리포트, 기능 요청을 하는 중요한 원천이며, 사용자의 역할은 전혀 사소하지 않다. 성숙한 커뮤니티는 프로젝트에 기여하는 다양한 방법을 인정할 것이다.
4. 사람들이 보호할 필요가 있는 자유는 역할에 따라 다르다. 예를 들어, 사용자는 락인(lock-in)으로부터 보호받는 것을 중요한 자유로 생각하며 설계에 오픈 표준을 사용할 뿐만 아니라 자신들을 대신해 일하는 배포-개발자를 선택하기를 원하기 쉽다. 네 가지 원조 자유가 기준점을 제공하지만, 이들을 각각의 "계층"으로 신중하게 해석할 필요가 있어서 부드러운 운영에 필수적인 자유를 이해하고 존경해야 한다고 나는 점점 확신한다.
5. 상업적인 기관이 커뮤니티에 연관되는 방법은 커뮤니티 활동에서의 역할과 또한 영향을 미치고 싶은 사람들의 역할 둘 다 존중해야 한다. 예를 들어, 모두를 배포-개발자인 것처럼 대하면 공동 개발자 모두에게서 부정적인 반응을 얻을 것이다. 마케팅 메시지를 모두에게 널리 알리는 것보다 가장 영향력 있는 커뮤니티 멤버들을 소원하게 하는 더 빠른 방법은 없다.
6. 오픈 소스 커뮤니티를 모델화하는 많은 방법이 있지만 나는 Sun Microsystems에서 엔지니어링, 마케팅, 관리 팀에게 커뮤니티 참여를 조언할 때 이 모델을 광범위하게 사용했다. 역할 구별을 위한 공유된 용어 집합을 갖는 것은 모두가 "커뮤니티"라고 할 때 같은 것을 의미한다고 따로 가정할 필요가 없도록 하는 데 중요했다.
7. 소프트웨어 회사 사람들은 흔히 "커뮤니티"를 "시장"과 동의어로 생각한다. 기업 소프트웨어 소비자도 흔히 "커뮤니티"를 "무상 지원"의 동의어라고 생각한다. 둘 다 의미가 있지만, 커뮤니티 계층화의 올바른 이해가 이러한 잘못된 연상에서 오는 경력 제약(career-limiting) 결정과 회사 손상(company-damaging) 행위를 피하게 한다.
투명성과 프라이버시
어떤 "계층"이 관련되든지 성공적인 오픈 소스 커뮤니티를 위한 비결 하나는 모든 참여자의 평등이다. 평등은 과부하가 걸릴 만큼 지나치게 많이 사용한 단어이다. 하지만 오픈 소스 커뮤니티에서 평등은 커뮤니티 안에서의 모든 행위 주변의 투명성과 커뮤니티 행위 범위 밖에서 모든 참여자의 프라이버시 존중을 결합해서 생긴 실질적 결과이다. 평등이 자동으로 민주주의를 의미하지는 않지만, 기여 자체로만 근거한 상호 존중을 의미한다.진정한 오픈 커뮤니티는 참여자의 프라이버시와 독립을 존중할 뿐만 아니라 투명성에 강력한 가치를 둔다. 결과적으로 그러한 커뮤니티가 상업적인 단체에 이로운 저작권 양도(assignment)을 하지도 않을 것이다. 이유는 다음과 같다.
관심사 동기화
사람들이 처음 커뮤니티에 참여하는 이유를 생각해 보는 것은 중요하다. 건강한 오픈 소스 커뮤니티에서 너그러움과 자선 활동이 대개 많이 있지만, 그것이 참여의 주요 이유는 아니다. 오픈 소스 커뮤니티는 많은 당사자의 개별 관심사를 동기화하면서 시작한다. 각 사람은:
- 자신의 (혹은 고용주의) 돈으로 커뮤니티에 오며,
- 그들을 불러들인 필요를 만족하게 하는 커먼즈 소프트웨어를 얻어내려고 애쓰며,
- 자유롭게 자신의 능력과 기여를 가져온다.
기꺼이 개인 이익을 동기화하고 코드 협업을 하는 환경을 만들기 위해 투명성이 요구된다. 발생하는 각 행위는 그 자체의 가치에 기초해야 한다. 각 코드 커밋(commit)은 이해할 수 있어야 하며, 각 규칙은 이성적이고 정당해야 하며, 각 지출은 설명되고 적절해야 한다.
하지만 투명성을 커뮤니티 밖에 있는 참여자의 삶과 비즈니스 이익으로 확장할 필요는 없다. 커뮤니티에 관련한 당신의 동기는 내 기여와 직접적인 관련이 없다. 왜냐하면, 커뮤니티에서 우리 관계는 코드에 관한 것이며 코드 범위 밖 관계에 달린 것이 아니기 때문이다.
우리가 커뮤니티 밖에서 관계가 있다면 그 관계가 커뮤니티 멤버로서 행위에 몰래 영향을 미쳐서 아마도 우리 명성과 커뮤니티 안녕에 해를 끼친다는 것을 아는 것이 매우 중요하다. 오픈 소스 커뮤니티에서 본 최악의 문제 중 일부는 커뮤니티 멤버가 사적으로 협상한 후, 대개 커뮤니티 규칙과 관련한 법률주의에 근거하여 기정사실 혹은 거짓된 합리화를 커뮤니티에 결론으로서 가져와서 일어난다.
코드, 커뮤니티 그리고 그들이 상호작용하는 법은 투명하지만 참여하는 동기는 불투명하다. 내 이유는 내게 달려 있고, 당신 것은 당신에 달려 있다. 코드는 스스로 명백하므로 참여 동기는 직접적인 프로젝트의 범위 밖에 있다. 프로젝트 이름 안에서 당신 비즈니스 모델을 내가 수용하도록 강요할 권리가 당신에게는 없다는 점은 중요하다. 프로젝트를 당신이 시작했고 여전히 주요한 자금 출처라도 이것은 사실이다. 일단 오픈 소스 커뮤니티를 만들고 나면, 아무리 역사적으로 훌륭한 기여를 당신이 했더라도, 이것은 사실이다. 통제에 관한 어떤 시도도 역효과를 낳는다.
사적인 동기 부여, 투명한 커뮤니티
따라서 건강한 오픈 소스 커뮤니티에서는 원한다면 나의 동기와 재정을 둘러싼 프라이버시 유지가 자유롭다. 반면에, 모든 코드가 알려지고, 모든 원천이 알려지고, 모든 결점이 잠재적으로 알려지고, 모든 디자인 결정이 메일 리스트에 있는 투명한 환경에서 일할 수 있다. 내가 보기에는 프라이버시와 투명성의 결합이 실질적으로 오픈 소스 커뮤니티의 주요 특징이다. "공개 기록의 문제로서 일어나지 않았다면 일어나지 않은 것이다."라는 규칙이 없는 커뮤니티는 소프트웨어 라이선스와 관계없이 문을 닫는다.
오픈 소스는 커뮤니티 수준의 투명성뿐만 아니라 관련된 개인의 프라이버시에 관한 것이다. 둘 사이의 인터페이스에 공식적인 커뮤니티/기여 계약(agreement)이 관련된다. 신뢰를 유지하고 개발 투명성을 가능하게 하며 개인 프라이버시를 허락하기 위해 모든 참여자가 커뮤니티 규범을 받아들인다는 계약을 승인하도록 요청하는 것이 합당하다. 그 규범은 특히 기여의 독창성과 그것들의 병행 출원 특허 가능성과 관련한다.
하지만 그것은 (있다면 "프로젝트 스폰서"도 포함한) 모든 참여자여야 한다. 어떠한 참여자 계약도 커뮤니티 규범을 수용해야 한다. 오웰(Orwell)의 "동물농장"과 다르게, 한 참여자 혹은 참여자의 계층이 "다른 사람 이상"이 되는 기회는 없다.
특권 없음
분명히 한 참여자에게 사적으로 사용하도록 종합한 저작권의 독점적인 이익을 주는 것은 합당하지 않다. 그렇게 하는 것은 투명성-프라이버시 경계를 위반하고 커뮤니티 커먼즈에 불투명한 행위를 가능하게 하여 신뢰를 손상한다. 그리고 그것이 속하지 않은 커뮤니티에 사적인 비즈니스 모델 추론(reasoning)을 도입한다.
저작권 양도를 정당화하기 위한 "우리는 수익을 창출할 수 있어야 한다." 혹은 "우리는 원본 코드에 기여했다."와 같은 주장을 들었다. 하지만 이것들은 개인적이며 커뮤니티의 주장은 아니다. 수익에 대한 당신의 필요는 커뮤니티의 것이 아니며 당신의 것이다. 커뮤니티를 시작하기 전에 이를 바로잡지 않고 OSI 인증 라이선스 하에 코드를 철회할 수 없는 라이선스를 했다면 이는 당신의 문제이다. 당신의 비즈니스 상 필요는 나의 저작권을 당신에게 넘겨주는 이유가 되지 않으므로 제발 요구하지 마라. 나에게 어떤 것을 요구하기 위해 당신의 기여해야 할 양은 존재하지 않는다. 당신의 권리가 당신이 오픈 소스 커뮤니티에 기여하는 양에 비례하지는 않는다.
단순한 철학적 문제가 아니라 실질적이기도 한 문제이다. "오픈 소스 커뮤니티 스폰서 증가에 따른 참여 구조의 역할"에서 Joel West와 Siobhan O’Mahony는 오픈 소스 커뮤니티를 시작하려는 회사가 특권을 유지하려 한다면 결과를 망칠 것이라며 확신한다. 통제하려는 것은 커뮤니티가 당신이 바라는 대로 성장하지 못하게 한다. 또는 결국 당신이 만든 커뮤니티의 당신 주위에서 포킹(forking)하고 작업(working)하게 한다. 이는 전에도 일어났고 계속되며 또 일어날 것이다.
시스템의 게임화
이러한 관심사의 분류에는 물론 제한이 있다. 이러한 토대에서 아파치(Apache) 소프트웨어 재단을 십여 년간 잘 운영했다. 다양한 동료 커뮤니티가 그러한 규칙과 함께했을 때 매우 효과적이었다. 아파치 모델은 존재하는 최고의 범용 오픈 소스 커뮤니티 모델에 가깝다.
하지만 결과적으로 오용자(abusers)가 될 사람들을 자석처럼 끌어오기도 했다. 아파치가 이런 경우를 여러 차례 성공적으로 다루면서, "게임화 된" 높은 투명성과 높은 프라이버시의 결합을 몇 차례 봤다. 다양한 역사의 순간에서 아파치는 더 큰 커뮤니티에 좋지 않은 방법으로 프로젝트에 참여하는 참여사를 봤다. 아파치만의 문제도 아니다. 다른 오픈 소스 커뮤니티가 성숙해지며 그들 모델의 게임화에 직면하는 것이다.
이러한 일이 일어난다. 숙련되고 경험 있는 직원과 소프트웨어 시장의 정치적인 힘이 있는 경험 있고 잘 갖춰진 회사가 사적으로 계약할 수 있다. 이것은 그들 자신의 직원과 파트너 에코시스템의 멤버 사이일 수 있으며, 비공식적으로 표현될 수 있다. 그들은 이러한 규범을 바탕으로 오픈 소스 프로젝트 운영을 효과적으로 통제하지만, 공개(openness)의 모습을 띤다. 게다가 커뮤니티에 강요한 투명성은 오용자가 그들의 게임을 방해하기 위한 경쟁사 혹은 그들의 통제 밖의 개인 기여자의 어떤 시도를 재빨리 알게 되는 것을 의미한다.
반어적으로, 프라이버시 문화 또한 개입(intervention)을 어렵게 한다. 참여자의 개별 상태를 강조하고 그들의 외부 동기를 사적으로 다룸으로써, 회사의 동기에서 일어나는 문제에 관해 이야기하거나 대역 외(out-of-band) 계약을 보고하고 의논하는 것을 참여자에게 부탁하기 어렵다. 기여의 높은 가치도 게임화 된다. 기여할 수 있는 사람을 선호하고, 대신에 물러서고 철수할 수 없거나 않을 사람들이 있는 "행위주의(do-ocracy)" 문화는 커뮤니티에서 쉬쉬하거나 심지어 생각하지 않으려는 미묘한 문제를 알아보는 사람들이 생기게 한다.
아파치는 이를 다루려고 인큐베이터 프로젝트 도입을 조치했다. 인큐베이터는 새로운 프로젝트가 숙련된 멘토의 감독하에 놓이는 "컨테이너"이다. 들어오는 프로젝트를 아파치 방식으로 조정하는 것을 돕는데다가, 그들이 더 큰 커뮤니티의 자율적 당사자가 되기 전까지 문제를 자세히 살필 수도 있다. 더 크거나 범용적인 오픈 소스 커뮤니티가 모방을 고려해야 할 장치이다. 그렇기는 하지만, 프라이버시/투명성 역학 "게임"을 할 수 있는 능력이 남아있다. 시스템이 내부에 결국 그것을 이용할 게임을 포함하는 것은 불가피하다. 유일한 방어는 파울을 기꺼이 불 수 있는 다양하고, 열심이며, 자율적인 커뮤니티이다. 감사하게도, 아파치 역시 가지고 있는 어떤 것이다!
오픈 소스 비즈니스 모델: 오픈 코어는 당신에게 나쁘다
커뮤니티의 타입과 오픈 소스 커뮤니티에서 참여의 성향을 고려해 보았다. 다음 주제는 오픈 소스 커뮤니티 참여자가 사용한 비즈니스 모델의 구조에 대해 생각해보는 것이다. 많은 오픈 소스 비즈니스 모델이 있지만 아주 일반화하면 모두 하나의 일반적인 구조로 추출할 수 있다. 당신의 풍부함으로 고객의 부족함을 채워라. 부족함이 진실하고 만들어내지 않은 것과 풍부함이 온전히 당신 것이라는 점을 보장하는 것이 좋은 오픈 소스 비즈니스 모델의 비결이다.오픈 소스 소프트웨어 주위의 비즈니스 모델을 논의하는 위키피디아 글에서 보듯이 이 주제는 거대하며 논란을 일으킨다. 내가 추천하는 주제에 대해 연구원 Carlo Daffara가 훌륭한 연재물을 냈다. 아마도 오픈 소스에 관련된 모든 비즈니스 모델을 고려할 수는 없지만, 유용한 사례 연구 한가지는 있다. 특히 오픈 코어 비즈니스 모델은 벤처 자본가에 의해 새로운 기본 "오픈 소스 비즈니스 모델"로 주목받았다. 그래서 오픈 코어 모델이 있다는 점은 VC 자본이 새로운 회사를 지지하는 훌륭한 지표이다.
하지만 그것이 고객에게 비용 절감과 유연성을 제공하는 자유 소프트웨어 원칙을 전달하며 지속시키지는 않는다고 나는 주장한다. 결과적으로, 오픈 코어에 의해 살거나 죽는 비즈니스는 코드의 커뮤니티 포크(fork)에 의해 기반이 약화하여 사실상 파산한 Compiere ERP와 같은 운명을 각오해야 한다. 그들이 고객이 요구할 매우 정교한 균형을 관리할 수 없다면, 고객이 따지게 될 것이다.
오픈 코어의 아이디어는 충분히 단순하다. 오픈 코어 비즈니스 모델에 의존하는 회사의 비즈니스 리더의 말을 수정하여 인용한다. 다음과 같이 말했다.
"우리 커뮤니티 판(edition)을 가지고 완전히 동작하는 제품을 내놓는다. 그것을 GPL v3 라이선스 하에 다운로드 할 수 있다. 게다가 돈을 낸다면 기업이 제공하는 기능(feature)을 준다. 이것이 오픈 코어이다."합리적으로 들리지만, 이 방식에는 명시되지 않은 중요한 문제가 있다. 소프트웨어 공급자든 소비자든 이 방식에 전념하기로 하기 전에 문제를 이해하고 그 결정이 충분한 이해를 바탕으로 한다는 것을 보장해야 한다.
소프트웨어 자유에서의 게임
모든 시스템은 허점이 있다. 이전 섹션에서 알아냈듯이 한 시스템은 그것을 이용할 게임을 암시적으로 내부에 포함한다. 허점을 이용하는 것은 대개는 시스템이 거의 의도치 않은 결과이다. 이는 다른 것에서와같이 오픈 소스에서도 사실이다. 오픈 코어 모델은 오픈 소스를 이용하고 소프트웨어 자유에서의 게임이다. 게임을 한다는 사실이 소프트웨어 자유를 무효로 하지는 않는다. 하지만 정의를 다시 논의하고 참여자 게임을 하기 더 어렵게 해야 함을 암시한다.
오픈 코어는 소프트웨어 자유의 정당한 표현이라기보다는 하나의 게임이다. 왜냐하면, 이것이 소프트웨어 사용자를 위하여 소프트웨어 자유를 구축하지는 않기 때문이다. 오픈 코어 비즈니스에는 오픈 소스이자 기본 기능을 전달하는 코어 패키지가 있다. 패키지를 오픈 소스 라이선스 조건에 자유롭게 사용할 수 있으며 이 점에 관한 문제는 없다. 이는 "오픈 코어"라는 용어를 만든 Andrew Lampitt가 주장한 다음과 같다.
"… 어느 정도 고객은 판매 회사로부터의 자유를 보장받는 것을 즐긴다. 판매 회사에 기대하지 못한대도 소스 코드에 "보장된 조건부 날인 증서(guaranteed escrow)" 같은 것이 있다."하지만 생산에 패키지를 실제로 이용하려면 비즈니스는 고성능의 코어 패키지의 경우에서조차도 코어 패키지 기능을 충분히 발견하지 못할 것이다. 어떠한 "추가(extras)" 없이는 대체로 효과적이지 못한 코어 패키지를 발견할 것이다. 그것은 오픈 소스가 아닌 패키지 "기업용 버전"에서만 가능하다.
이런 기능을 사용하려면 당신은 스폰서 회사만의 고객이 되어야 한다. 얻을 가치가 제반 비용을 정당화하지 못하거나 시간은 많은데 돈이 없다면 대안이 없고 스스로 할 도리도 없다. 더 나쁜 것은 패키지 사용이 당신을 그 공급자에게 얽매이게 한다는 점이다. 공급자로서 그들이 나쁜 선택으로 판명되거나 당신 비즈니스가 변화가 필요하면, "그것을 택하거나 그대로 둔다." 외의 현실적인 선택권이 없다. 많은 경우 공급자를 해지하는 것은 그 기업용 버전을 사용할 권리를 모두 잃는 것을 의미한다.
뻔히 보이는 곳에 문제 숨기기
오픈 코어 옹호자는 일반적으로 이 점을 완전히 건너뛴다. 그리고 나 같은 반대를 종교적 근본주의 탓으로 돌리기 좋아하고 뻔히 보이는 곳에 문제를 숨긴다. 그들은 이중 라이선스가 대부분의 "오픈 코어" 판매 회사가 판매하는 제한적인 애드온(closed add-ons)에 적용되지 않는 것을 모른다. 또한 (판매 회사가 그렇게 만들기로 선택한다면 고객 자유를 존중할 수 있는) "이중 라이선스"를 (그럴 수 없는) 오픈 코어와 혼동하게 한다.
"활기찬 커뮤니티"를 말하지만, 대부분은 그것들은 사용자 커뮤니티이지 제한적인 애드온의 대안을 제공하는 공동 개발자 커뮤니티가 아니다. "생기 넘치는 에코시스템"을 말하지만, 대안이 아닌 파트너가 에코시스템을 만드는 것을 보장하기 위해 오픈 코어 판매 회사 대부분이 힘을 코드에 들인다고 언급하지 않는다. 오픈 코어는 심지어 Compiere ERP와 같이 훌륭한 시스템이라도 성공을 보장 못 한다. Compiere 설립자 Jorg Janke은 다음과 같이 말했다.
"확실히 Compiere는 기술 때문에 실패하지는 않았다. 판매와 마케팅 전문가, 실행력의 부족과 전통적 상업 모델을 향한 "업그레이드" 오픈 소스 성향의 파트너와 고객에 대한 잘못된 베팅 때문에 실패했다. 나는 상업적 오픈 소스 모델이 여전히 유효하다고 생각하지만, Compiere는 소유권이 있는(proprietary) 제품 컴포넌트와 오픈인 것 사이 균형에서 도를 넘었다."오픈 소스 프로젝트 주위에 부가 서비스를 추가하는 것이 괜찮지 않다는 것은 아니다. 다른 방식으로, 오픈 소스 운동의 GPL 진영과 BSD 진영 모두는 그러한 능력에 의존한다.
나는 아파치 소프트웨어 재단의 전 재단장에 오픈 코어를 어떻게 바라보는지에 대해 물었다. 그는 대답했다.
"아파치 내에서와같이 오픈 코어는 재단 후원으로 사용자가 무료로 사용하고 배포되는 우수한 제품을 만들어내는 기능이다. 공개적인 제공이 자립하고 커뮤니티의 필요를 다룰 수 있다는 점은 매우 중요하다. 그렇지 않다면 아파치 표준에 맞는 다양한 커뮤니티의 관심을 받을 충분한 매력을 못 가진다. 공개적으로 제공한 것은 관대한 라이선스 하에 배포하고 투명한 방식으로 개발한다. 그러므로 상당한 수익 흐름과 벤처 자본 지원이 있는 아파치 커뮤니티 내의 다양한 협력자는 오픈 옵션을 포함하고 보완하는 자신의 제품을 제공할 수 있다."그렇다. 모든 아파치의 전제는 창업자가 다양한 아파치 프로젝트를 다른 작업을 위한 "코어"로 공유할 수 있다는 것이다. 하지만 모든 경우 아파치 프로젝트는 "사용자에게 우수한 제품을 만드는 기능"을 포함하는 기업용 수준으로 배포하면 필요 충분하다.
유명한 전문가가 말했듯이, 누구는 돈은 있으나 시간이 필요하고, 누구는 시간은 있으나 돈이 필요하다. 오픈 소스는 두 경우 다 자유로운 참여를 허락한다. 하지만 오픈 코어는 그렇지 않다.
오픈 코어는 소프트웨어 사용자를 해친다
분석을 일반화하면, 오픈 코어의 문제는 소프트웨어 자유를 전달하고 구축하는 대신 오픈 코어 비즈니스 모델이 제한된 소프트웨어에 의존하고 판매 회사에의 구속되는 것이다. 오픈 코어 비즈니스는 당신의 자유를 실재하는 단기 이익 혹은 단지 "반짝임(shiny)"과 기꺼이 바꾸기 원한다.
그들은 당신을 구속해 엄청난 이익을 얻으려 존재한다. 당신의 자유를 그들의 이익과 맞바꾸려 한다. 오픈 소스 코어 비즈니스는 정말로 오픈 소스 코어 소프트웨어를 유지한다고 하지만, 실제 그들의 비즈니즈는 오픈 소스와 관련 없다. 이는 오픈 소스라는 깃발 아래에서 오랜 같은 구속에 얽매여 당신이 알아채지 못하기를 바라는 유인 판매(bait-and-switch)이다.
단지 철학적 게임은 아니다. "소프트웨어 자유"는 추상적으로 들릴지도 모른다. 하지만 수많은 비즈니스가 오픈 소스를 사용하게 한 매우 현실적이고 실재적인 이익의 배후를 고려하는 시스템이다. 내가 이전에 썼듯이, 네 가지 자유(소프트웨어를 제한 없이 사용, 연구, 수정, 배포)가 비용 절감과 유연성을 가능하게 함으로써 막대한 시장을 만들었다. 그렇지 않으면 관심 있는 척하지만 자유에 대한 무심한 무관심과 폐지를 일으키는 비즈니스 모델은 도전받을만하다.
소프트웨어 판매 회사라면, 제발 당신 고객의 자유를 존중해 주어라. 돈을 낼 가치가 있다는 것을 알게 하라. 그러지 않기로 했다면, 오픈 소스 주위에서 비즈니스를 하는 유일한 방법이 동일하게 해야 하는 것을 의미하지 않는다. 단지 당신 고객으로부터 소프트웨어 자유를 주지 않는다는 요구를 선택했기 때문임을 기억하라. 이익 낼 수 있는 것에 대해 인위적으로 쓸 수 있는 통제 욕구를 뻔한 좋은 말 뒤에 감추지 마라.
기업용 소프트웨어 소비자라면, 당신의 자유도를 키우는 것이 중요하다. 이것이 변화한 시장 상태에 반응하는 능력의 원천이다. 어떤 거래에서 벗어나게 하는 선택권을 항상 당신이 가져서 공급자와 강력히 협상하는 능력. 어떤 판매 회사의 통제 밖에서 자유 시장으로부터 참모(staff)를 고용하는 능력. 구매하는 시장이 경쟁적으로 남아있어 지속적인 새로운 혁신을 기대하는 능력. 궁극적으로, 자유를 포기함으로써 돈을 절약하는 것은 다시는 돈을 절약할 수 없음을 의미한다.
저작권 축적?
저작권 축적 논란이라는 주제는 오픈 소스 커뮤니티에서 필연적이다. 이것은 필수적이지 않다면 피해야 하는 거의 불필요한 예외적 도구라는 것이 나의 입장이다. 왜냐하면, 오픈 소스 커뮤니티 역학에 미치는 부정적인 영향 때문이다. 필요한 드문 경우에, 문제 되는 소프트웨어 커먼즈 주변 전체 커뮤니티의 커뮤니티 이익을 포함하는 법적 실체의 손길로 저작권을 축적해야 한다. 단지 한 회사의 이익을 위해서는 안 된다. 이는 커뮤니티를 해칠 불평등을 만든다.
마찬가지로 유명 해설자가 오픈 소스를 홍보하는 소프트웨어 회사는 돈을 벌려면 저작권 축적을 사용해야 한다고 주장하는 것을 들었다. 겉보기에 합리적으로 들리지만, 이 진술은 순환 논증이라고 생각한다. 저작권 축적이 필요한 모델을 따라 비즈니스를 만들기로 했다면, 그것이 가능한 기여자 계약이 필요하다. 하지만 그런 비즈니스 모델을 사용하는지 혹은 저작권 축적이 불필요한 다른 비즈니스 모델을 선택하는지는 선택의 문제이다. 여기서 한 사업가는 하나의 선택을 한다.
부족함
궁극적으로 비즈니스는 자신의 풍부함과 고객의 부족함을 마주치며 운영하여 서로 도움이 되는 (win-win) 이익을 낸다. 소프트웨어 비즈니스에서 부족함은 알아내기 더 어렵다. 세상은 여전히 산업 혁명에서 승계된 대도시 터미널 집중 방식(hub-and-spoke) 토폴로지로 운영되고 있다. 그럼에도 저작권을 제한적으로 라이선스하여 인공적인 부족함을 만든 것은 지불 수단으로 잘 동작했다. 하지만 직접 조정 수단(direct means mediation)을 연결하는 능력이 인위적인 간섭인 오늘날의 그물망 구조 사회에서 소프트웨어 사용 권리를 청구하는 것은 인터넷에 손상으로 나타나고 주변으로 전해진다. 이는 커뮤니티에 극복할 수 없는 장벽도 만든다.
자유로 가는 초기 단계에서 오픈 소스의 규범을 도입하려는 오래된 회사가 기여자 계약이 필요하다고 생각하는 이유를 알 수 있다. 하지만 인위적인 어제의 부족함으로부터 수익에 의지하는 오늘의 새로운 비즈니스를 시작하는 것은 무례하며 반대를 일으킨다. 오픈 소스 소프트웨어로의 관문에 적용하려는 필요 없이도 클라우드 기반시설, 운용 기술, 스택 통합, 사법권의 차이 등 돈을 벌 수 있는 많은 부족함이 있다. 인위적인 부족함을 만들기 위한 저작권 축적의 요구사항은 통제 욕구에 대한 유전적 표시이며, 인터넷이 생성하는 그물망 구조 사회에서 그것은 피하며 일해야 하는 손상의 표시이다.
참여 계약
명확히 하자면, 저작권 양도에 대한 이 경고가 커뮤니티 규범을 확인하고 모든 참여자가 일관된 방식으로 계약을 기록하도록 보장하는 참여자 계약을 하는 것을 금지하는 것은 아니다. 참여자 계약은 다양한 쓰임이 있다. 예를 들어, 아무것도 명시되지 않았을 때 기본 라이선스 조건을 설정할 수 있고, 모든 기여에 독창성을 약속하는 것을 보여줄 수 있다. 이러한 계약은 아주 흔하다.
일부 잠재적인 커뮤니티 멤버를 위해 참여에 장벽을 두기도 한다. 고용주의 법무 자문위원에게 허가받아야 하는 개발자는 그렇게 하려면 상당한 동기 부여가 필요하다. 필수라고 생각하는 참여에 대한 각 장벽을 극복하는 데 필요한 추가적인 커뮤니티를 생성하는 노력 비용을 포함하는 방식으로 비용 이익 분석을 할 필요가 있다.
커뮤니티를 저작권 축적으로 이끄는 필요 중 하나는 라이선스 변화에 대한 미래의 필요에 대해 보호하려는 바람이다. 기여자를 위한 저작권이 원본 기여자에 남아 있다면, 나중에 라이선스를 바꾸려고 허가를 받는 것이 악몽일 수 있다. 하지만 저작권 축적이 가능한 유일한 도구는 아니다. 권리를 아주 넓게 허락하여, 다르지만 보완적인 규범을 가진 다른 라이선스를 추가하기가 매우 쉬운 아파치 라이선스 버전 2와 같은 라이선스를 사용할 수 있다.
대신 프로젝트를 위해 "플러스 라이선스"를 선택할 수 있다. 같은 라이선스의 이후 버전 아래에서 재라이선스를 허락하는 말을 포함한다. "라이선스 업그레이드" 능력은 커뮤니티가 재라이선스하는 것을 원하는 가장 유효한 경우를 다룬다. 파일 수준의 카피레프트("약한 카피레프트")를 원하는 프로젝트는 모질라 퍼블릭 라이선스 버전 2가 현재 최고의 선택이다. 강한 카피레프트 라이선스를 원하는 프로젝트는 GNU 제너럴 퍼블릭 라이선스 버전 3을 원해도 좋고, "또는 이후 버전"이라는 표현을 사용하는 버전 2 라이선스를 택해도 좋다.
누구의 자유?
새로운 비즈니스 설계에서 최후 진단은 자유 소프트웨어의 이점을 누가 얻느냐이다. 당신 혹은 당신과 당신 고객? 오픈 소스를 전복시키는 "이중 라이선스"와 "오픈 코어"에 의한 비즈니스 모델에 근거하여 시작하고 자금을 얻는 새로운 회사의 "거품"이 실제로 끝난다. 더이상 오픈 소스에 관련된 용어의 진실 은폐 속임수에 의지하지 않는다. 왜냐하면, 뛰어난 스타트업의 브랜드화가 너무 많은 사람이 소프트웨어 자유의 일상 현실에 익숙하게 했기 때문이다. 그리고 모든 커뮤니티는 저작권 축적의 위험을 알게 되고 있다.
결론: 영향력을 위한 통제권 교환
커뮤니티를 통해 어떻게 기업이 협업하는지에 대한 각각의 예에서, 모범 사례 모두에 가득한 공통된 맥락이 있다. 커뮤니티의 전반적인 도움을 위한 통제이며 그 커뮤니티의 완전한 동의와 함께 허락되지 않는다면, 커뮤니티에서 우리가 더 많은 통제를 하려고 할 때 그것이 역효과를 일으킬 큰 위험이 있다. Hudson/Jenkins 프로젝트와 OpenOffice.org/LibreOffice 프로젝트의 논쟁이 야기될 수 있는 손상을 보여준다.대신에 더 현명한 전략은 각 경우 각 커뮤니티가 혼자 힘으로 선택하는 방향으로 더 큰 영향력을 구하는 것이다. 인터넷의 디자인 원칙이 손상 주위를 따라 전달하는 것처럼 오픈 소스 커뮤니티도 같게 한다. 운용하는 오픈 소스 라이선스는 항상 누군가 코드를 다른 곳으로 가져가 당신 없이 작업하는 "포크(fork)"를 허락한다. 만약 그렇게 하는 것을 정당화한다면, 하나 이상의 커뮤니티 계층이 함께할 것이다.
아마도 포크에도 불구하고 오픈 소스 커뮤니티를 시뮬레이션하기 위해 파트너와 관계를 이용할 수 있는 부유하고 힘 있는 회사에서 당신이 왔을지도 모른다. 하지만 왜 그렇게 하는가? 대신에 투명성과 프라이버시의 지지자로 지내고 일하라. 다른 커뮤니티 멤버가 투명성을 전복하는 방식으로 행동하게 하는 사적인 계약을 피하라. 코드를 공개적으로 개발하라. 그들에게 얻을 수 있는 통제보다 그들에게 줄 수 있는 가치로 고객과 거래하라.
이렇게 할 때, 커뮤니티에서 당신의 영향력은 강력해질 것이다. 다른 참여자가 당신을 믿고 존경하기 때문에 영향력은 당신이 커뮤니티 결정을 이끌어 갈 수 있도록 한다. 도전에 대하여 다른 커뮤니티 멤버가 당신을 지지하고 변호하도록 한다. 이것이 오픈 소스 시대에서 성공적인 비즈니스를 위한 기반이다. 궁극적으로, 최고 커뮤니티 협업 전략은 영향력을 위해 통제권을 교환하는 것이다.
TAG :
이전 글 : 왜 빅데이터인가 : 디지털 신경기관
최신 콘텐츠