Bifurcando un proyecto de código abierto muy bien

Es la hora.

Has trabajado mucho y duro para agregar tu visión al proyecto de código abierto que amas, en el que has trabajado, debatido y al que has contribuido cantidades inestimables de código y conocimiento.

Pero no va a funcionar con los desarrolladores existentes.

Finalmente necesitas bifurcar el código.

¿Cómo haces esto y te mantienes en los mejores términos posibles con el proyecto existente? ¿Cómo no dices, " Oh sí? ¡Bifurcarte! "

Además de la mecánica de la polinización cruzada y de suponer que el razonamiento de la bifurcación es sólido, lógico y aceptable, ¿qué problemas surgen?

¿Competencia? ¿Aprovechamiento de recursos? ¿Caza furtiva de usuarios?

¿Cómo atraviesas este proceso posiblemente difícil y largo hasta que te hayas diversificado lo suficiente como para que ya no se vean como problemas?

En lugar de discutir el razonamiento detrás de la decisión, suponga que ya se ha convencido de que bifurcar el código es la mejor solución general, y ahora el punto es avanzar de la mejor manera posible.

-Adán

¿Desea trabajar en su propia bifurcación del código o quiere fragmentar la comunidad?

Hemos bifurcado internamente un par de proyectos. Haríamos un cambio, lo enviaríamos a los propietarios, ellos dirían "no, gracias", y nos encogeríamos de hombros y lo traeríamos internamente y lo mantendríamos nosotros mismos.

Tenga en cuenta que estos no fueron proyectos enormes, pero así son las cosas. No hemos publicado nada, alojado un sitio o lo que sea. Simplemente enviamos la fuente a nuestros clientes con el resto del código base.

Simplemente no había ningún llamado para que "promocionáramos" nuestros cambios de una manera más pública que la lista de correo de desarrollo.

Si desea mantener la paridad con el original, entonces tendrá que ser agresivo en la gestión de parches, la fusión y lo que sea.

Si no quieres molestarte, entonces ... no lo hagas. No hay razón para hacer algo público al menos que esa sea la intención general, en lugar de simplemente necesitar una versión bifurcada para sus propios proyectos.

La fuente está ahí para ser utilizada, así que úsela.

En la mayoría de los proyectos de código abierto, la palabra "bifurcación" a menudo no se percibe tan cálidamente, personalmente he hecho la experiencia de que es mucho más bienvenido pedir trabajar en una "rama temática" para desarrollar un conjunto específico de características.

Y esto solo tiene sentido: los "tenedores" son competidores potenciales por naturaleza, mientras que las "ramas temáticas", al menos por diseño, están destinadas a ser fusionadas / contribuidas al proyecto.

Primero di que solo quieres hacer una refactorización experimental. Ya sabes, solo algunas ideas con las que quieres jugar. Pero estos cambios pueden requerir romper la compatibilidad con la rama principal del proyecto, por lo que no debe confirmar los cambios allí.

Luego crea tu tenedor. Por supuesto, usted es un desarrollador responsable, por lo que coloca todo el código bajo control de revisión. Use Launchpad o SourceForge o Google Code o lo que sea.

Acuéstate un rato y solo trabaja en ello tú mismo. Luego, haga que alguien de su confianza "eche un vistazo" a lo que ha creado. Luego otro alguien. Algún tiempo después de eso, crea un sitio web de proyecto simple donde sea que guardes tu fuente.

Para entonces, las personas que creías que no estaban trabajando en el proyecto original probablemente también se habrán mudado, por lo que no quedará nadie para ofender. El proyecto original disminuirá en actividad a medida que su nuevo proyecto gane seguidores.

Re comentario de codelogic:

Correcto; Supuse que las personas que el OP quiere dejar atrás no son capaces de sostener el proyecto por sí mismas.

He oído decir: "las organizaciones sobreviven, la gente no". Es decir, ninguna persona es tan crítica para un proyecto que el equipo restante no puede compensar el vacío dejado por la partida de esa persona.

Sin embargo, en código abierto, a veces es cierto que nadie tiene la voluntad, el talento y el tiempo para ejecutar un proyecto sin el fundador.