Guide 3.3 Contributing For Developer
- 개발자를 위한 오픈소스 기여 가이드
개발자라면 누구나 자기계발을 통해 역량을 키우고, 보다 우수한 개발자로 성장하기 위한 열망을 갖고 있다. 오픈소스 커뮤니티에 참여하고, 관심있는 오픈소스 프로젝트에 기여하는 것은 개발자로서 역량을 키우고 평판을 높일 수 있는 최고의 방법이다.
여기서는 개발자들이 오픈소스에 기여하기 위해 알아야 할 오픈소스에 대한 기본 지식에 대해 설명한다.
회사에 다니고 있는 직원이라면 오픈소스 프로젝트에 기여하기에 앞서, 소속 기업의 오픈소스 기여 정책을 확인해야 한다. 외부 오픈소스 프로젝트로의 기여를 허용하는지, 어떤 주의 사항이 있는지, 제약 사항은 무엇인지 정확히 파악해야 한다. 기업이 정책적으로 외부 오픈소스 기여를 허용하지 않는 경우, 임의로 기여하는 활동이 예기치 않게 저작권, 특허 및 영업 비밀 등 IP 침해 이슈를 야기시킬 수 있음에 주의해야 한다. 기업이 오픈소스 기여 정책이본인의 기여 활동이
주로 소프트웨어 개발자들이 오픈소스에 기여한다. 그들은 소스 코드를 수정하여 버그를 고치거나, 기능을 개선하는 방식으로 오픈소스에 기여한다. 그러나 개발자들만 오픈소스에 기여할 수 있는 것은 아니다. 오픈소스 커뮤니티는 다음과 같이 문서화, 디자인 등 다양한 유형의 기여를 필요로 한다.
- 프로젝트 문서, 튜터리얼을 작성한다.
- 프로젝트의 뉴스레터를 작성하거나 메일링 리스트의 중요 사항을 요약한다.
- 프로젝트 문서를 자국어로 번역한다.
- 프로젝트 웹사이트의 레이아웃, 메뉴 등을 개선한다.
- 프로젝트가 일관성 있는 디자인을 가질 수 있도록 스타일 가이드를 만든다.
- 새로운 로고 또는 티셔츠를 만드는데 기여한다.
- 해결할 수 있는 오픈된 이슈를 찾는다.
- 새로운 기능을 추가한다.
- 자동화를 위한 도구와 테스팅을 개선한다.
- 프로젝트의 컨퍼런스, 워크샵, 밋업 등 다양한 모임을 기획하고 주관한다.
오픈소스 프로젝트는 팀장, 팀원으로 구분되어 있는게 아닌데, 어떻게 공동 작업이 가능하고 고품질의 소프트웨어 개발이 지속될 수 있을까? 어떻게 서로 모르는 다수의 사람들이 코드를 함께 작성하며 수많은 사람들이 사용하는 안정적인 제품을 만들어 낼 수 있을까? 우수한 오픈소스 프로젝트는 명확한 프로젝트 멤버쉽 역할을 통해 이를 가능하게 한다.
User는 오픈소스의 사용자로서 프로젝트에 목적을 부여하고, 기능, 버그 리포트 등의 방법으로 피드백을 제공함으로써 프로젝트를 발전시키는 데 도움을 줄 수 있다. User는 오픈소스 프로젝트의 성장과 발전에 가장 중요한 그룹이다.
Contributor는 코드, 문서화 등의 방법으로 오픈소스 프로젝트에 기여한다. 이러한 기여는 일반적으로 숙련된 Committer 및 Maintainer에 의해 리뷰 과정을 거치게 돤다.
Committer는 Maintainer의 승인을 받지 않고도 프로젝트의 일부에 직접 커밋할 수 있다.
Maintainer는 Leader로부터 특정 영역을 위임받아서 관리한다.
리더는 의사 결정이 필요할 때 최종 결정을 담당한다.
- 예를 들어, Linus Torvalds는 Linux Kernel의 원저작자로서 진행사항에 대한 모든 것에 대해 최종 결정권을 가지고 있다.
- Node.js 프로젝트와 같은 경우는 Core Technical Committee가 리더의 역할을 수행한다.
올바르게 기여하기 위해서는 각 오픈소스 커뮤니티의 동작 방식을 이해하고 프로젝트에서 원하는 바에 맞추어 활동하는 것이 중요하다. 대부분의 오픈소스 프로젝트는 README, CONTRIBUTING 등의 문서를 통해 이러한 사항을 사용자들에게 제공한다. 오픈소스 프로젝트에서는 다음과 같이 몇가지 공통적으로 사용되는 문서가 있으며, 대개 저장소의 최상위 레벨에 위치한다. 기여하기 전에 이러한 문서를 통해 커뮤니티의 문화와 행동 규범, 기여하는 방법을 익히는 것이 중요하다.
README는 새로운 멤버를 위한 설명서로써 프로젝트가 유용한 이유와 시작 방법에 대해 설명한다.
모든 오픈소스 프로젝트는 오픈소스 라이선스가 있어야 한다. 라이선스가 없다면 오픈소스가 아니다. 오픈소스 라이선스에 대한 자세한 내용은 OO장을 참고할 수 있다.
README는 프로젝트를 사용하는 사람들에게 도움이 되는 반면, CONTRIBUTING은 프로젝트에 기여하는 사람들을 위한 문서이다. 어떤 유형의 기여가 필요한지와 기여하는 방법에 대해 설명하기 때문에 오픈소스에 기여하고자 할 때는 이 문서를 자세히 살펴보아야 한다.
커뮤니티가 건강하게 유지되기 위한 참가자의 행동과 관련된 기본 규칙을 설명한다.
(규모가 큰 오픈소스 프로젝트의 경우) 튜터리얼, 거버넌스 정책과 같은 문서도 있을 수 있다.
기여할 만한 프로젝트인지 먼저 확인하는 것도 필요한다. 그렇지 않으면 수고한 기여가 아무 응답도 받지 못하고 묻혀버릴 수도 있다.
다음은 관심 있는 오픈소스 프로젝트가 기여 활동에 적합한지 확인하기 위한 체크리스트이다.
- LICENSE 파일이 있는가? 일반적으로 저장소의 루트 디렉토리 내에 LICENSE라는 파일이 있다.
오픈소스 라이선스가 적용되지 않은 프로젝트라면 오픈소스가 아니다. 소프트웨어의 저작권자가 오픈소스 라이선스를 통해 누구나 사용하고 배포할 수 있는 권리를 부여해야 기업은 그 소프트웨어를 자유롭게 사용할 수 있다. 오픈소스 라이선스가 없는 소프트웨어를 임의로 사용한다면 저작권 침해 등의 법적 리스크를 유발할 수 있다.
- 가장 최근 Commit은 언제인가?
- 얼마나 많은 기여자가 있는가?
- 얼마나 자주 Commit이 있는가?
기여자가 거의 없거나, 최근 수년간 Commit이 없다면 관리가 되지 않고 있는 프로젝트로 볼 수 있다.
GitHub에서의 Commit 현황은 화면 상단의 "Commits"에서 확인할 수 있다.
- 얼마나 많은 이슈가 오픈되어 있는가?
- 이슈가 오픈되면 Maintainer는 신속히 대응하는가?
- 이슈에 대한 활발한 토론이 있는가?
- 이슈들은 최근 것인가?
- 이슈들이 Close되고 있는가?
이슈가 오픈되지 않고 있거나, 오픈되더라도 대응이 되지 않는다면 관리가 되지 않는 프로젝트로 볼 수 있다.
GitHub에서 Issues 페이지 내 "closed" tab을 보면 Close된 이슈 현황을 확인할 수 있다.
- 얼마나 많은 Pull Request가 오픈되어 있는가?
- Pull Request가 오픈되면 Maintainer는 신속히 대응하는가?
- Pull Request에 대한 활발한 토론이 있는가?
- Pull Request들은 최근 것인가?
- 얼마나 최근의 Pull Request들이 머지되었는가?
GitHub에서 Pull Request 페이지 내 "closed" tab을 누르면 Close된 Pull Request를 볼 수 있다.
- 이슈 관련 질문에 대해 Maintainer가 도움이 되는 답변을 하는가?
- 이슈, 포럼, 채팅 (슬랙 등)에서 사람들이 친절한가?
- Pull Request를 하면 Review가 진행되는가?
- Maintainer가 사람들의 기여에 감사 표시를 하는가?
기여를 환영하지 않는 분위기인 프로젝트는 장기적으로 발전하기가 어렵다. 이런 부분도 기여할 만한 가치가 있는 프로젝트인지를 판단하는 기준이 될 수 있다.
지금까지 오픈소스에 기여하기 위한 프로젝트의 일반적인 구조 및 동작 방식 등에 대해 설명했다. 지금부터는 기업의 구성원이 오픈소스 프로젝트에 기여하기 위해 실제적으로 필요한 사항에 대해 설명한다.
몇차례 언급했지만, 오픈소스 프로젝트마다 기여자에게 요구하는 절차가 다르다.
!!! info * 코딩 스타일, language, formatting, bug/ticket 관리, 릴리즈 시기 등에 대한 다양한 가이드라인을 갖고 있다. * 어떤 프로젝트는 Contributor Agreement를 요구하는 반면, 어떤 프로젝트는 DCO를 요구를 한다. * Patch를 받는 방식도 요즘은 대부분 Github의 Pull Request로 받지만, 어떤 프로젝트는 여전히 Mailing List를 이용하기도 한다.
그렇기 때문에 기여하고자 하는 프로젝트의 프로세스를 제대로 이해하기 위해서는 우선 프로젝트에서 제공하는 문서를 잘 확인해야 한다. 대개의 프로젝트는 CONTRIBUTING 또는 README 파일로 이러한 문서를 제공한다. 예를 들어, Kubernetes는 기여자를 위한 자세한 가이드를 제공한다. (contributing.md : Kubernetes에 기여하기 위한 가이드) 문서에서 요구하는 사항을 잘 준수할수록 우리의 기여가 수락될 가능성이 커진다.
어떤 오픈소스 프로젝트는 기여하기 위해서는 먼저 기여자에게 CLA (Contributor License Agreement)에 서명할 것을 요구한다. 이때 CLA에 임의로 서명하지 말아야 한다.
드문 경우지만, CLA에서 지적 재산권을 완전히 양도할 것을 요구하기도 한다. 어떤 기업은 이러한 CLA에는 서명할 수 없도록 제한하고, 따라서 그 프로젝트에는 기여할 수 없게 한다.
기여를 제출하기 전에 다음 사항을 한번 확인하여 예기치 않은 저작권 침해 이슈 등을 최소화한다.
- 기여할 권리가 있는 코드인가? 직접 작성한 코드라면 문제 되지 않는다. 만약 기여하려는 코드에 직접 작성하지 않은 코드가 포함되었다면 기여할 권리가 있는지 확인이 필요하다.
- 회사의 민감하거나 독점적인 정보가 노출될 수 있는 코드를 제공하지 않는 것이 좋다.
- 기여하려는 코드에 특허가 포함되어 있는지 확인하라. 오픈소스로 기여할 경우 오픈소스 라이선스에 따라 특허를 허여해야 하는데, 이것이 기업의 정책과 부합되는지 사전에 확인해야 한다.
회사 업무와 관련된 오픈소스 프로젝트에 코드를 기여하기 위해서는 기업 의사 결정권자에게 승인을 받는 것이 좋다.
이제 프로젝트의 문서에서 요구하는 절차에 따라 기여를 제출한다. 이때 어떤 기업은 기업의 이메일 계정을 사용하여 기여할 것을 요구한다. 이는, 기업이 오픈소스 활동을 적극적으로 장려한다는 평판을 쌓을 수 있고, 기업 내 오픈소스 기여자 목록을 관리할 수 있기 때문이다. GitHub에 있는 프로젝트에 기여한다면 다음 페이지를 참고하여 이메일 주소를 설정할 수 있다. : How to associate your commit with a sktelecom.com email.
일반적인 오픈소스 프로젝트에 기여 제출 방법과 절차는 다음과 같다.
무엇이든 시작하기 전에 먼저 이전에 다뤄진 적이 있는지 과거 자료를 확인하라. 프로젝트의 README, 이슈, 메일링 리스트를 살펴보세요. 모든 문서를 다 확인할 필요 없이, 몇 가지 키워드를 검색하면 쉽게 확인할 수 있다.
과거 자료에서 관련 내용을 찾을 수 없다면 이슈를 열거나 Pull Request를 통해 커뮤니케이션을 시작할 단계이다. GitHub에서는 Issues와 Pull Request 기능을 제공한다.
- Issues : 대화나 토론을 시작할 수 있다.
- Pull Request : 문제에 대한 솔루션을 기여한다.
Issue 또는 Pull Request를 열기 전에 프로젝트가 제공하는 문서 (일반적으로 CONTRIBUTING 또는 README)를 확인하여 기여 절차 및 방법을 확인한다. 예를 들어 특정 템플릿을 따르도록 요구하거나, 사전 테스트를 요구할 수 있다.
기여를 위한 작업을 시작하기 전에 먼저 Issues를 오픈해서 커뮤니티 구성원에게 먼저 어떤 작업을 하려고 하는지 알리는 것도 좋은 방법이다. 때에 따라 불필요한 작업을 진행하지 않도록 도움을 받을 수 있다.
일반적으로 다음 상황에서 Issue를 생성한다.
- 스스로 해결할 수 없는 오류 보고
- 새로운 기능 또는 아이디어 제안
- 커뮤니티 비전, 또는 정책에 대한 토론
!!! tip "Issue에 대한 커뮤니케이션 Tip" 1. 다루고자 하는 오픈된 Issue가 있다면, 먼저 comment를 남겨서 다른 사람들이 중복으로 작업하지 않게 한다. 2. 오래전에 오픈된 Issue라면, 이미 해결된 것일 수 있다. 작업을 시작하기 전에 comment로 해결이 된 것은 아닌지 확인한다. 3. Issue를 오픈했지만, 나중에 스스로 답을 알아낸 경우, 해당 Issue에 대한 답을 다른 사람도 알 수 있도록 comment를 작성하고 이슈를 close 한다. 이렇게 문서화하는 것조차도 프로젝트에 기여하는 것이다.
기여할 파일이 모두 준비가 되다면, Pull Request를 통해 기여를 제출한다.
일반적으로 다음 상황에서 Pull Request를 오픈한다.
- 사소한 수정 사항 제출 (예: 오타, 링크 오류 등)
- Issue에서 이미 논의가 된 사항에 대한 작업 시작
Pull Request는 작업이 완료된 이후에 해야 하는 것은 아닙니다. 일반적으로 Pull Request를 일찍 오픈하여 다른 사람들의 피드백을 받는 게 좋다. 제목 줄에 "WIP" (Work in Progress)라고 표시하여 아직 진행 중인 작업이라고 표시하고, 나중에 언제든지 더 많은 Commit을 추가할 수 있다.
GitHub에 있는 프로젝트라면 Pull Request를 제출 시 다음 사항을 참고할 수 있다.
-
Repository Fork
- Repository를 Fork하고 Local PC에 복제(Clone)한다. 이로써 Local PC가 Original "Upstream" repository와 원격으로 연결된다.
- "Upstream"의 변경 사항을 수시로 당겨와서 (Pull) 항상 최신 상태를 유지한다. 이는 나중에 변경 사항을 Merge 할 때 Conflict 되는 걸 줄여준다.
- 자세한 사항은 다음 안내를 참고한다. : Syncing a fork
-
Branch 생성
- 별도의 Branch를 생성하여 수정 작업을 한다.
-
PR에 관련 Issue 번호 추가
- PR (Pull Request) 오픈 시, 관련된 Issue의 번호나 참조하는 문서를 표시한다. (예: "Closes #37")
-
전후 스냅샷 추가
- 수정 사항이 HTML/CSS를 변경하였다면, Pull Request에 전후 스냅샷 이미지를 추가한다.
-
수정 사항 테스트
- 수정 사항을 반영하여 기존 테스트를 실행한다. 필요할 경우 새로운 테스트 케이스를 작성한다. 어느 경우라도 수정 사항이 기존 프로젝트를 손상시켜서는 안 된다.
-
프로젝트 스타일 유지
- 들여쓰기 (Indent), 세미콜론, 또는 주석 등을 프로젝트 스타일대로 따르세요. 그래야 Maintainer가 Merge 하기 쉽고, 나중에 다른 사람들이 이해하고 유지하기 수월한다.
!!! tip * Pull Request가 처음이라면 Make a Pull Request(비디오 강의)를 참고한다. 또한, First Contributions에서 Pull Request 만드는 것을 연습할 수 있다. * 참고로, Kubernetes는 다음과 같은 Github workflow에 대한 설명 문서를 제공한다. : github_workflow.md
기여를 제출하면 프로젝트로부터 Feedback을 받게 된다.
{% hint style="warning" %} 일반적으로 Feedback은 개선이나 변경 사항이 어떤 방식으로 동작하는지, 왜 그런 방식을 채택하였는지 등에 대한 설명을 요구한다. 이 Feedback은 때로는 대응하기 어려울 수도 있지만, 기여의 수준을 높이는 과정이라고 받아들이는 것이 좋다. {% endhint %}
Feedback은 보통 다음 네 가지 중 하나에 해당한다.
기여하기 전에 프로젝트가 활발한지 먼저 확인하는 게 좋다. 어느 정도 활발한 프로젝트에서도 기여에 대해 응답을 받지 못할 수도 있다.
일주일 이상 응답을 받지 못한 경우, 동일한 스레드에 정중하게 누군가에게 검토를 요청하는 것이 좋다. 적절한 사람의 이름을 알고 있다면 @-멘션 기능을 이용한다.
!!! warning 단, 개인적으로 연락하지는 마세요. 오픈소스 프로젝트에서 공개 커뮤니케이션은 필수이다.
그럼에도 여러 가지 이유가 있겠지만 아무도 반응하지 않을 수도 있다. 썩 좋은 기분은 아니지만 낙담할 필요는 없다. 이는 누구에게나 일어날 수 있는 일이다. 기여할 수 있는 다른 방법이나 다른 프로젝트를 찾아보세요.
아이디어에 대한 설명이나 코드를 수정하라는 요청을 받는 것은 일반적이다. 이렇게 누군가 수정을 요청했다면 바로 응답한다. 그는 자기 시간을 내서 우리 기여를 검토했다.
PR을 오픈한 상태로 응답하지 않고 남겨두는건 결례이다. 더 이상 문제를 해결할 여건이 아닌 경우라면, Maintainer에게 더 진행할 수 없다고 알리세요. 그렇게 PR을 Close 하거나 다른 사람이 인수하여 추가로 진행할 수도 있다.
우리 기여는 결국 수락될 수도 있고, 수락되지 않을 수도 있다. 수락되지 않은 이유가 잘 이해되지 않을 경우, Maintainer에게 설명을 요청하는 것도 합리적이다. 그러나 이것이 그들의 결정임을 존중해야 한다. 논쟁하거나 적대적으로 행동하지 마세요. 끝까지 이견이 조율되지 않으면, 언제든지 Fork 하여 자신의 프로젝트에 작업할 수 있다.
!!! tip 코드가 승인되기까지 여러 차례의 반복적인 수정 과정을 거쳐야 할 수도 있으며, 때에 따라서는 거부될 수도 있다. 이때는 낙심하거나 포기하기보다는 거부된 이유에 대해 자세히 알아보고, 다음 기여가 향상되는 기회로 삼는 것이 좋다.
축하한다! 드디어 오픈소스 기여에 성공했다.
오픈소스에 기여하는 모든 과정은 커뮤니티 멤버들과 커뮤니케이션의 연속이다. 먼저 효과적인 커뮤니케이션을 위해 다음 사항을 기억하라.
오류 보고라면 어떤 작업에서 발생했는지, 재현 경로는 어떻게 되는지 정확히 설명하라.
새로운 아이디어 제안이라면 아이디어가 자신에게만 아니라 프로젝트에 유용하다고 생각하는 이유를 설명하라.
!!! example "좋은 예" "Y를 하는 과정에서 X가 동작하지 않습니다."
!!! bug "나쁜 예" “X가 안 돼요. 고쳐주세요.”
도움을 요청하기 전에 프로젝트의 README, 문서, 이슈, 메일링 리스트 또는 검색을 통해 답을 찾아보라. 이런 노력을 보여주는 게 좋다.
!!! example "좋은 예" "X를 구현하는 방법을 잘 모르겠습니다. 도움말 문서를 확인했지만 언급이 없습니다."
!!! bug "나쁜 예" “X는 어떻게 하는 거죠?”
모든 기여는 누군가가 검토해야 한다. 어떤 프로젝트는 검토하기 어려울 정도로 많은 기여나 요청이 발생한다. 따라서 가능한 간결하게 요청하는 것이 접수될 가능성이 커진다.
!!! example "좋은 예" "API 튜토리얼 작성하는 일을 지원하겠습니다."
!!! bug "나쁜 예" “얼마 전에 고속도로를 운전하다가 주유소에 들렀습니다. 그때 우리가 해야 할 일에 대한 놀라운 아이디어가 떠올랐습니다. 아이디어에 관해 설명하기 전에 한 가지 보여드릴 게 있습니다."
Maintainer에게 개인적으로 연락하는 것은 좋지 않다. 모든 대화를 공개하라. 이를 통해 더 많은 사람이 배우고 이익을 얻을 수 있다.
토론 자체도 하나의 기여이다.
!!! example "좋은 예" (Comment로) "@maintainer 안녕하세요, 이 PR을 어떻게 진행해야 할까요?"
!!! bug "나쁜 예" (이메일로) “안녕하세요, 나의 PR을 언제 확인해줄 건가요?”
Maintainer라도 모든 부분을 완벽히 대응할 수 없다. 그들에게도 확인해야 할 시간이 필요하다.
!!! example "좋은 예" "이 오류를 검토해주셔서 감사합니다. 당신의 제안을 따랐지만, 이번에는 이러한 오류가 나타났습니다."
!!! bug "나쁜 예" "왜 내 문제를 해결할 수 없나요? 당신이 Maintainer 아닌가요?”
우리의 아이디어가 커뮤니티의 우선순위나 비전과 다를 수 있다. 커뮤니티에서는 우리의 아이디어를 따르지 않기로 결정할 수 있다.
이에 대해 타협점을 찾거나, 결코 동의할 수 없다면 fork 하여 자신의 프로젝트를 새롭게 시작하는 걸 고려할 수 있다.
!!! example "좋은 예" "내게 제출한 Use Case가 채택되지 않아서 유감이지만, 그 이유를 자세히 설명해주셔서 고맙습니다. 잘 이해했습니다."
!!! bug "나쁜 예" "왜 내 Use Case를 지원하지 않나요? 용납할 수 없습니다."
오픈소스에서는 전 세계의 구성원과 협업을 한다. 언어, 문화, 지역 및 시간대에 따라 소통 방법에 온도 차이가 있다. 또한, 직접 대면해서 대화하는 게 아니라 글로써 의사소통하기 때문에 어조나 분위기를 정확히 전달하기가 어려울 수 있다.
이런 어려움을 극복하는 좋은 방법으로는 항상 상대방의 글은 좋은 의도라고 가정하는 것이다. 상대의 제안을 거절할 때도 정중히 하고, 자신의 입장은 명확히 표현하는 것이 좋다. 오픈소스라는 인터넷 공간에서 자신을 품위 있게 유지하라.
===
...
...
...
...
CONTRIBUTING 파일 https://sktelecom.github.io/oss-guide/contribute/contribute/#1
https://verizonmedia.github.io/oss-guide/docs/contributing/contributing.html
CLA https://verizonmedia.github.io/oss-guide/docs/contributing/contributing.html
(애매한 상황이면 OSPO에 문의)
...
(저작권 표시)
- fork
- clone
- branch
- develop
- test
- push(CI, code coverage ... )
- code review
- apply
- merge
어떻게 하면 좋은 기여자가 될 수 있을까? 물론 프로젝트마다 운영되는 방식이 다르기 때문에 하나의 정답은 없다. 프로젝트에 참여할 때마다 길을 찾고 운영 방식을 배우기 위한 시간을 투자해야 한다. 그럼에도 다음 사항들은 좋은 기여자가 되기 위해 도움이 될 수 있다.
각 커뮤니티는 참여방식이 조금씩 다르다. 문서를 읽고 커뮤니티에 대해 알아보고, Mailing List, 포럼, IRC, Slack, Bug tracker, Source Code Repository 등 주요 커뮤니케이션 채널에 참여하라.
커뮤니티에 가입한 후에는 기여하기 전에 잠시 커뮤니티의 문화를 흡수하라. 그동안의 커뮤니케이션을 살펴보는 것도 좋은 방법이다. 이런 과정을 거칠수록 첫 번째 기여가 수락될 가능성이 커진다.
기여하기 전에 프로젝트 관리 및 리더쉽에 관한 문서를 보면, 누가, 어떤 방법으로 결정을 내리는지 알 수 있다.
간단한 버그나 문서 수정으로 시작하라. 중요도가 크지 않은 작은 기여를 해보면서 프로세스를 배우고, 실수를 수정해가는 것이 좋다. 이러한 경험을 바탕으로 더 큰 기여를 하면서 점차 프로젝트에 영향을 미칠 수 있다.
오픈소스 커뮤니티의 다른 참여자와 지속적인 관계를 구축하는 것은 중요하다. 가장 좋은 방법은 콘퍼런스 등의 이벤트에 참석하는 것이다. 직접 만나는 것 만큼 관계 형성에 좋은 것은 없다.
어떤이는 코드의 양이 상당히 커질 때까지 개발한 다음 이를 오픈소스 프로젝트에 한 번에 기여하려고 한다. 이는 버그나 Side effect를 유발할 수 있기 때문에 긍정적인 방법이 아니다. 너무 코드가 커지기 전에 커뮤니티와 논의하고, 개발 초기에, 그리고 자주 기여하라.