<div><br></div><div>I didn&#39;t speak about it further, because in my estimation it wasn&#39;t viable, especially compared with the other two options.  In particular, these are the things I didn&#39;t like about npm and why I didn&#39;t think it warranted further consideration, in no particular order:</div>
<div><ul><li>The npm registry is wholly independent of GitHub and requires a registry in order to find packages, and is clearly geared towards serving NodeJS.  We would either have to integrate every package into the &quot;NodeJS registry&quot; (although they wouldn&#39;t be NodeJs modules) or create a separate registry and get everyone to &quot;re-point&quot; at that.</li>
<li>npm by default installs packages in ways that are geared towards server side frameworks and resolution of modules for NodeJS.  For example in most cases &quot;npm install module&quot; would put it into &quot;node_modules&quot; of the root directory.  That alone would be confusing to end developers.  There are ways to remap it, but publishing AMD packages I think is somewhat problematic, although IIRC it was James Burke who was stating that he had struggled with it for an extended period of time, which is eventually what gave rise to volo in part.</li>
<li>I am not impressed with the care, maintenance and governance that npm and the associated website is given.  <a href="https://github.com/isaacs/npm-www/issues/119">Issue #116</a> shows a level of personal frustration I have, and I recently have been having significant issues with even getting on to <a href="http://npmjs.org">npmjs.org</a> recently.</li>
<li>Its governance isn&#39;t fully clear in my mind, and seemed to be slightly less &quot;open&quot; than we maybe accustomed to, although I am not really in a position to comment on this, it was only what I could glean.  In particular I couldn&#39;t easily figure out how contributions are made (simply pull requests, maybe to the GitHub repo) and it seems that it is wholly managed by Isaac.  Where as with the other two, we understand their governance models and in particular, I noticed that James has gone out of his way to make it clear.  (As a side note, I think it is becoming increasingly important for us to remind people that just choosing an open source license doesn&#39;t make your software open)</li>
<li>NodeJS (and CommonJS) for whatever reason have &quot;rejected&quot; AMD.  It is likely that there will be further divergence in the future.  My estimation is that npm will, by its nature, do whatever NodeJS does.  If there is further divergence between AMD and NodeJS modules, we will be left out in the cold.  My estimation is this risk is less with volo, because it is obviously committed to support AMD.</li>
</ul></div><div>I honestly don&#39;t know if an extension would be viable or not, but if it were, we would have to say &quot;what you need to do is install npm, then install our extension and then you can finally install Dojo&quot;.  Of course we could derive a single installable, but I don&#39;t necessarily see how that would be different from a fork as likely any upstream changes in npm would have a negative effect on the extension.</div>
<div><br></div><div>But in the end, it is a discussion document.  All I could add to it was my point of view.  If we really feel that npm is a viable option, then I am all for discussing it.  You are right that the penetration will significantly greater, but npm isn&#39;t a JavaScript package manager, it is a NodeJS Package Manager, and I think it will always be.  If we feel my points above aren&#39;t valid (or not material to the decision) then I can further investigate what we would need to do in order to bend npm to our will.  I just didn&#39;t think there was enough juice in the squeeze.</div>
<br><div class="gmail_quote">On 23 September 2012 15:56, Rawld Gill <span dir="ltr">&lt;<a href="mailto:rgill@altoviso.com" target="_blank">rgill@altoviso.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
</div>After your point-by-point comparison, you say nothing more about NPM. Why?<br>
<br>
Can you explain the semantics of the item &quot;How does it deal with AMD?&quot;<br>
<br>
It seems to me that another possible option is to develop an extension (not branch) to NPM that adds the functionality we need. I think NPM is fairly stable and likely used more than all the other javascript package managers combined. These two facts are quite important from a marketing pov.<br>

<span class="HOEnZb"><font color="#888888"><br>
--Rawld<br>
</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote></div>