I wrote extensive gulp pipelines and workflows for my organization that have more than 1,100 node modules installed across combinations of packages and their versions. There are many different authors at play. I am not opposed to work towards compensating someone for their efforts if their product provides value at its price, of course, but I am trying to determine how compensation models would work out practically for tools this large, given the amount of authors that would be involved. I suspect that my organization would arrive at having our teams rewrite much from scratch to be proprietary (at a huge cost), pay for turnkey solutions that may not fully deliver, or drastically reduce features to build our applications.
It's quite a conundrum really, and we have seen what happens when altruistic maintainers burn out or move on (recall the event-stream incident). Nobody owes us anything, and we have accepted the fragility that comes with the systems we've adopted.
Based on what I wrote, wouldn't only gulp itself be Parity, in which case they just pay for a single gulp license? Maybe there's a few more packages in there.
I think a really interesting bit here is that licensezero itself has tools that automate the process of buying these licenses, and I think that tooling could improve even further if the need arose.
At least gulp but also all its gulp plugins that can be used. I originally thought that I would still need to have awareness of license types for all dependent packages, too, but rereading your post makes it clearer to me that that should be abstracted enough. I wonder where the ultimate responsibility lies if a package has a dependency but does not honor its license or payment model correctly. Is only the package at fault or also my organization for including (and possibly paying) this package while satisfying its but perhaps not its dependent's licenses? That's what made me worry about my large amount of dependencies originally.
As a believer in markets typically finding and providing good solutions, I wholeheartedly agree with you that tooling will improve to satisfy both provider and consumer of these products.
From an ease-of-use perspective, I suspect that one avenue would simply be a subscription model through a registry. You could have registries such as npm compete with other registries similarly to how music and video subscriptions are done. Reducing barriers of entry for consumers is key to choosing services. If an organization was charged X per month or year to have unlimited downloads of packages, that would be a much easier pill to swallow than dealing with individual licensing requirements on a per package or per author basis. With that would come the expectation that service providers a) pay out their package authors / contributors appropriately, and b) some assurances that packages are safe, curated, inspected, etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for taking a stab at it, Kat!
I wrote extensive gulp pipelines and workflows for my organization that have more than 1,100 node modules installed across combinations of packages and their versions. There are many different authors at play. I am not opposed to work towards compensating someone for their efforts if their product provides value at its price, of course, but I am trying to determine how compensation models would work out practically for tools this large, given the amount of authors that would be involved. I suspect that my organization would arrive at having our teams rewrite much from scratch to be proprietary (at a huge cost), pay for turnkey solutions that may not fully deliver, or drastically reduce features to build our applications.
It's quite a conundrum really, and we have seen what happens when altruistic maintainers burn out or move on (recall the event-stream incident). Nobody owes us anything, and we have accepted the fragility that comes with the systems we've adopted.
Based on what I wrote, wouldn't only
gulpitself be Parity, in which case they just pay for a singlegulplicense? Maybe there's a few more packages in there.I think a really interesting bit here is that licensezero itself has tools that automate the process of buying these licenses, and I think that tooling could improve even further if the need arose.
At least gulp but also all its gulp plugins that can be used. I originally thought that I would still need to have awareness of license types for all dependent packages, too, but rereading your post makes it clearer to me that that should be abstracted enough. I wonder where the ultimate responsibility lies if a package has a dependency but does not honor its license or payment model correctly. Is only the package at fault or also my organization for including (and possibly paying) this package while satisfying its but perhaps not its dependent's licenses? That's what made me worry about my large amount of dependencies originally.
As a believer in markets typically finding and providing good solutions, I wholeheartedly agree with you that tooling will improve to satisfy both provider and consumer of these products.
From an ease-of-use perspective, I suspect that one avenue would simply be a subscription model through a registry. You could have registries such as npm compete with other registries similarly to how music and video subscriptions are done. Reducing barriers of entry for consumers is key to choosing services. If an organization was charged X per month or year to have unlimited downloads of packages, that would be a much easier pill to swallow than dealing with individual licensing requirements on a per package or per author basis. With that would come the expectation that service providers a) pay out their package authors / contributors appropriately, and b) some assurances that packages are safe, curated, inspected, etc.