I was just thinking about this today. But from the point of view of growinga community around a platform!<p>Would you want to have one namespace for &quot;official&quot; modules and heavily influence everyone to use them? That&#x27;s centralization (of governance). But, it&#x27;s not centralization of a process that requires high availability. So the &quot;drawback&quot; is only that you centralize control and can make certain guarantees to developers on your platform.<p>When you&#x27;re starting an ecosystem, you can choose a &quot;main namespace&quot; as yum, npm etc. does or you can choose the more &quot;egalitarian&quot; convention of &quot;Vendor&#x2F;product&quot; as github and Composer do. I think, in the end, the latter leads to a lot more proliferation of crap, and as the articls said, multiple versions of everything existing side-by-side.<p>I have to deal with these issues when designing our company&#x27;s platform (<a href="http:&#x2F;&#x2F;qbix.com&#x2F;platform" rel="nofollow">http:&#x2F;&#x2F;qbix.com&#x2F;platform</a>) and I think that having a central namespace is good. The platform installer etc. will make it super easy to download and install the &quot;official&quot; plugins. You can distribute your own &quot;custom&quot; plugins but the preferred way to contribute to the community would be to check what&#x27;s already there first and respect that. If you REALLY want to make an alternative to something, make it good enough that the community&#x27;s admins protecting the namespace will allow it into the namespace. Otherwise, promote it yourself, or fork the whole platform.