Jason Fried on The Federation Of Work

Jason Fried responded to my criticism of Basecamp in a comment to a recent post, Micheal McDerment on Software Should Be Social Because No One Works Alone. I had stated that I consider it a basic flaw that Basecamp doesn't support a federated model of work: that is to say, if I am working with four companies who each have a Basecamp instance, I wind up with four account/login/password combinations, and worst of all, no unified dashboard view to consolidate all my Basecamp information.

Jason makes some well-reasoned arguments in favor of the current status quo:

Thanks for your thoughts. A couple things.

1. Most people are not like you. Most people are not as connected as you. Most people, the vast majority of our customers in fact, have one Basecamp account that they use with their clients or just internally. Yes, there are folks with multiple accounts, but they are the slim minority exception, not the norm. The majority of our customers aren't well connected techies, they are small business owners that use a tool alone or with their clients. They have their own small world. Multiple Basecamp systems are rare among these folks.

2. We are working on a product we've code named "Compass" that will provide single-sign-like capabilities to customers that use multiple versions of our products. We don't comment on release dates so I can't share any additional information, but it's something we're planning.

The inconvienent truth for techies is that most people don't have the problems that techies do. Most people aren't roaming between multiple Basecamp accounts. Most people also use the same username/password everywhere so they already have "single sign-on." But we do agree -- a more unified sign on across multiple products is useful so we are working on it, it's just not the most important thing right now.

Another thing to remember is while it feels like we've been at this for years, it's only been 2.5 years since Basecamp has been released. Backpack just turned 1 a few months ago and Campfire is just a few months old. We like to nail the basics in our apps first and then work on the more complex issues later. Multiple products with multiple logins is a more complex issue. It's time is coming, but it would have been wasteful for us to spend our time on such a complex issue a year ago.

Jason's point about me being abnormal is true, as far as it goes. I made the same observation last week at Reboot 8, where I outlined the Basecamp Federation Bug as an anti-example in my talk on Social Architecture. I am more connected than others, and so I have encountered this basic flaw earlier than the majority of Basecamp users.

However, anyone who is a free agent -- working for multiple companies, or across multiple projects in a big company that has more than one Basecamp account -- will encounter this problem just as soon as I have, although they may not have the situation that I do, with over a dozen account/login/password triples in the past 12 months.

Note: the admin of the account picks the name for the instance, such as awm.seework.com, which is my A Working Model account. Other instances could be on any other the five or so non-intuitive domain names that 37signals maintains for Basecamp account. Then the admin picks the login name for users. I picked stoweboyd for myself, but my clients have picked stowe, sboyd, and other variants. And, yes, I can change the passwords to all be the same, but that is a minor part of the whole thing.

And I think that nearly everyone will encounter this issue in time, as more and more companies adopt Basecamp, and seek to collaborate with other users. And what about those "clients" that Jason mentioned? Aren't they likely to be clients of other companies, even if they aren't the one paying the bills?

I am happy to see that Jason is planning to work on this issue at some point, and regret that he doesn't think that it is critical enough to address right now. And I still believe that this is a design flaw in the basic social architecture of Basecamp, not a feature that only supernodes like me need. Although Basecamp has had great success, a flaw like this retards growth of the user base. If this worked in a federated fashion, it's easy to imagine that the product would be spread more easily.

At the present time Basecamp is super dominant in the market for online social project management, but they aren't alone. And I can safely predict that the eventual Number 1 in this space will be the player that gets the social dimension right, not just the best list of features. That could very well be Basecamp, if they focus on that tier of social architecture. But some other enterprising players could enter the market with a stronger focus on the social dimension, and by virtue of that focus could move more quickly to create a marketplace to support whatever the larger context is for all that project work. And that marketplace is worth billions more than project tools.

And, remember that Basecamp is not really winning today based on the quality of the features: writeboards, as just one example, work well enough, but let's face it, textile is a pain in the ass as a markup language. Have you tried to indent paragraphs, or sticks images into writeboards? Very kludgy.

So the strength of Basecamp's competitiveness is the intuitive social media approach to sharing of project information. That's the key to the product's strength, and at the same time, hedging in that area may prove to be its Achilles Heel.

Jason and I will be attending the upcoming Collaborative Technologies Conference 2006, in Boston, in a few weeks. I think he is a brilliant entrepreneur, author, and developer, as I have said on numerous occasions (see my review of Getting Real, for example). So I hope that we will get a chance to discuss this again, in some forum or another at the event.

tags: jason+fried, 37signals+compass,37signals, the+federation+of+work, basecamp, social+architecture, reboot8, the+revolution+will+be+socialized

Comments

[Amie Gillingham]

Our biggest tech issue is that our people can only use Basecamp to co-author documents instead of using tools like Mindmap collaboratively or work on code together in any meaningful way. Plus, you can't even cross reference between what well may be related projects within one's biz structure. And that's just within the small system for our business.

There's no question that Basecamp has helped us to get more organized and keep better track of team tasks across the board. But I long for an app that will actually do that PLUS facilitate the ability to complete the task in a social manner.

Anyone out there have something like *that* up their sleeves?

[Jason Fried]

Thanks for the follow-up comments, Stowe.

Remember that we have an API so some enterprising entrepreneur can build a nice multi-account Dashboard. Maybe there's even a business here -- the Basecamp economy is pretty large. I'm sure a well-built tool to let people manage multiple Basecamp accounts from a single screen could make some good money.

http://basecamphq.com/api/

[Chris Messina]

As a fellow superuser, I feel your pain. I actually had the same conversation with Jason recently without having read this post and he outlined similar reasoning, which I do respect.

At the same time, I think that it would serve 37Signals' -- and other independent shops more generally -- (since 37Signals is the bastion of independent neue-tech businesses) to optionally offer a distributed authentication system like OpenID for its members. So, in our case, rather than creating yet another account when invited to a new Basecamp, we'd simply enter in the address of the other Basecamp... we'd pick our username, login to the other Basecamp (that we're already familiar with) and be done. The personal data that we choose to share would be sent over and the new Basecamp wouldn't even need to reveal the remote URL that I used to login.

Anyway, that'd be a fairly easy mechanism for getting to something like SSO. And the benefit, of course, is that, rather than having 37Signals building yet another identity silo, it could play nice with other sites that support OpenID -- which, I might add -- is going to be increasingly steadily in the near future.

[Todd Sieling]

I have to sympathize with both Jason and Doc on this. As a product manager, I'm sometimes tempted to believe that if we can solve the problems of our most dedicated, most ambitious users (basically, leading edgers like yourself, Doc), then everyone would be better off. In some cases that's true, especially if the leading edger is doing something with your service that can change things for a lot of people (a novel use of the API for example). But in many cases solving the problem would add a layer of complexity that other members or customers won't see value in, and may even be confused by, because it doesn't fit in with how they use the service.