Marketing your node module - darker patterns

I am capturing here a few ideas that I've had recently in the same topic as in the last post .

I realize that the ideas become more and more extreme/desperate/dark still I felt that there is nothing wrong in capturing them.

At the high level the idea here is that you want to increase the "page rank" of your module.

Soon that pagerank will be a combination of

- the recent/all time downloads # as published by npm

- the page rank of the author (some aggregate of the pagerank of all the modules authored by the person)

- the github stars/forks accumulated by that module's repo

- the aggregate follows/starrs etc accumulated by that repo's owner

As a result improving the page rank of the module implies that you will somehow get these # s up - which is not obvious when nobody yet knows your module.

So here are a few things that you can do to speed up the process

Increasing Download counts

- Make sure that *you* use the new modules. You or your friends may have some modules that have daily downloads. You should see if it is possibly to refactor any of your existing modules (particular ones with high download counts) to make use of your module. If you achieve that any download of the former will result in downloads of the later!. This also means that as soon as you have one success you can easily build up on it... 

- Look at all the competing/alternative modules - find which modules/apps are using it. If you can make a case that your module can do a better job at it... than go ahead file an issue pull request doing the change (replacing one module with the other) and explaining that by doing so you are improving the functionality etc etc. The odds are that,  assuming your module is actually better,  the user of the alternative doesn't care whose module to use - he just cares to improve his own functionality and doing so with minimal personal effort.  Again here you should focus on cases where the target module has significant traffic

- Your employer may be a great resource. Most employers don't publish their code. However, they have teams of developers continuously commiting => firing continuous integration systems which do continously pull dependencies and rebuild stuff. Ie even private reposititories contribute to "download counts" and you definitely know at least one big such example - the repos of your employer. Finding how/where your opensource module can be used in your employer's repo is a very easy way to build up download count.

Increasing your module stars.

- Get people with lots of followers to star your module. The idea here is that if someone with lots of followers stars your repo... that goes into the newsfeed of all their followers . I typically find out about interesting new modules this way by looking what other people star...  Of course then the next question is and how do you get these guys to notice you?  The answer: the hard way. You need to closely keep an eye on their interests - where they put their time/commits - and knowing that may give you an idea about how you can help them . It might take more than one indirection - you see something that they do - you write some code/a PR for them - so as they know you / build up some credit - so when the time that they use something that you have a better version of... you are ready to offer your alternative - and if you persuade them to use your in your current project - they might be ok if you PR to replace the module in all prior modules they might have written depending on it.

- if you manage with all the above efforts to get someone to visit your module - your primary goals is not to star it - but to extend his page-count visit. Essentially think that you just bought an expensively aquired visitor and you want to get most of them. They came following a link towards a specific module but they actually may look around. You need to be prepared for that:

  + Your public repo should have only your jewels - it should not have every single repo you have ever written. This is very important - both because if you get followers you want them to checkout whatever you are creating and because a user with lots of crappy repos is just like a blogger with lots of crappy blog posts - nobody has the patience to go through the crap to find the jewel. So what you need to do is create a separate github account and move there anything thats is not yet publish-grade. This will also help you with the problem that the very first github push of a repo - will invite your followers to visit it - they should better see it in its full glory with the polished readme etc...

  + Your readme should have something provocative/novel in how it presents itself - "badges" (like travis)  that others don't use - interesting clip art, an animated gif that shows a terminal running the module etc

  + Your readme should point if possible to other modules of yours.

  + You should make sure that you have your links to your blog/homepage etc in your github account... again making sure that you appear as a guy that talks rarely but is worthwhile listen to when he does.  Exactly the opposite of me in this blog.....
  + Add a gitcomment thingy (what is a gitcomment will be captured in a future post) at the bottom of your project's readme - seeded with some comments from your friends.

Marketing your node module

Continuing the thoughts in the last post  I am finding a bitmore about the steps that you need to do to market your blog

I just tried to find a module that provide google spreadsheet editing capability..
When I type google spreadsheet in the npm search
npm find one module google-spreadsheet (right in the first rows) but the probably better module (comparable downloads, comparable github stars, include the exact string "google spreadsheet" in the description, include google and spreadsheet in the keywords) named google-spreadsheets is in the 3rd page after several completely unrelated to "spreadsheet" matches (somehow it seems that npm shows in the search even modules that don't match all my keywords.
Now this says something about the poor state of affairs in the node module search-land.
Looking at stackoverflow in case I am the last person that is not using someting cooler and better to find node modules... I found this post . which lead me to two more useful places (and a couple more broken links). A github wiki page that includes lots of modules - https://github.com/joyent/node/wiki/modules,
(unfortunately I didn't find any of the "google spreadsheet" modules I was looking for there which shows that while long this list can have significant gaps...) plus sth that went pretty close to what I was looking - nipster - a search tool that combines the github stars and a bit better (still lousy if you read the open issue) search.

Anyway, after logging in my todo "NIDEA - better npm module search" I concluded that until then one should definitely include in the "marketing steps" the following
 - add module in joyent module list page
 - make searches in npm to see if your module shows up - if not tinker with description, keywords etc until it does
 - look for your competition - other modules that show up on search - include in the description something that would make your module more attractive than them - its the only line that shows from your module in the search listing
 - look for what keywords your "competitor" modules are using - add them too - npm doesn't use any advanced matching that would decrease the weight of the keywords if there are many - so the more the merier.
 - confirm that your module shows up correctly in nipster search
 - pleade your gh friends to star it
 - make sure that you push in github with travis-ci any module/app that is using your module - for a while you will be the only user of your module and travis npm installs do count against the download counts that npm shows - which are the only signs of life when someone searches for your module.

Writing reusable modules vs deployable services

We were discussing this with gl and we realized that the differences (like in the past.. ) between writing code that becomes an open source node module vs writing code that is part of a deployable (web service/web app or even executable) are even fewer.

In reality it seems to me that you always need to think that you "deploy" your code
 0. npm version major to 1.0 from 0.xx
 1. fix up the readme
 2. add keywords to package.json to allow searches to find you
 3. possibly add command line executables, man page in your npm
 4. possibly add a drawing the way substack does
 5. post the link/readme of the module to your blog/twiter
 6. go through the places that you search to find a module (and when you didn'y you ended up builting it) and let them know you did (github issue comments, stack overflows, node mailing list
 7. (there are probably sites that are have some "new/cool modules… where it may be worth to submit your module to…)
--
Of course when you are substack.. all you need to do is add the module as public repo and your followers all find it… but even then he still does the 1..5.

It is also interesting that you rarely have a module that doesn't have a natural deploy:
 - gl created a random-password service. Its a deployable but ideally he should have captured the logic into a module - excluding the mouse-generating-randomness - the module's function would probably have a optional "randomness" paramterer.
 - I created a slugify-url module... given that its use is to create mnemonic filenames out of urls... it makes sense as npm -g installed executable with a man page etc.