<p>[데브멘토 동영상] 허광남 모비젠 TI연구소 MA연구팀</p><p>공개SW와 오픈소스, 잘 나가는 오픈SW 제품의 성공요인</p><p>2010 공개SW 개발자대회 1차 기술세미나</p><p>주최: 지식경제부</p><p>주관: 정보통신산업진흥원, 한국공개SW협회</p>
<p>[데브멘토 동영상] 허광남 모비젠 TI연구소 MA연구팀</p><p>공개SW와 오픈소스, 잘 나가는 오픈SW 제품의 성공요인</p><p>2010 공개SW 개발자대회 1차 기술세미나</p><p>주최: 지식경제부</p><p>주관: 정보통신산업진흥원, 한국공개SW협회</p>
<p><font>공개SW 왜 도입을 안하는가, 불만은 무엇인가?</font></p><div><font>[데브멘토 동영상]</font><font>양재영 LG CNS 부장</font></div><div> </div><div><font>Free Software 개념은 1984년, Open Source Software 개념은 1998년 등장</font></div><div><font>정의: 소스코드를 공개한 상태로 실행프로그램을 제공하는 소프트웨어로 소스코드를 누구나 자유롭게 사용, 개작, 재배포할 수 있도록 허용한 소프트웨어</font></div><div><font>개발방법론</font></div>
빌드? 우선 사용부터 매뉴얼? Getting started 한 번 돌려보기 TV 리모컨 버튼 5개 전문가는 교육받아 만들어진다? 경험=시간+시행착오+성공실패 오픈소스 트러블슈팅 “메시지” 구글링 오픈소스 함부로 수정하지 마라 최신 버전을 대하는 우리의 자세 LTS로 대동단결 팀장 설득하기 오픈소스는 공짜가 아닙니다. 저도 기여하고 싶어요 2,000년 톰캣을 시작으로 Ant, Eclipse, JUnit, JMeter를 거쳐 현재 개발에 잘 사용하고 있는 Yona, Git, VSCode, Jenkins, CentOS, VirtualBox, Nginx, Node.js, Express.js, MariaDB, Uptime, Mocha, SonarQube, ZAP 이야기 등입니다.
https://www.youtube.com/watch?v=5LHOTBxG0hc
Chaos Engineering을 위한 최신 도구 업데이트 - 윤석찬 (AWS 테크에반젤리스트)Channy Yun
- 발표 영상: https://www.youtube.com/watch?v=mLWD4KCQuT4
카오스 엔지니어링(Chaos Engineering)을 테스트해 볼 수 있는 각종 도구에 대해 최신 업데이트를 해드립니다. 로컬 장애 주입용 도구 부터, AWS System Manager기반 Runcommand 도구, AWS Lambda 도구, 그리고 ToxiProxy, ChaosToolkit 같은 오픈 소스 기반 도구와 간단한 데모를 함께 보여드립니다.
<p><font>공개SW 왜 도입을 안하는가, 불만은 무엇인가?</font></p><div><font>[데브멘토 동영상]</font><font>양재영 LG CNS 부장</font></div><div> </div><div><font>Free Software 개념은 1984년, Open Source Software 개념은 1998년 등장</font></div><div><font>정의: 소스코드를 공개한 상태로 실행프로그램을 제공하는 소프트웨어로 소스코드를 누구나 자유롭게 사용, 개작, 재배포할 수 있도록 허용한 소프트웨어</font></div><div><font>개발방법론</font></div>
빌드? 우선 사용부터 매뉴얼? Getting started 한 번 돌려보기 TV 리모컨 버튼 5개 전문가는 교육받아 만들어진다? 경험=시간+시행착오+성공실패 오픈소스 트러블슈팅 “메시지” 구글링 오픈소스 함부로 수정하지 마라 최신 버전을 대하는 우리의 자세 LTS로 대동단결 팀장 설득하기 오픈소스는 공짜가 아닙니다. 저도 기여하고 싶어요 2,000년 톰캣을 시작으로 Ant, Eclipse, JUnit, JMeter를 거쳐 현재 개발에 잘 사용하고 있는 Yona, Git, VSCode, Jenkins, CentOS, VirtualBox, Nginx, Node.js, Express.js, MariaDB, Uptime, Mocha, SonarQube, ZAP 이야기 등입니다.
https://www.youtube.com/watch?v=5LHOTBxG0hc
Similar to 오픈소스 개발 방법론 - Mozilla 사례 중심 (2010) (20)
Chaos Engineering을 위한 최신 도구 업데이트 - 윤석찬 (AWS 테크에반젤리스트)Channy Yun
- 발표 영상: https://www.youtube.com/watch?v=mLWD4KCQuT4
카오스 엔지니어링(Chaos Engineering)을 테스트해 볼 수 있는 각종 도구에 대해 최신 업데이트를 해드립니다. 로컬 장애 주입용 도구 부터, AWS System Manager기반 Runcommand 도구, AWS Lambda 도구, 그리고 ToxiProxy, ChaosToolkit 같은 오픈 소스 기반 도구와 간단한 데모를 함께 보여드립니다.
How to Measure DevRel's Perfomances: From Community to Business - Channy Yun ...Channy Yun
Developer relations are an impactable to generate business values in many software companies who hope to gain mindshare of developers in various approaches from contributing open sources to gaining meaningful sales leads. In this session, you’ll learn about how to measure the perfomrmance of developer relations for building community, increasing impacts and generating leads for sales.
https://tokyo-2018.devrel.net/speakers/yun/
카오스 엔지니어링(Chaos Engineering)이란 프로덕션 서비스의 각종 장애 조건을 견딜 수 있는 시스템의 신뢰성을 확보하기 위해 분산 시스템을 실험 하고 배우는 분야입니다. 즉, 개발자들이 현실 세계에서 발견되는 시스템 장애를 미리 탐지하여 복원성 높은 아키텍처를 구성하는 방법을 공유합니다.클라우드 컴퓨팅의 발전과 데브옵스 방법론을 기반으로 자동화를 통해 좀 더 쉽게 개발자들이 직접 분산 시스템을 통제된 환경에서 실험을 하는 동안 나오는 결과를 관찰함으로써 현실에서 실제 행동 방법을 배울 수 있습니다. 본 세션에서는 카오스 엔지니어링의 기본 개념과 함께 Kubernetes용 Chaos Tool인 KubeMonkey를 통해 무작위로 클러스터의 포드를 삭제하여 장애 복구 서비스 아키텍처를 검증하는 방법을 설명합니다.
클라우드 컴퓨팅과 Daum의 사례- 윤석찬 (KREN 연구 협력 포럼, 2013) Channy Yun
출처: http://www.koren.or.kr/board/board.php?task=view&db=data2&no=44
<개발자에서>
최근에 클라우드 기술이 부각되면서 다음에서도 발빠르게 사내 프라이빗 클라우드 서비스를 준비중이다. 가장 먼저 한 일은 사내 개발자들이 언제든지 자신의 가상머신(VM)을 할당 받아 테스트해 볼 수 있는 사내 클라우드 플랫폼 구축이었다.
2011년 초 오픈소스인 클라우드스택을 최적화해 구축했으며, 개발자들은 공용 테스트 서버나 서비스 서버에서 못하던 자신만의 최신 기술 습득이나 테스트를 아무 구애 받지 않고 자기 서버에서 해 볼 수 있게 됐다. 이 플랫폼은 앞으로 클라우드 파운더리 기반의 사내 PaaS과 하둡 테스트베드로도 활용하고 있으며, 실제 다음 서비스에서 클라우드 컴퓨팅 기술을 활용하는 기초가 되고 있다.
- http://www.bloter.net/archives/107844
DockerCon 2014에서 Adrian Cockcroft가 발표한 The state of the art in Microservice 중 해외 사례 발췌본
https://blog.docker.com/2014/12/dockercon-europe-keynote-state-of-the-art-in-microservices-by-adrian-cockcroft-battery-ventures/
2005년 구글맵으로 부터 시작된 웹 기반 지도 API 서비스는 웹 2.0의 데이터 플랫폼 서비스의 주요 사례로 떠올랐다. 그 이후 야후!, 마이크로소프트 등에서 지도 플랫폼 서비스와 API 제공이 잇달았으며, 국내에서도 다음이 최초로 항공 사진(스카이뷰)과 거리 사진(로드뷰)을 제공하고 네이버도 참여함으로서 로컬 기반 서비스의 폭발적 성장의 견인차 역할을 하였다. 노키아의 Here 및 오픈스트릿맵 등 제 3의 사업자 및 협업 기반 플랫폼이 성장하였으며, Open Layer 라이브러리 및 Open GIS 등 다양한 공개 소프트웨어 들도 함께 성장하였다.
특히, 스마트폰의 보급과 아울러 모바일용 지도 SDK를 적극 보급 및 지원하는 추세로 기존의 Ajax 기반의 이미지 기반 웹 지도 표현 기술은 WebGL 혹은 Canvas를 통해 3차원 기술을 도입하면서 웹 호환성 및 성능을 동시에 높히고 있다. 구글 스케치업을 통해 시작된 공간 3차원 서비스는 약간 주춤하지만 45도 이미지너리 및 DEM 기반 데이터는 계속 추가되고 있다.
최근에는 구글맵 엔진 서비스와 같은 전문 사용자의 참여를 이끌어 내어 클라우드 소싱 형태의 지도 데이터 생성 커뮤니티를 통해 저개발 국가 및 북한과 같은 미공개 지도 데이터 생산을 만들고 있다.
2011년부터 구글 부터 지도 API 서비스 유료화를 단행하여 보안 강화 및 품질 및 성능 향상을 통해 제 3자 재판매를 통한 사업을 진행하고 있다. 또한, 최근 많은 기업들이 글로벌 홈페이지에 자사의 위치나 고객센터를 이용자들이 찾는데 활용하고 있으며, 이를 활용해 물류•관제•입지분석•위험관리•마케팅 등에 활용하고 있다.
현재 글로벌 지도 API 플랫폼은 단순히 베이스맵을 지원하는데 그치지 않고 공간 정보를 시각화 및 표현하는데 필요한 다양한 기능을 제공하면서, 정보 전달 역할을 강화하고 있다. 또한, Mapbox 등 지도 타일의 다양한 스타일과 테마 기능을 통해 좀 더 미려한 지도를 제공하기도 한다.
향후 글로벌 지도 API 플랫폼은 단보다 고도화된 시스템을 활용해 데이터 분석 및 2차원 시각화 그리고 3차원 공간 정보 활용으로 진화하고 있다.
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/