You're right, I was far too indignant. I can't say that I don't trust npm. I am a javascript developer, after all. For the most part, I have had a great experience working with Node.js and npm. Further, we were not affected by the bug at my company.

I hadn't seen the seldo's apology when I posted, but they do seem very honestly apologetic. Like I said, I have nothing against them messing something up time and again, especially something that shouldn't break responsible production environments. Everybody makes mistakes.

The big red flag to me was the deletion of Rob's criticism. I know they must have been very stressed out, but it wasn't a good move. The industry needs to question if we can rely on these people, and kneejerk reactions like that don't earn any trust.

Nobody can deny that trustworthiness is a touchy subject as npm transitions into a real company. Node developers rely on the reliability of thier development stack, and the reputation of node is largely in the hands of this organization. As npm changes and becomes more opaque, it will become harder for the open alternatives to keep up. If npm gets messed up, node does too. For developers working on production node projects, there is certianally something to loose. If the time comes that npm does need to be forked, the path forward will certianally be a bumpy one.

For the time being, I continue to trust npm for my js modules (and even with my "life", considering I have a few -g installed modules.) Like I said, developers working on node projects don't have much choice, but after reading their apologetic response I will continue to trust npm.

> better still JVM/.Net!

Sure do, enjoying them every day.

I'm not sure why you think version number is any indicator of quality. In any case, npm is 1.4.4 on my machine.

As per semantic versioning, 0.x.y is for development. That's not to say that code quality will be necessarily lower, but the API and functionality is expected/allowed to fluctuate prior to 1.0.0.

For more info on semantic versioning: http://semver.org/spec/v2.0.0.html

Your point regarding npm itself being beyond 1.0.0 is fully valid, I just wanted to clarify the reason for certain expectations existing based on version number.

node does not use semantic versioning.

Then there shouldn't be an expectation that it is "enterprise ready" at all, right? :P

Having looked, I can't find any link citing that one way or the other, but that doesn't change the fact that enough things these days do adhere to semantic versioning that many people expect certain things based on the version number.

node.js decided uses very non-semantic versioning. It's genarally understood that a 0.x release isn't production-ready, but node.js is widely considered production-ready and in fact every even-numbered release below 1.0 is considered stable. That's a pretty arbitrary and nonsensical scheme if you ask me, but you're not. The bottom line is that backwards incompatible changes aren't expected for a 0.x.y release where x is even.

I don't think it's an indicator of quality.

But "enterprise readiness" (whatever that means) which is what Rob the random commenter was talking about in his comment, seems silly on a runtime that is below version 1.0

Yes npm is 1.4.4, but node is 0.10.25. So an expectation of ANYTHING being "production ready" on a non-production ready runtime seems fraught.

I get that nodejs is high quality and it is run in production all over the place (I myself run it, and even meteor in production applications). But I understand there are risks and it's a fast moving target.