Realmente no hay nada de malo en hacerlo, siempre y cuando todos puedan soportar los costos, beneficios y riesgos.
... la solución parece bastante simple ... parchear el código yo mismo
Cuando tienes un trabajo que hacer, perfecto (tener una biblioteca de terceros que es exactamente lo que quieres) es el enemigo de lo suficientemente bueno (parcharlo tú mismo), y a veces tienes que hacer cosas como esas. He realizado una serie de proyectos en los que hemos comprado licencias de origen para bibliotecas comerciales para que podamos solucionar los problemas antes de que el proveedor llegue a ellos.
... los detractores quieren argumentar que esto es casi siempre una mala idea, ya que es arriesgado e introduce una complejidad problemática.
Es una mala idea si no tiene las habilidades para manejar la disección del código de otra persona, identificar un problema y escribir una solución. Eso es cierto si el código es interno o de un tercero; la única diferencia es si se arrojó sobre un cubículo o una pared del edificio antes de aterrizar en su regazo.
Si sus detractores simplemente están dejando de lado la idea sin sopesar los costos de no hacer este parche, no están haciendo su tarea. Si tiene una gran cantidad de código interno que se ve afectado por el error que corregirá su parche, deberá revisarlo y cambiarlo para evitarlo y volver a probar todo para asegurarse de que funciona correctamente. Luego, si alguna vez actualiza el paquete a una versión corregida, puede que tenga que encontrar y eliminar sus soluciones y volver a probar. También existe el riesgo de hacerlo, como perder un caso que cambió o pruebas insuficientes. Personalmente, si tengo la oportunidad de corregir un error en su origen, prefiero hacerlo allí que perseguir el resto del código con un matamoscas y espero obtener todo.
... el cambio de código lo hicimos nosotros ... debe ser parte de nuestra base de código ... debemos presentarlo como un nuevo proyecto e incorporar su compilación automatizada en nuestro proceso de compilación.
Si está haciendo un parche, el parche es parte de su propio código, lo que significa que debe hacerlo parte de su proceso. Esto no es diferente a agregar algo que sea 100% su código a su sistema. Trate la distribución de terceros como sacrosanta y colóquela en un módulo como si fuera el código fuente. Cualquier parche que escriba se almacena con él en archivos separados y se aplica como parte del proceso de compilación. De esa manera, siempre pasa de una fuente limpia a una fuente parcheada a un producto construido y puede mostrar exactamente lo que está sucediendo. (Algunas personas desempacan, parchan a mano, vuelven a empacar y almacenan eso en el control de versiones. Eso es malo).
... estaríamos extrayendo su código de su repositorio de control de origen al nuestro, y perdemos el historial detrás de cualquier cambio de código ...
Si está tratando la biblioteca de terceros como una dependencia de terceros, no tiene ese historial para empezar y no está perdiendo nada. Si tiene acceso continuo al repositorio de un tercero, puede consultarlo si lo necesita. Los lanzamientos de terceros deben tratarse como blobs amorfos que usted verifica en su propio sistema sin alteraciones. Si necesita ver los cambios entre la versión que está utilizando y las versiones posteriores, puede hacerlo y, si lo desea, encontrar parches para la versión anterior que incorporen los cambios que desee.
Además, parece algo demasiado complicado para un cambio de código tan pequeño que debe hacerse.
Si su proceso de compilación es lo suficientemente sofisticado, agregar esto no debería ser más difícil que agregar su propio código. Hay una pequeña cantidad de trabajo para llegar al punto en que el proceso de desempaquetado / parche / compilación es automático, pero una vez que se hace, se hace para siempre. Puede haber un error ahora, pero podría haber veinte en el futuro. Si lo hay, será mucho más feliz de haber sentado las bases para apoyar todo eso ahora, porque hará que lidiar con los próximos 19 sea mucho menos trabajo.