“현명한 군주(Benevolent Dictator)” 프로젝트는 유일한 리더가 주도합니다. “현명한 군주” 모델을 논할 때, 사람들이 가장 자주 인용하는 예는 아마도 Linux 커널 프로젝트일 것입니다. 이 프로젝트는 리누스 토르발스가 직접 리드하고 의사결정을 합니다. “현명한 군주”가 되는 것은 쉽지 않습니다. “현명한 군주”는 교제와 커뮤니티 구축 기술, 포괄적이고 깊은 프로젝트 기술 지식, 그리고 평범한 사람을 넘어서는 헌신과 집중이 필요합니다. 하지만 Linux 커널 프로젝트가 보여주듯이, “현명한 군주” 모델은 매우 효과적입니다. 이러한 관리 통제와 정반대인 것은 능력주의 거버넌스 모델로, 이 모델의 참여자는 프로젝트에 기여하고 인정을 받아 프로젝트에 영향을 미칩니다.
프로젝트의 조직 방식은 거버넌스 문서에 설명되어 있습니다. 두 번째 절은 “현명한 군주” 모델을 사용하고 자신의 거버넌스 문서를 만들고자 하는 프로젝트를 위한 템플릿을 제공합니다. 이 템플릿을 그대로 사용할 수도 있고, 구체적 요구에 따라 변경하여 사용할 수도 있습니다. 우리가 제공하는 대부분의 자료와 마찬가지로, OSS Watch에서 왔다고 명시하면, 크리에이티브 커먼즈 라이선스에 따라 이 템플릿을 얻을 수 있으며, 템플릿을 재사용하고 수정할 수 있습니다. 거버넌스 모델의 목적이나 다양한 모델의 장단점에 대한 논의는 우리의 거버넌스 모델 설명 문서를 참조하십시오.
소개
능력주의 모델과 “현명한 군주” 모델은 구조적으로 명백한 차이가 있지만, 둘 다 동일한 오픈소스 이념에 기반합니다. 즉, 코드를 공유하고 모든 사람이 커뮤니티에 기여하도록 장려합니다. 따라서 “현명한 군주”와 능력주의 프로젝트 관리 위원회 모두 충성도를 통해 법적 수단이 아닌 의사결정권을 행사하는 것은 놀라운 일이 아닙니다. “현명한 군주”와 능력주의 프로젝트 관리 위원회 모두 회원이 자유롭게 코드를 얻고 유사한 프로젝트를 만들 수 있다는 것을 알고 있습니다. 사실, 이러한 분화 능력은 오픈소스 커뮤니티의 건전한 발전에 매우 중요합니다. 왜냐하면 프로젝트 거버넌스가 개인이나 개별 기업이 아닌 커뮤니티를 위해 올바른 결정을 내리도록 보장하기 때문입니다. 그럼에도 불구하고, 두 모델은 특히 커뮤니티 내에서 어떻게 의사결정을 하는지에서 상당한 차이가 있습니다.
“현명한 군주” 거버넌스 문서 템플릿
개요
본 프로젝트는 “현명한 군주”가 리드하고, 커뮤니티가 관리합니다. 즉, 커뮤니티가 적극적으로 프로젝트를 일상적으로 유지 관리하고, “현명한 군주”는 프로젝트의 전반적인 전략 방침을 수립하는 책임을 집니다. 의견 차이가 발생하면, “현명한 군주”가 최종 결정권을 가집니다. “현명한 군주”의 책임은 커뮤니티 내부의 분쟁을 해결하고, 프로젝트가 조화롭게 발전하도록 보장하는 것입니다. 커뮤니티의 책임은 적극적인 참여와 기여를 통해 “현명한 군주”의 의사결정을 안내하는 것입니다.
역할과 책임
“현명한 군주”(프로젝트 책임자)
일반적으로 “현명한 군주”(또는 프로젝트 책임자)는 스스로 임명할 수 있습니다. 하지만 커뮤니티는 항상 분화 능력이 있으므로, “현명한 군주”는 커뮤니티에 전면적으로 책임을 져야 합니다. 프로젝트 책임자의 업무는 도전적이며, 그들은 프로젝트의 전략 목표를 설정하고, 커뮤니티와 명확하게 소통하는 책임이 있습니다. 프로젝트 책임자는 또한 전체 커뮤니티를 이해하고, 가능한 한 다양한 상충되는 요구를 충족시키며, 프로젝트의 장기적 발전을 보장해야 합니다.
많은 면에서 “현명한 군주”의 역할은 독재자보다 외교관에 더 가깝습니다. 프로젝트가 확장됨에 따라, 적합한 인물이 프로젝트에 영향을 미치도록 보장하고, 커뮤니티가 단결하여 프로젝트 책임자의 비전을 함께 실현하는 것이 핵심입니다. 따라서 프로젝트 책임자의 책임은 커미터(아래 참조)가 프로젝트에 유리한 올바른 결정을 내리도록 보장하는 것입니다. 일반적으로 커미터가 프로젝트 전략을 따르는 한, 프로젝트 책임자는 그들이 원하는 방식으로 제출하도록 허용합니다.
커미터
커미터는 프로젝트에 가치 있는 기여를 했고, 현재 직접 저장소에 코드를 작성하고 다른 사람의 코드를 선별하는 참여자입니다. 많은 경우 커미터는 프로그래머이지만, 때로는 다른 기여자일 수도 있습니다. 커미터는 usually 프로젝트의 특정 측면에 관심을 가지며, 그들의 전문 기술과 이해 수준으로 커뮤니티와 프로젝트 책임자의 존경을 받습니다. 커미터는 정식 임명이 필요 없으며, 프로젝트 책임자에게 지도와 지원을 제공하는 영향력 있는 커뮤니티 구성원이 바로 커미터입니다.
커미터는 프로젝트의 전반적인 발전 방향을 결정할 수 없습니다. 하지만 그들은 프로젝트 책임자의 중시를 받습니다. 커미터의 책임은 프로젝트 책임자가 커뮤니티 요구와 공동 목표를 이해하도록 보장하고, 프로젝트 개발에 참여하거나 프로젝트에 대한 기여를 촉진하는 것입니다. 그들은 종종 자신이 담당하는 구체적 분야에 비공식적인 통제권을 가지며, 특정 분야의 소스 코드를 직접 수정할 권한이 있습니다. 즉, 커미터는 명확한 의사결정권이 없지만, 그들의 행동은 종종 프로젝트 책임자의 결정과 동등한 효력을 가집니다.
기여자
기여자는 커미터가 되고 싶지 않거나, “현명한 군주”가 아직 그들을 커미터로 임명하지 않은 커뮤니티 구성원입니다. 기여자는 프로젝트에 가치 있는 기여를 하지만(아래 목록 참조), usually 직접 프로젝트 코드를 변경할 권한이 없습니다. 기여자는 메일링 리스트 등 통신 도구와 문제 추적기의 문제에 보고서와 패치를 제출하는 등의 방식으로 프로젝트에 참여합니다. 자세한 내용은 우리의 커뮤니티 도구 문서를 참조하십시오.
누구나 기여자가 될 수 있습니다. 기여자는 프로젝트에 대한 약속이 필요 없고, 구체적 기술 요구 사항이 없으며, 선별 과정도 필요 없습니다. 기여자가 되려면 커뮤니티 구성원이 프로젝트에 한두 가지 유익한 기여를 하면 됩니다.
일부 기여자는 이미 프로젝트의 사용자이며, 다음 한두 가지 분야에서 성과를 냈습니다:
- 신규 사용자 지원(현재 사용자가 종종 신규 사용자를 가장 효과적으로 지원할 수 있음)
- 버그 보고
- 요구 사항 식별
- 디자인 및 웹 디자인 제공
- 프로그래밍
- 프로젝트 인프라 구축 지원
- 문서 작성
- 버그 수정
- 기능 추가
기여자의 프로젝트 경험이 늘어나고 프로젝트에 대한 이해가 깊어짐에 따라, 프로젝트 책임자의 그들에 대한 의존도가 점차 깊어집니다. 이때 그들은 위에서 언급한 대로 점차 커미터의 역할을 맡게 됩니다.
사용자
사용자는 프로젝트에 요구가 있는 커뮤니티 구성원입니다. 그들은 커뮤니티의 가장 중요한 구성원입니다: 사용자가 없으면 프로젝트는 아무런 의미가 없습니다. 누구나 사용자가 될 수 있으며, 구체적 요구 사항이 없습니다.
사용자가 가능한 한 많이 프로젝트와 커뮤니티에 참여하도록 권장합니다. 사용자의 참여는 프로젝트 팀이 사용자의 요구를 충족시킬 수 있도록 보장합니다. 일반적인 사용자 활동에는 (但不限於) 다음이 포함됩니다:
- 프로젝트 홍보
- 신규 사용자 관점에서 개발자에게 프로젝트의 장점과 단점 알리기
- 정신적 지원 제공(“감사합니다” 한마디가 큰 격려)
- 재정적 지원 제공
프로젝트와 커뮤니티에 지속적으로 참여하는 사용자는 종종 점점 더 깊이 관여하게 됨을 발견합니다. 이러한 사용자는 위에서 언급한 대로 기여자로 발전할 수 있습니다.
지원
모든 커뮤니티 참여자가 프로젝트 관리 팀이 신규 사용자에게 지원을 제공하도록 돕도록 권장합니다. 참여자의 지원은 커뮤니티가 성장하고 강해지는 경로 중 하나입니다. 지원을 구하는 사람은 프로젝트에 대한 모든 지원이 자발적이라는 것을 이해해야 하며, 따라서 시간이 허락할 때만 지원이 제공됩니다. 사용자가 응답 시간이나 응답 결과에 보장을 원한다면, 공급자와 지원 서비스 구매 계약을 체결하는 것을 고려해야 합니다.(물론 해당 공급자는 커뮤니티의 활발한 구성원이어야 합니다.) 하지만 자신의 방식대로 프로젝트에 참여하고 다른 사용자를 돕고자 하는 사용자에게 커뮤니티 지원은 이상적인 채널입니다.
기여 프로세스
누구나 기술에 관계없이 다양한 방식으로 프로젝트에 참여할 수 있습니다. 예를 들어, 기여자는 프로젝트 메일링 리스트와 문제 추적기에서 활동하거나, 패치를 제공할 수 있습니다. 참여 방식에 대한 자세한 정보는 우리의 오픈소스 역할 문서를 참조하십시오.
처음 기여를 하는 기여자에게 개발자 메일링 리스트는 도움을 구하는 최선의 도구입니다.
의사결정 프로세스
프로젝트 책임자가 최종 의사결정권을 가지므로, “현명한 군주” 모델은 공식적인 분쟁 해결 프로세스가 필요 없습니다. 커뮤니티가 커미터의 행동이 현명한지 의문을 제기하면, 프로젝트 책임자는 보관된 메일을 검토하여 그들의 이전 결정을 지지하거나 뒤집을 수 있습니다.
종합
“현명한 군주” 거버넌스 구조는 관리하기 쉽지 않으며, 전담 프로젝트 책임자를 임명해야 합니다. 하지만 “현명한 군주” 거버넌스 모델은 그 단순함 때문에 매우 효과적입니다. 이 문서에서 제공하는 템플릿은 합리적으로 관리할 수 있는 모델을 정의하고, 그와 관련된 오픈소스 프로젝트의 주요 역할, 활동, 의사결정 프로세스를 설명합니다.
“현명한 군주” 거버넌스 문서를 만들 때, 프로젝트 책임자와 다른 기여자의 역할에 대한 필요한 정보를 제공하고, 새로운 참여자가 어떻게 프로젝트에 기여할 수 있는지, 그들의 기여가 어떻게 인정받는지 명확히 설명해야 합니다.
원문은 Ross Gardler와 Gabriel Hanganu가 2010년 2월 15일에 발표했으며, 2013년 11월 7일에 마지막으로 업데이트되었습니다.
재게시 출처: 개발자 관계 »
