Bien démarrer un projet open source

C'est l'heure.

Vous avez travaillé longtemps et dur pour ajouter votre vision au projet open source que vous aimez, sur lequel vous avez travaillé, débattu et auquel vous avez apporté une quantité inestimable de code et de connaissances.

Mais cela ne fonctionnera pas avec les développeurs existants.

Vous devez enfin bifurquer le code.

Comment faire et rester dans les meilleures conditions possibles avec le projet existant? Comment ne dites-vous pas: " Oh ouais? Fourchez-vous! "

Mis à part la mécanique de la cross-polination et en supposant que le raisonnement pour la fourche est solide, logique et acceptable, quels problèmes se posent?

Concurrence? Sappage des ressources? Braconnage des utilisateurs?

Comment traversez-vous ce processus sans doute difficile et long jusqu'à ce que vous vous soyez suffisamment diversifié pour que ces problèmes ne soient plus considérés comme des problèmes?

Plutôt que de discuter du raisonnement derrière la décision, supposez que vous avez déjà été convaincu que forder le code est la meilleure solution globale, et maintenant il s'agit d'avancer de la meilleure façon possible.

-Adam

Vous souhaitez travailler sur votre propre fork du code ou souhaitez-vous fragmenter la communauté?

Nous avons bifurqué en interne quelques projets. Nous ferions un changement, l'expédierions aux propriétaires, ils diraient "non merci", et nous hausserions les épaules et l'apporterions en interne et le maintiendrions nous-mêmes.

Attention, ce n'étaient pas des projets énormes, mais c'est comme ça que ça se passe. Nous n'avons rien publié, hébergé un site ou quoi que ce soit. Nous poussons simplement la source en aval vers nos clients avec le reste de la base de code.

Il n'y avait tout simplement aucun appel pour que nous «promouvions» nos changements de façon plus publique que la liste de diffusion des développeurs.

Si vous voulez maintenir la parité avec l'original, vous devrez être agressif sur la gestion des correctifs, la fusion, etc.

Si vous ne voulez pas vous embêter, alors ... ne le faites pas. Aucune raison d'en faire une annonce publique à moins que ce ne soit l'intention générale, plutôt que d'avoir simplement besoin d'une version fourchue pour vos propres projets.

La source est là pour être utilisée, alors utilisez-la.

Dans la plupart des projets open source, le mot «fork» n'est pas souvent aussi bien perçu, j'ai personnellement fait l'expérience que demander de travailler sur une «branche de sujet» afin de développer un ensemble spécifique de fonctionnalités est beaucoup plus apprécié.

Et cela n'a de sens que: les «fourches» sont par nature des concurrents potentiels, tandis que les «branches thématiques» sont - au moins par conception - destinées à être éventuellement fusionnées / réinvesties dans le projet.

Dites d'abord que vous voulez juste faire un refactoring expérimental. Vous savez, juste quelques idées avec lesquelles vous voulez jouer. Mais ces modifications peuvent nécessiter une rupture de la compatibilité descendante avec la branche principale du projet, vous ne devez donc pas y valider les modifications.

Créez ensuite votre fourchette. Bien sûr, vous êtes un développeur responsable, vous mettez donc tout le code sous contrôle de révision. Utilisez Launchpad ou SourceForge ou Google Code ou autre.

Allongez-vous pendant un moment et travaillez-y vous-même. Demandez ensuite à quelqu'un en qui vous avez confiance de «jeter un œil» à ce que vous avez créé. Puis un autre. Quelque temps après cela, créez un site Web de projet simple où que vous conserviez votre source.

À ce moment-là, les gens que vous pensiez ne pas travailler sur le projet d'origine auront probablement également évolué, il n'y aura donc plus personne pour offenser. L'activité du projet d'origine diminuera à mesure que votre nouveau projet gagnera des abonnés.

Commentaire de codelogic:

Droite; Je supposais que les personnes que le PO veut laisser derrière lui ne sont pas capables de soutenir le projet par elles-mêmes.

J'ai entendu dire: «les organisations survivent, les gens non». Autrement dit, aucune personne n'est si critique pour un projet que l'équipe restante ne peut pas compenser le vide laissé par le départ de cette personne.

Cependant, en open source, il est parfois vrai que personne n'a la volonté, le talent et le temps de mener un projet sans le fondateur.