Category: Business

BaseJumpr: BaseCamp -> ActiveCollab

BaseJumpr has a fascinating service offering: they export your data from your Basecamp account, producing a set of files ready to import in to ActiveCollab, the open source Basecamp-sorta-clone-like-program. They then, if you wish to buy their hosting service, create an instance of ActiveCollab for you and import your data there. (They host your file storage on Amazon S3, so they can easily offer ample storage.)

I find this very appealing, yet also a bit impolite; 37Signals has built a good business on Basecamp, the ActiveCollab team has created (well, is creating) an open source clone, while BaseJumpr did neither of these things yet stands to gain (at 37s’s expense). However, I doubt BaseJumpr is a significant threat or bother to 37Signals because most users interested in the open source ActiveCollab would likely not be using the Basecamp service in the first place.

Speaking of Basecamp, I am fascinated by 37Signals’ business success with such a simple (but well executed) application. I tried out Basecamp myself, and found it far too feature-anemic for my taste; but I could readily see its appeal and simplicity, and it has me thinking about the merit of building a business in a focussed niche, intentionally and happily excluding the potential customers outside it.

Update in 2009: BaseJumpr doesn’t appear to exist any more. I am curious how it worked out.

Selling your Software as a Service: Notes and Audio

At the St. Louis Code Camp on May 5, 2007, I gave a talk on Selling Your Software as a Service, in which I discussed our experiences selling a complex (Java) “enterprise” application in that manner. The room was much more crowded than I expected, it was exciting to have an eager group. As with all my recent talks, I used a handout instead of slides. You can download a PDF of the handout (one page, one side), or read the contents below.

The 1 hour audio recording (Olympus WS-100 digital voice recorder, Audacity cleanup) is available here: SAASTalk.mp3

A transcript of the talk is available. In the talk I mentioned Paul Graham’s The Other Road Ahead, which is shorter and easier to read the my talk transcript.

A couple of people at Code Camp asked if I could come give a similar talk in-house at their firms. Yes – please contact me with the contact form to arrange a date.

The handout contents follow.

Continue reading “Selling your Software as a Service: Notes and Audio”

St. Louis Code Camp, May 5 2007

It’s time for the second (annual) St. Lous Code Camp on May 5, 2007. There’s no actual camping (unlike some other ___ camps out there), just one day of sessions. Think of it as a mini-conference. See Brian’s announcement for more details. If you’ve been thinking of giving user group talks and never gotten around to it, Code Camp is a great place to start.

I’m in for two sessions this year, assuming enough slots are available for both: Continue reading “St. Louis Code Camp, May 5 2007”

Dear PayPal, My Thoughts Do Not Fit In 40 Characters

I recently closed a PayPal account. During the closing process, and again thereafter, I was surveyed as to why I closed the account. Predictably, these surveys offered a few choices for why I didn’t want the account, with only a tiny field if I wanted to explain in more detail why I closed it. I picked the choices that were closest to my actual reasons; but they really were not close at all.

(Kyle’s Business Tip of The Day: You really aren’t helping yourself, or your customers, if you set up feedback mechanisms that only allow you to hear messages you want to hear.)

So here is my reason to be wary of PayPal: I can start with a credit card, but I won’t get far that way; to do anything useful with PayPal, I need to grant them full access to my bank account. At every bank I’ve ever used, there is no mechanism for partial access. Once a vendor is in, there is nothing I can do to stop them from withdrawing all my money. For example, there is no way to say “this vendor can pull out up to $N in a month, and no more”; at most I can get, in some cases, notification of transactions. This is unsafe: fraudulent access to my PayPal account, or a bug at PayPal, could empty my bank account.

There is no “push” way to get money in to PayPal. An example of Push would be that I mail them a check, they deposit it, they wait N days for it to clear, then they put the money in my PayPal account. Push is safe; it avoid granting them “Pull” access to my accounts.

These issues are not solely PayPal’s, rather they are caused by the broken bank payment system here in the U.S.; but it is clearly PayPal’s choice to not provide a workaround in the form of a “push” deposit mechanism.

(European readers will probably find all this silly; apparently in that part of the world there are “push” mechanisms to transfer money electronically, and for all I know PayPal may work like that European customers.)

How Not To Shoot Yourself in the Foot with Change Control

As anyone with experience in a large firm knows, change control procedures (and “change control boards”) are a common fixture. Change control mechanisms (such as requiring extensive documentation, signatures, meetings, checklists, approvals, etc.) have obvious benefits, but they also add inertia, increasing the cost of change. This refers to both dollar costs (meetings aren’t free), and to inaction by employees who find it not worth the effort to a desirable change approved. The net result can be that bad procedures, features, documents, etc. stay in place, to the detriment of the organization.

Thus, I will frame Kyle’s Guideline on Change Control:

The “weight” of your change control system should be, at most, proportional to how good your product / processes are. If things are really bad, fix them *first*, while it’s easy, and then *after* that add in the obstacles to change.

Unfortunately, this ubiquitous alternative procedure:

  1. Notice things are bad.
  2. Add change control mechanisms that make it hard to fix them.
  3. Avoid changing the things that are bad.

is actively stupid. (Of course, maybe your problem is that things change too much… in that case, the first thing to change, is to make it harder to change.)

One URL per page

A few weeks ago I was working on a web site that wasn’t getting as much attention from Google as the site owner expected.  One (of many) issues was that for every “interesting” page (those that had link-worthy material), there were at least three URLs for that same content. Depending on how the user navigated the site, they’d get to a different URL.

I pointed out that this is a Bad Thing, since distributing the incoming links across those duplicates would decrease the Google-worthiness of each… but hadn’t had time to write up the detals.  Today I was thrilled to see this detailed writeup of the phenomenon and this one about how fix it.  I’ve done the same thing in the past, but never written it up.

If your site has this “feature”, and you would prefer it gets more traffic, fix it.