Check out the mythical man month:
Basically it talks about how 200 developers is quite possibly going to make it SLOWER than 100 developers rather than the "twice as fast" you might guess! (well, in the specific example of one which is running late but I think it can be generally have some other applications too here)
So, you're going to find there is a fair amount of duplication between the two (or more) developers. There is overhead too, making sure they don't step on each others toes etc. But good policy/practice such as using github and a wiki can partially reduce these negative side effects.
I'm sure you're aware of the saying "too many cooks spoil the broth", remember that.
My answer might not be too satisfactory as really "it depends". On the people, how you're doing it, and what the project is (some can easily be broken into little pieces to be shared about, others can not be. Oh, and of course the breaking it up and sharing it about is yet another overhead...).
Anyway, on the flip side now I've mentioned a few of the negatives I'll now mention a positive:
Several people are sure to have a greater range of a talents than one person will have (for instance if game programming, one guy might be good at AI/Graphics/Sound while the other is good at Physics/Graphics/Networking. Together they're much better than they are apart). Also, even IF they have exactly the same range of talents there is benefits to have a fresh pair of eyes they can call upon if they get stuck.
In conclusion, where N is the number of (part time) developers then for small N it is likely to scale well (greater than linearly) but for large N it will scale less well (a lot less than linearly!).
I leave it as an exercise for the reader to calculate the optimal value of N! ;-)