Apache 프로젝트 만들기(1)
모대학에서 오픈소스 관련 특강 요청이 와서 어떤 주제로 할 것인가 고민하다가 특정 오픈소스에 대한 이야기보다는 "오픈소스 프로젝트 따라잡기" 라는 주제로 진행하였습니다. 이번 글에서는 강의 내용 중 Apache Software Foundation(이하 ASF)에 프로젝트를 만드는 방법 및 절차에 대해 정리해보았습니다. 발표자료는 다음 링크를 참고하세요.
http://www.slideshare.net/babokim/ss-70026310
최근 한국에서도 개발자나 회사들이 ASF에 오픈소스 프로젝트 만드는 것에 관심이 많아 졌습니다. 과거에는 국내에서는 오픈소스를 사용만 했었습니다. 최근 몇 년사이에 한국 개발자가 중심이 된 여러 오픈소스 프로젝트가 ASF에 만들어지면서 점차 이런 생각이 많아지고 있는 것 같습니다.
Why Apache Software Foundation?
- 높은 인지도 ASF의 프로젝트라는 것만으로도 이미 브랜드는 얻었다라고 할 수 있습니다. 해당 프로젝트를 만든 팀이 유명하지 않거나 프로젝트를 홍보할 수단이 마땅히 없는 경우라면 ASF에 프로젝트를 만들어 볼 것을 추천합니다. 필자가 참여한 오픈소스 프로젝트의 경우에도 ASF에 올라가기 전에 모기업에 과제를 같이 하자고 했지만 부정적인 피드백을 받았는데 ASF에 올라간 이후에는 좋은 피드백으로 과제를 진행할 수 있었습니다. 또한 글로벌한 네트워크가 약한 한국 개발자가 중심으로 만든 프로젝트라면 글로벌하게 사용되게 하기 위해서는 ASF가 좋은 대안이 될 수 있습니다.
- 인지도가 솔루션에 대한 신뢰도는 아님 ASF는 솔루션이 뛰어나고 우수하다는 것을 보장하지는 않습니다. ASF는 오픈소스 프로젝트가 잘 운영되고 꾸준히 개선활동을 이룰 수 있는 프로젝트인지에 대해서만 보장을 합니다. 즉, ASF에 등록된 프로젝트는 최소한 오픈소스 프로젝트가 갖추어야 할 사항인 잘 구성된 개발자 커뮤니티, 코드 기여자, 이를 잘 운영, 관리할 수 있는 PMC 구성 등을 검증 받은 프로젝트라 할 수 있습니다.
- ASF의 신뢰도는 다음과 같은 이유때문에 나온다고 할 수 있습니다.
- 공정하고 합리적인 프로세스
- 소스코드 자체보다는 프로젝트의 영속성, 투명함, 공정성 등을 더 중요하게 생각
- 특업 업체에 종속되지 않고 독립적으로 운영
ASF에 프로젝트를 만들기 전에 반드시 생각해야 할 사항
ASF에 프로젝트를 만들기 전에 반드시 생각해야 할 점이 있는데 이것을 간과하면 프로젝트 공개 후 이 프로젝트를 이용하여 비즈니스하는데 있어 난처한 상황이 발생할 수 있습니다. ASF에 프로젝트를 만드는 것은 ASF에 해당 프로젝트의 모든 권한을 양도하는 행위입니다. 여기서 모든 권한이라는 것은 프로젝트 명, 소스코드, 로고, 문서 등을 포함한 프로젝트 모든 사항을 의미합니다. 따라서 해당 프로젝트의 지적재산권은 ASF가 가지기 때문에 특정 회사가 주도하여 프로젝트를 만들거나 회사의 소스 코드 그대로를 ASF에 제공한 경우라도 동일합니다.
프로젝트를 만든 회사라고 하더라도 회사 로고와 Apache 프로젝트의 로고를 병행표기 할 수 없으며, 회사명을 Apache 프로젝트와 동일하게 할 수 없습니다. 회사의 제품명에도 해당 프로젝트 명을 사용할 수 없습니다. Hadoop에 많은 기여를 하고 있는 Hortonworks와 Cloudera의 공식 제품 명칭도 각각 HDP, CDH로 Hadoop이라고 명시적으로 표시하지는 않습니다.
최근 한국 회사가 중심이 되어 개발한 Zeppelin(https://zeppelin.apache.org/)의 경우에도 최근 투자를 받으면서 회사명을 변경할 때 ZeppelinX로 변경하였지만 라이센스의 문제로 ZEPL로 회사명을 정한 사례도 있습니다.
ASF에 프로젝트를 생성하기나 코드를 공개하기 전에는 반드시 이런 사항을 고려해서 비즈니스 실행 전략을 수립해야 합니다. 이런 것을 모르고 잘못 실행하게 되면 지적재산권 위반을 하게 됩니다. 애매한 경우 반드시 ASF에 확인해보고 실행하는 것이 좋습니다. 자세한 사항은 다음 URL을 참고하세요.
특정 회사가 만든 제품이 Apache의 프로젝트와 관련 있는 제품이라면 다음과 같이 Powered By 라는 로고는 사용하는 것을 허용하고 있습니다.
ASF의 역할 이해하기
ASF에도 커미터, PMC 등과 같은 여러가지 호칭이 있습니다. 이런 역할을 나누는 것은 상하 관계를 가지는 것이 아니라 프로젝트에 필요한 역할을 나눔으로써 자발적으로 모여 이룬 조직이나 프로젝트가 잘 운영되도록 하기 위함입니다. 이 역할의 명칭을 잘 알고 있어야만 아파치 프로젝트의 관리나 운영 등에 대해서도 잘 이해할 수 있습니다.
- Contributor 아파치 프로젝트에 기여를 하는 모든 사람을 Contributor라고 합니다. 넓은 의미로는 Committer, PMC 등도 모두 포함하지만 좁은 의미로는 코드 Committer 권한은 아직 가지고 있지 않지만 소스코드나 버그 리포트, 매뉴얼 작성 등에 도움을 주는 사람을 Contributor라고 합니다.
- Committer 아파치 특정 프로젝트의 소스 코드 레포지토리에 코드를 commit 할 수 있는 권한을 가진 사람을 의미합니다. Committer는 해당 프로젝트 멤버들의 투표에 의해 선정되며 Committer 선정 기준은 각 프로젝트마다 다릅니다.
- PMC(Project Management Committee) PMC는 프로젝트의 의사 결정을 위한 협의체로 Committer 중에서 몇명이 PMC에 소속되어 있습니다. PMC는 코드 릴리즈의 승인, 새로운 Committer의 승인 등 프로젝트의 주요 활동에 대해 의사 결정을 하게 됩니다.
- PMC Chair PMC Chair는 PMC 중 의장에 해당합니다. PMC Chair는 특별한 권한이 있다라기 보다 겉으로는 주로 의사 결정을 위한 안건을 상정하고, 투표를 진행하고, 진행결과를 공표하는 등의 업무를 수행합니다. 하지만 실제적으로는 프로젝트가 잘 운영될 수 있도록 뒤에서도 많은 고민과 다양한 활동을 수행하고 있습니다.
여기까지가 하나의 프로젝트에 관련된 역할입니다. 다음은 ASF 운영 자체에 대한 역할입니다. 저도 여기에 속해 있지 않기 때문에 정확하게는 알지 못하고 홈페이지에 있는 내용 정도 입니다. 틀린 부분이 있으면 알려주시면 바로 수정하겠습니다. ASF 는 일반적인 회사와 비슷한 역할을 가지고 있지만 모두 보수를 받지 않는 자원봉사자들로 구성되어 있습니다.
- Member Member는 일반 회사의 주주와 같은 개념으로 공개적으로 모집하지 않고 다른 멤버들의 추천 및 투표에 의해 선정됩니다. 멤버는 다음 페이지에서 확인할 수 있습니다. http://www.apache.org/foundation/members.html
- Director Director는 새로운 member를 선정하고, ASF의 정책을 결정하는 등 일반 회사의 이사회 역할을 수행합니다. 현재 이사회는 9명으로 구성되어 있으며 Director 목록은 다음에서 확인할 수 있습니다. http://www.apache.org/foundation/board/
- Officer ASF의 법률, 행정, 펀딩, 인프라, 컨퍼런스 지원 등의 행정적인 업무를 주로 수행합니다.
좀 더 자세한 내용은 다음 페이지를 참고하세요.
이 외에 인큐베이션 프로젝트 관련 조직도 있는데 ASF에 프로젝트를 만드실 분이라면 다음 두 용어를 많이 듣게 되실겁니다.
- PPMC(Podling PMC) 인큐베이션 단계에 있는 PMC를 일컫는 용어 입니다. Top level 프로젝트의 PMC와 구분을 하기 위해 사용하고 있습니다.
- IPMC(Incubation Project Management Committee) ASF의 프로젝트는 정식 프로젝트(Top-Level) 가 되기 전에 반드시 인큐베이션 단계를 거쳐야 하는데 인큐베이션 단계에 있는 프로젝트가 잘 운 영 될 수 있도록 도움을 주고 관리해주는 프로젝트의 멤버를 IPMC라고 부릅니다. 인큐베이션 프로젝트의 시어머니라고 할 수 있습니다.
ASF 프로젝트 프로세스
앞에서도 잠깐 언급 했지만 ASF 프로젝트에는 Top-Level 프로젝트라고 부르는 정식 프로젝트와 아직 정식 프로젝트로 승인 받지 않은 인큐베이션 프로젝트(Podling 프로젝트)가 있습니다. ASF 프로젝트라고 하면 일반적으로는 Top-Level 프로젝트라고 합니다. ASF는 Top-Level로 직접 프로젝트를 승인하는 경우는 거의 없으며 모두 인큐베이션 단계를 거치도록 하고 있습니다. 이것은 인큐베이션 단계에서 ASF의 룰과 프로세스를 익히고, 커뮤니티를 활성화 시키고, Committer를 확보하는 등 프로젝트가 안정적으로 운영될 수 있는 지를 검증하기 위함이라 할 수 있습니다. ASF 프로젝트가 인정 받는 이유도 이런 인큐베이션 과정을 거친 프로젝트만 Top-Level 로 승인해주기 때문이라고 볼 수 있습니다.
다음 그림은 ASF 프로젝트의 운영 과정을 나타낸 그림입니다.
ASF에 프로젝트를 생성하기 위해서는 먼저 제안서를 작성해서 제출해야 하며 이 제안서가 승인이 되면 인큐베이션 프로젝트가 됩니다. 인큐베이션 프로젝트는 IPMC의 가이드를 받으며 짧게는 2 ~ 3개월, 길게는 1년 이상 인큐베이션 프로젝트로 있으면서 프로젝트 운영을 하게 됩니다. 프로젝트 운영은 일반 개발 프로젝트와 운영과 동일합니다. 이렇게 잘 운영되면 다시 투표에 의해 Top-Level 프로젝트로 선정되며 이때부터가 진정한 Apache 프로젝트라고 할 수 있습니다.
이번 글에서는 왜 ASF인가와 ASF의 조직 구성, ASF의 프로젝트 프로세스에 대해 간단하게 살펴보았습니다. 다음 글에서는 인큐베이션 프로젝트 선정 프로세스 및 제안 과정에 대해 자세하게 살펴보겠습니다.