I can totally relate. What bothers me is that all these utility functions are made during company hours. Can you really publish them on your private github, or even take the decision "These stuff will go under the MIT-licence"?
That's a great point that I didn't even touch on in this post - but I know that there are some companies that encourage and quantify the open source contributions made by their employees. I think those companies are the exception. But they do exist. And if you had that kinda policy in place, it would encourage more of your own coders to avoid copying-and-pasting "utility" code from one project to another.
These are good points - and they're pretty much the same points that kept me from taking an NPM-package-approach for years. I don't claim to have perfect answers, but these are some of my opinions on it at the time being:
For the sake of argument, let's say that you have some ridiculously-simple function. For me, a good example would be this: npmjs.com/package/@toolz/create-ra...
There are a thousand different ways that you could choose to generate a random ID. But I got tired of constantly rewriting/copying the same logic every time I needed to do this. So I put it into an NPM package.
I can't honestly remember the first time that I wrote this function. Was it for an employer? Maybe. I'm just not sure. But I know that in the last several years, I've used it at numerous jobs - and in numerous private projects. So it'd be quite a stretch to claim that it's the "property" of any one employer. More importantly, the logic within it is just really... generic. It's not generating random IDs according to a given company's standard. Nor does it contain the kinda logic that, say, saves those IDs in a company database or retrieves those IDs from a company endpoint. It's just a dead-simple utility function.
What if you wrote a standalone function that divides by 2? (OK... that'd be kinda silly - but I'm just illustrating a point.) If your employer paid you to write that code, it would technically be "their" code. But, c'mon... it's a divide-by-2 function! If your employer pays you to play a drum, that doesn't mean that your employer now owns the act of hitting a drum with a drumstick. Nor would they own the sound that's generated from hitting a single drum one time with a drumstick. They would only own the compositions they paid you to create (just as they own the apps that we develop in our jobs).
Also, you aren't required to use the MIT license for NPM packages. In fact, you can kinda have whatever license you want. The MIT license is just sorta the "default" that you see on NPM. And of course, you don't have to publish public packages on NPM. You can have private packages - although that diminishes many of the benefits that I'm talking about here.
So in summary, I'm not encouraging anyone to start pushing their company's IP out to NPM - and then claiming it as their own. But if you've written something that's truly a utility function - the kinda functionality that you're gonna find yourself copying-and-pasting between different work projects, and personal projects, and even between multiple employers - then yeah, go ahead and put that code into a package.
I can totally relate. What bothers me is that all these utility functions are made during company hours. Can you really publish them on your private github, or even take the decision "These stuff will go under the MIT-licence"?
You are right, I guess we need a policy to manage Open Source work in Companies' hours.
That's a great point that I didn't even touch on in this post - but I know that there are some companies that encourage and quantify the open source contributions made by their employees. I think those companies are the exception. But they do exist. And if you had that kinda policy in place, it would encourage more of your own coders to avoid copying-and-pasting "utility" code from one project to another.
These are good points - and they're pretty much the same points that kept me from taking an NPM-package-approach for years. I don't claim to have perfect answers, but these are some of my opinions on it at the time being:
For the sake of argument, let's say that you have some ridiculously-simple function. For me, a good example would be this: npmjs.com/package/@toolz/create-ra...
There are a thousand different ways that you could choose to generate a random ID. But I got tired of constantly rewriting/copying the same logic every time I needed to do this. So I put it into an NPM package.
I can't honestly remember the first time that I wrote this function. Was it for an employer? Maybe. I'm just not sure. But I know that in the last several years, I've used it at numerous jobs - and in numerous private projects. So it'd be quite a stretch to claim that it's the "property" of any one employer. More importantly, the logic within it is just really... generic. It's not generating random IDs according to a given company's standard. Nor does it contain the kinda logic that, say, saves those IDs in a company database or retrieves those IDs from a company endpoint. It's just a dead-simple utility function.
What if you wrote a standalone function that divides by 2? (OK... that'd be kinda silly - but I'm just illustrating a point.) If your employer paid you to write that code, it would technically be "their" code. But, c'mon... it's a divide-by-2 function! If your employer pays you to play a drum, that doesn't mean that your employer now owns the act of hitting a drum with a drumstick. Nor would they own the sound that's generated from hitting a single drum one time with a drumstick. They would only own the compositions they paid you to create (just as they own the apps that we develop in our jobs).
Also, you aren't required to use the MIT license for NPM packages. In fact, you can kinda have whatever license you want. The MIT license is just sorta the "default" that you see on NPM. And of course, you don't have to publish public packages on NPM. You can have private packages - although that diminishes many of the benefits that I'm talking about here.
So in summary, I'm not encouraging anyone to start pushing their company's IP out to NPM - and then claiming it as their own. But if you've written something that's truly a utility function - the kinda functionality that you're gonna find yourself copying-and-pasting between different work projects, and personal projects, and even between multiple employers - then yeah, go ahead and put that code into a package.
Great org name. Surprised that was available.
yeah - I had to cycle through quite a few already-taken "orgs" before I found that one!