When I was there, there was no universal process; different teams had different processes based on their focus. There was a launch process for Google products and there was the open source office for approving open source code (which amounted to a rubber stamp in my experience; they mainly checked for boilerplate issues). As I said above, my team and others were allowed to publish at our discretion.
Even if this person violated that process, it is an extreme consequence to fire them for that infraction.
>there was the open source office for approving open source code (which amounted to a rubber stamp in my experience; they mainly checked for boilerplate issues)
In 2018 I applied for a permission to work on an open-source project, in my own spare time, and I was denied. The problem was the license (AGPL is like poison to corporations), but it's my after-hours side project anyway so I still don't get why it mattered.
They basically deny everything. They say they don't want to give bored people a reason to leave, but that's seemingly outweighed but not wanting to give bored people something besides their day job to focus on. Even at Google, plenty spend non-work hours on work, instead they might spend it on a side project.
They don't really have the teeth to deny it if you live in California, where there are laws partially invalidating those non-compete clauses, but most people will just accept it.
It's a fair point that it's still up, though looking just now for two minutes there are at least some issues with auth[1] which would make me really not trust it.
It was just speculation about what could be bad enough if they really did have permission to release it, but the OP is being so cagey below now I'm just wondering if they got release permission but misrepresented what they would be releasing or something.
> and is official [1]
FWIW no idea what you're trying to point out on that page unless you mean the one link to a different project in the same github org indicates the org is official, but that never seemed in doubt in this thread of comments.
Maybe at this point it's even more disruptive to delete it since people are using it. There's a real reason to not want someone to release an official-looking CLI when you're already doing an actual official one for the same thing.
Idk if the firing was justified since he supposedly followed process and had manager approval, but that's only one side.
> If that's a real problem and fireable offence, then there's people at Google that should be fired ASAP for failing to delete this repository.
Unclear what you're referring to here. Was it "misrepresented what they would be releasing"?
If that's the case, I disagree that the repo still existing is on its face evidence against that theory. It could be a perfectly fine tool, but if you lie on a release checklist, depending on what you lie about, it's easy enough to imagine a fireable offense. There are multiple ways that "it's easier to ask forgiveness" can backfire if there are legal things or organizational things you are knowingly avoiding.
Again, this is just speculation. I wouldn't personally fire someone for releasing a library that got popular, but its also speculation to suggest that's the only reason he was fired.
Even if this person violated that process, it is an extreme consequence to fire them for that infraction.