Basecamp and The Federation of Work

I have run up against what I think is a basic flaw in the Basecamp model.

Many times in the past few months, I have started a project up with a group, or groups, who like me are already using Basecamp. The problem that arises: Whose Basecamp implementation to use?

I would, of course, rather manage projects that I am involved with in my own Basecamp instance, while the others have the same perspective. But what happens, quickly, is that I have a bunch of memberships in other Basecamp projects, which do not collate into a coherent single view.

What's missing is a fundamental insight: the federation of work.

Basecamp lacks the notion of federating project work. While I can invite my pal, Greg Narain, to join a project I am running, Basecamp is only willing to consider Greg as another individual, not as the owner of his own Basecamp instance. As a result, Greg must login to my instance to participate, and the status of the project does not show up on his dashboard.

The solution? 37 Signals should rework their participation model to reflect their new-found success: there are thousands of Basecamp users out there, and more of us will be running into this limitation. More important, perhaps, is that a federated model more accurately reflects the nature of the world. I am involved in a dozen or so projects, and I would like to have a single, coherent view of what's going on across the board, as do all over my partners-in-crime.

Certainly, a single company still needs to be the administrator for each Basecamp project, but that doesn't mean that we need to login at ten different instances everyday.

Basecamp should look at the federation model of Jabber and other successful bottom-up, federated tools. Within Jabber, I can login to my local server, and IM with any other trusted server in the world. The servers simply have to establish a trust relationship. In the Basecamp world, I should be able to invite Greg to participate in a project, and when he agrees, he should be able to simply point at his own Basecamp instance, rather than having to create a brand new, easily forgotten login.

At any rate, Jason and company are well-known for rejecting new features, but this is more than that, this is a fundamental need that should have been forseen from the start. And, in a way, it's just another indicator of the success that the product enjoys.

tags: jason+fried, 37+signals, Basecamp, federated+work, project+tools

Comments

[Darren Herman]

Yes Yes Yes. You nailed it on the head. What if a person registered with 37 Signals (Basecamp) and then got their own dashboard. They then could subscribe to multiple dashboards. This way, we dont have to recreate each time we want to join a project. This is a problem of their own success, and can be modified. Steve, you found a great flaw... fantastic!

[Bill Seitz]

JonUdell refers to this realm as Overlapping Scopes of Collaboration.

[Stowe Boyd]

Darren - It's Stowe, not Steve.

Bill - I will track that down.

[Dave Carroll]

I think the interview would have better if you spent less time talking about yourself, and more time letting Jason talk. The interview is about the other person, NOT you.

No need to post this. Just a little constructive feedback. Thanks for the interview.

[Stowe Boyd]

Dave - Thanks for the tip.