프로젝트를 오픈 소스로 진행하기 전에 확인해야할 사항 I
VM (Vicky) Brasseur
여러분의 기업이 프로젝트를 오픈 소스로 진행하기 이전에, 추진 이후 형성될 커뮤니티의 새로운 책임들에 대해서 여러분이 준비가 되어 있는지 확인해야 한다.
여러분의 기업은 내부 프로젝트 진행을 오픈 소스로써 공개할 예정이다. 축하합니다! 여러분의 코드가 준비되어 있지만 여러분은 향후 발생할 새로운 책임들에 대하여 과연 준비가 되어 있나요?
프로젝트가 오픈 소스로써 대중들에게 공개가 된다면, 여러분의 기업은 프로젝트 뿐만 아니라 이로 인하여 만들어질 커뮤니티에 대한 책임도 주어지게 된다. 해당 부분은 흔히 개발, 빌드 그리고 작업 흐름에 대하여 공개가 요구된다. 이것은 코드 자체에 대한 것이 아니지만 이는 오픈 소스 프로젝트를 성공적으로 완성해줄 코드와 관련된 모든 절차들과 인프라들에 대한 것이다. 여러분의 오픈 소스 프로젝트를 공개하기 이전에 여러분이 숙지해야 하는 것은 다음과 같다.
여러분의 기업 목표들을 확인해라.(Identify your company's goals.)
여러분이 보다 많이 진행하기 이전에, 우선 프로젝트 공개를 위해 여러분의 기업 목표를 검토해야 한다. 기업은 많은 시간과 노력을 이번 공개에 투자를 할 것이며 프로젝트와 관련되어 형성되는 커뮤니티를 유지하기 위해서 보다 많은 것을 투자해야 할 것이다. 이러한 노력들이 이타적일 수도 있는 반면에, 기업은 투자에 상응하는 무엇인가를 기대하고 있을 가능성이 높다. 프로젝트와 커뮤니티에 착수하기 이전에 여러분이 목표들을 자세히 알고 있는지 확인하여야 한다. 여러분의 기업이 이를 달성 할 수 있도록 조치를 취하는 것은 기업을 도와줄 뿐 만 아니라 전반적으로 오픈 소스 소프트웨어를 도움이 되는 것이기도 하다. 오프 소스 프로젝트를 하면서 기업의 목적들을 달성하지 못하거나 목표를 파악하지 못하는 기업들은 전적으로 FOSS 참여를 완전히 중단하게 되며 이는 누구에게도 이익이 되지 않는다.
커뮤니티의 기대를 파악하여라.(Understand community expectations.)
여러분이 기업의 성공에 대한 열쇠를 쥐고 있으며 병합에 대한 기여와 공개를 언제 할지 결정할 수 있지만, 모든 개발은 공개적 방식으로 이루어져야 하며 관계로 형성되는 커뮤니티의 협조로 이루어져야 한다. 즉, 프로젝트는 오픈 소스 프로젝트에 대해 형성된 커뮤니티의 기대를 기반으로 반드시 운영 되어야 한다. 이러한 기대치들은 다음과 같다(하지만 이에 국한되지는 않는다):
○ 프로젝트들과 관련된 버그 수정, 새로운 기능 구현, 제품 계획안, 그리고 논의와 이슈 확인들을 포함한 모든 개발 작업들은 공개적으로 커뮤니티의 협력과 함께 진행되어야 한다.
○ 코드와 관련된 모든 구축 과정들은 (지속적 통합/전개, 등) 공개적으로 운영되어야 하며 커뮤니티가 접근 할 수 있도록 구축되어야 한다.
○ 기업은는 “기여”의 의미가 단지 코드뿐만이 아니라 프로젝트에 관련된 서류, 디자인, 제품 계획안 안내, 관리, 그리고 다른 사항들을 포함한 커뮤니티로부터 기부금을 수령한다. 모든 기부들은 지체 없이 검토되어야 하며, 이에 상응하는 응답은 공개적으로 제공하여야 한다.
커뮤니티의 핵심을 인지하라.(Know that community is key.)
실질적으로 하나의 프로젝트를 오픈 소스로 제작한다는 것은 사유 소프트웨어 개발에 지나지 않을 수도 있지만 실지로 많은 작업들을 유발되게 된다. 물론, 공개된 상태에서 효과적으로 그리고 효율적으로 일하고 오픈 소스 커뮤니티를 지원하기 위해서는 문화에 대한 전환 과정들이 수반되는 상당히 많은 부분의 노력이 필요로 하다. 만약 해야 될 일이 많다면, 왜 그렇게 해야 하는가? 제가 앞에서 언급했듯이, 기업들은 진심으로 우러난 선의로서 프로젝트들을 공개하는 것이다. 이를 공개하는 이유는 프로젝트 관계가 형성될 커뮤니티로부터 이익을 얻기 위해서 이지만 이러한 이익들은 오로지 기업이 커뮤니티의 신뢰를 얻으며 구축하고 유지하는 경우에만 이와 같은 혜택이 발생할 수 있다. 이러한 신뢰는 모든 작업들이 커뮤니티의 의사소통과 협력 안에서 개방적으로 진행함으로써 얻을 수 있다. 기업이가 일방적으로 또는 사적으로 결정은 신뢰를 침해하게 되는 것이며 커뮤니티로부터 소외될 것이다. 커뮤니티가 소외 되었을 경우, 기업은 이탈하게 된다 (때로는 다른 방법으로 다시 시작하기 위해서 코드를 양도하기도 한다). 소멸한 커뮤니티로부터 이익을 획득하는 방법은 없다. 결과적으로 기업은 공개된 코드가 있지만 사용하지 않거나 신경 쓰지 않는다. 오픈 소스 프로젝트를 진행함에 설정한 목표를 달성할 수 없는 것은 당연하다.
여러분의 공개 이슈 트래커을 실행하라.(Launch your public issue tracker.)
프로젝트가 공개가 되었을 경우, 이전에 있었던 것들과 새로운 것을 포함한 모든 버그 보고서들은 프로젝트의 공개 이슈 트래커에서 확인할 수 있어야 한다. 여기에 여러분이 해야 할 몇 가지 사항들이 있다.
○ 이전에 있었던 버그, 티켓, 그리고 이슈들을 프로젝트의 이슈 트래커로 이동시켜라.
- 이동시킬 경우 종종 스크립터가 필요하다는 것을 숙지하라.
- 여러분이 무엇이든 이동시키기 이전에 현존하는 모든 이슈들을 검토하고 실현 불가능한 것은 종결 한다.
- 공개 트래커로 이전에 존재하던 버그, 티켓, 그리고 이슈들을 이동시키기 이전에 지적 재산권 정보들을 반드시 제거하도록 하라.
○ 종결 버그, 티켓, 그리고 이슈들을 공개 트래커로 이동할 것인지 결정하여라. 이는 선택 사항 이지만 향후 개발에 귀중한 것들을 제공해 줄 수 있다.
○ 새로운 작업 흐름을 구축하여 모든 버그, 티켓, 그리고 이슈들이 효율적으로 공개 이슈 추적(트래커)로 전송되거나 게시할 수 있도록 하라.
- 버그, 티켓, 그리고 이슈들을 다루거나 보고해야 할 모든 기업 직원들을 지정하고 교육 하라.
- 만약 여러분이 대중적으로 이용 가능한 이슈 보고 수단(예를 들어 ZenDesk)을 사용할 경우, 새로운 작업 흐름은 그곳에 보고된 문제들이 효율적으로 공공 이슈 추적(트래커)에 전송이 되고 보고 당사자들(보통 고객들)이 기대하는 정보와 서비스들을 제공 받을 수 있는지 명확하게 하라.
[원문출처] https://opensource.com/article/17/6/what-know-you-open-source-your-project
※ Opensource.com에 의해 작성된 이 저작물은 크리에이티브 커먼즈 저작자표시-동일조건변경허락 4.0 국제 라이선스에 따라 이용할 수 있습니다.
자세한 기사는 링크를 참조하시기 바라며 한국저작권위원회는 공정한 오픈소스SW 사용을 위하여
상담, 컨설팅, 라이선스 교육, 오픈소스SW 라이선스 검사서비스 등을 무료로 제공하고 있습니다.
