Creí entender el Código Abierto. estaba equivocado

oh chico, estaba tan equivocado.

¿Te acuerdas de ese extraño lugar "No quieres descargar un coche"?

Lo vi tantas veces en mi cine local durante mi infancia, y tengo que admitir que siempre me pareció extraño.

éste

Quiero decir, robar un auto y descargar un archivo en mi cabeza tenía dos efectos completamente diferentes: en este último caso, terminarías con dos archivos. No es que el original desapareció mágicamente una vez que terminó la descarga. El auto, en cambio, bueno … siempre fue [solo] uno.

Esta disonancia, en aquel entonces, fue tan fácil para mí detectar que estaba extrañamente sorprendido de que me llevara años de uso diario de código abierto, y muchos meses como mantenedor real para comprender que estaba tan lejos como ese punto en la forma en que mezcló el mundo real con el virtual.

Solía ??interactuar con el software de código abierto como cliente obteniendo un regalo de promoción.

Allí, lo dije: solía agregar esa biblioteca o ese fragmento a mi código para integrar una nueva función y, si algo salía mal, volvía al repositorio de GitHub y abría un problema al respecto; Intentaría ser un buen escritor de la mayoría de las veces, pero también escribí mi buena cantidad de comentarios tontos "+1 / yo también".

Creía que los mantenedores, las personas que creaban el código que estaba usando, estaban allí para producir un producto excelente, y al darles retroalimentación sobre cómo agregar una función, o solicitar una ETA sobre algo de lo que se trataba un problema, era una fiar y forma estándar de cooperar. Esperaba que aceptasen gustosamente mi sugerencia y modificaran su hoja de ruta para satisfacer mi deseo.

Incluso cuando comencé a ayudarme con reaccionar-navegación , mantuve esta "mentalidad" al ver a aquellos que abrían problemas como clientes; y, al hacerlo, casi me quemo al hacer demasiado triaje de problemas (y manejar demasiados "malos clientes") y tratar de mantener a todos "contentos".

Luego me uní a la comunidad Open Source Maintainers en GitHub, donde pude interactuar con algunas personas inteligentes que se han desarrollado con código abierto durante muchos años.

Y algo hizo clic.

Creo que lo entiendo de la manera correcta, ahora: el código abierto no significa "en juego", sino que

"Oye, mira, hice esto, si quieres usarlo también, así es como. Lo hice de una manera que se ajusta a mis necesidades, pero úsala como quieras ".

Y eso es.

La primera persona que debería resolver ese problema, la que usted escribió, no debe ser otra que usted mismo.

Esa característica que crees que es tan útil y necesitas tanto, ¿qué tal si bifurcas el repositorio y agregas tu código para habilitarlo?

El código abierto significa que usted usa lo que hay por ahí como quiera, y git & GitHub nos brinda a todos una manera fácil de unir nuestras dificultades para que otro desarrollador no los enfrente en el futuro.

Pero comienza cuando todos se arremangan y contribuyen activamente. Escribir código es siempre la primera forma en que debe abordar un problema que tenga en código abierto.

¿Crees que no eres lo suficientemente bueno? No te preocupes Hazlo de todos modos. Abre ese PR; cuando te pones en peligro, otros desarrolladores lo reconocerán y te ayudarán a crecer y a convertirte en un mejor codificador.

No tienes ganas de codificar, ¿verdad? Bueno, recuerde seguir guías como esta al abrir un problema.

Y nunca olvides que nadie está obligado a hacer lo que estás escribiendo; nadie debe hacer el trabajo por usted, en su problema.

Comience su 2018 con el pie derecho, no cometa el error colosal que cometí.

Use el código abierto de manera responsable y guíe con el ejemplo: la mayoría de las personas no leerán este artículo y / o no hablarán con un mantenedor activo en el corto plazo, pero si ven que así es como todas las personas a su alrededor usan el OSS "correctamente", se comportará igual.

mono mira mono hace

Feliz año nuevo a todos, hagámoslo bien juntos ?

Creí entender el Código Abierto. estaba equivocado

oh chico, estaba tan equivocado.

¿Te acuerdas de ese extraño lugar "No quieres descargar un coche"?

Lo vi tantas veces en mi cine local durante mi infancia, y tengo que admitir que siempre me pareció extraño.

éste

Quiero decir, robar un auto y descargar un archivo en mi cabeza tenía dos efectos completamente diferentes: en este último caso, terminarías con dos archivos. No es que el original desapareció mágicamente una vez que terminó la descarga. El auto, en cambio, bueno … siempre fue [solo] uno.

Esta disonancia, en aquel entonces, fue tan fácil para mí detectar que estaba extrañamente sorprendido de que me llevara años de uso diario de código abierto, y muchos meses como mantenedor real para comprender que estaba tan lejos como ese punto en la forma en que mezcló el mundo real con el virtual.

Solía ??interactuar con el software de código abierto como cliente obteniendo un regalo de promoción.

Allí, lo dije: solía agregar esa biblioteca o ese fragmento a mi código para integrar una nueva función y, si algo salía mal, volvía al repositorio de GitHub y abría un problema al respecto; Intentaría ser un buen escritor de la mayoría de las veces, pero también escribí mi buena cantidad de comentarios tontos "+1 / yo también".

Creía que los mantenedores, las personas que creaban el código que estaba usando, estaban allí para producir un producto excelente, y al darles retroalimentación sobre cómo agregar una función, o solicitar una ETA sobre algo de lo que se trataba un problema, era una fiar y forma estándar de cooperar. Esperaba que aceptasen gustosamente mi sugerencia y modificaran su hoja de ruta para satisfacer mi deseo.

Incluso cuando comencé a ayudarme con reaccionar-navegación , mantuve esta "mentalidad" al ver a aquellos que abrían problemas como clientes; y, al hacerlo, casi me quemo al hacer demasiado triaje de problemas (y manejar demasiados "malos clientes") y tratar de mantener a todos "contentos".

Luego me uní a la comunidad Open Source Maintainers en GitHub, donde pude interactuar con algunas personas inteligentes que se han desarrollado con código abierto durante muchos años.

Y algo hizo clic.

Creo que lo entiendo de la manera correcta, ahora: el código abierto no significa "en juego", sino que

"Oye, mira, hice esto, si quieres usarlo también, así es como. Lo hice de una manera que se ajusta a mis necesidades, pero úsala como quieras ".

Y eso es.

La primera persona que debería resolver ese problema, la que usted escribió, no debe ser otra que usted mismo.

Esa característica que crees que es tan útil y necesitas tanto, ¿qué tal si bifurcas el repositorio y agregas tu código para habilitarlo?

El código abierto significa que usted usa lo que hay por ahí como quiera, y git & GitHub nos brinda a todos una manera fácil de unir nuestras dificultades para que otro desarrollador no los enfrente en el futuro.

Pero comienza cuando todos se arremangan y contribuyen activamente. Escribir código es siempre la primera forma en que debe abordar un problema que tenga en código abierto.

¿Crees que no eres lo suficientemente bueno? No te preocupes Hazlo de todos modos. Abre ese PR; cuando te pones en peligro, otros desarrolladores lo reconocerán y te ayudarán a crecer y a convertirte en un mejor codificador.

No tienes ganas de codificar, ¿verdad? Bueno, recuerde seguir guías como esta al abrir un problema.

Y nunca olvides que nadie está obligado a hacer lo que estás escribiendo; nadie debe hacer el trabajo por usted, en su problema.

Comience su 2018 con el pie derecho, no cometa el error colosal que cometí.

Use el código abierto de manera responsable y guíe con el ejemplo: la mayoría de las personas no leerán este artículo y / o no hablarán con un mantenedor activo en el corto plazo, pero si ven que así es como todas las personas a su alrededor usan el OSS "correctamente", se comportará igual.

mono mira mono hace

Feliz año nuevo a todos, hagámoslo bien juntos ?