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

오픈 소스 개발 방법론- Mozilla 사례를 중심 으로 윤석찬 @channyun

About me 다음커뮤니케이션 – Open API 플랫폼 개발 및 서드 파티 개발자 지원 – 사외 기술 마케팅 및 오픈 소스 커뮤니티 지원 • http://dna.daum.net 웹 표준 커뮤니티 – Web Standards Project ILG – W3C HTML W/G Invited Expert – 한국 웹 표준 프로젝트 리더 • http://webstandards.or.kr 오픈 소스 – Mozilla Korean Community http://www.mozilla.or.kr 블로그 – Channy’s Blog http://channy.creation.net – KoreaCrunch http://koreacrunch.com Contact – channy@gmail.com – http://twitter.com/channyun – http://facebook.com/channyun

My Role 나의 경험 – 1998년 Mozilla 소스 코드 공개 시 시작 – 2002년에 본격 참여 (Mozilla 1.0) – Firefox 1.0 부터 제대로 된 Localization 시스템 구축. – 주요 작업 버전: Mozilla 1.0~1.7, Firefox 0.7~8.0, Thunderbird 0.5~8.0 주요 활동 – Ko Module Owner & Release Manager (Service/Trademarks Review) – Korean community leader – Bug Report and follow-up for i18n – Mozilla Evangelism & International Communications

What’s Open Source?

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

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

Now main stream!Major companies – IBM Sun Intel Apple HP Dell – Novell Oracle Motorola Nokia – Apple Google Yahoo NHN DaumMicrosoft

Open Source Life Cycle Code - development Community - building Communication - improving

Release EarlyRelease Often

The Interesting Code? Narrow – 코드의 개발 범위가 한정적일 것 Easy Install – 개발자가 바로 이용 가능하도록 Open Standard – 일상화된 개발자 표준 이용 (코딩 컨벤션, API 표준) Composablity – 모듈화를 통한 참여 촉진

Robert Lefkowitz’s Exceptional Software Development try { … } catch { …70% … }

Developing Management

1. Roadmap OLD - 레포지터리 및 안정성 중심 17

NEW – 사용자 및 기능 중심

Problem? 3rd Party – Add-ons and localizations

2. Development Tools 과거 Mozilla 개발 시스템 – Language: C++ (gcc, MSVC++ etc), Javascript – CVS (버전 관리 도구) – LXR (소스 코드 브라우저) – Bonsai (소스 코드 체크인 뷰어) – Tinderbox (프로그램 빌드 체크 도구) – Bugzilla (버그 리포팅 및 관리 도구)

현재 Mozilla 개발 시스템– Mercurial (버전 관리 도구)– Buildbot (프로그램 빌드 관리 도구)– L10N Dashboard (로컬리제이션)– Bugzilla (버그 리포팅 및 관리 도구)

Mercurial http://hg.mozilla.org

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/

L10n Dashboard

Development in Action

1. Source Control • Git • CVS • Bzr • SubVersion • Mercurial

Central vs. Distributed

분산형 소스 콘트롤

Mercurial http://hg.mozilla.org

Push & Merge

Github http://github.com Open Source Developer’s Social Networks

• No rules. Project belongs to you, not the site• Free for share, fork, change - do what you want.• Ruby on Rails, jQuery, nginx, CakePHP…• 주로 스크립트 언어 위주 빠른 개발…

GitHub 일반적 사용 방법GitHub에서 자유롭게 Fork한다.자신의 PC에 로컬 레포지터리를 만든다.원하는 기능을 만들고 테스트를 한다.자신의 레포지터리에 커밋 한다.변경 사항을 나의 Fork로 Push한다.원래 개발자에게 Pull 요청을 한다.Pull 하면 좋고 아니면 말고!

•Project management Code review, Pull request• Code hosting Online editing, annotation, IDE integration• Community Developer Karma system Social graph

2. Tools Website or Wiki Portal Source Code Repository Repository Issue Tracker Bug Tracker Mailing List Mailing List

“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

Forge Software 개발자들이 함께 개발 및 커뮤니케이션 할 수 있는 공간

How to choose? Hosting Install – SourceForge.net – SourceForge Enterprise – Launchpad.net Edition – BerliOS – GForge – GNU Savannah – FusionForge – Gna.org – Savane – Project Kenai – Trac – Tigris.org – LibreSource – Google code – Codendi – CodePlex – InDefero – ShareSource – nForge (NHN) – OpenFoundry

e.g. SourceForge.net

Launchpad.net

Google Code

Etc…

3. Bug tracking 출처: http://www.michaelflanakin.com/Articles/Comparisons/WebBasedIssueTrackers/tabid/198/Default.aspx

왜 버그 트래킹이 필요한가?제품의 문제점을 발견하고 해결하기 위한 과정 – 문제 발견/ 증상 규격화 / 원인 규명 / 재구현 / 문제 해결가장 적합한 커뮤니케이션 방식 부재 – e-mail: 모두 참여 어려움. 변경 과정을 추적하기 힘듦 – Phone, IM: 모두 참여 어려움. 금방 잊어 먹음 – Wiki: 공지나 변경 사항 알림 힘듦버그 처리를 위한 새로운 도구가 필요 – 버그에 대한 변경과정을 추적할 수 있어야 함

Bug peocess 어디가 틀렸는지 알겠군! 고쳐야지! 엇! 이문제군! 음 이건 내 코드인데!

Reproduction of Bug 버그 상황을 재현하는 최소한의 소스 – 어이없어도 됨! 소스는 짧고 테스트는 많으면 더욱 좋음! – 원래의 의도를 잘 드러낼 수 있어야 함 되도록 재현하는데 수고가 적게 들어야 함 – 셸 스크립트! 자동화가 가능하면 더욱 좋음 – 원래 프로그램이 사용하는 프레임워크로

Bugzilla’s process

Bug Triage!

Peer Review

Issue tree

4. Patch process 매력 있는 패치? – 문제가 명확하고 재현 이 쉬움 – 패치 첫인상 및 적용 방식이 쉽고 부작용이 없어야 함. 패치 처리 과정 – 생성된 패치를 Attach 를 통해 추가. – 의사 결정 과정(Flags) 을 거쳐 패치 처리 여 부 확인. – 커밋 시 반드시 버그 번호와 의사 결정자 정 보 추가.

플래그(Flags) 주의: 아무나 플래그를 사용하면 안됨.플래그란? – 버그에 대한 중요 의사 결정 수행 – 의사 결정은 주로 상위 개발자나 프로젝트 리더들이 수행플래그의 종류 – Tree Blocking: 현재 버그가 특정 소스 트리에서 처리 해야하는 지 여부 (ex. blocking 1.1b) – Attach Blocking: 현재 첨부 (Patch)를 특정 소스 트리에서 수 정 코드로 사용하는 지 여부 (approval1.3b)플래그 사용 방법 – 의사 결정 요청: ? – 허용: + – 허용 안 함: -

Community

1. Structure

2. Culture 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.

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!) 61

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

Communication

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

Wiki/Blog

Mail/IRC/Chat

Offline meetup

3. Leadership

Why Important? Code CommunitySuccess Factor Time

User Community Often separated from developer community Major Roles – Q&A and product support. – 3rd party module developers – Localization Minor Roles – Documentation, book authors, editors etc. – Teaching and self-appointed evangelists – professional users Business Roles – Customer Supporter – Packagers – Code-based businesses

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)

참고. Daum 오픈 소스 지원 활동

2Source Control

Wiki/Bug Tracking

3 사외 오픈 소스 지원공개 FTP 미러 서버– 사내 미러 서버 필요에 의해 시작개발자 커뮤니티 지원– 외부 개발자와 원활한 커뮤니케이션대학 교육– 오픈 소스 친화적 인재 양성

오픈소스 공개 미러링 지원주요 오픈 소스 공식 미러 서비스 제공– OS: Red Hat Enterprise Linux AS release 4– Memory: 12GB– Storage: 4TB Raid Storage– Network: Gigabit Ethernet– http://ftp.daum.net

커뮤니티 지원 및 교육오픈 소스 커뮤니티 서버 호스팅 – 국내 주요 OSS 커뮤니티 개발 서버 & 홈페이지 오픈 소스 모임 지원 – 장소 대여, 마케팅 물품 및 현금 지원 제주대학교 ‘오픈 소스 개발 방법론’ – 국내 최초 오픈 소스 대학 강좌 – 오픈 소스 개발 활동 직접 참여 및 실습 위주 – http://code.google.com/p/open-source-class/

Thanks for Attention : Q&A Seokchan (Channy) Yun channy@creation.net http://channy.creation.net http://twitter.com/channyun

http://channy.creation.net	761
url_unknown	5
http://blog.naver.com	1

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

by Channy Yun on Jun 27, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 767

Statistics

오픈소스 개발 방법론 - Mozilla 사례 중심 — Presentation Transcript