오픈소스 기여하기

• 1: SK텔레콤 오픈소스 기여 Rule
• 2: SK텔레콤 오픈소스 기여 절차
• 3: 기여 제출
• 4: 오픈소스 기여 배경 지식
• 4.1: 오픈소스 기여의 혜택
• 4.2: 오픈소스 기여의 유형
• 4.3: 오픈소스 프로젝트 멤버십
• 4.4: 오픈소스 프로젝트 주요 문서
• 4.5: 좋은 기여자가 되기 위해
• 4.6: 기여하기에 좋은 프로젝트 확인 방법
• 4.7: 커뮤니케이션 방법

1 - SK텔레콤 오픈소스 기여 Rule

SK텔레콤은 오픈소스 커뮤니티와의 협업 가치를 존중하고, 구성원의 외부 오픈소스 프로젝트로의 기여를 장려합니다. 다만 SK텔레콤의 지식재산을 보호하고 의도치 않은 저작권 침해를 막기 위해 지켜야 할 규칙이 있습니다.

승인 받기

오픈소스 기여는 저작권 관점에서 저작자가 저작물을 수정하고 사용하고 배포할 권한을 프로젝트에 부여하는 행위입니다. 때로는 저작권 자체를 프로젝트에 양도하기도 합니다. 일반적으로 고용 기간에 만든 저작물의 저작권은 고용주가 소유하므로, SK텔레콤 구성원이 만든 저작물은 SK텔레콤이 소유합니다. 구성원이 임의로 기여하면 불필요한 저작권 침해 이슈가 생길 수 있습니다.

따라서 기여하려는 프로젝트가 있다면, 최초 기여 전에 기여 절차에 따라 리뷰 요청과 승인을 받으세요.

기여할 권리가 있는 코드

직접 작성한 코드를 기여하세요. 3rd party의 코드를 임의로 기여해서는 안 됩니다.

지식 재산 노출 주의

민감한 정보나 특허 등 기업의 지식재산이 노출될 우려가 있는 코드와 문서는 기여하지 마세요. 기여하려는 코드에 회사의 특허가 포함되어 있다면, 이 특허를 오픈소스 라이선스로 기여해도 되는지 확인하세요. 모호하면 OSRB에 문의하세요.

참고로 Apache-2.0이나 GPL-3.0처럼 명시적 특허 라이선스 조항이 있는 라이선스로 기여하면, 기여한 코드를 구현하는 데 필요한 회사 보유 특허의 실시권까지 함께 허여될 수 있습니다. 특허가 얽힌 코드라면 기여 전에 OSRB의 검토를 받으세요.

코드 품질

수준 이하의 코드는 기여하지 마세요. 이는 기업의 평판에도 영향을 줄 수 있습니다.

CLA 서명 주의

어떤 프로젝트는 모든 기여자에게 CLA(Contributor License Agreement) 서명을 요구합니다. 이는 여러 기여자의 저작물을 관리하면서 생길 수 있는 저작권 분쟁을 줄이기 위한 약정서입니다. 주로 대기업이 주도하는 프로젝트에서 요구합니다.

CLA는 프로젝트마다 다르지만 주로 다음에 동의하는 내용을 담습니다.

• 나(또는 소속 기업)는 기여물을 프로젝트에 기여할 권리가 있다(기여물의 저작자이다).
• 나(또는 소속 기업)는 기여물을 프로젝트가 수정하고 배포하고 관리할 권한을 부여한다.
• 나(또는 소속 기업)는 부여한 권한을 철회하지 않는다.
• 나(또는 소속 기업)는 프로젝트가 향후 라이선스를 변경할 권한을 부여한다.
• 나(또는 소속 기업)는 기여물에 구현된 특허에 대해 프로젝트와 사용자에게 라이선스(특허 실시권)를 허여한다.

드물게 어떤 CLA는 다음 조건에도 동의를 요구합니다.

• 나(또는 소속 기업)는 기여와 동시에 저작권을 프로젝트 또는 관리 조직으로 양도한다.

SK텔레콤은 자사의 지식재산 보호를 위해 저작권 양도를 요구하는 프로젝트로의 기여는 허용하지 않습니다. 따라서 기여하려는 프로젝트가 CLA 서명을 요구하면, 서명 전에 반드시 OSRB에 리뷰를 요청하세요. 대부분의 CLA는 서명해도 문제가 없어 승인이 오래 걸리지 않습니다.

CLA 대신 DCO(Developer Certificate of Origin)를 요구하는 프로젝트도 많습니다. DCO는 저작권이나 특허권을 양도하거나 별도로 허여하는 것이 아니라, 기여물이 본인의 것이며 기여할 권리가 있음을 커밋의 Signed-off-by로 증명하는 경량 방식입니다. DCO 서명 방법은 기여 제출에서 설명합니다.

저작권 표시

구성원이 재직 기간에 만든 저작물의 지식재산은 기본적으로 기업이 소유합니다. 따라서 외부 프로젝트에 코드를 기여할 때 SK텔레콤의 저작권을 표기해야 합니다. 하나 이상의 파일을 기여할 때 파일 상단에 다음과 같이 저작권과 라이선스를 표기합니다.

SPDX-FileCopyrightText: Copyright {연도} SK TELECOM CO., LTD.
SPDX-License-Identifier: {SPDX_license_id}

• {연도}는 파일을 작성한 연도를 적습니다.
• {SPDX_license_id}는 해당 프로젝트의 라이선스 정책에 따릅니다.
• 버그 수정처럼 기존 코드를 일부 수정하는 정도라면 저작권을 따로 표기하지 않아도 됩니다.

이 표기는 REUSE 표준을 따릅니다. 표기 형식은 공개하기의 저작권 표시와 일치시킵니다.

회사 이메일 사용

기여 시 개인 이메일이 아니라 SK텔레콤 이메일을 사용하세요. 이를 통해 구성원은 회사를 대표해 커뮤니티와 소통한다는 책임감을 갖게 되고, SK텔레콤은 오픈소스 기여 활동을 활발히 하는 기업으로 인지도를 높일 수 있습니다.

2 - SK텔레콤 오픈소스 기여 절차

SK텔레콤 기여 Rule에 따라, 구성원은 외부 프로젝트에 기여할 때 다음 절차를 따릅니다. 단, 개요의 의사결정 흐름에서 승인 없이 바로 기여할 수 있는 경우에 해당하면 이 절차를 거치지 않아도 됩니다.

1. 소속 조직 내부 승인

하나의 오픈소스 프로젝트에 기여를 시작하기 전에, 소속 조직의 담당 임원이나 리더에게 승인을 받습니다.

2. 검토 요청

내부 승인을 받은 후 OSRB(opensource@sktelecom.com)에 검토를 요청합니다. 아래 체크리스트의 항목을 모두 채워 요청하면 검토가 빨라집니다.

제출 항목 체크리스트

• 오픈소스 프로젝트 이름
• Repository 주소
• 프로젝트 라이선스
• 기여 목적
• 기여 내용 요약
• 소속 조직 내부 승인 여부
• 프로젝트가 CLA 또는 DCO를 요구하는지 여부

GitHub 이슈 템플릿

사내 이슈 트래커나 GitHub 조직에서 아래 템플릿으로 요청을 접수하면, 빈칸을 채우는 것만으로 제출 항목이 갖춰집니다.

### 오픈소스 기여 검토 요청

- 프로젝트 이름:
- Repository:
- 라이선스:
- 기여 목적:
- 기여 내용 요약:
- 내부 승인(임원/리더):
- CLA/DCO 요구 여부:

처리 예상 소요

검토는 라이선스와 CLA 확인을 포함합니다. 단순 확인은 보통 짧게 끝나고, 추가 확인이 필요하면 더 걸릴 수 있습니다.

OSRB는 프로젝트의 라이선스와 CLA를 검토하고, 이상이 없으면 승인합니다.

3. 승인 후 기여 범위

한 번 승인받은 프로젝트에는 이후 구성원의 재량으로 기여할 수 있습니다. 프로젝트가 바뀌면 다시 검토를 요청합니다.

4. 프로젝트 기여 문서 확인

프로젝트마다 요구하는 절차가 조금씩 다릅니다. 기여 전에 프로젝트의 CONTRIBUTING이나 README를 확인해 다음을 파악합니다.

• 코딩 스타일, 언어, 포매팅, 이슈와 티켓 관리, 릴리스 시기 등의 가이드라인
• CLA 서명 또는 DCO Signed-off-by 요구 여부
• 패치 제출 방식(GitHub Pull Request 또는 메일링 리스트)

5. 기여 제출

기여 Rule에 따라 코드를 다듬은 뒤, 프로젝트가 요구하는 방식으로 기여를 제출합니다.

3 - 기여 제출

승인과 준비를 마쳤다면 프로젝트가 요구하는 방식으로 기여를 제출합니다. 아래는 GitHub 기반 프로젝트의 일반적인 절차입니다.

이전 이력 확인

제출하려는 기여가 이전에 다뤄진 적이 있는지 확인하세요. 프로젝트의 README, 이슈, 메일링 리스트에서 몇 가지 키워드를 검색하면 쉽게 확인할 수 있습니다. 관련 내용이 없다면 이슈를 열거나 Pull Request로 커뮤니케이션을 시작하세요.

작업을 시작하기 전에 먼저 이슈를 열어 어떤 작업을 하려는지 알리는 것이 좋습니다. 중복 작업이나 불필요한 작업을 피할 수 있습니다.

이슈 생성

보통 다음 상황에서 이슈를 생성합니다.

• 스스로 해결할 수 없는 오류 보고
• 새로운 기능이나 아이디어 제안
• 커뮤니티 비전이나 정책에 대한 토론

커뮤니케이션 팁은 다음과 같습니다.

• 다루려는 열린 이슈가 있다면 먼저 댓글을 남겨 중복 작업을 막으세요.
• 오래된 이슈는 이미 해결됐을 수 있으니 작업 전에 댓글로 확인하세요.
• 이슈를 연 뒤 스스로 답을 찾았다면, 답을 댓글로 남기고 이슈를 닫으세요. 이런 문서화도 기여입니다.

Pull Request 생성

기여할 파일이 준비됐다면 Pull Request로 제출합니다. 작업을 일찍 공개해 피드백을 받는 것이 좋으며, 진행 중이라면 제목에 “WIP”(Work in Progress)를 표시하고 이후 커밋을 더할 수 있습니다.

GitHub 기반 프로젝트의 Pull Request 절차는 다음과 같습니다.

Fork

Upstream Repository를 자신의 GitHub 계정으로 Fork 합니다.

Clone

Fork한 Repository를 로컬 작업 디렉토리로 Clone 하고, Upstream을 remote에 추가합니다.

$ git clone https://github.com/$user/[repository]
$ cd [repository]
$ git remote add upstream https://github.com/[upstream]/[repository]
$ git remote -v

브랜치 생성

main 브랜치를 최신 상태로 맞춘 뒤 작업용 브랜치를 만듭니다.

$ git fetch upstream
$ git checkout main
$ git rebase upstream/main
$ git checkout -b myfeature

작업과 커밋

코드를 작업하고 커밋합니다. 프로젝트가 DCO를 요구하면 -s 옵션으로 Signed-off-by를 남깁니다.

$ git commit -s -m '[commit message]'

Push

작업한 브랜치를 자신의 Repository에 push 합니다.

$ git push origin myfeature

이미 push한 브랜치를 rebase 등으로 다시 정리해 push해야 하는 드문 경우에만 force 옵션을 쓰되, 공유 브랜치에는 사용하지 않도록 주의하세요.

Pull Request 생성

GitHub의 자신의 Repository에서 Compare & pull request 버튼으로 Pull Request를 생성합니다. 이후 Upstream 관리자가 검토하여 Merge 여부를 결정합니다.

DCO와 CLA

기여물의 출처를 보증하는 방식으로 DCO와 CLA가 있습니다. 프로젝트가 무엇을 요구하는지 미리 확인하세요.

• DCO는 커밋에 Signed-off-by 한 줄을 남기는 경량 방식입니다. git commit -s로 자동 추가됩니다.
• CLA는 별도 약정서에 서명하는 방식입니다. 저작권 양도를 요구하는 CLA는 서명 전에 기여 Rule에 따라 OSRB에 검토를 요청하세요.

피드백 받기

기여를 제출하면 프로젝트로부터 피드백을 받습니다. 피드백은 기여의 수준을 높이는 과정이므로 열린 태도로 받아들이는 것이 좋습니다. 피드백은 보통 다음 넷 중 하나입니다.

응답이 없는 경우

기여 전에 프로젝트가 활발한지 확인하는 것이 좋습니다. 일주일 이상 응답이 없으면 같은 스레드에 정중하게 검토를 요청하세요. 적절한 담당자를 안다면 @-멘션을 쓰세요. 개인적으로 따로 연락하지 말고 공개 채널로 소통하세요. 그래도 반응이 없을 수 있으니, 다른 기여 방법이나 다른 프로젝트를 찾아보세요.

수정을 요청받는 경우

아이디어 설명이나 코드 수정을 요청받는 것은 일반적입니다. 누군가 시간을 내어 검토했으니 바로 응답하세요. 더 진행할 수 없다면 Maintainer에게 알려 다른 사람이 이어받게 하세요.

거절된 경우

기여가 수락되지 않을 수 있습니다. 이유가 이해되지 않으면 설명을 요청하되, 그 결정을 존중하세요. 끝내 이견이 좁혀지지 않으면 Fork 하여 자신의 프로젝트로 이어갈 수 있습니다. 거절을 다음 기여를 개선하는 기회로 삼으세요.

수락된 경우

축하합니다. 오픈소스 기여에 성공했습니다.

참고 자료

• Make a Pull Request
• First Contributions
• Kubernetes GitHub Workflow

4 - 오픈소스 기여 배경 지식

이 묶음은 “왜"에 답하는 학습 자료입니다. 실제로 무엇을 해야 하는지를 다루는 행동 페이지(기여 Rule, 기여 절차, 기여 제출)와 분리해 두었습니다.

포함 페이지

• 오픈소스 기여의 혜택: 기여가 기업과 개발자에게 주는 이점
• 기여의 유형: 오픈소스 기여에는 어떤 유형이 있나
• 프로젝트 멤버십: 오픈소스 프로젝트에는 누가 있나
• 주요 문서: 오픈소스 프로젝트에는 어떤 문서가 있나
• 좋은 기여자: 어떻게 좋은 기여자가 될 수 있나
• 좋은 프로젝트: 어떤 프로젝트가 기여할 가치가 있나
• 커뮤니케이션: 오픈소스 커뮤니티에서 소통하는 방법

4.1 - 오픈소스 기여의 혜택

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

유지 관리 비용 절감

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

프로젝트 방향에 영향

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

우수한 개발자 채용

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

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

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

4.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)

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

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

리더 (Leader)

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

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

메인테이너 (Maintainer)

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

커미터 (Committer)

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

기여자 (Contributor)

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

사용자 (User)

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

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

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

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

README

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

LICENSE (혹은 COPYING)

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

CONTRIBUTING

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

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

CODE OF CONDUCT

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

기타 문서

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

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

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

1. 커뮤니티 참여

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

2. 문화 살펴보기

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

3. 거버넌스 이해

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

4. 작은 것부터 시작

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

5. 이벤트 참가

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

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

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

4.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가 진행되는가?
• 메인테이너가 사람들의 기여에 감사 표시를 하는가?

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

4.7 - 커뮤니케이션 방법

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

정확한 의사 전달

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

먼저 스스로 찾아보기

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

간결한 대화

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

공개 커뮤니케이션

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

문의 후 기다리기

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

커뮤니티의 결정 존중

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

품위 유지

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