What is Backpack?

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.

It's almost here.

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,

Ben

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.

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.

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.

I "got" del.icio.us when I saw Jon Udell using it in his screencast. I think screencasts are the perfect way to demonstrate those sorts of websites. Just a thought.

Ben/Jason,

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?

An API for Backpack is high on the list of things we want to accomplish quickly after launch. When its in Backpack, we'll use the experience to get it into Basecamp too.

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.

That's exactly the plan, Curt. We already have an XML-exporter, so there's no trunk either.

Or pulling out a grocery list to store in my iPod's Notes?

You guys should add some “Show, don’t tell” movies for the backpack system then, a great way to see the benefits and “experience” of developing in rails…

Funny that you mention Instiki, David.

I've been thinking about that too. Backpack sounds awesome, and I'm psyched to try it (or simply start using it, I imagine). But will this product kill Instiki? Or wound Instiki and kill Instiki2?

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...

Hi all,

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.

I'm looking forward to the Basecamp/Backpack API. I think Basecamp especially could benefit from tight integration with other applications.

See http://sforce.com for more information than you need about the Salesforce.com API.