때가됐다.
당신은 당신이 사랑하고 오픈 소스 프로젝트에 당신의 비전을 추가하기 위해 오랫동안 열심히 노력해 왔으며, 당신이 일하고 토론하고, 예측할 수없는 양의 코드와 통찰력에 기여했습니다.
그러나 기존 개발자와는 해결되지 않습니다.
마지막으로 코드를 포크해야합니다.
이 작업을 어떻게 수행하고 기존 프로젝트에서 가능한 최상의 조건을 유지합니까? " 아 그래? 포크 해! "
교차 수분 의 역학을 제외하고 포크에 대한 추론이 건전하고 논리적이며 수용 가능하다고 가정하면 어떤 문제가 발생합니까?
경쟁? 자원 주입? 사용자 밀렵?
더 이상 문제로 간주되지 않을만큼 충분히 다양해질 때까지 어떻게이 어렵고 긴 과정을 겪고 있습니까?
의사 결정의 추론을 논의하기보다는 코드 포킹이 전체적으로 최상의 솔루션이라는 것을 이미 알고 있다고 가정 해 봅시다. 이제 요점은 가능한 최선의 방법으로 나아가는 것입니다.
-아담
답변:
자신의 코드 포크에서 작업하고 싶거나 커뮤니티를 조각화하고 싶습니까?
내부적으로 몇 가지 프로젝트를 진행했습니다. 우리는 변화를 가져 와서 소유자에게 전달하고, "고마워요"라고 말하고 어깨를 으 rug하고 내부적으로 가져 와서 우리 자신을 유지합니다.
마음, 이것들은 거대한 프로젝트가 아니라, 그것이 진행되는 방식입니다. 우리는 아무것도 출판하거나 사이트를 호스팅하지 않았습니다. 우리는 나머지 코드베이스로 고객에게 소스를 다운 스트림으로 보냅니다.
개발자 메일 링리스트보다 더 대중적인 방식으로 변경 사항을 "홍보"하라는 요구는 없었습니다.
원본과의 패리티를 유지하려면 패치 관리 및 병합 등을 적극적으로 수행해야합니다.
귀찮게하고 싶지 않다면 ...하지 마십시오. 자신의 프로젝트를 위해 단순히 포크 버전이 필요하지 않고 일반적인 의도가 아니라면 대중에게 공개 할 이유가 없습니다.
사용할 소스가 있으므로 사용하십시오.
대부분의 오픈 소스 프로젝트에서 "포크 (fork)"라는 단어는 따뜻하게 인식되지 않는 경우가 많으며, 특정 기능 세트를 개발하기 위해 "토픽 브랜치"에서 작업하도록 요청하는 것을 훨씬 더 환영합니다.
"포크"는 본질적으로 잠재적 경쟁자 인 반면 "토픽 브랜치"는 적어도 디자인에 의해 최종적으로 프로젝트에 합병 / 기여되는 것을 의미합니다.
먼저 실험적인 리팩토링을 원한다고 말하십시오. 당신은 당신이 놀고 싶은 아이디어 만 알고 있습니다. 그러나 이러한 변경 사항은 프로젝트의 주요 지점과의 호환성을 깨뜨려야 할 수 있으므로 변경 사항을 커밋하지 않으려 고합니다.
그런 다음 포크를 만듭니다. 물론 책임있는 개발자이므로 모든 코드를 개정 관리해야합니다. 런치 패드 또는 SourceForge 또는 Google 코드 등을 사용하십시오.
잠시 누워서 직접 작업하십시오. 그런 다음 신뢰하는 사람이 자신이 만든 것을 "보도록"하십시오. 그런 다음 다른 사람. 그 후 얼마 지나지 않아 소스를 보관할 때마다 간단한 프로젝트 웹 사이트를 만드십시오.
그때까지, 당신이 원래 프로젝트에서 작업하지 않았다고 생각한 사람들도 아마 움직일 것이므로, 아무도 기분을 상하게 할 사람은 없습니다. 새 프로젝트가 추종자를 얻으면 원래 프로젝트의 활동이 감소합니다.
Codelogic의 의견 :
권리; 나는 OP가 떠나고 싶은 사람들이 스스로 프로젝트를 유지할 수 없다고 가정했습니다.
나는 "조직은 살아남고 사람들은 그렇지 않다"고 말했다. 즉, 남은 팀이 그 사람이 떠난 진공 상태를 보상 할 수 없도록 프로젝트에 중요한 사람은 없습니다.
그러나 오픈 소스에서는 창립자없이 프로젝트를 수행 할 의지, 재능 및 시간이 아무도 없다는 것이 사실 입니다.