The Freemium business model is normal for consumer applications, but can it work for enterprise software? Freemium usually means a free service with an "up sell" to paid premium subscriptions. Examples include Skype, LinkedIn, Flickr, Ancestry.com, Typepad, Dropbox, and many others. Freemium differs from Free Trial in that a free trial is the fully functional product but only for a limited time. Freemium is always free, but you can purchase additional features or service for a premium price.
Freemium business models usually involve a Free service, sometimes time limited or feature limited, supported by advertising. The ads rarely cover costs. The goal is to convert these free users to paid subscriptions. Most consumer services start with a $10 per user per month subscription and scale up to $20 or $50 per month based on a small, medium, large usage scale.
Enterprise software is also using the Freemium model, sometimes with higher prices commensurate with the power and functionality of the product. They all have slightly different measurements and cut-off points, but most have some notion of small, medium, large.
Most companies see a 1.5% to 5% conversion rates, with most of them averaging around 3%. That doesn't sound like much but they are reaching tens of thousands to hundreds of thousands of users...sometimes millions.
Here is some math. 100,000 free users convert to 3,000 paid users. If they pay $50 per user per month, that is $150K a month or $1.8M per year. That is an excellent revenue stream for small startups that typically have 3 to 5 employees. And, it is an annuity stream that continues to grow every year. By the 3rd or 4th year these small companies can be generating $5M to $10M a year, still with less than 10 employees. Most of these small companies don't take Venture Capital so they own the whole company. It is a pretty good cash flow business.
Recently at Google IO I moderated an all-star panel of VCs on the subject of Freemium in the enterprise.Making Freemium work - converting free users to paying customers - Venture Capitalists, Brad Feld (Foundry Group), Dave McClure (500 Startups), Jeff Clavier (SoftTech VC), Matt Holleran (Emergence Capital) and Joe Kraus (Google Ventures) discussed strategies for building free products that can be upgraded to paid versions.
Some key points from the panel;
Watch the video for more details and insight. This group of VCs has built lots of companies based on the Freemium business model. They have some great insights.
The programming language of Google Apps Script is JavaScript (ECMAScript). JavaScript is a very flexible and forgiving language which suits us perfectly, and there's also a surprising amount of depth and power in the language. To help users get into some of the more useful power features we're starting a series of articles introducing some more advanced topics.
Let's say we want to create an object that counts the number of occurrences of some event. To ensure correctness, we want to guarantee the counter can't be tampered with, like the odometer on your car. It needs to be "monotonically increasing". In other words, it starts at 0, only counts up, and never loses any previously counted events.
Here's a sample implementation:
Counter = function() { this.value = 0; };
Counter.prototype = { get: function() { return this.value; }, increment: function() { this.value++; } };
This defines a constructor called Counter which can be used to build new counter objects, initialized to a value of zero. To construct a new object, the user scripts counter = new Counter(). The constructor has a prototype object, providing every counter object with the methods counter.increment() and counter.get(). These methods count an event, and check the value of the counter, respectively. However, there is nothing to stop the script from erroneously writing to counter.value. We would like to guarantee that the counter's value is monotonically increasing, but lines of code such as counter.value-- or counter.value = 0 roll the counter back, breaking our guarantee.
Most programming languages have mechanisms to limit the visibility of variables. Object-oriented languages often feature a private keyword, which limits a variable's visibility to the code within the class. Such a mechanism would be ideal here, ensuring that only the methods counter.increment() and counter.get() could access value. Assuming that these two methods are correctly implemented, we can be sure that our counter can't get rolled back.
Javascript has this private variable capability as well, despite not having an actual keyword for it. Let's examine the following code:
Counter = function() { var value = 0; this.get = function() { return value; }; this.increment = function() { value++; }; };
This constructor gives you objects that are indistinguishable from those built with the first constructor, except that value is private. The variable value here is not the same variable as counter.value used above. In fact, the latter is undefined for all objects built with this constructor.
How does this work? Instead of making value a member variable of the object, it is a local variable of the constructor function, by use of the var keyword. The get and increment functions are the only functions that can see value because they are defined within the same code block. Only code inside this block can see value; outside code does not have access to it. However, these methods are publicly visible by having been assigned to the this object.
Limiting visibility of variables is considered a good practice, because it rules out many buggy states of your program. Make sure to use this technique wherever possible.
Cross-posted from Google Apps Script Blog
by: Jason Ganetsky, Software Engineer, Google Apps Script
Editor's Note: Jeff Bonforte is CEO at Xobni. Xobni gives you instant access to email, contact information, conversations and attachments that are often lost in exploding inboxes. Xobni has leveraged Gmail Contextual Gadgets to make your email more responsive. We invited Xobni to share their experience with the Gmail Contextual Gadgets.
The new Gmail contextual gadgets platform announced at I/O last month is bringing renewed innovation to the inbox. Using this new simple but powerful platform, developers can write new innovative gadgets for users of Google Apps and Gmail. But to offer the same gadgets to Outlook’s 600 million users, a developer would need to do quite a bit of extra work.
They would need to be very familiar with COM, know about CBT hooks, have mastery of runtime callable wrappers (RCWs) and Outlook’s primary interop assembly (PIA). They should know MAPI inside and out. They should be experts in Windows forms and Redemption. They should understand the requirements of the new 64-bit support needed for Outlook 2010. They should understand the nine APIs of Outlook, including OOM (introduced in 2007) and OSC (introduced in 2010). They should develop in .Net, and have a massive variety of QA virtual machines running every version of Win XP to Win 7, with every version and service pack of Outlook 2003 to 2010, including a large variety of the top 400 add-ins to Outlook, and every version of Redemption (running with each version installed in various order to trap on likely conflicts).
And even the most experienced engineer in these technologies will need to reference Charles Petzold’s seminal Programming Windows 95 (out of print, 1996, Microsoft Press) and De la Curz Thaler’s Inside MAPI (out of print, 1996, Microsoft Press).
Given these non-trivial hurdles, we were pretty sure most developers would forgo the opportunity to offer their clever new gadgets to Outlook’s millions of users. That is a shame.
So we got on the case to bring this innovation from Gmail gadget developers to Outlook users. Enter Xobni.
Xobni, (“inbox” spelled backwards) is a San Francisco startup that offers and easier and better way to manage the people and information in email and on your phone. Our free Outlook search and contact manager add-in for Outlook has been downloaded over five millions times in the last two years. We focused early on Outlook for two simple reasons: size and pain.
When the team at Google called to encourage us to bring our Xobni app to Gmail in time for Google I/O, we were thrilled. It has long been the #1 request of our customers…and engineers. It didn’t take much work for us to realize the simplicity and power of this platform. In fact, we had our first gadget for Hoover’s business information written in about a day. Though we are excited to write gadgets, we wanted to do something bigger. We wanted Gmail gadgets to run natively for the millions of people using Outlook.
So we set out to port over Google’s platform to Outlook in a ridiculously short amount of time. The first step was to get Google on board. We weren’t sure what to expect from them when we explained our plan. The first response we got from the Google team was puzzlement. Why and how would we do this? In a short amount of time, Google’s mood progressed from quiet to excited (phew). So we set up the war room in the office, cleared our calendars and weekends for the foreseeable future and started cranking away. (And, yes, even with our Outlook expertise, we frequently referenced Programming Windows 95 and Inside MAPI along the way.)
The result: Developers can now write one application for Gmail contextual gadgets and will soon deploy not just to the millions of Gmail users, but also to the millions of Outlook users: the same code available in both worlds. Thanks to Google’s simple but powerful platform (and the hard work of Xobni’s engineers), you just write your gadgets for Gmail and they are ready to be used in Outlook as well.
Want to get started? Download the Xobni for Outlook Developer Preview today. It includes a “Welcome Gadget” with sample code, so you can see your Gmail gadgets in Outlook. We plan to release an updated version of Xobni that will allow end users to start enjoying your gadgets.
We’d love to hear from you. Let us know what you think and how we can continue to make email a better place to be.
Author: Jeff Bonforte, CEO Xobni
