• The SaaS talk handout as a PDF
• The SaaS talk slides as a PDF (also shown below)
• Transcript of the Talk, with slides, as a PDF
• Audio recording of the SaaS talk

There is also a video recording, which I’ll add here if it come out well.

Reddit

I finally have the right opportunity to do so; later this month at the St. Louis Innovation Camp mini-conference I’ll give an updated talk on the same topic, on Friday, Feb 26, in a time-slot to-be-determined. The talk:

The Software as a Service Business Model

In this talk, I will share some “lessons learned” from five years operating a Software as a Service business. Topics will include:

• What is SaaS?
• Starting a SaaS business
• SaaS Product Management
• Cash Flow
• Customer Retention
• Infrastructure and Operations

Reddit

or for download as a PDF.

Reddit

I’m giving a talk (one of two) at the first meeting. Contrary to the initial description floating around, I won’t be speaking (in detail) about “Amazon Web Services from a Developer Perspective”. Rather, my talk will be broader, and from a developer+business perspective:

To the Cloud(s) and Back

Over the last few years, I’ve been to the Amazon cloud and back; on a real project I started with inhouse file storage, moved to Amazon S3, then moved back. I’ve likewise used EC2 and tried a couple of competitors. I think this qualifies me to raise key questions:

• Should you use (public) cloud storage? Why and why not?
• Should you use (public) cloud CPUs? Why and why not?
• How do you manage an elastic set of servers?
• Can you trust someone else’s servers? Can you trust your own?
• Can you trust someone else’s sysadmins? Can you trust your own?
• What about backups?

This talk will mostly raise the questions, then offer some insights on the some of the answers.

Update: Slides are online here.

Reddit

Appistry again provided space and pizza – thanks guys! (Appistry is our locally-grown but widely-known cloud infrastructure software maker – they’d been cloudy for years before the term entered wide use.)

The talk appeared to go over well. There were many important things about factor that I’d love to talk about but didn’t have time. Nonetheless, I think 45 minutes is a good talk length, and I think the format (short talks) is a key part to the Lambda Lounge’s success so far.

Speaking of the Lambda Lounge,  next month there is a “language shootout” – if you want to participate, be sure to join the mailing list and look over the participants. (You need to join the list, to be able to get to the wiki with that page.) I might submit an entry myself, using Factor or another language.

Reddit

Introduction and Agenda

Linus Torvalds wanted a replacement for BitKeeper. He wrote the first version of Git in a few weeks. A few years later, Git is now the leading contender among distributed source control tools: http://git.or.cz/

This will not be a typical “introduction” talk; there are ample introductions to Git on the WWW. Instead, I’ll wander through some source control use cases, pointing out Git features, strengths, and weaknesses along the way.

I use Git on both Linux and Windows, and I use both the command line and GUI tools. For this presentation, I will show how it works on Windows, and mostly use the included GUI tools.

We’ll end a bit early, to leave time for questions and ah doc demos.

Why Git?

Git promises to keep your files exactly as they are, and uses hashes to make it happen.

Git is very fast; speed matters a lot more than you might think.

Git is distributed and local, it works very well offline as well as online.

Git handles the realities of branching and merging.

Git has an enormous set of very useful features.

Git is clearly a tool made by people who love great tools.

Get Git

Deb/Ubuntu:   apt-get install git-core

Windows:        http://code.google.com/p/msysgit/

Version Some Files, Look at Them

git init                      git add                    git-gui

git commit                .gitignore                                gitk

Use Git with Eclipse

There is a git-Eclipse project in development:

http://repo.or.cz/w/egit.git

However, I will show how to use Git and Eclipse without any integration. This turns out to be much less problematic than you might initially guess, and has advantages:

If you use git with multiple IDEs, you only need to learn one interface.

You can use the tool in ways that the IDE does not anticipate, such as by versioning a whole workspace as a unit.

Branch and Merge

git branch                                git checkout -b newbranch

git diff                                     git merge

Rebase

The best thing in the world, a great capability.

The world thing in the world, never do this.

My advice: Have it in your toolbox, but be careful.

Review and Search History

The sample repos from tonight’s demo don’t have much history to show; but with git, and without relying on a network connection, we can see git’s review and search capabilities on projects “in the wild”.

Rearranging Files

Git tracks content, and will follow that content as it moves around, without you telling it about the moves. This is extremely helpful if you have a pile of files to rearrange.

http://kylecordes.com/2008/07/18/rearrange-file-svn-git/

Blame!

Poll: Do you use Blame? How often? Does it help?

Blaming is a terrible way to interact with other people… but get over the name, because “blame” is a fantastic source control feature.

Host Your Repo on Your Server

Git has a built in ability to host repos, and also includes gitweb.

Gitosis is also a great tool: http://eagain.net/gitweb/?p=gitosis.git

GitHub

Don’t want to mess with hosting?  http://github.com/

Enterpriseynessility

Git does not have all the same feature as whatever enterprisey tool you may be using. It has a different set of features. YMMV, but in my opinion it is a “disruptive innovation”.

Git-SVN

Git makes a great front end for SVN; I use it this way regularly on Linux. Msysgit does not currently include git-svn, so no demo.

Tips

Initial Setup:

git config –global color.diff auto

git config –global color.status auto

git config –global color.branch auto

export PS1=”\u@\h \W\$(git-branch 2> /dev/null | grep -e ‘\* ‘ | sed ’s/^..\(.*\)/ {\1}/’)\$ ”

Remove from source control, the files you have removed from the file system:

git ls-files -z –deleted | git update-index -z –remove –stdin

Using Git in a Closed Team

There are many ways to use Git; you can think of it as mostly a superset of what other systems do. You can use Git to achieve many possible workflows. Here is one way to use it effectively:

Set up a server everyone can pull from and push to.

Use Gitosis or similar.

Have one(+) repo per developer, and one(+) for leads to all push to.

Everyone pushes to their repo.

Leads pull from others’ repos, and push to the main repo.

Server performance is not important, a slow machine can serve many users.

Backup is not all that important, you will not actually lose anything if the machine dies.

Make your initial repo fork for each person, on the server, for speed and space sharing.

Using Git for Open Source

Clone the project’s repo.

Hack.

Push your changes to your public repo (perhaps on Github)

Get someone to pull them.

git format-patch, if you want to send them.

Problems in the Git World

On Linux, things are going very well. But on Windows, not so well: the Windows port itself  is advancing nicely, but it appears to suffer somewhat badly from the “I am just doing this for fun, if you want it fix, make a patch” problem.

My opinion: to really thrive on Windows, Git needs a firm to create a commercial offering around it, and feed lots of core fixes back to the project.

Reddit

How well you speak can have a great impact on  your ability to get customers, to attract employees, to persuade others to adopt your ideas, and much more. But how do you know how well you speak? You can’t tell as you are speaking; and if you’ve never heard yourself speak but simply assume you do well, there is a great risk that you are very, very wrong.

To become a better speaker, you need to review your own “performances”. For the last few years I’ve been recording my talks (at user groups etc.) with a hand-held voice recorder. I use an Olympus WS-100 (probably obsolete by now) and you can readily find an adequate device for $70 or less.

Make the Recording

Don’t actually hold the recorder on your hand. Sit it on the podium if you use one (I don’t care for podiums, I use one only if I am presenting with my computer and the podium is the only place to put the computer); but not to close to your noisy computer. Put it on a table or unused chair in the first row, but not too close to any noisy people or equipment.

Start it at the very beginning, and stop it at the very end. It is easy to edit out extra recording later.

Put in a fresh battery, so it doesn’t run out partway through.

Listen to the Recording

Take the recorder/player in your car, copy it to  your iPod, burn to CD, whatever… but listen to it, end to end. Experience your talk as a member of the audience. Make notes about any bad habits you exhibit, such as “umm”, “ahh”, “like”, “ya-know”, long (unintentional) pauses, pointless extra words, etc. This is your first opportunity to become a better speaker by means of the recording. WARNING! The first few times this might be very, very painful.

Edit the Recording

If you plan to post this audio online (as I usually do),  clean up the recording to trim off any extra starting and ending time; the audio you post should start immediately with your talk content and end crisply. Download Audacity (or another audio editing) and use it for this initial trim.

If you can spare the time (approximately 2x the length of the talk), listen through the whole recording in Audacity, trimming out the “umms”, “ahs”, overly long pauses, etc. This is your second opportunity to become a better speaker… but only for the offline listeners, and in an artificial, one-off way. Still, for an occasional important talk it is worthwhile.

Get a Transcript

Finally, be aware that your (now-pristine) audio is completely unsearchable and invisible to Google. To make it findable, have a transcript made and post that also. You can pay CastingWords or other similar service to create a transcript for around a dollar per minute, or perhaps much more cheaply with some searching. The resulting text can be readily posted online, making your talk both more findable, and more accessible.

An example of a recorded, lightly edited, and posted talk (with transcript) is my Ruby GUI talk earlier this year.

Reddit

Unfortunately I didn’t get an audio recording of this talk, so no transcript either.

About 30 people were in attendance. Nearly 100% were familiar with CVS and SVN, and perhaps 20% with other tools (ClearCase, SourceSafe, and others). Only 4 had ever used branch/merge in any project or tool!

A Brief Introduction to Distributed Version Control

You Branch and Merge.

A fundamental truth: every time you edit a file you are branching, and every time you reconcile with another developer you are merging. In most tools you get one easy branch and merge locus: your local working directory. All other branching is a Big Deal.

It does not have to be this way.

A Short Tour of 3 tools

bzr: http://bazaar-vcs.org/

hg: http://www.selenic.com/mercurial/

git: http://git.or.cz/

Also, check your distro’s package system.

(At this point in the talk I demonstrated the basic features of each)

What is a DVCS? Why Use a DVCS?

Peer-to-peer design

Everyone gets all the features, rather than the interesting features limited to a high priest class.

Make use of the massive CPU and disk capacity on dev machines.

No central server needed, though many projects nominate a machine for this purpose.

Use a “dumb” storage location for a repository, if desired. Or a “smart server” for performance and security.

Work offline, with full history, branches, merges.

No central administrator is needed, potentially a cost savings.

Very cheap branching, in some cases immediate, even for large projects.

Very good merging, because you merge all the time.

Commit-then-merge, not merge-then-commit.

Repeated merge without havoc.

Merge keeps both sides of history, which is important because you merge a lot. This varies by tools, for example apparently bzr keeps this history less effectively than some others.

Depending on what you are coming from and which tool you choose, the speed gain can be so remarkable that it help every developer every day.

Some SVN Nitpicks

It is easy and tempting to pick on SVN. Linus does so vigorously in his online talk. I don’t hate it as much as he does but, these things bother me:

SVN is slow for large projects.

Branching in SVN sounds clever as you read its cheap copy story. It’s a great story. But actually using it is ridiculous; both in the URL-crazy syntax and utter lack of merge history.

We don’t need a better CVS, we need something much better than CVS.

.svn directories scattered all over are a pointless pain.

.svn directories are enormous, sometimes larger than the entire project history in git or hg!

Security

Security is a weak area in terms of out-of-the-box features and tutorials, because these tools come from the open source world where the default is for everyone to be able to see all code. However, with a little effort you can set up whatever security you like:

If you’re serving over HTTP, you can use Apache mod_whatever to control access.

Tunnel over SSH (in the box, in most cases) to avoid ever sending code in the clear.

Even a “dumb” storage location can be secured with SFTP.

Scripts can be used for per-branch and other fine grained access control, akin to what you can do with svn-access.conf. There are examples online.

I Can’t Use a DVCS Because:

SOX/HIPPA/CMM/etc. requires a centralized tool.

SOX/HIPPA/CMM/etc, is the standard reason why anyone can’t do anything. Some of these tools facilitate much stronger guarantees about the provenance of the source code than you get from a centralized tool, because they have credible and straightforward ways to verify that centralized store has not been compromized.

We are all in one place, therefore a DVCS makes no sense.

Actually many of the features in these tools are as useful in the same building as in a worldwide team.

Tool ZZZ is our corporate standard.

Then you should use it, don’t get fired. However, many people are using a DVCS in front of their corporate standard tool.

DVCS vs DVCS:

Many DVCS tools treat each repo/workspace as a branch and vice versa, so if you use many branches you will have many workspaces.

bzr can use shared files to reduce the bloat from this.

git handles many branches much better, with arbitrarily many per repo/workspace.

My feeling is that hg and git are more mature than bzr.

git does not work well on windows yet.

Other DVCS to Consider

Monotone – has some slick features, but does not appear to scale well to large projects. It stores information in a SQLite DB. Monotone, unlike any others I’ve seen, replicates all branches by default, which is nice.

An aside — there are fascinating thoughts on how to a data synchronization system can work, in the Monotone docs / presentations.

arch / tla — one of the early DVCSs that started all this. I have heard it is mystifying to use.

darcs — everyone loves its “cherry picking”, but I have not triedit.

SVK — optimized for being a better svn client, with offline history and merging that works. Stores merge history in SVN attribute.

More git Merging

Depending on time, I will show more of the branch / merge facilities in git, as well as its gitk GUI.

Other Resources

http://wiki.sourcemage.org/Git_Guide

http://www.adeal.eu/

Update: the following appeared a few days after my talk, it is very good, aside from slightly bogus listings in the “disadvantages” section:
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

Reddit

When: October 10th, meeting starts at 6:30 PM

I’ll introduce distributed source control tools:

• A short tour of the basic use of git, bzr, and hg (Mercurial)
• Thoughts on why you’d want to use a distributed source control tool at all, vs. a centralized system like SVN or CVS.
• Some differences between these tools (and a few others), with thoughts on how to choose

In response to a question below about slides… most likely there will be no slides. Rather there will be a handout (which will be posted on my site).

Update: The handout notes are here. Sorry, no audio/video/transcript this time.

Reddit

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.

Selling your Software as a Service

Kyle Cordes
May 5, 2007

An Encouraging Idea

When you open up an IDE/editor at home, on your own time, you have a remarkable power in your hands: you can create something that you own (modulo some employment agreements). It is yours to sell, to give away, or to decline to do either, on your own terms. Likewise a company has this on a larger scale.

For the last few years my firm has been selling access to an application we wrote (and continue to write) as a service, charging a monthly fee for use, hosting, and support. I won’t name names or describe our product in detail (this talk is not spam), but I will share some things we’ve learned along the way.

What is SAAS?

Delivering a software product (especially a complex “enterprise” system, less so with consumer products) involves more than just bits in a file / on a CD-ROM:

1. Delivery of the deployable code

2. License (legal right to use it)

3. Hosting: hardware, deployment, and management thereof

4. Support for the server(s) / software on the servers

5. Support for the end users / software on their PCs or other devices

In a consulting or in-house project, the most common type of project for the audience here at Code Camp, you sell hours of labor to do the things above.

In a commercial software product company, you bundle #1 and #2 for a price, then perhaps sell a service contract for #4 and possibly #5.

With Software as a Service (SAAS) you bundle #1, #2, #3, #4, and possibly #5, then sell the result for a yearly / monthly fee times some measure of volume (per computer, per user, per transaction, per site, etc.). A company selling their software in this way is sometimes called an Application Service Provider.

The Business Model

From a business perspective, SAAS offers a recurring revenue stream rather than “spiky” up front sales. In the short term this can make higher investment demands (since the revenue arrives more slowly). In the long term, though, recurring revenues are very amenable to a sustainable ongoing business.

On the downside, as a SAAS vendor you are at greater risk of ongoing payments stopping, vs. up-front payments in full when the sale is made.

Collections are typically much less of a problem with SAAS: you will generally be paid by customers in a timely way (as they would pay for electricity, bandwidth, and other ongoing utility services).

This gradual arrive of revenues will shape your company’s financial decisions: you need to meter expenses to match.

Hosting

With SAAS, your customer stays out of the “hosting business”, but you get in to it. One way to offer reliable hosting is to put your servers in a colo facility; you can typically get a full rack (with power and bandwidth) for less than $1000 per month. This will provide redundancy in the power, air conditioning, and connectivity, which would be much more costly to provide in-house.

You will become experts in hosting, by experience. You will host more instances of your software than any one customer would, so you are in a better position to do a good job doing so.

Another route, for a smaller operation, is to rent a single dedicated server or even a “virtual” dedicated server. Or, go utterly virtual and use Amazon EC2 and S3 as your infrastructure.

Support / Operations

As an SAAS firm you can offer much more hands-on support than a traditional software vendor, because you have direct and immediate access to the production systems serving your customers.

At the same time, this access will expose your team to the customer’s pain points, making it more likely those problems are fixed soon.

With SAAS you can readily deploy updates regularly (weekly / monthly) at low cost, enable end-to-end agility. Paul Graham wrote about this in “The Other Road Ahead”.

What do customers like about SAAS?

Customer love not paying for unproven software up front, even if they have abundant cash and even if the software is in use elsewhere. They avoid making an unrecoverable investment in case their needs change or the software turns out to be inadequate.

Customers generally like not running a hosting operation: not operating a data center, not hiring employees for it, etc.

Customers benefit with SAAS’s easy scaling up or down as their needs grow and shrink. Financial decision makers often prefer costs that scale smoothly with business volume.

What do customers not like about SAAS?

Customer may be concerned that they have less direct control over an application supplied SAAS, than one hosted in-house, with less ability to persuade an operator/developer to drop everything and fix it now.

Eventually a customer may spend more with SAAS (at least in terms of the checks written to the software vendor, though perhaps not in total cost) than they would have spent buying a license up-front; thus they are prone to regret that they didn’t buy an up front license.

A customer may want to customize the software in a way the vendor does not offer.

Start Fast

SAAS provides considerable flexibility in delaying software work past the product launch; “admin” features can be less complete and more rough, if they are used primarily by the vendor’s staff instead of by the customer, and can require deeper system knowledge.

There is also a risk that the ability to get by with rough edges will too easily allow you to never truly finish the product.

What’s it like to sell software this way?

The biggest difference in selling SAAS is a more substantial long term relationship with the customer, both operationally and financially. This can be a great advantage – with a close customer relationship you will be in a position to understand their needs more fully, and innovate in your software to meet those needs better.

Customizations

The purest SAAS way to offer customizations is to not charge hourly / project fees for the changes, but rather to invest in the desired enhancements then charge a higher ongoing price for the enhanced system. Hybrid customization payments are also possible, combinations of customization fees and monthly costs. Be sure your customer understands that paying for a customization, does not grant ownership of the underlying system.

Intellectual Property

While an SAAS firm usually owns (or licenses) its software, customers should own their data (and have access to a copy of the raw data, if they ask for it). Hire a lawyer to work out the details.

Go to great lengths to keep customer data separate: you must make sure to never, even briefly or accidentally, give one customer access to another customer’s data. For small, cheap services, WHERE clauses are OK for this, but for large expensive services, use (at minimum) separate databases and server code instances, and perhaps even separate hardware.

Reddit