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.
So they should develop the whole thing behind closed doors because some people are going to have to suffer the embarassment of having someone post "hahaha disregard that ... " on their mini facebook wall?
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
Basic authorization for resource access isn't the kind of thing you add later. This isn't just an issue of bugs or being in development, it's a fundamental issue with their development process.
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.
For brand new/"experimental" projects with both user permissions and a non-trivial set of features, built by a small team, I've always found it easiest to work like this:
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".
Part of me wants to say 'Cut them some slack, they just put their work-in-progress code on Github like they promised!'[1], but I understand that most of the criticism stems from caring enough about the project to want it to succeed. At this point, they should be thankful for the attention and the guidance more experienced people are providing for free.
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.
Invites are not implemented. They have already changed websockets many times since the release. If you have an install you're probably busy merging changes and reconfiguring your web server, flushing the database and debugging it and all people capable of maintaining such an unstable environment realize that it's for testing only, I have yet to meet anyone who's using it to store personal/production data. Stop freaking people out, only devs are playing with it, and if some people are not, this is open source, there's nothing we can do about it.
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.
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