Apache 프로젝트 만들기(2)

지난 글에서는 Apache 프로젝트의 조직과 Apache에 프로젝트를 만드는데 있어 주의해야 할 사항들이 대해 이야기 했습니다. 이번 글에서는 본격적으로 Apache에 프로젝트를 만드는 과정에 대해 자세하게 살펴보겠습니다.

프로젝트 Cycle

Apache 프로젝트는 다음과 같은 사이클로 생성 및 운영이 됩니다. 이전에는 바로 Top Level 프로젝트로 등록되는 경우가 간혹 있었지만 최근에는 대부분 인큐베이션 프로젝트 단계를 거쳐 정식 프로젝트로 승인되게 되어 있습니다. Apache는 프로젝트의 코드나 기술 자체에 대한 성숙도보다는 오픈소스 프로젝트의 커뮤니티에 대한 성숙도를 더 중요하게 생각하고 있다고 볼 수 있습니다.

오픈소스 프로젝트는 많은 개발자가 자발적으로 참여하는 경우가 많습니다. 최근에는 이런 부분이 많이 없어진 것 같아 안타깝기는 하지만 이 주제에 대해서는 뒤에 다시 논의 해보겠습니다. 따라서 단순히 반짝 개발되었다가 지속적으로 패치의 추가나 업그레이드 되지 않는 프로젝트를 방지하기 위해서는 커뮤니티의 성숙성이 더 중요하다고 할 수 있습니다. 기술 또는 솔루션의 우수성은 커뮤니티가 건전하게 ,꾸준하게 운영되면 따라오는 부산물인 경우가 많기 때문입니다.

apache_project_cycle

그림에서 보는 것과 같이 Apache 프로젝트의 운영은 인큐베이션 프로젝트와 정식 프로젝트인 탑 레벨 프로젝트와 차이는 없습니다. 다만 프로젝트의 배포, 커미터 추가 등과 같은 중요 의사결정 및 테스크의 실행을 프로젝트 내부의 의사 결정 만으로 하느냐, Incubation Project Management Committee 의 도움 및 승인을 받는지의 차이만 있습니다.

Apache에 프로젝트를 만드는 과정에서 가장 어려운 부분은 인큐베이션 프로젝로 승인을 받는 것입니다. 물론 이후에 프로젝트 커뮤니티를 활성화 시키는 것도 쉽지는 않지만 인큐베이션에 등록이 되어야만 그 이후의 과정을 진행할 수 있기 때문에 인큐베이션 승인 과정이 가장 중요하면서도 어려운 과정이라 할 수 있습니다.

Proposal 준비

프로젝트 생성을 위해서는 Proposal을 제출해야 하는데 단순히 문서만 작성한다고 해서 제출할 수 있는 것이 아닙니다. 흔히들 Apache 프로젝트가 되기 위해서는 어느 정도 실행되는 소스 코드가 필요하다고 생각하는데 소스 코드가 반드시 필요한 것은 아닙니다. 지금은 유명한 HBase 라는 분산 데이터 저장소 프로젝트의 경우에는 소스 코드 없이 인터페이스 정의만으로 제안을 하기도 했습니다.

소스 코드를 공개된 Repository에 업로드

보통 소스코드를 공개하기로 결정하면 개발자들은 자신의 코드가 외부에 노출되기 때문에 코드의 품질을 높이는 작업을 마친후에 공개하려고 합니다. 하지만 개인적인 의견으로는 소스 코드 자체의 품질은 그렇게 중요하지 않다고 생각합니다. 그 코드를 만드는데 참여한 사람들, 즉 앞으로 오픈소스 커뮤니티를 이끌고 갈 Initial Member 들의 마인드가 더 중요하다고 생각합니다. 따라서 Proposal을 준비하는 단계에서는 소스 코드의 품질을 높이는 작업 보다는 어떻게 하면 커뮤니티를 잘 만들고 운영할 것인가에 더 집중하는 것을 제안합니다.

Apache의 모든 프로젝트의 패키지는 자바의 경우 <project_name>.apache.org 이지만 이 단계에서는 제안만 하는 단계이기 때문에 기존에 사용하는 패키지명, 프로젝트 명을 그대로 사용합니다. 코드의 공개는 github, bitbucket 등과 같이 공개된 Repository 서비스를 이용하거나 자체 구축한 공개된 Repository를 이용합니다.

프로젝트 명 검토

프로젝트 명은 중요하지는 않지만 가급적이면 기존에 동일한 분야에 유사한 솔루션이 있는 경우 사용하지 않는 것이 좋습니다. 유사한 솔루션이 있거나 Apache에서 정한 프로젝트 이름 규칙에 부합되지 않는 경우 인큐베이션 승인 시에 프로젝트 명칭에 대한 변경을 요청하는 경우도 있고, 승인 이후에 첫번째 배포 시에 변경을 요청하는 경우가 간혹 있습니다. 이렇게 변경 요청이 오면 패키지부터 모두 바꿔야 하기 때문에 여간 귀찮은 작업이 아닙니다. 따라서 선정 시 다음 문서를 참고해서 여러가지를 점검해보고 선정하는 것이 좋습니다.

사용 라이브러리의 라이센스 확인

Proposal 준비 단계에서 점검할 필요는 없지만 꾸준히 확인하는 것이 좋습니다. Apache 프로젝트에 포함시킬 수 있는 오픈소스는 Apache 라이센스와 호환이 되는 라이센스만 가능합니다. BSD나 MIT 라이센스가 대표적이라 할 수 있습니다. 그리고 각 라이센스에서 명시하고 있는 제약조건을 반드시 지켜야 합니다. 예를 들면 해당 프로젝트의 License 파일을 어디에 위치시켜야 한다거나 사용했다는 것을 README 등이 반드시 명시해야 한다는 등입니다.

갈수록 외부 라이브러리를 많이 사용하게 되는 경향이 있는데 이 부분은 꾸준히 확인해야 하는 사항이며 외부 라이브러리 선택할 때에도 반드시 호환 라이센스인지 확인하는 절차를 반드시 거치는 것이 좋습니다.

관련 문서 공개

제안을 받으면 IPMC 역할을 수행하는 분들이나 투표에 참여하는 분들은 이 프로젝트가 어떤 프로젝트인지 확인해보려고 합니다. Proposal 문서 상에서는 모든것을 표현하기 어렵기 때문에 가능한 영어로 되어 있는 솔루션 소개 자료를 공개된 서비스에 올려 놓는 것이 좋습니다. 논문이 있으면 가장 좋고 그렇지 않더라도 개념 소개나 Usecase 등에 대한 소개 자료를 Slideshare 등에 공유하는 것을 추천합니다.

Champion을 찾아야 함

Proposal을 완성하고 제출하기 하고, 인큐베이션으로 승인된 이후에도 지속적으로 프로젝트 운영을 도와줄 스폰서를 찾아야 하는데 이를 Champion 이라고 합니다. Project Proposal을 실제 Apache에 제출하는 것도 이 Champion의 역할입니다. Champion은 아무나 수행할 수 없는데 Apache의 Member나 Officer 라야 가능합니다. 이들은 전세계에도 수백명 정도이기 때문에 지원을 받기가 쉽지 않습니다. 어쩌면 프로젝트 생성 과정에서 가장 어려운 과정이라고도 할 수 있습니다. 적극적으로 후원해주는 Champion을 찾는 것이 인큐베이션 승인을 받을 수 있는 가장 좋은 방법입니다. 물론 프로젝트 제안 자체가 매력적이라야 하는 것은 기본이고요.

알고 있는 Apache Member가 없는 경우 위 링크에 있는 Member 중에 자신의 솔루션 영역에서 활동하고 있는 Member를 찾아 메일로 Champion이 되어 줄 것을 부탁할 수도 있습니다. 챔이언이 되어 줄 Member를 찾을 때에는 기존의 인큐베이션 프로젝트를 보면 여러 프로젝트에 챔피언을 하고 있는 Member가 있는데 그런 분들에게 부탁하는 것이 수락할 가능성이 더 높습니다. Tajo의 경우 메일을 보내서 수락받아서 챔피언을 찾았습니다.

그리고 또 다른 방법은 소스 코드를 공개할 생각이 있으면 Apache Conference나 Apache Member 들이 참석하는 Conference 또는 Meetup 에 해당 솔루션에 대해 발표할 것을 권합니다. 발표하면서 자연스럽게 기존의 아파치 커미터와 친분을 쌓은 후 챔피언이 필요한 시점에 친분을 통해 찾아보는 것이 가장 좋은 방법이라고 생각합니다. Zeppelin의 경우 이런 방법으로 챔피언을 찾은 것으로 알고 있습니다.

Mentor도 찾아야 함

챔피언을 찾았으면 이제 Mentor를 찾아야 합니다. Mentor는 3명으로 구성하는 것을 권장하고 있습니다. Mentor는 인큐베이션 과정에서 도움을 주는 역할을 수행하게 되는데 Mentor로 선정 가능한 사람은 IPMC의 멤버라야 합니다. IPMC 멤버 3명의 수락을 받는 것도 쉬운 일은 아닌데 처음에는 직접 부탁해서 찾는 과정을 거친 후 그래도 찾을 수 없는 경우에는 챔피언에게 도움을 요청하면 됩니다.

IPMC가 아닌 다른 프로젝트의 PMC를 Mentor로 선정할 수도 있는데 이 경우에는 반드시 해당 Mentor가 IPMC의 멤버가 되도록 요청을 해야 합니다.

Initial Committer 선정

다음은 초기 Committer를 지정해야 하는데 가능하면 커미터는 여러 회사, 여러 국가의 개발자로 구성하게 하는 것이 좋습니다. 물론 한두군데 회사나 국가에 집중되는 경우에도 문제가 없다고는 하지만 선정 확률을 높이기 위해서는 다양하게 구성하는 것을 권장합니다. 이것은 한 회사나 지역에서만 운영되는 커뮤니티의 경우 해당 회사가 사라지거나 회사에서 관심을 더 이상 주지 않는 경우 안정적인 커뮤니티 운영이 어렵다고 생각하기 때문입니다.

Proposal 작성

앞의 모든 항목이 정리되면 가장 중요한 Proposal 문서를 작성해야 합니다. 이 문서는 Apache에서 정해진 양식이 있으며 다음 링크에서 확인할 수 있습니다.

각 항목들을 보면 기술이나 솔루션에 대한 설명보다는 커뮤니티 운영에 대한 항목이 더 많은 것을 알 수 있습니다. 처음부터 그냥 작성하기 보다는 기존 프로젝트의 Proposal을 참고해서 작성하는 것이 좋습니다.

현재의 인큐베이션 프로젝트 목록에서도 기존의 제안서를 볼 수 있으며 Incubation mailing list를 찾아보면 과거의 다양한 Proposal을 찾아 볼 수 있습니다.

Proposal 제출

이제 모든 준비가 되었으면 챔피언에게 Proposal 을 전달하여 Apache에 제출을 요청하면 됩니다. 챔피언은 IPMC 메일링 리스트에 Proposal에 대한 토론을 요청하는 것으로 제출하게 됩니다.

메일링 리스트에 제출이 되면 다양한 IMPC 구성원들이 의견을 주는데 이들 사항을 반영하거나 의견을 달아서 해결을 해야 합니다. 대부분의 토의 항목이 해결되면 챔피언은 투표 요청을 하게 됩니다. 다음은 Netbean 프로젝트의 투표 요청 메일입니다.

Apache의 모든 의사 결정은 투표로 진행됩니다. 일반적으로 투표는 메일링 리스트에 안건을 상정하고 해당 메일에 답장으로 자신의 투표권을 행사합니다. Apache에 기본적인 Voting Rule을 가지고 있는데 다음URL에서 확인할 수 있습니다.

  • Apache의 기본 Voting Rule: http://www.apache.org/foundation/voting.html
  • ASF의 일반적인 투표 룰은
    • 다음 세가지 종류의 투표가 있음
      • Code modifications
        • +1이 3개 이상, -1이 없어야 함
        • -1이 하나라도 있으면 통과 못함(거부권, veto)
      • Package releases
        • +1이 3개 이상이고 -1의 수보다 많으면 통과
        • 그렇지만 대부분의 프로젝트에서는 -1이 있으면 재투표
      • Procedural
        • +1이 3개 이상이고 -1의 수보다 많으면 통과
    • Binding Votes
      • PMC 멤버만 유효한 표
    • Lazy Consensus
      • 특정 일자내에 아무헌 의견이 없으면 통과
        • "The patch below fixes bug #8271847; if no-one objects within three days, I'll assume lazy consensus and commit it.”
      • Code modification에서 review-then-commit 정책을 사용하는 프로젝트에는 적용이 안됨
    • 하지만 일반적으로는 다음과 같이 진행
      • 메일링 리스트를 통해 진행
      • Code modifications Committer 중 한명이 +1이 있고 -1이 없으면 통과 Project Guide 페이지에 명시 https://cwiki.apache.org/confluence/display/TAJO/How+to+Contribute+Codes+to+Tajo Committers: for non-trivial changes, it is best to get another committer to review your patches before commit. Attach your patch on the relevant jira issue in order to share your patch, and then wait for a "+1" from another committer before committing.
      • Package release, Procedural 72시간 투표 시간 Binding +3 이상, No -1

이런 투표룰을 이용하여 인큐베이션 승인 투표를 진행하는 데 다음과 같은 룰을 따릅니다.

  • Incubator PMC member 만 유효표
  • -1이 한표도 있으면 안됨
  • 투표에서 미 통과 시 -1 사유에 대해 해결 후 다시 재투표 요청 가능

마치며

지금까지 아파치에 프로젝트를 만들기 위한 첫 관문이면서 가장 어려운 과정이라고 할 수 있는 Proposal 준비와 Proposal 제출, 승인 투표 과정에 대해 설명드렸습니다. 제가 완전히 프로젝트를 만들어 본 것이 아니라서 중간에 오류가 있을 수 있지만 전반적으로 이런 흐름으로 진행된다는 수준으로 이해해 주셨으면 합니다. Proposal 준비 과정에서도 보는 것 처럼 소스 코드 자체에 대한 내용보다는 솔루션의 개념, 컨셉을 더 비중있게 보며, 커뮤니티의 안정적인 운영 능력도 승인을 위한 중요한 판단 기준이 됩니다. Proposal을 제출하기 위해서는 Apache에 소속된 사람들의 도움이 필요한데 이를 위해 평소 온/오프라인으로 친분을 쌓아둘 것을 추천해드리고 싶습니다.

다음 글에서는 인큐베이션에 선정된 이후 프로젝트 셋업을 위한 활동과 Top Level 승인을 위한 조건 등에 대해 살펴보도록 하겠습니다. 한국 개발자들이 주도적으로 만든 프로젝트들이 많이 생성되었으면 하는 바램입니다.

Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.