* (이 논문은 저자의 허락 하에 번역되었습니다. 2006년에 거칠게 번역)


성공적인 프리 소프트웨어 프로젝트를 만드는 방법

(How to Have a Successful Free Software Project)

원저자:   

    Anthony Senyard and Martin Michlmayr
    Department of Computer Science and Software Engineering
    The University of Melbourne
    ICT Building, 111 Barry St, Parkville
    Melbourne, Victoria, Australia
    anthls@cs.mu.oz.au, tbm@cyrius.com

번역: 이 민석 (한성대학교 컴퓨터공학과 교수, minsuk@hansung.ac.kr)

주요 용어: free software, software lifecycle, development process.

1. 개요

몇몇 프리 소프트웨어 프로젝트는 매우 성공적이었다. 이런 두드러진 성공은 해당 소프트웨어의 높은 품질과 적합성 때문일 가능성이 높다. 높은 품질과 적합성은, 소프트웨어의 결함을 발견하여 수정하고, 기능을 추가하는 협동 개발자 역할을 수행하는 큰 규모의 사용자 커뮤니티에 의한 세심한 피어 리뷰 과정을 통해서 얻어진다. 이 과정이 프리 소프트웨어 프로젝트의 성공에 반드시 필요한 것이지만, 프리 소프트웨어 개발을 위해서는 ‘시장’의 형성 이상의 뭔가가 더 필요하다. 이 논문에서 우리는 프리 소프트웨어 모델의 생명 주기를 정의하기 위해 기존 프리 소프트웨어들을 조사하여, 생명 주기 모델의 각 단계를 정의한다. 그리고 시장 단계가 가장 많은 주목을 끌기는 하지만, 실제 다양한 참여를 수용할 수 있는 기반은 초기 단계의 모듈화된 설계이며, 또 프리 소프트웨어 프로젝트의 성공과 실패를 좌우하는 중요한 단계는 초기의 그룹 개발 단계에서 커뮤니티 기반 개발로 전이하는 단계라는 점을 이 논문에서 주장한다.

2. 서론

Linux[34], Apache[1], FreeBSD[12]와 같이 잘 알려진 프리 소프트웨어 프로젝트는 대단히 성공적인 프로젝트이다. 또 실패한 프로젝트들도 많이 있다. 프리 소프트웨어 프로젝트를 새로 시작하고, 공동으로 작업을 하는데 있어서의 장애물은 이런 활동들과 프로젝트 생명 주기의 각 단계들에 대한 정연한 설명이 없다는 것이다. 프리 소프트웨어 개발의 원리는 많이 이야기되어 왔으며, 주로 경험 있는 개발자들을 대상으로 하고 있다[28, 8]. 이 논문에서는 좀 더 완전하고, 구조화되고, 구체적인 프리 소프트웨어 프로젝트 개발 생명 주기를 기술한다. 이 모델은 프리 소프트웨어 프로젝트의 개발에 좀 더 체계적인 접근을 하도록 하여 프로젝트의 성공의 가능성을 높이는 기초가 될 것으로 본다.
에릭 레이몬드는 그의 저명한 저서 ‘성당과 시장 (The Cathedral and the Bazaar)’에서 리눅스 커널의 성공에 비추어 프리 소프트웨어와 오픈 소스 프로젝트의 개발 구조를 살펴보았다 (프리 소프트웨어와 오픈 소스라는 용어는 특정 라이선스 아래서 배포된 소프트웨어를 의미한다[26].) 이 논문에서 프리 소프트웨어의 개발 모델이란 분산된 조직 하에서 인터넷으로 의사소통을 하며 자원 개발자 그룹에 의한 개발 모델을 의미한다.
. 전통적인 소프트웨어 개발(소스 코드를 공개하지 않는)과 성당의 건축을, 자원자 커뮤니티에 의해 개발되는 프리 소프트웨어를 시장에 비유했다. 우리는 이 논문 전체에서 성당과 시장이라는 용어를 사용한다. 그러나 이러한 접근이 서로 상반된다기보다는 같은 생명 주기 안에서 상호 보완적인 단계로 보고 있다. 그림 1은 성공적인 프리 소프트웨어 프로젝트가 기본적으로 거쳐 가는 세 가지 단계를 그린 것이다.



<그림 1 > 프리 소프트웨어 개발 생명 주

프리 소프트웨어 프로젝트의 초기 단계는 자원자에 의한 커뮤니티 환경에서 운영되지 않는다. 실제로는, 성공적인 프리 소프트웨어 프로젝트만이 전통적인 폐쇄적 프로젝트에서 커뮤니티 기반 프로젝트로 전이된다. 사실 시장 단계에서 프로젝트를 시작하는 것은 불가능하다. 자원 개발자들을 끌어들여 동기를 부여하고, 프로젝트 커뮤니티를 형성하게 만드는 요구가 있다하더라도, 프리 소프트웨어 프로젝트가 실제로 어떻게 시작되는지에 대한 설명을 하기는 쉽지 않다. 하지만 이 초기 단계는 성공적인 프로젝트가 되기 위한 중요한 부분이다.
프리 소프트웨어 프로젝트의 초기 단계는 나중의 시장 단계와 뚜렷한 대조를 이루며 성당 스타일 개발의 모든 특성을 가지고 있음을 볼 수 있다. 초기 구현을 하기 위한 초기 단계는 커뮤니티에서 분리된 채 개인이나 작은 팀에 의해 진행된다[4]. 초기 구현은 외부의 기여나 도움 없이 요구 사항 정리, 디자인, 구현, 테스트와 같은 일반적인 소프트웨어 개발 활동들을 통해 이루어진다. 이러한 개발 과정은 프로젝트 창시자를 중심으로 하는 엄격한 관리와 기획 아래 진행되며,  존슨의 ‘폐쇄적 프로토타이핑’으로 불린다[16].
그러나 전통적인 소프트웨어 프로젝트와 달리, 프리 소프트웨어 프로젝트는 고품질의 유용한 결과물을 얻기 위해서 성당 단계에서 시장 단계로 이동해야 한다. 이러한 이동은 이 논문에서 다루겠지만 상당히 복잡하며 성공으로 가는 길목의 주요 걸림돌이 된다. 실제로 시장 단계에 성공적인 프로젝트의 많은 예가 있는 한편, 주요 프리 소프트웨어 프로젝트는 결코 성당 단계를 벗어나지 못하고 개발자 커뮤니티라는 자원에 접근하지 못한다[6].
이 논문의 목적은 프리 소프트웨어 프로젝트의 성공을 위해 시작하고 관리할 것인가에 대한 지침을 제공하는 것이다. 첫째, 시장 단계에서의 프리 소프트웨어 프로젝트가 가져야 하는 특성들에 대하여, 현재 가장 좋은 관행이 무엇인지를 예로 들어 설명한다. 이 설명은 우리에게 프리 소프트웨어 프로젝트의 초기 단계의 목표를 제시하고, 소프트웨어가 시장 단계로 진행하기 위해 요구하는 속성이 무엇인지를 설명한다. 또 프로젝트가 성공적인 것으로 살아남기 위한 관리상의 이슈들에 대하여 개괄적으로 기술한다. 둘째, 프로젝트가 시장 단계에 도달하기 전에 이루어져야 하는 초기 단계-성당 스타일 개발에서 더 일반적으로 가지고 있는-에 대하여 이야기한다. 성당 단계에 대한 기술은 그림 1에 보이는 구성 요소들을 차례로 다루는 방법을 설명함으로써 이루어진다. 설명과 함께 한 단계에서 다음 단계로 넘어가기 위한 선행 조건들이 제시된다. 셋째, 시장 단계에서의 프로젝트 성공적 운영을 위한 전이 단계에서의 활동들에 대하여 설명한다. 마지막으로, 전체 프로세스와 생명 주기에 대한 결론을 기술한다.

3. 시장 단계

프리 소프트웨어 프로젝트의 목표는 사용자 커뮤니티가 향후 개발에 활발히 기여할 수 있는 단계에 이르는 것이다. 이 절에서는 어떤 것이 성공적이며, 어떤 함정이 있는지 정확히 정의하기 위하여 성공적인 프로젝트에 대한 설명을 한다. 이것으로 성당 단계와 전이 단계에서 요구되는 특성들이 무엇인지 추정할 수 있을 것이다.
시장 단계의 핵심 특성은 사용자 커뮤니티와 개발자가 소프트웨어 시스템을 구성하는 소스 코드를 검토하고 수정할 수 있다는 것이다. ‘백지장도 맞들면 낫다.’는 옛 속담은 프리 소프트웨어가 성공하는 이유를 잘 설명한다. 많은 수의 자원자가 한 프로젝트에 동시에 일을 하는 경우의 여러 장점들과 몇 가지 문제점에 대하여 이 절에서 설명한다. 이 절에서 초기 구현이라 함은 시장 단계의 시작 시점에 사용될 소프트웨어를 의미한다. 또 전이 단계는 시장 단계를 지원하기 위한 발판을 만드는 일을 수행하는 절차이다. 이 개념들은 4절에서 좀 더 상세하게 다루어진다.


<그림 2> 시장 스타일의 개발 생명 주기

그림 2의 시장 스타일 개발에서는 소스 코드를 일반에게 공개하며, 특히, 사용자들로부터 적극적인 기여를 권한다. 기여는 여러 형태로, 어느 때나 이루어질 수 있다. 전문 기술이 없는 사용자들은 새로운 요구 사항을 제안하거나, 사용자 설명서, 지침서를 만들거나, 혹은 사용상의 문제점들을 보고하는 기여를 할 수 있다. 기술이 있는 사용자는 기능을 구현하거나, 버그를 수정하고, 소프트웨어의 설계를 확장할 수도 있다. 큰 규모의 사용자와 개발자 커뮤니티에 의해 수행되는 전체적이고 계속적인 소프트웨어 검토에서 오는 소프트웨어 품질 확보가 이 단계의 주요 이득이다.
이러한 이득은 소프트웨어 공학에서의 원리와 일치한다. 프리 소프트웨어 프로젝트의 ‘디버깅 절차’는 전통적인 소프트웨어 생명 주기의 유지 단계와 비슷하다. 여러 연구에서 프로젝트 유지 보수를 위한 비용은 개발 비용의 50%에서 1,300% 정도인 것으로 조사된다[32,19]. 이 비율을 차치하고서라도, 소프트웨어 유지 보수는 개발의 모든 전 단계만큼, 또는 그 보다 더 많은 자원을 소비한다는 것이 대개 받아들여지고 있다. 프리 소프트웨어 프로젝트는 유지 보수 단계에 이르렀을 때, 협동하는 개발자 커뮤니티의 자원을 이용할 수 있기 때문에 제한적인 자원을 가지고 있는 전통적인 프로젝트보다 훨씬 더 생산적이다. 이 절에서는 어떤 활동들이 시장 단계를 촉진하는지 살펴본다.

3.1. 피어 리뷰

소스 검토와 읽기를 포함하는 피어 리뷰는 최고의 개발 관행 가운데 하나로 자리 잡고 있으며 소프트웨어의 품질을 높게 만든다[10]. 프리 소프트웨어 프로젝트에서는 누구에게나 소스 코드에의 완전한 접근을 허용하는 분산된 피어 리뷰가 가능하다. 오직 제한된 수의 개발자들만이 프로그램의 구현을 위해 실제로 일을 할 수 있는 반면[5], 코드를 검토하고 버그를 찾는 사람들의 숫자는 제한되지 않는다. 버그와 연관성이 있는 여러 조건들이 확인될 때만, 버그는 수정이 가능하기 때문에, 큰 사용자 기반과 코드를 검토하고 버그를 확인하는 개발자가 많다는 것은 성공적인 프리 소프트웨어 프로젝트로서는 큰 혜택이다.

3.2. 동시 개발

시장 단계에서의 활동들은 각 활동들 간의 뚜렷한 구별 없이 동시 다발적으로 이루어질 수 있다[16]. 시장 단계에서의 개발 병렬성에는 두 가지 주요 형태가 있다. 첫째는 기능의 추가와 버그 수정과 같은 여러 가지 다른 개발 형태가 동시에 이루질 수 있다는 점이다. 자원자들은 각자 그들이 원할 때마다 자신이 좋아하는 작업을 할 수 있다. 이것은 프로젝트에서 자원자들의 잠재적 유용성을 증가시킨다. 둘째는 다양한 개발자들이 동시에 구현 작업을 진행할 수 있다는 것이다. 이를 통해, 많은 기능 추가와 버그 수정을 빠르게 해낼 수 있다. 조정이 덜 요구되는, 문서화와 테스트 같은 다른 작업들 역시 동시에 수행될 수 있다[23, 30]. 그러나 프로젝트를 병렬적으로 진행하는 것을 제한하는 요소도 있다[5]. 이 제한 요소는 초기 구현을 위한 설계가 얼마나 잘 모듈화 되어있는지에 달려있다. 또 주 코드 베이스와 개발자들의 코드가 점차 달라지면서, 주기적인 동기화 작업이 필요하다는 점이다.

3.3. 요구 사항의 수용

시장 단계는 자원자들에 의한 여러 입력(요구 사항 등)이 프로젝트의 진행 방향을 정의하는, 공개적인 프로세스를 가진다는 점으로 특징 지워진다. 초기 구현은 주로 프로젝트 창시자의 요구를 기반으로 만들어진다. 시장 단계에서 프로젝트는 기능을 향상하고 소프트웨어를 좀 더 마음에 들게 만들기 위해 일하는, 여러 다른 요구 사항들을 가진 다양한 영역의 개발자들의 참여로 이득을 얻는다. 이것은 기능의 변형이라는 문제를 일으킨다. 이를 방지하기 위하여, 프로젝트 관리자는 특정 기능과 프로젝트의 전반적인 범위가 맞는지를 판단해야만 한다. 만약 어떤 기능이 거부되면, 자원 봉사자는 프로젝트가 자신이 원하는 기능을 가지고 있지 않기 때문에, 프로젝트를 활용하거나 기여하기 위한 동기를 잃게 된다. 반면에, 만약 모든 요구 기능을 수용한다면, 그로 인하여 발생하는 기능의 변형 때문에 크기가 크고, 아마도 유지 보수가 어려운 소프트웨어도 바뀔 수도 있다. 이 문제점은 전이 단계에서 프로젝트의 범위에 관한 명확하고 충분한 의견 교환을 통해 극복될 수 있다.

3.4. 병렬 구현과 디버깅

많은 다양한 사람들이 코드 기여를 할 수 있기 때문에 코딩 스타일과 표준을 기술하는 지침서가 있어야 한다. GNU 프로젝트는 코딩 관행을 설명하는 상세한 문서를 가지고 있으며, 대부분의 큰 프로젝트는 이와 비슷한 문서를 가지고 있거나 잘 알려진 표준들을 따른다[17]. 패치들이 이러한 표준을 확실히 따르게 하는 것이 프로젝트 관리자의 임무이다. 패치는 다른 사람들로부터 이루어질 수 있고 규모도 상당히 다를 수 있다. 많은 프로젝트에서, 대부분의 구현을 담당하고 있는 주요 기여자의 수는 적지만, 많은 그룹이 결함을 고치기 위한 소규모 패치를 제시하곤 한다.
디버깅은 일정 수준의 기술적 전문 지식을 요구한다. 과거에는 프리 소프트웨어를 이용하는 사용자가 파워 유저와 전형적으로 프로그래머 그 자신들이었으며, 이는 사용자들이 소프트웨어의 소스를 검토하는 관행을 만드는데 기여했다. 최근에 프리 소프트웨어가 좀 더 대중화되면서 이런 관행은 바뀌었다. 여전히 기술적으로 익숙한 사용자들이 많이 있는 반면에, 코드를 조사하거나 결함을 수정하는 기술을 가지고 있지는 않지만 전통적인 버그 보고는 계속 할 수 있는 사용자들의 수가 증가하고 있다. 상용 소프트웨어를 능가하는 프리 소프트웨어의 강점은 누구나 코드를 검토할 수 있고 버그 보고를 할 수 있다는 점이다. 버그를 수정하는 것은 소프트웨어의 관리하는 사람들만의 작업이 아니다. 프로젝트 관리자와 사용자 사이의 중간 계층에 많은 수의 개발자들이 있을 수 있으며, 프리 소프트웨어를 이용하여 소프트웨어 배포 판을 만드는 업체가 점점 더 버그 수정 작업을 많이 수행하고 있다.

3.5. 설계와 모듈화의 중요성

요구 사항을 정리하고 코드 기반이 만들어지기 위해서는, 반드시 설계가 이루어져야 한다. 자원 개발자들은 설계 작업을 위해 서로 의견을 교환할 수 있는 방법이 있어야 한다. 훌륭한 디자인과 구현 결과를 만들고자 하는 욕망이라는 동기를 가진 개발자들이 가장 좋은 설계를 완성하기 위해 경쟁함으로써, 여러 설계 대안이 논의되고 병렬적으로 시험될 수 있다.
어떤 설계를 채택하는데 있어 주의해야 할 점은 설계 복잡도의 증가 문제이다. 복잡도를 줄이기 위한 별도의 작업을 하지 않으면, 프로그램은 발전되어가면서 복잡성이 증가한다[18]. 기능의 추가를 장려하면서도 설계 복잡성의 증가를 피하기 위한 유일한 방법은 처음부터 모듈화 설계를 하는 것이다[2, 33]. 초기 구현에서의 명확하고 모듈화된 설계는 개발자 커뮤니티가 요구 사항을 특정 범위 안에서 정리할 수 있게 하고, 설계를 정연하게 유지할 수 있게 하며, 프로젝트의 성공에 필수적이다[34].
그러나 몇 가지 점에서 기술적으로는 기존의 시스템을 계속 유지하는 것 보다, 더 간단한 버전의 시스템으로의 교체가 기술적으로 바람직할 수도 있다. 완전한 재설계에 대한 필요는 초기 구현 결과를 보고는 알 수 없으며, 시스템 재설계를 유도하는 여러 이유가 있다. 첫째는 처음 프로젝트 시작할 때와는 다른, 요구 사항의 확장과 계속되는 개발이 초기 설계를 더 이상 쓸모없게 만드는 경우이다. 더욱이 수정된 요구 사항이 원래의 요구와는 너무나 달라서, 새로운 기능들을 수용하기에 이전 설계가 충분히 모듈화되어 있지 않거나, 확장성이 부족할 수도 있다. 10년도 더 된 NCSA의 http 데몬에 기반하고 있는 아파치 서버가 이런 경우에 해당된다. 둘째는 기술적 수월성 달성이라는 큰 동기가 자유 소스 커뮤니티에 있을 때이다[27]. 즉, 기술적 수월성 확보라는 목표가 재설계를 통해 이루어질 것으로 판단되면, 작업에 들어간다. Perl 5의 개발이 이 경우에 해당된다[16]. 셋째는 자원이나 시간 같은 별다른 경제적 제약이 없어, 기술적 수월성을 달성하는데 무리가 없는 경우이다. 프리 소프트웨어 프로젝트에서는 기존 설계가 재사용이 가능하며, 단기적으로는 더 쉬운 방법임에도 불구하고, 완전한 재설계를 진행하는 경우도 있다.
대부분의 경우 완전한 재설계와 구현은 최초의 구현 (즉, 성당 단계) 때와 비슷한 방법으로 수행된다. 시장 단계에서의 최고 개발자들로 구성된 정예 팀이 완전히 새로운 설계와 구현을 위해 함께 일한다. 이 새로운 초기 구현은 이전 소프트웨어보다 더 모듈화되고, 적응력이 강한 것이 된다. 요약하면, 성당 단계의 초기 구현은 실제 초기 구현인지, 재설계인지 상관없이 더 모듈화되어 있으며 확장성도 높다.

4. 성당 단계

전통적인 소프트웨어 개발은 대개, 사용자와의 접촉이 제한된 채, 전문가에 의해 수행된다. 이런 접근 방법에서, 소프트웨어 버전들은 그림 3에서 보이는 개발 생명 주기에서 시험 단계를 지나 릴리즈 된다. 이 방법은 정적인 개발 조직에서 주로 사용되며, 총괄적인 계획을 따르게 된다. 개발은 개인들로 구성된 팀에 의해 주도되며, 사용자는 소스 코드에 접근할 수 없다. 전통적인 소프트웨어 생명 주기의 중요한 특징은 시험이 완료된 후에 소프트웨어가 릴리즈 된다는 것이다. 성당 단계의 초기 구현을 가장 잘 설명하는 것이 바로 이 접근 방법이다.



<그림 3> 전통적인 개발 방법


<그림 4> 성당 단계에서의 구체적인 프로세스


4.1. 요구 사항

조사 단계로 넘어가기 위한 유일한 조건은 사용자가 소프트웨어에 의해 충족될 수 있는 요구 사항을 가진다는 것이다. 새로운 프리 소프트웨어 프로젝트를 시작한다는 것은 매우 심각한 결정이며, 시간과 에너지의 장기적인 투자에 대한 약속을 하는 것이다. 따라서 강한 인센티브가 있지 않다면 새로운 프로젝트는 시작될 수 없다. 새로운 프로젝트를 시작하려는 개인에게 이러한 동기는 특정한 요구 사항에 의해서 생긴다. 레이몬드의 글에 따르면, 프로젝트는 가려운 곳을 긁어주기 위해서 시작된다[28].

4.2. 조사

시작 단계로 넘어가기 위해서는 하나의 기본적인 조건이 있다. 기존의 어떤 프로젝트도 사용자의 요구를 만족할 수 없다는 점이 확인되어야 한다는 것이다. 또는 유사한 프로젝트가 있다 하더라도 사용자가 그 프로젝트에 참여하기를 원하지 않아야 한다는 것이다.
조사 단계는 개인적인 요구를 이미 충족하는 프로젝트가 없다는 것을 확실히 하는 단계이다. 그 개인은 다른 누군가가 그가 가진 요구 사항을 충족하는 어떤 도구를 이미 만들었거나 만들기 위한 프로젝트가 있는지를 찾기 시작한다. 가장 이상적인 시나리오는 그가 원하는 것을 정확하게 구현한 프로젝트를 발견하는 것이다. 그런 경우, 그 프로젝트도 새로운 사용자를 받아들여, 소프트웨어를 사용하고, 시험하고, 새로운 요구 사항을 제시하고, 프로젝트가 더 넓게 알려지기 때문에 이득을 볼 수 있다.
그런 프로젝트를 발견할 수는 없어도, 그 개인은 정확하게 그의 요구를 만족하지는 않지만, 비슷한 범위와 요구 사항을 가진 그럴듯한 전망이 있는 프로젝트를 대안으로 찾을 수도 있다. 이 경우, 그 개인은 그 프로젝트에 참여하여 특정 기능을 요구하거나 자신의 요구 사항을 만족하도록 소프트웨어의 수정을 요구한다. 이 시나리오는 진행 중인 프로젝트가 어떻게 자원자를 끌어들이고 커뮤니티로부터 이득을 얻을 수 있는지를 설명한다. 그 개인 또한 자신이 새로운 프로젝트를 시작하는 것보다는 기존 프로젝트에 참여하고 기여하는 것이 쉽기 때문에 이득을 볼 수 있다. 프리 소프트웨어 개발자에 관한 연구에 따르면, 30% 가량의 개발자가 다른 개발자의 결과물을 개선하기 위해 프리 소프트웨어 커뮤니티에 참여하는 것으로 알려지고 있다[13].
그렇지만, 유사한 요구 사항을 가진 프로젝트가 없거나, 있다 해도 그 개인이 그 프로젝트에 참여할 가치가 없다고 생각할 수도 있다. (프리 소프트웨어 커뮤니티와 연관성이 있는) 유닉스 철학은 소프트웨어의 재사용을 권장하는 것이지만, 재사용을 막는 여러 가지 심리적 장벽들이 있다. 첫 번째는 그 개인이 익히 아는 언어가 아니거나 선호하지 않는 언어로 프로젝트가 진행되는 경우이다. 두 번째는 소프트웨어에 대한 그 프로젝트의 설계 결과에 동의하지 않는 경우이다. 세 번째는 프로젝트의 기존 멤버들을 선호하지 않는 경우이다. 이러한 요인들은 개인이 자신의 프로젝트를 새로 시작하는 충분한 동기가 된다. 이 때문에 두 프로젝트가 합쳐졌다면 월등히 훌륭한 소프트웨어 프로젝트가 되었을 것이, 평범한 중복된 두 프로젝트로 남게 된다. 어떤 경우에는 기존 프로젝트의 근본적인 결함 때문에 새로운 프로젝트를 시작하는 것이 더 나을 수도 있다.

4.3. 시작 단계

프로토타입 단계로 넘어가기 위해서는 두 가지 조건이 만족되어야 한다. 첫 번째는 요구 사항, 위험 요인, 스케줄에 대한 분석이 의식적이건 무의식적이건 이루어져야 한다는 것이며, 두 번째는 참여하려는 개발자가 앞으로 진행될 개발 작업에 충분한 동기를 가져야 한다는 것이다.
자신의 프로젝트를 시작하려는 개인들은 의식적이건 무의식적이건 성공적인 프로젝트가 될 것인가에 관한 위험 요인 분석과 요구 사항 정리, 일정 만들기 등의 작업을 한다. 위험 요인 분석은 그 개인의 동기와 장기간의 노력을 투자할 수 있는지를 검토하는 것이다. 또 다른 위험 요인 분석은 이 새로운 프로젝트가 이전에 있던 프로젝트에 비하여 경쟁력이 있는지, 또 충분한 자원자를 확보할 수 있는지를 검토하는 것이다. 요구 사항의 정리는 프로젝트의 범위를 정의하는 것으로 어떻게 다른 프로젝트와 차별화되는 지를 확인하는 것이다.  또 프로젝트 창시자에게 개발 일정에 관한 개략적인 아이디어가 있다면, 주 개발자들(있다면)의 초기 구현에 도움이 될 수 있다.
프리 소프트웨어 프로젝트에서 위험 요인 분석, 요구 사항 정리, 일정 만들기에 관한 공식적인 절차는 없기 때문에 이런 작업은 비공식적으로 이루어진다. 필요한 것은 이러한 일련의 작업에서 긍정적인 신호들을 얻는 것이다. 이러한 분석의 결과들이 더 긍정적일 때, 그 프로젝트는 더 장기적으로 유지되며, 시장 단계로 넘어가기 위한 자원자들을 더 잘 모을 수 있다. 시작 단계에서는 개발자가 될 사람들에 대한 동기를 시험하는 단계이다. 개발자들은 요구 사항과 성공적인 프로젝트가 될 가능성뿐만 아니라 프로그래밍 그 자체에 의해서도 동기 부여가 된다. 이러한 요인들이 개인의 초기 요구 사항들과 어우러져, 프로젝트를 시작할 충분한 동기가 된다.

4.4. 프로토타입

전이 단계로 넘어가기 전에 프로토타입 단계에서 만족시켜야 하는 조건은 프로젝트가 창시자의 요구 사항들을 만족시키고, 여러 개발자들이 동시에 작업을 할 수 있도록 확장성을 가져야 한다는 것이다[2, 33].
일단 어떤 개인이 프로젝트를 시작하겠다고 결정하면, 실제 프로젝트 셋업 자체는 비교적 쉽다. 개발 플랫폼으로서 대개는 표준적인 PC들로 충분하며 특별한 장비는 필요하지 않다. 컴파일러, 디버거, 프로그램 환경과 같이 개발과 시험을 위해 필요한 소프트웨어들은 거의 최초로 만들어졌던 프리 소프트웨어들이었으며, 최소한의 노력으로 얻을 수 있는 것들이다.
일단 프로젝트를 위한 인프라가 갖추어진 후에는, 요구 사항의 수집, 설계, 구현, 시험 등의 단계가 진행되며, 개인들은 개발자로서 역할을 수행한다. 이 시점에서의 개발 단계나 활동에 관한 확고한 구조는 없다. 어떤 개발자는 단계를 차례로 진행하고, 어떤 개발자는 일부 또는 모든 단계를 반복적으로 수행하는 순환적인 프로토타입 구현 스타일을 선호한다. 개발 모델의 선택은 개발자들이 알아서 할 일이다[2].
프로토타입 단계가 끝나고, 개발자들이 시장 스타일의 개발로 옮겨가기로 결정할 때, 커뮤니티의 피드백과 참여를 확보하는 일이 중요하게 된다. 프로토타입의 설계와 구현 특징은 프로젝트에 다른 사람들이 참여하기 위한 동기가 될 수 있어야 하며, 이는 단순, 명료한 모듈화된 설계에 의해 가능하다.

4.4.1. 요구 사항

설계 단계로 넘어가기 위해서는 설계될 소프트웨어가 가진 요구 사항에 대한 아이디어들을 정리할 필요가 있다. 프로토타입에 대한 요구 사항은 개발자의 특정한 요구에서 나온다[21,33,35]. 이 요구 사항과 프로그램에 대한 욕심은 다음 단계로 넘어가기 위한 원초적인 동기를 부여한다. 개발자들은 조사와 구현 단계를 지나면서 그들이 원하는 것이 무엇인지 점점 구체적으로 알게 된다. 기존 소프트웨어를 재 구현하는 프로젝트의 경우, 요구 사항은 기존 소프트웨어로부터 나온다[21]. 다른 소프트웨어에 대한 경험과 조사 단계에서 발견된 다른 사용자들의 요구 사항도 추가된다.

4.4.2. 설계

구현을 위해 설계 단계에서 해야 하는 일은 모듈화와 단순화를 통해 얻을 수 있는, 확장성의 확보이다. 설계가 몇 가지 중요한 속성을 만족하는 한, 설계 단계에서의 절차는 별로 중요하지 않다. 개인적인 설계 관행, 유닉스 철학과 문화가 프리 소프트웨어 프로젝트의 성공에 공헌할 수 있는 설계 프레임웍을 제공한다. 명확한 통신 방법과 인터페이스를 유지한 채, 전체 소프트웨어 시스템을 작은 시스템들로 나누면, 자원 개발자들이 독립적으로 개발을 진행할 수 있는 환경이 마련된다[23]. 그런 접근 방법은 훌륭한 소프트웨어 엔지니어링 개발 관행으로 강하게 주창되어 왔으며 ‘응집력(cohesion)이 강하고, 결합(coupling)이 적으면, 구조적으로 안정된다’는 말로 요약된다[9].
소스 코드의 공유는 프리 소프트웨어 프로젝트에서 사용되는 설계, 구현 방법에 기여하는 중요한 요소이다. 소스 코드는 더 광범위한 프리 소프트웨어 커뮤니티에 의해 공유되며, 개발자들은 다른 사람의 소스를 읽음으로 학습을 하게 된다. 실제로 개발자들은 자신의 프로젝트를 시작하기 전에 다른 프리 소프트웨어 프로젝트에 대하여 연구한다. 이 연쇄적인 활동은 복잡한 소프트웨어를 어떻게 설계하고 구현할 것인가에 관한 이해를 돕는다. 또 이런 관행이 많은 프리 소프트웨어 프로젝트에 걸쳐 설계와 구현 스타일의 일관성과 호환성을 유지하게 했고, 유닉스 철학을 따르는 효과적인 방법이 되어왔다[29]. 상용 소프트웨어 개발에 있어서는 소스 코드가 기업 비밀 또는 경쟁의 원천으로 인식되어 회사들 사이에 이런 일이 일어나는 경우는 훨씬 적다.

4.4.3. 구현

시험 단계로 가기 전, 구현 단계에서 해야 하는 일은 기술적으로 적절하고, 그럴듯해 보이는 것을 만들어야 한다는 것이다[28]. 구현 과정에 필요한 상당한 도구들은 이미 만들어져 있다. 이는 소프트웨어 재사용과 도구의 지원이라는 유닉스 철학에 대한 강조 덕분이다[29]. 프리 소프트웨어가 주로 모듈 단위로 설계 및 구현되기 때문에, 소프트웨어는 여러 다른 라이브러리들로 분리되는 경우가 많다. 이 라이브러리들이 초기 구현에 필요한 기능들을 구현하기 위해 사용될 수 있다. 또 구현 과정에서 GNU autoconf나 GNU make와 같은 표준 도구들이 소프트웨어 개발을 용이하게 만든다. 이런 도구의 사용은 유닉스 철학 가운데 하나인 이식 가능성을 높이고,  많은 프리 소프트웨어 프로젝트의 소스가 공통적인 소스 기반에 포함되는 것을 보장한다. 또 개발 과정에 필요한 도구에 관한 지식이 덜 필요하기 때문에 개발자들이 다른 프로젝트들에서 쉽게 작업을 할 수 있도록 돕는다.

4.4.4. 시험

전이 단계로 가기 위해서는, 초기 구현 결과가 시험을 통해 안정화 된, 그럴듯해 보이는 결과물이 완성되어야 한다.
더 넓은 커뮤니티에 구현 결과가 릴리즈 되기 전에, 시험이 이루어진다. 이 과정을 얼마나 정교하게 할 것인지는 개발자가 결정한다. 보통 특별한 시험 도구나 회기 시험 기법과 같은 방법론은 사용되지 않는다[3, 20]. 대신, 개발자는 프로그램이 그들이 원하는 대로 동작하는지를 시험한다. 스스로 시험 결과에 만족하지 않으면 설계, 구현 단계로 되돌아간다. 만일 프로그램이 다른 사람들에게 공개할 수 있는 수준이고, 그로 인해 더 많은 개발자들을 끌어들일 수 있을 것이라는 확신이 생기면, 초기 구현 단계의 결과물은 릴리즈 되고 시장 단계로의 전이가 시작된다.

4.4.5. 배포

성당 단계에서는 배포와 프로젝트의 호스팅이 별로 중요하지 않다. 시장 단계로의 전이 과정에서 효과적인 배포 방법은 아주 중요하지만, 초기 구현은 한 명 또는 작은 규모의 팀에 의해 개발이 진행되기 때문이다. 이메일에 의한 개발자 간의 코드 공유 또는 한 웹사이트를 통한 공유로 충분하다. 또 SourceForge나 Savannah 같은 프리 소프트웨어 호스팅 사이트를 이용할 수도 있지만, 커뮤니티에 의한 리뷰가 중요해지기 전까지는 꼭 그렇게 할 필요는 없다.
처음부터 호스팅 사이트를 이용하는 것에 대하여는 찬반의 논란이 있다. 반대하는 측에서는 만일 개발자들이 프로젝트에 흥미를 잃었을 때, 호스팅 사이트는 점차 잠자는 프로젝트들이 많아져, 사용자나 개발자들이 활성화된 프로젝트를 찾는데 어려움을 겪게 될 수 있다고 주장한다. 반면에 호스팅 사이트를 이용하면 코드가 보존되어, 다른 사람이 잠자고 있는 프로젝트를 재건할 수 있는 기회를 맞을 수도 있다. 하지만, 대형 호스팅 사이트에서 활성화된 프로젝트를 찾기는 점점 더 어려워지고 있고, 잠자는 프로젝트와 활성화된 프로젝트를 효과적으로 구분하는 방법에 대한 필요성이 프리 소프트웨어 프로젝트 계의 이슈가 되고 있다.

5. 전이 단계

전이 단계에는, 특히 프로젝트 관리 방법에 있어서의 과감한 구조 조정이 필요하다. 성공적인 전이를 이루기 위해서는 여러 가지 문제들을 고려해야 한다. 첫째는 어떻게 코드를 배포할 것인가이다. 이 문제는 프로젝트 호스팅 사이트의 선택과 같은 프로젝트 인프라 문제와 관련되어 있다. 둘째는 어떤 라이선스를 채택할 것인가 이며, 이는 개발 과정에서의 기여자 참여와 그를 통한 시장의 형성에 영향을 준다. 셋째는 묵시적으로 결정되는 경우가 많지만, 관리 스타일의 선택이다. 이러한 문제들이 그림 5에 나와 있으며 다음 절들에서 자세히 설명된다.


<그림 5> 전이 단계에서의 구체적인 프로세스

5.1. 배포

적절한 시점에 전이를 시행하는 것은 성공적인 프로젝트를 위해 매우 중요하며, 이는 많은 프로젝트들이 극복하지 못한 장애물이기도 하다[11]. 자원자들이 이 전이 과정에서 모여들기 때문에, 프로토타입은 잘 동작해야 하며, 또 개선의 여지도 가지고 있어야 한다[16, 28, 2]. 만일 프로토타입이 충분한 기능을 가지고 있지 못하거나, 프로그램이 자주 멈추는 등, 안정적이지 못하면, 잠재적인 자원자들이 참여하지 않을 수도 있다. 한편, 프로토타입이 너무 완성도가 높으면, 코드 기반이 매우 복잡해져 있거나, 그들이 원하던 기능이 이미 구현되어 있기 때문에 자원자들이 그 프로젝트에 참여할 동기가 줄어들게 된다. 이러한 이유들 때문에, 프로젝트 창시자는 언제 프로젝트를 전이하여 다른 사람들에게 코드를 공개할 것인가를 심사숙고해야 한다.

5.2. 인프라

프로젝트 창시자가 적절한 전이 시점을 선택했다 해도, 프로젝트의 인프라와 관련하여 커뮤니티를 끌어들이는 것과 연관된 위험은 아직도 남아있다. 전이 과정에서 고려해야할 인프라와 관련된 세 가지는 소스 코드에 접근하는 방법, 프로젝트에 관한 의견 교환 수단, 그리고 라이선스의 선택이다.
첫째, 프로젝트와 연관된 인프라 가운데 반드시 변경되어야 할 부분은 커뮤니티에서 프로젝트에 참가하여 소스 코드에 접근할 수 있도록 만들어야 한다는 점이다. 소스 코드는 쉽게 접근 가능하며, 검토, 다운로드, 컴파일 할 수 있어야 하며, 궁극적으로 패치를 만들어 프로젝트 관리자에게 보낼 수 있어야 한다[31].
둘째, 프로젝트 내부의 통신 방법이 있어야 한다. 프로젝트의 주요 이슈에 관한 토론을 진행할 수 있는 커뮤니티 포럼이 프로젝트가 성공하기 위해 반드시 필요하다. 시장 단계에서 프로젝트 창시자에 의해 축적된 지식은 모든 프로젝트 협력자들과 공유되어야 한다. 큰 프로젝트들은 전형적으로 공지를 위해 관리가 되는 토론 공간과 사용자와 개발자를 위한 별도의 토론 공간을 가지고 있다. 커뮤니티 포럼의 좋은 예는 누구에게나 개방되어 있는 메일링 리스트이다. 이 메일링 리스트를 통해 개발자들은 설계와 구현에 관한 질문도 하고, 다른 개발자들이 검토할 수 있도록 패치도 게시할 수 있다[14]. 더 나아가 메일링 리스트와 그 메일을 모아놓은 것(archive)은 프리 소프트웨어 프로젝트에서 공식적인 문서를 대치할 수도 있다. 프리 소프트웨어 프로젝트에서는 보통 공식적인 요구 사항 명세나 설계 문서가 없으며 그런 정보는 메일링 리스트에서 얻을 수 있다. 또 자원자들이 프로젝트의 메일링 리스트에서 이전에 토론된 내용으로부터 질문과 그에 대한 답을 추려내어 FAQ (자주하는 질문과 답)을 만들어 내기도 한다.
셋째, 소스 코드는 잠재적 기여자들이 받아들일 수 있는 또 그 안에서 그들이 행한 수정과 개선 내용을 공유할 수 있는 라이선스를 가지고 배포되어야 한다. 이는 ‘프리 소프트웨어’ 또는 ‘오픈 소스’ [7, 25] 라이선스를 채택하는 경우, 명확하게 이해되는 가이드라인이 있기 때문에 문제가 되지 않을 것처럼 보이기도 하지만, 리눅스 커널과 관련된 코드의 일부를 비롯하여, 어떤 프로젝트에서는 이것이 문제가 되기도 한다. 여러 가지 라이선스들 간의 주요한 차이는 프리 소프트웨어가 상용 소프트웨어 또는 그의 일부로 이용되는 경우의 조건이다. 비공개 상용 소프트웨어를 포함한 여러 가지 소프트웨어의 분류에 관한 개괄적인 내용은 http://www.gnu.org/philosophy/categories.html에서 볼 수 있다. 적절한 라이선스는 프로젝트의 성격에 달려있으며, 프로젝트 창시자가 주의 깊게 고려해야할 사항이다.

5.3. 관리 스타일

프로젝트 관리 방법과 그와 관련된 기준들은 자원자들의 프로젝트 참여를 돕는다. 전이 단계에서 바꿔야 하는 가장 중요한 것이 이 관리 방법이다. 성당 단계에서, 프로젝트 창시자와 핵심 멤버들은 모든 결정을 그들 스스로 한다. 시장 단계에서는 프로젝트 창시자가 모든 개발 과정을 공개하고, 다른 사람들이 프로젝트에 참여할 수 있도록 허용한다. 즉 다른 개발자들의 참여가 독려되고, 그들의 기여 내용이 받아들여지며 보상된다. 보상의 형태는 기여자의 개선 내용이나 수정 내용이 프로젝트에 반영되어 새로운 버전이 릴리즈 되는 것이다. 이 방법으로 개발자들은 자신의 기여가 유용한 것이라는 것을 알게 되고, 프로젝트에 계속 참여하게 된다. 또 이와 관련하여 다른 중요한 요소는 그들의 기여를 기록하는 것이다. 즉, ‘THANKS’ 파일 등에 기여자들의 이름이 눈에 보일 수 있도록 적절히 감사를 표시하는 것이다 ('README' 파일처럼, 프로젝트의 전체 묶음 파일 (tar)의 최상위 디렉토리에 ‘THANKS' -모두 대문자로- 파일을 두는 것이 이제 전형적인 방법이 되었다. 이와 같은 류의 파일에는 COPYING, NEWS, TODO 등이 있다.)
.
불행히도, 다른 사람들의 참여를 유도하기 위하여 관리 방법을 변경하는 일은 쉽지 않다. 새로운 관리 방법을 도입하여 다른 사람들이 방향을 결정하는 것은 자신이 프로젝트의 제어권을 가진다는 것과 상충되기 때문이다. 성당 단계에서 시장 단계로의 전이 과정에서 프로젝트 소유권에 관한 모든 개념은 변경된다. 성당 단계에서는 프로젝트가 프로젝트 창시자에 의해 주도되었지만, 이 권한은 전이 단계에서 약화되고, 점차 그 소유권이 커뮤니티로 옮겨간다. 프로젝트 창시자의 성격은 성당 단계의 소유권자 자격에서, 어떤 설정된 기준에 의거하여 다른 사람들의 코드를 통합하는 주 관리자 자격으로 바뀐다. 그 설정된 기준을 공개한다면 관리는 더 투명해지고, 자원자들에게 더 좋은 인상을 남길 수 있다. 시장 단계에서 프로젝트가 관리되는 스타일은 매우 다양하며 그 다양한 관리 방법 가운데 양 끝단에 있는 두 프리 소프트웨어 프로젝트의 예를 보인다.
첫 번째는 엄격한 스타일이다. 리눅스 커널의 관리는 상대적으로 엄격한 관리를 하는 스타일이다. 이런 관리 스타일을 가지게 된 것은 프로젝트가 가진 기술적 위험 때문이다. 커널에서는 기능이 변경되거나 부풀려지는 것을 피하고, 커널과 사용자 공간의 명확한 분리를 유지하는 것이 매우 중요하다. 리눅스의 자비로운 독재자인 리누스 토발즈의 주 역할은 코드를 승인하는 것보다는 거부하는 것이다[22]. 이런 경우 프로젝트의 범위를 정확하게 유지하기 위하여, 누군가 중심이 되어 프로젝트를 관리하는 것이 유리하다.
두 번째는, 느슨한 스타일이다. 리눅스와는 상반되게 KDE는 많은 다양한 분야에서 기능 향상 및 추가가 바람직하면서도 요구되는 환경이다. 또 리눅스 커널과 달리 기능의 변경이나 확장에 대한 위험이 적다. 이것은 많은 사람들이 많은 서로 간의 의견 교환 없이도 여러 다른 분야에서 각자 작업을 할 수 있다는 것을 암시한다. 이런 경우에는 독립적이면서도 계층이 없는 관리 방법이 잘 동작한다.
시장 단계에서 사용할 수 있는 관리 스타일은 다양하다. 그렇지만 그들 모두가 가지고 있는 중요한 공통점이 있다. 첫째, 다른 개발자들의 기여가 독려되며, 버그 발견 수준이라 하더라도 모든 자원자가 환영받는다. 둘째, 자원자들은 자신이 기여한 것의 효과를 빠르게 확인할 수 있다. 셋째, 프로젝트 창시자는 완전한 프로젝트 소유권을 포기하고 프로젝트의 나아갈 바를 커뮤니티에 맡긴다. 이런 관리 스타일이 실현되기 위해서는, 자원자들이 자신이 만든 것을 기꺼이 공유할 수 있도록 하는 공개적인 인프라와 라이선스가 필요하다.

6. 결론

프리 소프트웨어는 최근에 많은 관심을 끈 현상이다. 시장 단계에 이른 몇몇 프로젝트들은 충실한 기능과 품질로 인정받고 있으며, 버그 보고, 기능 요구, 버그 수정, 기능 추가 등의 방법으로 소프트웨어의 기여하는 많은 수의 자원자들이 모이고 있다. 그렇지만 어떻게 한 프로젝트가 커뮤니티를 이루고 성공할 수 있는지에 관한 설명은 없었으며, 이 논문의 프리 소프트웨어 생명 주기 모델이 그 부분을 채우고 있다.
이 글에서는 프리 소프트웨어 프로젝트의 생명 주기를 세 단계로 설명했다. 첫 번째 단계는 에릭 레이몬드의 저서에 따온 이름을 가진 성당 단계로, 전통적인 소프트웨어 개발에서와 같이 소규모 그룹 또는 개발자에 의해 폐쇄적인 개발 작업이 수행되는 단계이다. 두 번째 단계는 전통적인 개발 방식에서 커뮤니티 개발 방식으로 옮겨가는 전이 단계이다. 오직 명확한 특성을 가진 프로젝트들만이 성공적으로 전이 단계를 넘어설 수 있다.
시장 단계에서 성공하기 위해서는 다음 몇 가지 사항들이 완료되어야 한다. 1번부터 6번까지는 필수적이며, 7번에서 11번까지는 중요하며, 마지막 12번은 있으면 바람직한 것이다.

1. 그럴듯해 보이는 프로토타입이 완성되어 있어야 한다.
2. 프로토타입의 설계는 반드시 모듈화되어 있어야 한다.
3. 프로토타입의 모든 소스 코드는 공개되어야 하며, 컴파일 되어 실행될 수 있어야 한다.
4. 사용자와 개발자 커뮤티니의 관심을 끌 수 있어야 한다.
5. 프로젝트 창시자는 프로젝트 관리에 대한 동기 부여가 되어있어야 하며, 그렇지 않다면 대안을 찾아야 한다.
6. 프로젝트에 대한 기여 방법과 의견 교환 방법이 마련되어야 한다.
7. 프로젝트의 범위가 잘 정의되어 있어야 한다.
8. 코딩 표준 또는 스타일이 정해져 있어야 한다.
9. 사용자 버전은 안정적이고 일관성이 있어야 하며, 개발자 버전 소프트웨어는 짧은 릴리즈 주기를 가져야 한다.
10. 개발자들이 선호하는 라이선스를 가져야 한다.
11. 적절한 관리 스타일이 선택되어야 한다.
12. 적정 수준의 프로젝트 문서가 있어야 한다.

마지막 단계는 프로젝트가 커뮤니티 프로젝트가 되어 여러 이득을 얻게 되는 시장 단계이다. 이 논문에서 제안된 생명 주기 모델이 프리 소프트웨어의 발달 단계에 대한 이해를 돕고, 그들의 성공을 도울 수 있을 것을 기대한다.
이글을 리뷰해 준 Damien Wilmann 과 Dr. June Senyard에게 감사를 표한다.

참고문헌

[1] R. Fielding A. Mockus and J. Herbsleb. A case study of open source software development: the apache server. In Proceedings of the 22nd International Conference on Software Engineering (ICSE 2000), pages 263–272, Limerick, Ireland, June 2000. ACM Press.
[2] B. Arief, C. Gacek, and T. Lawrie. Software architectures and open source software – where can research leverage the most? In 1st Workshop on Open Source Software Engineering. ICSE, 2001.
[3] U. Asklund and L. Bendix. Configuration management for open source software. In 1st Workshop on Open Source Software Engineering. ICSE, 2001.
[4] M. Bergquist and J. Ljungberg. The power of gifts: Organising social relationships in open source communities. Information Systems Journal, 11(4):305–320, 2001.
[5] F. P. Brooks, Jr. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley Publishing Company, 2nd edition, 2000.
[6] A. Capiluppi, P. Lago, and M. Morisio. Evidences in the evolution of OS projects through changelog analyses. In 3rd Workshop on Open Source Software Engineering. ICSE, 2003.
[7] Debian Free Software Guidelines. http://www.debian.org/social_contract.
[8] C. DiBona, S. Ockman, and M. Stone, editors. Open Sources: Voices from the Open Source Revolution. O’Reilly, Sebastapol, CA, 1999.
[9] A. Endres and D. Rombach. A Handbook of Software and Systems Engineering. Pearson Addison Wesley, Harlow, England, 2003.
[10] M. E. Fagan. Design and code inspections to reduce errors in program development. IBM Systems Journal, 15(3), 1976.
[11] K. F. Fogel. Open Source Development with CVS. TheCoriolis Group, 1st edition, 1999.
[12] The FreeBSD project. http://www.freebsd.org/.
[13] R. Ghosh. Clustering and dependencies in free/open source software development: Methodology and tools. First Monday, 8(4), April 2003.
[14] T. J. Halloran and W. L. Scherlis. High quality and open source software practices. In 2nd Workshop on Open Source Software Engineering. ICSE, 2002.
[15] P. Himanen. The Hacker Ethic and the Spirit of the Information Age. Secker & Warburg, London, 2001.
[16] K. Johnson. A descriptive process model for opensource software development. Master’s thesis, Department of Computer Science, University of Calgary, 2001. http://sern.ucalgary.ca/students/theses/KimJohnson/thesis.htm.
[17] N. Jørgensen. Putting it all in the trunk: Incremental software engineering in the FreeBSD Open Source project. Information Systems Journal, 11(4):321–336, 2001.
[18] M. M. Lehman. Programs, life cycles and the laws of software evolution. Proceedings of the IEEE, 68(9):1060–1076, September 1980.
[19] C. Letondal and U. Zdun. Anticipating scientific software evolution as a combined technological and design approach. In Proceedings of USE2003, 2003.
[20] B.Massey. Why OSS folks think SE folks are clue-impaired. In 3rd Workshop on Open Source Software Engineering. ICSE, 2003.
[21] Bart Massey. Where do open source requirements come from (and what shold we do about it)? In 2nd Workshop on Open Source Software Engineering. ICSE, 2002.
[22] R. McMillan. Kernel driver. Linux Magazine, September 1999.
[23] M. Michlmayr and B. M. Hill. Quality and the reliance on individuals in free software projects. In 3rd Workshop on Open Source Software Engineering. ICSE, 2003.
[24] A. Oram and M. Loukides. Programming With GNU Software. O’Reilly, Sebastopol, CA, 1997.
[25] The Open Source Definition. http://www.opensource.org/docs/definition.php.
[26] M. O’Sullivan. Making copyright ambidextrous: An expose of copyleft. The Journal of Information, Law and Technology, 3, 2002.
[27] C. Payne. On the security of Open Source software. Information Systems Journal, 12(1):61–78, 2002.
[28] E. S. Raymond. The Cathedral and the Bazaar. O’Reilly, Sebastopol, CA, 1999.
[29] E. S. Raymond. The Art Of Unix Programming. Addison-Wesley, 2003.
[30] D. C. Schmidt and A. Porter. Leveraging open-source communities to improve the quality & performance of opensource software. In 1st Workshop on Open Source Software Engineering. ICSE, 2001.
[31] M. Shaikh and T. Cornford. Version management tools: CVS to BK in the Linux kernel. In 3rd Workshop on Open Source Software Engineering. ICSE, 2003.
[32] I. Sommerville. Software Engineering. Addison-Wesley, third edition, 1989.
[33] I. Stamelos, L. Angelis, A. Oikonomou, and G. L. Bleris. Code quality analysis in Open-Source software development. Information Systems Journal, 12(1):43–60, 2002.
[34] L. Torvalds. The linux edge. In C. DiBona, S. Ockman, and M. Stone, editors, Open Sources: Voices from the Open Source Revolution. O’Reilly, Sebastapol, CA, 1999.
[35] P. Vixie. Software engineering. In C. DiBona, S. Ockman, and M. Stone, editors, Open Sources: Voices from the Open Source Revolution. O’Reilly, Sebastapol, CA, 1999.

저작자 표시 비영리 변경 금지
신고
Posted by 이민석 hl1itj