Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I would like to start new Open Source project, and I believe all check-ins should be reviewed before merged into trunk.

What are some great online code review tools for Open Source projects that have this functionality, and what makes them great?

share|improve this question

marked as duplicate by gnat, MichaelT, Kilian Foth, BЈовић, GlenH7 Apr 29 '13 at 2:26

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Have you looked at Code Collaborator from smartbear.com? It is free for OSS –  trondd Oct 14 '10 at 19:32
Could I suggest that a question with "best" in is probably a poor one - what you're asking for is recommendations for good code review tools however when it comes to tools best can vary significantly by individual circumstances (what's best for me and my use cases isn't necessarily best for you and your use cases - in fact may not work at all). Replace "what is best" with "recommend good" and ask for pros and cons and you'll get the same answers. –  Murph Oct 15 '10 at 7:25
I saw a presentation of Bamboo once, and it blew me away. Although it's a commercial product, it's free for open source software projects, just like most other Atlassian products (I do not work for them, but I do think they make some very nice products. :)) –  Vetle Oct 15 '10 at 7:55

3 Answers 3

  • code.google.com
    • Used this during undergraduate for projects, it was free and provided all the tools needed for a team environment without having to manage a server. (Perfect for undergraduate projects, back before github existed.)
    • Offers svn or mercurial repositories although we used solely SVN for our projects.
  • github
    • Great because its based on git which I have more and more taken a liking too!
    • Also provides some bit of a "social networking" aspect that I enjoy.
share|improve this answer
+1, though toss a bit of explanation in there. Why are those good choices. –  Josh K Oct 14 '10 at 19:18
+1 for github - you can use pull requests directly on github to accomplish what you want. –  dr Hannibal Lecter Oct 14 '10 at 21:17
These would be better as 2 separate answers so we could vote / comment on them in a more targetted manner. –  rjmunro Jan 6 '11 at 23:04
Comment at will. The question asked for tools so tools I gave. I am happy to break into two answers. –  Chris Jan 6 '11 at 23:15


I've tried a number of them and Code Collaborator is an excellent stand alone code review tool. It imports well from many source control systems, but didn't integrate seamlessly with my bug/feature tracking system. They have a new version out since I used it, so perhaps that has been improved. Code Collaborator has a beautiful comment / issue / suggestion tracking system.

Fogbugz is a great lightweight feature/bug/customer tracking system for software development. It also now integrates really well with Kiln, a Mercurial-based source control and they've recently added a pretty cool code review tool.

What I like best about the Kiln/Fogbugz code review process is that it works post-checkin and it enables the submitter to request a code review from a peer and automatically create a work item assigned to their peer to track the code review. This is imho an excellent combination of all the code review best practices rolled into one.

With Code Collaborator, I struggled with the 'assign a review to' logic and because it works against diffs/changesets rather than checked in code it tended to impede lines of code written with a bit too much process. You want to ensure your code review process is a 'teaching tool' rather than a 'quality gate' otherwise the 'gate' slows things down and you start to lose acceptance from your devs.

share|improve this answer
Not sure what you mean by that last sentence. A quality gate is exactly what code review is: by having more than one person look at the code, you reduce the chances of something bad ending up in production. The time for teaching is before and during the coding process, not after the code's been written. –  Mason Wheeler Oct 15 '10 at 0:03
Devs shouldn't be continuously repeating the same mistakes over and over. After a few weeks of rigorous code review, expectations should be clear and quality code the norm. If every checkin is still gated on one or more 'approved by' reviews, the developers will see it as a management impediment to success, not a useful learning tool. At this point, CR becomes a tool for higher level learning, pointing out better algorithms, simpler designs, refactored interfaces. These are longer discussions that tend to inform the next milestone rather than the immediate checkin. –  Jay Beavers Oct 15 '10 at 2:45
The Fogcreek tool with code review is Kiln - which is built on/with/alongside Mercurial. Fogbugz is the bug/feature tracking software (and is excellent). Neither, so far as I'm aware, are free. –  Murph Oct 15 '10 at 7:29
I'm also quite fond of Kiln. It is a really, really useful tool and Fog Creek has subsequently done a lot for Mercurial. –  Tim Post Oct 15 '10 at 10:05
Fogbugz and Kiln are free in the 'Student and Startup Edition' for up to two users. Good point though that a larger OSS project would need more than two developers, it slipped my mind since I'm on the free version. –  Jay Beavers Oct 15 '10 at 20:02

You could always just set up a good old mailing list and email patches for code review that way. Some people say patch emails are a sign of bad practice in version control, but I disagree since ideally all the developers read the mailing list. If they see a patch while just downloading email they are likely to click on it and maybe write a reply.

I think most version control systems make this easy, like with git-sendemail for example.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.