Yikes. The lack of judgement involved in personally releasing something that could be confused for an official release (I was confused) by your employer is someone who has huge wildcard risk in the future. I would expect significant disciplinary action if they didn't follow procedure, and termination if they were directly warned at any point.
The real problem is that OP is or wants to be an old school disruptor working at what used to be an exciting and disruptive employer (but isn't any more - its just a boring old money maker).
OP crank out a pretty decent and well received, by the community, product and get absolutely canned because they are well out of touch of how Google now works. You don't do risk (without reward) at Google and you certainly don't show a bit of ankle or look exciting. Google are well out of the market for being interesting (outside of the balance sheet and P&L for those who fetishise in accountancy.
Unfortunately: going viral isn't always a good thing as anyone who has experienced a nasty virus will attest.
> what used to be an exciting and disruptive employer (but isn't any more - its just a boring old money maker).
I feel sorry for this person, but I would be surprised if this would have been okay at Google in the past 20 years. It wouldn't have been okay at any company I've ever worked at, big or small.
I think there's a valid argument that this started as a simple DevRel script or trick, but due to the way you can write a lot of code very quickly with AI it expanded to something that resembled a full-blown product.
Maybe uncharted territory as the previous assumption was that an individual DevRel person releasing scripts couldn't be mistaken for a supported product because one person couldn't produce that much code in the past.
Dunno about 20, but 7 years ago, they fired a security engineer for forcing in a CL for their internal Chrome extensions to put a disapproving banner on certain anti-union websites. Wasn't a very harmful change, but because she left a clear paper trail of circumvented code/release reviews, she couldn't be trusted anymore.
That was a security engineer modifying internal security tooling without proper permissions/reviews.
The union piece was probably extra motivation but still you just do not do that to security infra, it should always be a firing offense unless it was a truly exceptional circumstance.
Conversely, this guy was in a DevRel role where it sounds like they released open source stuff all the time and the line was a lot more fuzzy (admittedly I've only heard one side of the story).
I would encourage this sort of thing in my company. I'm not google. I'm not legally beholden to anyone except myself and my business partners ... and my own sense (which is worryingly odd!)
Google can never be exciting or interesting evermore by design and intent. They dived on in and went "money" full on. They exist to generate revenue for their shareholders. They dumped the "Don't be evil" thing without blushing.
I think your encouragement is admirable but could be interpreted as naive.
For one thing, the author of this tool used Google trademarks (the logo) to represent the project.
If you are even slightly larger than a mom and pop small business you pretty much have to defend that trademark or else you risk losing it.
But, okay, fine, you can just tell them not to use your trademark and have them say it's not an official thing. No big deal.
The other thing I would say is that growing beyond even a relatively small number of employees fundamentally changes everything. Once you don't have that face to face with all your employees that trust level between you and them can't possibly be the same, no matter how good your intentions are. Even a modest company with 25-50 people...how well can you know those people, really? Even if you try your hardest to know them?
Once you have a certain number of employees you run into probabilistic realities.
Google has over 100,000 employees, which means statistically speaking a few of them have committed or will commit homicide. The idea of "we trust all our employees" can't exist from a mathematical perspective, even if the leadership happens to be the nicest people in the world who really want their employees to have freedom and autonomy.
In a modest 25 people company you absolutely can just go and do this of your own initiative and it will be tolerated or encouraged. Any company that size where it's not possible will close in 18 months when it runs out of investor money without having accomplished anything. You should still mention you're doing it beforehand, though.
In this case I guess the only other option the person had is to quit to build something of their own or work at another more builder friendly company, but at least in this case they got to release a thing that was valuable to many people and got popular, so they got some good publicity out of that. So ultimately I don't see that their actions were wrong overall.
Getting fired like this and then bad-mouthing your previous company is not good publicity for most employers.
I meant the person got good publicity, not Google. Google got bad publicity.
Yeah this is super weird to me, because the processes at Google for employees to release and attribute ownership of open source projects are extremely clear and well established. It's genuinely hard for me to imagine this happening in a way that confused or caught the author off guard.
It's totally fair to question the wisdom of those processes and policies!
But I'm pretty skeptical of the "I'm surprised I got in trouble for this" narrative.
Clueness sometimes goes hand-in-hand with perceived freedom. I think it's that cause and effect are not as often connected (consequences). I remember a Google employee updating a Google font that broke thousands of websites. Community members explained that Google recommended (at that time) letting Google host the font, and that they could fork it instead, or find a path that wouldn't break so many websites. The employee took the implication of consequences as being connected to ther actions as an aff(r)ont "They can just host it themselves"; "they can switch to another font/redesgin their site". When it was pointed out that the cause would not be known to most, and that budgets would have to be found to ferret out the cause and implement the solution, etc., etc., the Google employee stopped responding.
We take annual training that warns us against doing what this engineer did.
yes we all pay attention to 'the training'
Again, I'm pretty skeptical that this person completely missed this part of the training for seven years.
Yeah that's kind of the impression that I had.. should have ran it past his superiors. Hope he learns something from this instead of deflecting like he seems to be doing.
His boss is the one that announced the tool.
Superiors like...his manager, who announced the project for him?
If that's really the case (which isn't really clear from this post) then I feel like we're missing some details.
In any reasonable company (with common sense leadership), someone would not be fired for doing something (with good intentions) that does not harm company very much.
Releasing something like this did not really harm the company (the project is still on GitHub).
Any smart executive could have spun the release of this CLI into a win.
Even if some other team complained that this was encroaching on their work, a smart executive would say: “cool show me your work tomorrow morning so we can replace this with you work”
What if they were told not to do it and they still did?
I do not want to speculate too much. Sure, many things could have happened, even things unrelated to this project, that led to the firing.
But since this project is still on GitHub, I would say the project itself was probably not so bad that releasing it should be a fireable offense.
So my thinking is this:
Did the employee act with the goal of helping the company?
If the answer is yes, and the action did not cause serious harm to the company, then you do not fire the employee. At my old company, the employee would probably be sent to take a couple of courses related to whatever rule they broke.
In general, smart people should be encouraged to take initiative.
The real problem (and the reason why you have all these HR rules) is when you have stupid employees who take initiative. Actually, you should never hire someone who is both unintelligent and full of initiative. It is okay to hire someone who is stupid and lazy and has no initiative (You need those people too).
And OP is obviously smart and talented and should be encouraged to take initiative.
Depends on the reason. If there was a valid reason not to release it, then sure. But it's hard for me to see what can be so problematic about releasing a cli wrapper. It's hard to think of anything non political. And politics isn't valid reason to me. If someone from the leadership was e.g. blocking the release out of pettiness then I'd cheer on the person releasing it - assuming they know the risks.
Particularly for a company that possibly has to navigate high-volume, often frivolous litigation and brand attacks from trolls. I have been in similar situations having to partner with legal defending the most frivolous things on products released. You literally sign docs to not do such things when u onboard. Not sure what the point of broadcasting this is though.
You are assuming that it was "personally" releasing something and that the process wasn't followed.
You continue to dance around this question on this post - did you or did you not follow Google's open source approval process[1]? Did you have an approved Ariane/Launcher2 entry?
1: https://opensource.google/documentation/reference/releasing/...
Yes
Did you have your launch approved? So did you follow the process?
Why isn't it under google's username on github?
Why does the repo say "This is not an officially supported Google product."?
Is it actually approved by Google or not?
You need to actually answer these questions instead of dodging them.
Are you the "serious consequences for ____" guy?
The reason you think he's "dodging" the questions is because you clearly don't know anything about the situation, like the fact that it was published under the github organization used by the workgroup he was in, same as a lot of other software the group authored.
Why is the repo still there if it's such an egregious violation of Google's policies?
> Why isn't it under google's username on github?
It's under "googleworkspace", one of Google's GitHub organizations (linked on https://developers.google.com/workspace).
> Why does the repo say "This is not an officially supported Google product."?
This seems to be boilerplate that Google puts on open-source releases, e.g: https://github.com/GoogleContainerTools/kaniko
It's not saying that it's not released by Google, but that it's not an officially supported Google product. I presume to make it clear that it's not covered by support agreements/bug bounties/etc. in the way products like Google Docs would be.
> Is it actually approved by Google or not?
It went through the launch/approval process (https://news.ycombinator.com/item?id=48655744) and was announced by Justin's manager.
Your ships would have been sunk during the 2002 Millennial challenge and an entire bureaucracy would defend you for the next 20 years.
Not only that but not clearing with your management that you're not working on something that is actually being worked on as a product.
Definitely they put some manager and/or team in a very uncomfortable position releasing this.
Management literally announced it for him.
That's a gross misunderstanding of corporate life.
_A_ manager boosted it on twitter. It's not an announcement in the sense that companies announce things. You're also assuming that one team knows what the other is doing.
This is literally the reason there are standard procedures for doing things like this.