오픈소스 개발 방법론 - Mozilla 사례 중심 (2010)

7,766 views

Published on

Published in: Technology
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,766
On SlideShare
0
From Embeds
0
Number of Embeds
3,963
Actions
Shares
0
Downloads
15
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide

오픈소스 개발 방법론 - Mozilla 사례 중심 (2010)

  1. 1. 오픈 소스 개발 방법론- Mozilla 사례를 중심 으로 윤석찬 @channyun
  2. 2. About me 나의 경험 – 1998년 Mozilla 소스 코드 공개 시 시작 – 2002년에 본격 참여 (Mozilla 1.0) – Firefox 1.0 부터 제대로 된 Localization 시스템 구축. – 주요 작업 버전: • Mozilla 1.0~1.7 • Firefox 0.7~, Thunderbird 0.5~ 주요 활동 – Ko Module Owner & Release Manager (Service/Trademarks Review) – Korean community leader – Bug Report and follow-up for i18n – Mozilla Evangelism & International Communications
  3. 3. Philosophy motivation
  4. 4. What’s Open Source?
  5. 5. Free vs. Open Source Free Software Open Source S/W – Freedom of the code – Freedom of the – Source code will developer ALWAYS be – Code CAN be included available and can in proprietary works never be restricted. under certain conditions
  6. 6. It’s “impossible to avoid”.By 2011, 80% of allcommercial software willcontain open source code. Open source impossible to avoid, Gartner says”, Network World http://www.networkworld.com/news/2007/092007-open- source-unavoidable.html
  7. 7. Open Source Life Cycle Code – developing Community - building Communication - improving
  8. 8. Code
  9. 9. Release EarlyRelease Often
  10. 10. The Interesting Code? Narrow – 코드의 개발 범위가 한정적일 것 Easy Install – 개발자가 바로 이용 가능하도록 Open Standard – 일상화된 개발자 표준 이용 (코딩 컨벤션, API 표준) Composablity – 모듈화를 통한 참여 촉진
  11. 11. Robert Lefkowitz’s Exceptional Software Development try { … } catch { …70% … }
  12. 12. 1. Roadmap NEW – 사용자 및 기능 중심
  13. 13. 2. Development Tools 과거 Mozilla 개발 시스템 – Language: C++ (gcc, MSVC++ etc), Javascript – CVS (버전 관리 도구) – LXR (소스 코드 브라우저) – Bonsai (소스 코드 체크인 뷰어) – Tinderbox (프로그램 빌드 체크 도구) – Bugzilla (버그 리포팅 및 관리 도구)
  14. 14. 현재 Mozilla 개발 시스템– Mercurial (버전 관리 도구)– Buildbot (프로그램 빌드 관리 도구)– L10N Dashboard (로컬리제이션)– Bugzilla (버그 리포팅 및 관리 도구)
  15. 15. Mercurial http://hg.mozilla.org
  16. 16. http://buildbot.net Build Pool – 4 Build Masters – ~300 Slaves Try Build Pool – 1 Build Master – ~200 Slaves Test Pool – 7 Test Masters – ~400 Slaves• http://anamariamoz.wordpress.com/2010/11/08/mozillas-build-system/
  17. 17. L10n Dashboard
  18. 18. Joel Spolsky
  19. 19. Joel’s Test • Do you use source control? • Can you make a build in one step? • Do you make daily builds? • Do you have a bug database? • Do you fix bugs before writing new code? • Do you have an up-to-date schedule? • Do you have a spec? • Do programmers have quiet working conditions? • Do you use the best tools money can buy? • Do you have testers? • Do new candidates write code during their interview? • Do you do hallway usability testing?
  20. 20. 1. Source Control • Git • CVS • Bzr • SubVersion • Mercurial
  21. 21. Central vs. Distributed
  22. 22. 분산형 소스 콘트롤
  23. 23. Push & Merge
  24. 24. Github http://github.com Open Source Developer’s Social Networks
  25. 25. • No rules. Project belongs to you, not the site• Free for share, fork, change - do what you want.• Ruby on Rails, jQuery, nginx, CakePHP…• 주로 스크립트 언어 위주 빠른 개발…
  26. 26. GitHub 일반적 사용 방법GitHub에서 자유롭게 Fork한다.자신의 PC에 로컬 레포지터리를 만든다.원하는 기능을 만들고 테스트를 한다.자신의 레포지터리에 커밋 한다.변경 사항을 나의 Fork로 Push한다.원래 개발자에게 Pull 요청을 한다.Pull 하면 좋고 아니면 말고!
  27. 27. •Project management Code review, Pull request• Code hosting Online editing, annotation, IDE integration• Community Developer Karma system Social graph
  28. 28. 2. Tools Website or Wiki Portal Source Code Repository Repository Issue Tracker Bug Tracker Mailing List Mailing List
  29. 29. “Every successful open source project Iknow uses PRIM. Every closed sourceproject I know, doesnt. ... Peoplewonder how open source projectsmanage to create high-quality productswithout managers or accountability. Theanswer: were accountable to ourinfrastructure. PRIM is the open sourcesecret sauce.” - Ted Husted http://jroller.com/TedHusted/entry/prim
  30. 30. Forge Software 개발자들이 함께 개발 및 커뮤니케이션 할 수 있는 공간
  31. 31. How to choose? Hosting Install – SourceForge.net – SourceForge Enterprise Edition – Launchpad.net – GForge – BerliOS – FusionForge – Tigris.org – Trac – Google code – LibreSource – CodePlex – Codendi – ShareSource – OpenFoundry – nForge (NHN)
  32. 32. 상용 도구
  33. 33. 대세는…
  34. 34. Github http://github.com Open Source Developer’s Social Networks
  35. 35. 3. Bug tracking
  36. 36. 왜 버그 트래킹이 필요한가?제품의 문제점을 발견하고 해결하기 위한 과정 – 문제 발견/ 증상 규격화 / 원인 규명 / 재구현 / 문제 해결가장 적합한 커뮤니케이션 방식 부재 – e-mail: 모두 참여 어려움. 변경 과정을 추적하기 힘듦 – Phone, IM: 모두 참여 어려움. 금방 잊어 먹음 – Wiki: 공지나 변경 사항 알림 힘듦버그 처리를 위한 새로운 도구가 필요 – 버그에 대한 변경과정을 추적할 수 있어야 함
  37. 37. 출처: http://www.michaelflanakin.com/Articles/Comparisons/WebBasedIssueTrackers/tabid/198/Default.aspx
  38. 38. Bug process 어디가 틀렸는지 알겠군! 고쳐야지! 엇! 이문제군! 음 이건 내 코드인데!
  39. 39. Bug Triage
  40. 40. Peer Review
  41. 41. Issue tree
  42. 42. 4. Committing Source Code
  43. 43. Finding Bug 남들 잘 안 하는 것! – 의도적으로 남들이 안 하는 것 하기! 새로운 플랫폼, 컴파일러, 라이브러리 – 개발 버전, 의존성 이슈를 통해 버그 찾기 색다른 사용법 – 테스트 확장 등
  44. 44. Reproduction of Bug 버그 상황을 재현하는 최소한의 소스 – 어이없어도 됨! 소스는 짧고 테스트는 많으면 더욱 좋음! – 원래의 의도를 잘 드러낼 수 있어야 함 되도록 재현하는데 수고가 적게 들어야 함 – 셸 스크립트! 자동화가 가능하면 더욱 좋음 – 원래 프로그램이 사용하는 프레임워크로
  45. 45. Patch 패치의 종류 – 원래 프로그램에서 버그를 제대로 고치는 패치 – 임시 방편으로 필요한 문제만 해결하는 패치 – 많은 사람들이 임시로 사용할 수 있는 패치 패치의 전략 – 우선 돌아가게 만들자! – 가급적이면 테스트 자동화 먼저 – 마치 원래 있었던 소스인 것처럼
  46. 46. Patch process 매력 있는 패치? – 문제가 명확하고 재현이 쉬움 – 패치 첫인상 및 적용 방식 이 쉽고 부작용이 없어야 함. 패치 처리 과정 – 생성된 패치를 Attach를 통 해 추가. – 의사 결정 과정(Flags)을 거 쳐 패치 처리 여부 확인. – 커밋 시 반드시 버그 번호 와 의사 결정자 정보 추가.
  47. 47. Flags 주의: 아무나 플래그를 사용하면 안됨.플래그란? – 버그에 대한 중요 의사 결정 수행 – 의사 결정은 주로 상위 개발자나 프로젝트 리더들이 수행플래그의 종류 – Tree Blocking: 현재 버그가 특정 소스 트리에서 처리 해야하는 지 여부 (ex. blocking 1.1b) – Attach Blocking: 현재 첨부 (Patch)를 특정 소스 트리에서 수 정 코드로 사용하는 지 여부 (approval1.3b)플래그 사용 방법 – 의사 결정 요청: ? – 허용: + – 허용 안 함: -
  48. 48. Community
  49. 49. 1. Structure
  50. 50. 2. 커뮤니티 문화Open Communication – Online : Email, IRC, Bug Tracker etc. – Anyone can be joined and opened in public archives.Decision making – Lazy consensus from mailinglist without voting – For release, voting : +1 (Yes), 0(Abstrain), -1(Veto)Similarities, differences exist; examples: – Perl Foundation has no members. – Apache has no single leader. – Mozilla is driven by company based.
  51. 51. The Economic Motivation of Open Source Software: Stakeholder Perspectiveshttp://www.riehle.org/computer-science/research/2007/computer-2007-article.html
  52. 52. Step-by-Step Joining (local) open source community Beta Testing especially i18n and l10n Bug Reporting for good products Localization for ko locale Translation web site management Code review, writing and testing Submit your code patch CVS committer Be major role member (if be, you give up your general job!) 55
  53. 53. Linux 2.0.26 50% of the changes where made by 2.5% of the developers 50% of the changes were made by 97.5% of the developers Who Wrote 2.6.20? http://lwn.net/Articles/222773/ by corbet
  54. 54. Why Important? Code CommunitySuccess Factor Time
  55. 55. User CommunityOften separated from developer communityMajor Roles– Q&A and product support.– 3rd party module developers– LocalizationMinor Roles– Documentation, book authors, editors etc.– Teaching and self-appointed evangelists– professional usersBusiness Roles – Customer Supporter – Packagers – Code-based businesses
  56. 56. Communication
  57. 57. 커뮤니케이션 문화굉장히 개인적이고 이기적이기도 함 – 40% 이상이 자기 계발을 위해 참여메일 커뮤니케이션 – 여유를 갖자! 되도록 감사 – 내용의 형식보다 기술적 형식 중요! – 의무나 담당이라기보다는 해 주는게 좋은 것커뮤니티마다 고유의 문화적 특색 – 데비안의 철학 시험
  58. 58. Mozilla’s culture Open Organization – high agreement on core values – decision-making rests with module owners – groups will develop distinct ways of working – many decision-makers outside the “official” org – communication is central Open communication – Wiki/Blog – Mailinglist/IRC/Chat – Offline meetup
  59. 59. Wiki/Blog
  60. 60. Mail/IRC/Chat
  61. 61. Offline meetup
  62. 62. Leadership
  63. 63. Myths of Open Source OSP is opened! OSP is closed (hard to catch high level) OSP is difficult! OSP is easy (from bug report) OSP is inexpensive OSP is expensive (time and money) OSP is sharing OSP is non-sharing (self-development)
  64. 64. Licenses
  65. 65. Licenses : OSI 64+•Academic Free License •Microsoft Public License (Ms-PL)•Adaptive Public License •Microsoft Reciprocal License (Ms-RL)•Apache Software License •MIT license•Apache License, 2.0 •MITRE Collaborative Virtual Workspace License (CVW License)•Apple Public Source License •Motosoto License•Artistic license •Mozilla Public License 1.0 (MPL)•Artistic license 2.0 •Mozilla Public License 1.1 (MPL)•Attribution Assurance Licenses •NASA Open Source Agreement 1.3•New BSD license •Naumen Public License•Computer Associates Trusted Open Source License 1.1 •Nethack General Public License•Common Development and Distribution License •Nokia Open Source License•Common Public Attribution License 1.0 (CPAL) •OCLC Research Public License 2.0•Common Public License 1.0 •Open Group Test Suite License•CUA Office Public License Version 1.0 •Open Software License•EU DataGrid Software License •PHP License•Eclipse Public License •Python license (CNRI Python License)•Educational Community License, Version 2.0 •Python Software Foundation License•Eiffel Forum License •Qt Public License (QPL)•Eiffel Forum License V2.0 •RealNetworks Public Source License V1.0•Entessa Public License •Reciprocal Public License•Fair License •Ricoh Source Code Public License•Frameworx License •Sleepycat License•GNU General Public License (GPL) •Sun Industry Standards Source License (SISSL)•GNU General Public License version 3.0 (GPLv3) •Sun Public License•GNU Library or "Lesser" General Public License (LGPL) •Sybase Open Watcom Public License 1.0•GNU Library or "Lesser" General Public License version 3.0 (LGPLv3) •University of Illinois/NCSA Open Source License•Historical Permission Notice and Disclaimer •Vovida Software License v. 1.0•IBM Public License •W3C License•Intel Open Source License •wxWindows Library License•Jabber Open Source License •X.Net License•Lucent Public License (Plan9) •Zope Public License•Lucent Public License Version 1.02 •zlib/libpng license
  66. 66. License Types 신뢰 기반 – 파생물 재 라이센싱 가능 – 조건: 보증 없음. 저작자 표시 – Apache(AL), BSD, MIT 코드 기반 – 파일 혹은 파생물 기반 (소스코드와 바이너리에 차이 있음) – 재 라이센싱이 가능하나 원저작자에게 특수 권한 있음 – LGPL, Mozilla(MPL), Eclipse(EPL/CPL) 자유 기반 – 저작권 특허 모두 포기 및 공유 기반 – 파생물도 원래 라이센스에 기반 – GPL
  67. 67. License Scope BSD AL MPL LGPL GPL
  68. 68. 상용 소프트웨어와함께 소스 코드 이용상용 소프트웨어와 함께 바이너리 이용
  69. 69. 왜 중요한가?개발자는 라이센스가 뭔지 모른다.커뮤니티 공감대를 위해 라이센스에 대해인식해야 한다.소스코드의 종류와 커뮤니티의 성격에 따라 라이센스가 결정된다.라이센스에 따라 여러 가지 개발 문화가발전(퇴보)한다.
  70. 70. 참고. Daum 오픈 소스 지원 활동
  71. 71. 1
  72. 72. 2Source Control
  73. 73. Wiki/Bug Tracking
  74. 74. 3 사외 오픈 소스 지원공개 FTP 미러 서버– 사내 미러 서버 필요에 의해 시작개발자 커뮤니티 지원– 외부 개발자와 원활한 커뮤니케이션대학 교육– 오픈 소스 친화적 인재 양성
  75. 75. 오픈소스 공개 미러링 지원주요 오픈 소스 공식 미러 서비스 제공– OS: Red Hat Enterprise Linux AS release 4– Memory: 12GB– Storage: 4TB Raid Storage– Network: Gigabit Ethernet– http://ftp.daum.net
  76. 76. 커뮤니티 지원 및 교육오픈 소스 커뮤니티 서버 호스팅 – 국내 주요 OSS 커뮤니티 개발 서버 & 홈페이지 오픈 소스 모임 지원 – 장소 대여, 마케팅 물품 및 현금 지원 제주대학교 ‘오픈 소스 개발 방법론’ – 국내 최초 오픈 소스 대학 강좌 – 오픈 소스 개발 활동 직접 참여 및 실습 위주 – http://code.google.com/p/open-source-class/
  77. 77. Thanks for Attention : Q&A Seokchan (Channy) Yun channy@creation.net http://channy.creation.net http://twitter.com/channyun

×