컨트리뷰션 시작하기

컨트리뷰션은 오픈소스 프로젝트에 참여하고 기여하는 모든 활동을 의미합니다. 전 세계 사람들이 다양한 컨트리뷰션 활동을 통해 오픈소스를 발전시키고 있습니다.

사람들이 왜 컨트리뷰션 활동을 하는지, 컨트리뷰션에 어떤 유형이 있는지 알아보고, 컨트리뷰션 전에 확인해야 하는 사항과 컨트리뷰션 시 주의할 점을 살펴보겠습니다.

이 글은 "How to Contribute to Open Source"의 내용을 기반으로 작성되었습니다.

컨트리뷰션의 유형

컨트리뷰션에 대해 일반적으로 오해하는 것이 바로 '소스 코드 수정'만 컨트리뷰션에 해당한다는 것입니다. 소스 코드 수정 이외에 다양한 방법으로 누구든 컨트리뷰션에 첫발을 디딜 수 있습니다. 사용하던 오픈소스에서 버그를 발견했을 때 버그를 알리는 것만으로도 컨트리뷰션을 시작할 수 있습니다.

2016년 발표된 "More Common Than You Think: An In-Depth Study of Casual Contributors"에 따르면 다음과 같이 컨트리뷰션의 30% 이상이 소스 코드 수정 이외의 영역에서 이루어졌습니다.

소스 코드 수정 이외에 어떤 유형의 컨트리뷰션이 있는지 알아보겠습니다.

오타 수정도 컨트리뷰션입니다

소스 코드나 문서에 있는 오타를 수정하는 일도 컨트리뷰션입니다.

다음은 Flux 프로젝트의 README 문서에서 오타인 dipatcher를 dispatcher로 수정한 사례입니다.

번역도 컨트리뷰션입니다

프로젝트에 필요한 문서를 번역하는 일도 컨트리뷰션입니다.

다음은 웨일 확장앱 프로젝트의 README 문서를 영어에서 한글로 번역해 Pull request를 요청한 사례입니다.

가이드 문서 작성도 컨트리뷰션입니다

튜토리얼과 같은 가이드 문서를 작성하는 일도 컨트리뷰션입니다.

다음은 Python 배포 방법을 설명하는 문서를 작성하고 관리하는 Python Packaging User Guide 프로젝트에 새로운 튜토리얼 내용과 개요를 작성해 이슈로 등록한 사례입니다.

디자인 작업도 컨트리뷰션입니다

로고와 같은 디자인 요소를 제작하는 일도 컨트리뷰션입니다.

다음은 Node.js에서 사용하는 웹 서비스 프레임워크인 hapi 프로젝트에 새로운 로고 이미지 만들기를 제안한 사례입니다.

의견 제시도 컨트리뷰션입니다

단순히 프로젝트에 관한 의견을 제시하는 것도 컨트리뷰션입니다.

다음은 JavaScript 코드 분석 도구인 ESLint 프로젝트의 이슈 관리 방법에 관해 의견을 제시한 사례입니다.

기타

앞에서 설명한 유형 외에도 프로젝트의 스타일 가이드를 작성하거나, 중복된 이슈를 정리하는 등 다양한 방법으로 프로젝트에 기여할 수 있습니다.

프로젝트에 도움이 되는 것은 아무리 사소한 것이라도 컨트리뷰션 대상이 될 수 있습니다.

컨트리뷰션 활동 이유

전 세계 사람들이 다양한 컨트리뷰션 활동을 통해 오픈소스를 발전시키고 있습니다. 사람들은 왜 컨트리뷰션 활동을 할까요?

• 사용하던 오픈소스에 불편한 점이나 버그가 있어 개선했을 때, 혼자만 사용한다면 오픈소스를 버전업할 때마다 추가 패치 작업을 해야 합니다. 이러한 번거로움을 줄이기 위해 컨트리뷰션을 하는 경우가 많습니다.
• 오픈소스에 참여하는 전 세계의 개발자에게 멘토링을 받을 수 있어 컨트리뷰션을 하는 경우도 있습니다. 오픈소스 활동을 통해 개발 실력 향상과 영어 실력 향상 두 가지를 모두 노릴 수 있습니다.
• 모든 오픈소스 활동은 공개되므로 본인의 역량을 쉽게 노출시킬 수 있고, 이를 이력서에 활용할 수 있으므로 본인 홍보의 수단으로 컨트리뷰션 활동을 할 수 있습니다. 참여하고 있는 오픈소스를 통해 채용이 될 수도 있고, 인턴 활동을 할 수 있는 기회를 얻을 수도 있습니다.
• 소스 코드가 모두 공개되기 때문에 더 많이 테스트하고 수준 높은 코드 품질을 고민하게 되어 결과적으로 코딩 능력이 향상됩니다. 또한 다른 사람들과 협업을 통해 개발이 진행되기 때문에 문제에 접근하는 시야가 넓어질 수 있습니다.

이 외에도 오픈소스 생태계에 기여해 본인의 명성을 높이고자 활동할 수도 있고, 오픈소스의 발전을 위해 컨트리뷰션 활동을 할 수도 있습니다. 이처럼 다양한 이유의 컨트리뷰션을 통해 오픈소스가 발전하고 있습니다.

컨트리뷰션 전에 알아두기

오픈소스 프로젝트마다 사용하는 어휘도 다르고 규범도 다르며 커뮤니케이션 방법도 다릅니다. 컨트리뷰션 활동을 시작하기 전에 먼저 오픈소스 프로젝트의 기본 구조와 활동할 오픈소스를 선택할 때 고려할 사항을 살펴보겠습니다.

오픈소스 프로젝트의 구조

오픈소스 프로젝트의 구조가 동일하지는 않지만 일반적으로 구성원과 역할이 정의되어 있고, 라이선스나 컨트리뷰션에 대한 가이드 문서가 존재합니다. 또한 협업을 위해 다양한 커뮤니케이션 방법을 사용합니다.

오픈소스 프로젝트 구성원의 역할

대부분의 오픈소스 프로젝트는 다음과 같은 구성원으로 이루어져 있습니다.

• 사용자: 프로젝트를 사용하는 사람입니다.
• 컨트리뷰터: 프로젝트에 컨트리뷰션 활동을 하는 모든 사람입니다.
• 커미터: 다른 사람의 컨트리뷰션 내용을 리뷰하고 프로젝트에 반영할 권한을 가진 컨트리뷰터입니다. 커미터가 없는 프로젝트도 있습니다.
• 메인테이너: 프로젝트의 방향을 설정하고 프로젝트를 관리하는 책임이 있는 컨트리뷰터입니다. 보통 커미터 중 일부가 메인테이너가 됩니다. 메인테이너가 없는 프로젝트도 있습니다.
• 저작자: 프로젝트를 만든 사람 또는 조직입니다.

실제로는 프로젝트마다 구성원의 역할이 다르고 역할에 대한 규정과 구성원이 되는 방법도 다릅니다. 그러므로 컨트리뷰션 활동을 하려는 프로젝트에는 어떤 역할이 있고, 현재 구성원은 누구인지 미리 확인해 보는 것이 좋습니다.

오픈소스 프로젝트의 기본 문서

대부분의 오픈소스 프로젝트에서는 다음과 같은 문서를 작성합니다.

• README 문서: 프로젝트의 목적과 사용 방법을 설명하는 문서입니다.

• LICENSE 문서: 오픈소스 라이선스를 명시한 문서입니다. 모든 오픈소스 프로젝트는 오픈소스 라이선스 하에 배포됩니다. 만약 오픈소스 라이선스 없이 배포된 프로젝트가 있다면 라이선스에 대해 문의해 보는 것으로 첫 컨트리뷰션을 할 수도 있습니다.

  GitHub에서 프로젝트를 관리하는 오픈소스에서는 주로 저장소의 최상위 디렉터리에 라이선스를 명시한 문서가 있습니다.

• CONTRIBUTING 문서: 프로젝트에 어떻게 컨트리뷰션 활동을 할 수 있는지 설명한 문서입니다. 어떤 유형의 컨트리뷰션이 필요한지, 해당 프로젝트의 컨트리뷰션 절차가 어떤지 알 수 있습니다. CONTRIBUTING 문서가 없는 프로젝트도 있지만, 컨트리뷰션 활동을 하는 방법이 명시된 프로젝트라면 다른 사람들의 컨트리뷰션을 환영한다는 것을 알 수 있습니다.

이 외에도 프로젝트에 따라 코딩 컨벤션이나 이슈 템플릿 등의 문서가 있습니다.

오픈소스 프로젝트에서 커뮤니케이션 방식

오픈소스 프로젝트의 구성원은 다양한 방식으로 커뮤니케이션을 합니다. 이슈를 논의하기 위해 이슈 트래커를 사용하는 프로젝트가 있는가 하면, Slack 또는 IRC 같은 실시간 채팅 채널을 사용하는 프로젝트도 있습니다. 기능 제안을 하거나 코드를 주고받기 위해 GitHub의 Pull requests를 활용할 수도 있고, 메일링 리스트를 사용할 수도 있습니다.

프로젝트 성격에 따라 다양한 형태의 커뮤니케이션 방법이 있으므로 미리 확인해 보는 것이 좋습니다.

오픈소스 찾기

가장 좋은 컨트리뷰션 대상은 현재 사용하고 있는 오픈소스입니다. 이미 그 오픈소스가 어떤 비전을 가지고 있고 어떤 문제를 고민하고 있는지 알고 있을 뿐만 아니라, 버그를 알고 있을 수도 있습니다. 또한 가이드 문서의 부실함이나 오타를 알고 있을 수도 있습니다. 사용법을 잘 알고 있기 때문에 조금만 고민한다면 컨트리뷰션 활동을 할 수 있는 부분을 발견할 수 있습니다.

그 외에도 관심이 있는 다른 오픈소스를 새롭게 찾아볼 수 있습니다. 하지만 컨트리뷰션 활동을 시작하기 전에 먼저 해당 오픈소스를 잘 사용해 보는 것이 좋습니다.

컨트리뷰션 활동을 할 수 있는 오픈소스를 찾을 때는 다음과 같은 사이트를 참고할 수 있습니다.

• GitHub의 Explore 메뉴: 유형별 오픈소스와 최신 경향의 오픈소스를 볼 수 있습니다.
• Your First PR: 첫 컨트리뷰션으로 시도하기 좋은 이슈와 새로운 컨트리뷰터의 도움이 필요한 오픈소스를 볼 수 있습니다.
• CodeTriage: 처리할 이슈가 있는 오픈소스를 관심 있는 언어에 따라 찾아 볼 수 있습니다.

컨트리뷰션 활동을 할 오픈소스를 선택할 때에는 컨트리뷰션을 받아 줄 만한 오픈소스인지 미리 확인하는 것이 좋습니다. 성공적인 첫 컨트리뷰션을 위해 미리 확인하면 좋을 몇 가지 질문을 소개합니다. 컨트리뷰션 작업을 시작하기 전에 질문에 있는 사항을 확인하며 잠시 지켜보는 것은 해당 오픈소스를 이해하는 데도 도움이 될 것입니다.

오픈소스 라이선스 하에 배포된 프로젝트인가

• 소스 코드에 LICENSE 문서나 라이선스 정보가 있는지 확인해 보세요. 오픈소스 라이선스 없이 배포된 프로젝트라면 오픈소스가 아닐 수 있으므로 주의해야 합니다. 만약 오픈소스 프로젝트인데 라이선스 정보가 없다면 저작권자에게 문의하거나 라이선스 정보 표시를 제안해 보세요.

커뮤니티가 적극적으로 컨트리뷰션을 수용하는가

• 수정 사항 반영이 잦은지, 프로젝트 내에 컨트리뷰터가 몇 명인지 살펴보세요. 활발하게 수정 사항이 반영되고 있고 컨트리뷰터의 활동이 잦다면 새로운 컨트리뷰션도 환영할 가능성이 높습니다.

• 적극적으로 논의되고 있는 개선 사항이 있는지, 사람들의 논의가 활발한지 확인해 보세요.

• 전체 이슈가 얼마나 있는지, 이슈가 해결되고 있는지, 최신 이슈는 있는지 확인해 보세요. 만약 이슈가 너무 많이 누적되어 있거나 정리되고 있지 않다면 이슈 정리를 제안할 수도 있습니다.

커뮤니티가 새로운 사람들에게 우호적인가

• 컨트리뷰션을 위한 가이드 문서가 잘 되어 있는지 살펴보세요. 컨트리뷰션을 위한 가이드 문서가 잘 되어있다면 컨트리뷰션을 환영한다고 생각할 수 있습니다. 만약 가이드 문서가 없다면 문서 작성을 제안해 보세요.

• 이슈나 새로운 제안이 생성되었을 때 커뮤니티의 구성원들이 빨리 답변해 주는지 확인해 보세요. 새로운 이슈를 생성하거나 제안했을 때 답변이 얼마나 빨리 오는지 예측할 수 있습니다.

컨트리뷰션 시 주의 사항

오픈소스는 여러 사람들이 참여해서 작업하기 때문에 같은 작업을 중복해서 할 수도 있습니다. 컨트리뷰션 활동을 할 오픈소스를 정했다면 작업을 시작하기 전에 먼저 작업하려는 내용이 이미 진행된 적이 있는지 빠르게 확인해야 합니다. README 문서와 이슈 목록, 메일링 리스트, Stack Overflow 등에서 확인한다면 중복된 작업을 미연에 방지할 수 있습니다.

그 외에 컨트리뷰션 활동을 할 때는 다음과 같은 점에 주의해서 활동해야 합니다.

기존에 있는 이슈를 수정하고자 할 때는

기존에 있는 이슈를 수정하고자 할 때는 작업 시작을 다른 사람들이 알 수 있게 이슈에 의견을 다는 것이 좋습니다. 동일한 작업을 다른 사람이 시작하는 것을 예방할 수 있습니다.

만약 수정하려는 이슈가 너무 오랫동안 상태에 변화가 없이 유지되고 있다면 작업 시작 전에 현재 상황을 문의해 보아야 합니다. 다른 곳에서 이미 이슈가 해결된 상태일 수도 있습니다.

규모가 큰 중요 기능을 개발할 때는

규모가 큰 중요 기능을 개발할 때는 개발이 완료된 후에 공유하는 것보다 개발 시작 전에 공유하는 것이 좋습니다. 해당 기능이 프로젝트 진행 방향과 맞지 않을 수도 있고, 이미 개발이 진행되고 있는 기능일 수도 있습니다.

작업한 결과물을 프로젝트에 적용해 달라고 요청할 때는

작업한 결과물을 프로젝트에 적용해 달라고 요청할 때는 프로젝트의 컨트리뷰션 가이드에 따라 요청합니다. 준수해야 하는 코딩 컨벤션이 있을 수도 있고, 사전 테스트를 해야 할 수도 있습니다.

프로젝트의 컨트리뷰션 가이드를 준수하면 수정 사항의 반영 확률을 높일 수 있습니다.

커뮤니티에서 커뮤니케이션을 할 때는

다른 무엇보다도 커뮤니티에서 커뮤니케이션을 할 때는 예의를 지켜 겸손한 자세로 임하는 것이 좋습니다. 오픈소스는 전 세계의 사람들이 협업하는 장이기 때문에 언어, 문화, 지역, 시간대에 따라 문맥의 의미가 다르게 받아들여질 수 있습니다. 언제나 본인의 의사 전달을 공개적으로 명확히 해서 오해가 없도록 하는 것이 좋습니다.

컨트리뷰션 이후

컨트리뷰션 활동을 하고 나면 수정 사항이 프로젝트에 반영되는지 확인해야 합니다. 컨트리뷰션이 프로젝트에 반영되는 것이 가장 이상적이지만 컨트리뷰션이 응답을 받지 못하거나 거절당할 수도 있습니다.

컨트리뷰션 작업을 시작하기 전에 커뮤니티의 활성화 정도와 외부 컨트리뷰션을 환영하는 분위기인지 확인해 보는 것이 좋습니다.

컨트리뷰션이 응답을 받지 못할 수 있습니다

커뮤니티가 활성화되어 있어도 컨트리뷰션이 응답을 받지 못할 수 있습니다. 일주일 넘게 아무런 응답도 받지 못했다면 다시 한 번 이슈를 생성하거나 의견을 달아 확인을 요청할 수 있습니다. 만약 리뷰할 수 있는 적당한 사람을 알고 있다면 직접 의견을 보낼 수도 있습니다. 하지만 개인적으로 리뷰를 요청하거나 연락하는 것은 추천하는 방법은 아닙니다. 의사소통은 언제나 공개적으로 진행하는 것이 좋습니다.

여러 번 요청했음에도 커뮤니티에서 아무런 반응도 없다면 이후에도 응답이 없을 확률이 높습니다. 반응을 기다리는 대신 프로젝트를 포크(fork)해 수정 사항을 직접 반영하는 방법도 있습니다.

컨트리뷰션 내용을 개선하거나 수정해 달라는 요청을 받을 수 있습니다

컨트리뷰션 내용을 개선하거나 수정해 달라는 요청을 받으면 빠르게 답변해 주는 것이 좋습니다. 변경할 수 있는지 없는지, 언제까지 할 수 있는지, 시간이 더 필요한지 등의 내용으로 답변을 보내 주세요.

만약 어떻게 변경해야 할지 모르겠다면 커뮤니티에게 도움을 청할 수도 있습니다. 더 이상 해당 이슈를 위해 작업할 시간이 없다면, 다른 누군가가 기꺼이 이어서 작업할 수도 있으므로 빠르게 상황을 알려 주는 것이 좋습니다.

컨트리뷰션이 거절당할 수도 있습니다

작업한 컨트리뷰션이 우선순위나 프로젝트의 방향과 약간 달라 거절당할 수도 있습니다. 만약 거절 이유를 납득할 수 없다면 거절에 대한 피드백과 추가 설명을 문의할 수 있습니다. 하지만 궁극적으로는 커뮤니티의 결정을 존중해야 합니다.

응답을 받지 못했거나 거절당했다면 프로젝트를 포크해서 새로운 프로젝트로 발전시켜 볼 수 있습니다. 또는 아예 새로운 프로젝트를 만들 수도 있습니다.

새로 만든 프로젝트를 오픈소스로 공개하는 방법은 "오픈소스 프로젝트 공개하기"에서 살펴볼 수 있습니다.