Forking un progetto open source piacevolmente

È tempo.

Hai lavorato a lungo e duramente per aggiungere la tua visione al progetto open source che ami, sul quale hai lavorato, discusso e al quale hai contribuito quantità inestimabili di codice e intuizione.

Ma non funzionerà con gli sviluppatori esistenti.

Alla fine devi inserire il codice.

Come si fa a farlo e rimanere nelle migliori condizioni possibili con il progetto esistente? Come non dire " Oh sì? Fork te! "

A parte i meccanismi della cross-polination e supponendo che il ragionamento per il fork sia solido, logico e accettabile, quali problemi sorgono?

Concorrenza? Zapping delle risorse? Il bracconaggio dell'utente?

Come si fa a superare questo processo probabilmente lungo e difficile fino a quando non si è abbastanza diversificati da non essere più visti come problemi?

Piuttosto che discutere il ragionamento alla base della decisione, supponiamo che tu sia già stato convinto che il fork del codice sia la migliore soluzione complessiva, e ora il punto è andare avanti nel miglior modo possibile.

-Adamo

Vuoi lavorare sul tuo fork del codice o vuoi frammentare la community?

Abbiamo biforcato internamente un paio di progetti. Faremmo un cambiamento, lo spediremmo ai proprietari, loro direbbero "no grazie", e scrolleremmo le spalle e lo porteremmo internamente e lo manterremmo da soli.

Mente, questi non erano progetti enormi, ma è così che vanno. Non abbiamo pubblicato nulla, ospitato un sito o altro. Spingiamo semplicemente la sorgente a valle verso i nostri clienti con il resto della base di codice.

Semplicemente non ci è stato alcun invito a "promuovere" i nostri cambiamenti in modo più pubblico rispetto alla mailing list degli sviluppatori.

Se vuoi mantenere la parità con l'originale, dovrai essere aggressivo nella gestione delle patch, nella fusione e quant'altro.

Se non vuoi disturbarti, allora ... non farlo. Nessun motivo per renderlo pubblico a meno che non sia l'intento generale, piuttosto che semplicemente bisogno di una versione biforcuta per i tuoi progetti.

La fonte è lì per essere utilizzata, quindi usala.

Nella maggior parte dei progetti open source, la parola "fork" non è spesso così calorosamente percepita, ho personalmente fatto l'esperienza che chiedere di lavorare su un "ramo tematico" al fine di sviluppare un set specifico di funzionalità è molto più apprezzato.

E questo ha senso solo: le "forcelle" sono per natura potenziali concorrenti, mentre le "branche tematiche" sono - almeno in base alla progettazione - destinate ad essere eventualmente unite / contribuite al progetto.

Per prima cosa dì che vuoi solo fare un po 'di refactoring sperimentale. Sai, solo alcune idee con cui vuoi giocare. Ma queste modifiche possono richiedere la rottura della compatibilità con le versioni precedenti del ramo principale del progetto, quindi non si desidera impegnare le modifiche lì.

Quindi crea il tuo fork. Naturalmente sei uno sviluppatore responsabile, quindi metti tutto il codice sotto controllo di revisione. Usa Launchpad o SourceForge o Google Code o altro.

Sdraiati per un po 'e lavoraci da solo. Quindi chiedi a qualcuno di cui ti fidi di "dare un'occhiata" a ciò che hai creato. Quindi un altro qualcuno. Qualche tempo dopo, crea un semplice sito web di progetto ovunque tieni la tua fonte.

A quel punto, anche le persone che pensavi non stessero lavorando al progetto originale sarebbero probabilmente andate avanti, quindi non rimarrà nessuno a offendere. Il progetto originale diminuirà di attività man mano che il tuo nuovo progetto guadagna follower.

Commento di Re codelogic:

Destra; Supponevo che le persone che l'OP voleva lasciare alle spalle non fossero in grado di sostenere il progetto da sole.

Ho sentito dire: "Le organizzazioni sopravvivono, la gente no". Cioè, nessuna singola persona è così critica per un progetto che la squadra rimanente non può compensare un vuoto lasciato dalla partenza di quella persona.

Tuttavia, nell'open source, a volte è vero che nessuno ha la volontà, il talento e il tempo per eseguire un progetto senza il fondatore.