Despedido por Google por crear la CLI de Google Workspace

Contexto y qué ocurrió

• La discusión gira en torno a una CLI de Google Workspace, publicada en GitHub bajo una organización propiedad de Google, con branding de Google y un descargo de responsabilidad de “no es un producto oficialmente soportado”.
• El ingeniero que la construyó dice que después fue despedido y atribuye parte de ello al temor interno a la disrupción de “agents” y la automatización para Workspace.
• El repositorio sigue siendo público y está enlazado desde la documentación oficial de Workspace, lo que a muchos les parece contradictorio si realmente fue una violación de la política.

Proceso de código abierto / lanzamiento y si se siguió

• Varios Googlers actuales y antiguos describen procesos bien definidos para:
  • Abrir el código fuente.
  • Usar marcas registradas/branding de Google.
  • Lanzar cualquier cosa externa (mediante herramientas IARC/Launcher, aprobaciones a nivel de director, etc.).
• Otros dicen que estos procesos son complejos, cambian constantemente y difieren según la organización; los equipos de DevRel históricamente tenían más autonomía y a menudo publicaban directamente en organizaciones de GitHub.
• El ingeniero afirma que siguió el proceso y que se “cambiaron bits” y hubo un lanzamiento respaldado por su gerente.
• Un supuesto Googler actual afirma que el ingeniero inició el proceso, fue confrontativo en la revisión, el lanzamiento se canceló y aun así siguió adelante.

Branding, marcas registradas y riesgo

• Muchos sostienen que el nombre del proyecto, la redacción del tuit, el nombre de la organización y el logo hicieron que pareciera un producto oficial, que es precisamente lo que las políticas buscan evitar.
• Otros responden que decenas de repos de Google usan branding y descargos similares, y que las preocupaciones legales podrían haberse solucionado con un cambio de nombre y de logo en lugar de terminar el contrato.

20% time, proyectos paralelos y propiedad intelectual

• Los comentaristas señalan que, en toda la industria tecnológica, cualquier cosa relacionada con el trabajo creada con tiempo o recursos de la empresa es propiedad de la empresa.
• Los proyectos de 20% nunca pretendían eludir la revisión legal o de lanzamiento ni competir con productos internos ya en desarrollo.
• Algunos argumentan que los empleados suelen malinterpretar esto, especialmente cuando programan en máquinas personales en casa sobre ideas cercanas al trabajo.

¿Estuvo justificado el despido?

• Un bando: violar políticas claras, hacerse pasar por un producto oficial e ignorar decisiones legales/de gestión son motivos legítimos para despedir, especialmente en una empresa grande y propensa a litigios.
• Otro bando: como mucho, esto merecía una reprimenda severa; despedir a un ingeniero de DevRel productivo que lanzó una herramienta popular basada en API es una reacción exagerada y una mala gestión del talento.

Señales sobre la cultura de Google y la innovación

• Muchos ven esto como un emblema del paso del viejo ethos de “20% time / construir cosas geniales” hacia una burocracia aversa al riesgo, la protección de feudos internos y el miedo a la disrupción interna.
• Otros argumentan que, dada la escala de Google y su exposición legal, son necesarios controles fuertes y una marca centralizada, aunque eso frene parte de la iniciativa individual.

Puntos poco claros / en disputa

• Si el lanzamiento fue aprobado por completo o bloqueado explícitamente.
• Cuánto influyó la existencia de una CLI “oficial” en curso o de una estrategia de IA/agents en la decisión.
• Por qué el repositorio sigue arriba si realmente era inaceptable.