오픈소스 기여 배경 지식

• 1: 오픈소스 기여의 혜택
• 2: 오픈소스 기여의 유형
• 3: 오픈소스 프로젝트 멤버십
• 4: 오픈소스 프로젝트 주요 문서
• 5: 좋은 기여자가 되기 위해
• 6: 기여하기에 좋은 프로젝트 확인 방법
• 7: 커뮤니케이션 방법

1 - 오픈소스 기여의 혜택

기업은 왜 오픈소스에 기여할까

유지 관리 비용 절감

오픈소스를 수정해도 기여하지 않으면, 새 버전이 나올 때마다 자체 수정 사항을 다시 반영하고 테스트하는 노력이 반복됩니다. 기여하면 수정 사항이 향후 버전에 포함되어 추가 유지보수가 줄어듭니다.

프로젝트 방향에 영향

필요한 기능을 직접 개발해 기여하면, 여러 참여자의 손을 거쳐 그 기능이 안정화되고 고도화됩니다.

우수한 개발자 채용

오픈소스에 적극 기여하는 기업은 커뮤니티에서 좋은 평판을 쌓습니다. 우수한 개발자들은 이런 기업에서 일하고 싶어 합니다.

개발자는 왜 오픈소스에 기여할까

• 공공의 이익에 기여할 수 있습니다. 버그 수정이나 기능 추가로 글로벌 커뮤니티에 공헌합니다.
• 실력을 키울 수 있습니다. 버전 관리, Unit Test, Integration Test, CI/CD 같은 실무 기술을 배웁니다.
• 오픈소스를 깊이 이해하고 기술을 습득합니다. 향후 변경에도 유연하게 대응할 수 있습니다.
• 협업을 배웁니다. 다양한 지역과 시간대의 사람들과 일하며 도구 사용법을 익힙니다.
• 새로운 사람을 만납니다. 공통 관심사로 신뢰 관계를 쌓고 경력 발전에 도움을 받습니다.
• 평판과 경력을 키웁니다. 공개된 기여 활동은 누구에게나 보여줄 수 있어 개인의 평판을 높입니다.
• 리더십을 배웁니다. 팀 구성, 갈등 해결, 우선순위 조정을 경험합니다.

2 - 오픈소스 기여의 유형

오픈소스 프로젝트에는 주로 소프트웨어 개발자들이 소스 코드를 수정해 버그를 고치거나 기능을 개선하는 방식으로 기여합니다. 그러나 개발자만 오픈소스 프로젝트에 기여할 수 있는 것은 아닙니다. 오픈소스 프로젝트에는 다음과 같이 문서화, 디자인 등 다양한 유형의 기여가 필요합니다.

문서 작성 / 번역

• 프로젝트 문서, 튜토리얼을 작성합니다. (예: PyPA’s contributors did)
• 프로젝트의 뉴스레터를 작성하거나 메일링 리스트의 중요 사항을 요약합니다.
• 프로젝트 문서를 자국어로 번역합니다.

테스트 / 이슈 생성

• 소프트웨어가 정상적으로 동작하는지 테스트합니다.
• 문서에 기재된 대로 빌드와 설치가 되는지 테스트합니다.
• 문서와 API가 일관성 있게 작성되었는지 확인합니다.

디자인

• 프로젝트 웹사이트의 레이아웃, 메뉴 등을 개선합니다. (예: Drupal suggest)
• 프로젝트가 일관성 있는 디자인을 가질 수 있도록 스타일 가이드를 만듭니다.
• 새로운 로고나 티셔츠를 만드는 데 기여합니다. (예: hapi.js’s contributors did)

코드 작성 / 리뷰

• 해결할 수 있는 오픈된 이슈를 찾습니다. (예: @dianjin did for Leaflet)
• 새로운 기능을 추가합니다.
• 자동화를 위한 도구와 테스팅을 개선합니다.
• 다른 사람이 제출한 코드를 리뷰합니다.
• 다른 기여자의 멘토가 됩니다. (예: @ereichert did for @bronzdoc on Rust)

마케팅

• SNS, 세미나 발표 등 다양한 방법으로 프로젝트의 목적과 효용성을 홍보합니다.

이벤트 행사

• 프로젝트의 콘퍼런스, 워크숍, 밋업 등 다양한 모임을 기획하고 주관합니다. (예: fzamperin did for NodeSchool)

3 - 오픈소스 프로젝트 멤버십

오픈소스 프로젝트는 어떻게 공동 작업으로 고품질 소프트웨어 개발을 지속할 수 있을까요? 서로 모르는 여러 사람이 어떻게 코드를 함께 작성하며 안정적인 소프트웨어를 만들어 낼 수 있을까요? 오픈소스 프로젝트는 명확한 역할 구분으로 이를 실현합니다.

리더 (Leader)

모든 프로젝트에는 리더가 있으며, 일반적으로 창시자가 그 역할을 맡습니다. 리더는 프로젝트의 방향을 결정하며, 의사 결정이 필요할 때 최종 결정을 담당합니다. 리더는 개인일 수도 있지만, 규모가 큰 프로젝트는 운영 위원회(Steering Committee)를 조직하여 리더의 역할을 수행합니다.

• 예를 들어 Linus Torvalds는 Linux Kernel의 원저작자로서 진행 상황의 모든 사안에 최종 결정권이 있습니다.
• Node.js 프로젝트는 Technical Steering Committee가 리더의 역할을 수행합니다.

메인테이너 (Maintainer)

메인테이너는 핵심 기여자로서 프로젝트에서 가장 신뢰할 수 있는 기술 역량을 보유한 사람들입니다. 리더로부터 특정 영역을 위임받아 주도적으로 관리하는 역할을 맡습니다.

커미터 (Committer)

커미터는 프로젝트 내 특정 모듈의 코드를 충분히 이해하면서 정기적으로 기여하는 사람들입니다. 기여자의 기여를 리뷰하고 승인할 권한이 있으며, 특정 모듈은 메인테이너의 승인 없이도 Merge 할 수 있습니다.

기여자 (Contributor)

누구든지 간단하게라도 기여한 사실이 있다면 기여자입니다. 기여자는 간단한 버그 수정, 문서화 등의 방법으로 오픈소스 프로젝트에 기여합니다. 이러한 기여는 숙련된 커미터와 메인테이너가 리뷰하고 보완한 후 저장소에 Merge 합니다.

사용자 (User)

사용자는 오픈소스 프로젝트에서 프로젝트의 성패를 좌우하는 역할을 맡습니다. 프로젝트가 아무리 잘 준비되었다고 해도 사용하는 사람이 없다면 프로젝트는 성공할 수 없습니다. 사용자는 프로젝트를 사용하면서 버그 리포트, 새로운 기능 제안 등 아이디어를 제공함으로써 프로젝트에 존재의 목적을 부여합니다.

• 프로젝트의 리더나 기여자들이 사용자의 요청을 신중히 듣지 않으면 장기적으로 건강하게 성장하기 어렵습니다.
• 프로젝트는 사용자의 필요를 충족시키는 방향으로 성장해야 지속할 수 있습니다.

4 - 오픈소스 프로젝트 주요 문서

올바르게 기여하려면 각 오픈소스 프로젝트의 동작 방식을 이해하고 프로젝트에서 원하는 대로 활동하는 것이 중요합니다. 대부분의 오픈소스 프로젝트는 README, CONTRIBUTING 등의 문서로 이러한 요구 사항을 안내합니다. 오픈소스 프로젝트에는 다음과 같이 공통으로 사용되는 문서가 있으며, 대개 저장소의 최상위 레벨에 있습니다. 기여하기 전에 이러한 문서를 통해 프로젝트의 문화와 행동 강령, 기여 방법을 익혀야 합니다.

README

README 파일은 프로젝트에 처음 접근했을 때 보이는 파일로, 프로젝트 소개와 이 프로젝트를 사용해야 하는 이유, 사용 방법 등을 설명하는 문서입니다. 어떤 프로젝트인지 파악하려면 반드시 봐야 할 문서입니다.

LICENSE (혹은 COPYING)

LICENSE는 프로젝트를 누구나 사용할 수 있다고 명시하는 오픈소스 라이선스를 담은 파일입니다. 모든 오픈소스 프로젝트는 오픈소스 라이선스가 있어야 합니다. 오픈소스 라이선스가 없다면 오픈소스가 아닙니다. 소스 코드는 공개되었지만 사용하거나 배포할 권리가 부여되지 않은 상태입니다. 이런 소스 코드를 제품이나 서비스에 포함하면 저작권 침해 이슈가 발생할 리스크가 있으니 주의해야 합니다.

CONTRIBUTING

README가 프로젝트를 사용하는 사람들을 위한 문서라면, CONTRIBUTING은 프로젝트에 기여하는 사람들을 위한 문서입니다. 어떤 유형의 기여가 필요한지와 기여하는 방법을 설명하므로, 오픈소스에 기여하려 할 때는 이 문서를 자세히 살펴봐야 합니다. 기여자는 이 문서에서 설명하는 기여 방법을 따라야 합니다.

기여하려는 프로젝트에 CONTRIBUTING 파일이 없다면 커뮤니티에 기여 방법을 문의하세요. 적절한 답변을 받지 못한다면, 기여할 가치가 없는 프로젝트로 보고 다른 프로젝트를 찾아도 됩니다.

CODE OF CONDUCT

CODE OF CONDUCT는 행동수칙, 행동강령이라고도 불리며 프로젝트가 건강하게 유지되기 위한 참가자의 행동 규칙을 정의합니다. 예를 들어 성별, 인종, 종교, 나이 등의 차별이 있어서는 안 되고, 누구나 따뜻하게 환영받으며 안전한 활동을 보장받도록 행동해야 함을 강조합니다. 그리고 누군가 그 규칙을 어길 경우 신고할 방법을 안내합니다.

기타 문서

규모가 큰 오픈소스 프로젝트는 튜토리얼, 거버넌스 정책과 같은 문서도 제공합니다.

5 - 좋은 기여자가 되기 위해

본격적으로 기여 제출을 설명하기 전에 어떻게 하면 좋은 기여자가 될 수 있을지 간단히 살펴봅니다. 물론 프로젝트마다 운영 방식이 다르므로 하나의 정답은 없습니다. 새로운 프로젝트에 참여할 때마다 운영 방식을 익히는 데 시간을 투자해야 합니다. 그렇더라도 다음 사항들은 좋은 기여자가 되는 데 공통으로 도움이 됩니다.

1. 커뮤니티 참여

오픈소스 프로젝트에는 사용자와 개발자들이 모인 커뮤니티가 있습니다. 각 커뮤니티는 참여 방식이 조금씩 다릅니다. 커뮤니티에서 제공하는 문서를 읽고, 메일링 리스트, 포럼, IRC, Slack, Bug tracker 등 주요 커뮤니케이션 채널에 가입하세요.

2. 문화 살펴보기

커뮤니티에 가입한 후에는 기여하기 전에 잠시 커뮤니티의 문화에 익숙해지세요. 지난 커뮤니케이션을 살펴보는 것도 좋은 방법입니다. 이런 과정을 거칠수록 첫 기여가 수락될 가능성이 커집니다.

3. 거버넌스 이해

기여하기 전에 프로젝트 관리와 거버넌스 문서를 통해 프로젝트의 거버넌스 방식을 이해하세요. 누가 어떤 방법으로 결정을 내리는지 알 수 있습니다.

4. 작은 것부터 시작

간단한 버그나 문서 수정으로 시작하세요. 중요도가 크지 않은 작은 기여를 해 보면서 프로세스를 배우고 실수를 수정해 가는 것이 좋습니다. 이러한 경험을 바탕으로 더 크게 기여하면서 점차 프로젝트에 영향을 미칠 수 있습니다.

5. 이벤트 참가

오픈소스 커뮤니티의 다른 참여자와 지속적인 관계를 구축하는 것은 중요합니다. 가장 좋은 방법은 콘퍼런스 등의 이벤트에 참석하는 것입니다. 직접 만나는 것만큼 관계 형성에 좋은 것은 없습니다.

6. 초기 단계부터 자주 기여

어떤 사람은 코드의 양이 상당히 커질 때까지 개발을 마친 다음 한 번에 기여하려 합니다. 이러한 기여는 오픈소스 프로젝트에서 수락되기 쉽지 않습니다. 프로젝트에서 많은 양의 코드를 한꺼번에 리뷰하기도 어렵고, 기여한 코드가 프로젝트가 원하는 방향과 다를 수도 있습니다. 아이디어 단계에서부터 커뮤니티와 논의하고, 개발 초기부터 자주 기여하세요.

6 - 기여하기에 좋은 프로젝트 확인 방법

물론 업무와 연관이 있거나 기술적인 관심이 있는 분야의 오픈소스 프로젝트에 기여하는 것이 좋습니다. 그런 프로젝트가 여러 개라면, 어떤 프로젝트가 기여할 만한지 따져 보는 것도 필요합니다. 그렇지 않으면 애써 기여하고도 아무 응답을 받지 못한 채 묻혀버릴 수 있습니다.

다음은 관심 있는 오픈소스 프로젝트가 기여 활동에 적합한지 확인하기 위한 체크리스트입니다.

1. 오픈소스 라이선스 파일이 있는가

• LICENSE 파일이 있는가? 일반적으로 저장소의 루트 디렉터리에 LICENSE라는 파일이 있습니다.

오픈소스 라이선스가 적용되지 않은 프로젝트라면 오픈소스가 아닙니다. 소프트웨어의 저작권자가 오픈소스 라이선스를 통해 누구나 사용하고 배포할 수 있는 권리를 부여해야 기업은 그 소프트웨어를 자유롭게 사용할 수 있습니다. 오픈소스 라이선스가 없는 소프트웨어를 임의로 사용하면 저작권 침해 등의 법적 리스크를 유발할 수 있습니다.

2. 프로젝트가 활발히 기여를 받고 있는가

• 가장 최근 Commit은 언제인가?
• 얼마나 많은 기여자가 있는가?
• 얼마나 자주 Commit이 있는가?

기여자가 거의 없거나 최근 수년간 Commit이 없다면 관리가 되지 않는 프로젝트로 볼 수 있습니다.

GitHub에서의 Commit 현황은 화면 상단의 “Commits"에서 확인할 수 있습니다.

3. 프로젝트 이슈 확인

• 얼마나 많은 이슈가 오픈되어 있는가?
• 이슈가 오픈되면 메인테이너는 신속히 대응하는가?
• 이슈에 대한 활발한 토론이 있는가?
• 이슈들은 최근 것인가?
• 이슈들이 Close 되고 있는가?

이슈가 오픈되지 않거나, 오픈되더라도 대응이 되지 않는다면 관리가 되지 않는 프로젝트로 볼 수 있습니다.

GitHub에서 Issues 페이지의 “closed” 탭을 보면 Close 된 이슈 현황을 확인할 수 있습니다.

4. 프로젝트의 Pull Request 확인

• 얼마나 많은 Pull Request가 오픈되어 있는가?
• Pull Request가 오픈되면 메인테이너는 신속히 대응하는가?
• Pull Request에 대한 활발한 토론이 있는가?
• Pull Request들은 최근 것인가?
• 얼마나 최근의 Pull Request들이 머지되었는가?

GitHub에서 Pull Request 페이지의 “closed” 탭을 누르면 Close 된 Pull Request를 볼 수 있습니다.

5. 프로젝트가 기여를 환영하는 분위기인가

• 이슈 관련 질문에 메인테이너가 도움이 되는 답변을 하는가?
• 이슈, 포럼, 채팅(슬랙 등)에서 사람들이 친절한가?
• Pull Request를 하면 Review가 진행되는가?
• 메인테이너가 사람들의 기여에 감사 표시를 하는가?

기여를 환영하지 않는 분위기인 프로젝트는 장기적으로 발전하기 어렵습니다. 이런 부분도 기여할 만한 가치가 있는 프로젝트인지 판단하는 기준이 될 수 있습니다.

7 - 커뮤니케이션 방법

오픈소스에 기여하는 모든 과정은 커뮤니티 멤버들과의 커뮤니케이션의 연속입니다. 효과적인 커뮤니케이션을 위해 다음 사항을 기억하세요.

정확한 의사 전달

오류 보고라면 어떤 작업에서 발생했는지, 재현 경로는 어떻게 되는지 정확히 설명하세요. 새로운 아이디어 제안이라면 그 아이디어가 프로젝트에 유용하다고 생각하는 이유를 설명하세요.

먼저 스스로 찾아보기

도움을 요청하기 전에 프로젝트의 README 등 문서, 이슈, 메일링 리스트나 검색을 통해 답을 찾아보세요. 이런 노력을 보여주는 것이 좋습니다.

간결한 대화

내가 보낸 모든 기여는 누군가가 검토해야 합니다. 어떤 프로젝트는 검토하기 어려울 정도로 기여나 요청이 많이 쌓입니다. 따라서 가능한 한 간결하게 요청해야 접수될 가능성이 커집니다.

공개 커뮤니케이션

메인테이너에게 개인적으로 연락하는 것은 좋지 않습니다. 모든 대화를 공개하세요. 이를 통해 더 많은 사람이 배우고 혜택을 받을 수 있습니다.

문의 후 기다리기

메인테이너라도 모든 부분을 완벽히 대응할 수 없습니다. 그들에게도 확인할 시간이 필요합니다.

커뮤니티의 결정 존중

여러분의 아이디어가 프로젝트의 우선순위나 비전과 다를 수 있습니다. 커뮤니티에서 그 아이디어를 채택하지 않기로 할 수도 있습니다. 이를 받아들여야 합니다. 타협점을 찾지 못하거나 결코 동의할 수 없다면, Fork 하여 여러분 자신의 프로젝트를 새롭게 시작하는 것을 고려하세요.

품위 유지

오픈소스 프로젝트에서는 전 세계의 구성원과 협업합니다. 언어, 문화, 지역, 시간대에 따라 소통 방법에 온도 차이가 있습니다. 또한 직접 대면해서 대화하는 것이 아니라 글로 의사소통하기 때문에 어조나 분위기를 정확히 전달하기 어려울 수 있습니다. 이런 어려움을 극복하는 좋은 방법은 상대방의 글을 항상 선의로 해석하는 것입니다. 상대의 제안을 거절할 때도 정중히 하고, 자신의 입장은 명확히 표현하는 것이 좋습니다. 오픈소스라는 인터넷 공간에서 자신을 품위 있게 유지하세요.