프로젝트를 오픈 소스로 진행하기 전에 확인해야할 사항 II
VM (Vicky) Brasseur
여러분의 제품 계획안을 시작하도록 준비하라.(Be ready to open your product roadmap.)
프로젝트가 오픈 소스로써 공개가 되었을 경우, 개발 계획안과 모든 관련 논의들이 대중적으로 이용 가능해야 한다.
○ 계획안에 어떤 것이(그리고 왜) 포함되는지에 대한 모든 논의들과 결정들은 커뮤니티의 조언과 함께 공개적으로 이뤄져야 한다.
○ 커뮤니티의 피드백은 계획안에 통합되어야 한다. 참고 사항: 이와 관련된 계획안과 모든 논의들은 개방적으로 커뮤니티의 논의를 통하여 이루어지지만 다른 조정을 하지 않는 이상 기업은 여전히 계획안에 무엇이 언제 그리고 왜 포함이 될 것인지에 대한 결정을 할 수 있다. 이와 같은 모든 절차는 프로젝트가 제공 및 지원하는 커뮤니티에서 존중하는 방식으로 진행 되어야 한다. 만약 공공 계획안이 독점적 기능과 상호 영향을 미치거나 독점적 기능에 의존하는 기능이 포함된다면, 프로젝트와 관련된 모든 사람들은 공공 계획안에 대한 논의에서 독점적 정보들이 유출되지 않도록 주의해야 한다.
워크플로의 참여를 정의하라.(Define the contributions workflow.)
프로젝트가 오픈 소스로써 공개가 되는 순간, 이에 대한 모든 참여는 기업 혹은 커뮤니티로부터 참여와는 무관하게 대중에게 공개된 작업 흐름(워크플로) 하나만을 사용해야 한다. 다음은 전형적인 작업 흐름(WorkFlow)의 예이다.
○ 참여자는 자신 소유의 컴퓨터에 공용 저장소를 공유하거나 복제해야 한다.
○ 참여자는 저장소(리포지토리)의 기능 브랜치(feature branch)을 생성해야 하며 해당 브랜치에 대한 참여를 개발해야 한다. 해당 업무는 자신의 소유의 컴퓨터에서 진행 되므로 비공개이다.
○ 참여가 준비가 된다면, 참여자는 그들의 참여를 공개 저장소(리포지토리)에 다시 등록해야 한다. (해당 절차는 사용되고 있는 버전 관리 시스템과 프로젝트의 선호도에 따라 달라진다.)
○ 참여는 공개적으로 검토를 할 수 있는 자격이 있는 커뮤니티 일원 중 한 명에 의하여 검토 된다. (일반적으로 핵심 참여자로 알려져 있다). 이러한 사람들은 참여를 병합하거나 연기 하거나 또는 종결(거부)에 대한 선택을 할 수 있다. 만약 참여가 병합된다면, 이는 아마도 헤드(마스터) 또는 다른 브랜치(branch)에서 될 수 있지만 여전히 프로젝트의 필요성과 작업 흐름에 따른다. 각각의 프로젝트는 구체적인 참여 필요성과 작업 흐름에 따라 고려되고 결정되어야 하며 프로젝트의 CONTRIBUTING.md 파일에 공개적으로 이용 가능하도록 구축하여야 한다.
구축 과정에 대해서 명심하라.(Don't forget about the build process.)
내부 프로젝트를 오픈 소스로 계획 할 경우 빌드 프로세스 종종 간과되는 경우가 많다. 프로젝트가 공개되면 빌드 프로세스 오픈되기 때문에 이런 경우에는 당혹스럽게 된다. 빌드 프로세스를 오픈할 경우 주의해야 할 점
○ 독점적이거나 내부 전용 코드는 없다.
- 만약 있다면, 이는 종료할 커뮤니티의 신뢰를 배반하게 되는 것이다.
- 이것은 또한 코드 병합과 유지에 필요한 작업량을 크게 증가시키게 된다.
○ 모든 빌드 프로세스들은 공개적으로 사용 가능한 코드에 적합하게 만들어져야 하며, 마스터/헤드 또는 안정된 브랜치(branch)에서 빌드가 유지 되어야 한다 (프로젝트와 제품이 무엇이든 가장 적합해야 한다)
○ 모든 빌드 아티팩트(Artifacts)들은 완성 대는 대로 즉시 공개적으로 사용 가능해야만 한다. 이를 어떻게 분배할 지는(예를 들어 고객들에게 전달) 대하여서는 비즈니스 결정이지만 빌드 아티팩트(Artifacts)들은 (최종 바이너리 포함) 공개적으로 항상 사용 가능하다.
커뮤니티 거버넌스(Governance) 및 Tooling에 관한 공개 토론을 지원 하라.
프로젝트가 공개가 되었을 경우, 거버넌스(Governance)의 변화, 버전 제어 또는 지속적인 통합 및 의사소통 경로의 추가 또는 변경을 포함한 프로젝트에 영향을 주거나 커뮤니티에 영향을 주는 모든 결정들은 공개적으로 이뤄져야 한다.
이런 이유로 모든 사소한 결정들이 위원회에 통보하거나 커뮤니티 전체로부터의 논의가 무조건적으로 필요하다는 것은 아니다. 간혹, 커뮤니티으로 부터의 피드백과 제안을 구하고 고려하는 것으로 결정을 하는 경우 충분한다.
모든 최종 결정들과 그 이유들 그리고 예상되는 결과들은 공개적으로 공개되며 이용 가능하고 프로젝트가 사용하는 추적기 시스템에 기록 되어야 한다 (대체적으로 메일링 수신자 명단과 문서화 시스템 또는 위키피디아).
특정 프로젝트에 존재하는 다른 항목들 오픈하기
이제는 여러분은 이해할 것이다:
프로젝트에 관련된 어떤 것이든 공개된 상태에서 수행되어야 한다.
프로젝트가 오픈 소스로써 공개된다면, 그것은 더 이상 “여러분”, 기업에 전유물이 아니라 이제는 “우리” 커뮤니티(기업은 일 부분)에 속하게 되는 것이다. 즉 향후 발전하는 데 있어 커뮤니티가 반드시 모든 단계에 포함되어야 한다는 것이다.
[원문출처] https://opensource.com/article/17/6/what-know-you-open-source-your-project
※ Opensource.com에 의해 작성된 이 저작물은 크리에이티브 커먼즈 저작자표시-동일조건변경허락 4.0 국제 라이선스에 따라 이용할 수 있습니다.
자세한 기사는 링크를 참조하시기 바라며 한국저작권위원회는 공정한 오픈소스SW 사용을 위하여
상담, 컨설팅, 라이선스 교육, 오픈소스SW 라이선스 검사서비스 등을 무료로 제공하고 있습니다.
