¿Cuál es la réplica canónica a "es de código abierto, envíe un parche"? [cerrado]

215

El peligro de sugerir alguna característica de un producto, especialmente de código abierto, es que obtendrá la respuesta, "¿por qué no lo hace?".

Eso es válido, y es genial que puedas hacer el cambio tú mismo. Pero sabemos prácticamente que los productos a menudo mejoran a medida que los programadores escuchan la voz de los usuarios, incluso si esos usuarios son otros programadores. Y, la forma eficiente de hacer esos cambios puede incluir a alguien que ya está trabajando en el proyecto, tomando la idea e implementándola.

Hay algunos términos comunes utilizados para referirse a problemas de desarrollo de software. Por ejemplo, Bikeshedding . ¿Se utiliza un término común que esencialmente responda: "Sí, sé que puedo cambiar casi cualquier cosa en el mundo, incluso de código cerrado. Podría ser contratado e ir a escribir ese código. Pero en este caso solo estoy haciendo una observación que de hecho puede ser útil para otro codificador que ya está bien preparado para hacer ese cambio fácilmente, o simplemente para discutir las posibilidades ".

[ps (unos días antes) - Debería haber señalado que "enviar un parche" a menudo se dice con humor irónico, y estoy buscando una respuesta ingeniosa apropiada.]

Vincent Scheib
fuente
16
¡Ojalá pudiera votar esto más de una vez! (Y eso viene de alguien que ha enviado parches a varios proyectos diferentes y los ha aceptado. ¡Esa actitud que usted describe es simplemente molesta!)
Mason Wheeler
62
Supongo "¿Cómo me veo, un mono código desempleado? ¡Tengo una vida!" no es una réplica aceptable ;-)
Steven A. Lowe
12
En mi experiencia, la respuesta "enviar un parche" generalmente viene después de que el desarrollador ya ha explicado por qué no sería práctico agregar la función.
user16764
77
@ Steven, depende de que solo quieras superar el insulto, o realmente hacer que hagan lo que necesitas. Creo que no es una estrategia óptima si quieres lo último.
12
@orokusaki: O D) Consideran que la característica es menos valiosa que otras características en las que podrían estar trabajando, y tienen recursos limitados.
David Thornley

Respuestas:

115

Es un punto difícil: dado que el usuario no paga directa o indirectamente un producto, no puede pedir que se implemente una característica. No es como si fuera una parte interesada 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é pasa con el envío de 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 instaladas todas las versiones correctas de las dependencias de compilación (incluidas las bibliotecas de tiempo de ejecución y las herramientas de compilación).

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

  • Debe comprender muy bien cómo se realiza el proyecto , cuáles son los estilos de codificación que se utilizarán, si los hay, cómo ejecutar pruebas unitarias, etc. Si el proyecto no tiene una documentación decente (que suele ser el caso para 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 diariamente, pero el proyecto usa .NET Framework 2.0, no puede usar LINQ, ni Code Contracts, ni otras miles de nuevas características de las últimas versiones del framework.

  • 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, 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í en unos minutos no es razonable, a menos que te guste.

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

MainMa
fuente
99
Parece que fue escrito por alguien sin experiencia en el mantenimiento de un proyecto de código abierto.
Rein Henrichs
46
@Rein: Mantener un proyecto de código abierto no es diferente de mantener cualquier otro proyecto. Tienes clientes Si ignora a esos clientes, dejarán de darle comentarios valiosos y se irán a otro lado para buscar sus soluciones. Tal vez eso esté bien con las personas de código abierto, pero seguro que me gustaría saber si sería totalmente responsable de hacer las correcciones de errores en un software de código abierto, porque eso me haría pensar dos veces antes de usarlo.
Robert Harvey
17
@Rein: Bueno, hasta ahora te he escuchado decir dos veces que no sabemos de qué estamos hablando. Quizás puedas iluminarnos, ¿eh?
Robert Harvey
8
@Rein Henrichs: Tus dos primeros comentarios son ataques "ad hominem". Si hay diferencias entre los dos, diga cuáles son, en lugar de decir que otras personas no saben nada.
Andrew Grimm
13
Sospecho que la intención era "Mantener un proyecto de código abierto no es diferente de mantener cualquier otro proyecto en lo que respecta a escuchar los comentarios de los clientes y mantener su buena voluntad". Si es así, estoy totalmente dispuesto a abandonarlo, pero, como alguien que ha mantenido varios proyectos FOSS con un puñado de cientos de contribuyentes, encuentro que la declaración general original es "incorrecta".
Rein Henrichs
79

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

wnoise
fuente
47
O mejor aún, decir: "Ya lo hice hace seis meses. ¿Cuándo van a poder revisarlo y comprometerlo?"
Bob Murphy
14
Normalmente no me gustan las respuestas cortas, pero esta es realmente la única forma de responder que seguramente terminará en el resultado que estás buscando. Indican claramente la mejor manera posible de lograr su objetivo. ¿Por qué perder el tiempo con cualquier solución menor?
19
-1 respuesta de gilipollas de código abierto. Inútil. (Lo siento). No hay una "réplica" canónica. La mejor respuesta (suponiendo que el OP no puede simplemente enviar un parche, lo que creo que es una suposición razonable en este caso) es uno de (1) "No tengo las capacidades o los recursos para generar un parche [y posiblemente incluya un enlace a esta misma pregunta] ", (2) eyeroll, sin respuesta, uso de la herramienta en su estado actual, o (3) buscar una herramienta mejor.
JohnL4
1
No necesariamente tiene que ser un parche. Proporcionar comentarios detallados y refinados también vale la pena. Todo lo que dice es que no espere que invierta mi tiempo para cubrir su necesidad específica si no tiene nada que ofrecer a cambio.
Evan Plaice
67

Esta es la respuesta estándar cuando los desarrolladores no piensan que van a hacer algo en un plazo razonable, pero ha sido mencionado repetidamente.

Es muy injusto cuando se ha mencionado repetidamente, pero la persona que lo mencionó más recientemente no lo sabe, y se da cuenta de que "estamos tomando parches para eso" de inmediato. En este caso, el mantenedor está harto de la discusión, pero el usuario cree que es un tema nuevo. De todos modos, lo más probable es que si "toma parches" de inmediato, no debería tomarlo personalmente, pero es posible que desee leer los archivos y el rastreador de errores para obtener más detalles sobre el tema.

Si usted mismo presenta una solicitud en repetidas ocasiones, "tomar parches" está potencialmente destinado a ser un rechazo relativamente amable, en comparación con algunas alternativas menos educadas ...

Y luego, por supuesto, hay groseros mantenedores que dirán "tomar parches" sin ninguna explicación para 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 podrían obtener los encargados del mantenimiento, y muchas de esas solicitudes son importantes para el solicitante pero serían exageradamente difíciles, 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 juicios, y lleva demasiado tiempo discutir cada uno 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 tiene algunas opciones (pagarle a alguien para que codifique la función, etc.) y aunque los desarrolladores pueden ser groseros, al menos dan respuestas directas. Prefiero tener "no" que lo habitual "está en nuestra hoja de ruta ... [2 años después] ... todavía está en nuestra hoja de ruta" tipo de cosas que he recibido de varios proveedores ...

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

Tal vez no sea código, pero posiblemente haya muchos análisis y documentación de escenarios de usuario que podría hacer. Cuando mantenía el administrador de ventanas de GNOME, muchas veces hubiera sido útil para las personas analizar un problema globalmente considerando a todos los usuarios, y realmente escribir los problemas y las ventajas y desventajas y lo que debería suceder desde una perspectiva global.

(En cambio, lo habitual era comenzar a flamear como si fueran el único usuario que importara y no hubiera compensaciones. Y si bien eso es genial, y fue un punto de datos, y a menudo me las arreglé para ser educado o incluso resolver su problema eventualmente ... . flamear no hace que nada suceda más rápidamente. Simplemente confunde las emociones con el tema y desperdicia el tiempo de todos).

Havoc P
fuente
44
@Aaronaught He estado alrededor de cientos de proyectos de código abierto y no he notado el bricolaje como respuesta predeterminada. Es una respuesta a ciertos sabores de solicitud.
Havoc P
2
Todo lo que digo es, creo que la mayoría de las veces, hay alguna razón por la que un responsable de mantenimiento está al menos un poco harto de un tema (o persona) antes de decir "tomar parches", y puede valer la pena investigar por qué Recibí esa respuesta. Es mi experiencia, fwiw. Si la pregunta aquí es sobre casos en los que no hay razón para estar harto del tema o la persona, entonces, seguro, "tomar parches" probablemente no sea algo grandioso para el encargado de decir. La gente comete errores. Todavía digo, dudo que una réplica (o una meta-discusión como esta) ayude, pero participar constructivamente a veces podría.
Havoc P
55
Asimismo, si bien se puede expresar más o menos cortésmente, si un mantenedor tiene un atraso de trabajo en su mente, que probablemente tienen 1 cosa que pueden llegar a ellos mismos, por cada 100 cosas que podrían tener un parche para porque querrían la característica; y luego hay otra categoría de cambios que rechazarían incluso si alguien más hiciera el trabajo. Por lo tanto, tiene que haber alguna forma de comunicar "Tomaría ese cambio, pero no tengo planes de hacerlo yo mismo". Algunas personas aquí parecen sentir que "Claro, viene" es la única respuesta aceptable. Pero "tomar parches en eso" es una categoría real.
Havoc P
2
@Anunciados, eso suena como una buena redacción. Creo que a menudo no se pretende ninguna ofensa / grosería por "tomaríamos un parche para eso", pero los programadores no son, por regla general, los tipos más sensibles emocionalmente, pueden apresurarse por correo electrónico y el tono no se transmite muy bien a través del texto, así que es fácil de encontrar como cortante.
Havoc P
2
En realidad, "tomaríamos un parche para eso" es diferente de dos maneras sutiles pero importantes: (1) no asigna la responsabilidad directamente al usuario , y (2) reconoce que la solicitud ha sido considerada seriamente a pesar de no ser implementado. Aunque el resultado neto es esencialmente el mismo, es una respuesta mucho más humana. (Aun así, no estaría de más añadir de forma explícita los implicados ... pero no tiene los recursos para completar que nosotros en este momento. )
Aaronaught
43

La razón por la que obtiene esta respuesta no es que los encargados del mantenimiento sean imbéciles, es que no los ha convencido adecuadamente de la propuesta de valor de que trabajen en su función para usted .

La mejor respuesta es iniciar un diálogo sobre el valor de su función para toda su comunidad , para ver si puede convencerlos de que cambien de opinión. Tal vez tengan razón y sepan más sobre las necesidades de su propia comunidad que usted, pero, una vez más, tal vez 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 excelente motivador, mientras que las quejas sobre su actitud no lo son.

Rein Henrichs
fuente
15
Por supuesto, tal vez son idiotas. Esta respuesta por sí sola no es un indicador muy preciso, ya que también es utilizada por personas que no son idiotas cuando el autor de la pregunta es un idiota.
Rein Henrichs
44
También me gustaría agregar que, en ausencia de dinero, a menudo puede intercambiar en especie por algún trabajo: ayudar a clasificar una cola de problemas ocupada, pasar el rato en el canal IRC y brindar soporte, probar parches o escribir documentación. Los proyectos de código abierto tienen recursos limitados y deben aprovecharlos al máximo. Agregar una función es viable si es importante para suficientes personas, o importante para las personas que hacen / dan lo suficiente. Si su caso no es el primero, hágalo el último.
HedgeMage
2
Honestamente, la mejor manera de convencer a un desarrollador es mostrarle cuánto de su base de usuarios quiere la función. Los rastreadores de errores con votación, hilos de foros, etc. son muy buenos para esto, y se utilizan en muchos proyectos de código abierto.
ProdigySim
44
Del mismo modo, cuando las personas obtienen un RTFM o DAFS como respuesta, o un -1 en SE, es porque el interlocutor no ha convencido adecuadamente al respondedor de la propuesta de valor de responder su pregunta por ellos . Estoy seguro de que muchos de ustedes pueden relacionarse con este sentimiento.
Rein Henrichs
1
@Walter Yep, por eso sugerí convencer a la persona de "el valor de su función para toda su comunidad".
Rein Henrichs
31

¿Cuál es la réplica canónica a "es de código abierto, envíe 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 algo peor.

Sus opciones son:

  • Haz lo que sugiere la respuesta; es decir, implemente la función y envíela 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í (por ejemplo, a cambio de patrocinio), alguien asociado con el proyecto o algún "codificador de alquiler" aleatorio.

  • Encuentra 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 valió la pena / bien pensada / inteligible / etc., pero no tuvo el tiempo o la paciencia para entablar un debate prolongado?


He estado involucrado en un proyecto de sistema operativo de código abierto de larga duración, y una de las cosas más molestas son las personas que se sientan en la "galería de maní" y lo llenan de sugerencias sobre cómo hacer las cosas "mejor" que:

  • son incompletos, ininteligibles o francamente 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 establecidos del proyecto.

A menudo, la mejor respuesta es desafiar deliberadamente a la persona para que se involucre en el proyecto ... y esperar que tomen la indirecta ... de "aguantar o callar". Desafortunadamente, los más molestos ni siquiera se dan cuenta.

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

Stephen C
fuente
77
"¿Cómo respondería USTED si pensara que la sugerencia no valía la pena / bien pensada / inteligible / etc." , exactamente cómo responden los demás profesionales? "¿Podría explicar / dar algunos ejemplos de lo que está pidiendo?" o "¿Podría darme algunos antecedentes sobre por qué cree que necesita esta función?" o "¿Qué pasaría si hiciéramos esta otra cosa en su lugar, eso funcionaría para usted?" o qué tal "Gracias por su sugerencia, lo consideraremos para un lanzamiento futuro". Estas son habilidades interpersonales básicas, no ciencia espacial.
Aaronaught
12
@Aaronaught - Lo siento, pero no lo entiendes. El desarrollador de código abierto típico no tiene tiempo para entablar conversaciones educadas, pero en última instancia, sin sentido, destinadas a acariciar el ego de sus "clientes"; es decir, pretender que le importa, cuando una persona medio inteligente puede darse cuenta de que todo es una fachada. Y para ser sincero, creo que ese tipo de ego que acaricia la cortesía es condescendiente ... y MÁS ofensivo que decirles sin rodeos que no hay posibilidad de que implementen XYZ.
Stephen C
66
@kurige: en realidad, si las personas en cuestión PRESENTAN parches, se considerarían DEFINITIVAMENTE. El problema es que las personas en cuestión son "todas boca"; es decir, no hay interés en hacer ningún esfuerzo.
Stephen C
10
Porque el desarrollador de código abierto típico ya tiene un trabajo y hace su desarrollo de código abierto por diversión. Hacer lo que otras personas quieren que hagas es trabajar. Hacer lo que quieres hacer es divertido.
ProdigySim
8
@Aaronaught: ¿Es necesario tratar a muchos idiotas con respeto? Dado un servicio público, habrá personas que hagan demandas irrazonables, a menudo de forma insultante. Tratar con tontos descortés puede ser un verdadero dolor. El requisito de ser respetuosos con ellos expulsaría a muchas personas del negocio de F / OS, y eso sería una pérdida para todos.
David Thornley
20

La respuesta sería razonable si usted y el programador en cuestión fueran iguales y supieran casi lo mismo sobre la base del código 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 réplica adecuada:

"No hay forma de que pueda hacerlo tan rápido y 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 "oh, sí, esto en lo que he pasado mucho tiempo y es realmente bueno, es tan simple que cualquiera puede venir de la calle y hacer un trabajo tan bueno como Yo puedo ".

usuario1249
fuente
Excepto que eso no es realmente lo que dicen en absoluto. Dicen que "lo que quieres no es algo que la comunidad quiera, por lo que no estamos realmente interesados ​​en trabajar en él. Podríamos aceptar un parche si quieres trabajar en él". Implícito es "también podríamos cambiar de opinión si la comunidad lo quiere". Recuerda que "Quiero que me ayudes " va en contra de la naturaleza fundamental de los proyectos de código abierto , donde (para ejercer toda la fuerza de mi nerdery de Star Trek) el bien de muchos siempre supera el bien de unos pocos.
Rein Henrichs
Bueno, a menos que esos pocos tengan mucho dinero, históricamente hablando.
Rein Henrichs
2
@Rein, no, lo que dicen es que ELLOS no quieren hacerlo. Todo esto "la comunidad quiere" es solo un hombre de paja. El punto es que uno de la COMUNIDAD lo está solicitando.
1
"Es extremadamente descortés sugerir escribir un parche si no sabe de antemano que, si llegara, lo consideraría para su producto". Convenido. Como dije, es por eso que no uso esta respuesta. Sin embargo, puedo simpatizar con eso. "Si quiere decir sinceramente que" enviar un parche "está destinado a callar a las personas en lugar de delegar el trabajo, entonces acepta que esto fue solicitado por un miembro de la comunidad y no por un desarrollador". No estoy muy seguro de lo que estás diciendo aquí, lo siento.
Rein Henrichs
1
@ Thorbjørn Ah sí. Bueno, de hecho, los mantenedores de código abierto con los que estoy familiarizado ciertamente no piensan de esa manera. De hecho, hacemos todo lo posible para proporcionar directrices y documentación para desarrolladores para ayudar a las personas a aprender el proyecto y las convenciones para contribuir a él precisamente porque somos conscientes de la brecha de habilidades. Por ejemplo, rubini.us/doc/en/contributing
Rein Henrichs
16

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

usuario16764
fuente
8
o envíe un parche
Kamil Szot
2
Qué buena se bifurcan a traer?
1
@Thorbjorn: Todos podrían usar un buen tenedor de vez en cuando. Incluso un tenedor de lástima.
user18014
15

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

"No tengo las habilidades, la experiencia o el tiempo requerido, así que ¿podría decirme dónde enviar las cajas de cerveza al tipo que puede hacerlo por mí"?

gbjbaanb
fuente
13

Presentar un caso de prueba completo .

alecco
fuente
1
Sin embargo, me gusta este, ¡hacerlo a menudo llevaría más tiempo que enviar el parche en sí! ¡La constante aquí es el momento de familiarizarse con la base del código y es muy probable que sea la mayor parte de crear la prueba o escribir el parche directamente!
Newtopian
1
Me gusta esta respuesta para errores. Incluso si no comprende el marco lo suficiente como para enviar una solución, ahorra una gran cantidad de tiempo para alguien que sí lo hace. No hay nada menos probable que me haga solucionar un problema que un "error" vago e irreproducible que podría ser simplemente un sistema mal configurado. No hay nada que me haga saltar sobre un problema más rápido que un simple caso de prueba para que pueda probar rápidamente diferentes soluciones.
BobMcGee
11

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

Si no puede hacer el trabajo por una razón u otra, explique la circunstancia al responsable del proyecto en privado.

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

Yfeldblum
fuente
55
Entonces, ¿solo aquellos que contribuyen directamente tienen derecho a quejarse de un error o una característica que falta? Bien, supongo, pero eso también significa que ni los contribuyentes ni los usuarios tienen derecho a quejarse por la falta de adopción.
Aaronaught
@Aaronaught No, tienen derecho a quejarse, pero hay un límite en la cantidad de tiempo no pagado que un desarrollador puede invertir en un proyecto y es importante que los usuarios lo reconozcan. En mi propio trabajo, reservo "Me gustaría recibir una solicitud de parche / extracción" para las características que tienen un esfuerzo pésimo / propuestas de valor comunitario. O cuando el usuario insiste en que obtenga la función AHORA MISMO y no respete el tiempo de otra persona u otros compromisos del proyecto.
BobMcGee
10

"Gracias por la respuesta."

Porque:

  • A precio cero, la demanda (solicitudes de funciones) excede la oferta (codificadores disponibles para implementar dichas funciones).
  • Molestar a todo lo que se proporciona gratis carece de clase en mi humilde opinión.
  • Este es el objetivo de FOSS: las personas que traen verduras y carne para agregar nutrición a la sopa de piedra. Si no puedo contribuir con algo, debería estar agradecido de poder comer y no quejarme de que no estoy comiendo mejor.
John
fuente
9

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

Al final del día, nada de lo que diga convencerá al desarrollador de que trabaje para usted si no lo desea.

Dean Harding
fuente
9

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 encargados del mantenimiento puedan identificar lo que es importante para la comunidad en su conjunto. Sin embargo, la forma más rápida de implementar su función es enviar un parche. Punto ... no hay forma de evitar eso.

Michael Brown
fuente
8

Personalmente, preferiría recibir una respuesta de "Este es un problema conocido, pero desafortunadamente no es un problema que se aborde en el corto plazo. 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 una serie de cosas:

  1. Todos los usuarios del programa son programadores o todos los reporteros de errores son programadores.
  2. Todos los programadores conocen el idioma en el que se encuentra el programa.
  3. Todos los programadores saben sobre todo tipo de problema que pueda 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 creador de la respuesta "enviar un parche" sabe todo lo anterior, eso simplemente hace que la afirmación suene como "X horas de mi tiempo valen más que las órdenes de magnitud de más horas de su tiempo para levantarse acelerar y solucionar el problema ".

En general, cuando recibo una respuesta grosera de un desarrollador cuando pregunto sobre un problema que tengo o envío un error, dejo de usar ese programa. Ya no uso uTorrent (no de código abierto, pero el punto sigue siendo), por ejemplo, porque las respuestas que recibí en su foro de "soporte" fueron muy groseras. Envié un problema que tuve en el foro de Bug Reports. El subproceso se bloqueó inmediatamente con un enlace a otro subproceso sobre un problema similar pero diferente en un subproceso (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 regresar y ver que mi primer hilo había sido bloqueado, mi hilo en General estaba bloqueado y mi cuenta del foro fue bloqueada por comportamiento disruptivo. Desinstalé uTorrent y no he vuelto desde entonces.

tocino
fuente
¿Quiere decir "Prefiero obtener una respuesta de" en lugar de "Prefiero no obtener"?
Andrew Grimm
Gracias por el primer párrafo en particular. Es sorprendente cómo una forma tan básica de cortesía profesional puede ser ajena a tanta gente. Ya sea que le paguen o no, la respuesta apropiada es reconocer el problema y explicar su estado (incluso si el estado es "diferido").
Aaronaught
8

Simplemente responder "enviar un parche" es grosero de la OMI, pero aún así ... si usa software de código abierto para algo serio, debe estar preparado para encargarse de él si surge la necesidad.

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

Si algo no funciona para usted, tiene varias opciones:

  • Esto es de código abierto: puede solucionarlo usted 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".

Bertrand Delacretaz
fuente
6

Cada vez que veo esto, inmediatamente empiezo a buscar un producto alternativo. Para mí, esta es una señal peligrosa de que los mantenedores no se preocupan por sus usuarios (malo si su proyecto se usa en todas partes) o han perdido interés en el proyecto. Por lo general, ambos significan que el proyecto morirá pronto o estará plagado de estancamiento a medida que los desarrolladores se nieguen a avanzar el proyecto

(Tenga en cuenta que no estoy diciendo que el primer informe de error que vea con este tipo de respuesta se ejecute. Debe observar una tendencia general. Si la mayoría de los informes de error terminan con este tipo de respuesta, siga este consejo. Si son solo unos pocos, entonces esas son las solicitudes de características que probablemente no se ajustan a los objetivos del proyecto o son extremadamente específicas de 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.

TheLQ
fuente
3

De vez en cuando bromeo diciendo que el software libre puede ser gratis como en cerveza, gratis como en voz o gratis cuando obtienes lo que pagas.

Si bien lo digo en broma (trabajo para una empresa que usa mucho OSS) pero creo que hay una verdad allí: si quieres soporte a nivel comercial, entonces necesitas usar software comercial con un acuerdo de soporte adecuado o encontrar un Solución de software de código abierto que le permite ese nivel de soporte (generalmente a través de alguien a quien se le paga por proporcionarlo, pero potencialmente a través de su organización que emplea o asigna recursos de desarrollo para trabajar en él).

"Enviar un parche" es exasperante, pero resalta 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 ello ( internamente, pagado por oa través de la comunidad).

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

Jon Hopkins
fuente
2

Cambie a una 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, tiene muchas posibilidades de ser implementado.

revs vartec
fuente
2
Los informes de errores y las solicitudes de funciones a menudo no están bien definidos. Mi experiencia es que la competencia y el respeto funcionan bien. Además, se considerará una solicitud de función bien definida en el mejor de los casos. Puede considerarse de baja prioridad, o puede ser algo que el grupo de proyecto explícitamente no quiere hacer (hay buenos ejemplos en las Preguntas frecuentes de PuTTY, y una buena lista de solicitudes de funciones agrupadas por categorías).
David Thornley
1

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

Vincent Scheib
fuente
1

Considero que cuando uno está trabajando en un proyecto, brindando lanzamientos y soporte, surge un contrato de soporte implícito y tácito entre el desarrollador y el usuario. El desarrollador ha asumido la responsabilidad implícita de admitir la base de código 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 implementarlo, a veces arruinaría el proyecto existente o incurriría en una creaturitis débil, o cualquiera de una serie de otras razones. Pero, en última instancia, está diciendo, "jódete, no lo hagas". Lo que, en mi opinión, es, en cierto nivel, una violación de ese contrato tácito.

Paul Nathan
fuente
No es un contrato a menos que ambas partes reciban algo. Lo que normalmente quiere el proyecto son informes de errores bien hechos y, con frecuencia, solicitudes de funciones bien hechas, y no todo lo que entra en vigencia hasta el final del contrato implícito.
David Thornley
1
@Aaronaught: Proporcionan pruebas gratuitas solo si presentan informes de errores lo suficientemente detallados para trabajar con ellos. He visto mi parte de informes de errores malos. Pueden o no proporcionar buena publicidad. La mayoría de las personas que usan F / OSS no devuelven nada útil, lo cual está bien, pero seguro que no es un lado de un contrato.
David Thornley
1
@David: ¿Podrías dejar de tratar de restringir la conversación solo a los usuarios más difíciles / improductivos? Si vamos a generalizar, entonces esa generalización debe ser para toda la base de usuarios y contribuyentes como un colectivo; liberar al público te lleva a todas estas personas. A cambio del bien que obtienes de muchos de ellos, obtienes algunos problemas de muchos otros. Así es la vida.
Aaronaught
1
@Aaronaught: Si vamos a generalizar, debemos asegurarnos de que estamos generalizando adecuadamente. No estoy tratando de restringir la conversación a los peores usuarios, solo estoy señalando que están allí. Gran parte de la conversación parece suponer que todos los usuarios son contribuyentes de alguna manera, y eso simplemente no es cierto. Si vamos a hablar solo de los usuarios que son útiles para el proyecto, solo parece justo hablar solo de los miembros del equipo del proyecto que generalmente son educados.
David Thornley
2
@David: Claramente, hay algunos usuarios y colaboradores externos que ayudan, y también algunos que causan problemas. Claramente, hay algunos desarrolladores que son educados y profesionales en la medida en que lo permitan el sentido común y las buenas habilidades de gestión del tiempo, y también hay algunos desarrolladores que son groseros y poco profesionales por costumbre. Esta fue una pregunta sobre cómo tratar con el último grupo de desarrolladores. La existencia de "usuarios problemáticos" no está en disputa, pero es una pista falsa que no tiene otro propósito que descarrilar la discusión creando una situación de confrontación, así que dejémoslo en paz.
Aaronaught
1

Hay varias formas de hacerlo.

  • Característica propuesta y votación. Pero esto lleva tiempo.

  • Ser contratado por una empresa que lo necesita para hacer el parche. Obviamente esta es la mejor solución, pero prepárate para colaborar con el tipo que hace el software de código abierto que deseas actualizar.

  • Descubrir por qué la función no se implementa en primer lugar también es importante. 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 necesaria o simplemente piensa que no es la mejor manera de hacer algo. En este caso, solo debe bifurcar el proyecto y hacerlo usted mismo.

  • Use software propietario que haga lo que quiera.

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

  • Quejarse en una lista de correo, en irc o en un foro simplemente enojará a los programadores y dará munición a los proponentes de OSS.

jokoon
fuente
0

No hay nada que puedas decir que lo obligue a hacerlo. Después de todo, ¿por qué debería hacerlo? ¿Por los deseos de un usuario? No es razón suficiente.

Pero , si puede reunir una cantidad razonable de usuarios y dar razones racionales ("Lo quiero" no es una razón racional), por qué esa característica podría ser útil, en general, para usted y para una cantidad de otros, podría cambiar de opinión. .

Aunque, también hay un caso especial que debe ser considerado. Que un dev. está cansado de desarrollar la aplicación, lentamente desea abandonarla (tiene otras cosas que hacer), por lo que lentamente está abandonando las solicitudes de funciones. Aparte de tratar de convencerlo de que publique el código, en este caso no hay prácticamente nada que pueda hacer, incluso con respecto a lo anterior.

Torre
fuente
Alternativamente, el desarrollador tiene suficientes solicitudes de funciones para mantenerlo ocupado durante el resto del siglo, le gustaría incluir las suyas, pero no prevé llegar pronto.
David Thornley
@David Thornley - Eso también.
Torre
0

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 los lanzamientos oficiales.

Además, sí, una de las ideas detrás de la publicación de código abierto es que todos 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 desea.

Apalala
fuente
2
El derecho a contribuir, sí, pero la última vez que leí la GPL no mencionó nada sobre la responsabilidad de los usuarios finales de hacer sus propias contribuciones. Eso es un poco exagerado, ¿no te parece?
Aaronaught
0

En mi experiencia, esta respuesta generalmente se da 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 futuro excelente y feliz.

'Enviar un parche' es una respuesta relativamente grosera (y debe evitarse, por supuesto. Especialmente en esta forma concisa y aguda. Hay muchas formas de expresar aproximadamente el mismo mensaje, por ejemplo, 'invitar' a los usuarios a ayudar porque usted no tengo tiempo para implementarlo por tu cuenta). Pero como es, es un claro indicador de "deja de perder el 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 . Suponiendo que su parche funciona, al menos ha demostrado que la idea no es totalmente poco realista. Por lo general, esto significa que las personas a cargo del proyecto volverán a considerar la propuesta.

Alexander Gessler
fuente
1
No creo que ningún desarrollador deba responder "enviar un parche" con respecto a una solicitud que no se ajusta al objetivo del proyecto. Eso es más deshonesto que grosero. O el software se hincha y el desarrollador lo odia por él, o no acepta el parche y efectivamente pierde su tiempo. Lo último es más probable. El desarrollador realmente debería decir honestamente "No queremos cambiar esto porque ____" y terminar con eso.
Rei Miyasaka
@Rei Miyasaka: Personalmente, me enfurecería si recibiera "enviar un parche", hiciera el trabajo para hacer un parche de buena calidad, y luego me dijeron que no querían la función de todos modos.
David Thornley
@David Sí, ¿eh? Tiraría una silla o dos.
Rei Miyasaka
0

"enviar un parche" es un rechazo legítimo de ideas que no se ajustan a los objetivos del proyecto. Probablemente sea mejor a largo plazo simplemente decirle que la idea apesta o que está tratando de usar el proyecto para algo que está muy lejos del alcance previsto, pero "oye, si crees que lo que estás preguntando es tan trivial, ¿por qué no?" Intentar ajustarlo en nuestra base de código existente "es apropiado en algún momento.

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 así.

Lo que puede parecer un cambio simple menor que ayudaría a toneladas de usuarios en realidad puede ser un gran dolor en el culo que nadie usaría además de usted. 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 unidireccional de que su sistema es el universo, su interpretación de las especificaciones es la palabra de Dios, y eso es todo, independientemente de de cuántas personas preferirían lo contrario.

Kevin Peterson
fuente
No creo que nadie elegiría hacer esta pregunta si supieran que el cambio sería un gran dolor en el culo que solo usa una persona. Entonces, en lugar de "enviar un parche", ¿por qué no explicar cortés y brevemente por qué es tan importante y no se puede hacer de inmediato?
Sr. Shickadance
2
"Enviar un parche" es un rechazo realmente pésimo, ya que es posible que alguien envíe un parche. Debe reservarse para los productos agradables de baja prioridad.
David Thornley
0

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

Renji Panicker
fuente
-1

De hecho, me inscribí solo para responder esta pregunta.

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

Te daré un ejemplo en vivo. ubuntu abandonó el soporte de systray (pero puede solucionarse haciendo una lista blanca de una aplicación) y agregó nuevos indicadores de aplicación. algunas aplicaciones como jupiter confiaban en el soporte de systray, por lo que el desarrollador habló sobre el workaournd en lugar de agregar soporte de indicador de aplicación, así que le pedí al desarrollador que agregara el indicador de indicador de aplicación, la respuesta fue "Envíenos parches". al preguntar la razón por la que eligieron no implementar esto. hubo esto

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

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

Lo suficientemente justo. el desarrollador tiene razones 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.

Conclusión: la réplica canónica sería enviar el parche, pero si no puede, no hay necesidad de una réplica

Lincity
fuente
-1

Comience una recompensa por la función que desee.

O salga y compre el producto que dice hacer exactamente lo que quiere y abusa de su personal de soporte cuando descubre que el marketing no cumple con sus expectativas.

CyberFonic
fuente
-2

Lo mejor que puedo pensar 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 jodido. Un llamamiento brutalmente honesto a la conciencia del desarrollador es un último esfuerzo.

Podría intentar ofrecer "donaciones" (para la tos ) para que se solucione su problema, pero me temo que una práctica de este tipo, si se hace común, conduciría a una pérdida de integridad realmente grave en la industria, ya que las correcciones de errores nunca deberían ser rentables, ya sea para Software "gratuito" o comercial.

Rei Miyasaka
fuente