Una contribución a un proyecto que no es tuyo se lee como trabajo creíble en un currículum cuando la entrada indica con precisión qué hiciste realmente: una pull request concreta que se fusionó, un error que rastreaste y corregiste, una revisión que diste y que moldeó el cambio de otra persona, o un rol de mantenedor que ocupas en el proyecto, en lugar de solo el nombre de un repositorio junto a un enlace. El trabajo de código abierto se diferencia de un proyecto que construiste tú mismo en un punto importante: tu nombre aparece en el historial de commits junto al de otros colaboradores, en un proyecto que ya tenía sus propios mantenedores antes de que llegaras y que siguió funcionando después de que tu cambio se integrara, así que la entrada debe indicar con precisión tu parte concreta en lugar de dejar que el lector asuma que eres dueño de todo el proyecto.
Por qué una línea de código abierto necesita una redacción distinta a la de un proyecto propio
Para un proyecto que construiste y controlas por completo, presentar proyectos personales en un currículum de ingeniero de software explica cómo describir qué hace, con qué lo construiste y qué cambió porque lo construiste. Una contribución de código abierto plantea primero una pregunta distinta, no qué hace el proyecto, ya que el lector suele poder comprobarlo en segundos si el proyecto es conocido, sino qué hiciste específicamente dentro de un proyecto que ya existía y ya tenía su propia dirección. Una línea vaga junto al nombre de un proyecto conocido, sin ninguna descripción de tu implicación real, puede leerse como un intento de tomar prestada la reputación de ese proyecto en lugar de describir trabajo real, que es justo lo contrario de lo que esa línea debería lograr.
Los tipos de contribución que vale la pena nombrar con precisión
Una pull request fusionada es la unidad de contribución más clara para nombrar, y decir qué cambió importa más que solo mencionar que existe: una corrección de un error concreto, una función nueva, una mejora de rendimiento, o un fragmento de documentación que faltaba. La revisión de código es trabajo real y valioso en un proyecto activo, y merece una línea aparte de tus propios cambios fusionados cuando has hecho suficiente para que cuente, sobre todo en un proyecto donde la calidad de las revisiones forma parte de cómo los mantenedores juzgan la posición de un colaborador. Un rol de mantenedor o de triaje, donde tienes acceso de escritura, revisas las pull requests de otras personas o gestionas los issues de un proyecto, merece su propia línea en lugar de fundirse en una mención genérica de "colaborador", porque dice algo que una sola corrección fusionada no dice: que otros mantenedores confían en tu criterio de forma continuada. Las contribuciones recurrentes al mismo proyecto durante varios meses también vale la pena describirlas como un patrón en lugar de listar solo el cambio fusionado más llamativo, porque un patrón se lee como una implicación sostenida y no como un hecho puntual.
Ejemplo ilustrativo: una línea de contribución de código abierto
Ejemplo ilustrativo, de vago a específico. Vago: "Colaborador, proyecto de código abierto (github.com/example/project)." Específico: "Colaborador, una herramienta de línea de comandos de código abierto usada para entornos de desarrollo locales. Corrigió un error que bloqueaba la herramienta con archivos de configuración grandes, y revisó varias pull requests de otros colaboradores del mismo repositorio durante seis meses." La versión específica nombra el propósito del proyecto en una frase, indica con precisión qué corrigió realmente el cambio fusionado, y separa el trabajo de revisión de la corrección, en lugar de dar a entender que toda la línea describe una sola contribución.
Reconocer el trabajo compartido sin exagerar
La mayoría de los cambios fusionados en un proyecto de código abierto activo suelen pasar por la revisión de otra persona antes de integrarse, y una entrada de currículum que da a entender que eres el único autor de una función que en realidad varios mantenedores moldearon juntos se lee como una exageración en cuanto alguien revisa el historial de commits, algo que en un repositorio público lleva solo segundos. Nombrar tu contribución concreta, una corrección, una función, un área que revisas con regularidad, en lugar de describir toda la funcionalidad del proyecto como si la hubieras construido tú solo, mantiene la línea honesta y, en la mayoría de los casos, más específica y creíble que una afirmación más amplia. Cuando varias de tus contribuciones se concentran en un área del proyecto, como sus herramientas de compilación o su conjunto de pruebas, nombrar esa área suele aportar más información al lector que listar varias pull requests pequeñas por separado.
En qué se diferencia de un proyecto que es completamente tuyo
Un proyecto personal que construiste desde cero merece una línea que describa su propósito y su resultado, porque tomaste cada decisión sobre qué hace y cómo. Una contribución de código abierto merece una línea que describa tu parte concreta dentro de las decisiones de otra persona, porque la dirección general, la arquitectura y el alcance del proyecto normalmente ya estaban fijados antes de que llegaras. Ambas cosas son trabajo técnico legítimo que merece un lugar en el currículum, pero confundir las dos, describir una contribución de código abierto de la misma forma en que describirías tu propio proyecto, tiende a exagerar tu papel en el proyecto compartido o a restar importancia al trabajo concreto que realmente hiciste.
Dónde va en el currículum
Una contribución de código abierto significativa, o un rol de mantenedor mantenido en el tiempo, suele merecer su propia línea dentro de una sección de proyectos junto a los proyectos personales, ya que ambos describen trabajo técnico fuera de un puesto remunerado. Varias contribuciones más pequeñas en distintos proyectos suelen agruparse mejor bajo un solo título, como "Contribuciones de código abierto", nombrando cada proyecto brevemente en lugar de dar a cuatro líneas delgadas y casi idénticas el mismo peso visual que a una entrada bien descrita. La plantilla Developer está construida con un área de proyectos junto al historial laboral, lo que encaja con este tipo de entrada, tanto si surgió de un empleo como si es completamente independiente.
Añádela a tu currículum
Una contribución de código abierto, descrita con precisión y acreditada con honestidad, es evidencia real de criterio técnico que el lector a menudo puede comprobar directamente. Empieza con una plantilla pensada para trabajo de ingeniería y añade tus contribuciones en el editor, donde puedes seguir puliendo la redacción a medida que lleguen nuevas contribuciones.