Their product is released to end users, because the first thing every early adopter is doing with their shiny new host-you-own federated social network is sending out invites.
Their code is out there, they have openly said it is full of bugs and they now have a hell of a lot of eyes, They will get a massive benefit from this being opened early and it really isnt their problem if people refuse to ignore all their and everyone elses advice and give out their banks password
The question is, do the problems in the code establish beyond doubt that this team is not capable of delivering a final product that will see some level of acceptance? I really hope not.
1: I'm assuming that - I would hope they didn't think this was release-ready material.
Furthermore, one of the primary goals of the project was to make something more privacy-conscious than Facebook, and so far they show they have a development process that pays less attention to access control than any Rails app I'm aware of.
1. Build features, ignoring permissions entirely.
2. When the feature set is relatively stable, default to disallowing everything.
3. Re-enable one feature at a time as you add appropriate permissions checks.
Step 1 looks horribly irresponsible if you don't know 2 is coming. But if you do, it avoids a false sense of security from half-finished permissions in rapidly changing code, and it keeps up early motivation since you're rolling out "exciting" features right away. And counting on step 2 ensures you're always checking whether something is allowed, instead of foolishly checking whether something isn't allowed.
Whether this scenario applies to Diaspora at all ... I don't know. Time and another release will tell. But I do think there are valid situations where authorization is "the kind of thing you add later" for appropriate values of "later".
And may I add, I think it is really great that many public seeds are being deployed, this is the only and best way to test a social federated network, pre-alpha or not.