[daleharvey]

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

[carbon8]

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.

[nickbw]

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".

[shajith]

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.