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

윤 석 찬@channyun

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

Philosophymotivation

What’s Open Source?

Free vs. Open Source

Free Software– Freedom of the code

– Source code will ALWAYS be available and can never be restricted.

Open Source S/W– Freedom of the

developer

– Code CAN be included in proprietary works under certain conditions

It’s “impossible to avoid”. By 2011, 80% of all commercial software will contain open source code.

Open source impossible to avoid, Gartner says”, Network Worldhttp://www.networkworld.com/news/2007/092007-open-

source-unavoidable.html

Open Source Life Cycle

Code – developing

Community - building

Communication - improving

Code

Release Early Release Often

The Interesting Code?

Narrow – 코드의 개발 범위가 한정적일 것

Easy Install– 개발자가 바로 이용 가능하도록

Open Standard– 일상화된 개발자 표준 이용 (코딩 컨벤션, API 표준)

Composablity– 모듈화를 통한 참여 촉진

Robert Lefkowitz’s

Exceptional Software Development

try { … } catch { …70% … }

1. Roadmap

NEW – 사용자 및 기능 중심

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

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/

http://buildbot.net

L10n Dashboard

Joel Spolsky

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?

1. Source Control

• Git• Bzr• Mercurial

• CVS• SubVersion

Central vs. Distributed

분산형 소스 콘트롤

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 WikiSource Code RepositoryBug TrackerMailing List

PortalRepositoryIssue TrackerMailing List

“Every successful open source project I know uses PRIM. Every closed source project I know, doesn't. ... People wonder how open source projects manage to create high-quality products without managers or accountability. The answer: we're accountable to our infrastructure. PRIM is the open source secret sauce.”

- Ted Husted

http://jroller.com/TedHusted/entry/prim

Forge Software

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

How to choose?Hosting– SourceForge.net

– Launchpad.net– BerliOS

– Tigris.org

–Google code– CodePlex

– ShareSource

– OpenFoundry

Install– SourceForge Enterprise

Edition

– GForge

– FusionForge

– Trac– LibreSource

– Codendi

– nForge (NHN)

상용 도구

대세는…

Github http://github.com

Open Source Developer’s Social Networks

3. Bug tracking

왜 버그 트래킹이 필요한가?

제품의 문제점을 발견하고 해결하기 위한 과정– 문제 발견/ 증상 규격화 / 원인 규명 / 재구현 / 문제 해결

가장 적합한 커뮤니케이션 방식 부재– e-mail: 모두 참여 어려움. 변경 과정을 추적하기 힘듦

– Phone, IM: 모두 참여 어려움. 금방 잊어 먹음

– Wiki: 공지나 변경 사항 알림 힘듦

버그 처리를 위한 새로운 도구가 필요– 버그에 대한 변경과정을 추적할 수 있어야 함

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

Bug process

음 이건 내 코드인데!

어디가 틀렸는지알겠군! 고쳐야지!

엇! 이문제군!

Bug Triage

Peer Review

Issue tree

4. Committing Source Code

Finding Bug

남들 잘 안 하는 것!– 의도적으로 남들이 안 하는 것 하기!

새로운 플랫폼, 컴파일러, 라이브러리– 개발 버전, 의존성 이슈를 통해 버그 찾기

색다른 사용법– 테스트 확장 등

Reproduction of Bug

버그 상황을 재현하는 최소한의 소스

– 어이없어도 됨!

소스는 짧고 테스트는 많으면 더욱 좋음!

– 원래의 의도를 잘 드러낼 수 있어야 함

되도록 재현하는데 수고가 적게 들어야 함

– 셸 스크립트!

자동화가 가능하면 더욱 좋음

– 원래 프로그램이 사용하는 프레임워크로

Patch

패치의 종류– 원래 프로그램에서 버그를 제대로 고치는 패치

– 임시 방편으로 필요한 문제만 해결하는 패치

– 많은 사람들이 임시로 사용할 수 있는 패치

패치의 전략– 우선 돌아가게 만들자!

– 가급적이면 테스트 자동화 먼저

– 마치 원래 있었던 소스인 것처럼

Patch process매력 있는 패치?– 문제가 명확하고 재현이

쉬움– 패치 첫인상 및 적용 방식

이 쉽고 부작용이 없어야함.

패치 처리 과정– 생성된 패치를 Attach를 통

해 추가.– 의사 결정 과정(Flags)을 거

쳐 패치 처리 여부 확인. – 커밋 시 반드시 버그 번호

와 의사 결정자 정보 추가.

Flags플래그란?– 버그에 대한 중요 의사 결정 수행– 의사 결정은 주로 상위 개발자나

프로젝트 리더들이 수행

플래그의 종류– Tree Blocking: 현재 버그가 특정

소스 트리에서 처리 해야하는 지여부 (ex. blocking 1.1b)

– Attach Blocking: 현재 첨부(Patch)를 특정 소스 트리에서 수정 코드로 사용하는 지 여부(approval1.3b)

플래그 사용 방법– 의사 결정 요청: ?– 허용: +– 허용 안 함: -

주의: 아무나 플래그를 사용하면 안됨.

Community

1. Structure

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.

The Economic Motivation of Open Source Software: Stakeholder Perspectiveshttp://www.riehle.org/computer-science/research/2007/computer-2007-article.html

55

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

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

Why Important?

SuccessFactor

Time

Code Community

User CommunityOften 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

Communication

커뮤니케이션 문화

굉장히 개인적이고 이기적이기도 함– 40% 이상이 자기 계발을 위해 참여

메일 커뮤니케이션– 여유를 갖자! 되도록 감사

– 내용의 형식보다 기술적 형식 중요!

– 의무나 담당이라기보다는 해 주는게 좋은 것

커뮤니티마다 고유의 문화적 특색– 데비안의 철학 시험

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

Leadership

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 inexpensiveOSP is expensive (time and money)

OSP is sharingOSP is non-sharing (self-development)

Licenses

Licenses : OSI 64+•Academic Free License•Adaptive Public License•Apache Software License•Apache License, 2.0•Apple Public Source License•Artistic license•Artistic license 2.0•Attribution Assurance Licenses•New BSD license•Computer Associates Trusted Open Source License 1.1•Common Development and Distribution License•Common Public Attribution License 1.0 (CPAL)•Common Public License 1.0•CUA Office Public License Version 1.0•EU DataGrid Software License•Eclipse Public License•Educational Community License, Version 2.0•Eiffel Forum License•Eiffel Forum License V2.0•Entessa Public License•Fair License•Frameworx License•GNU General Public License (GPL)•GNU General Public License version 3.0 (GPLv3)•GNU Library or "Lesser" General Public License (LGPL)•GNU Library or "Lesser" General Public License version 3.0 (LGPLv3)•Historical Permission Notice and Disclaimer•IBM Public License

•Intel Open Source License•Jabber Open Source License•Lucent Public License (Plan9)•Lucent Public License Version 1.02

•Microsoft Public License (Ms-PL)•Microsoft Reciprocal License (Ms-RL)•MIT license•MITRE Collaborative Virtual Workspace License (CVW License)•Motosoto License•Mozilla Public License 1.0 (MPL)•Mozilla Public License 1.1 (MPL)•NASA Open Source Agreement 1.3•Naumen Public License•Nethack General Public License•Nokia Open Source License•OCLC Research Public License 2.0•Open Group Test Suite License•Open Software License•PHP License•Python license (CNRI Python License)•Python Software Foundation License•Qt Public License (QPL)•RealNetworks Public Source License V1.0•Reciprocal Public License•Ricoh Source Code Public License•Sleepycat License•Sun Industry Standards Source License (SISSL)•Sun Public License•Sybase Open Watcom Public License 1.0•University of Illinois/NCSA Open Source License•Vovida Software License v. 1.0•W3C License•wxWindows Library License•X.Net License•Zope Public License•zlib/libpng license

License Types

신뢰 기반– 파생물 재 라이센싱 가능– 조건: 보증 없음. 저작자 표시– Apache(AL), BSD, MIT

코드 기반– 파일 혹은 파생물 기반 (소스코드와 바이너리에 차이 있음)– 재 라이센싱이 가능하나 원저작자에게 특수 권한 있음– LGPL, Mozilla(MPL), Eclipse(EPL/CPL)

자유 기반– 저작권 특허 모두 포기 및 공유 기반– 파생물도 원래 라이센스에 기반– GPL

License Scope

AL GPLLGPLMPLBSD

상용 소프트웨어와

함께 소스 코드 이용

상용 소프트웨어와

함께 바이너리이용

왜 중요한가?

개발자는 라이센스가 뭔지 모른다.

커뮤니티 공감대를 위해 라이센스에 대해인식해야 한다.

소스코드의 종류와 커뮤니티의 성격에 따라 라이센스가 결정된다.

라이센스에 따라 여러 가지 개발 문화가발전(퇴보)한다.

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

1

2Source Control

Wiki/Bug Tracking

공개 FTP 미러 서버– 사내 미러 서버 필요에 의해 시작

개발자 커뮤니티 지원– 외부 개발자와 원활한 커뮤니케이션

대학 교육– 오픈 소스 친화적 인재 양성

사외 오픈 소스 지원3

오픈소스 공개 미러링 지원

주요 오픈 소스 공식 미러 서비스 제공– 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.nethttp://channy.creation.net

http://twitter.com/channyun