오픈소스의 개발방식

오픈소스 소프트웨어 프로젝트에서는 ‘공개’라는 단어가 함축하듯이 여러명의 개발자가 참여하는 분산개발, 기존에 공개되어 있는 많은 소프트웨어 자원의 이용, 다양한 부류의 자원자들에 의한 소프트웨어 리뷰및 시험 과정, 기술 지원 방법, 기능의 확장, 새로운 프로젝트로의 따른 가지치기 과정 등이 상용 소프트웨어와 달리 매우 중요한 의미를 가지게 된다. 새로운 프로젝트의 경우, 비교적 폐쇄적인 초기 개발 단계를 거쳐, 공개된 뒤에, 커뮤니티와 호흡 하는 오픈소스 소프트웨어 순환 구조에 들어간다. 일단 오픈소스 소프트웨어 순환구조에 들어가면, 프로젝트 관리자들뿐만 아니라 커뮤니티의 모든 참여자들이 공개된 소스에 접근 가능하며, 기능 추가, 버그 리포트 및수정, 새로운 기능의 요구 등을 함으로서 지속적인 소프트웨어의 개선이 그 안에서 이루어지게 된다.

개발방식 종류

1. 기존 프로젝트 참여하기

어떤 소프트웨어를 개발하고자 하는 사람(그룹)은 우선 개발하고자 하는 소프트웨어가 가져야할 기능에 대한 충분한 분석을 한 뒤, 이미 존재하는 오픈소스 소프트웨어 프로젝트들 가운데 주어진 요구 사항을 만족하는 것이 있는지 확인한다. 이 과정에서 요구사항을 모두 충족하는, 또는 충족을 목표로 하는 프로젝트를 성공적으로 발견했다면, 그 사람은 아마도 발견된 프로젝트의 사용자 또는 적극적인 역할을 하는 자원자, 더 나아가 개발자로 오픈 소스 소프트웨어 순환 구조에 참여하게 된다. 혹시 부분적으로 요구 사항을 만족하는 프로젝트가 발견된 경우에도 기능추가를 요구하고, 그 요구가 프로젝트 관리자 그룹에서 받아들여짐으로서 순환 구조에 참여가 가능하다. 실제로 30% 가량의 개발자가 다른 개발자의 결과물을 개선하기 위해 기존 프로젝트 커뮤니티에 참여하는 것 으로 조사되고 있다. 반면에, 상용 소프트웨어의 경우에는 주어진 요구사항을 만족하는 타 소프트웨어가 이미 시장에 존재하는 경우, 경쟁력(기능, 가격 등) 분석, 자사 관련 제품 라인업, 장기적 제품 로드맵 등을 바탕으로 한 경영적 판단을 거쳐 프로젝트의 진행 여부, 또는 해당소프트웨어 업체와의 연합, 더 나아가서는 인수, 합병등을 결정한다. 검색 단계에서 유사 프로젝트가 발견되었지만, 기존 프로젝트 관리자 그룹에서 새로운 기능 추가 요청을 받아들이지 않은 경우에 개발자는 두가지의 선택을 할 수 있다. 첫번째는 검색단계에서 요구 사항을 만족하는 프로젝트가 없었던 경우와 같이, 전혀 새로운 프로젝트를 시작하는 것이고, 두 번째 선택은 직접 기존 프로젝트에 기능을 추가하는 방법이다. 이를 프로젝트 가지치기 (Branching)라 하며, 공개소스 소프트웨어의 경우, 원 소스를 바탕으로 수정되거나, 추가된 소스 를 모두 공개한다면, 소스의 사용과 배포가 자유롭기 때문에 아무런 법률적 문제없이이런 결정을 내릴 수 있다. 이런 과정으로 개발된 결과는 원 소스에 대한 패치 형태로 원 소스의 개정에따라가는 형식으로 배포되거나, 원 소스의 특정 버전을 기점으로 하는 새로운 프로젝트로 발전하며, 독자적인 오픈 소스 소프트웨어 순환 구조를 성공적으로구성하기도 한다. 프로젝트 가지치기에는 이전 프로젝트 의 결과물을매우 확고한 프로토타입으로 사용할 수 있다는 점을제외하고는 새로운 프로젝트의 시작에 버금가는 준비와 여러 가지 선택이 필요하며, 프로젝트 가지치기를한 개발자에게는 프로젝 트를 성공적으로 유지해야하는 묵시적인 책임도 따른다.

2. 새로운 프로젝트 만들기

새로운 공개소스 소프트웨어 프로젝트의 시작은 요구사항을 만족하는 기존 프로젝트를 발견하지 못한 경우나 기존의 유사 프로젝트에 새로운 기능에 대한 수용요구가 받아들여지지 않은 경우등에 내리는 최후의 선택이라고 볼 수 있다. 그밖에 자주 발생하는 새 프로젝트 시작요인으로는 개인적 취향에 따른 것 인데, 기존 프로젝트에 사용된 개발 언어가 마음에 들고 실제 공개 소스 소프트웨어들은 다양한 라이선스 정책을 가지고 있어서, 거의 대부분은 이 가지치기가 문제 되지 않는다. 자신이 순환구조에 참여가 어렵다고 느끼는 경우, 프로젝트 결과물의 설계구조에 전혀 동의 할 수 없는 경우, 마지막으로는 기존 프로젝트의 핵심 개발자, 관리자 그룹을 개인적으로 선호하지 않는 경우등이 있다. 일단 여러 동기에 의하여, 새로운 프로젝트가 시작되면, 상용 소프트웨어의 개발과 유사한 과정을 거치게 된다. 이 과정은 같은 동기와 목표의식을 가진 핵심 개발자들로 개발팀을 구성하고, 요구분석을 더욱 견고하게 한 뒤, 각종 위험 요인 분석, 일정 만들기 등의 절차적인 작업들로 시작된다. 그 가운데 위험 요인 분석에는, 이 새로운 프로젝트가 기존 프로젝트들에 비하여 경쟁력을 가질 수 있는지, 개발과 추후 관리를 위한 충분한 자원자를 확보할 수 있는지, 개발에 필요한 장비가 확보 가능한지 등을 포함한다. 많은 프로젝트의 경우, 표준적인 PC들로 개발환경을 어렵지 않게 구축할 수 있으며, 소프트웨어 개발도구도 역시 오픈소스 소프트웨어를 사용하기 때문에 큰 비용을 유발하지 않으며, 여러 개발자들의 분산 개발을 지원 하기 위한, 버전 관리 시스템(소스 저장소), 메일링 리스트 등도 개인 PC를 이용하여 구축할 수 있다. 최근에는 다수의 오픈소스 프로젝트들의 결과물이 마이크로소프트의 윈도우즈 계열 운영체제를 위해서 개발되고 있다. cygwin과 같은 운영체제 적응계층을 바탕으로 하는 경우에는 별다른 문제가 없지만, 윈도우즈 운영체제를 직접 지원하는 경우, 도구의 문제가 따른다. 프로젝트의 시작단계에서부터 소스의 관리, 버그의 관리, 개발자들간의 원활한 의사소통을 위 하여 SourceForge.net과 같은 공개소스 소프트웨어 개발자 사이트를 이용할 수 있지만, 대부분 초기의 프로젝트의 경우, 프로젝트의 시작 동기, 요구사항, 설계 등이 기술된 공식적인 문서의 부족이나 다운로드가 가능한 소프트웨어 릴리즈가 없다는 이유로 개발자지원 사이트에 등록된다 해도, 커뮤니티 형성 등의 파급효과를 기대하기는 어렵다.

3. 개발자간의 소통

개발자 간 소통 방법에는 커뮤니티 참여자의 성격(개발자, 관리자, 사용자 등)에 따른 전자우편 리스트, 포럼과 그들의 저장소, 버그 리포트, 프로젝트 관련 문서, FAQ 등이 있다. 버그 리포트는 사용자와 개발자의 공식적인 통신 방법으로, 오픈 소스 소프트웨어 개발자 사이트들이 공통으로 제공하는 버그 트래킹 시스템을 이용한다. 별도의 홈페이지를 이용하여 프로젝트를 공개한다면, ?Bugzilla[13]와 같은 버그 트래킹 시스템을 설치하여 이용할 수 있다. 버그 트래킹 시스템은 버그를 등록하고, 누가 그것을 담당하여 수정할지를 할당하고, 현재 처리 상태는 어떤지, 그리고 그 버그에 대한 의견 교환을 하는 등, 버그의 발생부터 해결까지의 전 과정에 대한 체계적인 관리 방법을 제공한다. 소스 코드의 경우 안정된 배포 버전, 흔히 베타 버전이라고 하는 외부용 시험 버전, 그리고 현재 개발이 진행 중인 소스 코드 스냅숏, 세 가지를 모두 공개하는 것이 보통이다. 소스 코드 스냅숏 공개는 개발자들 이 소스의 버전 관리를 위하여 사용하고 있는 소스 코드 버전 관리 서버에 로그인하여 소스에 읽을 수 있도록 하는 것이다. 소스 코드의 공개는 오픈 소스 소프트웨어의 가장 큰 미덕으로 누구나 쉽게 다운로드, 리뷰, 빌 들을 할 수 있도록 하고, 궁극적으로 패치를 만들어 프로젝트 관리자에게 보낼 수 있어야 한다. 많은 오픈 소스 프로젝트들은 홈페이지 또는 배포된 소스에 프로젝트 기여자들을 나열함으로써, 그들의 기여에 감사하고, 동시에 그 목록에 없는 개발자, 사용자들에게 동기를 부여한다.

4. 커뮤니티 기반 개발

단 프로젝트의 프로토타입, 소스가 공개되어, 점차 알려지고, 사용자, 자원 개발자 등의 관심을 끌어, 커뮤니티가 형성되면 오픈 소스 순환 구조에 의해 프로젝트는 진화한다. 공개에 앞서 결정된 의사 결정 구조 등에 따라 수정 버전의 배포, 기능이 대폭 보강된 버전 상향 등이 이루어지며, 사용 중에 발생하는 버그의 보고 및 수정, 기능 추가 요구 등이 커뮤니티 측에서도 이루어지며, 그 결과가 프로젝트 관리자 그룹에 의해 반영된다. 이 순환 구조가 얼마나 원활하게 운영되는지가 결국 오픈 소스 소프트웨어 프로젝트의 성패를 결정한다. 이 구조의 원활한 순환과 효율성은 모든 참여자 사이의 의사소통 및 의사 결정 과정 등, 배포 전에 내려진 여러 결정 때문에 좌우된다. 오픈 소스 소프트웨어가 커뮤니티에 의해 진화한다는 일반적인 인식에도 불구하고, 그 프로젝트를 처음 시작하고, 많은 경우 결국 관리하게 되는 코어 개발자 그룹의 지속적인 관심과 개선 의지는 프로젝트 성공의 가장 중요한 요인이다. 많은 오픈 소스 소프트웨어 프로젝트 참여의 동기가 ‘재미’ 또는 ‘명성’이라고 언급한 바가 있다. 하지만, 오픈 소스 순환 구조에 안정적으로 들어선 아주 성공적인 프로젝트들은 그 결과가 상업적인 활동에 점차 많이 적용되면서, 기술 지원과 새로운 기능 요구에 대하여 시기적절한 대응이 요구되며, 프로젝트의 핵심 개발자, 관리자 그룹에는 더 빠른 진화를 할 수 있는 추 임시 쌓기인 동력이 필요하게 된다. 이 과정에서 많은 경우 기술 지원에 대한 대가로서 금전적 보상 이 따르는 경우가 많아졌다.