팀에서 개발할 새로운 오픈 소스 제품에 기여할 수 있을지 궁금합니다. 우리가 할 수있는 한 더 넓은 지역 사회로부터 많은 지원을 받도록 격려하고 있지만, 사무실 외부에있는 제 3자가 코드 품질과 같은 일을 처리하고 있음을 확인하는 데 많은 시간이 걸리는 것을 볼 수 있습니다. 또한 프로젝트가 시작될 때 핵심 팀 내에서 시스템 디자인, 스파이크 등의 디자인에 대해 많은 비공식 토론을 할 수 있으며 커뮤니티 참여를 허용하기 위해 온라인으로 가져가는 데 많은 시간이 소요될 수 있습니다. 덜 효과적인 토론.
고려해야 할 더 인간적인 측면이 있습니다. 디자인 프로세스에 커뮤니티 참여를 허용하면 프로젝트의 소유 소유권과 관련하여 이점이있을 수 있으며 초기 참여가 핵심 문제를 해결할 수있는 기회는 항상 있습니다 팀은 눈치 채지 못했다.
질문 : 오픈 소스 프로젝트의 어느 단계에서 커뮤니티의 기여를 초대해야합니까?
답변
처음부터! 당신은 지역 사회가 그들이 당신의 프로젝트에 진정한 지분을 가지고 있다고 느끼기를 원합니다. 그렇지 않으면 그들은 자유 노동으로 사용되는 것처럼 느낄 것입니다.
모든 커뮤니케이션은 공개 메일 링리스트 나 포럼을 통해 이루어져야하므로 커뮤니티의 아이디어가 향상됩니다.
메일 링리스트에 대한 초기 게시물에 명확한 비전을 제시하여 ‘위원회 별 디자인’문제를 완화 할 수 있습니다.
“우리는 (JIRA-4에 따라) Pet Store를 대표하는 도메인 모델을 찾고 있습니다.이 모델과 관련하여 큰 문제가있는 사람이 있습니까?”
실제 물리적 기여를 받아들이려면 먼저 패치를 수락하고 공개 코드 검토를 수행해야합니다. 그렇게하면 기고자는 이미 어떤 종류의 코딩 표준을 준수해야하는지 공개적으로 확인할 수 있습니다. 커밋이 커밋 메일 링리스트에서 사용 가능한지 확인하십시오-동일한 표준을 가지고 있어야합니다!
또한 위키 나 그와 같은 문서에 프로젝트 표준을 세우는 데 비용을 지불합니다.
읽기 http://www.producingoss.org을 성공적으로 오픈 소스 프로젝트를 실행하는 방법에 대한 자세한 내용은.
답변
이것은 브라이언 피츠 패트릭 (Brian Fitzpatrick)과 서브 콜린스 (Brian Collins-Sussman)의 구글 프로그래머 ( Google IO talk )에서 유능한 프로그래머의 신화 에서 오랫동안 논의되었다 . 요컨대 그들은 아직 아무것도 없어서 아직 아무것도 없어야한다는 결론을 내 렸습니다 (예 : “내 멋진 프로젝트를 보러 오세요! 아직 여기에는 많지 않지만 많은 멋진 것들이 계획되어 있습니다!”) 그래서 모든 결정은 이미 이루어졌습니다 (솔로 프로젝트에 대한 정보를 얻기는 어렵습니다.)
답변
나는 Martijn Verburg에 동의합니다 . 처음부터 기부를 요청해야합니다. 나는 전에 이것에 대해 조금 썼다 .
그 게시물의 요약은 소프트웨어가 썩었다는 것입니다. 신선하게 유지하려면 유지 관리를해야합니다. 프로젝트의 인기가 높을수록 더 많은 버그가 발견되고 더 많은 기능이 추가되며이 유지 관리 작업이 더 많이 진행됩니다.
실제로 이것은 매우 일반적인 문제입니다. Fat 는 오픈 소스 란 무엇인가? 왜 그렇게 유죄라고 느끼는가? 이 강연에서 (나는 당신을 강력히 추천합니다) 그는 OSS 프로젝트 중 하나의 이야기를 이야기하고 시간이 지남에 따라 티켓 심사 및 관리 작업을 수행하는 자유 시간의 대부분을 보냈습니다. 그리고 그는 이것이 얼마나 해로운 지 이야기합니다. 그것은 내가 완전히 공감할 수있는 것입니다.
물론 해결책은 사람들을 프로젝트에 일찍 그리고 자주 추가하는 것입니다. 당신의 시간은 제한적이고 가치가 있습니다. 기고자 기반을 늘리는 데 투자하면 나머지 문제는 스스로 해결하기 시작합니다.
필자가 말한 것처럼 “프로젝트에서 더 중요한 것은 무엇입니까? 기능 또는 미래? 하나를 선택하고 그에 따라 노력을 우선시하십시오.”