오픈 소스#3 - 프로젝트내 의사결정은 어떻게 할까? | 매거진에 참여하세요

성장하는 프로젝트를 위한 거버넌스 이해하기

프로젝트가 성장하고, 사람들이 참여하며, 지속적으로 유지하려고 할 때, 정기적으로 기여하는 사람들을 어떻게 워크플로우에 통합할지 고민될 수 있습니다.

예를 들어, 커밋 권한을 부여하는 방법이나 커뮤니티 내 논쟁을 해결하는 방법 등입니다. 이러한 질문이 있다면, 답변을 준비해두었습니다.

오픈소스 프로젝트에서 사용되는 공식적인 역할 예시

많은 프로젝트가 기여자 역할과 인정 방식에 대해 유사한 구조를 따릅니다.

그러나 이러한 역할의 의미는 전적으로 여러분에게 달려 있습니다. 다음은 대표적인 역할 유형입니다:

• - 유지보수자 (Maintainer)

• - 기여자 (Contributor)

• - 커미터 (Committer)

어떤 프로젝트에서는 유지보수자가 커밋 권한을 가진 유일한 사람일 수도 있고, 어떤 프로젝트에서는 README에 유지보수자로 명시된 사람일 수도 있습니다.

유지보수자는 반드시 코드 작성자일 필요는 없습니다.

프로젝트를 널리 알리는 데 기여했거나, 문서를 작성하여 접근성을 높인 사람도 포함될 수 있습니다.

“유지보수자”는

프로젝트의 방향에 대한 책임감을 가지며, 이를 개선하는 데 헌신하는 사람입니다.

“기여자”는

이슈나 풀 리퀘스트에 댓글을 단 사람, 이슈를 관리하거나 코드를 작성하거나 이벤트를 조직하는 등 프로젝트에 가치를 더하는 사람,

혹은 단 한 번이라도 풀 리퀘스트가 병합된 사람까지 포함할 수 있습니다.

“Node.js에서는 이슈에 댓글을 달거나 코드를 제출하는 모든 사람이 프로젝트 커뮤니티의 일원입니다.

이들이 보이는 것만으로도 사용자가 아닌 기여자가 되었다는 의미입니다.”
— @mikeal, “Healthy Open Source”

“커미터”는

커밋 권한을 가진 사람들을 다른 기여자와 구분하는 데 사용될 수도 있습니다.

역할을 정의할 때는, 기여의 형태를 폭넓게 인정하는 것이 좋습니다. 기술적 역량과 관계없이 탁월한 기여를 한 사람들을 공식적으로 인정하는 것이 도움이 될 수 있습니다.

“사람들은 내가 Django의 ‘창시자’라고 생각하지만, 사실 나는 프로젝트가 만들어진 후 1년 뒤에 고용된 사람일 뿐입니다. (…)
사람들은 내가 프로그래밍 실력 때문에 성공했다고 생각하지만, 사실 나는 평균적인 개발자일 뿐입니다.”
— @jacobian, “PyCon 2015 Keynote”

리더십 역할을 공식화하는 방법

리더십 역할을 공식화하면 사람들이 프로젝트에 대한 소속감을 느끼고, 다른 커뮤니티 구성원들에게 도움을 요청할 사람이 누구인지 명확해집니다.

작은 프로젝트의 경우, 리더들의 이름을 README 또는 CONTRIBUTORS 파일에 추가하는 것만으로도 충분할 수 있습니다.

더 큰 프로젝트에서는 공식 웹사이트가 있다면, 팀 페이지를 만들어 리더들의 목록을 추가하는 것이 좋습니다.

예를 들어, PostgreSQL은 모든 기여자들의 간단한 프로필이 포함된 팀 페이지를 운영합니다.

활발한 기여자 커뮤니티가 있는 경우, 유지보수자로 구성된 “코어 팀”을 만들거나, 보안, 이슈 분류, 커뮤니티 운영 등 특정 분야를 담당하는 하위 팀을 구성할 수도 있습니다.

역할을 지정하기보다는 사람들이 자발적으로 조직화할 수 있도록 하는 것이 좋습니다.

“[우리는] 코어 팀 외에도 여러 ‘하위 팀’을 운영합니다. 각 하위 팀은 언어 설계나 라이브러리와 같은 특정 분야에 집중합니다.

프로젝트 전체의 일관된 비전과 글로벌 조정을 보장하기 위해, 각 하위 팀은 코어 팀 멤버가 이끌도록 합니다.”
— “Rust Governance RFC”

리더십 팀은 별도의 커뮤니케이션 채널(예: IRC)이나 정기 회의를 운영할 수도 있습니다. 예를 들어, cucumber-ruby는 매주 공개적인 사무 시간을 운영합니다.

한 번 역할을 정의했다면, 사람들이 이 역할을 어떻게 맡을 수 있는지에 대한 명확한 프로세스를 문서화하는 것이 중요합니다.

프로젝트의 GOVERNANCE.md에 유지보수자가 되는 방법이나 특정 하위 팀에 합류하는 절차를 기록하세요.

또한, 오픈소스 프로젝트의 투명성을 유지하기 위해, Vossibility와 같은 도구를 활용해 기여 내역을 공개적으로 추적할 수도 있습니다.

마지막으로, 프로젝트가 GitHub에 있다면, 개인 계정에서 GitHub Organization으로 프로젝트를 이전하고 최소한 한 명의 백업 관리자를 추가하는 것이 좋습니다.

이는 권한 관리와 다중 저장소 관리에 용이하며, 프로젝트의 지속성을 보호하는 데 도움이 됩니다.

커밋 권한을 부여하는 시점

어떤 사람들은 기여하는 모든 사람에게 커밋 권한을 부여해야 한다고 생각합니다.

이는 사람들이 프로젝트에 대한 소유권을 느끼도록 장려할 수 있습니다.

반면, 더 크고 복잡한 프로젝트에서는 기여도가 일정 수준 이상인 사람들에게만 커밋 권한을 부여하는 것이 일반적입니다.

어떤 방식이든, 프로젝트 운영자가 가장 편한 방법을 선택하면 됩니다.

GitHub에서는 보호된 브랜치(Protected Branches) 기능을 사용하여 특정 브랜치에 대한 접근 권한을 관리할 수도 있습니다.

“누군가 풀 리퀘스트를 보낼 때마다 커밋 권한을 부여하세요. 처음에는 말도 안 되는 전략처럼 들릴 수도 있지만, GitHub의 진정한 힘을 끌어낼 수 있습니다. (…)
커밋 권한을 부여받은 사람들은 자신의 코드가 병합되지 않을까 걱정하지 않기 때문에, 훨씬 더 많은 노력을 기울이게 됩니다.”
— @felixge, “The Pull Request Hack”

오픈소스 프로젝트의 일반적인 거버넌스 구조

오픈소스 프로젝트에서 흔히 사용되는 거버넌스 구조는 다음과 같습니다:

1. - BDFL (Benevolent Dictator for Life)

   • 프로젝트 창시자가 주요 결정을 내리는 구조입니다.

   • 예: Python

3. - 메리토크라시 (Meritocracy)

   • 기여도가 높은 사람들에게 의사결정권을 부여하는 구조입니다.

   • 예: Apache 프로젝트

5. - 자유 기여 모델 (Liberal Contribution)

   • 현재 기여도를 기준으로 영향력을 부여하며, 주요 결정을 투표가 아닌 합의 과정으로 해결합니다.

   • 예: Node.js, Rust

어떤 모델을 선택할지는 프로젝트에 따라 다르며, 각각 장단점이 있습니다.

이 글은 원문을 번역 및 재가공한 글로, 원문은 아래에서 확인하실 수 있습니다.

https://opensource.guide/leadership-and-governance/