因创建 Google Workspace CLI 而被 Google 解雇

原文 ↗ Hacker News 讨论 ↗

背景与发生了什么

  • 讨论的中心是一个 Google Workspace CLI，它以 Google 拥有的组织名义在 GitHub 上发布，带有 Google 品牌标识，并附有“不是官方支持产品”的免责声明。
  • 这位构建它的工程师说，之后自己被解雇了，并将原因部分归结为内部对“agents”和 Workspace 自动化可能带来颠覆的担忧。
  • 该仓库仍然公开可见，并且被官方 Workspace 文档链接，这让很多人觉得如果这真是违反政策的行为，就显得很矛盾。

开源 / 发布流程以及是否遵循

  • 一些现任/前任 Googler 讲述了非常明确的流程，用于：
    • 开源代码。
    • 使用 Google 商标/品牌标识。
    • 发布任何外部内容（通过 IARC/Launcher 工具、总监级审批等）。
  • 也有人说这些流程很复杂、不断变化，而且因组织而异；历史上 DevRel 团队拥有更大的自主权，常常会直接发布到 GitHub 组织中。
  • 这位工程师声称自己遵循了流程，并且有“bits flipped”以及经理支持的发布。
  • 一位自称是现任 Googler 的人则声称，这位工程师启动了流程，但在审核中态度强硬，发布被取消，而他们仍然继续推进了。

品牌、商标与风险

  • 许多人认为，这个项目名称、推文措辞、组织名称和 logo 让它看起来像官方产品，而这正是这些政策要防止的情况。
  • 另一些人反驳说，谷歌有几十个仓库使用类似的品牌与免责声明，而法律方面的顾虑本可以通过重命名和更换 logo 来解决，而不是直接解雇。

20% 时间、副项目与知识产权

  • 评论者指出，在科技行业里，任何使用公司时间/资源做出的与工作相关成果通常都属于公司财产。
  • 20% 项目从来都不意味着可以绕过法律/发布审查，或与正在推进中的内部产品竞争。
  • 有些人认为员工常常误解这一点，尤其是在家用个人电脑编写与工作相关想法时。

解雇是否正当？

  • 一派观点认为：违反明确政策、冒充官方产品，以及无视法务/管理层决定，在这样一家大型、易诉讼的公司里，都是合理的解雇理由。
  • 另一派观点认为：最多也只是应当严厉训诫；解雇一位高产的 DevRel 工程师、而且他还交付了一个受欢迎的、基于 API 的工具，这是反应过度，也是不善于管理员工。

关于 Google 文化与创新的信号

  • 很多人将此视为一个标志：从过去“20% 时间 / 做酷东西”的精神，转向更规避风险的官僚主义、内部地盘保护，以及对内部颠覆的恐惧。
  • 也有人认为，以 Google 的规模和法律风险来看，强控制和集中化品牌管理是必要的，即使这会压制一些个人主动性。

不明确 / 存在争议的点

  • 发布是否已获得完全批准，或是否被明确叫停。
  • 正在推进中的“官方” CLI 或 AI/agent 战略的存在，在多大程度上影响了这一决定。
  • 如果这真是不可接受的，为什么仓库仍然保留在线。