이 섹션에서는 새로운 오픈 소스 프로젝트를 만드는 근거와 가치 제안을 살펴보겠습니다. 새로운 오픈 소스 프로젝트를 만들어야 하는 좋은 이유와 나쁜 이유, 그리고 새 프로젝트의 비즈니스 잠재력을 평가하는 방법에 대해 논의하는 데 시간을 할애할 것입니다.
이 섹션이 끝나면 다음을 수행할 수 있습니다:
- 오픈 소스 내부 코드 또는 처음부터 새로운 오픈 소스 프로젝트 생성에 대한 가치 제안 설명
- 소스 코드를 공개해야 하는 이유에 대한 좋은 예와 나쁜 예를 제시하십시오.
- 새로운 오픈 소스 프로젝트의 비즈니스 잠재력을 평가하는 방법 설명
새로운 오픈 소스 프로젝트를 만드는 여정을 시작하기 전에 올바른 질문을 하는 것이 중요합니다. 회사의 고유한 상황에 따라 고려해야 할 몇 가지 추가 특정 질문이 있을 수 있지만 다음 그림은 질문할 내용을 파악하는 데 도움이 되는 좋은 출발점이 될 것입니다.
이 그래픽의 맨 윗줄은 실제로 오픈 소스 프로젝트를 생성하기 위한 가치 제안이 무엇인지 이해하는 문제를 다룹니다. 첫 번째 질문은 불행히도 충분히 자주 묻지 않는 질문입니다. 다른 오픈 소스 프로젝트를 만들어야 하는지 여부를 심각하게 평가해야 합니다. 수천 개의 프로젝트가 존재합니다. 귀하의 코드가 그 자체로 차별화된 가치를 제공할 것입니까, 아니면 확립되고 성공적인 오픈 소스 프로젝트를 훨씬 더 좋게 만드는 것이 더 나을까요?
조직에서 오픈 소스 개발 모델(이 과정 시리즈의 이전 섹션에서 다뤘음)을 이해하고 해당 구조로 프로젝트를 구축하는 데 전념하고 있다면 프로젝트를 시작하기로 결정하기 전에 **성공적인 요소를 평가해야 합니다. 사용할 측정항목입니다. 홍보 목적으로 프로젝트를 생성하거나 시작된 오픈 소스 프로젝트 수에 대한 내부 지표를 개선하는 것만으로는 일반적으로 프로젝트가 실패하게 됩니다.
두 번째 질문 행은 새로운 오픈 소스 프로젝트에서 가치를 구축할 수 있는 조직과 커뮤니티의 능력에 더 중점을 둡니다. 너무 많은 회사가 내부 재정 및 엔지니어링 투자 없이 방화벽을 넘어 단순히 코드를 던지는 전략을 시도했지만 실패했습니다.
시간을 내어 잠재적인 새로운 오픈 소스 프로젝트를 성공적으로 만드는 방법을 고려하십시오. 오픈 소스 프로젝트를 만드는 것이 특정 코드에 적합하지 않다는 결론에 도달해도 괜찮습니다. 오픈 소스 에코시스템에 참여하거나 다른 오픈 소스 프로젝트에 귀하의 기술을 기여할 수 있는 많은 기회가 있습니다.
업스트림 오픈 소스 커뮤니티에 무엇을 다시 기여할 것인지 결정해야 하는 것과 마찬가지로(이 시리즈의 이전 과정에서), 처음에 공개 상태에서 어떤 코드 또는 기술을 구축할지 또는 어떤 독점 코드를 만들 것인지에 대한 결정' ll 릴리스는 중요한 것입니다. 다음은 이 선택을 고려하는 데 도움이 될 수 있는 몇 가지 기준입니다.
- 제품의 어떤 부분이 전략적 이점의 원천인지, 그리고 단순히 이러한 부분을 지원하는 부분을 결정합니다.
- 비전략적 부분은 종종 오픈 소스 프로젝트를 만들기 위한 훌륭한 후보입니다.
- 다른 회사도 같은 느낌을 받을 가능성이 높으며 새로운 프로젝트를 유지하고 발전시키는 데 도움이 될 수 있습니다.
예:
- 업계에서 널리 사용되는 파일 시스템 또는 파일 형식
- 연결된 IoT 장치를 위한 네트워크 스택
시작할 수 있는 또 다른 장소는 기업이 권위자가 될 필요가 없고 문제 해결을 도울 수 있는 전 세계의 더 많은 기술자 그룹이 있을 수 있는 2차 코딩 프로젝트를 포함합니다. 미션 크리티컬 코드가 아닌 경우 오픈 소스로 사용할 수 있는 좋은 후보입니다. 그러나 회사에서 여전히 적극적으로 사용하고 유지 관리하는 코드여야 합니다. 코드에 대한 상업적 종속성은 버그 수정, 패치 및 새로운 기능에 대한 지속적인 피드백 루프를 가능하게 합니다.
새로운 오픈 소스 프로젝트를 출시하거나 생성하기로 결정하는 것은 상황에 따라 다릅니다. 회사는 먼저 오픈 소스 소프트웨어를 사용하고 기존 프로젝트에 기여하여 일정 수준의 오픈 소스 숙달을 달성해야 합니다(이 시리즈의 이전 과정에서 다루었음).
오픈 소스를 사용하는 방법을 이해하면 외부 프로젝트와 개발자를 활용하여 제품을 구축하는 방법을 배울 수 있습니다. 참여하면 오픈 소스 커뮤니티의 관습과 문화에 더 유창해질 수 있습니다. 그러나 오픈 소스에 능숙해지면 자신의 오픈 소스 프로젝트를 시작하기에 가장 좋은 시기는 단순히 "초기" 및 "자주"입니다.
이 그래픽은 이 코스워크 시리즈의 오픈 소스 개발 사례 부분에서 다룬 내용에 대한 약간의 알림입니다. 오픈 소스에 다시 기여할 때뿐만 아니라 첫 번째 새로운 오픈 소스 프로젝트를 고려할 때도 중요합니다.
첫 번째 오픈 소스 프로젝트를 만들기 전에 모든 것이 절대적으로 완벽할 필요는 없습니다. 프로세스, 법적 검토 등의 측면에서 몇 가지 최소 사항이 있지만(곧 다룰 예정임), 시작하기 위해 코드와 거버넌스 모두에 필요한 최소 사항을 구축하면 더 일찍 참여하고 더 일찍 피드백을 받아 발전할 수 있습니다. 당신의 새로운 프로젝트.
첫 번째 프로젝트를 만들기 전에 오픈 소스 프로젝트를 만드는 좋은(그리고 나쁜) 이유에 대해 논의해야 합니다.
이 그래픽은 오픈 소스 프로젝트를 시작해야 하는 5가지 이유를 보여줍니다. 모두 비즈니스 목표로 돌아가지만 처음 두 가지는 시장에서 고유한 비즈니스 이점을 얻는 것과 관련이 있습니다. 그러나 이러한 '선도자' 비즈니스 이점은 커뮤니티의 나머지 구성원이 귀하가 오픈 소스로 제공한 기술에 익숙해질 때까지 일시적(6-10개월)일 수 있다는 점에 유의하는 것이 중요합니다.
세 번째 및 네 번째 항목은 고객의 참여를 유도하고 비오픈 소스 제품의 가치를 구축하는 데 중점을 둡니다. 오픈 소싱 코드에서 가치를 제공하는 것은 결과적으로 제품을 더 좋게 만드는 것임을 기억하십시오.
마지막으로, 기술로 스스로를 지원할 수 있는 기술 고객(또는 개발자)이 있는 업계에 있다면 오픈 소스로 선택한 코드에 대해 추가 기술 또는 지원 리소스를 제공할 필요가 없다는 점에서 가치를 실현할 수 있습니다.
올바른 이유로 오픈 소스만큼 중요한 것은 잘못된 이유로 오픈 소스 프로젝트를 만들려고 하지 않도록 하는 것입니다. 오픈 소스 생태계는 좋은 의미를 지닌 조직의 실패한 프로젝트로 가득 차 있지만 단순히 코드를 오픈 소싱해야 하거나 새 프로젝트를 만들어야 하는 이유를 충분히 고려하지 않았습니다.
다음은 새로운 오픈 소스 프로젝트를 만들어야 하는 나쁜 이유의 몇 가지 예입니다:
- 구식 소프트웨어 제거
- 투자할 의사가 없을 때 오픈 소스 커뮤니티에서 무료 엔지니어링을 기대합니다.
- 단종 발표에 대한 긍정적인 마케팅 스핀으로
- 프로젝트를 장기적으로 지원할 의도 없이 홍보 또는 마케팅 활동을 얻기 위해
- 내부 성공 지표를 충족하는 수단
이 모든 것이 오픈 소스 프로젝트를 만들어야 하는 나쁜 이유가 분명하기를 바랍니다. 하지만 이들 모두의 공통점이 무엇인지 살펴보겠습니다. 내부 초점 및/또는 더 큰 오픈 소스 커뮤니티의 지원 기대입니다.
오픈 소스에서 일하는 것은 종종 (기업의 관점에서) '계몽된 자기 이익'으로 설명됩니다. 기업이 반드시 이타적인 이유로 오픈 소스와 함께 일하지 않는다는 것을 모두가 이해하기 때문에 이 경우에 해당합니다. 오픈 소스에서 진행되는 것과 일치하는 비즈니스 가치가 있어야 합니다. 그러나 위에 표시된 이유는 결국 파트너와 경쟁자로 구성된 나머지 오픈 소스 커뮤니티에 대한 불신의 씨앗을 뿌립니다.
모든 비즈니스 결정과 마찬가지로 오픈 소스 프로젝트를 생성해야 하는 대상, 경우 및 시기를 결정하는 것은 궁극적으로 비즈니스에 제공되는 가치로 돌아갑니다. 이러한 질문을 고려할 때 비즈니스 사례 구축 측면에서 생각하는 것이 가장 좋습니다.
먼저 회사에서 코드와 프로젝트의 소유권을 유지하면서 코드를 만들거나 릴리스할 것인지 아니면 프로젝트를 유지 관리하고 관리하기 위해 다른 사람에게 코드를 기여할 것인지 결정해야 합니다. 코드가 이미 존재하는 경우 프로젝트의 모든 코드를 릴리스할지 아니면 일부만 오픈 소스 프로젝트로 릴리스할지에 대한 관련 문제가 있습니다.
이러한 결정을 내리려면 뒤로 물러나 코드에 대해 염두에 두고 있는 목표를 결정하는 것이 좋습니다. 이 코드가 조직 외부에서 유용하고 업계에도 변화를 줄 수 있는 코드입니까? 귀사는 조직의 제품 포트폴리오를 지원하기 위해 이 기술에 대해 작업할 파트너(및/또는 경쟁업체)를 유치할 가능성이 있습니까?
예를 들어 작업의 핵심이 아닌 응용 프로그램의 일부에 대해 다른 개발자로부터 신선한 통찰력을 얻고 싶을 수 있습니다. 또는 시스템 모니터링 응용 프로그램에서 로그를 감지하기 위해 추가 실제 알고리즘을 찾을 수 있습니다. 전체 제품을 오픈 소스로 공개하는 대신 알고리즘과 관련된 코드만 공개할 수 있습니다. 이를 통해 핵심 비즈니스를 손상시키지 않으면서 다른 사람들의 기여를 얻고 유사한 도움이 필요한 다른 사람들을 도울 수 있습니다.
프로젝트를 시작하고 전반적인 제어를 유지하면 감독을 할 수 있고 필요한 것을 구체화하는 데 도움이 되는 기능을 제공하는 동시에 기여하는 개발자에게 작업을 수행할 수 있는 자유와 제어를 제공합니다.
이 섹션에서는 법률, 비즈니스 및 커뮤니티 고려 사항에 대한 논의를 포함하여 새로운 오픈 소스 프로젝트 생성을 준비하는 방법을 살펴봅니다. 또한 성공을 위해 필요한 프로세스, 도구 및 인력 요구 사항에 대해서도 논의합니다.
이 섹션이 끝나면 다음을 수행할 수 있습니다:
- 새로운 오픈 소스 프로젝트를 만들기 위한 전반적인 준비 단계를 설명합니다.
- 성공적인 프로젝트 생성을 위해 필요한 프로세스, 고려 사항, 도구 및 요구 사항 이해
성공적인 오픈 소스 프로젝트를 생성하려면 많은 투자가 필요하므로 조직의 경영진 후원자의 동의를 얻는 것이 중요합니다. 후원자가 두 명 이상인 경우 도움이 될 수 있지만 최소한 다음 사항을 제공하고 약속할 수 있는 사람을 목표로 해야 합니다.
- 공개적으로 프로젝트에 대한 약속을 지속적으로 재확인
- 성과에 기반한 인정 문화 조성
- 중립성 확보
- 다음 오픈 소스 방법 및 프로세스에 전념
- 내부: 프로젝트 진행을 위한 충분한 개발 자금 지원
- 외부: IT 리소스 및 시스템 관리자에 대한 자금 지원
이전 페이지에서 언급한 바와 같이 경영진 후원자가 자금을 적절하게 할당하도록 해야 하지만 프로젝트를 성공시키기 위해 적절한 직원 시간을 지시할 수 있어야 합니다. 개발자 시간은 초기에 내부 코드 작업에 소비한 시간과 비슷할 것입니다. 그러나 새로운 커뮤니티의 다른 사람들이 코드베이스에 대한 속도를 높일 수 있도록 개발자가 제공해야 하는 시간, 자료 또는 도움도 고려해야 합니다.
또한 경쟁자가 포함될 수 있는 오픈 소스 프로젝트를 만드는 데 관여할 법무팀과 출시 후 프로젝트가 지원과 기여자를 얻을 수 있도록 마케팅 투자에 필요한 리소스도 있습니다.
또한 프로젝트를 시작하고 유지 관리하는 데 사용되는 인프라에 대한 예산을 설정해야 합니다. 여기에는 코드가 상주하고 유지 관리되는 GitHub와 같은 프로젝트 호스팅 및 소스 제어 웹 사이트, 버그 해결 및 기타 필요한 도구가 포함됩니다.
곧 도구와 인프라에 대해 자세히 다룰 것입니다.
조직에서 오픈 소스 주제(예: 이 과정 시리즈)에 대한 교육을 받았더라도 엔지니어링 팀과 관리자에게 일반적으로 제품 구축 또는 작업 평가에 접근하는 방식과 다를 수 있는 특정 항목을 상기시키는 것이 중요합니다.
- 오픈 소스 개발 방법 및 프로세스 검토
- 회사의 오픈 소스 정책 및 규정 준수 규칙 검토
- 소프트웨어 개발 모델 내에서 오픈 소스 소프트웨어 통합
- 가능한 경우 내부적으로 오픈 소스 모범 사례를 따르십시오. *보다 일반적인 솔루션을 만드는 데 도움이되는 커뮤니티 사고를 연습하고 장려하십시오.
- 기존 성능 측정항목이 더 이상 적용되지 않을 수 있음
- 코드가 사용되지 않은 결과만 계산
- 결과에 영향을 미치는 것은 코드를 작성하는 것만큼 유효한 솔루션입니다.
- 관리자가 아닌 개발자를 관리하십시오.
- 당신은 오픈 소스 프로세스를 제어할 수 없습니다
- 직원과 커뮤니티를 위한 학습 곡선이 있습니다.
- 영향력과 존중을 구축하는 데는 시간이 걸립니다(회사의 프로젝트일지라도).
일부 청중은 새로운 오픈 소스 프로젝트와 같은 노력을 시작하기 전에 긴 리뷰를 반드시 높이 평가하지는 않지만 법무 팀, 엔지니어링 팀 및 마케팅 팀의 리뷰를 위해 적절하게 시간을 내어 계획하는 것이 중요합니다.
가장 자주 놓치는 요소가 균열을 통과하지 않는지 확인하기 위한 간단한 체크리스트 세트가 도움이 될 수 있으므로 이것들이 반드시 고통스러울 필요는 없습니다. 새로운 오픈 소스 프로젝트를 만드는 과정을 시작할 때 이 시간을 사용하면 프로젝트가 종료되고 가시성을 확보한 후 많은 골칫거리를 줄일 수 있습니다.
이러한 검토 프로세스를 간소화하는 방법에 대해 다음 섹션에서 몇 가지 모범 사례를 다룰 것입니다.
새 프로젝트에서 발생할 수 있는 최악의 상황 중 하나는 커뮤니티가 코드베이스의 법적 청결성에 대한 불신을 갖는 것입니다. 릴리스하는 코드에 명확한 라이선스와 출처가 있는지 확인하는 것이 중요합니다. 완전한 법적 검토는 기여한 내용이 커뮤니티의 다른 사람들에게 받아들여질 수 있는지 확인하는 데 종종 도움이 됩니다.
법적 검토에는 상표 실사 및 등록도 포함되어야 합니다. 프로젝트를 재단에 기여하는 경우(이에 대한 자세한 내용은 나중에 거버넌스 섹션에서) 코드베이스를 오픈 소싱하기 전에 상표 전략에 맞춰져 있는지 확인하십시오.
또한 프로젝트에 대한 라이선스를 선택해야 합니다. 라이선스 또는 지적 재산권 요구 사항을 문서화하는 것이 중요합니다. 프로젝트는 일반적으로 아웃바운드 라이선스(예: 다운스트림 사용자가 코드를 받는 라이선스)와 인바운드 기여 메커니즘(예: 프로젝트에 기여하는 프로세스)을 모두 고려해야 합니다. 많은 프로젝트에서 인바운드 기여 메커니즘에 대해 개발자 인증서(DCO) 승인 프로세스를 사용합니다. 특허 부여에 대한 회사의 명시적인 약속이 필요하거나 나중에 프로젝트에 라이선스를 다시 부여할 수 있는 기능이 필요할 것으로 예상되는 경우 좀 더 일반적인 기여자 라이선스 계약(일반적으로 CLA라고 함)을 살펴보는 것이 좋습니다. 모든 CLA가 동일한 것은 아니므로 이 옵션을 신중하게 고려하십시오. 또한 CLA는 개발자가 서명을 받기 위해 힘든 승인 프로세스를 거쳐야 하는 경우가 많기 때문에 참여를 방해할 수 있습니다. 라이선스 옵션에 대한 자세한 내용은 이 교육 시리즈의 오픈 소스 규정 준수 프로그램 모듈을 참조하십시오.
귀하의 프로젝트는 소프트웨어가 아닌 결과물을 생산할 수도 있습니다. 프로젝트에서 문서를 생성하는 경우 문서에 특정 라이선스를 사용해야 하는지 여부를 논의하십시오. 예를 들어, 많은 오픈 소스 프로젝트는 소프트웨어에 대해 오픈 소스 라이선스를 사용하고 문서에 Creative Commons 라이선스를 사용합니다. 또한 일부 프로젝트에서는 다른 사람이 다양한 방식으로 구현할 수 있는 사양을 만들려고 합니다. 이러한 프로젝트는 사양 라이선스를 사용하는 옵션을 고려해야 합니다.
각 라이선싱 접근 방식에는 장단점이 있지만 상호 운용 가능하거나 다양한 공급업체 솔루션 간에 이식성을 제공해야 하는 소프트웨어의 경우 특히 문제인 프로젝트 단편화 가능성을 인식해야 합니다. 종종 이 문제는 상용 솔루션이 커뮤니티에서 만든 테스트 또는 일련의 요구 사항을 통과하는 경우 프로젝트 상표의 사용을 허용하는 적합성 프로그램을 만들어 해결됩니다. 이에 대해 미리 생각하면 프로젝트에 대한 법적 검토 및 계획을 알리는 데 도움이 됩니다.
요약하면 법적 검토 프로세스의 단계는 다음과 같습니다:
- 회사의 지적 재산에 대한 오픈 소스의 영향 고려
- 오픈 소스 라이선스에 대한 완전한 규정 준수 보장
- 공개할 소스 코드에 대한 오픈 소스 라이선스를 선택하고 프로젝트의 모든 라이선스 요구 사항을 매우 명확하게 문서화합니다.
- 기여자 동의가 필요한지 결정
- 커뮤니티의 가능한 비 소프트웨어 출력과 문서 및 사양과 같은 적절한 라이선스를 고려합니다.
- 상표 관련 고려 사항 결정
- 적합성 테스트와 같은 생태계 계획에 구축할 추가 요소가 있는지 결정
기술 검토에서는 소스 코드가 다른 내부 코드 또는 개발 방식(사용자 지정 내부 빌드 시스템 포함)에 종속되지 않고 작동할 수 있으며 회사가 오픈 소스 릴리스에 포함할 수 없는 타사 코드가 포함되어 있지 않음을 확인합니다.
기술 검토에는 모든 라이선스 및 저작권 고지에 대한 확인이 포함되어야 하며 모든 개인 또는 내부 코드 주석은 삭제되어야 합니다. 단계에는 다음이 포함됩니다:
- 비공개 구성 요소에 대한 중요한 종속성 제거
- 문서 및 사용 사례 제공
- 내부 주석, 다른 내부 코드에 대한 참조 등을 제거합니다.
- 코딩 스타일이 일관적인지 확인
- 소스 코드 파일의 저작권 고지 업데이트
- 소스 코드 파일에 라이선스 고지 추가
- 코드가 모든 외부 대상 플랫폼에서 컴파일 및 빌드되는지 확인합니다.
- 루트 디렉토리에 라이센스 텍스트를 파일로 추가
성공적인 오픈 소스 프로젝트는 코드와 기술의 장점에만 의존할 수 없습니다. 프로젝트를 계속 진행하려면 주의가 필요한 일련의 추가 비즈니스 및 마케팅 단계가 있습니다. 여기에는 프로젝트 홍보, 성공적인 운영 전략 수립, 현실적인 예산 및 프로젝트 브랜딩 제공, 활발한 소셜 미디어 계정 및 장기적인 성공을 뒷받침하는 유용한 도메인 이름 설정이 포함됩니다.
마케팅 검토는 브랜딩에 대한 지침을 설정합니다. 이는 시장에서 일관된 메시지를 보장하는 데 도움이 되기 때문에 특히 중요합니다. 마케팅 검토 단계에는 다음이 포함됩니다:
- 프로젝트 로고, 색 구성표, 웹사이트, 자료 등을 디자인합니다.
- 브랜딩 가이드라인 공식화
- 프로젝트의 소셜 미디어 계정 등록(Twitter, Facebook, LinkedIn 등)
- 프로젝트에 대한 도메인 이름 등록
프로젝트 시작 전에 이 마케팅 검토를 수행하면 잠재적인 브랜딩 문제(예: 선호하는 이름에 사용할 수 없는 도메인 이름)가 프로젝트의 성공을 위협하기 전에 처리할 수 있습니다. 마케팅 팀이 이러한(및 기타) 문제를 탐색하는 데 도움이 될 수 있도록 초기에 마케팅 팀을 참여시키십시오.
코드를 기여하고, 포럼에 참여하고, 버그 수정을 제공하고, 문제를 보고하기 위해 얼마나 많은 사람들을 프로젝트로 몰고 갈 수 있는지 보는 것은 재미있는 도전이기 때문에 마케팅 팀이 흥분할 것이라는 것을 알게 될 것입니다.
새로운 오픈 소스 프로젝트를 위한 거버넌스 모델이 무엇인지 고려하는 것이 중요합니다. 그러나 거버넌스란 무엇을 의미합니까? 간단히 말해서, 거버넌스는 다음에 대한 결정을 가능하게 하는 프로젝트 주변의 구조입니다:
- 참가요령 및 요건
- 아키텍처 변경
- 유지 보수 지명
- 분쟁에 대한 최종 중재자
- 참여자 중단
다양한 수준의 비즈니스 및/또는 기술 리더십으로 프로젝트를 관리할 수 있는 여러 가지 방법이 있습니다. 리더십에 대해서는 잠시 후에 다루겠지만 다양한 유형의 거버넌스 모델에 대한 자세한 내용은 이 교육 시리즈의 "오픈 소스 프로젝트와 효과적으로 협업" 과정을 참조하십시오.
진행하기 전에 리더십 역할을 설정하는 것도 중요합니다. 이는 다른 프로젝트에 대해 다른 것을 의미할 수 있습니다. 여러 기업 참여자가 있는 다중 회사 프로젝트를 시작하는 경우 프로젝트에 이사회 또는 기타 관리 그룹과 같은 보다 공식적인 거버넌스가 필요할 수 있습니다.
다른 준비에는 단순히 기술적인 관점에서 오픈 소스 프로젝트의 모든 측면을 감독하는 기술 위원회가 필요할 수 있습니다. 위원회의 구성에는 대부분 기술 리더십과 진행 상황 및 프로젝트 요구 사항에 대한 업데이트를 제공하기 위해 경영진에 다시 연락하는 연락 담당자가 포함됩니다. 그런 다음 기술 구성원과 경영진이 적합하다고 생각하는 대로 법무팀을 투입할 수 있습니다.
당신의 최고의 건축적 지식인은 물론 코드 기반이 어떻게 작동할지 알고 있는 다른 사람들도 분명히 그곳에 있을 것입니다. 전체적으로 위원회의 구성원은 프로젝트가 어디로 가고 있는지에 대한 비전과 개발자 커뮤니티 내에서 지원을 받게 됩니다. 그들은 당신이 그 과정을 계획하기 위해 테이블에 있기를 원하는 사람들입니다.
새로운 오픈 소스 프로젝트가 생성될 때 자주 제기되는 또 다른 질문은 공급업체 중립적인 비영리 조직에 코드를 기여할 것인지 아니면 자체 프로젝트를 소유하고 실행하여 일부 통제권을 유지할 것인지입니다. 답은 달성하려는 목표에 따라 다릅니다. 업계를 위한 초기 기술을 구축하기 위해 소수의 파트너와 협력하고 있다면 처음부터 비영리 재단을 고려할 필요가 없을 것입니다.
그러나 계획하고 있는 것이 산업 전반에 걸쳐 광범위하게 적용될 수 있거나, 산업 전반에 걸쳐 있거나, 작은 노력에서 크고 복잡한 것으로 성장한 경우, 종종 비영리 오픈 소스/공개 표준 컨소시엄을 고려하여 귀하를 호스팅하는 것이 좋습니다. 프로젝트. 프로젝트를 호스팅할 수 있는 진정한 벤더 중립적인 장소를 갖는 것의 가치 외에도, 이러한 기반에는 프로젝트를 성공으로 이끄는 프로세스를 극적으로 간소화할 수 있는 법률, 거버넌스, 마케팅 및 프로젝트 인프라 서비스가 있습니다.
선택할 수 있는 많은 기초(및 하위 기초)가 있으며 각각 고유한 가치 제안, 가격 및 서비스 수준을 제공합니다. 이러한 기초의 몇 가지 예는 다음과 같습니다:
선택하는 기초는 프로젝트가 속한 전문 분야와 비용, 거버넌스 모델 등과 같은 고려 사항에 따라 다릅니다.
시작하기 전에 프로젝트 관리자가 변경 및 개선을 수행할 때 코드의 정기 릴리스를 예약하기 위해 표준 릴리스 프로세스를 만드는 것이 종종 도움이 됩니다. 일정은 개발 커뮤니티와 프로젝트의 비즈니스 측면에 대해 잘 정의되고 가시적인 세부 정보로 설정되어야 합니다.
이러한 릴리스의 빈도는 커뮤니티의 기대치에 따라 다릅니다. 프로젝트가 기업 중심이고 매우 강화된 것을 구축하려는 경우 릴리스 일정이 1년에 두 번일 수 있습니다. 프로젝트의 범위가 더 작고 더 민첩하고 프로젝트의 일부를 꺼내려고 하는 경우 매월 또는 매주 코드를 릴리스할 수 있습니다. 일정의 핵심은 커뮤니티가 일정을 지시하고 사용자가 필요로 하고 기대하는 것을 제공하면서 속도의 관점에서 프로젝트를 지원할 수 있는 능력을 이해해야 한다는 것입니다. 커뮤니티에서 릴리스가 너무 빠르거나 너무 느리다는 피드백을 제공하는 경우 프로세스를 살펴보고 일부 조정을 해야 합니다. 여기서 중요한 것은 일관성, 예측 가능성 및 가시성입니다.
또한 코드, 패치, 기능 아이디어, 문서 또는 기타 프로젝트 아티팩트를 제출하기 위한 잘 정의된 프로세스가 있어야 합니다. 이 중 일부는 프로젝트 인프라/도구(곧 다루게 될 주제)에서 처리할 수 있지만 기술 프로세스의 일부는 도구가 아니라 워크플로의 기대치 - 예: 코드 제출 방법, 어떤 종류의 코딩 표준을 따를 것인지, 릴리스 주기에서 새 코드가 언제 받아들여질 것인지 - 등입니다.
프로젝트를 시작하기 전에 프로젝트를 위한 저장소를 준비해야 합니다. 이것은 본질적으로 프로젝트를 기여자가 항상 사용할 수 있는 코드 리포지토리를 위한 인프라입니다. 많은 프로젝트에서 잘 알려진 GitHub 또는 GitLab 저장소를 사용하거나 Gerrit과 같은 도구를 사용하여 자체 저장소를 호스팅합니다.
사용할 수 있는 다른 옵션도 많이 있지만 개발자가 프로젝트에 쉽게 참여하고 참여할 수 있도록 하는 것이 유용한 경우가 많다는 것을 기억하십시오. 대부분의 개발자에게 친숙한 도구 플랫폼을 선택하면 프로젝트의 기여와 성장을 가속화하는 데 도움이 됩니다.
버그, 문제 및 기능 추적도 프로젝트 인프라 계획의 일부로 포함되어야 합니다. 기고자가 수정해야 할 문제와 유용할 수 있는 새로운 기능에 대한 요청을 보고할 수 있는 쉬운 장소를 제공하고자 합니다. 그런 다음 품질을 보장하기 위해 코드를 스캔하고 확인하는 동안 시스템과 프로젝트의 원활한 흐름을 유지하기 위해 프로젝트의 GitHub 리포지토리의 일부로 포함해야 할 수 있는 자동화된 빌드 및 테스트 시스템 프로세스가 있습니다.
이 과정 시리즈의 Open Source Development Practices 모듈을 검토하면 자동화된 테스트 및 지속적인 통합과 같은 것에 대한 자세한 정보를 얻을 수 있습니다.
중요한 단계는 프로젝트에 대해 회사 중립적인 웹 존재를 만드는 것입니다. 오픈 소스 프로젝트 웹사이트를 회사 웹 페이지의 하위 도메인으로 배치하려고 하지 마십시오. 최선의 의도가 있더라도 프로젝트의 중립적인 홈을 시각적으로 구분하는 것이 중요합니다. 웹 페이지는 커뮤니티에서 문서, 코드 다운로드 링크 등을 포함하여 프로젝트에 대한 정보를 찾을 수 있는 장소를 제공합니다. 웹 페이지는 또한 프로젝트의 리더십, 범위, 사용자 및 기여자, 예산, 거버넌스 및 기타 세부 사항에 대한 세부 정보를 제공할 수 있습니다. 중앙 정보 저장소인 귀하의 웹사이트에는 새로운 개발자가 커뮤니티에 가입할 수 있는 매우 명확한 클릭 유도문안/장소가 있어야 합니다.
커뮤니티에서 도움을 요청할 수 있는 커뮤니케이션 채널을 제공하는 것이 중요합니다. 전체 개발 워크플로에 통합할 수 있는 도구를 찾고 싶을 것입니다(예: 지원 요청, 코드 체크인, 오류 로그 및 기타 작업에 대한 알림 수신). 또한 커뮤니티 구성원이 프로젝트에 참여하고 있는 다른 사람들로부터 빠른 답변을 얻을 수 있는 중요한 토론 포럼과 메커니즘을 제공하고 싶을 것입니다. 모두 실시간으로 프로젝트를 진행하는 데 도움이 되는 중요한 커뮤니케이션 수단입니다.
고려해야 할 프로젝트 도구 중 하나는 Slack입니다. 온라인 팀 프로젝트 관리 및 커뮤니케이션 플랫폼은 사용자가 메시지와 파일에 액세스 및 공유하고, 워크플로를 구성하고, 정보 검색을 수행하는 등의 작업을 수행할 수 있는 플랫폼입니다. 그러나 Slack은 독점 도구이며 특정 사용 임계값을 초과하여 유지 관리하는 데 비용이 들 수 있습니다. IRC, Gitter.im, Mattermost, Rocketchat 등과 같은 오픈 소스 옵션이 있습니다.
개발자 및 사용자 커뮤니티에 따라 최신 포럼 도구가 필요할 수도 있습니다. Discourse는 완전 오픈 소스이며 선택적 호스팅도 제공하는 훌륭한 옵션입니다. 통신 시스템을 선택할 때 모든 형태의 종속성, 재정적 비용 및 향후 새 시스템으로의 마이그레이션이 얼마나 쉬운지를 염두에 두십시오.
커뮤니티가 성장함에 따라 새로운 커뮤니케이션 채널에 적응할 수 있어야 합니다. 프로젝트가 발전함에 따라 도구 결정에 커뮤니티를 참여시키십시오. 사용자와 개발자는 시간이 지남에 따라 유용하다고 생각하는 다른 도구에 자연스럽게 끌릴 수 있습니다.
문서 관리의 일부 형태는 오픈 소스 프로젝트, 특히 문서 작성 프로세스, 방법 및 기타 텍스트 기반 프로젝트를 더 쉽게 만드는 경우에 종종 유용합니다. 많은 프로젝트에서 GitHub 또는 GitLab의 기본 제공 마크다운 텍스트 도구 기능을 사용하는 것이 편안하지만 다른 프로젝트에서는 Wiki 또는 기타 공유 편집 소프트웨어를 사용하는 것을 선호합니다.
잠재적인 Wiki 도구 옵션 목록은 Wikipedia에서 확인할 수 있습니다. 통신 도구에 적용되는 동일한 주의 사항이 여기에도 적용됩니다. 사용자와 개발자가 다른 플랫폼으로 마이그레이션하기로 결정할 때(그렇지 않은 경우가 아님) 모든 종류의 데이터 또는 도구 종속을 피할 수 있는 방법을 고려하십시오. -won 문서, 자주 묻는 질문 목록 및 방법 내용.
이 섹션에서는 성공적인 오픈 소스 프로젝트 출시에 필요한 최종 단계에 대해 논의하고 프로젝트에 대한 채택 및 기여를 유지하고 장려하는 방법에 대한 몇 가지 추가 정보를 제공합니다.
이 섹션이 끝나면 다음을 수행할 수 있습니다:
- 오픈 소스 프로젝트를 성공적으로 시작하는 데 필요한 마지막 단계를 설명합니다.
- 증가된 프로젝트 채택과 강력한 기여 파이프라인을 허용하는 강력한 커뮤니티 프로세스를 구축하는 방법을 설명합니다.
프로세스의 이 시점에서 시작을 준비하기 위해 소스 코드를 한 번만 마지막으로 통과하는 것이 좋습니다. 앞에서 설명한 프로세스를 따랐다면 큰 부담이 되지는 않겠지만 수정하기 쉬운 항목을 잊지 않도록 하는 것이 매우 도움이 될 수 있습니다.
특히, 이 최종 검토의 목표는 법률, 기술 및 마케팅 검토에서 식별된 모든 요구 사항이 완전히 충족되었는지 확인하는 것이어야 합니다. 찾아야 할 몇 가지 예는 다음과 같습니다:
- 라이선스, 저작자 표시 및 저작권 텍스트가 모두 완전하고 제자리에 있습니다.
- 소스 코드 스캐너는 깨끗한 BOM을 보고합니다.
- 모든 코드 라인은 릴리스에 적합하게 라이선스가 부여됩니다.
- 댓글은 일상적이거나 관련 없는 언어로 삭제됩니다.
- 소스 코드는 내부 프로젝트를 실수로 드러내지 않습니다.
- 소스 코드는 빌드될 만큼 충분히 완전합니다.
- 공개적으로 사용 가능한 도구를 사용하여 소스 코드 빌드
- 파일 및 함수 이름이 변경된 경우 프로젝트 이름을 반영
- MAINTAINERS 파일은 사용하는 경우 최신 상태입니다.
새 프로젝트를 공식적으로 시작하기 전에 조직과 커뮤니티 전체에 최고의 출시 경험을 보장하기 위해 할 수 있는 몇 가지 작업이 있습니다. 성공을 보장하기 위해 할 수 있는 가장 큰 일 중 하나는 출시 전에 임계 질량이 있는지 확인하는 것입니다.
새 프로젝트를 발표할 때 함께할 파트너와 고객을 식별해야 합니다. 코드에 익숙해지고 기여할 준비가 될 수 있도록 리포지토리에 대한 미리보기 액세스 권한이 있어야 합니다(또는 이미 기여하고 있음).
이것이 초기 오픈 소스 프로젝트 중 하나인 경우 개발자와 함께 빠르게 재검토하여 오픈 소스 커뮤니티에서 다른 사람들과 상호 작용할 것을 예상하여 오픈 소스 개발 방법 및 프로세스를 따르고 있는지 확인하는 것도 나쁘지 않습니다. 귀하의 프로젝트에 기여할 것입니다.
모든 프로젝트 인프라가 실행 중인지 확인한 후 내부 개발자가 프로젝트의 커뮤니케이션 도구에 참여하고 질문이나 새로운 기여를 모니터링하기 시작했는지 확인하십시오.
이제 중요한 순간을 맞이할 시간입니다! 마지막 남은 코드를 업로드하고 스위치를 전환하여 프로젝트를 전 세계에 라이브로 만들 수 있습니다.
이제 프로젝트가 시작되었으므로 앞으로 작업의 시작일 뿐입니다. 귀하의 조직이 계속해서 훌륭한 오픈 소스 시민인지 확인하고 다른 사람들이 귀하와 함께 프로젝트에서 함께 작업하도록 권장하는 방식으로 운영되도록 해야 합니다. 다음은 몇 가지 방법입니다:
- 공개적으로 대화하고 결정하기
- 이는 영업권을 구축하고 결정을 문서화할 때 오버헤드를 줄입니다.
- 이는 신규 참여자의 온보딩 프로세스를 간소화합니다.
- 열린 아카이브를 갖는 것은 참여자가 변경될 때 연속성을 보장합니다.
- 커뮤니티에 귀 기울이기
- 그들의 경험은 특히 통합 및 테스트에서 매우 중요합니다.
- 필요한 것을 확장하는 일반화된 구현을 장려합니다.
- 작업을 수행하는 유일한 회사인 것처럼 리소스를 할당합니다.
- 목표를 설정하고 달성할 수 있는 자원이 있는지 확인
- 이는 레버리지 개발 모델이 적용될 때까지 추진력을 구축합니다.
훌륭한 오픈 소스 시민이 되기 위해서는 노력이 필요하며 이타적이지 않습니다. 조직이 오픈 소스 프로젝트를 시작하는 데 투자한 투자에 대해 최상의 수익을 얻는 것은 좋은 비즈니스 관행입니다.
프로젝트가 시작된 후에는 외부 개발자 및 사용자 커뮤니티의 활력을 모니터링하는 것이 필수적입니다. 커뮤니티 구축은 자동으로 이루어지지 않습니다. 프로젝트의 초기 단계에서 추진력을 구축하기 위해 개발자 이벤트를 주최하거나 주요 회의에서 모임을 후원해야 할 수도 있습니다. 프로젝트 거버넌스 및 투명성에 대한 기대치를 관리하고 의무를 이행하는 것도 매우 중요합니다.
진행 중인 활동은 다음과 같습니다:
- 방향 또는 거버넌스에 대한 변경 사항이 명확하게 전달되도록 합니다.
- 다른 유사한 커뮤니티의 모범 사례를 따르십시오.
- 대면 커뮤니티 구축을 위한 기회를 장려하고 제공합니다.
- 적절한 이벤트를 식별하고 커뮤니티에서 토론을 제출하도록 합니다.
- 지역 모임을 고려하십시오
다양한 기여자 그룹을 구축함으로써 나중에 시간, 돈 및 기타 자원을 투자하는 데 관심이 있는지 결정하기 위해 작업을 가치 있다고 생각하는 다른 기업 및 조직과 토론하여 프로젝트를 다음 단계로 이동하기로 결정할 수 있습니다. 초기 노력을 확장합니다. 다른 사람들로부터 의견과 자원을 얻음으로써 프로젝트를 확장하고 확장하여 추가 기여자를 위해 더 많은 작업을 수행할 수 있습니다.
이러한 성장은 추가 기업이 자신의 개발자가 노력에 참여하도록 하기 위해 더 많은 돈을 기부하고 시작한 노력 뒤에 무게를 두어 작업을 진행하는 데 도움이 되기를 원할 수 있음을 의미합니다. 프로젝트의 중요성과 다른 회사에 미치는 영향에 따라 $10,000 또는 $250,000 이상이 포함될 수 있습니다. 프로젝트가 시작되면 다른 회사가 임무에 도움이 될 경우 작업에 자금을 기부할 수 있습니다.
기업과 조직이 해결하려는 기술 문제가 개별 문제보다 더 크다는 사실을 깨닫고 있기 때문에 오늘날에도 이러한 일이 정기적으로 발생합니다. 그 때 기업이 직면한 기술적 문제를 해결하는 데 더 큰 이익을 위해 일하는 벤더 중립적 공동 프로젝트에서 다른 회사와 함께 하는 전략적 가치를 볼 수 있습니다.
새로운 오픈 소스 프로젝트의 성공을 돕기 위해 고용할 수 있는 가장 중요한 역할 중 하나는 커뮤니티 옹호자(커뮤니티 관리자라고도 함)입니다. 이 사람의 역할은 커뮤니티를 성공시키는 데 필요한 모든 일을 하는 것입니다.
마케팅, 개발자 옹호, 비즈니스 개발, 위기 관리, 피스메이커 등 다양한 기술이 필요하기 때문에 실행하기 어려운 역할이며 고용하기 어려운 역할이 될 수 있습니다. 찾기 시작하기에 좋은 곳입니다. 이 역할의 누군가는 조직의 내부 개발 또는 마케팅 리소스를 고려하는 것입니다. 또한 기술 작가, 프로그램 관리자 또는 사회학, 심리학 등과 같은 비전통적인 연구 분야와 같은 사람들을 무시하지 마십시오.
훌륭한 커뮤니티 옹호자는 아무도 사용하지 않는 기술적으로 성공적인 프로젝트와 배포된 커뮤니티 구축 및 브리징 기술로 인해 비약적으로 성장하는 합리적으로 좋은 기술 프로젝트 간의 차이가 될 수 있습니다. Linux Foundation TODO Group은 커뮤니티 관리 리소스를 식별하는 데 도움이 되는 좋은 장소입니다.
모든 새로운 프로젝트 노력과 마찬가지로 자주 평가하고 예상했던 채택 및 기여도가 나타나지 않는 경우 접근 방식을 조정할 준비가 되어 있어야 합니다. 조직의 평판은 새로운 오픈 소스 프로젝트의 성공 여부를 결정짓는 방정식의 일부일 뿐임을 기억하는 것이 중요합니다.
커뮤니티에서 피드백을 제공할 때 유연성과 민첩성을 유지하면 협업하고 경청하기에 좋은 장소로 프로젝트의 명성을 높일 수 있습니다. 프로젝트가 시작되면 몇 가지 주요 메트릭을 살펴봐야 합니다:
- 초기 개발자 기반 외부의 코드 커밋/풀 요청 수
- 배포한 커뮤니케이션 채널에 대한 토론/주제 수
- 제출된 버그 보고서 또는 기능 요청 수
또한 부정적인 피드백이라도 커뮤니티가 프로젝트에 참여하고 있다는 것을 기억하는 것이 중요합니다. 투명성과 책임성을 실천하고 우려 사항을 공정하게 해결하려고 노력함으로써 프로젝트는 긍정적인 평판을 얻게 됩니다.
이 교육 과정 시리즈 전체에 걸쳐 반복된 격언인 '일찍 릴리스, 자주 릴리스'를 기억하십시오. 새 프로젝트가 첫날에 완벽할 필요는 없지만 이 격언을 염두에 두면 성공적이고 강력한 오픈 소스 노력을 구축하는 데 순조롭게 진행될 것입니다.