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
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. 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 World
http://www.networkworld.com/news/2007/092007-open-
source-unavoidable.html
7.
8. Open Source Life Cycle
Code – developing
Community - building
Communication - improving
11. The Interesting Code?
Narrow
– 코드의 개발 범위가 한정적일 것
Easy Install
– 개발자가 바로 이용 가능하도록
Open Standard
– 일상화된 개발자 표준 이용 (코딩 컨벤션, API 표준)
Composablity
– 모듈화를 통한 참여 촉진
12.
13. Robert Lefkowitz’s
Exceptional Software Development
try { … }
catch { …70% … }
15. 2. Development Tools
과거 Mozilla 개발 시스템
– Language: C++ (gcc, MSVC++ etc), Javascript
– CVS (버전 관리 도구)
– LXR (소스 코드 브라우저)
– Bonsai (소스 코드 체크인 뷰어)
– Tinderbox (프로그램 빌드 체크 도구)
– Bugzilla (버그 리포팅 및 관리 도구)
16. 현재 Mozilla 개발 시스템
– Mercurial (버전 관리 도구)
– Buildbot (프로그램 빌드 관리 도구)
– L10N Dashboard (로컬리제이션)
– Bugzilla (버그 리포팅 및 관리 도구)
21. 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?
26. Github http://github.com
Open Source Developer’s Social Networks
27. • No rules. Project belongs to you, not the site
• Free for share, fork, change - do what you want.
• Ruby on Rails, jQuery, nginx, CakePHP…
• 주로 스크립트 언어 위주 빠른 개발…
28. GitHub 일반적 사용 방법
GitHub에서 자유롭게 Fork한다.
자신의 PC에 로컬 레포지터리를 만든다.
원하는 기능을 만들고 테스트를 한다.
자신의 레포지터리에 커밋 한다.
변경 사항을 나의 Fork로 Push한다.
원래 개발자에게 Pull 요청을 한다.
Pull 하면 좋고 아니면 말고!
29. •Project management
Code review, Pull request
• Code hosting
Online editing, annotation, IDE integration
• Community
Developer Karma system
Social graph
30. 2. Tools
Website or Wiki Portal
Source Code Repository
Repository Issue Tracker
Bug Tracker Mailing List
Mailing List
31. “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
38. 왜 버그 트래킹이 필요한가?
제품의 문제점을 발견하고 해결하기 위한 과정
– 문제 발견/ 증상 규격화 / 원인 규명 / 재구현 / 문제 해결
가장 적합한 커뮤니케이션 방식 부재
– e-mail: 모두 참여 어려움. 변경 과정을 추적하기 힘듦
– Phone, IM: 모두 참여 어려움. 금방 잊어 먹음
– Wiki: 공지나 변경 사항 알림 힘듦
버그 처리를 위한 새로운 도구가 필요
– 버그에 대한 변경과정을 추적할 수 있어야 함
45. Finding Bug
남들 잘 안 하는 것!
– 의도적으로 남들이 안 하는 것 하기!
새로운 플랫폼, 컴파일러, 라이브러리
– 개발 버전, 의존성 이슈를 통해 버그 찾기
색다른 사용법
– 테스트 확장 등
46. Reproduction of Bug
버그 상황을 재현하는 최소한의 소스
– 어이없어도 됨!
소스는 짧고 테스트는 많으면 더욱 좋음!
– 원래의 의도를 잘 드러낼 수 있어야 함
되도록 재현하는데 수고가 적게 들어야 함
– 셸 스크립트!
자동화가 가능하면 더욱 좋음
– 원래 프로그램이 사용하는 프레임워크로
47. Patch
패치의 종류
– 원래 프로그램에서 버그를 제대로 고치는 패치
– 임시 방편으로 필요한 문제만 해결하는 패치
– 많은 사람들이 임시로 사용할 수 있는 패치
패치의 전략
– 우선 돌아가게 만들자!
– 가급적이면 테스트 자동화 먼저
– 마치 원래 있었던 소스인 것처럼
48. Patch process
매력 있는 패치?
– 문제가 명확하고 재현이
쉬움
– 패치 첫인상 및 적용 방식
이 쉽고 부작용이 없어야
함.
패치 처리 과정
– 생성된 패치를 Attach를 통
해 추가.
– 의사 결정 과정(Flags)을 거
쳐 패치 처리 여부 확인.
– 커밋 시 반드시 버그 번호
와 의사 결정자 정보 추가.
49. Flags 주의: 아무나 플래그를 사용하면 안됨.
플래그란?
– 버그에 대한 중요 의사 결정 수행
– 의사 결정은 주로 상위 개발자나
프로젝트 리더들이 수행
플래그의 종류
– Tree Blocking: 현재 버그가 특정
소스 트리에서 처리 해야하는 지
여부 (ex. blocking 1.1b)
– Attach Blocking: 현재 첨부
(Patch)를 특정 소스 트리에서 수
정 코드로 사용하는 지 여부
(approval1.3b)
플래그 사용 방법
– 의사 결정 요청: ?
– 허용: +
– 허용 안 함: -
53. 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.
54. The Economic Motivation of Open Source Software: Stakeholder Perspectives
http://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!)
55
56. 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
58. 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
60. 커뮤니케이션 문화
굉장히 개인적이고 이기적이기도 함
– 40% 이상이 자기 계발을 위해 참여
메일 커뮤니케이션
– 여유를 갖자! 되도록 감사
– 내용의 형식보다 기술적 형식 중요!
– 의무나 담당이라기보다는 해 주는게 좋은 것
커뮤니티마다 고유의 문화적 특색
– 데비안의 철학 시험
61. 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
66. 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)
68. 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
69. License Types
신뢰 기반
– 파생물 재 라이센싱 가능
– 조건: 보증 없음. 저작자 표시
– Apache(AL), BSD, MIT
코드 기반
– 파일 혹은 파생물 기반 (소스코드와 바이너리에 차이 있음)
– 재 라이센싱이 가능하나 원저작자에게 특수 권한 있음
– LGPL, Mozilla(MPL), Eclipse(EPL/CPL)
자유 기반
– 저작권 특허 모두 포기 및 공유 기반
– 파생물도 원래 라이센스에 기반
– GPL
77. 3 사외 오픈 소스 지원
공개 FTP 미러 서버
– 사내 미러 서버 필요에 의해 시작
개발자 커뮤니티 지원
– 외부 개발자와 원활한 커뮤니케이션
대학 교육
– 오픈 소스 친화적 인재 양성
78. 오픈소스 공개 미러링 지원
주요 오픈 소스 공식 미러 서비스 제공
– OS: Red Hat Enterprise Linux AS release 4
– Memory: 12GB
– Storage: 4TB Raid Storage
– Network: Gigabit Ethernet
– http://ftp.daum.net
79. 커뮤니티 지원 및 교육
오픈 소스 커뮤니티 서버 호스팅
– 국내 주요 OSS 커뮤니티 개발 서버 & 홈페이지
오픈 소스 모임 지원
– 장소 대여, 마케팅 물품 및 현금 지원
제주대학교 ‘오픈 소스 개발 방법론’
– 국내 최초 오픈 소스 대학 강좌
– 오픈 소스 개발 활동 직접 참여 및 실습 위주
– http://code.google.com/p/open-source-class/
