오픈소스 개발 모델의 장점을 여러분이 속한 조직이 알게 되면서, 직접 오픈소스 프로젝트를 시작하기로 결정했을지도 모릅니다. 사려깊은 계획이, 빨리 잊혀지는 실패와 번창하면서 지속되는 코드베이스의 차이를 만듭니다. Linux Founation 가이드에서는 그 과정에 대해서 자세히 설명하며, 포괄적인 오픈소스 프로젝트 시작에 관한 체크리스트를 제공합니다. 앞 절들에서 설명한 모든 원칙들이 적용되며, 좀 더 고려할 만한 사항들이 이 절에서 설명될 것입니다.
법무팀에서는 앞으로 회사 내부에서만 사용하기 위하여 비공개로 개선할 것인지를 포함하여, 코드를 어떻게 활용할지를 파악하고 있어야 합니다. 라이선스의 선택은 다른 회사나 개인들이 그 소프트웨어의 채택 여부에 대한 결정뿐만 아니라 회사 내에서의 사용에도 영향을 줍니다. 그렇기에, 라이선스는 회사의 비지니스 전략을 고려해서 결정해야 합니다.
그럼에도 불구하고, 팬시한 라이선스를 채택할 필요는 없습니다. 이 책의 앞 부분에서 몇 가지의 유명한 라이선스를 소개하였습니다. OSI(Open Source Initiative)에 보면 많은 오픈소스 라이선스가 나열되어 있기는 하지만, 그 중에서 잘 알려져있고 최신에 만들어진 라이선스를 선택할 것을 강력하게 권합니다. GitHub은 잘 만들어진 라이선스 선별 가이드를 제공하고 있습니다. 마음에 맞는 라이선스를 찾을 수 없다면, 오픈소스로 프로젝트를 진행하는 동기를 다시 한번 진지하게 생각해 보십시오. 만일 잘 알려진 라이선스를 사용할 수 없다면, 오픈소스의 원칙과는 다른 방향으로 프로젝트를 진행하려고 하기 떄문일 가능성이 있으며, 그로 인하여 우리가 프로젝트에 끌어들이고 싶었던 사람들을 떨어져나가게 할 수 도 있습니다.
코드의 첫번째 라인을 작성하기 전부터 공개된 코드 저장소를 만들고 회사 외부에 참여를 요청하는 것이 가장 좋습니다. 그렇지 않으면 공개되서는 안되는 내용들과 낯 뜨거운 코멘트들을 제거하기 위한 철저한 코드 리뷰 전까지는 코드를 공개할 수 없을 것입니다. "오픈소스 퍼스트" 방식으로 처음부터 코드를 공개하면 개발자들이 최상의 코딩 방법을 따르게 될 것입니다.
프로젝트 이름은 커뮤니티와 공감할 수 있도록 선정하십시오.
이름은 아주 개인적일 수도 있고(예 : Linux는 운영체제 작성자의 이름을 따서 명명됨), 오피스 소프트웨어인 [LibreOffice] (https://www.libreoffice.org/)처럼 소프트웨어를 설명할 수 있는 것도 좋습니다.
마스코트의 이름을 따서 짓기도 하고 기억하기 쉽도록 의미없는 단어를 쓰기도 (예 : Hadoop) 합니다.
법무팀이 상표에 대해 수행하는 것과 동일한 수준의 조사와 확인을 거쳐, 같은 이름이 존재하지 않으며, 어떤 언어에서는 나쁜 의미를 가지지 않는 이름을 선택합니다.
프로젝트 및 브랜드 홍보에 대한 정보는 아래 '프로젝트 소통' 절을 참조하십시오.
오픈소스 개발 방식을 따르지 않고 내부 팀 작업에 익숙한 사람들이 만든 첫 번째 공개 코드는 지저분할 수 있습니다. 완성도가 낮은 코드를 공개하는 것은 개발자와 관리자 모두 수용하기 어려울 수 있습니다. 그러나 이미 진행된 내용과 커뮤니티로부터의 도움이 필요한 사항을 문서화하고, 프로젝트를 완성하겠다는 점과 새로운 사용자에 대한 멘토링을 약속하면 커뮤니티로부터 보상을 받게 됩니다. 당신이 좋은 아이디어를 가지고 있다면 많은 사람들이 손을 내밀어 같이 문제를 해결해 줄 것이고, 아이디어가 좋지 않다면, 외부로부터 좋지 않은 반응들이 들릴 것이며, 더 이상 개발자 시간을 낭비하지 않고 프로젝트를 포기할 수도 있습니다.
공개 리파지토리에 코드와 문서를 저장하거나, 당신이 사용하는 버전 관리 시스템을 누구나 접근하게 설정해도 됩니다. 개발자가 매일 또는 필요한 만큼 자주 변경 사항을 적용할 수 있게 하십시오. 개발자들은 이 방법을 "release early, release often"이라고 부릅니다. 오픈 소스 커뮤니티에서 모범 사례로 간주되는 지속적 통합(Continuous Integration) 및 회귀 테스트(Regression Test)로 개발자가 잘 되던 것을 망가뜨리지 않도록 해야합니다. 대부분의 프로젝트는 아직도 안정성을 보장하기 위해 (특히 주요 기업 사용자들에게) 공식 릴리스를 제공하기도 하지만 오픈소스에서는 끊임없는 피드백과 개선을 허용합니다.
프로젝트에 관한 결정 과정을 숨긴다면 사람들이 프로세스를 존중하거나 프로젝트에 기여하는 것을 기대하기 어려울 것입니다. "열린 소통 문화의 장려" 절에서 설명한 것처럼, 회사 안의 개발자들은 이제 기대하건대 회사 외부의 프로젝트로 커가는 더 큰 커뮤니티의 한 부분이 될 것입니다. 단순한 메일링 리스트 하나면 충분할 수도 있습니다. 토론에 사용하는 모든 도구들은 공개되어야 하며, 그 도구들 자체도 자유 오픈소스 소프트웨어로 만들어져야 하는 등, 참여를 막는 장벽을 두지 말아야합니다.
프로젝트를 시작할때 당신의 코드와 조직의 설립에 익숙하지 않은 사람들을 끌어모으는 것이 매우 중요합니다. 프로젝트가 잘 안착된 이후라고 해도 그것은 중요합니다. 이미 몇 년동안 참가한 사람들만 이해하는 편협한 문화 안에서만 떠다니면 안됩니다. 새로운 사람들을 프로젝트에 끌어들이기 위하여 지속적으로 다음과 같은 활동에 자원을 투입해야합니다:
문서화
빠르게 시작하기 (Getting Started) 안내서부터 당신의 프로젝트가 무엇이 특별하고 가치있는지를 설명하기 위한 기술적 구조 설명까지를 포함합니다. 코드를 기여하기에는 스킬이 부족한 많은 사람들은 문서를 작성하는 기여를 좋아할 가능성이 높으므로, 그런 사람들을 찾아, 프로젝트에 데려와 참여시켜야 합니다.
컨퍼런스와 코더톤(code-a-thons)
이 활동은 당신의 의지를 커뮤니티에 보여주며 열정을 불러일으킵니다. 많은 사람들이 이런 행사에 참가하고 난 뒤에 장기적인 기여자가 됩니다. 그래서 이런 행사는 새로운 기여자들을 확보하고 기존 기여자들이 더 많은 것을 할 수 있도록 격려할 수 있는 하나의 좋은 방법입니다. 또 이런 행사을 통해 주요 결정 사항들에 대하여 더 넓은 커뮤니티의 의견을 들을 수 있습니다. 참여하는 것 뿐만 아니라 이벤트를 준비하는 과정에도 커뮤니티의 참여를 유도하는 것이 좋습니다. 회사의 공간에서 피자와 샌드위치 정도를 제공하는 지역 밋업(meetup)은 비용이 적게들면서도 강력한 커뮤니티를 만들 수 있게 합니다.
행동 강령
프로젝트를 시작할 때 부터 존중이라는 것을 주요 가치로 설정하십시오. 너무나 당연하게 들릴지라도, 글로 쓰여진 행동 강령은 매우 중요합니다. 사람들이 무례하거나 독설을 할 때 프로젝트 리더들이 빠르게 개입하여 정리하여야 합니다. 심지어 단 한번의 이슈가 잠재적으로 많은 사용자들을 떠나게 할 수 있습니다. 만약 다양한 젠더나 다른 그룹들을 기꺼이 수용하지 않는다면 재능이 있는 큰 그룹에서 프로젝트 참여자를 찾을 수 있는 기회를 어쩌면 영원히 잃게 될 것입니다. 그리고 또한 나쁜 평판은 당신의 조직에도 영향을 끼칩니다.
해야할 일 목록
사람들이 어느 정도 코드를 사용해 왔다면, 그들은 어떤 일이 도움이 될지를 물어보기 시작합니다. 프로젝트에 대하여 당신과 커뮤니티의 다른 회원들이 우선순위에 입각하여 만든 명확한 할 일 목록을 제공하여야 합니다.
얼마나 많은 시간을 커뮤니티에 쏟을 수 있을지를 개발 단계 별로 가늠해야합니다. 바라건대 다른사람들이 할 일을 고르고 질문에 답변하기 시작할 것입니다. 그러나 궁극적으로는, 사용자들이 원하는 기능을 추가하고, 목소리를 내도록 해야합니다. 사용자들의 요구를 진지하게 받아들이지 않는다면 그들을 잃게될 것이기 때문입니다. 커뮤니티 매니져를 두는 것은 좋은 투자입니다. 직원 가운데 한 사람이 회사 직원들과 외부 커뮤니티 사람들에게 어떻게 프로젝트의 진행을 부드럽고 생산적으로 도울 수 있을지에 대해서 교육할 수 있을 것입니다. 프로젝트가 크게 성장하고 널리 채택되면, 독립적인 관리 조직를 가진 단체로 프로젝트 통제권을 넘겨줄 때가 올지도 모릅니다. 이에 대한 설명은 바로 다음장 "독립된 관리 조직에 프로젝트 릴리즈하기" 절에서 다뤄집니다.
커뮤니티를 잘 운영하기 위한 방법에 대한 심도있는 설명이 필요하다면 Jono Bacon의 책 The Art of Community (O'Reilly, 2012)가 매우 유용할 것입니다.
보통 주요 이벤트에 대한 보도에 집중하는 홍보 활동과 달라서 커뮤니티와의 소통은 그 이상을 필요로 합니다. 회사라면 커뮤니티와 전 세계가 프로젝트의 각 단계별로 그 이전, 진행 중 및 그 이후의 진화에 대해 알기를 원할 것입니다. 직원들이 블로그에 글을 게시하거나 소셜미디어를 활용하여 새로운 소식을 전하도록 독려해야 합니다. 커뮤니티 내의 누군가가 적어도 2 주일에 한 번 이상은 (큰 프로젝트의 경우 더 자주) 정기적인 트윗을 반드시 해야한다고 정할 수도 있습니다. 커뮤니티 멤버들이 노트북 컴퓨터나 양말 및 티셔츠 등에 붙일 수 있는 스티커를 만드는 것과 같은 작은 브랜드 투자는 프로젝트에 대한 자부심을 드러내고, 참여를 하면 좋겠다고 생각하는 사람들이 볼 수 있도록 프로젝트 이름을 알리는데 도움이 됩니다. 이런 활동은 새로운 사용자를 유치하고 기존 커뮤니티 멤버들에게 이 프로젝트가 활발한 활동을 하는 프로젝트 임을 상기시킵니다.
데이터가 주도하는 사회입니다. 모든 조직은 의미있는 측정 데이터를 수집하는 방법을 배워야하며, 데이터에 기반한 의사 결정 방법을 직원들에게 가르쳐야합니다. 일부 측정 데이터는 다른 것들보다 모으기 쉽기 때문에, 측정 기준을 정할 때는 실제로 사용자들에게 유용한 것이 무엇인지를 고려하여야 합니다. 따라서 먼저 다양한 측정 데이터를 모은 뒤에, 시간을 두고 어떤 측정 기준이 정말 유용한 지를 찾아내어 줄여나가야 합니다. 일반적인 측정 기준들은 다음과 같습니다:
- 기여자 수와 기여 수, 어떤 사람인지, 소속이 어디인지
- 다운로드 수, 메일링 리스트 참여자 수, 다른 간접 데이터 등을 이용하여 통계적으로 산출 가능한 사용자 수
- 기여자 메일링 리스트 참여자 수의 증가 혹은 감소
- 제보된 이슈 및 버그의 수와 해결된 수
- GitHub의 포크 수 및 스타 개수
- 프로젝트의 웹 페이지, 블로그 방문자 수, 프로젝트와 관련된 트윗 수
CHAOSS 커뮤니티에선 대부분의 프로젝트에 적용 가능한 측정 기준 들을 정의합니다.
보통 측정 결과가 더 높게 나오기를 원할 겁니다. 심지어 버그리포트가 늘어나는 것도 좋은 일 입니다. 이는 코드가 그만큼 유용하다는 뜻이며, 오히려 버그 해결 속도가 더 중요한 측정 기준이 될 수 있습니다. 만약 PR(Pull Request)이 들어오는 횟수가 점점 줄어든다면, 프로젝트를 홍보하거나 프로젝트를 더 매력적으로 만들어 줄 새 기능을 추가하기 위한 작업을 시작해야할 때임을 의미합니다.
대부분의 기여가 소수의 조직에서만 오고 있다면 다양성을 확보하기 위한 노력이 필요합니다. 코드가 한 두 명의 주요 사용자에게 맞춰서 최적화 될 경우, 다른 잠재적 사용자들을 잃을 수 있습니다. 그리고 그 주요 기여자가 갑자기 그만두게 되면 중요한 지원이 끊어지는 사태를 맞게 됩니다.
측정 기준은 상황에 따라 달라질 수 있습니다. 예를 들어, 꼭 필요한 몇몇 사람들을 위한 좁은 응용 범위의 프로젝트에서는 PR 수나 커뮤니티 참여가 안정적으로 유지된다 해도 문제가 없습니다.
측정 결과는 지속적인 개선 과정의 일부가 될 수 있습니다. 관리자가 이 결과를 대시보드로 볼 수 있게 하여 회의나 향후 작업의 우선 순위를 결정하는데 참고할 수 있게 하십시오. 거의 모든 소프트웨어와 마찬가지로, 측정 기준을 표시하는 대시 보드 및 시각화에 적합한 좋은 오픈소스 툴들이 존재합니다. Bitergia는 오픈소스 대시 보드를 제공하고, Amazon은 자신들의 오픈소스 관리부서에서 프로젝트를 관리하는 데 사용하는 OSS attribution builder와 OSS contribution tracker를 공개하였습니다.
여러분이 이 책의 조언들과 제시된 참고 자료의 내용을 잘 따라왔다고 가정해 봅시다. 여러분의 프로젝트는 성공한 것처럼 보일 것이며, 조직 외부사람들에게도 알려지고 채택될 겁니다. 프로젝트가 커지고 충분히 안정되면, 프로젝트를 회사로부터 독립시키는 것이 중요합니다. 이는 다른 조직들이 재정적으로, 혹은 다른 방법으로 그 프로젝트를 더 잘 지원할 수 있게 만듭니다. 또 이를 통해서 해당 프로젝트가 지속성 있고, 프로젝트의 미래에 대한 의사결정이 특정 회사의 경영적 판단에 의존하지 않을 것임을 세상에 알리는 길이기도 합니다. 그럼으로써 더 많은 사람들이 프로젝트를 사용하고, 기여할 것입니다. 하지만 그 프로젝트를 위해 독립적인 재단을 설립하는 것은 일이 매우 많아서, 정말 재단 설립이 중요한지에 대한 명확한 이유, 즉 주요 기여자들의 요청이나 외부의 조직에서 자금을 모아야 할 필요가 생긴 후에 진행하는 것이 좋습니다.
재단을 세운다는건 복잡한 일입니다. 물론 Linux, Mozilla, OpenStack 등 몇몇 주요 프로젝트는 독립 재단을 세웠지만, 대부분의 오픈소스 프로젝트는-Spark 데이터 처리 툴 등의 유명한 툴도 포함해서-기존 재단의 후원 하에 있습니다. Apache 소프트웨어 재단, Eclipse 재단, Linux 재단 등은 자신들의 원래 미션을 뛰어넘는 매우 다양한 소프트웨어를 후원합니다. 그밖에도 헬스케어 분야의 HL7이나 자동차 분야의 Automotive Grade Linux 등과 같이 특정 산업 영역만을 지원하는 조직들도 있습니다.