Month: October 2005

일반적인 오픈소스 프로젝트는 아무래도 여가시간에 자발적으로 참가하는만큼 프로젝트 진행 방향에 있어서 기업 프로젝트에서와 같이 “데드라인 엄수”, “최저 생산가”, “최고의 속도”, “가장 완벽한 인터페이스”가 아니라, 그저 “개발자의 재미”가 최고의 가치로 작용합니다. 완벽한 UI를 만들면 재미있는 개발자들은 완벽한 UI를 만들고, 표준을 완벽하게 엄수하는 것으로 재미를 느끼는 개발자들은 표준을 어기는 코드가 있으면 길이길이 날뛰면서 표준에 맞게 고쳐서 패치를 내겠지요. (토끼군처럼 남이 못 알아보도록 짜는 것에 재미를 느낄 수도 있고.. =3=3) 재미가 오픈소스 프로젝트의 가장 큰 요소인 것은 너무나 당연함에도 불구하고, 그동안 정부의 오픈소스 정책이나, 오픈소스를 추종하는 사용자들, 체계적인 체제를 갖추지 않은 오픈소스 프로젝트 들에서는 많이 간과되어 왔습니다.

최근 《재미와 소프트웨어 개발》이라는 논문이 나왔습니다. 이 논문에서는 주로 오픈소스 프로젝트들을 예를 들어서, 개발자들에게 개발의 재미를 주는 요소들과, 프로젝트 생산성, 창의성의 관계에 대해서 살펴보고 있습니다. 작업의 명료성, 재미, 충동, 주의, 집중 등이 프로젝트 결과에 영향을 주는 요소로 재미있게 분석되어 있습니다. 🙂

Haskell로 구현된 Perl6 프로젝트인 pugs 개발자가 쓴 O’Reilly 기사에서 얘기하고 있는 pugs의 -Ofun 성공 비결은 이렇게 요약하고 있습니다. (각 조건의 설명은 원문을 참조하세요.)

• -Ofun을 프로젝트 최우선 최적화 조건으로 삼아라.
• 현대적인 분산형 버전 컨트롤 시스템을 사용하라.
• 커밋이 허용되는 개발자들을 최대한 늘리고 커밋을 쉽게 하는 무정부주의를 지향하라.
• 빌드가 깨지거나 개발을 방해하는 데드락을 피하라.
• 커미터 권한을 많은 다양한 사람들에게 주어라.
• 돌아가는 코드가 아이디어보다 낫다.
• 끈끈하고 도움을 주는 개발자 커뮤니티를 만들자. (예: 신규 개발자들에게 멘터링을 해주는 방식)
• 흥미와 배움은 전염된다.

기업이 투자하는 것이 아니라면, 오픈소스 프로젝트가 성공하기 위해서는 리더들은 무엇이 개발자들에게 개발 동기를 유발하는가를 고려하여 그 점들을 자극할 수 있는 무언가를 충분히 재공해 줘야할 듯 합니다. 주변의 예만 보더라도, FreeBSD의 버그 트래킹 시스템인 GNATS는 웹에서 접근할 수 있는 개발자 리소스가 제한되어 있기에, 버그 트래킹 시스템에 접근하려면 ssh로 중앙 서버에 접속해야하고, 그 과정이 미미하지만 동기 요소를 떨어뜨리는 요소로 작용하게 마련입니다. 그래서 FreeBSD 버그 트래킹 시스템에서는 유난히 오래된 버그들이 많고 개발자들이 할당만 해놓고 거들떠보지도 않는 경우가 많습니다. 또한, 코드를 직접 커밋해서 다른 사람들이 리뷰할 수 있는 경우와, 최근 CVS로 업데이트한 다음에, diff를 떠서, 복잡하게 버그 트래킹 시스템에 올린 다음에, 커미터에게 리뷰를 받아서 다시 또 설명을 한 다음에 결국 한참 있다가 커밋되는 것과는 피드백의 시간에 있어서 동기 유발에 큰 차이를 보이겠지요.

그나저나, 저 오라일리 글의 “bus error” 표현은 아주 재미있군요. 이히히히~

Worse yet, a “bus error” (a key person being hit by a bus) may stall the project for good.