오픈소스 프로젝트 어떻게 참여하고 Apache 오픈 소스 프로젝트틑 어떻게 선정되고 운영되는지를 소개

1. 오픈소스 프로젝트 따라잡기 김형준 2016.10

2. 김형준(babokim)
현재 Jobplanet
Bigdata, Tajo (Gruter)
Hadoop, Naver Mail (Naver)
공공 SI, 전자 ITO (SDS)
Apache Tajo PMC & Committer
popit.kr Service Contirbutor

3. Open Source

4. http://www.ceitechs.com/page-technologies

6. http://programmers.stackexchange.com/questions/31603/why-does-
microsoft-have-such-a-bad-reputation-with-the-people-involved-in-open-s

7. 누가 만드는가?
Mainly contributed by “zeppelinX”
개인이 만들거나 회사에서 만든 코드를 공개

8. 대학 또는 정부 연구실
고려대학교 데이터베이스랩 UC Berkeley Amplab
USA Nation Security Agency NASA

9. 왜 만드는가?
개인: 기술적인 호기심/재미, 개인 명성
Cloud 환경에서는 플랫폼 영향력이 필수
http://www.infoworld.com/article/3121247/open-source-tools/bossies-2016-the-best-of-open-source-software-awards.html
기술력 과시, 좋은 개발자 채용,
오픈소스 커뮤니티를 이용한 꾸준한 개선
서비스 회사
소프트웨어 솔루션 회사
핵심 솔루션의 시장 점유율 확대를 위해 부가 솔루션 오픈(Eclipse 등)
Google didn’t used to share its source code with the rest of us. It used to share research
papers, then leave it to others to come up with the code. Perhaps Google regrets letting
Yahoo steal its thunder with Hadoop. Whatever the reason, Google is clearly in the thick
of open source now, having launched its own projects -- TensorFlow and Kubernetes -- that
are taking the world by storm.

10. 오늘의 주제
Open Source
가 아니라
Open Source
Project

11. 오픈소스 프로젝트 발담그기
기존 프로젝트에 참여
프로젝트 직접 생성
오픈소스 활용

12. 발담그기 전에 이것만은 알자!
개발 능력은 중요하지 않음!!!
룰/프로세스
커뮤니케이션
꾸준함

13. 가장 중요한 하나 더
babokim이 아닌
Hyoungjun Kim 이라야 함

14. 기존 프로젝트 참여하기
코드 분석
이슈 등록
Patch 개발리뷰 대응
이슈 종료
참여 분야 선정
프로젝트 선정
Committer
자격

15. 왜 참여해야 하는가?
• 오픈소스 프로젝트를 통해 선진화된 개발
프로세스 경험
• 국내 어떤 개발 조직보다도 잘 갖춰진 프로세스
• 학교 생활 또는 인턴 경험 등으로는 얻을 수 없는 경험
• 전설속의 개발자들을 만날 수 있다.
• 전세계 고수들의 코드를 직접 볼 수 있음
• 필요하면 고수의 코드에 질문도 할 수 있음
• 고수들이 만든 코드에 자신의 코드를 추가 할 수 있음
• 고수들이 나의 코드를 리뷰해 줌

16. 프로젝트 선정
• 현재 업무와 관련 있는 프로젝트
• 프로젝트에 기여 -> 팀/조직에 기여
• 관련 없으면 꾸준하게 하기 어렵다.
• 프로젝트 운영이 오픈되어 있는지 확인
• 많은 오픈소스 프로젝트가 폐쇄적으로 운영
• 커미터가 아닌 Contributor의 코드가 얼마나
커밋되는지 확인
• 새로운 커미터가 얼마나 등록되는지 확인
• 적당한 수준의 인기도
• 너무 인기가 많으면 경쟁도 심함
• 너무 인기가 없으면 왜 하는지에 대한 생각이 듬

17. 참여 분야 선정
• 소스 코드만 전부가 아니다!!!
• 문서 작업
• 매뉴얼, 위키, 홈페이지 관리, 한글화 등
• 버그 리포트
• 버그 이슈 등록
• 이메일 대응
• 메일링 리스트에 질문 등에 대한 대응
가능한 자신의 이름을 지속적으로
오픈소스 프로젝트 커뮤니티에
남기는 것이 가장 중요.

18. 코드 분석
http://www.popit.kr/오픈소스-코드-분석-어떻게-하나/

19. 이슈 등록
• 기존에 중복된 이슈가 있는지 반드시 검색
• 중복된 이슈가 있고 할당된 개발자가 없으면
Comment로 내가 하면 안되냐고 질문
• 할당된 개발자가 있는데 오랫동안 진행이
안되었으면 Comment로 프로젝트에 이 기능이
필요한데 내가 진행하면 안되냐고 질문
• 변경 사항이 많은 경우 Proposal 형태로 이슈
등록
• 여러 프로젝트 멤버들이 구현 방식에 동의를
해야하기 때문에 Proposal 하고 토론 후 구현방식
확정 후 진행하는 것이 바람직
• https://issues.apache.org/jira/browse/HADOOP-1687

20. Patch 개발
• 반드시 해당 프로젝트의 코딩 컨벤션 준수
• TestCase는 반드시 추가
• Patch 업로드 이전에 반드시 Full Test 수행
• 오픈소스 git 프로젝트에 Pull Request 보내기
참고

21. 리뷰 대응
• 대부분의 리뷰 댓글은
• Contributor를 도와주기 위해서이거나
• 프로젝트의 방향을 안정적으로 운영하기 위해서임
• 참여 초기에는 가능한 댓글에 긍정적으로
반응하는 것을 추천
• 자신의 구현방식과 다른 방안 제시 리뷰에
대해서는 논리적인 근거를 바탕으로 설득해야
함

22. 이슈 종료
• Commit 로그 등에 자신의 이름이 들어 갔는지
확인
• 처음에는 오래 걸리는 이슈를 하기 보다는 작은
이슈를 많이 하는 것을 추천
• 기존 Committer를 귀찮게 해야 함
• 이제 니 코드 대신 올려주기 귀찮으니 니가 직접
Commit 해라.

23. 기타 활동
• 꾸준히 Meetup 참석
• 뒷풀이가 알짜

24. Apache 프로젝트 만들기
마일스톤
정리
개발
테스트토론
릴리즈
Incubation 승인
Proposal
Top Level
승격
프로젝트 환경 구성

25. Why Apache Software
Foundation?
• 높은 인지도
• ASF에 있다는 것 자체만으로도 프로젝트 자체에 대한
검증은 되었음
• Global network가 없는 상황에서는 ASF의 network를
활용하는 것이 최선
• 주의: 솔루션 자체에 대한 신뢰는 아님
• ASF 신뢰도는 어디에서 오는가?
• 공정하고 합리적인 프로세스
• 소스코드 자체보다는 프로젝트의 영속성, 투명함,
공정성 등을 더 중요하게 생각
• 특업 업체에 종속되지 않고 독립적으로 운영

26. 반드시 생각해야할 사항
• ASF에 프로젝트를 만드는 것은 해당 솔루션의 모든
권한을 ASF에게 넘기는 것을 의미
• http://www.apache.org/foundation/marks/
• 프로젝트 명, 로고, 문서 등
• 개발한 회사 조차도 제품명에 ASF의 프로젝트 명을 사용할 수
없음
• Cloudera Hadoop Distribution <- 사용불가
• CHD <- 사용 가능
• 회사 로고와 ASF 프로젝트 로고를 나란히 배치하는 것도 불가

27. ASF Process
• http://incubator.apache.org

28. Incubation이 되기 까지
http://incubator.apache.org/incubation/Process_Description.html

29. Apache Org Chart

30. Apache Role
• Contributor
• Committer
• PMC(Project Management Committee)
• PMC Chair
• Officer
• Member
• Director
• PPMC(Podling PMC)
• IPMC(Incubator Project Management Committee)

31. Proposal
• http://incubator.apache.org/guides/proposal.html
• 예: Apache Tajo Proposal
• https://wiki.apache.org/incubator/TajoProposal
• Incubation mailing list를 참고
• http://mail-archives.apache.org/mod_mbox/incubator-
general/

32. Proposal 준비 사항
• 소스 코드를 공개된 Repository에 업로드
• 코드의 품질은 중요하지 않음
• 이 상태에서는 코드의 패키지는 원래 코드의 패지키
그대로 사용(예: kr.popit.xxx)
• github.com, bitbucket.org 등 이용
• 프로젝트 명 검토
• 해당 분야에 유사한 솔루션 명이 있으면 안됨
• IPMC에 의해 변경 요청을 받을 수도 있음
• Dependency가 있는 프로젝트의 라이센스 확인
• Apache 호환 라이센스라야 함(가장 중요)
• 관련 Document 공개
• Slideshare 등에 ppt 자료 등 공개(영문)
• 소스 코드 공개 사이트에도 관련 문서 공개

33. Proposal 준비 사항
• Sponsor 중 Champion을 찾아야 함
• 가장 어려움
• Apache Member 또는 Officer 라야 함
• 컨퍼런스나 Meetup 등에 참석해서 친해지는 것도 좋은
방법
• 아니면 메일로 작성된 Proposal 첨부하여 Sponsor 요청
• Mentor도 찾아야 함
• IPMC 멤버라야 함
• 아닌 경우 IPMC 멤버 추가 요청 해야 함
• Champion에 부탁하면 어느 정도 해결
• Initial Committer 선정
• 가능하면 여러 회사, 여러 국가의 개발자로 구성

34. Authorize Committers
• Committer는 Contributor License Agreement 를 작성해서
제출 해야 함
• Committer가 특성 회사 소속으로 활동하는 경우 Company도
제출해야 함
• ICLA(Individual Contributor License Agreement)
• Committer가 작성
• http://www.apache.org/licenses/icla.pdf
• CCLA(Coporate Contributor License Agreement)
• 회사가 작성
• https://www.apache.org/licenses/cla-corporate.txt
• ICLA 작성자의 메일이 회사메일인 경우 해당 회사는 작성해야 함
• 회사 대표자(?)가 sign 해야 하기 때문에 대기업에서는 다소
어려움
• 이 단계에서는 준비만 하면 됨

35. Discuss in IPMC
• Proposal이 준비되면 IPMC의 메일링 리스트에
Discuss 요청
• 주로 Champion이 요청
• https://www.mail-
archive.com/general@incubator.apache.org/msg56537.
html
• Discuss 메일 Thread에 나오는 사항 반영 후
메일링 리스트에 피드백

36. Proposal에 대한 투표
• Netbean 투표 요청 예
• https://www.mail-
archive.com/general@incubator.apache.org/msg56453.
html
• Apache의 기본 Voting Rule 적용
• http://www.apache.org/foundation/voting.html
• Incubator PMC member 만 유효표
• 투표에서 미 통과 시
• -1 사유에 대해 해결 후 다시 재투표 요청 가능

37. ASF Voting Rule
• 다음 세가지 종류의 투표가 있음
• 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 정책을 사용하는 프로젝트에는
적용이 안됨

38. 일반적으로 Voting은
• 메일링 리스트를 통해 진행
• Code modifications
• Committer 중 한명이 +1이 있고 -1이 없으면 통과
• Project Guide 페이지에 명시
• https://cwiki.apache.org/confluence/display/TAJO/How+to+C
ontribute+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

39. Voting이 통과되면
• Ensure Mentors are on the IPMC[Mentors]
• Add podling to reporting schedule [IPMC member]
• Initialize project status page [IPMC member]
• Start orientation [Prospective committers]
• Start CLA and CCLA submission [Prospective committers]
• Start IP Clearance [IPMC member]
• Request Required Resources
• Mailing Lists [Infrastructure Team]
• Consider and plan transition to official mailing lists
• Subversion [IPMC]
• Issue Tracking [Infrastructure Team]
• Consider and plan issue tracking transition
• Create website [Prospective committers]
• Consider and plan web site transition

40. Incubation 프로젝트 구성
• 필요 리소스는 Apache에서 제공
• Source code repository(subversion, git)
• 웹서버, JIRA, CI 서버 등
• http://www.apache.org/dev/ 참고
• 프로젝트 홈 페이지
• 도메인: http://<project_name>/incubator.apache.org
• 소스 레포지토리 이동
• 빠른 시간내에 프로젝트 패키지 변경
• org.apache.<project_name>
• Initial code 등록
• Issue Tracker 구성
• Apache에서 JIRA 제공(무지 느림)
• CI 등 구성

41. 개발 프로세스 예시(Tajo)
1. JIRA에 이슈 등록
• 모든 변경 사항은 반드시 이슈로 등록되어야 함
2. 담당자 할당
• 등록자 자신이 할당 하거나 Contributor는 Committer가 할당
• Contributor는 Issue에 댓글로 할당 요청
3. 담당자 개발 완료 후 PR 요청
4. 설정된 CI 구성에 의해 자동 Test 수행
• 테스트 결과 PR에 표시
5. Test 통과한 PR은 Committer에 의해 Code Review 진행
6. Code Review 사항 반영 후 Review 요청
• 4 ~ 5번 반복
7. Committer가 +1
• 다른 Committer가 -1을 줄 수 있음
8. Merge

42. Incubation 졸업을 위해서는?
• http://incubator.apache.org/guides/graduation.ht
ml
• Apache에서 Incubation 단계를 두는 이유는?
• 프로젝트 멤버들의 Apache의 룰에 대한 적응
• 최소한 한번 이상의 릴리즈가 필요
• 프로젝트 커뮤니티가 잘 운영되는지 검증
• 공개되어 있고, 다양성이 있는 커뮤니티를 구축해야 함
• 이 부분이 가장 어려운 분야임

43. 릴리즈 절차
• Top Level은 프로젝트 자체에서 결정하지만
• Incubation 프로젝트는 IPMC의 승인 필요
• 첫번째 릴리즈가 가장 어려다.
• Apache License 관련 준수 여부
• LICENSE.txt, 코드 내 라이센스 주석
• Dependency library의 license 준수 여부 등
• Project 내에서 Release VOTE
• 해당 프로젝트의 메일링 리스트 이용
• 72시간 동안 진행, +1 3개 이상, -1 없어야 함
• IPMC에 Release VOTE 요청
• IPMC 메일링 리스트에 요청
• Project 내 VOTE 결과 메일을 첨부
• https://www.mail-archive.com/general@incubator.apache.org/msg56592.html
• +3 얻기가 쉽지 않음
• 72 시간이 넘어도 +3이 없으면 Mentor에게 적극적으로 협조 메일 보내야 함

44. 커뮤니티 구축
• 투명하고 공정하게 운영하는 것이 가장 중요
• 특정 업체나 특정 멤버 중심으로 의사 결정이 주도되면 안됨
• PMC Chair는 결정권자가 아니라 발의자
• 커뮤니케이션은 가능한 공개된 채널 이용
• Mailing list, Issue Tracker, 공개된 IRC 채널 등
• Private한 의사 결정은 무효
• 특정 이슈에 관련된 개발자만 모여서 토론하더라도 결과는 이슈 트래커
등에 등록
• 꾸준한 활동이 중요
• 기존 Committer 들은 꾸준하게 Issue 등록 및 해결 필요
• 신규 개발자 유치를 위한 활동 필요
• 개발 가이드 및 newbie 를 위한 issue 생성 등
• 신규 개발자 접근 시 친철한 가이드 필요
• 마케팅도 중요
• 언론, Meet-up, Conference 등에서 꾸준한 활동 필요

45. Incubation 졸업 절차
• 위 조건이 만족되면 졸업 요청
• IPMC라는 시어머니에서 벗어남
• 기간은 정해진 것은 없지만 정해지 요건이 갖추어
지면 대략 6개월 이상되면 신청
• 프로젝트 내부 투표
• IPMC에 투표 요청
• Voting for Graduating Zeppelin
• https://www.mail-
archive.com/general@incubator.apache.org/msg54181.html
• Apache board meeting 에서 승인

46. Graduation Timeline

47. 드디어 Top Level
• Top Level 로 승인되면 도메인 변경에 따른 후속
작업 필요
• 홍보
• 언론, 블로그 등등
• Incubation 시절과 동일
• ASF의 프로세스와 룰을 준수해야 하며
• 공정하고, 투명하게 커뮤니티를 운영
• 프로젝트를 계속 발전 시켜야 함
• 다른 점은 주요 의사 결정(릴리즈 등)을 프로젝트
자체 내에서 결정할 수 있다는 것뿐.

48. 한국 오픈소스 개발자
• 제가 아시는 분들 위주로
• 한 프로젝트에는 대표로 한분만
• 김문수 님
• Apache Zeppelin PMC
• 류승우(Navis) 님
• Apache Hive PMC, Druid Committer
• 박철수 님
• Apache Pig PMC, Sqoop Committer, Spark Contributor
• 이희승(Trustin Lee) 님
• Netty, Apache Mina
• 최현식 님
• Apache Member, Tajo PMC Chair, Giraph Committer, IPMC
• http://people.apache.org/committers-by-project.html

49. 소프트웨어 개발에 대한 열정이 그대로 드러나는 곳이
오픈소스 프로젝트 입니다.
자소서의 몇 줄로는 자신의 열정을 모두 보이기
어려운 분들이라면
오픈소스 프로젝트에 도전해 보세요.

50. Q&A