L13L14-Open source software development (Ch07)

Open source development (오픈소스 개발)

1. 의미

: an approach to software development in which the source code of a software system is published and volunteers are invited to participate in the development process 
(소프트웨어 시스템의 소스코드가 공개되고, 개발 과정에 자원봉사자가 참여하도록 초대되는 소프트웨어 개발 방식)

 

2. 조건

• Its roots are in the Free Software Foundation (www.fsf.org)
  (오픈 소스 개발의 시작은 자유 소프트웨어 재단에서 비롯되었다.)
• source code should not be proprietary but rather should always be available for users to examine and modify as they wish. 
  (소스코드가 독점적이어서는 안 되고, 사용자들이 자유롭게 소스를 검토하고, 수정할 수 있어야 한다)

3. 특징

• Open source software extended this idea by using the Internet to recruit a much larger population of volunteer developers. 
  (인터넷을 통해 훨씬 더 많은 자원 봉사 개발자를 모집할 수 있도록, 이 아이디어를 확장시켰다.)
• Many of them are also users of the code. 
  (그들 중 많은 사람들이 코드의 사용자이기도 하다)

 

Open source system (오픈 소스 시스템)

1. 가장 잘 알려진 오픈 소스 제품

: the Linux operating system (리눅스 운영체제)

• It is widely used as a server system and, increasingly, as a desktop environment. (리눅스는 서버 시스템으로 널리 사용되며, 점차 데스크탑 환경으로도 확산되고 있다.)

2. 그 외 중요한 오픈 소스 제품

• Java, the Apache web server and the mySQL database management system. (자바, 아파치 웹 서버, MySQL 데이터베이스 관리 시스템)

 

오픈 소스의 이슈

• Should the product that is being developed make use of open source components? (개발 중인 제품이 오픈 소스 컴포넌트를 사용해야 하는가?)
• Should an open source approach be used for the software’s development? (소프트웨어 개발에 오픈 소스 접근 방식을 사용해야 하는가?)

 

오픈 소스 비즈니스 (Open source business)

• More and more product companies are using an open source approach to development.
  (점점 더 많은 제품 회사들이 오픈 소스 접근 방식을 개발에 사용하고 있다.)
• Their business model is not reliant on selling a software product but on selling support for that product. 
  (이들의 비즈니스 모델 : 소프트웨어 제품을 판매하는 것에 의존하지 않고, 그 제품에 대한 지원을 판매하는 것)
• They believe that involving the open source community will allow software to be developed more cheaply, more quickly and will create a community of users for the software.
  (그들은 오픈 소스 커뮤니티에 참여함으로써 소프트웨어를 더 저렴하고, 더 빠르게 개발할 수 있으며, 소프트웨어에 대한 사용자 커뮤니티를 만들 수 있다고 믿는다.)
• Open-source tool/platform services (e.g., github, Jira, ...)

 

오픈 소스 라이센스

1. 오픈소스 개발의 기본 원칙

: source code should be freely available (소스 코드가 자유롭게 제공되어야 한다)

• but this does not mean that anyone can do as they wish with that code (그러나, 누구나 그 코드르 마음대로 사용할 수 있다는 뜻은 아니다.)

2. 특징

• Legally, the developer of the code (either a company or an individual) still owns the code. 
  (법적으로 코드의 개발자는 여전히 그 코드를 소유한다.)
  
  • They can place restrictions on how it is used by including legally binding conditions in an open source software license.
    (개발자는 오픈 소스 소프트웨어 라이센스에 법적으로 구속력 있는 조건을 포함시켜 코드의 사용에 제한을 둘 수 있다.)
• Some open source developers believe that if an open source component is used to develop a new system, then that system should also be open source.
  (일부 오픈 소스 개발자들은 오픈 소스 컴포넌트를 사용하여 새로운 시스템을 개발했다면, 그 시스템도 오픈소스여야 한다고 믿는다.)
• Others are willing to allow their code to be used without this restriction. 
  (다른 사람들은 그들의 코드를 제한 없이 사용하도록 허용한다.)
  • The developed systems may be proprietary and sold as closed source systems.
    (개발된 시스템은 독점적일 수 있으며, 닫힌 소스 시스템으로 판매될 수 있다.)

 

라이센스 모델

1. 종류1 : The GNU General Public License (GPL) - GNU 일반 공용 라이센스

• This is a so-called ‘reciprocal’ license ('상호적인' 라이센스)
• If you use open source software that is licensed under the GPL license, then you must make that software open source.
  GPL 라이센스 하에 오픈 소스 소프트웨어를 사용하면, 그 소프트웨어도 오픈 소스로 만들어야 한다.

2. 종류2 : The GNU Lesser General Public License (LGPL) - GNU 약한 일반 공용 라이센스

• A variant of the GPL license
  GPL 라이센스의 변형
• where you can write components that link to open source code without having to publish the source of these components.
  오픈 소스 코드를 연결하는 컴포넌트를 작성하되, 이들 컴포넌트의 소스를 공개할 필요는 없다. 

3. 종류3 : The Berkeley Standard Distribution (BSD) License - 버클리 표준 배포 (BSD) 라이센스

• A non-reciprocal license (비상호적인 라이센스)
• you are not obliged to re-publish any changes or modifications made to open source code.
  오픈 소스 코드에 대해 변경하거나, 수정한 사항을 다시 공개할 의무가 없다.
• You can include the code in proprietary systems that are sold.
  이 코드를 독점적인 시스템에 포함시켜 판매할 수 있다. 

 

 

 

[2] What licence should I choose? (어떤 라이센스를 선택해야 할까?)

우리 회사의 라이센스 관리

• Establish a system for maintaining information about open-source components that are downloaded and used.
  (다운로드하고 사용중인 오픈 소스 컴포넌트에 대한 정보를 관리하는 시스템을 구축한다.)
  • 즉, 우리가 어디서 어떤 오픈 소스를 가져와서 쓰고 있는지 정리하고 기록해두는 시스템을 만들어야 한다.
• Be aware of the different types of licenses and understand how a component is licensed before it is used.
  (다양한 라이센스 유형에 대해 인식하고, 컴퓨넌트가 사용되기 전에 그것이 어떤 라이센스로 라이센스가 지정되었는지 확인한다.)
  • 즉, 오픈 소스마다 사용 조건이 달르기에, 오픈 소스를 사용하기 전에, 그 라이센스를 꼭 확인해야 한다.
• Be aware of evolution pathways for components.
  (컴포넌트의 진화 경로에 대해 인식한다.)
  • 즉, 이 컴포넌트가 앞으로 없어질 수도, 새로운 버전이 나올 수도 있기에, 앞으로의 발전을 알고 있어야 한다. 
• Educate people about open source.
  (사람들에게 오픈 소스에 대해 교육한다.)
  • 즉, 오픈 소스를 올바르게 사용하고 관리할 수 있도록 팀원들이나 개발자들에게 관련 지식을 알려줘야 한다.
• Have auditing systems in place.
  (감사 시스템을 구축한다.)
  • 즉, 혹시라도 라이센스 위반이나 문제가 생긴 오픈 소스를 썼는지 정기적으로 검사할 수 있는 시스템이 필요하다.
• Participate in the open source community.
  (오픈 소스 커뮤니티에 참여한다.)
  • 즉, 단순히 오픈 소스를 쓰기만 하지 말고, 기여도 하자는 의미이다.

 

Apache Software Foundation (ASF) 
(아파치 소프트웨어 재단)

1. 특징

• 가장 큰 오픈소스 커뮤니티 중 하나
• 1999년에 설립된 미국의 501(c)3 비영리 공공 자선단체

2. 역할

• User - 사용자
• Developer - 개발자
• Committer - 커미터
• PMC member - PMC 구성원 (프로젝트 관리 위원회 구성원, 개발자 또는 커미터)
• PMC chair - PMC 의장
• ASF member - ASF 회원

3. 프로젝트 인큐베이션

• 새로운 오픈소스 프로젝트가 아파치의 정식 프로젝트가 되기 전 거치는 준비 단계이다.
• 아파치의 정책, 라이선스, 커뮤니티 운영 방식을 익히고, 멘토의 도움을 받으며 성장하는 과정이다.

 

How to contribute OOS projects? (오픈 소스 프로젝트에 어떻게 기여할까?)

• Mostly changes (Patches)
  코드를 직접 수정해서, 프로젝트 기능을 개선하거나 버그를 고치는 것
• Documents
  프로젝트 설명서나 사용법 문서를 작성하거나 개선하는 것
• Reporting issues/bugs
  문제가 생기면 이슈로 남겨서 개발자가 알 수 있도록 도와주는 것
• Testing/validation
  새로운 기능이나, 수정된 코드가 잘 작동하는지 확인하여 테스트를 도와주는 것

Typical open source development model (전형적인 오픈 소스 개발 모델)

전체 흐름 요약
: 아이디어 제안 -> 설계 논의 -> 구현 -> 테스트 -> 배포 -> 유지보수

 

1. 전체 단계

1) Project or Feature ideas (프로젝트 또는 기능 아이디어 제안)

2) Feature Request (기능 요청)

3) Architecure and design disucssion (아키텍처 및 설계 논의)

4) Implementation (구현)

5) Patches (패치 제출)

6) Continuous Testing and Intergration (지속적인 테스트 및 통합)

7) Test projects to automate testing and validation (자동화 테스트 프로젝트)

8) Deployment / Release (배포 / 출시)

9) Maintenance (유지보수)

 

Understanding GitHub/Jira under the OSS model (OSS 모델 하의 Github / Jira 이해하기)

1. 예시 : Lucence 프로젝트

1) Feature request / issue tracking - 기능 요청 / 문제 추적

2) Implemenation (including builds/javadocs/test) - 구현 (빌드 / Javadocs / 테스트 포함)

3) 릴리스

 

Issue tracking model (문제 추적 모델)

1. 별칭 : 티켓 시스템

 

2. 예시 : Bugzilla 3.0의 버그 생명 주기 (Bug Lifecycle)를 설명하는 문제 추적 모델 

1) 🟧 UNCONFIRMENT (미확인됨)

• 버그가 처음 보고된 상태, 따라서 아직 진짜 버그인지 확인되지 않은 상태
• 이동 조건 : 버그가 검증되거나, 투표를 많이 받으면 NEW 상태로 이동

2) 🔴 NEW (새로 등록됨)

• 버그가 확인되었지만, 아직 누가 처리할지 정해지지 않은 상태
• 이동 조건 : 개발자가 이 버그를 맡으면 ASSIGNED로 이동

3) 🔴 ASSIGNED (할당됨)

• 특정 개발자에게 버그가 할당되었으며, 개발자가 문제를 해결하기 위해 코드를 수정중인 상태
• 이동 조건 : 해결이 완료되면, RESOLVED로 이동

4) 🟢 RESOLVED (해결됨)

• 개발자가 버그 수정을 완료했다고 표시한 상태
• 이동 조건 : QA(품질팀)가 확인하면 VERIFIED로, 불만족 시 REOPENED로 이동
• 상태 종류
  • FIXED: 버그가 수정됨
  • WONTFIX: 이슈를 해결할 계획이 없음
  • INVALID: 이슈가 유효하지 않음 (오류 아님)
  • DUPLICATE: 중복된 이슈
  • WORKSFORME: 재현되지 않아 수정할 수 없음

5) 🟢 VERIFIED (검증됨)

• QA가 실제로 버그가 잘 해결되었는지 확인한 상태
• 이동 조건 : 확인이 끝났다면, CLOSED로 이동

6) 🟢 CLOSED (닫힘)

• 버그 수정과 검증까지 모두 끝난 최종 상태

7) 🔴 REOPENED (다시 열림)

• 만약 버그가 제대로 고쳐지지 않았건, 다시 발생하면 돌아오는 상태
• 다시 ASSIGNED나 NEW로 돌아가서 수정 과정을 반복한다.

Pull Request (풀 리퀘스트)

• A typical way to provide a patch from users.
  (사용자가 패치를 제공하는 일반적인 방법)