오픈 소스 프로그램을 설정하는 방법
여기서는 오픈 소스 프로그램을 설정하기 위해 고려할 주요 사항을 설명합니다.
“오픈 소스”란 무엇인가요?
오픈 소스 프로그램은 코드베이스에 공용으로 액세스하는 것 이상을 의미합니다. 원하는 사람은 누구나 참여할 수 있는 활기 넘치는 프로젝트를 여는 것입니다. 적절한 프로젝트에 맞게 적절히 실행하면 오픈 소스 프로그램은 제품 품질을 상당히 개선하는 데 도움이 될 수 있습니다.
회사에서 오픈 소스 프로젝트를 진행하는 주된 이유 중 하나는 커뮤니티의 참여를 원하기 때문입니다. 인기 있는 프로젝트는 커뮤니티에서 상당한 참여를, 그것도 대가 없이 받습니다.
이런 참여가 이타심의 발로인 것만은 아닙니다. 사용자와 조직은 개인 또는 비즈니즈 이점이 있다고 보기 때문에 프로젝트를 ‘사용’합니다. 프로젝트가 요구나 기대치에 맞지 않으면 버그를 해결하거나 기능을 추가하는 기회로 활용할 수도 있습니다. 이러한 개선 사항을 프라이빗 포크에만 유지하기보다는 변경 내용을 원본 리포지토리에 기여하여 프로젝트 기준에 포함해야 합니다. 이러한 선순환하는 향상의 고리 때문에 많은 회사에서 오픈 소스 모델을 사용하여 소프트웨어를 ‘생산’합니다.
오픈 소스 목표
요약하면 오픈 소스 소프트웨어에 참여하는 차원은 다음 세 가지입니다.
- 소비자 - 다른 사람의 리포지토리를 연구하거나 사용하는 사용자입니다.
- 참여자 - 다른 사람의 리포지토리 개선에 적극 참여하는 사용자입니다.
- 생산자 - 다른 사람에게 공개되는 자신의 리포지토리를 빌드 및 유지 관리하는 사용자입니다.
조직이 각 차원에서 무엇을 얻으려고 하는지 깊이 숙고할 때는 차원이 현재 어디에 있는지 조사하는 것이 좋습니다. 각 차원 내에는 5가지 프로세스 수준이 있습니다.
- 임시 - 프로세스가 없는 수준입니다. 성공은 개별 활동에 달려 있습니다.
- 관리됨 - 부분적으로 문서화된 프로세스가 있는 수준입니다. 성공은 분야에 따라 달라집니다.
- 정의됨 - 문서화되고 표준화되고 통합된 프로세스가 있는 수준입니다. 성공은 자동화에 달려 있습니다.
- 측정됨에는 양적 관리 프로세스가 있습니다. 성공은 비즈니스 목표에 대한 메트릭 측정에 달려 있습니다.
- 최적화됨 - 증분 변경 및 혁신적인 변경 모두를 통해 지속적이고 안정적으로 개선되는 프로세스가 있는 수준입니다. 성공은 변경에 따른 위험을 줄이는 데 달려 있습니다.
조직의 상황을 보다 잘 파악하려면 Open-source self assessments(오픈 소스 자체 평가)를 확인하세요.
오픈 소싱이 필요한 이유는 무엇입니까?
오픈 소스의 이점을 얻을 수 없는 프로젝트도 많습니다. 기준은 회사의 목표와 프로세스 수준에 따라 달라질 수 있지만 프로젝트를 오픈 소싱하기 전에 고려하면 좋을 몇 가지 기준은 다음과 같습니다.
프로젝트에 보호하려는 지적 재산권이 포함되어 있습니까? 그럴 경우 오픈 소싱하면 해당 가치를 공짜로 나누어 주게 됩니다. 위험보다 이점이 크지 않는 한 이러한 프로젝트는 오픈 소싱하지 마세요.
프로젝트의 코드 품질이 안정되게 우수한 상태입니까? 프로젝트가 완벽할 필요는 없지만 나쁜 상태로 시작된다면 잠재적 참여자가 외면할 수 있습니다.
프로젝트가 회사 외부의 사용자에게 유용합니까? 그렇지 않다면 참여를 얻지 못할 수 있습니다.
회사 외부 사용자가 참여할 수 있습니까? 모든 프로젝트 종속성, 빌드 프로세스 및 프로젝트를 실행하는 데 필요한 기타 항목에 액세스해야 합니다. 실행할 수 없는 경우 참여할 수 없습니다.
팀에 오픈 소스 프로그램을 지원하기 위한 대역폭이 있습니까? 그렇지 않다면, 그럴 때까지 기다립니다. 프로젝트를 오픈 소싱한 다음 지원하지 않으면 신뢰할 수 있는 커뮤니티를 구축할 기회를 잃을 수 있습니다.
이러한 질문은 가장 일반적인 고려 사항 중 일부에 불과합니다. 사용자의 조직에는 염두에 두어야 할 다른 비즈니스 또는 준수 문제가 있을 수 있습니다.
오픈 소스 프로그램 설계
오픈 소스 프로그램은 InnerSource 프로그램을 실행하는 것과 유사하지만 일반을 대상 그룹으로 합니다. 따라서 고려해야 할 추가 사항이 몇 가지 있습니다.
커뮤니티 기대 수준 설정
README.md 및 CONTRIBUTING.md 같은 파일은 조직과 연관이 없는 사용자에게 노출되므로 훨씬 더 중요해집니다. 회사 외부의 사용자 관점에서 이러한 파일의 내용이 명료한지 평가해야 합니다.
또한 사용 규정도 표현해야 하는 중요한 정책입니다. 표준은 리포지토리의 루트에 CODE_OF_CONDUCT.md 파일을 추가하고 이를 사용하여 커뮤니티 참여자에게 기대되는 동작을 설명하는 것입니다. 이 문서는 법률 팀을 포함하여 조직의 여러 그룹에서 검토해야 합니다. 다행히 시작하는 데 사용할 수 있는 여러 표준 사용 규정이 있습니다. 많은 프로젝트에서 이러한 강령을 수정 없이 그대로 사용합니다. 자세한 내용은 오픈 소스 사용 규정 가이드를 참조하세요.
직원이 리포지토리를 유지 관리하도록 준비
직원이 오픈 소스 커뮤니티를 활용한 경험이 없을 수 있습니다. 직원의 준비를 돕기 위해 시작하기 전에 누구나 알고 있어야 하는 주요 항목을 다루는 일련의 가이드를 회사에서 제공하는 것이 좋습니다. 이러한 가이드는 정기적으로 유지 관리되고 회사 직원만 액세스할 수 있는 내부 리포지토리나 포털에 게시해야 합니다. 다음 가이드는 가장 중요한 몇 가지 사항입니다.
“이 프로젝트를 오픈 소싱해야 하나요?” 가이드 - 후보 프로젝트를 오픈 소싱할지 여부를 결정하기 위한 프레임워크를 제공합니다. 이 가이드는 순서도, 일련의 질문 또는 고려 사항 목록으로 구성될 수 있습니다.
설정 검사 목록은 팀이 오픈 소스 프로젝트를 시작하기 전후에 완료해야 하는 모든 작업 항목을 포함합니다. 이 목록에는 프로젝트의 오픈 소싱에 대한 승인 얻기, 프로젝트가 시작되기 전 중요 데이터를 제거하기 위한 코드 검토, 상표 또는 오픈 소스 프로젝트 검색을 통해 이름 충돌이 없는지 확인 등이 포함됩니다.
연락처 목록 - 유지 관리자의 직접 지원이 필요한 경우 연락해야 할 수 있는 조직 내 주요 사용자의 연락처 목록입니다. 이 목록에는 소프트웨어 보안, 사이트 보안, 법률, 홍보 등 부문의 관련 직원이 포함되어야 합니다.
복제해서 시작점을 사용할 수 있는 시작 리포지토리에 대한 링크. 여기에는 샘플 추가 정보, 라이선스, 사용 규정, 참여 가이드 및 회사의 모든 오픈 소스 프로젝트에 필요한 기타 지원 파일이 포함되어 있어야 합니다. 실수로라도 일반 대상 그룹에 푸시하지 않아야 하는 항목을 포함하지 않아야 합니다.
유지 관리자 가이드는 유지 관리자가 리포지토리를 정상적으로 유지하기 위해 맡은 책임을 설명합니다. 이러한 책임에는 리포지토리 설명서를 최신 상태로 유지, 이슈 및 끌어오기 요청이 적합한 사용자에게 적시에 전달되는지 확인 등이 포함됩니다.
통신 가이드는
README.md,CONTRIBUTING.md또는CODE_OF_CONDUCT.md와 같은 퍼플릭 파일에 포함하지 않으려는 항목에 관한 리포지토리 유지 관리자 지침을 제공합니다. 이러한 주제는 경쟁사에 대해 논의하지 않음과 같은 중요한 비즈니스 토픽일 수도 있고 상위 참여자를 적절하게 인정하는 방법과 같은 일반적인 행위 토픽일 수도 있습니다.내부 FAQ는 일반적인 질문에 대한 승인된 답변을 제공합니다. 이 목록은 회사에서 오픈 소스 프로그램을 유지 관리하는 과정에서 논의할 수 있는 토픽에 관한 법률적으로 미묘한 사항이 있는 경우 특히 유용합니다.
라이선스 정책에서는 법률 부서에서 오픈 소스 사용 또는 참여를 승인하거나 거부한 라이선스를 나열합니다.