Sad how those 50+ developers could never quite deliver a stable platform though, yet one guy working in his bedroom somehow managed to do just that.
It is all in the communication and the motivation. There are enormous risks in running a one person project, but if you compare this with a multi person project, the risks still there but are different.
In the one-person project, ensuring some variable does not go out of range (for example) is necessarily one person's responsibility. Ensuring you don't break your self-imposed architecture is only your responsibility. No-one else's. On a multi-person project, you get silly things like interfaces not quite matching, so developer A does not realise it has become his task to range check all the data passed through an interface to B's module. B on the other hand hasn't really thought about it either, and hopes for the best. Along comes a parameter that has an unexpected value and ..... Bang.
Also, if a project has as many as 20 on it, either these need to be grouped into teams of (say) four or five, or the communication overheads weigh the project down. And as for 50 - this looks like 50 people working very part-time.
I know open-source-style projects seem to cope with many, many people making small contributions, seemingly in ad-hoc fashion, but I believe the communication problem is still there, it is just difficult to pick out. Very large open source projects seem to evolve quite slowly. Often they are still essentially held together by a single-minded person who ensures that at least the main line of development keeps working, and he probably has to work as hard as the lone developer.
On the one person project, though the developer seems to have freedom to steer his project where he will, there us a risk that he will give in to every request, try to, or spend his effort arguing why he should or should not. He may eventually 'break' a nice architecture he created in the first place, and which may be his support that keeps the project in good order. This will lead either to poor quality or demotivation. Demotivation leads ultimately to no support. He also has the challenge of testing and review - ideally this needs ''another pair of eyes''.
Dave
