時間です。
あなたは、あなたが愛しているオープンソースプロジェクトにあなたのビジョンを追加するために長く一生懸命働いてきました。
しかし、既存の開発者とはうまくいきません。
最後に、コードをフォークする必要があります。
これをどのように行い、既存のプロジェクトで可能な限り最高の条件を維持しますか？「ああ、そうですか、フォーク！」と言わないでください。
クロスポリネーションのメカニズムおよび分岐の理由が健全で、論理的で、許容できると仮定する以外に、どのような問題が発生しますか？
コンペ？リソースのサッピング？ユーザーの密猟？
これらがもはや問題と見なされなくなるほど十分に多様化するまで、この間違いなく困難で長いプロセスをどのように経ますか？
決定の背後にある理由を議論するのではなく、コードの分岐が最良の全体的な解決策であるとすでに確信していると仮定してください。そして今、ポイントは可能な限り最善の方法で前進することです。
-アダム
回答:
独自のコードの分岐に取り組みたいですか、それともコミュニティを断片化したいですか？
内部でいくつかのプロジェクトを分岐させました。私たちは変更を加え、所有者にそれを出荷し、彼らは「感謝しない」と言い、肩をすくめて内部に持ち込み、自分でそれを維持します。
心は、これらは巨大なプロジェクトではありませんでしたが、それはまさにその方法です。何も公開しておらず、サイトをホストしていません。残りのコードベースを使用して、ソースをクライアントにダウンストリームにプッシュするだけです。
開発者のメーリングリストよりも公的な方法で変更を「促進」することは、私たちに単に要求されませんでした。
オリジナルと同等に保ちたい場合は、パッチ管理やマージなどに積極的に取り組む必要があります。
気にしたくない場合は、...しないでください。それが一般的な意図でない限り、あなた自身のプロジェクトのためにフォークされたバージョンを単に必要とするのではなく、それについて公開する理由はありません。
ソースは使用するためにありますので、使用してください。
ほとんどのオープンソースプロジェクトでは、「フォーク」という言葉はそれほど温かく感じられることはあまりありません。特定の機能セットを開発するために「トピックブランチ」で作業するように依頼することは大歓迎です。
そして、これは理にかなっています。「フォーク」は本質的に潜在的な競合他社であり、「トピックブランチ」は、少なくとも設計上、最終的にプロジェクトにマージ/貢献されることを意味します。
まず、実験的なリファクタリングを行いたいだけだと言います。あなたが知っている、あなたがプレイしたいいくつかのアイデア。ただし、これらの変更により、プロジェクトのメインブランチとの下位互換性を壊すことが必要になる場合があるため、そこで変更をコミットする必要はありません。
次に、フォークを作成します。もちろんあなたは責任ある開発者なので、すべてのコードを改訂管理下に置きます。LaunchpadまたはSourceForgeまたはGoogle Codeなどを使用します。
しばらく横になって、自分で作業してください。次に、信頼できる人に、作成したものを「見て」もらいます。それから別の誰か。その後しばらくして、ソースを保管している場所ならどこにでも簡単なプロジェクトWebサイトを作成します。
その時までに、元のプロジェクトで作業していないと思っていた人たちもおそらく移動しているので、気分を害する人は誰もいないでしょう。新しいプロジェクトがフォロワーを獲得すると、元のプロジェクトの活動は低下します。
codelogicのコメントについて：
右; 私は、OPが残したい人たちが自分でプロジェクトを維持できないと思っていました。
「組織は存続するが、人々は存続しない」と言われたと聞きました。つまり、プロジェクトにとって重要な人は一人もいないので、残りのチームはその人の出発によって残された空白を補うことができません。
しかし、オープンソースでは、創立者なしでプロジェクトを実行する意志、才能、時間を誰も持っていないというのは事実です。