Build cool shit and follow the proper release procedures for it. There is a huge difference between something unrelated to your employer on a personal repo, youremployerrepo/api-samples, and calling something "Employer Majorproduct CLI" on an official employer repo which is bound to be confused for an official release.

I would have been fired from every employer I've ever worked for of any size for doing something like that - including Google circa 2018.

▲

DANmode 3 hours ago | parent [-]

> follow the proper release procedures for it

What happens when your thing

or nothing close to your thing

will ever see the light of day?

▲

no-name-here 3 hours ago | parent | next [-]

1. If google said ok but don't release under google’s name/in google’s repo, do that.

2. If google said no this goes against our goals for the product, don't release it if you want to keep working for google?

▲

sib 3 hours ago | parent | prev | next [-]

Is that relevant here,

given that Google was creating an official thing

quite close to his thing

at the same time?

(And why are we writing like this?)

▲

gedy an hour ago | parent | next [-]

Would you like them

in a house?

Would you like them

with a mouse?

▲

seanhunter 2 hours ago | parent | prev | next [-]

Fair to point out,

the official google thing,

was quite a lot worse

than his thing.

(I’m quite into the whole “Posting in free verse” idea)

▲

DANmode 2 hours ago | parent | prev [-]

> Google was creating an official thing quite close to his thing

Just link to it.

	▲	Arainach 2 hours ago \| parent [-]
		It's mentioned in the original link for this post.

▲

Arainach 2 hours ago | parent | prev [-]

None of that is relevant. You're working on things for their employer, they control when and if anything is released. Most of us have worked on projects that were cancelled - even when that happens you don't just release it anyway.