Poverty (and abuse) of the commons

I really like Go’s full specification of dependencies (e.g., import ("github.com/golang-crypto/ssh")), but I fear linkrot, backward incompatibility, and visibility. Also, hard-coding access protocols to handle github.com, bitbucket.org, and code.google.com may be practical, but that doesn’t feel like the right solution.

A central repository can offer archives, consistency, reliability, searchability, and popularity rankings. I prefer npm to Go’s distributed “package manager”, because I can search npm directly, and it’s not too hard to extend on the existing search functionality to sort by downloads or github stars. Finding a suitable Golang package generally means fumbling around on Google for a bit, which takes longer than a simple npm search $1, or a GitHub search, which is generally a sucky user experience unless you’re looking for a particular line of code.

The problem with central repositories is curation (or moderation, depending on your perspective). Some repositories are relatively closed, like CRAN (for R), Maven, and Homebrew. Presumably anybody can submit a package, but it’s not automatic—somebody has to check and sign off on your request. There are a lot of policies and restrictions; CRAN has 26 bullet points to follow on its “Repository Policy” page. Others, like PyPI and npm, are totally open; you make an account, find an unused name, press publish, and it’s up and publicly available. npm is about 100x less painful than PyPI, but they have the same hands-off philosophy.

I think npm is the right solution. But it’s not flawless. My primary issue with its philosophy is name squatting. This is like domain name squatting, but it’s permanent (so far), and more rampant because it’s free. For example:

  • https://www.npmjs.org/package/click. Six lines of code (to do something that usually takes one). This is kind of an awful name for any open source project, but I can come up with better projects for the name. The owner, uggedal, isn’t just some node.js newbie, though – so I’m guessing he’s squatting the name to make some point about central repositories.
  • https://www.npmjs.org/package/mturk. Well-meaning, a good start, and it’s the obvious name for the job. But the owner has basically abandoned it, which I don’t blame him for, but he hasn’t signed it over to anyone else, despite several people volunteering, which I do blame him for.

I don’t want to charge money for the right to claim a name, but I think there should be some expiration period. I.e., if basically nobody uses your package, and you haven’t updated it in a year, especially if it’s at version 0.0.0 (for example), it should be archivable and up for takeover.

  1. If no one wants it, nothing changes.
  2. But it can be reclaimed by a new owner. At this point the major version is incremented; all the old archives remain in place, but the new owner now controls the full package.json specification and other npmjs.org settings.

Probably some of my own npm packages would qualify for takeover by these criteria, which makes me somewhat uncomfortable. Maybe there should be some voting process for takeovers, but otherwise the ecosystem is going to stagnate in some areas eventually.

Also, @izs, if you’re reading this, you could be a little more transparent about the download counts than just the API calls at https://api.npmjs.org/downloads/*. Having the API is great, but having the database too would be even better.