오픈소스 기여하기

우수한 ICT 기업은 오픈소스를 제품 개발에 사용하기에 그치지 않고 오픈소스 프로젝트에 다시 기여하여 가치를 창출하는 전략도 중요하게 여긴다. 그러나 기업이 오픈소스 프로젝트 및 운영 방식을 제대로 이해하지 못하거나, 견고한 전략 없이 오픈소스 기여 활동에 참여하면 오픈소스 커뮤니티에서 기업의 명성이 훼손되거나 법적 위험을 초래할 수도 있다.

이 가이드에서는 기업이 오픈소스 프로젝트에 기여함으로 얻을 수 있는 이익과 올바른 기여 정책의 필요성 및 정책 수립 방법을 다룬다. 이어서 기업의 구성원이 오픈소스 프로젝트에 기여하는 방법을 세부적으로 설명한다.

이 장에서는 두 가지 입장에 따라 오픈소스 기여 과정을 서술한다.

1. 오픈소스 기여 가이드 - 기업 편:

   오픈소스 사무국을 운영하는 입장을 위한 가이드이다. 기업의 구성원으로부터 오픈소스 기여 요청이 있을 경우, 혹은 기업에서 필요에 따라 오픈소스 기여를 추진하는 경우에 고려해야 할 내용을 다룬다.

2. 오픈소스 기여 가이드 - 개발자 편:

   기업에 속한 개발자의 입장을 위한 가이드이다. 회사 업무의 목적으로 오픈소스에 기여하는 경우, 신경 쓰면 좋을 부분을 다룬다.

이 장의 내용은 다음 문헌을 참고하였다.

• TODO Group의 Participating in open source communities¹
• GitHub Open Source Guide의 How to Contribute to Open Source²

오픈소스 기여, 왜?

다른 업무를 하는 것과 동시에 오픈소스 기여를 하려고 한다면 오픈소스 기여 작업을 왠지 미루게 되는 자신을 발견하게 된다. 기업에서는 오픈소스 기여보다 업무가 더 우선시되기 때문이다. 당연한 이야기이지만, 이렇게 계속 미루게 된다면 결국 그 기업은 오픈소스 기여를 하지 않는 기업으로 남게 된다. 기업에서 어떻게 오픈소스에 기여해야 하는가를 이야기하기 전에, 다른 사람들에게 동기부여를 할 수 있는 ‘오픈소스에 기여해서 얻을 수 있는 이점’에 대해 먼저 정리한다.

기업에서 얻는 이점

기업이 오픈소스에 기여하는 목적과 이익은 무엇인가? 기업은 왜 구성원의 오픈소스 기여 활동을 장려해야 하나? 기업의 비즈니스 관점에서도 오픈소스에 기여해야 하는 이유는 다음과 같다.

1. 유지 관리 비용을 절감할 수 있다

기업은 오픈소스를 사용하여 제품을 만들면서 버그를 수정하거나 새로운 기능을 추가한다. 그런데 이를 다시 오픈소스 프로젝트로 기여하지 않는다면 어떻게 될까? ‌ 오픈소스 프로젝트는 중요한 보안 패치 등 새로운 버전을 계속해서 배포할 텐데, 그때마다 기업은 새로운 버전을 적용하기 전에 자체적으로 수정한 사항을 다시 새로운 버전에 반영한 후, 기능은 이상 없이 동작하는지, 성능에는 영향이 없는지 매번 테스트해야 하는 노력이 필요하다. 이러한 수고가 반복된다면 이에 투입해야 하는 인력과 시간 등의 관리 비용은 악몽과도 같이 매우 증가할 것이다. 만약 수정 사항을 오픈소스 프로젝트에 기여했다면 향후 새로운 버전이 배포될 때 수정 사항이 이미 포함되어 있기 때문에 추가로 유지 관리해야 할 필요가 없게 된다.

따라서 오픈소스를 사용하는 기업은 기여의 중요성을 개발자들에게 교육해야 한다. 물론, 오픈소스 프로젝트에 기여하는 것은 적지 않은 수고와 시간이 들어갈 수 있다. 개발자들은 타이트한 개발 일정 때문에 패치를 만들어도 당장 제품에만 적용하려고 하지, 이를 오픈소스 프로젝트에 기여하지 않으려고 할 수 있다. 그러나 패치를 기여하지 않으면 신규 버전의 오픈소스가 새롭게 배포될 때마다 개발자는 자기가 만든 패치를 재적용하는 수고를 해야 한다는 점을 재차 강조하는 바이다. 이러한 작업이 반복될수록 더 많은 시간과 노력을 쏟아야 하는 악순환이 된다.

2. 오픈소스 프로젝트의 방향에 영향을 미칠 수 있다

기업이 제품 개발에 중요하게 사용하는 오픈소스 프로젝트에서 기업에 꼭 필요한 기능을 추가해주기를 바라는가? 그렇다면 그 오픈소스 프로젝트에 바라는 기능을 제안하고, 때에 따라서는 일부분을 직접 개발하여 기여하는 등, 활발히 활동할 것을 권한다. 기업에서 이렇게 기여한 이후에는 커뮤니티의 여러 개발자가 참여하여 해당 기능을 안정화하고 고도화하여 결과적으로는 기업이 원하는 방향으로 성장하게 된다.

3. 우수한 개발자를 고용할 수 있다

우수한 오픈소스 개발자를 찾을 수 있는 가장 좋은 장소는 바로 오픈소스 커뮤니티이다. 오픈소스에 적극적으로 기여하는 기업이 오픈소스 커뮤니티에서 좋은 평판을 쌓게 된다. 오픈소스 커뮤니티의 우수한 개발자는 오픈소스에 적극적으로 기여하는 기업에서 일하고 싶어 한다. 오픈소스 기여 활동을 전혀 하지 않는 기업이 우수한 오픈소스 개발자를 채용하기는 쉽지 않다.

개발자가 얻는 이점

1. 공공의 이익에 기여할 수 있다

사용 중인 오픈소스의 버그를 직접 수정하거나 새로운 기능을 추가하여 기여하면 소프트웨어가 개선될 뿐만 아니라 이 소프트웨어를 사용하는 모두에게 이익을 제공하게 된다. 작은 기여로 글로벌 커뮤니티에 공헌하는 것이다.

2. 실력을 키울 수 있다

오픈소스에 기여하는 활동을 통해 새로운 기술을 배울 수 있다. 그뿐만 아니라 반복적인 연습과 훈련은 역량을 향상시킨다. 버전 관리, Unit Test, Integration Test, CI/CD 등은 오픈소스 프로젝트 개발에서 탄생하여 지금은 거의 모든 소프트웨어 개발 시 사용되고 있는 개발방법론이다. 이들을 오픈소스 프로젝트에서 배울 수 있다. 더구나, 회사 업무와는 달리 오픈소스 프로젝트에서는 초보자의 실수에 비교적 관대하여 본인의 의지만 확고하다면 기술을 향상할 수 있는 최고의 공간이다. 오픈소스 프로젝트에서는 코딩뿐만 아니라 UI, 그래픽 디자인, 문서 작성 등의 실무를 배울 수 있다.

3. 오픈소스를 깊은 수준에서 이해하고 기술을 습득할 수 있다.

단순히 오픈소스를 사용하는 수준을 넘어 오픈소스 기여를 위해 이슈를 이해하고, 문제를 해결하게 되면 더욱더 깊은 수준으로 오픈소스 기술을 습득하게 된다. 이러한 활동은 오픈소스의 향후 변경 사항을 쉽게 식별하여 유연하게 대응할 수 있게 하며, 오픈소스 활용을 더 확장해나갈 수도 있게 한다.

4. 협업을 배울 수 있다

오픈소스 커뮤니티는 전 세계의 다양한 지역, 다른 시간대의 사람들이 모여 있는 공간이다. 이러한 제약 가운데 공통 과제를 수행하기 위해서는 고도의 협업 능력이 필요하다. 오픈소스 프로젝트에서는 분업, 위험관리를 고려한 진정한 협업이 이뤄진다. 이와 더불어 협업을 가능하게 하는 여러 도구에도 익숙해질 수 있다. 이슈 트래커, 버전 관리 시스템, 메일링리스트와 같은 도구가 대표적이다.

5. 많은 사용자를 경험할 수 있다

활성화되어있는 오픈소스 프로젝트에 참여하면, 경험할 수 없던 많은 사용자 환경을 경험할 기회가 된다. 다양한 사용자의 기능요구를 접할 수 있고, 소프트웨어 품질에 대한 기대와 현상 등을 가늠할 수 있어, 학교의 과제나 개인 프로젝트에서는 불가능했던 실제 현장 경험을 여러 훌륭한 개발자들과 협업하며 얻을 수 있다.

6. 새로운 사람을 만날 수 있다

오픈소스에는 커뮤니티가 있다. 공통 관심사가 있는 사람들이 참여하고 만남으로써 관계를 만들어 갈 수 있다. 어떤 사람을 만나느냐가 경력의 방향에 큰 영향을 미칠 수 있다. 신뢰할 수 있는 관계가 되고 나면 서로 새로운 업무나 직장으로 이끌어줄 수 있다. 오픈소스 커뮤니티에서는 항상 전문적으로 협업하면서 서로 업무 스타일과 인성을 깊이 있게 파악할 수 있어서 가능한 일이다. 이처럼 오픈소스 프로젝트에 기여하면서 형성된 관계야말로 왜 기여해야 하는지를 설명하는 분명한 답변 중 하나이다.

7. 평판과 경력을 키울 수 있다

오픈소스 작업은 모두에게 공개된다. 오픈소스에서 수행한 작업은 어디에서나 누구에게든 보여줄 수 있으며, 이는 개인의 평판을 높이는 데 큰 도움이 된다.

8. 리더쉽을 배울 수 있다

오픈소스에서는 팀 구성, 갈등 해결 및 우선순위 조정과 같은 리더십과 관리 기술을 배울 수 있다. 오픈소스 프로젝트에서 공동 작업을 하려면 누군가에게 업무 수행 방식을 설명해야 하고, 다른 사람들에게 도움을 요청해야 할 일이 있다. 이렇게 배우고 가르치는 일을 통해 리더쉽을 경험하고, 성취감을 맛보게 된다.

이렇게 오픈소스 기여는 전략적으로 활용한다면 기업과 개인에게 모두 유익한 활동이다. 다음 장에서는 기업과 개인 각각의 측면에서 효과적이고 안전한 오픈소스 기여를 위해 알아야 할 사항들을 설명한다.

오픈소스 기여 가이드 - 기업 편

기업은 올바른 오픈소스 기여 문화 조성과 예기치 않은 법적 리스크를 최소화하기 위해 오픈소스 기여 정책과 프로세스를 구축해야 한다. 이 장에서는 기업이 오픈소스 기여 정책을 올바르게 수립하여 저작권 침해 리스크를 최소화하면서도 구성원들에게 기여를 장려하여 오픈소스로부터 최대한의 이익을 취하기 위한 가이드를 제공한다.

오픈소스 기여 전략을 수립하라

기업은 오픈소스 기여 전략을 수립할 필요가 있다. 기여 전략은 다음과 같이 두 부분에 도움을 준다. (1) 오픈소스 프로젝트에 기여하려는 구성원에게 기업의 정책을 안내 (2) 오픈소스 기여 활동을 기업의 비즈니스 전략과 연계하여 경영진이 오픈소스 기여의 필요성과 정당성을 이해 기업은 비즈니스 목표와 연계된 오픈소스 기여의 목표와 전략을 수립하고 이를 실행하기 위한 계획을 수립해야 한다. 이때 고려해야 할 사항들은 다음과 같다.

1. 기업에 오픈소스 기여가 중요한 이유가 무엇인가?

오픈소스 기여가 기업의 비즈니스에 왜 중요한지에 대한 설득력 있는 주장을 준비한다. 그래야 경영진을 설득하고, 적극적인 지원을 받을 수 있다. 이러한 준비 없이 기업이 오픈소스 커뮤니티에 참여하려 한다면 시작하기조차 어려울 수 있다.

2. 기업이 전략적으로 사용하는 오픈소스 프로젝트가 무엇인가?

기업에서 비즈니스에 전략적으로 사용하는 오픈소스 프로젝트가 무엇인지 확인한다. 중요한 비즈니스 인프라일 수도 있고, 제품 성능에 영향을 미치는 중요한 기능을 제공하는 소프트웨어일 수도 있다.

3. 어떤 프로젝트에 기여해야 하는가?

기업이 사용하는 모든 오픈소스에 기여하기보다는 중요한 프로젝트에 집중하는 것이 필요하다. 물론 중요한 프로젝트가 아니라고 해서 기여할 수 없다는 것은 아니다. 다만, 중요한 프로젝트에 자원을 집중하여 기여 것이 기업에 도움이 된다는 의미이다. 기업의 비즈니스와 제품 및 서비스에 큰 영향을 미치는 프로젝트를 주요 기여 대상을 우선 검토한다.

4. 이미 기여하고 있는 현황을 파악하라

이미 일부 구성원들이 자발적으로 오픈소스 프로젝트에 기여하고 있는지 확인한다. 내부적으로 유지보수를 위해 생성한 패치를 업스트림에 기여하였거나, 우연히 발견한 버그를 제보하는 경우가 있을 수도 있다. 이렇게 기업 내 오픈소스 기여에 관심과 역량이 있는 구성원을 파악한다. 그들이 기업의 큰 자산이다.

5. 이미 전문가를 보유하고 있는가? 아니면 추가로 채용해야 하는가?

오픈소스 기여 역량을 갖춘 인재를 찾는 것은 중요하다. 기업 내 구성원 중에서 찾을 수도 있지만, 그렇지 않다면 기업이 주요 기여 대상으로 선택한 오픈소스 프로젝트에 이미 활발하게 기여하고 있는 오픈소스 개발자의 채용을 고려하는 것도 방법이다. 이를 위해 필요한 자원과 예산을 확보한다.

6. 오픈소스 프로젝트를 후원하기 위한 자금이 필요한가?

기업이 선택한 오픈소스 프로젝트의 거버넌스 모델을 확인하여 기업 멤버십 자격 또는 후원을 위한 방법이 있는지, 또는 이를 담당하는 비영리 재단이 있는지 확인한다. 프로젝트의 성공을 위해 자금을 지원할 수 있으며, 기업이 운영 위원회에 참가하여 프로젝트의 방향에 영향을 줄 수도 있다. 프로젝트에 직접 자금을 지원하는 것 외에도 관련 콘퍼런스를 후원하는 것도 좋은 방법이다. 이를 통해 기업의 오픈소스 전략과 비전을 커뮤니티에 홍보할 수 있다.

7. 기업의 오픈소스 활동을 어떻게 홍보할 것인가?

기업의 오픈소스 기여 활동을 홍보하기 위해 오픈소스 프로젝트의 콘퍼런스나 이벤트를 후원하고, 세션 발표를 하는 것은 좋은 방법이 될 수 있다. 특히, 기업 내 구성원이 오픈소스 프로젝트의 커뮤니티 활동에 참여하는 것을 허용하고 적극적으로 권장한다. 그렇게 함으로써 중요한 오픈소스 프로젝트 내에 기업의 적극적인 활동이 홍보되고, 열정적인 외부 개발자들을 채용할 기회 증가한다.

8. 기업의 오픈소스 기여 가이드와 프로세스는 준비했는가?

강제적인 정책과 규정보다는 기업의 구성원이 오픈소스 프로젝트에 성공적으로 기여할 수 있도록 지원하는 것이 더 중요하다. 물론, 라이선스 침해, 영업비밀 누수 등의 문제없이 기여하기 위한 정책과 가이드를 제공하여 오픈소스 기여 시 발생할 리스크를 최소화한다. 특히, 신규 기여자가 법적, 기술적 피드백을 받을 수 있는 내부 검토 프로세스를 제공한다.

9. 충분한 교육은 제공하는가?

기업이 구성원에게 오픈소스 라이선스, 거버넌스 및 오픈소스 커뮤니티 참여, 오픈소스 기여 모범 사례 등의 교육을 제공한다면 오픈소스 기여 문화 확산에 매우 유용하다. 신규 기여자 양성을 위해 숙련된 기여자를 멘토로 지원하는 멘토링 프로그램도 큰 도움이 된다.

오픈소스 기여 정책의 방향을 설정하라

기업의 소프트웨어 개발 환경에 따라 오픈소스 기여 정책은 개방적일 수도 있고 보수적일 수도 있다. 오픈소스 기여에 개방적인 기업이라면 다음과 같이 구성원의 기여를 독려하는 정책을 마련할 수 있다.

반면에, 영업비밀 노출 최소화를 위해 구성원의 기여를 세밀하게 관리하고자 한다면 다음과 같이 정책을 수립할 수 있다.

오픈소스 기여 정책에는 어떤 내용을 포함해야 하나?

기업의 오픈소스 기여 정책의 방향을 설정한 후에는 세부 정책을 수립하기 위해 몇 가지 고려해야 할 사항이 있다.

1. 기여를 허용하는 기준을 수립하라

기업의 OSPO_{Open Source Program Office}가 구성원의 외부 오픈소스 기여에 대해 모두 점검할 것인지, 아니면 구성원의 판단하에 자율적으로 기여하게 할 것인지에 대한 정책을 갖고 있어야 한다.

예를 들어, 오픈소스 기여에 친화적인 기업이라면 다음과 같이 일정 부분은 별도의 리뷰 절차 없이 구성원이 자율적으로 기여할 수 있게 할 수 있다.

1. 100 라인 이하의 작은 코드 조각
2. Stack Overflow 문의/ 답변
3. Bug Report
4. GitHub 활동 : Pull Request 수락, Comment 대응, 버전 릴리즈 등

또한, 구성원이 외부 오픈소스 프로젝트에 기여할 때 다음과 같은 상황에서는 기업의 리뷰와 승인을 거쳐야만 이뤄질 수 있도록 제한을 할 수도 있다.

1. 상당한 양의 기여
2. 라이선스 정책으로 인해 기업이 사용할 수 없는 프로젝트로의 기여 (예: AGPL, CC BY-NC*, 상업적 사용을 제한하는 프로젝트 등)
3. Private Repository (단, 기업과 별도의 서면 약정이 체결된 경우는 예외)

다만, OSPO_{Open Source Program Office}가 모든 기여 코드의 Commit를 리뷰하고 승인된 코드만 기여하는 정책을 가져가는 것은 OSPO와 구성원 모두에게 큰 부담이 될 수 있다. 따라서, 오픈소스 프로젝트에 기여를 원하는 구성원들에게 가능한 자율권을 부여하되 다음과 같은 기준을 정하고, 이외 모호한 때에만 OSPO에 문의 후 기여하도록 정책을 가져가는 것도 고려할 수 있다.

2. 개인이 업무 시간 이외에 개발한 코드라면?

어떤 개발자는 근로 외 시간에 업무와 전혀 상관없이 개인의 관심 분야에 작성한 코드이기 때문에 기업의 승인 없이 개인 이메일로 기여해도 된다고 생각한다. 하지만, 기업의 고용 계약에 따라 근로 외 시간에 개인 기기로 작성한 소스 코드라고 할지라도 코드의 내용이 업무와 관련이 있다면 기업이 저작권을 소유하게 될 수 있다. 업무와 연관성 여부는 입증하기 쉽지 않기 때문에 되도록 보수적으로 판단하는 것이 좋다. 따라서, 기업은 지식재산 유출 사고를 방지하기 위해 정책적으로 오픈소스에 기여하려는 구성원에게 오픈소스 프로젝트에 최초 기여 시, OSPO_{Open Source Program Office}의 리뷰와 승인을 한차례 받도록 한다. 이를 통해 구성원은 한 번 더 불필요한 지식재산 유출에 주의하게 되고, 기업도 기여자 Pool 관리 차원에서 의미가 있을 수 있다.

3. 기업 계정의 이메일을 사용하게 하라

기업은 오픈소스에 기여하는 구성원이 자신의 개인 이메일이 아닌 기업의 이메일을 사용하도록 의무화한다. 이를 통해 기업은 (1) 오픈소스에 기여하는 구성원이 기업을 대표하여 커뮤니티와 커뮤니케이션한다는 책임감을 부여하고, (2) 오픈소스 커뮤니티에 기여 활동을 활발히 하는 기업으로 인지도를 개선할 수 있다.

GitHub에서는 개인 계정이라도 기업의 이메일을 사용할 수 있는 설정하는 방법³을 제공한다.

4. CLA / DCO에 주의하라

어떤 오픈소스 프로젝트는 모든 기여자에게 CLA_{Contributor License Agreement}에 서명할 것을 요구한다. 이는 프로젝트가 여러 기여자의 저작물을 관리하면서 발생할 수 있는 저작권 분쟁을 최소화하기 위해 기여자들에게 동의를 구하는 약정서이다. 기업은 오픈소스 프로젝트에서 기여자에게 서명을 요구하는 CLA를 검토하여 기업의 지식 재산이 예기치 않게 노출되는 상황이 발생하지 않도록 주의해야 한다. 보통 대기업이 주도하는 프로젝트에서 CLA에 서명할 것을 요구한다.

기업은 구성원에게 오픈소스에 기여하기 전에 CLA 서명을 요구받을 시, 반드시 서명 전에 OSPO_{Open Source Program Office}에 의한 리뷰 과정을 거칠 수 있도록 의무화해야 한다.

CLA

CLA는 프로젝트마다 다르지만 주로 다음 사항을 동의한다는 내용을 담고 있다.

• 나(또는 소속 기업)는 내가 기여하려고 하는 기여물을 프로젝트에 기여할 권리가 있다. (즉, 이 기여물의 저작자이다.)
• 나(또는 소속 기업)는 나의 기여물을 프로젝트가 수정, 배포, 관리할 수 있는 권한을 프로젝트에 부여한다.
• 나(또는 소속 기업)는 부여한 권한을 철회하지 않는다.
• 나(또는 소속 기업)는 프로젝트가 향후 필요에 따라 라이선스를 변경할 수 있는 권한을 프로젝트에 부여한다.

이러한 CLA는 프로젝트가 여러 기여물을 포함하는 프로젝트 산출물을 사용/배포하는 과정에서 발생할 수 있는 법적 분쟁 가능성을 최소화하기 위해서이다. 만약 기여하려는 프로젝트에서 CLA 서명을 요구하는데, 기업의 구성원이 어느 하나라도 동의하기 어려운 항목이 있다면 절대 서명하게 해서는 안 된다. 예를 들어, 기여물에 3rd party의 소프트웨어가 포함되어 있다면 CLA에 서명하게 해서는 안 된다. 따라서, 구성원은 CLA에 서명하기 전에 반드시 OSPO나 법무 조직에 문의하고 승인을 얻은 후 서명하게 해야 예기치 않은 저작권 침해 이슈에 휘말리지 않을 수 있다.

또한, 드문 경우지만, 어떤 CLA는 다음과 같은 조건에 대해서도 동의를 요구한다.

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

이러한 저작권 양도 요구는 논쟁의 여지가 있다. 기업에 따라 위와 같이 저작권 이전을 요구하는 CLA에는 서명을 금지하고, 그런 프로젝트에는 기여를 제한하는 정책을 시행하고 있기도 하다.

DCO

CLA의 복잡성과 서명하는 것에 대한 부담 때문에 DCO_{Developer Certificate of Origin}가 CLA의 대안으로 주목받고 있다. DCO는 리눅스 재단이 만들었고, 리눅스 커널에 기여하는 기여자들이 기여를 제출할 권한이 있음을 확증하는 역할을 하는 간단한 문서이다.

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or₩

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

DCO는 별도의 서명을 요구하지 않고, Git 환경에서 --signoff 플래그를 사용하여 자신의 기여에 서명하는 단순한 방식이다. 그래서, CLA가 기여의 확산을 방해한다고 생각하는 사람들에게는 DCO가 지지받고 있다. 단, Git을 제외한 다른 버전 관리 시스템을 사용하는 프로젝트에서는 사용할 수 없다. 복잡한 지식재산권 이슈를 고려해야 하는 프로젝트를 주도하는 기업이라면 DCO 도입이 적절하지 않을 수 있다.

5. 기업 저작권을 표시하게 하라

구성원이 재직 기간에 생성한 저작물의 지식재산은 기본적으로 기업이 소유한다. 따라서, 기업은 구성원이 외부 오픈소스 프로젝트에 코드를 기여할 때 기업의 저작권을 표기한다.

하나 이상의 파일을 기여할 때는 다음과 같이 파일 상단에 저작권과 라이선스를 표기하도록 안내한다.

Copyright 2023 SK TELECOM CO., LTD.
SPDX-License-Identifier: {$SPDX_license_name}

여기서 $SPDX_license_name은 해당 오픈소스 프로젝트의 라이선스 정책에 따라 작성한다.

단, 버그 수정 등의 목적으로 기존 코드를 수정하는 정도라면 해당 코드 수정에 대해 기업이 저작권을 주장하기가 쉽지 않기 때문에 저작권 표기도 강제화하지 않는다.

6. 행동 강령을 준수하게 하라

대부분의 주요 오픈소스 프로젝트는 참여자에게 행동 강령_{Code of Conduct}의 준수를 요구한다. 행동 강령은 프로젝트의 건강하고 건설적인 커뮤니티 성장을 위해 참여자 간의 존중과 신사적인 태도를 강조한다.

기업은 구성원에게 오픈소스 프로젝트 행동 강령의 중요성을 알린다. 만약 기업의 구성원이 행동 강령을 위반하여 오픈소스 프로젝트로부터 경고나 활동 제한 등의 조치를 받았을 경우, 즉시 OSPO에 알리도록 해야 한다. 그래서 개인이 오픈소스 프로젝트와 소모적인 논쟁이 발생하지 않도록 기업 차원에서 신속히 현황을 파악하고 이슈가 해결될 수 있도록 조치한다. 불필요하게 이슈화를 시켜서 오픈소스 진영에서 기업의 평판을 잃을 필요가 없다.

7. 기여자 목록을 확보하여 활용하라

기업에서 다수의 오픈소스 프로젝트에 기여하고 있다면, 기여자 목록은 귀중한 자산이 될 수 있다. 여기에는 (1) 기여 대상 오픈소스 프로젝트, (2) 기여 형태, (3) 기여자 이름/조직, (4) 기여 내용 등의 정보를 포함한다. 이러한 목록을 확보하여 사내 공유한다면 다음과 같은 유익을 기대할 수 있다.

1. 동일한 오픈소스 프로젝트에 기여하고 있는 여러 조직 및 구성원이 기업 내 커뮤니티를 구성하여 기술 세미나, 밋업 등의 방식으로 기술 공유 및 상호 발전을 도모할 수 있다.
2. 특정 오픈소스 프로젝트에서 이슈가 발생했을 때, 사내 오픈소스 기여자 목록에서 해당하는 오픈소스 프로젝트 기여자를 찾을 수 있다면 이슈 해결을 위한 컨설팅을 요청할 수 있다. 물론 기여자에게는 기업 차원의 보상 제공 등으로 지원한다면 고품질의 사내 컨설팅을 지속할 수 있을 것이다.

오픈소스 기여 가이드 - 개발자 편

개발자라면 누구나 자기 계발을 통해 역량을 키우고, 더욱 능력 있는 개발자로 성장하기 위한 열망을 가진다. 오픈소스 커뮤니티에 참여하고, 관심 있는 오픈소스 프로젝트에 기여하는 것은 개발자로서 역량을 키우고 평판을 높일 수 있는 최고의 방법이다.

기여 전에 알아야 할 기본 지식

여기서는 개발자들이 오픈소스에 기여하기 위해 알아야 할 오픈소스의 기본 지식을 알아본다.

저작권을 고려하라

오픈소스 기여는 저작권 관점에서 저작자가 저작물을 수정/사용/배포할 수 있는 권한을 오픈소스 프로젝트에 부여하는 것이다. 때에 따라서는 오픈소스 프로젝트에 여러분의 저작권을 양도해야 하기도 한다. 이러한 저작권 측면의 고려 없이 오픈소스 기여를 한다면 예기치 않은 저작권 침해로 인해 법적인 문제를 유발할 수 있다. 이는 기여를 하는 개인뿐만 아니라, 소속 기업에도 리스크가 된다.

일반적으로 고용 기간에 만든 저작물은 고용주가 소유한다. 따라서 기업의 구성원이 만든 저작물은 기업이 소유하게 된다. 그렇기 때문에 기업의 구성원이 오픈소스 기여를 하기 위해서는 저작물의 저작자인 기업의 승인을 받아야 한다.

어떤 이는 ‘나는 회사 업무 시간이 아닌 개인 시간에 회사 기기가 아닌 개인 기기로 회사 업무와 무관한 분야의 프로젝트에 기여 활동을 하고 있다. 이런 경우도 회사의 승인을 받아야만 하는가?‘라고 질문한다. 이는 고용 계약 내용에 따라 달라질 수 있다. 모호한 부분이 있다면 가능한 보수적으로 판단하여 저작권 침해 위험을 발생시키지 않는 것이 좋다. 굳이 나와 기업의 리스크를 감수하고 오픈소스 기여 활동을 하는 것은 바람직하지 않다.

소속 기업의 오픈소스 정책을 확인하고 따르라

최근 ICT 기업들은 정책적으로 구성원의 오픈소스 기여를 허락할 뿐만 아니라 적극적으로 장려한다. 따라서, 소속 기업의 오픈소스 정책을 확인하고 따르면서 기여하는 것이 불필요한 저작권리스크를 유발하지 않는 가장 좋은 방법이다.

기업 속한 구성원이라면 오픈소스 프로젝트에 기여하기에 앞서, 소속 기업의 오픈소스 기여 정책을 확인한다. 외부 오픈소스 프로젝트로의 기여를 허용하는지, 어떤 주의 사항이 있는지, 제약 사항은 무엇인지 정확히 파악해야 한다. 어떤 기업은 오픈소스 기여가 가능한 프로젝트 리스트를 별도로 관리하기도 하고, 기업의 이메일 계정으로 기여하는 것만 허용하기도 한다.

소속 기업에 아직 오픈소스 기여 정책이 없다면 소속 조직의 팀장이나 법무 조직에 문의하여 기여에 대한 승인을 받고, 승인받은 문서를 잘 보관한다. 혹시 모를 향후 저작권 논쟁이 발생했을 때 문서화된 근거는 요긴하게 활용할 수 있다.

소스 코드만 기여할 수 있나?

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

문서 작성 / 번역

• 프로젝트 문서, 튜토리얼을 작성한다.
• 프로젝트의 뉴스레터를 작성하거나 메일링 리스트의 중요 사항을 요약한다.
• 프로젝트 문서를 자국어로 번역한다.

테스트 / 이슈 생성

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

디자인

• 프로젝트 웹사이트의 레이아웃, 메뉴 등을 개선한다.
• 프로젝트가 일관성 있는 디자인을 가질 수 있도록 스타일 가이드를 만든다.
• 새로운 로고 또는 티셔츠를 만드는 데 기여한다.

코드 작성

• 해결할 수 있는 오픈된 이슈를 찾는다.
• 새로운 기능을 추가한다.
• 자동화를 위한 도구와 테스팅을 개선한다.

마케팅

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

이벤트 행사

• 프로젝트의 콘퍼런스, 워크숍, 밋업 등 다양한 모임을 기획하고 주관한다.

오픈소스 프로젝트에는 누가 있나?

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

[오픈소스 프로젝트 구성]

리더 (Leader)

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

• 예를 들어, Linus Torvalds는 Linux Kernel⁴ 의 원저작자로서 진행 상황의 모든 것에 대해 최종 결정권을 가지고 있다.
• Node.js 프로젝트에서는 Technical Steering Committee⁵가 리더 역할을 수행한다.

메인테이너 (Maintainer)

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

커미터 (Committer)

커미터는 프로젝트 내 특정 모듈의 코드를 충분히 이해하면서 정기적인 기여 활동을 하는 자들이다. 기여자의 기여를 Review 및 승인할 권한이 있으며, 특정 모듈에 대해 메인테이너의 승인을 받지 않고도 Merge 할 권한을 갖는다.

기여자 (Contributor)

누구든지 간단히라도 기여 사실이 있다면 기여자이다. 기여자는 기능 추가, 버그 수정, 문서화 등의 방법으로 오픈소스 프로젝트에 기여한다. 이러한 기여는 숙련된 커미터 및 메인테이너에 의해 리뷰 과정을 거치면서 보완이 된 후 저장소에 Merge 된다.

사용자 (User)

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

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

오픈소스 프로젝트는 어떤 문서를 제공하는가?

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

README

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

LICENSE (혹은 COPYING)

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

오픈소스 라이선스의 자세한 내용은 1. 오픈소스 사용하기의 오픈소스 라이선스 장을 참고한다.

CONTRIBUTING

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

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

CODE OF CONDUCT

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

기타 문서

(규모가 큰 오픈소스 프로젝트의 경우) 튜터리얼, 거버넌스 정책과 같은 문서도 제공한다.

어떤 프로젝트에 기여해야 하나?

물론 업무와 연관이 있거나 기술적인 관심이 있는 분야의 오픈소스 프로젝트에 기여해야 한다. 그런 프로젝트가 여러 개일 경우, 어떤 프로젝트가 기여할 만한 프로젝트인지 확인하는 것도 필요하다. 그렇지 않으면 수고한 기여가 아무 응답도 받지 못하고 묻혀버릴 수도 있다.

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

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

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

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

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

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

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

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

프로젝트 이슈를 확인하라

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

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

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

프로젝트의 Pull Request를 확인하라.

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

GitHub에서 Pull Request 페이지 내 “closed” tab을 누르면 Close 된 Pull Request를 볼 수 있다.

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

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

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

지금까지 오픈소스에 기여하기 위한 프로젝트의 일반적인 구조 및 동작 방식 등을 설명했다. 지금부터는 기업의 구성원이 오픈소스 프로젝트에 기여하기 위해 실제로 필요한 사항을 설명한다.

좋은 기여자가 되기 위한 길잡이

본격적으로 기여 방법을 설명하기 전에 어떻게 하면 좋은 기여자가 될 수 있을지를 간단히 알아보자. 물론 프로젝트마다 운영되는 방식이 다르므로 하나의 정답은 없다. 새로운 프로젝트에 참여할 때마다 운영 방식을 습득하기 위한 시간을 투자해야 한다. 다음 사항들은 좋은 기여자가 되기 위해 공통으로 도움이 될 수 있는 내용이다.

1. 커뮤니티에 참여하라

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

2. 잠시 살펴보라

커뮤니티에 가입한 후에는 잠시 커뮤니티의 문화를 흡수하는 시간을 가진다. 이전 커뮤니케이션을 살펴보는 것도 좋은 방법이다. 이런 과정을 거칠수록 첫 번째 기여가 수락될 가능성이 커진다.

3. 거버넌스를 이해하라

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

4. 작은 것부터 시작하라

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

5. 이벤트에 참가하라

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

6. 초기 단계의 코드부터 기여하라

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

기여를 준비해보자

자, 그럼 이제 본격적으로 오픈소스로의 기여를 준비해보자. 여기서는 여러분의 필요에 따라 기여할 오픈소스 프로젝트를 이미 선택했다고 가정한다.

1. 오픈소스 프로젝트의 문서를 숙지하라

몇 차례 언급했지만, 오픈소스 프로젝트마다 기여자에게 요구하는 절차가 다르다.

그러므로 기여하고자 하는 프로젝트의 프로세스를 제대로 이해하기 위해서는 우선 프로젝트에서 제공하는 문서를 잘 확인해야 한다. 대개의 프로젝트는 CONTRIBUTING 또는 README 파일로 이러한 문서를 제공한다.

예를 들어, Kubernetes는 기여자를 위한 자세한 가이드⁶를 제공한다. 문서에서 요구하는 사항을 잘 준수할수록 여러분의 기여가 수락될 가능성이 커진다.

2. CLA / DCO 서명은 주의하라

‌어떤 오픈소스 프로젝트는 기여자에게 CLA나 DCO에 서명할 것을 요구한다. CLA와 DCO의 자세한 사항은 앞장에서 자세히 설명하였다.

여러분이 기업의 구성원으로서 오픈소스에 기여하려 한다면 이러한 문서에 서명하는 것을 기업에서 허용하고 있는지 반드시 확인해야 한다. 이러한 문서들은 여러분이 기여하려는 저작물의 저작권을 여러분이 소유하였음을 보장해야 한다고 요구한다. 만약 여러분이 기업에 속한 구성원이라면 일반적으로 여러분이 만든 저작물의 저작권은 기업이 갖는다. 따라서, 기업으로부터 허락받지 않은 상태에서 CLA에 서명하는 것은 예기치 않은 저작권 침해 이슈에 휘말리게 될 수 있음을 반드시 주의해야 한다. CLA에 서명하기 이전에 기업의 오픈소스 정책을 확인하거나, OSPO 혹은 법무 조직에 문의하여 위험 요소를 확실히 제거하자.

CLA를 요구하는 대부분의 프로젝트는 번거로운 서면 서명 대신 bot을 이용하여 기여자가 몇 번의 클릭만으로 서명할 수 있도록 편의를 제공한다. 그래서 오히려 기여자가 쉽게 서명하고 지나갈 수 있다는 점에 더 유의해야 한다.

CLA Bot (이미지 출처 : https://colineberhardt.github.io/cla-bot)

3. 기여 코드를 점검하라

소스 코드를 기여하려고 하는가? 기여를 제출하기 전에 다음 사항을 확인하여 저작권 침해와 같은 이슈를 최소화한다.

• 기여할 권리가 있는 코드인가? 만약 기여하려는 코드에 직접 작성하지 않은 코드가 포함되었다면 여러분에게 기여할 권리가 있는지 확인해야 한다.
• 기업의 민감하거나 독점적인 정보가 노출될 수 있는 코드는 제외한다.
• 기여하려는 코드에 특허가 포함되어 있는지 확인한다. 오픈소스 라이선스는 특허 라이선스까지 부여할 것을 요구하기도 한다. 이것이 기업의 정책과 충돌되지 않는지 사전에 확인해야 한다.
• 스스로 확인하기 어렵거나 모호한 부분이 있다면 기업의 OSPO에 문의한다. OSPO가 없다면 법무 조직이나 상사에게 문의한다.

4. 기업 내부 승인을 받아라

기업의 오픈소스 정책이 요구하는 대로 내부 승인 절차를 따른다. 다시 한번 말하지만 오픈소스는 저작권과 라이선스를 기반으로 성장하고 있어서 기여할 때도 저작권 측면의 확인 절차가 필요하다. 기업에 오픈소스 기여 정책이 없으면 조직 내 의사 결정권자에게 기여 의사를 밝히고 승인받는다. 이 과정은 개발자의 입장에서 불편한 과정으로 보일 수도 있지만, 불필요한 저작권 침해 이슈를 일으키지 않도록 돕고, 이후에는 기여 작업에 집중할 수 있는 환경을 만든다.

기여는 어떻게 제출해야 하나?

이제 기여를 제출하는 방법을 알아보자. 일반적인 오픈소스 프로젝트에 기여 제출 방법과 절차는 다음과 같다.

1. 이전 이력을 확인하라

제출하려고 하는 기여가 이전에 다뤄진 이력이 있는지 확인한다. 프로젝트의 README, 이슈, 메일링 리스트를 살펴봐라. 모든 문서를 다 확인할 필요 없이, 몇 가지 키워드를 검색하면 쉽게 확인할 수 있다.

이전 자료에서 관련 내용을 찾을 수 없다면 이슈를 열거나 Pull Request를 통해 커뮤니케이션을 시작할 단계이다. GitHub에서는 Issues와 Pull Request 기능을 제공한다.

• Issues : 대화나 토론을 시작할 수 있다.
• Pull Request : 문제의 솔루션을 기여한다.

Issue 또는 Pull Request를 열기 전에 프로젝트가 제공하는 문서 (일반적으로 CONTRIBUTING 또는 README)를 확인하여 기여 절차 및 방법을 확인한다. 예를 들어 특정 템플릿을 따르도록 요구하거나, 사전 테스트를 요구할 수 있다.

기여를 위한 작업을 시작하기 전에 먼저 Issues를 오픈해서 커뮤니티 구성원에게 먼저 어떤 작업을 하려고 하는지 알리는 것도 좋은 방법이다. 때에 따라 불필요한 작업을 진행하지 않도록 도움을 받을 수 있다.

2. Issue를 생성하라

일반적으로 다음 상황에서 Issue를 생성한다.

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

프로젝트에서의 커뮤니케이션 방법을 아래에서 좀 더 구체적으로 알아보자.

3. 커뮤니케이션을 시작하라

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

정확한 의사를 전달하라

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

무조건 물어보지 말고, 먼저 스스로 해볼 수 있는 걸 하라

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

대화는 가능한 간결하게 하라

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

모든 커뮤니케이션은 공개하라

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

문의하였으면 기다려라

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

커뮤니티의 결정을 존중하라

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

무엇보다도 품위를 유지하라

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

4. Pull Request를 생성하라

기여할 내용이 모두 준비가 된다면, Pull Request를 통해 기여를 제출한다.

Pull Request 시기

일반적으로 다음 상황에서 Pull Request를 생성한다.

• 사소한 수정 사항 제출 (예: 오타, 링크 오류 등)
• Issue에서 이미 논의가 된 사항의 작업 시작

Pull Request는 작업이 완료된 이후에 해야 하는 것은 아니다. 가능한 Pull Request를 일찍 생성하여 다른 사람들의 피드백을 받는 게 좋다. 제목 줄에 “WIP” (Work in Progress)라고 표시하여 아직 진행 중인 작업이라고 표시하고, 나중에 언제든지 더 많은 Commit을 추가할 수 있다.

GitHub에서의 Pull Request 절차

일반적으로 오픈소스 프로젝트는 다음 절차대로 Pull Request 할 것을 요구한다.

[GitHub Pull Request Workflow]

Step 1. Fork

Upstream Repository를 자신의 GitHub 계정으로 Fork⁷한다.

Step 2. Clone

Fork한 Repository를 자산의 Local working directory로 Clone 한다.

$ mkdir -p $working_dir
$ cd $working_dir
$ git clone https://github.com/$user/[repository]

Upstream Repository를 Remote⁸에 추가한다.

$ cd [repository]
$ git remote add upstream https://github.com/[upstream]/[repository]

# Confirm that your remotes make sense: 
$ git remote -v

Step 3. Create a branch

먼저 main branch⁹를 fetch와 rebase¹⁰하여 최신 상태로 유지한다.

$ cd $working_dir/[repository]
$ git fetch upstream
$ git checkout main
$ git rebase upstream/main

그리고 개발용 branch인 myfeature를 생성한다.

$ git checkout -b myfeature

Step 4. Keep your branch in sync

Branch를 fetch와 rebase¹⁰하여 최신 상태로 유지한다.

# While on your myfeature branch
$ git fetch upstream
$ git rebase upstream/master

그 상태에서 code 작업을 한다.

Step 5. Commit

수정 사항을 commit¹¹한다.

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

Step 6. Push

myfeature branch의 수정 사항을 자신의 GitHub Repository에 Push한다.

git push -f origin myfeature

Step 7. Create a pull request

GitHub에서 자신의 Repository에 가면 Compare & pull request 버튼이 활성화 된 것을 볼 수 있다. 이를 눌러서 Pull Request를 생성한다.

이후 Upstream Repository의 관리자는 요청된 Pull Request를 검토하여 Merge 여부를 결정한다.

Git 사용이 처음이라면

다음의 Git에 대한 안내서를 참고할 수 있다.

• Git cheat sheet¹²
• Do it! 지옥에서 온 문서 관리자 깃&깃허브 입문¹³
• 누구나 쉽게 이해할 수 있는 Git입문¹⁴

Pull Request가 처음이라면

• Make a Pull Request¹⁵(비디오 강의)를 참고한다.
• 또한, First Contributions¹⁶에서 Pull Request 만드는 것을 연습할 수 있다.

5. Feedback을 받아라

기여를 제출하면 프로젝트로부터 Feedback을 받게 된다.

Feedback은 보통 다음 네 가지 중 하나에 해당한다.

응답이 없다?

기여하기 전에 프로젝트가 활발한지 먼저 확인하는 게 좋다. 어느 정도 활발한 프로젝트에서도 기여에 대해 응답받지 못할 수도 있다. 일주일 이상 응답받지 못한 경우, 동일한 스레드에 정중하게 누군가에게 검토를 요청하는 것이 좋다. 적절한 사람의 이름을 알고 있다면 @-멘션 기능을 이용한다.

단, 개인적으로 연락하지는 마라. 오픈소스 프로젝트에서 공개 커뮤니케이션은 필수이다.

그런데도 여러 가지 이유가 있겠지만 아무도 반응하지 않을 수도 있다. 썩 좋은 기분은 아니지만 낙담할 필요는 없다. 이는 누구에게나 일어날 수 있는 일이다. 기여할 수 있는 다른 방법이나 다른 프로젝트를 찾아보라.

수정을 요청한다?

아이디어 설명이나 코드를 수정하라는 요청을 받는 것은 일반적이다. 이렇게 누군가 수정을 요청했다면 바로 응답한다. 그는 자기 시간을 내서 우리 기여를 검토했다.

Pull Request를 생성한 상태로 응답하지 않고 남겨두는 건 실례이다. 더 문제를 해결할 여건이 아닌 경우라면, 메인테이너에게 더 진행할 수 없다고 알려라. 그렇게 Pull Request를 Close 하거나 다른 사람이 인수하여 추가로 진행할 수 있게 한다.

거절됐다?

여러분의 기여는 결국 수락될 수도 있고, 수락되지 않을 수도 있다. 수락되지 않은 이유가 잘 이해되지 않을 경우, 메인테이너에게 설명을 요청할 수도 있다. 그러나 그들의 결정을 존중해야 한다. 논쟁하거나 적대적으로 행동하지 마라. 끝까지 이견이 조율되지 않으면, 언제든지 Fork 하여 자신의 프로젝트에 작업할 수 있다.

코드가 승인되기까지 여러 차례의 반복적인 수정 과정을 거쳐야 할 수도 있으며, 때에 따라서는 거부될 수도 있다. 이때는 낙심하거나 포기하기보다는 거부된 이유를 자세히 알아보고, 다음 기여가 향상되는 기회로 삼는 것이 좋다.

수락됐다!

축하한다! 드디어 오픈소스 기여에 성공했다.

지금까지 오픈소스 기여의 혜택과 필요성, 기업의 오픈소스 기여 정책 수립을 위한 고려 사항, 개인의 오픈소스 기여 방법에 대해 세세하게 알아보았다. 오픈소스 기여를 통해 오픈소스 커뮤니티에 참여해보라. 회사에서 배울 수 없었던 새로운 경험을 하게 될 것이다. 진정한 업계의 고수들을 만나고, 다시 열정이 솟아오를 것이다. 그렇게 역량이 쌓여가고, 회사 내 주위에 영향력을 미치게 된다. 그러면서 회사의 개발 역량도 향상된다. 기업은 구성원들이 오픈소스 커뮤니티에 참여하는 것을 장려하라. 결국에는 기업의 자산인 개발자들의 역량이 증가하게 된다. 단, 기업은 기업의 지식재산 보호를 위한 최소한의 정책을 수립하고 이를 개발자들이 충분히 인식할 수 있도록 교육한다. OSPO를 만들어 이런 활동이 회사 전체에 전파되도록 한다.

다음 장에서는 한 걸음 더 나아가서 기업이 개발한 소프트웨어를 오픈소스로 공개하고, 커뮤니티를 활성화하는 과정을 설명한다.

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.