Sobre compartir código y contribuir

Motivación

Esta mañana me he encontrado con un pequeño debate en twitter: una persona ha publicado un repositorio en GitHub con un juego (bastante molón, por cierto). A ese repositorio, por lo visto alguien le ha abierto una issue con varias sugerencias/consejos y se ha generado cierto debate sobre si se debe o no aportar a repositorios públicos, se sepa o no si el autor acepta contribuciones.

El código público

No es extraño que como desarrolladores queramos compartir lo que hacemos con la comunidad, ya sea porque pensemos que pueda ser útil para otros, porque alguien pueda aprender o, sencillamente, porque estemos orgullosos de algo que hayamos hecho. Aquí entran encima de la mesa las diferentes plataformas de repositorios de código que hay disponibles en el mercado: GitHub, Bitbucket, GitLab y otros... Es una forma de poder compartir nuestro código con los demás de una manera práctica, sencilla y, en la mayoría de los casos, gratuita.

Efectos colaterales

Estas plataformas, además de permitirte almacenar y compartir tu código con otros, o tenerlo ahí, de forma pública, añaden varias características a los proyectos almacenados en ellas. Para el caso del que estamos hablado, podemos centrarnos en dos:

• Un sistema de tiques o issues: Donde cualquiera puede incluir solicitudes para nuevas funcionalidades, pedir soporte o informar sobre algún bug en la aplicación.
• Un sistema de solicitudes de integración o Pull Requests: Donde cualquiera puede solicitar que una nueva funcionalidad, un arreglo o cualquier añadido en el código que haya realizado sea integrado al código principal o baseline.

Y con esto tenemos el contexto y la información necesarias para hablar de este asunto.

No todo el mundo quiere mantener sus proyectos

Y es normal, a veces repositamos nuestro código sólo por tenerlo almacenado en un sitio, o para consultarlo en algún momento futuro, o para compartirlo con un amigo, o para mostrarlo en una entrevista de trabajo, o dejarlo ahí por si alguien lo encuentra de casualidad y le sirve... Hay mil y una razones diferentes por las que uno puede querer tener su código en un repositorio público y la gran mayoría de ellas no buscan activamente la contribución de nadie de la comunidad. Diría que podemos clasificar este tipo de repositorios en tres tipos:

• Los que no buscan ni quieren contribución alguna.
• Los que no buscan la contribución, pero si llega, la evalúan.
• Los que buscan activamente y promueven la contribución de la comunidad.

Y ninguno de los anteriores es mejor que el otro.

Pero si pones el código en un sitio público te expones a que la gente lo critique o contribuya.
Señoro random. Cualquier año.

Y es cierto, al igual que es cierto que si salgo a la calle me expongo a que un desconocido me diga que si me afeitase estaría más guapo. Y sería igual de impertinente y de mal gusto que alguien me lo dijera sin yo haberlo pedido.

Las formas son importantes

El ejemplo que he puesto sobre el señor en la calle es una chorrada, pero me vale igualmente para ilustrar esto. Si ese señor se me acerca y me dice que soy un guarro porque llevo barba, lo más probable es que lo mande de vuelta por donde ha venido. Si ese señor se me acerca y me dice amablemente que debería quitarme la barba porque dice de mi que bla-bla-bla, le agradecería el consejo y luego lo mandaría de vuelta por donde ha venido.

La cuestión es que, si queremos contribuir o "ayudar" a alguien que no busca contribución en sus proyectos, debemos tener en cuenta que esa persona no nos ha pedido ayuda ni opinión, y es importante tener esto claro, porque luego nos sorprendemos cuando nos mandan a paseo muy amablemente.

No deberíamos ser condescendientes en nuestras contribuciones en el código de personas que consideramos que no saben, sino constructivos, no deberíamos decir eh, que te propongo estas refactorizaciones porque lo que has hecho tiene problemas por aquí y por allá en una issue. De nuevo, porque no nos han pedido nuestro consejo ni nuestra opinión y puede, perfecta y válidamente ser mal recibida. Y segundo, porque ese no es el foro.

Contribuye donde debes

Y ahora quiero hablar de la importancia de contribuir donde uno debe y en el foro correspondiente:

• ¿Tienes una sugerencia o ideas para una nueva funcionalidad? Usa las issues.
• ¿Tienes una mejora para un método de una clase que mejora el rendimiento? Abre una Pull Request.
• ¿Quieres incluir una nueva funcionalidad y tienes o quieres implementar el código para hacerlo? Primero abre una issue, habla con el dueño del código sobre por qué consideras que es necesario, y si le parece bien, abre una Pull Request.
• ¿Quieres refactorizar todo el proyecto porque tú lo habrías hecho mejor y el autor no sabe? Vete a tu casa, tómate un té, te abres tu propio repositorio y a programar. Deja al autor en paz.
• ¿No te gusta el proyecto, el autor, o como programa? Vete a tu casa, tómate un té y olvídate del proyecto.

Y, ojo, yo no estoy diciendo que me parezca mal que quieras contribuir en cualquier repositorio público que encuentres. Únicamente digo que, si lo haces, tienes que tener sentido común y saber que tu contribución puede acabar en el limbo. Y eso está bien.

¿Y cómo se si el autor de mi repositorio favorito va a aceptar mi contribución?

Esta es la buena. No hay una forma estándar para ello, pero aquí te dejo un par de trucos para mirarlo:

• Busca en el README.md alguna mención a cómo contribuir al proyecto.
• Busca el fichero CONTRIBUTING.md del proyecto, se suele usar para indicar cómo el autor espera que se contribuya.
• Mira las issues del proyecto, su ciclo de vida, sus etiquetas, si buscan contribuidores.
• Mira las Pull Requests del proyecto, si llevan mucho tiempo abiertas, si el autor las comenta, si se integran...

Si ninguna de estas cuatro cosas se cumplen, es bastante probable que el autor del repositorio no busque ayuda o contribuidores, así que tu contribución puede caer en saco roto.

Resumiendo

Los autores de los repositorios no tienen que decir explícitamente que no buscan contribuidores para sus proyectos, sencillamente con no decir que los buscan, es suficiente. Aún así, si aportas en estos repositorios y la respuesta no es la que esperas, no tienes derecho a la pataleta. Su código, sus normas.

Hay muchísimas formas de contribuir a un proyecto ajeno, desde la sugerencia de nuevas funcionalidades hasta meterte en el ring, tomar una issue y resolverla.

Y como colofón: cuando contribuyes a un repositorio que no es tuyo estás entrando a casa ajena. Se educado, no seas prepotente ni consideres que estás por encima de nadie. Porque tú no eres el dueño del producto. Tú solo eres un señor que le dice a otro señor que si se afeitase estaría más guapo.