No matter how many programmers this attracts or momentum the project has, if the underlying software design is bad, people need to either do a rewrite with a better design, or make a patchwork mess of it all until it becomes unmanageable, in which case you do the rewrite you should have done in the first place.
The problem is, there's a lot of eyeballs that are looking at the code right now, and that does help to identify bugs, but if the bugs we're seeing are deep seated architectural issues, then it's not very easy for someone to just go in and fix them. Then Diaspora has to determine if the fixes are worth including, and whether they fit into their system design (assuming they have one). Basically, in order to actually utilize the community interest in any practical way, they need to be solid managers. At 20 years old, with no real world software development experience.
This is something open source doesn't seem to understand, and why even the biggest projects end up being a small-ish team of dedicated professionals, instead of the "bazaar" we imagine.
I totally agree with this comment. I don't know whether Diaspora is architecturally secure or not. I strongly suspect that it isn't, but am unqualified (and insufficiently interested) to constructively prove that.
The things I found were mostly tactical insecurities, springing from a combination of Rails Security 101 errors and "web application programming is hard." They're pervasive tactical insecurities. Maybe they'll all get fixed if a lot of people pick over every line of that codebase for the remaining one month before release. But that won't help address the part of the iceberg below the waterline. (I can't see it, but the amount of ice above the waterline strongly suggests it is there.)
I haven't read the code or the design, but I'll say:
* To the extent that Diaspora's security depends on Rails, their problem is tenable; Rails (when properly configured, which this project isn't) does a really nice job of making CRUD secure.
* To the extent that Diaspora's security depends on cryptography, we needn't worry about the security of their current design at all, because they have no current design; what they have instead is a "hello world" of cryptography; someone professional (or in academia) will need to design something for them, and then write a paper on it.
I'm worried about their federation strategy: even assuming users A@provider1 and B@provider2 don't have their communications compromised, I have a feeling that Here There Be Dragons around this area, in every fashion I can imagine and many that I can't. At the moment, though, their crypto is academic in that it is like a bank vault door securing a vault where one wall is actually open air and passerby on the street could walk in and take the money. It may or may not be a good door, I don't know, but it is not a good vault.
The Rails bits, yeah, those should be solvable if anyone wants to solve them. I really like Rails for a lot of reasons, and my experience has been that I do less damage with it than I used to do with Java.