Capítulo 15 de 33 10 secciones 7 min

Mirar un repositorio y saber si sirve

Cómo decidir en dos minutos si un proyecto está vivo o abandonado

<strong>Mira la fecha del último commit, no las estrellas.</strong> Las estrellas se acumulan y nunca bajan, así que un proyecto con veinte mil puede llevar seis años sin tocarse. Las cuatro señales que sí dicen la verdad son: cuándo fue el último commit, cuántas personas lo mantienen, si los issues abiertos tienen respuesta y si hay README y licencia. Todo eso se puede ver desde la terminal después de clonar.

Buscas "chatbot whatsapp python" en GitHub y salen doscientos proyectos. Alguno tiene doce mil estrellas y se ve precioso. ¿Ese?

Depende, y averiguarlo toma dos minutos. Este capítulo es esa revisión, que yo hago siempre antes de meter algo ajeno en un proyecto de cliente 🔍

Por qué las estrellas engañan

Una estrella en GitHub es un marcador: "esto me interesa, lo guardo". Se pone y casi nadie la quita. O sea que las estrellas miden popularidad acumulada desde siempre, no si el proyecto sigue vivo hoy.

Lo mismo pasa con los forks: cuentan cuánta gente lo copió alguna vez, no cuánta lo usa.

Las cuatro señales que sí valen

SeñalBuenaPara huir
Último commitSemanasMás de dos años
Quién mantieneVarias personasUna sola y sin actividad
Issues abiertosCon respuesta del autorCientos sin contestar
README y licenciaLos dosNinguno

Vamos a sacar las tres primeras desde la terminal. Primero fabricamos un proyecto con historia para tener qué mirar:

mkdir bot-ventas
cd bot-ventas
git init -q
printf '# Bot de ventas\n\nResponde pedidos por WhatsApp.\n' > README.md
git add README.md
git commit -q -m "Primera version del bot de ventas"
printf 'MIT License\n' > LICENSE
git add LICENSE
git commit -q -m "Se agrega la licencia MIT"
printf 'ciudad,monto\nLima,1200\n' > ventas.csv
git add ventas.csv
GIT_AUTHOR_NAME="Rosa Quispe" GIT_AUTHOR_EMAIL="rosa@ejemplo.com" \
  git commit -q -m "Entran las ventas de Lima"
printf 'Arequipa,890\n' >> ventas.csv
git add ventas.csv
GIT_AUTHOR_NAME="Rosa Quispe" GIT_AUTHOR_EMAIL="rosa@ejemplo.com" \
  git commit -q -m "Entran las ventas de Arequipa"
git log --oneline
1894118 Entran las ventas de Arequipa
da3c666 Entran las ventas de Lima
a612da0 Se agrega la licencia MIT
47b6407 Primera version del bot de ventas

Señal 1: cuándo se tocó por última vez

git log -1 --format="%ad" --date=short
2026-01-15

Un solo dato y es el más importante de todos. Si esa fecha tiene más de dos años y el proyecto depende de librerías que cambian, ya sabes 📅

Para verlo con más contexto, los últimos cinco con su fecha:

git log -5 --format="%ad  %s" --date=short
2026-01-15  Entran las ventas de Arequipa
2026-01-15  Entran las ventas de Lima
2026-01-15  Se agrega la licencia MIT
2026-01-15  Primera version del bot de ventas

Señal 2: cuánta gente lo sostiene

git shortlog -sn


A la izquierda cuántos commits, a la derecha quién. Un proyecto con una sola persona no es malo, pero es frágil: si esa persona se cansa, se acabó. Esto se llama el bus factor y con uno solo conviene saberlo antes 🚌

Señal 3: qué hay dentro

ls -a
test -f README.md && echo "tiene README"
test -f LICENSE && echo "tiene licencia"
.
..
.git
LICENSE
README.md
ventas.csv
tiene README
tiene licencia

Sin licencia, el proyecto es de su autor y punto. Lo vemos en el capítulo 16, porque tiene más consecuencias de las que parece.

Señal 4: los issues

Esta no sale por terminal, porque los issues viven en GitHub y no en Git. Pero es la que más me dice: entra a la pestaña Issues, ordena por más recientes y mira si el autor contesta. Un proyecto con trescientos issues abiertos y ninguna respuesta en un año está abandonado aunque el código se vea impecable.

Mismo truco en Pull requests: si hay veinte propuestas de gente esperando desde hace meses, nadie está al volante 🛞

El resumen de dos minutos

echo "== ultimo commit ==" && git log -1 --format="%ad  %s" --date=short
echo "== gente ==" && git shortlog -sn | head -3
echo "== archivos clave ==" && ls | head -5
== ultimo commit ==
2026-01-15  Entran las ventas de Arequipa
== gente ==
== archivos clave ==
LICENSE
README.md
ventas.csv

Eso, pegado en la terminal después de clonar, resuelve la decisión casi siempre 🧾

La trampa

Buscas una librería para conectar tu bot de WhatsApp, encuentras una con muchísimas estrellas y la instalas sin dudar.

$ git log -1 --format="%ad" --date=short
2019-03-11

$ ls
README.md  setup.py  whatsapp_bot
Qué está mal

Doce mil estrellas y siete años sin tocarse ⭐️

Las estrellas son un marcador de popularidad histórica, no de salud: se acumulan y no se caen nunca. Un proyecto puede tener veinte mil y estar abandonado desde antes de la pandemia.

Lo que sí dice la verdad es la fecha del último commit, cuántos issues abiertos hay sin respuesta y si los últimos pull requests llevan meses esperando.

En una librería abandonada no solo faltan funciones nuevas: faltan los parches de seguridad, y esa es la parte cara.

Comprueba que se entendió

Comprueba que lo tienes

Dos librerías hacen lo mismo. Una tiene 12.000 estrellas y último commit de 2019. La otra tiene 300 y último commit de la semana pasada. ¿Cuál usas?

  • La de 12.000, es la que usa todo el mundo
  • La de 300, que sigue viva
  • La que tenga mejor README
  • Ninguna, mejor lo hago yo

Ejercicios

1. Arma un proyecto con historia

Crea el repositorio del reporte de canales con cuatro commits de dos personas distintas.

cd ..
mkdir reporte-canales
cd reporte-canales
git init -q
printf '# Reporte por canal\n' > README.md
git add README.md
git commit -q -m "Arranca el reporte por canal"
printf 'canal,monto\nBodegas,4200\n' > canales.csv
git add canales.csv
git commit -q -m "Entran las bodegas"
printf 'Horeca,3100\n' >> canales.csv
git add canales.csv
GIT_AUTHOR_NAME="Rosa Quispe" GIT_AUTHOR_EMAIL="rosa@ejemplo.com" \
  git commit -q -m "Entra el canal horeca"
printf 'Mayoristas,5600\n' >> canales.csv
git add canales.csv
git commit -q -m "Entran los mayoristas"
git log --oneline
e399c07 Entran los mayoristas
9c5b8c0 Entra el canal horeca
d69f94f Entran las bodegas
82ae78b Arranca el reporte por canal

Cuatro commits y dos autores. Ya hay algo que revisar.

2. Saca la fecha del último commit

La señal número uno, en una línea.

git log -1 --format="%ad" --date=short
2026-01-15

Si esa fecha te asusta, el resto de la revisión ya no hace falta.

3. Cuenta quién sostiene el proyecto

Lista los autores ordenados por cantidad de commits.

git shortlog -sn

Dos personas. Con una sola, el proyecto depende de que no se aburra 🚌

4. Mira el ritmo por mes

Agrupa los commits por mes para ver si el proyecto se mueve o solo tuvo un arranque.

git log --format="%ad" --date=format:"%Y-%m" | sort | uniq -c
      4 2026-01

Un mes con veinte commits y nada después es la firma del proyecto que se empezó con ganas y se dejó.

5. Comprueba los archivos clave

Mira si tiene README y licencia.

test -f README.md && echo "README si" || echo "README no"
test -f LICENSE && echo "licencia si" || echo "licencia no"
README si
licencia no

Sin licencia hay que preguntar antes de usarlo en algo de un cliente.

6. Busca claves olvidadas dentro

Antes de confiar en un proyecto ajeno, revisa que no traiga secretos publicados por descuido.

grep -rn "API_KEY\|password\|secret" . --exclude-dir=.git || echo "limpio"
limpio

Si aparece algo, no es solo un descuido: dice cómo trabaja quien lo mantiene 🔑

7. Pide la revisión de un archivo que no existe

Prueba a mirar la historia de un archivo que el proyecto no tiene.

git show HEAD:ventas-2019.csv
fatal: path 'ventas-2019.csv' does not exist in 'HEAD'

Git te dice que ese archivo no está en la historia, en vez de devolverte algo vacío que parezca una respuesta 🤷‍♀️

Lo que te llevas

Las estrellas cuentan el pasado. La fecha del último commit y quién contesta los issues cuentan el presente.

¿Tienes alguna duda o consulta?