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.
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!