The basic argument is "design a protocol (damn-it)".<p>I agree with this point, I've made it here and I don't think I'm the only one.<p>But everyone knows the Diaspora folks went the "product first, protocol later" route and a fair number of people agree this approach. So it's a disingenuous little to act "oh, they made a basic mistake so it just won't work." They went a route, at least, that lots of people think will work. It's not like they used hard coded eight-bit node identifiers, had each node multi-cast its information or some other design decision would <i>guarantee</i> things couldn't work.
I don't agree that it makes sense to "design a protocol" before building the application. You can try to imagine what you want the protocol to look like at the end of the day, but you are likely to get it wrong if you don't have an application that's actually using it. It's important to keep your eyes open and try to avoid going down blind alleys, but there's not much value in building infrastructure before it's needed.<p>The questions raised in that post are good, and we intend to address them as they become relevant to what we have build. Discovery, namespacing and routing are areas where we are starting to feel tension on in the product, and will probably be tackled quite soon. The point about affecting interface design is good, but we look at it the other way. We want our interface design to drive the protocol design, so we want to make protocol choices as late as is reasonable.<p>Finally, it's fantastic that people are reading and forking the code. The more people out there trying things, the better.
I think Diaspora could do itself a huge favor by writing up a blog post explaining how the $200k was distributed. Everyone keeps harboring on the fact that they have that much money, but everyone forgets that they have quite a bit of liability with what they guaranteed on Kickstarter.<p>I think once that is done, people won't be so fast to suggest to them to hire a $100k/year engineer from Google or other things. Just my $0.02...<p>[edit: spelling]
Maybe the old software engineering maxim "build one and throw it away" is the best way to look at what Diaspora's done so far.<p>Yes, it would be great to have a well-thought-out protocol and secure software. But then again there's also huge value in having an implementation that people can play with. We hear all the time about how important it is to get your best guess at an minimum viable product into users' hands, and that's pretty much what Diaspora has done.
I think a huge requirement for success is that distributed social networking needs to be a framework, not simply an application (as Diaspora is now). Hopefully they're considering refactoring in that direction, and that definitely falls into point #1 (Coding before designing). You don't want to haphazardly code a framework, you need to design it on some level beforehand.<p>The killer feature that moves people over to distributed social networking is not distributed social networking itself. But third party developers building onto a distributed social networking framework is what will allow the next killer feature to be built.
I have really bit my tongue since the beginning of diaspora - I think really they are simply victims of their own success. If they had a normal amount of publicity, or if they had gotten the 10 they asked for instead of 200 I think they'd be much better off. Much hungrier, scrappier. Less expectations to live up to. Way less people looking over their shoulder as they learn to code and manage a project. It's got to be a bitch to learn to dance on live TV as well.<p>I am not saying they are doing a bad job. Just that it's a very hard job to do. Most rock stars of today that built the next big thing had the luxury of not having to show anyone the code. And I'd say 90% of the time, that code is fucked, at least in parts. That's pretty recoverable - your product isn't the code it's the service or executable. Many opensource projects are similar - they can be hacky at first because no one even knows they exist - as they get traction they can fix things as they become issues.<p>But now with the whole internet breathing down their necks, celebrity status and a bunch of money burning a hole in their pockets they have no such luxuries at all.<p>I am inclined to agree though that they should really consider closing back up and rebooting both the design philosophy and the code base after folding a few key contributors into the core team.<p>Not that I'm right or that I know what I'm talking about, but just my opinion.
Incidentally I see Ben Nolan has released his xmpp port of Diaspora today. This goes some way to assuaging my worries about their architecture.<p><a href="https://github.com/bnolan/diaspora-x" rel="nofollow">https://github.com/bnolan/diaspora-x</a>
"My concern is that hype can also bite when you don't have something to ship or there isn't a big value-add over existing solutions."<p>This is critical. Diaspora could spend a lot of time in the architecture tower with nothing to show, and the early hype will bite them if they have nothing to show. I think they've done a good job making sure that doesn't happen.<p>Now that they've shown they can produce <i>something</i>, they need to slow down and make sure they are producing the <i>right thing</i>. When you are building a simple application, you can get away with design-by-coding; if you are trying to build a federated, global, social wonder, you are going to need to spend some time thinking about it.
Just to add to the chorus of voices: yes, Disapora team, please let your protocol spec define your application code, not the other way around. This one factor will make the most difference to the long term success of the project.
FTA: "...build this on XMPP."<p><a href="http://www.reddit.com/r/programming/comments/ehhbz/i_made_a_diaspora_branch_that_uses_xmpp_instead/" rel="nofollow">http://www.reddit.com/r/programming/comments/ehhbz/i_made_a_...</a>
At this point, I don't think diaspora will work. The project has lost its hype, so it has no more fuel. Its heading towards the deadpool. It doesn't even look like it'll live on as an open source project.<p>The main issues with the diaspora project, besides buggy code, was that there was never a good reason to build it. People were not angry enough at Facebook to start learning how to run their own servers (which costs money) or pay diaspora to do it (which costs money)
This is one case where I think the number "Four" in the original title would have been better left in. Without the number, the title made me think this site might be a community bug tracker for Diaspora design mistakes. With the number, it would be clear that this is one person's many ideas.
Is it me or can't Diaspora just make it easier to run your own Seed server, even for playing around. Come on guys, stick in on a EC2 AMI and make it easier for us to play.<p>(Before you retort, yes, I am capable of spending the hour or so build the stack, but it's nice to have plug and play sometimes).
Because Diaspora is open-source, it attracts this sort of "look at how bad the code is" attention. I'm willing to bet that the first prototype of yahoo/google/facebook all had terrible code that may have lasted a long time. However, by not being open source, no one was able to critique them on their software design mistakes and instead had to focus on the product itself.<p>Since it is open source, Diaspora could probably use the writers of these critique pieces (bad design, security holes, etc.) to actually make a better product.<p>(Tangentially, why are there so many blog posts about Diaspora's code? Is the code actually unforkable? Or is it just because Diaspora painted itself into a corner promising a secure social network on a relatively quick timeframe and now everyone wants to prove them wrong?)