All the signals have been crunching for past few days wrapping up our Next Big Thing. So what is it? We've been struggling with a succinct way to answer that question for a while, but one angle is to define it off something you already know.
Backpack is Basecamp for your life. It's the product I've longed for when I used Instiki as a personal wiki. It's the product I tried to create through a mesh of outlines, email inboxes, post-it notes, The Brain, and a gazillion other systems under the sun. It's a Get Your Shit Together And Keep It So kind of system.
But at the same time it's not limited to or just about productivity, such as The System in a Getting Things Done kind of way. Which is of course what's making it a bit harder to explain. This is really one of those things were words are poor substitutes for experience, which is why the marketing site is all about examples.
All the people we've been demoing Backpack to got it as soon as they started seeing how we used it. So examples, examples, examples. That's what you'll see when the marketing site launches next week.
Until then, you can either hit refresh in your mailbox an unhealthy number of times per hour waiting for one of those golden tickets we'll be distributing, or you can check out the Backpack Manifesto that Jason wrote up.
Let me say that I'm really impressed with Basecamp, and it looks like BackPack will be equally impressive. However, I don't actually use Basecamp, and I doubt I will use Backpack.
The reason is simple, and it's one that I brought up at the Building of Basecamp workshop I attended in Chicago a couple of months ago: There is a small percentage of the data that I work with that I simply can't trust to a 3rd-party server. It might be too private, or, in many cases with my company, simply illegal to share the info with a third party (information that might have this restriction apply ranges from personal medical information to any sort of classified or potentially classifiable material). The existence of even a small percentage of this type of information essentially makes an excellent all-in-one management tool like Basecamp, or by the sounds of things an excellent all-in-one PIM like Backpack, completely useless. A single "But for this info, you have to look over here in this other system" significantly undermines the utility of this kind of system as users lose trust in it, and have to think about which systems they use for which tasks, even though to them, the tasks are essentially the same.
At the BOB workshop, the signals talked about the difficulty of making user-installable versions of these products - versioning problems, "technical" installations, etc. I hope that the "signals" continue to consider their options in this arena, however. Someone such as myself would be willing to pay alot of money for this kind of functionality on our servers, just so that we could have nominal "control" of potentially sensitive data.
This is a problem that has been solved by many companies, and I hope that 37signals takes some hints from them and tries to solve them too. Difficult to keep versions up-to-date in a "release early release often" development model? Implement a self-patching system and verification system (I feel that Ruby's strong emphasis on unit testing makes this particular option especially workable on the backend). Install too difficult? Sell "consulting" services yourself, or train and then license others to sell them.
There is a HUGE market here for 37signals, and I huge benefit for people in situations such as mine.
Thanks for reading,
Challenge by Jason Fried on April 28, 22:23
Thanks for your feedback Ben. We don't want to become one of those software companies that has to deal with thousands of installed copies, thousands of unique tech support issues, thousands of configurations and third-party conflicts. We want to be an ASP and that's where we'll stay. Salesforce.com has done a good job with it. We can do.
It's ok if if we don't reach every possible customer. We're reaching the ones we want to reach, they're reaching back, and we're all in this together. It's managable for us. It's managable for them.
We're not in this to be all things to all people.
Challenge by Ben on April 28, 22:28
Actually, Salesforce.com does exactly what I'm asking for in a good way. Very little of Salesforce's engineering effort goes to the front-end; similarly, very little of their profit comes from it. The genius of salesforce is the way that it integrates their front-end with a variety of back-end data sources, many of which have the option to be customer-hosted. It's a company that is an army of consultants that tailor one good interface to many backends that give its customers tremendous control over how their data is stored.
Point taken on not wanting to be all things to all people though, and not wanting to take on the headaches of becoming too big for your own good. Best of luck to you guys.
Challenge by Jason Fried on April 28, 22:31
Well, then I was wrong about Salesforce.com. Basically we want to be an ASP and an ASP only. No customization, no configuration, no installation.
My understanding is that SalesForce.com integrate via their rich web service API (sforce.com). This allows externals applications to push and pull data into SalesForce and integrate to many systems in a seamless manner.
Have 37 Signals considered providing any form of web service support in Basecamp and now Backpack?
Will Backpack have an api that I use to access/manipulate the data I keep in backpack? For example, I could see automatically pulling out certain things from Backpack to appear on my blog's front page.
Jason, you are right in the approach to be an ASP and stay an ASP. That leverages a lot of software-inherent problems from you and you have complete controll over your software and service. I would love to drive such an approach from a developers perspective.
But then I think it is not the right direction to provide applications that try to manage sensible private information. I agree with Ben, there are a lot of things I want to manage in my PC (personal computer, with emphasis on personal, although I use Apples PBs) that I don't want to transmit over the internet.
The second fact is, I don't have web access every time I need to look into my life.
So I think as an ASP you should focus on data and applications that manage unprivate and unsensible information. That means, let "helping to bring your life's loose ends together" be the scope of a desktop app. A private app.
Btw. I really like to see Backpack, although I wouldn't use it if it's what I think of it now...
Challenge by PB on April 29, 15:02
Is not possible in Basecamp allow that database work inside customer server and basecamp in 37signals server?
In this way, customer has private data and 37signals has application. Of course, all comunication between data and app will be send encrypted.
I think everyone voicing privacy concerns should think for a moment about what Backpack will be storing. Credit card numbers? Bank account information? Social security numbers? I don't think so. Real-world crackers don't care that it's your mom's birthday tomorrow, but they will stop at nothing to get at your cash.
In the case where it makes sense to use Backpack for secret or other confidential information, from a business perspective it may make more sense for 37s to offer stronger encryption, and perhaps some form of insurance (as PayPal does, for example) rather than managing than dozens or hundreds of deployments.