Despedido por Google por crear la CLI de Google Workspace

Artículo original ↗ Discusión en Hacker News ↗

Un ingeniero de Google dice que fue despedido tras publicar como código abierto una herramienta de línea de comandos para Google Workspace bajo una organización de GitHub con apariencia oficial, lo que desató escrutinio sobre el branding, los procesos internos de aprobación y quién controla la dirección del producto. Los comentaristas se dividen entre verlo como una violación clara de políticas —especialmente por marcas registradas y revisión omitida— y como un ejemplo de la burocracia de las grandes tecnológicas sofocando la iniciativa y alejando a personas talentosas. El incidente alimenta preocupaciones más amplias sobre la cultura cambiante de Google, su creciente aversión al riesgo y la señal desalentadora que envía a los empleados que quieren lanzar herramientas útiles por iniciativa propia.

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.