mgk

Our main product is a desktop application built on top of the Firefox web browser. It is triple licensed GPL/LGPL/MPL. We make money by selling add-ons and a plus version, all of which is also sold under an OSS license (modified BSD). Similar to what Red Hat does, we modified the BSD to prohibit the use of our trade name (International registered wordmark) in any secondary distros of our OSS. In the end, all you have is a brand. Protecting that, protects the revenue stream.

When we launched our commercial SaaS, we initially offered an annual payment only, but ended up adding monthly options in response to user requests. Students, in particular, wanted a monthly option, so you might want to keep in mind the age demographic of your users.

The monthly was priced so the annual provided a 17% discount. At first, the split was 1/3 annual and 2/3 monthly, but this migrated over the past year to the current 50-50 (we expect this to revert back to the 1/3-2/3 split once the schools fire back up).

In the meantime, we added two other offerings, one of which was a set of virtual goods that could be bought separately or as a bundle, and the other were add-ons that augment the basic desktop app. These are one time purchases.

The combination of offering both subscription based services and one off purchases has worked well, with each model generating 1/3 of our revenue (the other 1/3 comes from a mobile app).

We often see users tip their toes in to the water by buying one of the lower cost "one off" items, and then come back later to buy more and sign up for the subscription service. Having a low cost item for sale seems to provide a mechanism for the buyer to check out the process before committing to a larger and/or repeating purchase.

This should be a non-brainer – ie. catering to the non-English users of the Web.

I wish I could say we were smart enough to have taken that in to account when we started, but, like most, we were oblivious to the fact, and only ended up awakening to the opportunity by virtue of our community leading the way, with their use and volunteer localizations of our offering.

At this point, about 50% of our users are non-English (our offering is available in 30 languages - again, all localized by volunteers).

We are monetizing in 40 countries, using PayPal to sell low cost subscription based web services and virtual goods. In order of sales - US, UK, Canada, Italy, Germany, Spain, Japan, France, and Brazil.

So, my best advice to all those running a start-up - think global. You will be able to monetize once you get there.

Done!

We just went through this.

We decided to charge in USD. We have a lot of international users, and while people generally know where their own currency stands vis a vi the Greenback, we surmised that they wouldn't be nearly as familiar with where they stand against the Loonie.

We initially went with the Canadian cc processor Moneris. They support recurrings, although their API support sux. Watch out too for the application approval process which was v slow and v painful.

We do not see the cc numbers. They are passed along to Moneris directly.

Moneris could only support Visa and MC transactions for USD, which was pretty limiting (credit cards are not used nearly as much in countries like Germany and Brazil) so we also went ahead and hooked up a pay by Paypal.

Shortly after we set everything up, Paypal started offering its cc processing service to Canada. They have much better API support then Moneris (although PP’s web UI sux), and since we had already set up the PP payment option, it was a no brainer to move it all over to PP. So PP now processes our cc as well.

Similar to Moneris, we do not see the cc numbers at all. They are passed along to PP directly.

(We took a look at Amazon, but they were not offering their 'Easy Pay' service in Canada.)

If you are a Canadian registered, there is no need to worry about US taxes.

Thanks much to you (and dtf) for the feedback. Really appreciated. We don't get a lot of press (you'd think that whoever wrote the piece about open source media apps would have at least Googled around a bit beforehand...), but the WOM is working nicely.

Shameless plug time.

www.celtx.com - Open source pre-production application for making films, stageplays, audio, AV and comics (so far).

Use a name that doesn't mean anything.

It will violate the branding law that a name should impart some sense of what the product/service does, but I think it's worth sacrificing that dogma in favor of having a name that: 1. Will derive a decent Google search without having to fool with any SEO stuff. 2. Work internationally. 3. Will be distinctive. 4. Will provide the flexibility you'll need as your product/service evolves over time.

After wasting a ton of time trying to come up with a name, we took the first letter of four key words that were relevant to our software, stuck them in to scrabble dot com, got some suggested words, one of which was pithy and sounded OK, and then stuck a 'x' on the end to make it unique.

The dot com is easy if it's made up.

The best I've read wasn't a strategy book per se. 1776 - http://www.amazon.com/1776-David-McCullough/dp/0743226712 by David McCullough was full of useful insights on General George Washington and how he used his smarts to defeat the enemy. He wasn't a great strategist, but very pragmatic (like counting the number of shoes on the feet of his “army’ to asses their battle readiness) and willing to take risks. It book was also entertaining as Hell.

celtx - www.celtx.com - a media making app, is built on top of FF (just about to be ported to the 3.* code base).