I understand the fact that it can be fairly expensive to run a large, popular module site such as npm and rubygems. What I'm curious about is how they intend to monetize npm, and how it affect users, if it does. Typically, VCs hope to get a return on their investment.
>The future is large, but I can pretty much guarantee that paying for access to open source modules is not ever going to happen. Not because it's evil (though, I believe is), but because it's stupid. It's just not a good model, and it's not hard to see why. No one wants to pay it, and rather than deliver value, you're making people go elsewhere. It is a case of the orchard selling lumber, burning down your value in order to get a short-term gain that can never expand.
>Many companies have been literally begging for me to figure out a way to take their money and add some features to npm. None of this impacts what any of you are currently doing, and in fact, it helps you, because it requires building additional high-availability systems that are robust enough for the next 10x increase we face.
>Like I said, all that is currently free will remain free, and all that is currently flaky will improve. There'll be some new stuff you can pay for if you want to use it, but if you're happy with the current status quo, you can just take it easy and maybe eventually get a job where you use npm for work stuff also :)
- Isaac Schlueter
Makes sense. One obvious power feature, that not only doesn't affect normal users, and would be well worth the money, is a locked down priority server. With npm being an open registry, any author can overwrite any release at any time. I don't want that possibility to happen on production, so if they provided a server with the versions you are using frozen from the general community, I would be interested in that.
You can specify what version you want.
That doesn't necessarily imply that version will continue to be available.
Ruby has the same problem with "yanked" versions of gems.
Stats in general seem like a pretty horrible monetization strategy considering the other obvious routes that would not be met with service-killing scorn. I would be shocked if the first option was not the route they take, with the second possibly coming later.
The messaging so far is that they don't intend for anything to change for typical users of npm, and that they'll make money with stuff like enterprise-level support. But I think it's still a bit in the air.
GitHub is another example of a company that caters to the open source community while still having a business plan.
Right now npm is at the core of every project using node.js, and businesses have more complex needs than open source projects. One such need would be having a private registry. You don't want to have your production build chain depending on packages that could be replaced by the author at any point in time. The current wisdom if you want protection from that is to run your own npm server, but why do that when you can just have the guys that do this exclusively do it for you?
This makes sense because there are business needs that don't overlap much with the open source world that they can sell, the same way GitHub does. GitHub was successful because they got the programming world using them for their open source projects, and after dominating over that market, those programmers took the service and recommended it to their employers, because that was the tool everyone was using.
Npm falls in the same business area, where the programming community is already using them, and businesses have other needs from them, that they currently cannot provide.
It would be nice for npm to put up a monetization blog post to clear up the confusion.
Enterprise offerings (support levels, private repositories, etc.) seem to be the most obvious. I could see many companies being interesting in an npm-style infrastructure for their non-OSS modules. Overall, this is interesting and will set a precedent going forward.
