responding to joindiaspora

The joindiaspora guys, in a generally good response to my questions, conclude by asking:

[W]hat would be un-pragmatic about giving four excited dudes who spent their last semester of school thinking about a problem you are “worried-about-but-can’t-deal-with-now,” twenty bucks so they can take an honest crack at solving it? :)

Lots of people asked some variant on ‘it is just $20’ or whatever. First, I tend to be one of these people who don’t give token amounts to charity- I prefer to give larger amounts to a small number of projects that have very high impact (or very high odds of success if they aren’t having an impact yet.)

But the money is secondary. The important thing is that there are already a fairly good number of projects in this space, with a fairly small amount of users, developers, testers, and attention to spread between them. And to be blunt, I don’t want someone coming in with more web design and marketing sense than actual hacking chops and using up all the oxygen in the room. I think DiSo did this to some extent, frankly. So yes, giving a little bit of money to someone can be quite counterproductive and unpragmatic- and I wanted to reassure myself that I wouldn’t be contributing to that problem again.

Given that it looks like they’re going to be doing this crazy thing ($13K raised of their $10K target) that concern is now irrelevant.

(untitled) by Môsieur J. [version 3.0b], used under CC-BY.

So some thoughts on the rest of the responses, again in hopes that they are supportive and constructive:

We plan to “build less.”

Hooray! Most of these questions don’t have right answers, but this one did. And the followup priorities seem reasonable- those probably are the right minimum bits necessary. That said, where people have already built things, consider building less than less by working with other projects. Status.net comes screamingly to mind for the message passing component, but I’m sure there are others. Don’t just build shared specs- where possible, build shared code.

We see all of this communication happening between two Diaspora servers, rather than strictly between peers.

This seems like the very pragmatic solution to me; all the talk of real peer-to-peer is terrific but that is a very hard slog- both technically (getting it working) and socially (getting users to install it.)

With regards to DiSo, the response had one set of great things, and one part that was very ambiguous to me:

It seems to us that all of the previous attempts at solving the problem are trying to create the perfect solution in the first version.

I think this is right, and I’m heartened to hear the talk about building answers that satisfy rather than perfect. These are all signs
of excellent taste (not just this sentence, but many of the things both in this specific answer and in the entire blog post.)

Ambiguously:

[DiSo] tried to add on to WordPress, a project which was not designed from the ground up to be a distributed
network.

I’d love to hear more elaboration about ‘designed from the ground up to be a distributed network.’ WordPress has
proven to be a very flexible platform for a lot of things, and it both publishes and consumes structured data very well to that distributed network we call the internet (particularly that subset of the distributed network that consists of Atom/RSS publishers and consumers- I subscribe successfully to many friend’s wordpress blogs in something that looks very much to me like a distributed network.) In addition, things have improved since DiSo started, since there is now PuSH, possibly webfinger, etc. So which features are you looking for in a ‘designed from the ground up’ distributed network that wordpress doesn’t have? I’m not saying that wordpress is the solution, but I’m curious to hear more about what it specifically lacks.

With regards to Mugshot… I wish the Red Hat folks had posted a good post-mortem on that; to the best of my recollection I never saw one. My own sense is that: (1) it was very difficult for others to set up, so it never got an outside development community, and no one looked to it as a distributed solution to the problem. (2) The community it attracted was heavily tech-y, so the community that built on it looked to outsiders (frankly) like it was a bunch of nerds, which made it hard to expand into a more broad-based audience. (e.g., it was a great source of community for linux distributions, not so much for sports. Identica has the same problem relative to twitter; compare a search for lebron on twitter to a search for lebron on identica some time. Ditto Bieber or Gaga. This is very related to Pick The Right Customers.) Both are problems worth being aware of.

Solid answers on specs and services, including a couple projects I hadn’t been aware of- usually a good sign (even if one of them appears to be completely insane :)

We will be constantly sharing our ideas, and 100% of our code at the end of the summer.

I’m still not clear on why no code until the end of the summer. Care to elaborate? I’m not an absolutist on this- mostly for reasons related to bikeshedding and design- but it does seem like an odd default choice.

We think in the future (after the summer), we will work on an easy installation…

Only clearly wrong answer of the whole thing. Easy installation should be baked-in from day one- adding it afterwards is hard. As a bonus, it helps you write automated tests (since automated deployment is easy) and easy installation helps you choose the right customers by helping you attract users who are interesting in talking to other people rather than playing with software.

What are your three favorite books on software development? three favorite essays? what about on design?

Is this one of the questions where if I don’t say “Kernighan and Ritchie,” “Getting Real”, “Mythical Man-Month,” “Don’t Make Me Think!” or something like that, you will disapprove? :)

Yeah, sort of. But ‘Getting Real’ was the right answer. ;) (I sort of wish I had the time to write a mashup of Getting Real and Producing OSS, maybe with a dash of The Poignant Guide.) I also highly recommend Rework and Designing From Both Sides of the Screen. Blog-wise, you might find this list interesting, though not necessarily pertinent to this discussion.

Finally:

We bought him some arepas. They were delicious.

I’m sort of bitter that you live near that particular deliciousness. Also that you called me an old dude. But mostly because I miss those arepas. And the yo-yos. Enjoy one or two for me during your hacking breaks. :)