19 Oct 2004 | Don Schenck said...

Partner with other companies that are willing to become "Certified Basecamp Experts" that will sign on to offer support.

(*cough*Xceeda*cough*)

I can't see walking away. I can see "spreading it out". Keep the burden evenly distributed.

19 Oct 2004 | Darrel said...

Don's method can work, though I dislike having to deal with intermediaries when it comes to enterprise software. You may not have to support the end user directly, but you still need to support these intermediaries.

I'd suggest selling unsupported licenses to those that want them, and then provide a strong, open user-to-user support system.

With enterprise software, I much prefer user-to-user support. I guess namely because 'included' or 'paid for' support is usually pretty crappy to begin with. ;o)

19 Oct 2004 | Sam Sherwood said...

Don's idea actually sounds like the most cost effective of the bunch.

If you put together some sort of certified reseller program, even, then those companies would be responsible for supporting their customers. If any larger problems come up, then said reseller escalates the issue to 37Signals.

Bidding sounds entirely too unpredictable, unless you've already gotten some solid offers from larger businesses. If that's the case, then you might as well offer Basecamp to those companies with whom you'd like to create a relationship.

Past that, option 8 is also rather agreeable, considering its most in line (in my opinion) with your current business model. Stick the niche... especially if it works!

19 Oct 2004 | Marc Hedlund said...

#8. Stay on target. Do one thing incredibly well.

19 Oct 2004 | Jason Santa Maria said...

You could sell the second most recent version as a stand alone, as-is, no support. Keep the latest and greatest on the current monthly scale.

19 Oct 2004 | Mark said...

8.

19 Oct 2004 | Brendan said...

8.

The other road ahead.

19 Oct 2004 | Thijs van der Vossen said...

8, but you might want to start selling higher-priced 'enterprise hosted' versions running on dedicated servers, using SSL for secured access, providing guaranteed uptime, maybe even running a bit older 'proven stable' version, etc.

Ask yourself why you get requests for installable versions. What's missing from the hosted version and how can you provide that?

19 Oct 2004 | rob said...

Perhaps an answer resides, quite literally, right under our noses (movabletype.org).

While it is doubtful a market exists for a "Personal Use" Basecamp license, some small modifications could make it a "Small Business" license that could work.

This model in some ways mitigates the human scaling and keeps the small group working on making basecamp better instead of being slaves to the current release.

It seems there are 3 key elements here here. Licensing, Coding, and Support. While related, they are all quite distinct and deserve their unique investigation before proceeding (as they can all drive you out of business *grin*)

Regarding the Coding/Support elements.

A low cost/effort next step could be having a few different friend-companies start with a clean base OS and let em have a go at the install of your current release and see how it goes. This should give you an indication of what the best case scenario would be with minimal effort required on your part. If the immediate results are scary, then walk away from the idea for now for a later re-investigation. If it seems doable, figure out some steps.

19 Oct 2004 | DaveMo said...

I have to say that Don's concept was the one that immediately popped into my mind about halfway through your post, so I was pleased to see it was the first in the replies here.

You could use option 6 as starting point to recruit potential partners.

Just some questions that come to mind as well:

How hard is it to trouble shoot your product from a remote location?
What kind of system "environment" is optimal for the product?
Would this be something you could sell as an "appliance" so that the "environment" could be more closely controlled if that was an issue?
Document and setup turn-key franchise packages?

Just thoughts.

It'll be really interesting to see what direction you decide to take.

19 Oct 2004 | Alderete said...

Combine 4 & 6 (and possibly 2, to set the price for #4?):

Pick the organizations you want to work with, and truly partner with them. If you're picking world-class creative teams, like those at Amazon.com and Google, and you give them the incentive to see you succeed, you will get human scaling from them, without hiring.

19 Oct 2004 | Wade Winningham said...

I've worked on an ASP modelled application for a number of years. It was written from the ground up to be sold in a stand-alone version, too. While we did have one company purchase the stand-alone version, the ASP version was so successful that we decided to not offer a stand-alone version anymore.

Our primary feature to make this happen was offering https URLs for access to their site, which really boosted our clients confidence that their information was secure. We charge a little extra for this, but it was enough for most of our clients to be okay with a hosted application.

So, maybe you can really dive into the reasons people are requesting the stand-alone version and see how you can make the hosted model address those issues.

19 Oct 2004 | A. Casalena said...

It's amazing to read this post, because this issue has been revisited with regard to Squarespace no less than 10 or 15 times in the past 6 months through various business discussions.

We're just like you, a hosted product that some people don't feel comfortable using in a hosted environment, because they're too big, need customizations, etc. We, just like you, respect that--and often point them towards a product that can better meet their non-hosted needs. The distribution channels thing pops up weekly, and we start considering the offline installs for big customers in various verticals.

My comment here could be about 2 pages long, but here's my main concern (from a developer's perspective): The work you do to support a non-hosted product is fundamentally different than the work you do to support a hosted product.

The managed product has a support cost that's EXTREMELY low compared to what you're going to be doing when you have to take phone calls when an enterprise customer can't install version 2.5 of Basecamp over version 2.3 (but they never upgraded to 2.4, and some other guy thinks that 2.4 is breaking their critical data.). This is NOT your managed product, and you will absolutely introduce more not-fun coding as a result of the change. You'll also introduce more phone calls, which--in my experience--ruin an entire day of development after about 3-4. Support costs can ruin a big company, and can even more easily ruin a small one.

Organizations purchasing your software will almost absolutely require human scaling on your end to meet this support need, and probably, the scaling will have to be done prior to the installs happening. This is especially true if you put the price point high.

Managing the offline installations is a decision that means, basically, releasing a second, and fundamentally different, new product line. Since I'm a fan of the "one thing perfect" approach to software, I vote to keep the managed situation until you're ready to add on people who want to make their lives be new product version.

If you choose to distribute--please document what happens here and let us know what the rough spots were :)

Also, I'd watch out for #5--it seems like that might erode at the value you've created on the managed product (which is immense). You don't want a ton of free alternatives suddenly popping up.

20 Oct 2004 | stp said...

#8.

Most everything else smacks of making customers jump thru hoops, one way or another, to prove they are good enough to buy something from you. I think that's kind of offensive.

Just be who you are.

20 Oct 2004 | Ian said...

How about if you team up with a host provider to allow larger companies to have the options they want (be it, https, dedicated hosting, etc). This would allow:
- them to get access to the latest version and greatest features (which is what they'd want)
- you to remain in control of the service to prevent them from onselling the services to others
- they don't have access to the sourcecode, if that is a concern
- ongoing income from yearly licences
- limiting your need to deviate from current practices to allow you to concentrate on what you're doing best

20 Oct 2004 | J. Peele said...

almost every option as some sort of appeal to it. but #8 most clearly reflects who you guys seem to be.

"don't make it more complicated than it needs to be."

and even though you charge for use of Basecamp, it has a certain grassroots, open-source appeal to it. it feels natural and obvious, and i think that is a result of the level of "hands-on" that you are able to apply to the finished product.

but partnering with a Google or an Amazon seems logical as well, but not with Basecamp as we know it. but rather a newly architected version of Basecamp (2.0) meant for the enterprise environment. here again, it seems as though that your current pricing and distribution model is what Basecamp was designed for. so let Google apply their muscle (if interested) to a version for the enterprise. and call it Gcamp...

*ching, ching*

20 Oct 2004 | Beau Hartshorne said...

Check your licenses. If you need to distribute any GPL'd software (like MySQL or Linux) with Basecamp, you'll need to release Basecamp under the GPL. Sometimes you can buy your way out of this situation, or switch to "more free" software like FreeBSD and PostgreSQL.

In any case, you can't compile or otherwise encrypt Ruby code unless you modify and redistribute the Ruby interpreter. If you do this, you'll have to make sure you don't violate Ruby's license. If you don't want to waste resources hacking away at the Ruby interpreter, you'll have to accept that your source code will be available for your clients to read and change. Even with a good contract, how would you enforce it? This makes 5 especially unatractive.

Joel Spolsky sells a web-based bug tracker as a downloadable installer. He's written about distributing source code to end-users here. Check out some of his essays if you're interested in what it's like to run this kind of software company.

Paul Graham built Viaweb (now the Yahoo Store) in 1995. He's written about why he thinks an ASP makes the most sense.

I think you should keep it simple. 8.

20 Oct 2004 | Brian Sweeting said...

I say keep it as a hosted application, but add SSL and secure file storage. It seems that those things would be the most important factors that would justify an installed instance of Basecamp.

20 Oct 2004 | pb said...

I'd suggest figuring out if you can go the dual-license open source route. The model here might be SugarCRM. They've indicated that they would offer hosting but I haven't seen it yet. Third parties are hosting it, though.

Separate but related, this might be where Ruby is problematic. A LAMP-based solution may be easier for customers to deploy, maintain, customize, etc.

20 Oct 2004 | Anon said...

I guess it comes back to the potential customers... why do they want to be able to purchase it in this way? Reasons may include:
- Keeping their IP under their full control
- Customising it to better suit their needs (ie, integrate security controls with their current system, expand for bigger projects, etc)
- Performance
- ?

20 Oct 2004 | JR said...

JF, stick with 8. Consider 1-7 for your next product.

20 Oct 2004 | a said...

I suspect that most recommendations for number 8 are from people who admire the simplicity and elegance of the idea, much as they might admire the simplicity and elegance of your other work. This is probably a poor reason to choose the option, since it's unlikely that business plans succeed (or fail) based on the same criteria we'd apply to user interfaces.

If you need to scale the business in a hurry, option 8 is too limiting. The auction-based ideas sound very unlike your usual attitude towards customers: "you might win and get what you want, but you might not" isn't very 37S.

It is very true that the costs of supporting both models--hosted and installed--are substantially higher than just doing hosted. You're really talking about adding a dedicated support staff that's trained on multiple versions, developers who know how not to break old versions that some customer's patched, and more. You may find you need a Services group that's dedicated to installation and customer account management. That stuff is grim, often soul-sucking work, not a lot of companies pull it off well .

Salesforce.com might be one of the most successful examples of an ASP/installed product, I don't think anyone's mentioned it here yet: lots of capital, lots of layers of management, lots of employees.

Here's another option: sell Basecamp to someone else and walk away with the cash.

20 Oct 2004 | Chui said...

You need channels. Trusted channels. Start through people you trust, one in each country, and let them be the local technical experts who are able to install and support your software. Continue to market globally and centrally.

Do not try to make much money out of these first level distributors. They are your seeds. Pay them well. Perhaps most of the takings from the first years subscription. After all, your marginal cost is zero. Once they have stabilized, they will be able to grow their channels or sales force to support their customer base.

On the other hand, these first level distributors must put money where their mouth is, and commit to sharing the cost of promoting and marketing.

Build a vibrant community of users so that they are able to self help. After all, social software is about conversations.

Do not be tempted to customize your software for each customer. This will only lead to negative-profit customers. Be prepared to say "no" or "we are not ready".

20 Oct 2004 | DaleV said...

8.

Enterprise software bites. Always does, always will. There is no such thing as a 'trusted channel'.

Me? I always figured some goat of a company would offer you a bucket of cash and then program the thing into the ground.

20 Oct 2004 | Don Schenck said...

Disclaimer: My idea, which I feel is a good one, is biased in that my company would want to be a partner.

Putting my own best interests aside (a stupid business move), I have to go with #8.

Can I be undecided?? *laugh*

20 Oct 2004 | Jim Cuene said...

1st, prioritize and clarify the problem you're trying to solve: Are you trying to increase revenue, trying to open new markets, get more clients, or generate some increased working capital (through the cash generated from the sale of the licences), or, something else? You've started thinking about what you'd be willing to invest to make this happen, and you've got the organizational design strategy figured out (stay small, scale slow on existing cash flow, use distributed blended contract/employee team).

Obviously, profit is the reason you're considering your options. But, are you being "pushed" to open new markets by cashflow or profit needs? Or, are you simply trying to be carefull about your next step so as not to mess up the current success? Do you really need to open new markets? Do you feel like you've topped out your current market? Are you not making the profit you need in the current market?

Mainly, I'd be uncomfortable changing your business model. Selling apps is very different than signing up users online. Hitting the pavement vs signing up clients while you sleep. I'd look for ways to enhance the current model through product extensions (billing, invoicing apps) for which you can charge incremental revenue, or developing new, related products using the same model.

Assuming it makes sense to sell Basecamp as an installed, supported product, I'd lean towards 8. 1 through 4 seem overly complicated and don't really solve any problems for your customers, other than gettin them the software.

#6 is attractive, too. If you can get the right companies to buy in, it can work out well for both. Keep the number of clients small, though. And build in a monthly service fee. At the very least, if you're interested in trying to seel the app, I'd find one company you want to work with and try out an install / service model with them. You don't have to move fast on this, I'm guessing.

As someone who has been in a similiar situation, I'm glad we chose #8 as our option. It was right for us at the time.

But, here's what we could have done, if we thought of it back then. I wish we could have set up a separate company as a sales organization, to take on the sales, support and client management for us. We could have stayed focused on the product development and the hosted model we had working well. It would have been relatively easy to hire the sales development and support teams. I'm sure you guys know a number of good business development pros. It could have been small (1 sales guy part time, 1 full time support/coder) out the door, too. The sales organization could have been independent, which means it would have had to be successful on it's own as a business (which wouldn't have negatively impacted the cashflow/finances of "the mother ship").

Good luck, guys. You're in a great position.

20 Oct 2004 | Joe said...

Don't distribute a piece of software that gets installed on a server. Distribute a 'Basecamp distribution' on a server that's already set up with the software.

Then, if I'm an enterprise, and I want internal Basecamp, I just get a rack-mountable server from 37s. I plug it in, put it on the network, answer a few short wizard questions (how to get IP address, machine name, etc), and I'm off. Give the client the option of allowing (or not allowing) your staff to dial in to the server, poke around, and fix things. Include a CD that, when inserted into the drive on boot, resets all the software back to the state it came in. Provide a facility for regular backups, and a facility to restore. If you use Linux or BSD, you could hook in to a package management system that allows for automatic updates.

Supporting your app on a huge number of software configurations is always a pain in the can. Supporting it when there are lots of systems all configured the same way might be easier. I'd even argue against giving the purchasers root access to the box. Only allow them to perform the administrative use cases neccesary to run and maintain the app.

20 Oct 2004 | Rob H said...

I would reccomend that you stay with the ASP model..For those who don't feel comfortable with their information hosted, you might offer a version of Basecamp for additional $x that is SSL encrypted.

An installable version would be nice, but also brings the burden of support..

Focus on making Basecamp the best that it can be(your on the way), and when the time comes to have to reinvent you can look at all the options available ( Like AVR program, standalone versions with or w/out support, Open Source it, bascamp appliance(ala Google Appliance,etc.) and what the marketplace wants.

-R

21 Oct 2004 | Chris Messina said...

I think you really need to go back to both who is requesting the installed product and why. I remember you talking about this at the Chicago Building of Basecamp workshop. At the time, it sounded like a lot of these companies needed more security, more control and more integration with their existing infrastructure -- certainly things which justify a non-hosted solution. But then again, perhaps you could simply create APIs for Basecamp which their systems could interact with? Or perhaps what they need is more than or different from Basecamp?

I really think that you should stick to the nexus of the power and attractiveness of Basecamp -- to that mix of features, functionality and style of defensive design that's lead so many people to chose to sign up with your hosted service.

That said, if you are really considering a new direction/expansion for the Basecamp service... do so carefully. The current product is what gives the Basecamp brand so much value--and I think for so many of us, we like Basecamp as it is, with the improvements that you steadily and zenlike continue to add. I'd hate to see you forget about us in search of a better profit generation stream.

On the other hand, there are a few things you can do which won't jeopardize the integrity of the experience that will also accommodate the needs of 66% of your anti-ASP customers.

First, offer SSL and secure file hosting. That we (the user) need to provide file hosting and that the files are sent over open http is probably a deal breaker for a lot of folks. Additionally, I think if the overhead of hosting everyone's files wasn't so high, you would have built it in to the product from the beginning... so remember, in an ideal world, this problem wouldn't exist and what your clients are requesting is something you could implement if you charged more for those features.

Second, develop a Basecamp API that people can upload contacts into or do whatever kind of integration with their own systems that they need. Perhaps it's not as easy as that, but I think that might take care of another 10%. Beyond that, you've allowed them to change the logo and colors... what more do they need to customize unless they plan on selling the service to someone else? At some point, it won't be Basecamp anymore!

Lastly, consider Joe's suggestion. I think that a Basecamp rack-mounted server makes a ton of sense compared with the willy-nilliness of your other suggestions. It's been said in the comments above and I'll repeat it: if you open up your source code to third-party tweaking, a mess will result.

Think of all the times you've said "no" to Basecamp users' suggestions. Think of how many of your own good ideas you've sacrificed to the chopping block to keep your vision consistent. It's your job as Basecamp's creators to also be its keepers. YOU maintain its integrity. YOU maintain the "say no first" mentality that has brought you so much success--success where so many others have failed. I mean, I'm only 1 of your 10,000s of users, but I think I speak for a lot of us when I say, don't mess with a good thing by distracting yourself on anti-ASP customers!

21 Oct 2004 | awk said...

The GPL doesn't apply to Basecamp if you are "aggregating" the software, i.e. distributing MySQL along with Basecamp and they communicate over a socket in the usual way. www.fsf.org has a long FAQ about all that.

What I've done occasionally is distribute only my own code, and then run a script to download, patch, and install all 3rd party code. I've done this to use djb's software which is doesn't come with a distribution license. You can make a customized Gentoo install CD, for instance, that pulls down all the right packages.

Other comments: I'm just a lone consultant with a handful of clients, I am used to open source software and customizing it myself so I would love to see an option for folks like me. The only reason I would buy a copy would be 1) warm fuzzy feeling of being able to back up data myself and 2) ability to tell clients for sure that the data is not accessible to a 3rd party, 3) the ability to customize it for my use.

Lotteries and writing college applications seems rather arrogant to me.

I like the ASP model because as a user it's nice to see new features and bugfixes magically appear. Plus I can't justify any great expense due to the small number of clients that I use basecamp with. With the ASP model I get the same service as a higher-paying customer.

As a programmer or designer I'd like the ASP model because I could concentrate on making one version the best it can be.

The "appliance" model might be good too, I am doing that in a small scale (6 installations) with a web app I wrote, basically install it on a dedicated machine from scratch and only support that configuration. Push upgrades out to the machines so everybody uses the same version and they get new features. And remote monitoring over the web and security upgrades so they don't have to worry about a full disk or buggy Apache. That's like the best of both worlds for the customer and you take in monthly fees.

21 Oct 2004 | Beau Hartshorne said...

awk, MySQL's Commercial License page says that distributing software that includes MySQL or requires users to install MySQL means that you'll need to purchase a MySQL license, or release your code under the GPL. MySQL AB owns the copyright to MySQL, and they enforce it.

RE: Customized Linux CD, or hardware appliance. Linksys (Cisco) was caught releasing their hardware with a version of Linux pre-installed without releasing their code under the GPL.

Chris, I think your ideas are solid, especially the one about releasing a Basecamp API.

Jason, what are your thoughts so far?

21 Oct 2004 | Don Schenck said...

Xceeda stands ready ...

21 Oct 2004 | JF said...

Jason, what are your thoughts so far?

Love the feedback so far. Thanks so much for everyone putting time and thought into their responses. It's really amazing.

Oh, we're heavily leaning towards #8 ;)

21 Oct 2004 | marc said...

Although I realize it is not the focus of Basecamp, I would urge you to consider how it may be utilized in the University/Educational environment. I am a graduate student and am often dealing with team projects where basecamp would be/is a great help. These are significant projects... perhaps the only difference to your other clients is that the profits are not necessarily monetary.

An option for student/educational pricing would be fantastic.

I understand the advantages of your current model, but for what it's worth I have never been a fan. I am simply uncomfortable with you hosting my information and having no control to the changes of your application. I suddenly get an email with a list of things that have changed and why. What if i don't agree with your changes? or simply the timing of them?

thank you for your time.

22 Oct 2004 | Ritz said...

Where do you see an end-game or exit strategy? Not to say that you want to quit or cash out, but at what point is the product... the product?

Seems like you have winner and some scary decisions are opening up. A lot of companies see success and try and figure out how to make more success and just end up diluting their brand and losing the edge they had on what was successfull in the first place.

Go with 8 and keep it rock solid and spend more time thinking up new stuff. Can't wait for "Building Another Boomstick Application Conference". I'll be there for sure!

22 Oct 2004 | Jason Hoffman said...

Keep it hosted but expand it to allow custom domain names, some sort of local file upload (putting it on top of subversion repositories would be the ultimate, can offer versioning) and make the email notifications two-way (so one can reply/post via email).

And also sell it just a few local installations at a real premium.

30 Jan 2005 | compatelius said...

bocigalingus must be something funny.