충남대 학생들을 대상으로 오픈소스 프로젝트에 어떻게 기여할 수 있는지 저의 경험을 기반으로 talk을 했습니다.

1. Open source software 개발
어떻게 입문할까?
2016.9.19
최재원
jaewon.james.choi@gmail.com

2. 발표자
• 최재원
• 아주대학교 의료원 특임연구원
• 아주대학교 소프트웨어학과 4학년
• 관심분야: System software, Data engineering, High performance
computing

3. 강의 목표
• 어떻게 하면 OSS contribution 가까이라도 갈지(?) 제안한다.
• 또래 개발자로서 어떻게 OSS를 활용하고 있는지 경험을 공유한다.
• 더 좋은 OSS 개발자가 되기 위해 어떻게 하면 좋을지를 공유한다.

4. 목차
• OSS 개발자 되기
• 내 history : OSS를 중심으로
• OSS 개발자가 되기 위해 어떤 준비를 할 것인가?

5. OSS 개발자 되기

6. Open source software란?
• 소스코드가 공개 되어 있고, 그것을 이용하고, 수정하고, 재배포
할 수 있는 소프트웨어
• 우리 주변에도 굉장히 많다.
• Android, iOS의 일부, Linux, gcc, vim, node …
• 앞으로 OSS를 이용하지 않고 개발하기는 쉽지 않을 것
• Google, Facebook은 많은 형태의 프로젝트들을 오픈소스로 공개
• Build 2016에서의 Microsoft의 변화

7. (바람직한) OSS의 특징
• 적극적 공개
• 코드 뿐만 아니라 문서와 이슈의 공유
• 커뮤니티
• Mailing list, IRC, user group 등 기여자들이 소통하는 채널이 존재
• 생태계
• 하나의 오픈소스 프로젝트로 가치를 발휘하는 경우도 많지만
• OpenCV
• 다른 오픈소스 프로젝트들과 함께 생태계를 이루는 경우도 많음
• Hadoop eco system, npm, pip…

8. 이 talk에서의 OSS 개발자의 정의
• OSS를 이용할 수 있는 개발자
• OSS에 기여했거나, 기여할 마음이 있는 개발자
• OSS 프로젝트를 운영하는 개발자
• 셋 중에 하나를 만족한다면 OSS 개발자!

9. 우리는 왜 OSS 개발자가 되어야 하는가?
• 봉사정신
• 돈(?)과 명예
• 커리어
• 간지
• 학점
• 배울 것이 많다.
• Printf가 어떻게 구현되어 있는지 알 수 있다.

10. 어떻게 우리는 OSS 개발자가 될 수 있는가?
• OSS user 되기
• OSS contributor 되기
• OSS maintainer 되기

11. OSS user 되기
• OSS를 다운 받고, 설치하고, 실행해본다.
• Build가 은근히 어렵다.
• 자신의 프로젝트에 OSS를 가져다 써본다.
• 코드를 봐야 하는 상황이 발생한다면(자주 발생한다), 열심히
분석해본다.

12. OSS contributor(1)
• 기회(?)를 포착하면 가리지 않고 contribution을 하고, community에
들어간다.
• 좋은 user가 되면 contribution을 할 기회가 생긴다.
• 궁금한 점이 생기면 물어보자
• Mailing list, github issues, gitter
• 개선점을 찾으면 patch를 보내자.
• Mail, github pull request
• 잘 안받아 준다 ㅠㅠ
• 커뮤니티마다 있는 How to contribute or Contribution guide 등을
읽어보자.

13. OSS contributor(2)
• 사용하고 있는 software에 대한 documentation을 하자
• 번역
• 튜토리얼 코드 작성 / 번역
• 오타나 오역의 제보
• 내가 얻은 조언: 남들이 제일 하기 싫어하는 일을 하라.
• 테스트 코드를 작성해라.
• 여러 플랫폼으로 porting 해라.
• 내가 얻은 조언2: 신뢰를 얻어서 community에 들어가라.
• 검증이 되어야 mainline에 영향을 끼치는 개발자가 될 수 있다.

14. OSS maintainer(1)
• 쓸모있고 재밌는 OSS 프로젝트를 만들어서 배포한다.
• 최근에 본 멋진 프로젝트
• Algorithm visualizer(https://github.com/parkjs814/AlgorithmVisualizer)
• slack-invite-automation(https://github.com/outsideris/slack-invite-
automation)
• 생태계에 편입될 수 있는 프로젝트
• Apache zeppelin
• netty

15. OSS maintainer(2)
• 개발/연구의 결과
• Apache tajo
• Apache s2graph
• 없으니까 만들지 뭐
• Git
• 그냥 재미로
• Linux kernel

16. 내 history
OSS를 중심으로

17. 한국 애니메이션 고등학교
- 컴퓨터 게임 제작 전공
아주대학교
- 소프트웨어학 전공
- 수학 전공

18. Soulmate
Pentacube
게임 프로그래머, Co-founder
- C/C++, lua, cocos2d-x, Qt
클라이언트 프로그래머 인턴십
- C++, DirectX 11, WinSock2
소프트웨어 엔지니어 인턴
- C++, OpenGL 4, MFC
소프트웨어 엔지니어 인턴
- C#, OpenTK, OpenGL 3, WPF

19. Computer graphics
Collision detection
Stroke based rendering
File system
Distributed system
System software
Medical analytics platform
Server monitoring system
Java, python, node.js, Angular.js, MSSQL
Embedded system
HCI
Sensor network

20. Irrlicht: 나의 첫 Open source 사용기
• C++로 구현된 3D Game Rendering Engine.
• 게임 만드는 방법, Computer graphics와 OOP의 기초를 이 엔진에서
배움
• 추후 이 엔진을 따라해서 PDE라는 엔진을 만들었고, 그 엔진을
이용해 게임을 만들어 공모전에서 수상
• 얻은 것
• C++, OOP Design, Computer graphics
• 대학 합격장(Maybe?)

21. Cocos2d-x : 나의 첫 contribution
• 창업 후, cocos2d-x를 개조하고 지원 툴을 만들게 됨.
• Irrlicht와 비슷한 구조와 패턴이 있어 비교적 빠른 시간내에 코드
분석이 가능했음.
• 그 과정에서 별거 아닌 것을 발견하게 되는데…
• 다 Swap function 아시죠?

28. 교훈
• 아주 작은 contribution이라도 하려면 프로젝트 전체를 봐야 한다.
• 또한 그 프로젝트의 배경, 그 프로젝트에 쓰인 기술들을 빠삭하게
알아야 한다.
• 운도 있어야 한다

29. 교훈
• Cocos2d-x는 당시 빠르게 크는 중이었기 때문에 가능했던 것 같음.
• 사실 최근의 프로젝트들은 수학함수에 대한 unit testing 정도는
있기 때문에 이런 일은 잘 발생하지 않는다.
• C/C++, 그리고 시스템에 가까운 소프트웨어일 수록 이런 부분을
찾기가 힘들고, 찾았을 때의 효과는 굉장히 크다.
• Googler가 리눅스의 TCP에서 버그를 찾아 contribution 한 경우
• Google fixes nearly decade-old Linux kernel TCP bug
• https://news.ycombinator.com/item?id=10285151

30. 이것저것
• 먹고 살다보니 유저 입장에서 OSS를 쓸 일이 많았음.
• FUSE, linux kernel, Hadoop eco system, mdpnp, node.js, angular.js …
• 이젠 OSS를 찾아 쓰는게 어느정도 쉬워졌다.
• 어떤 부분을 contribution할지는 아직도 잘 모르겠다.
• 지금은 눈팅하면서 기회를 노리고 있다.

31. Jandy: 나의 본격적인 OSS maintaining
• https://github.com/jandy-team/jandy
• 고등학교 선배의 부름
• 같이 OSS 할래? ㅋ 많이 알려줄게
• 매주 일요일마다 project meetup
• Google hangouts 로 토론

32. 좋은 점
• 새로운 기술을 적용해 볼 수 있다.
• Scala, finatra, Radis…
• 도전적인 시도를 해볼 수 있다.
• Profiler, Graph database
• 보통 노가다를 하는 일이 많은데, 어려운 문제에 대해 생각해보게 됨.
• 성장한다.
• 주말에 마냥 놀지만은 않게 됨
• 다른 사람들에게 자극을 받고, 내 경험을 share하기도…

33. 어떤 준비를 할 것인가?

34. 어떤 준비가 필요할까?
• 좋은 개발자가 되어야 한다.
• 좋은 유저가 되어야 한다.
• 커뮤니티에 참여해야 한다.

35. 좋은 개발자
• 다들 생각은 다를지 몰라도 동의할 수 있는 세가지
• 기본
• 경험
• 스킬

36. 기본
• 좋은 CS background를 갖추자.
• 교수님이 시키는대로 공부 열심히 합시다.
• Algorithms, DB, Network, OS, Architecture, Compiler, Languages, Automata,
AI, Software engineering…
• 생각을 많이 하자.
• 개인적으론 친구들과 자주 하는 technical discussion이 도움이 많이 된다.
• 알고리즘 문제 풀기
• 논문 읽기

37. 경험
• 코딩을 많이 하자.
• 질은 학교에서 양은 혼자서
• 이것저것 공부해보자.
• Today I learned.
• 프로젝트를 시작해서 끝을 내보자.
• 회사 인턴십이 큰 도움이 된다.

38. 스킬
• 공부하기 위한 스킬
• 원서를 읽고 영어로 공부
• 1차 원문을 보는 습관: spec, paper, reference manual…
• 커뮤니티와 공부: stackoverflow(http://stackoverflow.com/users/22656/jon-
skeet)
• 도구를 다루는 기술
• VCS, Editor 등
• Protocol
• Mail 쓰는 법, discussion 할 때 서로 기분 안나쁘게 하는 법, 문서 쓰는 법…

39. 스킬
• 개발 방법론
• Agile (http://agile.egloos.com/)
• Insight 출판사의 좋은 책들.
• Clean code, 마법사 책 등
• 테스팅
• 생산성 향상용 소프트웨어
• Issue tracking system, VCS, CI에 대한 이해
• Slack, Trello, git, github, Travis CI…
• Cloud infrastructure
• AWS
• Microsoft azure

40. 좋은 유저
• 생활에서, 과제를 할 때, 숙제를 할 때 OSS를 써보자.
• 불편함을 느끼고, 그 불편함의 포인트를 나눠보자.
• OSS를 잘 쓰기 위해서 코드를 보자.
• OSS 코드를 처음 보면 이 언어가 내가 쓰던 언어가 맞나, 싶다.
• 사용자 그룹에 놀러가보자!
• 실제 오픈소스 커미터/컨트리뷰터를 만나보자.
• 관심 분야의 코드를 열심히 보자.

41. 커뮤니티(온/오프라인)
• 자신의 관심 분야를 검색해보면 나온다.
• 비단 OSS가 아니어도 커뮤니티는 큰 도움이 된다.
• 교육 프로그램
• 소프트웨어 마에스트로
• 삼성 소프트웨어 멤버십
• D2 Campus seminar
• 개발자 그룹
• 9x년생 개발자 모임
• 나는 프로그래머다 slack
• Onoffmix를 열심히 보자…

42. 커뮤니티(온/오프라인)
• 오픈소스 경진대회
• Google summer of code
• Naver D2 FEST
• 팟캐스트
• 나는 프로그래머다
• Software engineering dailiy
• Blog, github

43. 추천도서
• OSS 관련 문서는 온라인으로 많이 관리가 되고 있으니 읽어보길
바란다.
• Npm의 github 사용은 교과서로 불리기도 한다.
• https://github.com/npm/npm
• 개발 방법론
• 산드로 만쿠소 저, 권오인 역, “소프트웨어 장인”, 길벗
• 테스팅
• Kent Beck, “Test Driven Development By Example”, Addison-Wesley

44. 결론

45. Give and take
• OSS로부터 우린 뭘 얻고, 뭘 줄것인지 생각해보자.
• 현재는 얻는 것이 더 많은 단계. 열심히 얻어보자.
• 줘야 한다는 마인드를 갖고 살자.
• Article: Don’t develop closed code!
• 줘야 하는 순간에 귀찮아 하지 말고 최대한 주자.

46. Thanks!
• https://github.com/jafffy
• jaewon.james.choi@gmail.com

47. Q & A
• 어디서부터 contribution을 시작하면 좋을까요?
• 관심분야를 정하는 것이 제일 중요하다고 생각합니다. 자주 사용하는
소프트웨어도 좋구요.
• Tutorial을 쓰거나 번역하거나, 예제를 만들고 기존의 예제에 있는 문제를
제보하는 것도 좋습니다. 테스트 케이스를 써도 좋습니다.
• 모든 코드를 다 보겠다고 생각하지 않으셔도 됩니다. 리눅스 커널은
1400만줄입니다. 어짜피 다 못봅니다.