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.
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.
Actually, no. Virtually all successful frameworks (Rails, Django, Tornado, MapReduce, etc.) grow out of an application or set of applications where common pieces are incrementally refactored out of the application and into the framework. When you start with the framework and design it upfront, you end up with an overdesigned mess.
Actually, I agree. My framework was built out of Appleseed the application, and was then re-factored into a framework, and most of the structure was based on what I had learned from building the app.
I don't think anyone should start by building a framework without any conception of what that framework is meant to do. But Diaspora already has an app of sorts, so they wouldn't exactly be doing that.
I share your frustrations about the quality of legacy Java web frameworks (though that Play one looks interesting, or would be if I had any interest in ever writing Java again). That said, I voted you down rather than voting you up to express my preference for HN having a high signal-to-smug ratio.
I voted you an aggregate of zero - +1 because I agree with you, -1 because I dislike people explaining their voting.
:)
I'm just teasing, no offense intended. I actually do agree with you and upvoted you - your comment just really reminded me of this quote from Steve Yegge (supposedly found on Reddit): "I upvoted you for the appropriate uses of 'its' and 'their' in the link title, but downvoted you because your link actually appeared on a little-known German social networking site several hours ago. I feel it is important that you understand that this is not a zero-vote of abstention, but rather a single upvote and a single downvote cancelling one another out."
A concretely realized framework isn't all that much more abstract than an application. Creating a framework doesn't mean you've created a well-defined interface, much less a well-defined protocol.
Moreover, a protocol is pretty much the only thing that has meaning over-a-wire. After all, you don't know what object you're talking to on the other side of a network connection so either you each have a well-defined protocol you're using or you don't.
I think the huge requirement for success is that is grows at grass roots level with completely non-technical people because of non-software reasons. I don't think you can compete with something like FB if your scope is "we need to develop better software" unless you have a whole other aspect of creative and analysis skills that this kind of development drive do not posses or engage.
I would say that both are important. The underlying architecture needs to be very flexible, and the user-facing interface must be familiar and intuitive to the lcd.
I'm struggling to think of examples where an open application has defined both a successful architecture/protocol and also provided a widely adopted user-interface.
For example, not many people used Tim Berner-Lee's original web browser but it did help define the standards that then went on to be picked up by Mosaic which was the first really popular web browser. However, by the point that Mosaic came out most of the features of the architecture of the web were in place and remain recognizable to this day.
Surely the goal is to provide common lower levels of a "social" protocol stack and allow as many and different user interface applications to layer on that common core?
Surely the goal is to provide common lower levels of a "social" protocol stack and allow as many and different user interface applications to layer on that common core?
That's one of the goals, but it's not the only goal. I think what you're bringing up is what makes social networking somewhat new terrain for open source. So far, open source has been able to dominate the server space because of superior tech implementations for an insanely low price point.
For social applications, that doesn't matter as much when you're trying to draw users. You need a usable UI, you need to learn all the lessons that the proprietary systems have learned over the years. It's not good enough to just have a better technology, you have to present it as well or better than the competition.
I think it's a new trajectory, because there's less incentive for walled gardens to open up than there was for Netscape to use http. So I think this is a necessary trail for open source to blaze through.
So in a lot of ways, there's very much a chicken-or-the-egg dilemma: Usable protocol stack that others can build on, or sizable enough user base that developers want to build on it. And the closest I've seen to open source dealing with these questions was actually, the gnu/linux desktop projects.
I think Mosaic actually used the CERN libwww library and I'm pretty sure that the CERN HTTP server was the standard at the time Mosaic was first released.
It would be interesting if there was an equivalent for social applications... a common server component, an application library and maybe a reference application but with plenty of scope for people to innovate in the UI without the need to continually reinvent the core communication components if they don't want to.
I think the problem is a bit higher level then that. This project feels like it lacks the necessary experienced leadership. What they are doing is Not Easy and this is being borne out by their product. Building apps isn't too hard, designing systems is.
Perhaps it was overly general and poorly worded, but I think the underlying point is clear and valid: building an open source distributed system intended to be used globally by diverse individuals and organizations is several orders of magnitude harder than building an app that lives within the doors of a single organization.
I want something that is also a platform. Maybe that's what you meant, but I want a decentralized alternative to Facebook Connect. I want to clone Google Apps and beat them at "+1" with an open data platform that anyone can build an app on top of. But then again, I have my own grand plans in my head. And on paper. And scrawled on a desk.
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.