오픈 소스 소프트웨어 개발

**오픈 소스 소프트웨어 개발**(Open-source software development, **OSSD**)은 오픈 소스 소프트웨어, 또는 소스 코드가 공개된 유사한 소프트웨어를 **오픈 소스 소프트웨어 프로젝트**(open-source software project)를 통해 개발하는 과정이다. 이는 오픈 소스 사용권 하에 소스 코드와 함께 제공되어 디자인을 연구하고, 변경하며, 개선할 수 있는 소프트웨어 제품이다. 인기 있는 오픈 소스 소프트웨어 제품의 예시로는 모질라 파이어폭스, 구글 크로미엄, 안드로이드, 리브레오피스 및 VLC 미디어 플레이어가 있다.
# 역사
1997년에 에릭 레이먼드는 성당과 시장을 썼다.Raymond, E.S. (1999). The Cathedral & the Bazaar. O'Reilly Retrieved from http://www.catb.org/~esr/writings/cathedral-bazaar/. 이 책에서 레이먼드는 두 가지 종류의 소프트웨어 개발을 구분한다. 첫 번째는 기존의 클로즈드 소스 개발이다. 레이먼드에 따르면 이러한 개발 방식은 중앙 집중식 계획, 엄격한 조직화, 그리고 처음부터 끝까지 하나의 과정으로 진행되는 성당 건축과 같다. 두 번째는 진보적인 오픈 소스 개발로, 이는 "서로 다른 의제와 접근 방식이 뒤섞인 시끌벅적한 시장과 같아서, 일련의 기적을 통해서만 일관되고 안정적인 시스템이 나올 수 있는 것 같다"고 비유된다. 후자의 비유는 오픈 소스 개발 과정에서 발생하는 논의를 가리킨다. 바(Bar)와 포겔(Fogel)에 따르면, 두 가지 개발 방식의 차이점은 일반적으로 버그 보고서 및 기능 요청 처리(및 생성) 방식과 프로그래머가 작업하는 제약 조건에 있다.Bar, M. & Fogel, K. (2003). Open Source Development with CVS, 3rd Edition. Paraglyph Press. () 클로즈드 소스 소프트웨어 개발에서 프로그래머는 버그 보고서를 처리하고 생성하며 기능 요청을 다루는 데 많은 시간을 보낸다. 이 시간은 추가 개발 계획을 세우고 우선순위를 정하는 데 사용된다. 이는 개발팀의 일부가 실제 개발이 아닌 이러한 문제에 많은 시간을 할애하게 만든다. 또한, 클로즈드 소스 프로젝트에서 개발팀은 소프트웨어의 기술적 문제와 상충하는 관리 관련 제약(예: 마감 기한, 예산 등) 하에서 작업해야 하는 경우가 많다. 오픈 소스 소프트웨어 개발에서는 이러한 문제가 개발 과정에 소프트웨어 사용자를 통합하거나, 심지어 이러한 사용자들이 직접 시스템을 구축하도록 함으로써 해결된다.
# 모델
오픈 소스 소프트웨어 개발의 프로세스-데이터 모델 오픈 소스 소프트웨어 개발은 여러 단계로 나눌 수 있다. 여기에 명시된 단계들은 샤르마(Sharma) 외 연구진의 논문에서 파생되었다.Sharma, S., Sugumaran, V. & Rajagopalan, B. (2002). A framework for creating hybrid-open source software communities. Information Systems Journal 12 (1), 7 – 25. 오픈 소스 소프트웨어 개발의 프로세스-데이터 구조를 보여주는 다이어그램이 오른쪽에 표시되어 있다. 이 그림은 해당 데이터 요소와 함께 오픈 소스 소프트웨어 개발 단계를 보여준다. 이 다이어그램은 메타모델링 및 메타 프로세스 모델링 기술을 사용하여 만들어졌다.
## 오픈 소스 프로젝트 시작하기
오픈 소스 프로젝트 작업은 여러 가지 방식으로 시작될 수 있다. # 프로젝트의 필요성을 느낀 개인이 공개적으로 프로젝트 개발 의사를 밝힌다. # 제한적이지만 작동하는 코드베이스를 개발하던 개발자가 이를 공개하여 오픈 소스 프로그램의 첫 번째 버전으로 배포한다. # 성숙한 프로젝트의 소스 코드가 공개된다. # 잘 확립된 오픈 소스 프로젝트가 관심 있는 외부 당사자에 의해 포크될 수 있다. 에릭 레이먼드는 그의 에세이 《성당과 시장》에서 프로젝트 의도를 발표하는 것이 작동하는 프로젝트를 대중에게 공개하는 것보다 일반적으로 열등하다고 언급했다. 기존의 유사 프로젝트에 기여하는 것이 더 효과적일 때 프로젝트를 시작하는 것은 흔한 실수이다 (NIH 증후군). 성공적인 프로젝트를 시작하려면 이미 존재하는 것을 조사하는 것이 매우 중요하다. 이 과정은 기존 프로젝트를 채택할지, 아니면 새로운 프로젝트를 시작할지 선택하는 것으로 시작된다. 새로운 프로젝트가 시작되면 과정은 초기화 단계로 넘어간다. 기존 프로젝트가 채택되면 과정은 실행 단계로 직접 넘어간다.
# 오픈 소스 프로젝트의 종류
몇 가지 유형의 오픈 소스 프로젝트가 존재한다. 첫째, 독립적인 코드 조각으로 구성된 일반적인 소프트웨어 프로그램 및 라이브러리가 있다. 일부는 다른 오픈 소스 프로젝트에 의존할 수도 있다. 이러한 프로젝트는 특정 목적을 수행하고 명확한 요구를 충족시킨다. 이 유형의 프로젝트의 예시로는 리눅스 커널, 파이어폭스 웹 브라우저 및 리브레오피스 오피스 스위트 도구가 있다. 배포판은 또 다른 유형의 오픈 소스 프로젝트이다. 배포판은 공통된 목적을 가지고 동일한 소스에서 발행된 소프트웨어 모음이다. "배포판"의 가장 대표적인 예는 운영 체제이다. 많은 리눅스 배포판 (예: 데비안, 페도라 코어, 맨드리바, 슬랙웨어, 우분투 등)은 리눅스 커널과 함께 많은 사용자 공간 구성 요소를 제공한다. 다른 배포판으로는 다양한 운영 체제용 펄 프로그래밍 언어인 ActivePerl과 마이크로소프트 윈도우용 오픈 소스 프로그램 시그윈 배포판이 있다. BSD 파생물과 같은 다른 오픈 소스 프로젝트는 전체 운영 체제, 커널 및 모든 핵심 구성 요소의 소스 코드를 하나의 버전 관리 시스템으로 유지 관리하며, 전체 시스템을 단일 팀으로 함께 개발한다. 이러한 운영 체제 개발 프로젝트는 다른 배포 기반 시스템보다 도구를 더 긴밀하게 통합한다. 마지막으로 책 또는 독립 문서 프로젝트가 있다. 이러한 항목은 일반적으로 오픈 소스 소프트웨어 패키지의 일부로 제공되지 않는다. 리눅스 문서화 프로젝트는 리눅스 운영 체제의 다양한 측면을 문서화하는 많은 프로젝트를 호스팅한다. 이 유형의 오픈 소스 프로젝트에는 다른 많은 예시가 있다.
# 방법론
폭포수 모델과 같은 전통적인 소프트웨어 개발 방법론을 따르는 오픈 소스 프로젝트를 운영하기는 어렵다. 이러한 전통적인 방법에서는 이전 단계로 돌아가는 것이 허용되지 않기 때문이다. 오픈 소스 소프트웨어 개발에서는 프로젝트 시작 전에 요구 사항이 거의 수집되지 않으며, 대신 로빈스(Robbins)가 설명한 대로 소프트웨어 제품의 초기 릴리스를 기반으로 한다.Robbins, J. E. (2003). Adopting Open Source Software Engineering (OSSE) Practices by Adopting OSSE Tools. Making Sense of the Bazaar: Perspectives on Open Source and Free Software, Fall 2003. 요구 사항 외에도 종종 자원 봉사자가 소프트웨어의 초기 릴리스를 기반으로 소프트웨어 제품 개발을 돕기 위해 참여한다. 아브라함손(Abrahamsson) 외 연구진에 따르면 이러한 네트워크 효과는 필수적이다. "제시된 프로토타입이 충분한 관심을 모으면 점차 더 많은 개발자를 끌어들이기 시작할 것이다." 그러나 아브라함손 외 연구진은 또한 커뮤니티가 폐쇄형 소프트웨어의 비즈니스 세계와 마찬가지로 매우 가혹하다고 지적한다. "고객을 찾으면 살아남지만, 고객이 없으면 죽는다."Abrahamsson, P, Salo, O. & Warsta, J. (2002). Agile software development methods: Review and Analysis. VTT Publications. 푸게타(Fuggetta)doi=10.1016/S0164-1212(02)00065-1는 “고속 프로토타이핑, 점진적 및 진화적 개발, 나선형 수명 주기, 고속 응용 프로그램 개발, 그리고 최근의 익스트림 프로그래밍 및 애자일 소프트웨어 프로세스가 독점 소프트웨어와 오픈 소스 소프트웨어에 동일하게 적용될 수 있다”고 주장한다. 그는 또한 익스트림 프로그래밍을 오픈 소스 소프트웨어 개발에 매우 유용한 방법으로 지목한다. 보다 일반적으로, 모든 애자일 프로그래밍 방법은 반복적이고 점진적인 특성 때문에 오픈 소스 소프트웨어 개발에 적용 가능하다. 다른 애자일 방법들도 오픈 소스 소프트웨어 개발과 폐쇄형 소프트웨어 개발 모두에 똑같이 유용하다. 예를 들어, 인터넷-스피드 개발은 분산 개발 원칙을 채택하기 때문에 오픈 소스 소프트웨어 개발에 적합하다. 인터넷-스피드 개발은 지리적으로 분산된 팀이 '24시간 내내' 작업하도록 한다. 이 방법은 주로 대규모 폐쇄형 기업에서 채택되지만(다른 시간대에 개발 센터를 둘 여유가 있는 유일한 기업이기 때문), 자원 봉사자들로 구성된 대규모 그룹이 개발한 소프트웨어는 자연스럽게 모든 시간대에 걸쳐 개발자를 보유하는 경향이 있으므로 오픈 소스 프로젝트에서도 똑같이 잘 작동한다.
# 도구

## 통신 채널
오픈 소스 프로젝트의 개발자와 사용자는 모두 프로젝트에서 근접하게 작업할 필요는 없다. 이들에게는 전자적인 통신 수단이 필요하다. 전자우편은 오픈 소스 개발자와 사용자 간의 가장 일반적인 통신 형태 중 하나이다. 종종 전자 메일링 리스트가 사용되어 이메일 메시지가 관심 있는 모든 당사자에게 한 번에 전달되도록 한다. 이는 최소한 한 명의 구성원이 회신할 수 있도록 보장한다. 실시간으로 통신하기 위해 많은 프로젝트는 IRC와 같은 인스턴트 메신저 방법을 사용한다. 최근 웹 포럼은 사용자가 오픈 소스 제품을 사용할 때 발생하는 문제에 대한 도움을 얻는 일반적인 방법이 되었다. 위키는 개발자와 사용자를 위한 통신 매체로 일반화되었다.magazine=Wired UK
## 버전 관리 시스템
버전 관리 OSSD(오픈 소스 소프트웨어 개발)에서는 주로 자원 봉사자로 이루어진 참가자들이 서로 다른 지리적 지역에 분산되어 있기 때문에, 참가자들이 소스 코드 개발에 협력할 수 있도록 돕는 도구가 필요하다. 2000년대 초반에는 CVS가 OSS 프로젝트에서 사용되는 대표적인 소스 코드 협업 도구였다. CVS는 여러 사람이 동시에 프로젝트를 작업할 때 파일과 코드를 관리하는 데 도움이 된다. CVS는 여러 사람이 동시에 같은 파일을 작업할 수 있도록 한다. 이는 파일을 사용자 디렉토리로 옮긴 다음 사용자가 작업을 마치면 파일을 병합하는 방식으로 이루어진다. CVS는 또한 이전 버전의 파일을 쉽게 검색할 수 있도록 한다. 2000년대 중반에는 서브버전 버전 관리 시스템 (SVN)이 CVS를 대체하기 위해 만들어졌다. 이는 OSS 프로젝트 버전 관리 시스템으로 빠르게 자리 잡고 있다. 많은 오픈 소스 프로젝트는 이제 SVN 및 CVS와 같은 중앙 집중식 저장소보다 더 잘 확장되는 분산 버전 관리 시스템을 사용한다. 인기 있는 예로는 리눅스 커널에서 사용하는 Gitlanguage=en과 파이썬 프로그래밍 언어에서 사용하는 머큐리얼이 있다.
## 버그 추적기 및 작업 목록
버그 추적 시스템 대부분의 대규모 프로젝트는 프로젝트 개발에서 다양한 문제의 상태를 추적하기 위해 버그 추적 시스템을 필요로 한다.
## 테스트 및 디버깅 도구
OSS 프로젝트는 빈번한 통합을 거치므로, 시스템 통합 중 테스트 자동화를 돕는 도구가 사용된다. 이러한 도구의 한 예는 Tinderbox이다. Tinderbox는 OSS 프로젝트 참가자들이 시스템 통합 중 오류를 감지할 수 있도록 한다. Tinderbox는 지속적인 빌드 프로세스를 실행하며, 문제가 있는 소스 코드 부분과 해당 문제가 발생하는 플랫폼에 대해 사용자에게 알려준다. 디버거는 다른 프로그램을 디버깅(그리고 때로는 테스트하거나 최적화)하는 데 사용되는 컴퓨터 프로그램이다. GNU 디버거(GDB)는 오픈 소스 소프트웨어 개발에 사용되는 디버거의 한 예이다. 이 디버거는 원격 디버깅을 제공하여 오픈 소스 소프트웨어 개발에 특히 적용 가능하다. 메모리 누출 도구 또는 메모리 디버거는 메모리 누출 및 버퍼 오버플로를 찾는 프로그래밍 도구이다. 메모리 누출은 컴퓨터 프로그램이 더 이상 필요하지 않은 메모리를 해제하지 못하는 특정 종류의 불필요한 메모리 소비이다. 모질라가 사용하는 메모리 누출 감지 도구의 예로는 XPCOM 메모리 누출 도구가 있다. 유효성 검사 도구는 코드 조각이 지정된 구문에 부합하는지 확인하는 데 사용된다. 유효성 검사 도구의 한 예는 Splint이다.
## 패키지 관리
패키지 관리 시스템은 컴퓨터에서 소프트웨어 패키지를 설치, 업그레이드, 구성 및 제거하는 프로세스를 자동화하는 도구 모음이다. .rpm용 레드햇 패키지 매니저(RPM)와 .deb 파일 형식용 고급 패키징 도구(APT)는 여러 리눅스 배포판에서 사용되는 패키지 관리 시스템이다.
# 프로젝트 홍보
소프트웨어 디렉터리 및 릴리스 로그: # 자유 소프트웨어 디렉터리 문서: # 리눅스 위클리 뉴스 # IBM developerWorks
# 추가 자료
* location=Amsterdam Boston * location=Cambridge, Mass * location=Hershey, Pa. * oclc=ocm62322583 * location=Bradford * location=New York, NY * editor-first3=Ioannis M. * location=Sebastopol * location=Oxford * location=Boca Raton * location=Berkeley, CA 소프트웨어 공학 위키데이터 속성 추적 분류:자유-오픈 소스 소프트웨어