My Journey with the Nmap Project
I am among the thousands of programmers who aspire to be a part of Google’s Summer of Code Program each year. It so happened that I was going through the issue tracker on Github for Nmap one day, when I came to know that Nmap was a part of GSoC in previous years. Being a guy who uses a variety of pentesting tools for fun, I got excited and started becoming familiar with the source. The source was big, but not too hard to decipher, since it was documented pretty well. The next step was, abviously bug-fixing. So, I got my hands dirty, started contributing a few patches and became acquainted with the IRC handle at #Nmap. I still remember the feeling when my first PR was merged and this motivated me to put in more PRs.
I did not know why then, but my PRs were stagnating and didn’t receive much review. I improved upon the requests in the ones that did, but that would be the end of the thread, no merges, no comments, nothing. Just silence. This kept on going for about a month and the Orgs list was announced by Google. The IRC handle was burning with “How do I contribute?”, “How do I get started?” and similar stuff. Due to the lack of activity of the maintainers on the IRC channel, I used to reply to such requests.
I, at this point, became a regular at #Nmap, giving out suggestions to people who faced problems (even if some of them were terribly wrong). I also became acquainted with bonsaiviking aka Daniel Miller, who is the primary maintainer of Nmap on GitHub. With his guidance, I proceeded to purge many more bugs and asked his advice and opinions on various issues reported by other users of Nmap (on StackOverflow, Security StackExchange and so on). Little did I know that I was overworking myself at this point.
Between all this, I also did some bug-reporting with Nmap and testing with Npcap (the Nmap project’s packet sniffer) on Windows. I would frequently put down my thoughts on the issue tracker and it could be quite assumed that the regulars of the Nmap Project knew me.
Back to the PRs, the hard-worker in me doled out even more PRs (and some of them were even merged, surprisingly). By this time, I had to write a proposal since the dates were nearing and I asked Daniel for his advice on the same. I went ahead and applied for the “Feature Creeper and Bug Wrangler” profile because it was a pretty staple project in Nmap’s GSoC history. With over 33 open PRs, 6 merged ones (a few independent), I was quite confident that I would clear GSoC. (How foolish!)
Anyways, I continued to contribute more PRs, though by now, they were restricted to TODOs and FIXMEs since, well, the other ones would take extended discussion and time. By now, the maintainers were pretty much dead on GitHub. By dead, I mean towards the PRs, since they did continue committing to the main trunk and merged a few major PRs.
A few repeated cycles of the same and it was May 1 already with the results due on May 4. By now, I had about 50 PRs in the queue and I safely assumed that I would make it. I knew how nmap worked, where bugs might arise, contributed a few patches and made contact with the maintainers. What could go wrong?
Its results day, and I am not selected. I didn’t know how to react initially, given my reasonable contributions to Nmap, but all I did see was Nmap had 4 slots - 3 for NSE and one for Ncrack and that I wasn’t among them. I tried contacting Daniel via IRC to know the reason, but to no avail. I shot off an email asking why and he replied that he would tell me why. Later.
On one hand, I wondered how on Earth I wasn’t selected when it struck me that there were two possibilities:
- One, my proposal was bad, which might be a good proposition BUT I received no comments whatsoever on my proposal and Daniel (the admin) himself said it was fine.
- I hadn’t done enough, which couldn’t be the case. Be it merges/issues/involvement, I had done enough.
So where is the problem?
To be clear, I’m not against the Nmap project or its maintainers. Daniel Miller has been extremely helpful in teaching me a lot of things about how Nmap works and same goes with the entire IRC team. I have a few suggestions and questions for any open source organization that is/aims to be a part of GSoC in the future:-
- Please do be active on GitHub. I do understand that maintainers are very busy. But a small amount of time could be devoted towards addressing the Pull Requests and Issues on GitHub. For a lot of OSS developers (including me), GitHub is the point of entry to OSS and it would be really nice if you guys could be active (maybe twice/thrice a week?).
- Have a clear set of rules for contributing. Every time when I fixed a TODO/FIXME, the one question that popped was “Do I really need to put in a PR? Or would messaging a maintainer be fine?” The last one wasn’t possible in my case (since Daniel was busy), so I went ahead with the first.
- Have difficulty tags for issues. This would help a lot of newcomers come within the fold of the org and potentially expand it.
- Prioritise Issues on the tracker. This would’ve helped me a LOT since I would’ve picked a different project (maybe even org) altogether for GSoC.
While I’m not a professional, as a developer (and a noob of sorts), I feel that these changes would be better for the entire community in general.
The reasons why I’m writing this is not only because I didn’t get GSoC,(I was planning to anyway) but because the result (in my opinion) would’ve been way different had I known certain things before applying.
Big Shoutout to the entire Nmap community for helping me out over the past six months with their advice.
For beginners, my advice would be to pick up an org that responds to you frequently, so that you know where you’re heading and don’t face the same kind of uncertainty that I did.
My GitHub profile: https://github.com/Varunram
My rejected GSoC proposal: https://docs.google.com/document/d/1IGx8qMZPna1h-hlwKsOfuhuZQePGV4KfSS3xGNcPM_A/edit?usp=sharing