¿Cuál es la respuesta canónica a "es de código abierto, enviar un parche"? [cerrado]

Es un punto difícil: dado que el usuario no paga directa o indirectamente un producto, no puede solicitar que se implemente una función. No es como si fuera un interesado o un cliente directo que ordenó el producto, y ni siquiera un usuario final de un producto comercial.

Dicho esto, "enviar un parche" no es una respuesta válida. No es cortés. No es correcto. Incluso para un producto de código abierto. "Enviar un parche" es la versión corta de:

  

"no nos importa si le gusta nuestro producto o no. Vaya y modifíquelo si lo desea, pero no nos moleste con las solicitudes de sus clientes".

¿Qué hay de enviar un parche?

Bueno, no es tan fácil. Para hacerlo:

• Debe conocer los idiomas utilizados en el proyecto de código abierto.

• Debe poder cargar el código fuente desde el control de versión para poder modificarlo.

• Debe tener todas las versiones correctas de las dependencias de compilación instaladas (incluidas las bibliotecas de tiempo de ejecución y las herramientas de compilación).

• Debes poder compilar este código fuente , que no es tan obvio en algunos casos. Especialmente, cuando un gran proyecto demora algunas horas en compilarse y muestra 482 errores y miles de advertencias, puede ser valiente para buscar el origen de esos errores.

• Debe comprender muy bien cómo se realiza el proyecto , cuál es el estilo de codificación que se debe utilizar, si corresponde, cómo ejecutar pruebas unitarias, etc. Si el proyecto no tiene una documentación decente (que suele ser el caso de los proyectos de código abierto), puede ser realmente difícil.

• Debe adaptarse al proyecto y a los hábitos de los desarrolladores que participan activamente en el proyecto. Por ejemplo, si usa .NET Framework 4 a diario, pero el proyecto usa .NET Framework 2.0, no puede usar LINQ, ni los contratos de código, ni otras miles de nuevas características de las últimas versiones del marco.

• Su parche debe ser aceptado (a menos que haga el cambio solo para usted, sin la intención de compartirlo con la comunidad).

Si su intención es participar activamente en el proyecto, entonces puede hacer todas esas cosas e invertir su tiempo para ello. Si, por otro lado, solo hay un pequeño error molesto o una característica simple que falta, pasar días, semanas o meses estudiando el proyecto, entonces hacer el trabajo en sí mismo en unos pocos minutos es irrazonable, a menos que te guste.

Entonces, ¿hay una respuesta canónica a "es de código abierto, enviar un parche"? No lo creo. O le explicas a la persona que es descortés, o simplemente dejas de hablar con ella.

La réplica canónica es enviar un parche.

Esta es la respuesta estándar cuando los desarrolladores creen que no podrán hacer algo en un plazo de tiempo razonable, pero se ha repetido.

Es más injusto cuando se lo menciona repetidamente, pero la persona que lo mencionó más recientemente no lo sabe, y simplemente se pone "estamos tomando parches para eso" de inmediato. En este caso, el mantenedor está harto de la discusión, pero el usuario piensa que es un tema nuevo. De todos modos, lo más probable es que si obtienes "parches" de inmediato, no deberías hacerlo personalmente, sino que quizás quieras leer los archivos y el rastreador de errores para obtener más detalles sobre el problema.

Si usted mismo presenta una solicitud repetidamente, "tomar parches" podría ser una eliminación relativamente educada, en lugar de algunas alternativas menos educadas ...

Y luego, por supuesto, hay personas groseras que dicen "llevar parches" sin explicación alguna a nadie, pero yo diría que es una minoría.

Si alguna vez ha mantenido un proyecto de código abierto con muchos usuarios, sabrá que hay 100 veces más solicitudes de las que los mantenedores podrían obtener, y muchas de esas solicitudes son importantes para el solicitante, pero serían escandalosamente difícil, o interrumpiría a muchos otros usuarios, o tendría algún otro defecto que solo sea visible con una comprensión global del proyecto y la base de código. O a veces solo hay llamadas de juicio, y lleva mucho tiempo discutirlas una y otra vez.

La mayoría de las compañías que no son de código abierto no le darán acceso a los desarrolladores en absoluto, y solo recibirá el tratamiento silencioso o una historia cortés pero falsa de la atención al cliente. Entonces, en código abierto al menos tienes algunas opciones (pagarle a alguien para que codifique la característica, etc.) y aunque los desarrolladores pueden ser groseros, al menos dan respuestas directas. Prefiero tener "no" a lo habitual "está en nuestra hoja de ruta ... [2 años más tarde] ... todavía está en nuestra hoja de ruta" algo que he recibido de varios proveedores ...

Así que no creo que haya una réplica. Tal vez el mantenedor de código abierto esté realmente ocupado, quizás sea un imbécil, pero de cualquier manera, es probable que tengan un trabajo difícil y entablar un debate sobre quién tiene la última palabra no va a ninguna parte. Lo mejor que puedes hacer es contribuir de alguna manera e intentar ser constructivo.

Tal vez no sea un código, pero posiblemente hay mucho análisis y documentación de los escenarios de usuario que podría hacer. Cuando mantenía el gestor de ventanas de GNOME, muchas veces hubiera sido útil que las personas analizaran un problema globalmente teniendo en cuenta a todos los usuarios , , y realmente escribieran los problemas, los pros y los contras y lo que debería suceder. desde una perspectiva global.

(En lugar de eso, lo habitual era comenzar a flamear como si fueran el único usuario que importaba y no hubo concesiones. Y si bien eso fue genial, fue un punto de datos y, a menudo, logré ser educado o incluso resolver su problema eventualmente ... las llamas no hacen que nada suceda más rápido. Simplemente confunde las emociones en el tema y desperdicia el tiempo de todos.)

La razón por la que obtienes esta respuesta no es que los mantenedores sean idiotas, es que no los has convencido adecuadamente de la propuesta de valor de ellos trabajando en la función tu para ti .

La mejor respuesta es iniciar un diálogo sobre el valor de su función para su comunidad en general , para ver si puede convencerlos de que cambien de opinión. Tal vez tienen razón y saben más acerca de las necesidades de su propia comunidad que tú, pero, de nuevo, quizás no.

Si la función solo es valiosa para usted y tiene poco o ningún valor para la comunidad, creo que el dinero es un motivador excelente, mientras que no es una queja su queja.

  

¿Cuál es la respuesta canónica a "es de código abierto, enviar un parche"?

No hay una réplica razonable que pueda hacer alguna diferencia. Intentar persuadir a los voluntarios para que hagan algo que no tienen intención de hacer es una pérdida de tiempo ... o peor.

Sus opciones son:

• Haz lo que sugiere la respuesta; es decir, implementar la función y enviarla como un parche. Se llama "devolver algo".

• Encuentre a alguien que esté dispuesto a implementar la función por dinero real. Podría ser el proyecto en sí mismo (por ejemplo, a cambio de patrocinio), alguien asociado con el proyecto, o algún "programador para contratar" al azar.

• Encuentre un producto alternativo.

Si recibió esta respuesta cuando hizo una sugerencia "útil", considere cómo podría haber respondido si estuviera en su lugar. Por ejemplo, ¿cómo respondería USTED si pensara que la sugerencia no valía la pena / bien pensada / inteligible / etc, pero no tenía el tiempo o la paciencia para participar en un debate prolongado?

He estado involucrado en un proyecto de SO de código abierto de larga ejecución, y una de las cosas más molestas es la gente que se sienta en la "galería de cacahuetes" y le ofrece una serie de sugerencias sobre cómo hacer las cosas "mejor":

• son incompletos, ininteligibles o simplemente sin sentido,
• son ideas no probadas con una probabilidad objetivamente baja de éxito,
• requeriría una gran cantidad de esfuerzo para implementar, y / o
• son contrarios a los objetivos declarados del proyecto.

A menudo, la mejor respuesta es desafiar intencionalmente a la persona para que se involucre en el proyecto ... y esperar que tome la sugerencia ... de "levantarse o callarse". Desafortunadamente, los más molestos ni siquiera dan una pista.

Por supuesto, la otra respuesta a esas personas es no responder en absoluto, o ignorarlas por completo.

La respuesta sería razonable si usted y el programador en cuestión fueran iguales, y supieran lo mismo sobre el código base y el lenguaje y todas las demás cosas relevantes para esta cosa en particular que está señalando.

No eres igual (o probablemente lo hubieras hecho), por lo que sugeriría una respuesta adecuada:

"No hay forma de que pueda hacerlo tan rápido y tan bien como puedas, por eso te pedí que me ayudaras en primer lugar. ¡Por favor!"

Creo que va en contra de la naturaleza humana fundamental decir entonces "oh, sí, he pasado mucho tiempo y es realmente bueno, es tan simple que cualquiera puede venir desde la calle y hacer lo mejor. un trabajo como I puede ".

La réplica canónica es para bifurcar el proyecto.

La respuesta canónica a "enviar un parche" es:

  

"No tengo las habilidades, la experiencia   o el tiempo requerido así que puedes por favor   dime donde enviar los casos de   Cerveza para el chico que puede hacerlo por mí "

Envíe un caso de prueba completo.

"Si lo haces, lo incluiré" es mucho mejor que "no".

Si no puede hacer el trabajo por una razón u otra, explique las circunstancias al encargado del proyecto en privado.

Si no está dispuesto a contribuir de alguna manera a un proyecto de código abierto que le gustaría usar, entonces debería buscar soporte comercial u otro producto comercial.

"Gracias por la respuesta".

Porque:

• A precio cero, la demanda (solicitudes de características) excede la oferta (los codificadores disponibles para implementar dichas características).
• Ragging en todo lo que se ofrece gratis carece de clase IMHO.
• Este es el punto central de FOSS: personas que traen verduras y carne para agregar nutrición a la sopa de piedra. Si no puedo aportar algo, entonces debería estar agradecido de poder comer, y no quejarme de que no estoy comiendo mejor.

No tienes que decir nada. El hecho mismo de que los desarrolladores hayan respondido es un indicio suficiente de que ya saben que el problema existe y que causa dolor a (al menos algunos) usuarios.

Al final del día, nada de lo que digas va a convencer al desarrollador de que trabaje para ti si no lo desea.

Un buen proyecto de código abierto tendrá un sistema de solicitud de errores / características donde los usuarios pueden enviar errores / características y otros pueden votar sobre ellos para que los mantenedores puedan identificar lo que es importante para la comunidad en general. Sin embargo, la forma más rápida de colocar su función es enviar un parche para ella. Período ... no hay manera de evitar eso.

Personalmente, prefiero obtener una respuesta de "Este es un problema conocido, pero desafortunadamente no es un problema que se esté resolviendo en el futuro. Los desarrolladores están trabajando en otros problemas. No hay ETA en este momento".

La respuesta "enviar un parche" es muy grosera, ya que supone varias cosas:

1. Todos los usuarios del programa son programadores o todos los informadores de errores son programadores.
2. Todos los programadores saben el idioma en el que se encuentra el programa.
3. Todos los programadores conocen todos los problemas que puede tener un programa de cualquier tipo.
4. Todos los programadores tienen tiempo libre para trabajar en un proyecto de código abierto.

Incluso si asumimos que el fabricante de la respuesta "enviar un parche" sabe todo lo anterior, eso simplemente hace que el enunciado suene como "X horas de mi tiempo vale más que las órdenes de magnitud más de horas de tu tiempo para ponerse al día y solucionar el problema ".

Generalmente, cuando recibo una respuesta grosera de un desarrollador cuando pregunto sobre un problema que tengo o cuando envío un error, dejo de usar ese programa . Ya no uso uTorrent (no es de código abierto, pero el punto sigue siendo), por ejemplo, porque las respuestas que obtuve en su foro de "soporte" fueron muy groseras. Presenté un problema que tuve en el foro de informes de errores. El hilo se bloqueó de inmediato con un enlace a otro hilo sobre un problema similar, pero diferente en un hilo (que también estaba bloqueado, por supuesto). Mientras tanto, abrí un hilo en el foro de discusión general preguntando si alguien había encontrado una solución al problema. En el tiempo que tardó en guardar ese hilo y volver atrás y ver que mi primer hilo había sido bloqueado, mi hilo en General estaba bloqueado y mi cuenta del foro prohibida por comportamiento perjudicial. Desinstalé uTorrent y no he vuelto desde entonces.

Simplemente responder "enviar un parche" es IMO grosero, pero aún así ... si usa un software de código abierto para algo serio, debe estar preparado para cuidarlo si fuera necesario.

Lo siguiente se basa en una publicación de Jeremias Maerki (de Apache FOP fama):

  

Si algo no te funciona, tienes varias opciones:

     

• Esto es de código abierto: puedes arreglarlo tú mismo.
  
• Si no puede arreglarlo usted mismo, puede esperar hasta que alguien tenga tiempo libre y piense que es divertido implementarlo.
  
• Si eso no sucede, puede encontrar o contratar a alguien para que lo haga por usted.
  

Creo que es una versión completa muy válida de la respuesta "enviar un parche".

Cada vez que veo esto, inmediatamente comienzo a buscar un producto alternativo. Para mí, esto es una señal peligrosa de que los mantenedores no se preocupan por sus usuarios (es malo si su proyecto se usa en todas partes) o han perdido interés en el proyecto. Ambas cosas suelen significar que el proyecto morirá pronto o se verá afectado por el estancamiento a medida que los desarrolladores se nieguen a hacer avanzar el proyecto

(Tenga en cuenta que no estoy diciendo que el primer informe de error se ve con este tipo de respuesta que ejecuta. Debe observar una tendencia general. Si la mayoría de los informes de error finalizan con este tipo de respuesta, siga esto Si solo son unos pocos, lo más probable es que esas solicitudes de funciones no se ajusten a los objetivos de los proyectos o sean extremadamente específicas para su uso)

Como dijo @MainMa, comenzar a contribuir a un nuevo proyecto es muy difícil. La mayoría de los desarrolladores no entienden esto, ya que han estado trabajando en el proyecto durante meses / años y tiene sentido para ellos. Esto a veces puede ser un error honesto.

Bromeo ocasionalmente que el software libre puede ser gratis como en la cerveza, libre como en el habla o libre como en lo que recibes por lo que pagas.

Aunque lo digo en broma (trabajo para una compañía que usa muchos OSS) pero creo que hay una verdad allí: si quiere soporte a nivel comercial, entonces necesita usar software comercial con un acuerdo de soporte adecuado, o encuentre una solución de software de código abierto que le permita ese nivel de soporte (generalmente a través de alguien a quien se le paga para que lo proporcione, pero potencialmente a través de su organización que emplee o asigne recursos de desarrollo para trabajar en él).

"Enviar un parche" es exasperante, pero destaca algo sobre OSS y quizás debería ser un recordatorio de que OSS no es adecuado para todos en cada situación, al menos no sin asegurarse de tener un marco de soporte sólido para (ya sea de forma interna, pagada o a través de la comunidad).

A menudo pensamos en software que es gratis como en cerveza pero no como en voz (es decir, software gratuito no abierto). Quizás este sea un caso en el que deberíamos pensar que el software es tan libre como en el habla pero no como en la cerveza.

Cambiar a alternativa bien mantenida.

Según mi experiencia con proyectos de código abierto bien mantenidos, si crea un informe de error bien definido o una solicitud de función, es muy probable que se implemente.

"Solo puedo trabajar en una cosa a la vez, pero puedo quejarme de muchas cosas a la vez. Creo que ambas funciones son útiles". - akkartik on ycombinator .

Considero que cuando uno está trabajando en un proyecto, brindando lanzamientos y soporte, surge un contrato implícito, implícito, de soporte entre el desarrollador y el usuario. El desarrollador ha asumido la responsabilidad implícita de respaldar el código base para sus usuarios, incluida la adición de funciones a pedido.

"Enviar un parche" es básicamente dar el dedo a los usuarios, en mi opinión. Esto es contextual: a veces es demasiado esfuerzo para implementar, a veces arruinaría el proyecto existente o incurriría en la creación de una criatura, o cualquiera de las otras razones. Pero, en última instancia, está diciendo, "atornillarte, no hacerlo". Lo que, en mi opinión, es, en algún nivel, una violación de ese contrato tácito.

Hay varias formas de hacerlo.

• Propuesta de propuesta y voto. pero esto lleva tiempo.

• Contrate a una empresa que lo necesite para hacer el parche. Obviamente, esta es la mejor solución, pero prepárate para colaborar con la persona que crea el software de código abierto que deseas actualizar.

• También es importante averiguar por qué la función no está implementada en primer lugar. A menudo, la función está fuera de la línea del proyecto de software: el equipo no quiere esta función, no se siente necesario o simplemente piensa que no es la buena manera de hacer algo. En este caso, simplemente debe dividir el proyecto y hacerlo usted mismo.

• Use software propietario que hace lo que usted quiere.

• Recuerde que el software OOP a menudo facilita el proceso de integración de una función.

• Al gimotear en una lista de correo, en irc o en un foro solo molestaremos a los programadores, y daremos munición a los proponentes de OSS.

No hay nada que puedas decir que hará que él lo haga. Después de todo, ¿por qué debería? Debido a los deseos de un usuario? No es razón suficiente.

Pero , si puede recopilar un número razonable de usuarios y dar razones racionales ("Lo quiero" no es una razón racional.) Por qué esa función podría ser útil, en general y para usted. y el número de otros que podría cambiar de opinión.

Aunque, también hay un caso especial que debe ser considerado. Eso es un dev. está cansado de desarrollar la aplicación, deseando lentamente abandonarla (tiene otras cosas que hacer), y por eso está abadoneando lentamente las solicitudes de características. Aparte de intentar convencerlo de que libere el código, en este caso no hay prácticamente nada que puedas hacer, incluso con respecto a lo anterior.

Los proyectos de código abierto en particular son amigables con las recompensas o la financiación del desarrollo de una característica en particular, incluso si la nueva característica no llega a las versiones oficiales.

Además, sí, una de las ideas detrás de la publicación de código abierto es que todos y cada uno tengan el derecho y la responsabilidad de hacer sus propias contribuciones.

Con el código cerrado, su mejor recurso es reunir un grupo estadísticamente importante de la base de usuarios que desee soluciones como las que usted desea.

En mi experiencia, esta respuesta se suele dar si la solicitud del usuario no se ajusta al objetivo del proyecto. Ocurre cuando la gente piensa que vas a implementar todo lo que te proponen, y un poco más, de forma gratuita, de código abierto y un gran y feliz futuro.

"Enviar un parche" es una respuesta relativamente grosera (y debe evitarse, por supuesto. Especialmente en esta forma concisa y clara. Hay muchas formas de expresar aproximadamente el mismo mensaje, por ejemplo, "invitar" a los usuarios a ayuda porque no tiene tiempo para implementarlo por su cuenta). Pero tal como está, es un claro indicador de 'dejar de perder mi tiempo'. Como tal, no hay mucho que puedas hacer al respecto, ni hay una respuesta "canónica".

La mejor respuesta que se me ocurre es presentar un parche . Asumiendo que su parche funciona, al menos ha probado que la idea no es totalmente irreal. Por lo general, esto significa que los responsables del proyecto volverán a considerar la propuesta.

"enviar un parche" es un reparto legítimo de las ideas que no se ajustan a los objetivos del proyecto. Probablemente sea mejor a la larga decirte que la idea apesta o estás tratando de usar el proyecto para algo que está fuera de su alcance previsto, pero "hey, si crees que lo que estás pidiendo es tan trivial, ¿por qué? t intenta adaptarlo a nuestra base de código existente "en algún momento es apropiado.

Si es menor y realmente útil para los usuarios previstos del proyecto, simplemente envíe el informe de error, describa claramente el problema, dé pasos para reproducir, indique que está utilizando la compilación nocturna actual y déjelo en que.

Lo que puede parecer un cambio pequeño y simple que ayudaría a miles de usuarios podría ser un gran dolor en el culo que nadie usaría aparte de ti. Ese es el mejor caso para "enviar un parche".

También es posible que te hayas encontrado con un caso como el notorio mantenedor de glibc que parece tener una mente de una sola pista de que su sistema es el universo, su interpretación de las especificaciones es la palabra de Dios, y eso es todo lo que hay que hacer. sin importar cuántas personas preferirían lo contrario.

Sugeriría crear un proyecto para implementar la función en sitios como RentACoder / ELance / etc, y publicarlo al respecto en el foro del proyecto de código abierto original. Cualquiera de los programadores en los proyectos de código abierto, incluido el autor, ahora tiene un incentivo financiero para considerar su solicitud.

En realidad me inscribí solo para responder a esta pregunta.

¿Hay necesidad de una réplica? esta respuesta se suele utilizar cuando el desarrollador conoce el problema pero no lo considera tan importante.

Te daré un ejemplo en vivo. ubuntu eliminó el soporte de la bandeja del sistema (pero se puede solucionar mediante la inclusión de una aplicación en la lista blanca) y se agregaron nuevos indicadores de aplicación. algunas aplicaciones como jupiter se basaron en el soporte de systray, por lo que el desarrollador habló sobre el trabajo en lugar de agregar el soporte de indicador de aplicación, así que le pedí al desarrollador que agregara el soporte de indicador de aplicación. La respuesta fue "Envíenos los parches ". al preguntar La razón por la que optaron por no implementar esto. hubo esto

  

No tengo interés en dedicar mi tiempo a desarrollar un soporte para una biblioteca que nunca usaré solo porque alguien con mucho dinero lo exija al poner en una lista negra la capacidad de mis aplicaciones para funcionar correctamente en su distribución de Linux simplemente porque puede. p>      

Si se tratara de un problema técnico real, probablemente tomaría medidas, pero esto es puramente una maniobra política, así que no, no lo creo.

     

No, solo lo incluiré en la lista blanca

Bastante justo. el desarrollador tiene motivos para no implementar una función, pero está dispuesto a aceptar parches. Esto no es realmente grosero y ofensivo, por lo que no hubo necesidad de una réplica.

resultado final: la respuesta canónica sería enviar el parche, pero si no puede, no es necesario realizar una respuesta

Comienza una recompensa por la característica que deseas.

O salga y compre el producto que dice hacer exactamente lo que quiere y maltrate a su personal de soporte cuando descubra que el marketing no coincide con sus expectativas.

Lo mejor que se me ocurre es "apestas".

Lo siento, obviamente, esto no es muy útil, pero creo que esta es solo una de las situaciones desafortunadas en las que el usuario está completamente atornillado. Un recurso brutalmente honesto a la conciencia del desarrollador es un último esfuerzo.

Puede intentar ofrecer ( tos ) "donaciones" para que se resuelva su problema, pero me temo que tal práctica, si se hace común, podría llevar a una muy mala pérdida de integridad en la industria, como las correcciones de errores nunca deben ser rentables, ya sea para software "gratuito" o comercial.