El autor y mantenedor de varios proyectos de código abierto , Andrew Gallant está tratando de aliviar la tensión que se ha acumulado recientemente en la comunidad de código abierto. Los gritos del alma "¿Cómo es ser un mantenedor de software libre" , "código abierto ingrato" y otras quejas de los mantenedores dieron lugar a una discusión sobre agresividad, grosería, ingratitud, agotamiento emocional y la gravedad del apoyo desinteresado para los proyectos. La publicación fue publicada el 19 de enero de 2020, - aprox. trans.

Quiero alejarme de la tradición de hablar casi estrictamente sobre temas técnicos, y compartiré algunas de mis relaciones personales con software libre y de código abierto (FOSS). Aunque todas las personas son diferentes, espero que el intercambio de opiniones ayude a construir un entendimiento mutuo, empatía y confianza en nuestra comunidad.

No considere esta publicación como una reacción directa a las acciones de cualquier otro responsable. Esta no es una receta para un comportamiento ideal, sino una reflexión personal con la esperanza de que se conviertan en una ocasión para que otros reflexionen sobre sus propias relaciones con el código abierto. No hay una sola forma correcta de convertirse en un buen mantenedor. Cada uno tiene sus propias formas de lidiar con esto.

Esto de ninguna manera es un llamado de ayuda. Se trata de entender. No estoy pidiendo un cambio en la economía de software libre ni discutiendo mi salud mental. No estoy hablando de atraer mantenedores adicionales. Solo quiero compartir mi historia e intentar aumentar la empatía en la comunidad de FOSS.

Público objetivo : todos los involucrados en código abierto.

Contenido

• La historia
  
• Malditas emociones
  
• Negativo purulento
  
• Trabaja a través del poder
  
• Grosería
  
• Autoridad
  
• Más acerca de la competencia
  
• Confianza
  
• Mejor de lo que parece
  
• Conclusión

La historia

Mi primer proyecto de código abierto salió hace casi 16 años: un tablón de anuncios en PHP. En ese momento, casi todos crearon tales cosas, y así es como aprendí a programar. Inicialmente, el proyecto comenzó como un sistema escolar para las discusiones (en ese momento, las escuelas no funcionaban con Internet en absoluto, excepto para alojar sitios de mala calidad). Entonces me encontré con la dificultad de estimar. El proyecto se prolongó durante mucho más de un semestre y gradualmente se trasladó a un pasatiempo que iba más allá del alcance del proyecto escolar.

Personalmente, siempre me encantó programar solo por diversión. Me gustan todas las etapas: primero sondear un tema, determinar la viabilidad, desarrollar un plan inicial, codificar obsesivamente e incluso pensar en ello, me gusta cada minuto de todo.

Para disfrutar de la programación, no tengo que compartir los resultados de mi trabajo. Sin embargo, el código abierto se convirtió rápidamente en una parte natural de mi proceso de desarrollo, que persistió de una forma u otra durante 16 años. De hecho, lo que más me gusta es si el código permite que alguien resuelva su problema de manera más eficiente. Cuanto más bueno sea mi código, más agradable será. Como regla general, no me importa quién, por otro lado, sea otro pirata informático que satisfaga su curiosidad, o una corporación gigante que haga algo interesante a una escala increíble.

Mi historia de FOSS continuó con varios lanzamientos de mi tablón de anuncios y wtcSQLite , un simple clon de phpMyAdmin , pero para SQLite.

Cuando cambié de Windows a Linux alrededor de 2009, lancé aún más proyectos, pero en Python y X11. Entre ellos están PyTyle para arreglar marcos en el administrador de ventanas múltiples y openbox-multihead , mi implementación de soporte de monitores múltiples en Openbox . Estos proyectos, junto con algunas investigaciones de Go, me llevaron a crear el administrador de ventanas en Go que todavía uso.

Con el paso del tiempo, y hace unos seis años, comencé a escribir en Rust. Quickcheck se convirtió en la primera biblioteca, pero fue seguida por una gran cantidad de otros: regex , docopt.rs , rust-csv , fst , termcolor , walkdir y muchos otros en los próximos seis años.

Aunque la gran mayoría de mis proyectos de Rust son bibliotecas, existen herramientas de línea de comandos como xsv y ripgrep .

Muchos de mis proyectos antiguos están actualmente muertos o respaldados por otros, pero sigo apoyando la mayoría de los proyectos de Rust. O fueron suplantados por los bastidores de mejor calidad de otra persona (por ejemplo, cómo el canal de viga transversal suplantó al chan ).

Hoy en día, todavía me gusta programar mucho, pero también paso mucho tiempo revisando códigos, depurando problemas con usuarios finales, respondiendo solicitudes de funciones y otras cosas similares. Esto significa invariablemente interacción, trabajo y comunicación con otras personas.

Malditas emociones

En mi juventud estaba orgulloso de mi "lógica" y "toma de decisiones imparcial". Como en todo buen autoengaño, aquí hay un grano de verdad. Pero, en esencia, personalmente soy un ser profundamente emocional.

Las emociones fluyen profundamente y pueden ser una fuente realmente útil para la motivación interna. Por ejemplo, durante algún tiempo después del lanzamiento de ripgrep, realmente odié tocar el código responsable de mostrar los resultados de búsqueda . Estaba confundido, con errores y difícil de cambiar. Reescribir completamente el código es una decisión completamente lógica que se puede tomar por razones puramente técnicas, pero me sentí motivado a hacerlo por asco. Simplemente no me gustaban mis sentimientos . Las emociones me ayudaron a arreglar la situación, ayudarme a mí mismo. Por ejemplo, ahora la salida está aislada en una biblioteca separada con pruebas exhaustivas, y me siento mucho mejor cada vez que necesito entrar en este código y hacer algo. Este todavía no es mi mejor trabajo, pero ya es una gran mejora, al menos desde un punto de vista emocional, en comparación con el estado anterior.

Las emociones son divertidas porque pueden llevarte a estados verdaderamente sorprendentes. Digamos, en el ejemplo anterior, ¿hay algunas razones técnicas suficientes para reescribir el código de salida? Aquí debes tomar una decisión. Pero si no hay motivación, tal vez nunca me atreveré a refactorizar. Y sin refactorizar, lo más probable es que la base del código se estanque y el programa comience a fallar, o alguna combinación de ambos. Si las emociones dan motivación, la refactorización abrirá un futuro mucho mejor, donde puede implementar más funciones en el software sin comprometer la confiabilidad.

Las emociones tienen un inconveniente. Cualquiera que haya lanzado y respaldado algún software bastante popular seguramente se comunicará con otras personas. Resulta que otra persona puede tener un efecto sorprendente en su estado emocional. Un gesto o comentario positivo puede alegrar tu día. La misma sensación: sí, cargar mi código fue tan importante que ayudó a esta persona . Pero, como lo confirma cualquier responsable de mantenimiento, los comentarios positivos casi siempre se ven eclipsados ​​por los negativos.

Los comentarios negativos no son tan malos. Esta es una consecuencia natural del intercambio de código cuando invita a otros usuarios a usarlo e informar problemas . Cuando aparece un mensaje de error, siente que le ha fallado a este usuario. Cuando escribió el código, estaba seguro de que lo probó lo suficientemente bien, pero sigue siendo incorrecto . ¿Los informes de errores nunca se detendrán? ¿Cuánto tiempo perdió este usuario debido a un error? ¿Cuánto tiempo me llevará arreglar todo? Ni siquiera eso: ¿cuánto tiempo me tomará simplemente cambiar a un modo en el que al menos hay esperanza de arreglarlo?

Estos pensamientos pueden conducir a emociones que comienzan a erosionarse. Y este es el escenario más probable cuando se trata de comentarios negativos.

Negativo purulento

Rápidamente aprendí a superar las emociones negativas de los informes de errores. De hecho, los buenos mensajes de error fáciles de leer pronto se vuelven agradables porque generalmente son muy raros. La mayoría de los errores no se reproducen en absoluto, incluso si proporciona una plantilla para el problema con solicitudes explícitas para todos los parámetros (plantilla de problema). El remitente probablemente quiere lo mejor, pero la información simplemente no es suficiente para reproducir el error. Y el alboroto comienza de un lado a otro en un intento de aislar el error.

Para mí personalmente, esta es el área más dolorosa. Las emociones ganan ventaja porque solo puedo pensar en una cosa: ¿por qué esta persona no se tomó el tiempo de leer y completar la plantilla del problema ? O si ocurre un error debido a un error de un usuario que no ha leído la documentación, solo puedo pensar: ¿ me tomé el tiempo para darle algún software a este usuario, y él ni siquiera puede leer README antes de enviar un informe de error?

Esto es una locura Por supuesto, las emociones no siempre son racionales. La documentación probablemente podría ser más clara. O el usuario podría no haber notado este artículo. Tal vez no tenga experiencia en la ejecución de proyectos de software libre o la presentación de informes de errores y, tal vez, no sabe cómo ayudar en la reproducción simple de un error. Todos estos son supuestos bastante razonables, y es por eso que hago mi mejor esfuerzo para que las emociones no prevalezcan. Aunque la empatía con la persona en el otro extremo del cable también es importante.

Supongamos que no digo "Te invito a usar mi código" en ningún lado, pero hago muchas cosas solo porque mi intención es que otros usen mi código. Estoy escribiendo documentación más detallada, ejemplos de uso. Configuré pruebas de integración continua. Hecho README para principiantes. El enlace al proyecto se indica en muchas de mis páginas. Si las personas aceptan esta invitación para usar mi código o consideran que un rastreador de errores abierto es una invitación para informar errores, entonces no debería castigarlos cuando realmente envían estos mensajes. El autor de un informe de error malo probablemente piensa que hizo todo lo posible. Y aunque actúan por buenas acciones, realmente trato de responder lo mismo.

Esto subraya la asimetría entre los usuarios y el mantenedor. Los autores de muchos informes de errores pueden intercambiar uno o dos mensajes conmigo. Para ellos, un informe de error mal escrito realmente no importa. Pero estoy en el lado equivocado, porque tengo esta escena representada una y otra vez en todos mis proyectos. Todo el tiempo Casi todos los dias. Mantener la empatía en tal situación es extremadamente difícil, especialmente si tienes un mal día. Lo que a veces pasa.

A veces mi impaciencia se manifiesta en respuestas demasiado cortas. Hago mi mejor esfuerzo para mejorar en este sentido. El proceso de superación personal aún no se ha completado.

Trabaja a través del poder

Si es el mantenedor de un proyecto popular o de varios repositorios regulares, obtendrá un flujo casi continuo de informes de errores y solicitudes de grupo. Vienen a diario. Mantenerse al día con él es casi imposible. El tamaño de la memoria caché de mi cerebro es inusualmente pequeño, por lo que no soy muy bueno para cambiar el contexto entre proyectos. Como resultado de este fenómeno, rápidamente recopilo informes de errores y solicitudes de grupos para aquellos proyectos con los que trabajé recientemente. Estos proyectos son probablemente más accesibles o mejor abordados en las últimas páginas de la memoria caché del cerebro.

Pero en otros proyectos, la lista de problemas comienza a acumularse. Todos los días ves un nuevo problema y te dices a ti mismo: "Sí, realmente lo veré tan pronto como regrese del trabajo". Pero algo nuevo se acerca. Como resultado, la motivación para cambiar el contexto surge solo cuando el usuario te llama mensualmente durante cuatro meses, probablemente su solicitud de grupo es realmente importante.

Lo siento, hubo un poco de sarcasmo en la última oración, pero al mismo tiempo es cierto. La asimetría de usuarios y mantenedores vuelve a la acción, pero realmente estoy tratando de eliminar el conjunto de colas de solicitudes y desarrollar el proyecto. Quiero contribuir con este usuario, no solo para continuar usando mi código, sino también para hacerlo feliz . En muchos casos, solo una hora es suficiente para resolver las solicitudes del grupo y todos los problemas que requieren acción.

Pero pasé cuatro meses mirando con tristeza cómo los problemas languidecen en aquellos que entran sin una solución.

Para este fenómeno, apliqué un método que uso muy eficazmente en mi vida personal: establecer límites. Cortésmente, pero estableciendo límites es uno de esos trucos mágicos de vida que genera dividendos tan pronto como lo aprende. Si no sabes cómo hacer esto, entonces apenas puedo explicarte. Sin embargo, establecer límites le permite concentrarse en lo que es importante para usted , no en los demás .

Obviamente, uno debe luchar por el equilibrio. El establecimiento de límites no significa que pueda concentrarse solo en sus propios asuntos. Pero la capacidad de levantar este muro y decir: "No, no hago X, pero con gusto haré Y", realmente funcionó de maravilla para mí. Mi secreto es hacer argumentos con los que otros no puedan discutir basados ​​en mi propia experiencia y deseos.

¿Qué tiene esto que ver con el código abierto? Para mí, personalmente, la clave era establecer un límite entre mí y todos estos problemas huérfanos con las solicitudes de grupo. Necesitas impresionarte de alguna manera: “Voluntariamente paso mi tiempo, y es normal que no responda a tiempo. Estoy seguro de que la mayoría de la gente lo entenderá y será razonable ".

Esto también aparece cuando se discuten solicitudes de nuevas características. A veces, la solicitud puede tener sentido para su proyecto, pero esta función implica una gran carga de apoyo. Aprendí a establecer límites: puede decir "No" a una función solo porque no desea dedicar más tiempo al soporte. Como ha sucedido más de una vez, ¡puedes cambiar de opinión! Por ejemplo, si el código ha mejorado, sea más accesible para el mantenimiento; puede notar en usted mismo más deseo de introducir nuevas funcionalidades. Pero si no, entonces hago lo mejor que puedo para superar mis límites y me niego a cargarme con un trabajo extra que no da placer.

Me gustaría escribir instrucciones paso a paso sobre cómo establecer límites firmes y dejar de sentirme mal debido a un montón de problemas. Esto no elimina completamente lo negativo, pero ayuda mucho.

Grosería

Los trolls obvios suelen ser fáciles de tratar. Este es un grupo de personas con intenciones obvias de molestarte. Los trolls generalmente no envían ningún código, por lo que no es necesario prestar mucha atención a sus comentarios. Al menos, eso es lo que me digo en el marco del mecanismo de defensa. Si veo un troll, generalmente lo informo en apoyo de GitHub con el bloqueo posterior. En general, rara vez me encuentro con tales personajes, así que aquí parezco tener suerte.

Pero la rudeza toma muchas formas. Mi emocionalidad establece un marco de decencia bastante apretado, por lo que no puedes considerar toda esta grosería. Pero desde mi punto de vista, esto es al menos grosero.

• "Su herramienta no funciona [para mi caso de nicho], por lo que está rota".
  
• "Solo intervendré para decir que también me gustaría esta función" (Nota. Parece que algunos lectores no pueden soportar lo que yo llamo "grosería". Quizás esta es una palabra demasiado fuerte, pero cuando en la discusión acumulan " "Complementos", solo agrega ruido al correo electrónico y puede ser molesto. En cambio, los emoticones son bienvenidos o puede agregar algunos detalles a su caso de uso específico. Sin embargo, parece bastante pequeño en el fondo, y realmente veo eso aquí asticamente mi problema).
  
• Para insistir en que para implementar la función necesita " simplemente hacer X".
  
• Agresión pasiva cuando pasa una solicitud de función.
  
• Regaño poco constructivo sobre el software en [inserte aquí cualquier red social].
  
• Variaciones sobre el tema "¿Por qué estás reinventando la rueda?" O "¿Por qué no contribuir a un proyecto existente?"

En muchos casos, la grosería es el resultado de una decepción genuina por parte del usuario. ¿Cuántas veces has murmurado en voz baja cuando algún instrumento no se comportó de la manera que deseas? No importa que esta herramienta sea presentada de forma gratuita. Solo está tratando de resolver un problema, y ​​la herramienta se está interponiendo en su camino. Yo mismo definitivamente lo sentí. En mi opinión, un sentimiento humano completamente normal.

A veces prevalece la rudeza, que se expresa de varias maneras improductivas. Sé que yo mismo hice esto y, por supuesto, también sucedió en el otro lado. Esto es increíblemente molesto para todos los involucrados.

En otros casos, algunas personas no entienden su rudeza. Tal vez por la barrera del idioma, o porque simplemente no sabían cómo sus palabras afectarían a los demás. Muy inocente, pero no cambia los sentimientos de mi parte.

Tratar con este tipo de grosería puede ser muy difícil. Quizás estos problemas no molesten a nadie, pero yo no soy uno de ellos. Podría fingir que no me molesta, pero estoy seguro de que esto conducirá a un insulto al código abierto e incluso a una mayor decepción.

Aquí nuevamente, establecer límites me ayudó. Si descartamos los trolls, entonces la gran mayoría de los pargos generalmente responden bastante bien, si los aborda cortésmente. A menudo hice esto en mis rastreadores de errores, y esto generalmente mejoró la situación. No me siento insultado porque me protejo, y al mismo tiempo me siento mejor cuando la otra persona se disculpa, lo que sucede en la gran mayoría de los casos.

Para hacer esto, es suficiente decir simplemente: "No me gusta cómo dijiste X. Creo que será mucho más productivo si rechazamos tales llamamientos en el futuro".

Pero en algunos casos, las personas no responden muy bien a tales palabras. En mi experiencia, generalmente los ignoran. Si continúan siendo groseros, puedo repetir esto un par de veces, porque algunos necesitan escuchar algo más de una vez para alcanzarlos. Al menos sé esto por mi cuenta (para disgusto de mi esposa). Si esto todavía no funciona, y su tono todavía me molesta, entonces dejo de interactuar. Simplemente cierre o bloquee el problema o la solicitud de grupo, o vaya más allá hasta que el usuario esté bloqueado en [inserte las redes sociales aquí].

Autoridad

Érase una vez, hablé con algunos amigos cercanos que viajaban al extranjero. Al regresar a los Estados Unidos, compartieron un pequeño ejemplo de conmoción cultural. ¿Lo principal?

Nunca pensé en cuánto les encanta forzar a los estadounidenses .

Si esta es una característica de toda la cultura estadounidense o solo del medio ambiente, no lo discutiremos. El punto es que a algunas personas les gusta hablar sobre lo que otras personas deberían hacer. Crecí con tales alimentaciones de personas de los niveles más diferentes de la jerarquía de poder, y realmente siento un disgusto innato por esto.

Estoy absolutamente convencido de que la mayoría de las personas ni siquiera se dan cuenta de ese comportamiento. Algunos no quieren meterse en tu vida, sino que simplemente intentan darte consejos. Al menos así es como responden cuando señalo casos particularmente atroces de coerción.

Retrocediendo un poco, usar la palabra "debería" no es necesariamente malo en sí mismo. Pero lo que realmente cambia su significado, en mi opinión, es la presencia de una invitación . Si le pediste consejo a alguien sobre un tema, y ​​él dice algo así como "Sí, tienes que hacer una X", entonces eso no suena tan mal.Pero si una persona apareció sin una invitación, surge un sentimiento completamente diferente.

En código abierto vi o experimenté esto en varias variaciones:

• Debe lanzar una nueva versión.
  
• Debe reescribir esto en [insertar lenguaje de programación aquí].
  
• Debe cambiar el nombre del proyecto.
  
• Debería [insertar cambios arquitectónicos fundamentales aquí].
  
• Debe cambiar la licencia de su proyecto.

, - . . , , - , . , - , - , .

, , . :

• , « ?», , . FAQ .
  
• . , - , .

, . , Rust, UNLICENSE . - «» , () , . . . - , .

, . - , . . , .

, . , , , - .

, - ( ), . . . -, . - , — , , — . , -: - , .

. . , , .

. open source. , , , .

FOSS — . , . FOSS , , . , .

, . - , , , .

. , . :

• , , ?
  
• ?
  
• ?
  
• ?

, . , . , . . — , . , , .

, JSON, , . , / . .

, , . . , . , , . , .

, , . , , FOSS.

,

. : « ?» , . . , , . , ( ) .

, :

• , . , . , : «, , . ».
  
• -, .
  
• -, , , . — , .
  
• changelog, , . , , .
  
• , , . , .
  
• . , , .
  
• . , , .

, — — . . , , , . .

Conclusión

FOSS, . , . , . , . , , . , . - , FOSS.

, , , , . , .

En el artículo, he enumerado muchos tipos de comportamiento que considero negativos. No todos los percibirán tan negativamente como yo. Esto es normal y esperado . Además, yo mismo hice algunas de estas cosas negativas. Las personas no son perfectas y nunca podemos responder completamente el 100% del tiempo. Estas son preguntas sutiles, y espero que podamos mejorar la situación, al menos un poco.