"Four software design mistakes that Diaspora needs to fix. Fast."

[j...@qworky.net]

From buddycloud.

1. Coding before designing (Diaspora should: separate code from
protocol )
2. Trying to reinvent Facebook (Diaspora should: innovate on different
features, not play catch-up)
3. Building a new social graph (Diaspora should: Hook into existing
groups of friends)
4. Building a product (Diaspora should: design a protocol, build a
tools and foster an ecosystem that enables others to integrate)

More at http://buddycloud.com/cms/node/204

Hacker News discussion at http://news.ycombinator.com/item?id=1979188

[Sarah Mei]

Opinions mine, not necessarily those of anyone official.

> 1. Coding before designing (Diaspora should: separate code from
> protocol )

IMO, the biggest mistake other distributed social networks have made
is designing before coding. Social software is...social. You can't
divorce the protocol from actual usage, so you need to *have* actual
usage before you know what the protocol should be. And in order to get
usage, you need working software.

> 2. Trying to reinvent Facebook (Diaspora should: innovate on different
> features, not play catch-up)

This is not a software development issue.

> 3. Building a new social graph (Diaspora should: Hook into existing
> groups of friends)

I kind of agree with this. But there's time. It's important to have a
working basic system before expanding.

> 4. Building a product (Diaspora should: design a protocol, build a
> tools and foster an ecosystem that enables others to integrate)

Totally missing the point. Designing tools and an ecosystem cannot
come before actual product usage, because until you have usage, you
don't know what tools will be useful. And you can't sustain an
ecosystem without ... having an ecosystem. And you get an ecosystem by
having people actually USE your software.

[Spiral Syzygy]

Diaspora-x has been forked and is based on the xmpp protocol, which
has a very large user-base and many apps already that prove the
protocol works. Jabber already supports decentralization and
cross-node communication, service discovery, status, and support for
publish/subscribe systems. Aspects in diaspora can organize jabber
rosters and service discovery can reveal what nodes I publish to so
you can subscribe to these nodes. Nodes can be blogs, galleries,
facebook style micro-blog topics, etc.

I value diaspora and the efforts put forward by the team and community
and especially the hype that has brought attention to distributed
social-networks in general. Let's not reinvent the wheel and make
anyone who wants to collaborate have to wait for a protocol to evolve
from this project. I fear continuing to do so will only further
fragment the project and render one of the best features of
distributed social-networks, federation, ineffective.

Spiral

[Spiral Syzygy]

Here is the github link for diaspora-x

https://github.com/bnolan/diaspora-x

Spiral

[Joseph Method]

Why not properly fork diaspora on Github? You're going to want to be able to pull from Diaspora, and your early commits are actually improvements that don't relate to XMPP. Git is great for exploring ideas like Diaspora on XMPP.

--
-J. Method

[jdeisenberg]

On Dec 7, 9:27 am, Sarah Mei <sarah...@gmail.com> wrote:
> Opinions mine, not necessarily those of anyone official.
>
> > 1. Coding before designing (Diaspora should: separate code from
> > protocol )
>
> IMO, the biggest mistake other distributed social networks have made
> is designing before coding. Social software is...social. You can't
> divorce the protocol from actual usage, so you need to *have* actual
> usage before you know what the protocol should be. And in order to get
> usage, you need working software.
>

Opinions mine also. I have to disagree on this one. Imagine if Tim
Berners-Lee had written his first HTML pages and web server, and only
after a lot of people had used it had brought forth the document for
HTTP and HTML. This would have slowed adoption, if not blocked it
entirely. If I understand it correctly, HTML, web server, and HTTP
were designed concurrently, and all were publicly released. All of
this, of course, with the understanding that all three would evolve.

Now, of course, there are many well-established and well-documented
protocols to choose from.

> > 2. Trying to reinvent Facebook (Diaspora should: innovate on different
> > features, not play catch-up)
>
> This is not a software development issue.

Agreed.

[Michael Sofaer]

Your theory is that forking to use a protocol that's incompatible with
Diaspora's current protocol will help reduce protocol fragmentation?

On Dec 7, 5:40 pm, Spiral Syzygy <spiralena...@gmail.com> wrote:
> Diaspora-x has been forked and is based on the xmpp protocol, which
> has a very large user-base and many apps already that prove the

> protocol works. ...

[Spiral Syzygy]

It's not so much a theory as an opinion. My thoughts are that XMPP has
had an extremely large deployment and has been very successful. The
enhancements are pretty well documented, most popular languages
already have decent libraries for interfacing to it. If I wanted to
make an app that talked to other XMPP apps, I can do that NOW. I can
also know that my app can also work with Apache Wave, Gtalk, Jabber,
and quite a large number of other XMPP sites.

To create a new one from scratch makes you less of a team player. Do
we want Diaspora to talk to other diaspora seeds/pod only or do we
want to be able to speak to other apps?

Forgive me for saying so, but it seems most of the resistance to this
idea comes down to:

A) It's too much trouble to learn how XMPP works
B)We're already creating our own protocol from scratch.

My answers to that:

A) That depends on what you consider "too much trouble". I rather
enjoy learning about protocols from reading a clearly written, mature
spec. It can't be too difficult if Diaspora-X already exists. Some one
is doing it already.

B)There are already several other communities working on projects that
use XMPP. Not only can they help with this, they can be part of the
same federation of social networks as Diaspora. Connect with
communities to create new communities and community tools.
The XMPP community has large players, like Google and Twitter behind
it. Even if Diaspora's protocol is "better", it is going to take at
least months of iterations just to catch up to anything that is as
well tested and spec'd as XMPP. Then you have to convince others to
use this protocol as well. All of this paints Diaspora into an
interoperability corner.

So a fork exists. I would love to see the two duke it out and may the
best implementation win. Diaspora-X may take a lead if people can
start making additional apps that can work with it sooner than the
main branch.

[Michael Sofaer]

I worry that potential fragmentation of the social network that is
just starting to exist represents a serious risk to the Diaspora
community right now. Rightly or wrongly, the recent media attention
on Diaspora has provided something of a solution to a coordination
problem about which distributed protocol to use, and that's a valuable
thing for the community as a whole. Incompatible forks can become a
force that reintroduces the coordination problem, and that would be
too bad.

I don't think there's any deep opposition to using XMPP on the core
team. It just hasn't been necessary for any of the features that
Diaspora currently has, and might slow down development if it was
implemented without a very clean dispatch interface to separate it
from the data model. I'm looking forward to seeing a pull request
based on the diaspora-x fork XMPP work. It's a little awkward that
it's not a github fork, but there's no reason to think that's a
deliberate attempt to fork the community.

[Hugo M]

"1. Coding before designing (Diaspora should: separate code from
protocol )"

I agree with that. And I think that, for now, we don't need some super-social network with extensions and other things incredible cool (for programmers) that will never be finished. I think the first step should be make a new simple-and-nice distributed social network that really works and a user can view without running away, I mean, should have a nice design.

2010/12/7 Michael Sofaer <goo...@mike.sofaer.net>

[Andrew Rondeau]

You might want to look at the Federated Social Networking list. There
are quite a few projects; Diaspora just happened to be good at
grabbing the spotlight. ;)

[Paolo G. Giarrusso]

Hi,

in short, my opinion is that this project is different from all the
others because the guys gave it a try and built something, and in Open
Source, it works much better than writing design documents, and that's
why other projects are behind. The analogue of this style in non-OS
development is simply agile development.

In the taxonomy of this interesting link, the others made mistake no.
5 (The "We'll Ship It When It's Ready" syndrome), while Diaspora might
risk mistake no. 2 (the Overhype syndrome):
http://www.joelonsoftware.com/articles/fog0000000017.html

About "We'll Ship It When It's Ready", it's also very interesting to
Google for "worse is better" (no quotes needed) - I explain the
relation in more detail below.

On Dec 7, 9:00 pm, jdeisenberg <jdavid.eisenb...@gmail.com> wrote:
> On Dec 7, 9:27 am, Sarah Mei <sarah...@gmail.com> wrote:
>
> > Opinions mine, not necessarily those of anyone official.
>
> > > 1. Coding before designing (Diaspora should: separate code from
> > > protocol )
>
> > IMO, the biggest mistake other distributed social networks have made
> > is designing before coding. Social software is...social. You can't
> > divorce the protocol from actual usage, so you need to *have* actual
> > usage before you know what the protocol should be. And in order to get
> > usage, you need working software.
>
> Opinions mine also. I have to disagree on this one. Imagine if Tim
> Berners-Lee had written his first HTML pages and web server, and only
> after a lot of people had used it had brought forth the document for
> HTTP and HTML. This would have slowed adoption, if not blocked it
> entirely. If I understand it correctly, HTML, web server, and HTTP
> were designed concurrently, and all were publicly released. All of
> this, of course, with the understanding that all three would evolve.

from my understanding of what you wrote, it seems that you didn't get
what Sarah meant, because "no HTTP" is not comparable to the
Diaspora's situation, nor to what she was talking about [1]. I'll
admit that if you ignore the context, i.e. that Diaspora _has_ a
protocol [2], then you could misunderstand what she wrote.

So, you are writing that Diaspora needs to have a protocol at all -
which it seems to have. I guess you mean that it should be good. The
original article argues that Diaspora is too underdesigned.

But this point, unlike Sarah Mei's one, does not seem informed of the
whole debate in software engineering about the risk of overdesigning.
IMHO, there's nothing really different about social networking, it
might just be an even less predictable field, but you can almost never
get correct requirements upfront.

Have you ever heard of agile vs waterfall development models? Why open
source works well because it is agile (point made by Eric S. Raymond)?
"Worse is better" (Google for it)? I don't explain them here, because
tons of stuff has been written discussing them to death, and you
surely must know at least one of them. However, since the discussed
point is _identical_ to all of them, any discussion on this should be
informed by at least one of them, rather than reinvent the wheel.

Particularly interesting, among these debates, could be "worse is
better": the original essay explains how C won over a much better
language, Lisp, and why Diaspora _might win_ over projects doing a
much better design. Note that the author itself has been changing his
mind many times over the years, and writing sequels to that essay.

Finally, even after reading the blog post, I still think that as long
as the project can break backwards compatibility, everything can get
fixed. If federation is so hard, then supporting XMPP will maybe force
the project to adopt a matching architecture and solve it (not sure).
And maybe they'll have to perform heavy surgery on the codebase to
allow for that, but Linux kernel developers do that all the time. Of
course, they are much more experienced.

[1] An appropriate comparison would have been with an HTTP 0.1,
supporting just GET and other basic features, and not having methods
like PUT and DELETE? My understanding is that they make no sense in
HTTP because there's not an advanced enough authentication - they are
maybe used by WebDAV, but there's no point in having them in HTTP.

[2] All I've read in the past 3 hours, especially the rest of this
discussion, suggests so, but I might be wrong.

[urbanarpad]

There is a bigger picture here. I'm not sure Diaspora sees it and I'm
not sure I see it but it certainly is not limited to "coding before
design." IMHO, the biggest thing required of a new social network
standard is not, strangely, "a standard" so much as a compelling
argument. Why does your mother want to use Diaspora? Because there's
that cool tool/app/feature thing that she likes; not because she
thinks federation is worked out well. Remember, domain name
resolution used to consist of copying host files around the Internet.
BLAH. Yet the Internet survived and changed how that worked - a
somewhat foundational technical detail.

That said, the protocol, the design, should not fail. Build momentum,
build followers but just make sure you don't fubar it so badly that
people get turned off. Myspace case in point. For me, the user
experience killed Myspace not Rupert Murdoch. It was poorly thought
out and it didn't change. In FOSS, things CAN change... look at Alsa,
OSS and PulseAudio on Linux (not the most shining example but still).

(2)(3) and (4) are somewhat related. As soon as Diaspora is on its
feet, there needs to be ample way for others to integrate with it and
build on top of it - ala modules like Pidgin or Drupal or even
Apache. Love it, nurture it and then set it free by giving people the
tools to extend it.

Back to point 1, Federation needs to exist because you can't extend
what you haven't built. If it can't be worked out without an external
technology (XMPP) then maybe the best thing is to plug XMPP in. The
iron is hot NOW.

[Vladimir Sinitzyn]

Totally agree with u and I guess Diaspora community needs to think not
to code or even design first, but about it's architecture. How
modules will be interact with each other and it will be more useful in
future, when we will be about creating an API to build external tools
for diaspora, to build some extensions. We need to know how it works
and it would bring 2 things 1st - it would be freed new community
members from questions of Diaspora's infrastructure, 2nd - improve
stability, as we could see where one module communicates with each
other, it would be good for fast error finding. This is my opinion.