Since launching the Apps Marketplace back in March, we’ve been heads down working on our Marketplace billing API, which is based on Google Checkout. The goal of the API is to make it easy for Marketplace vendors to sell their installable applications to Google Apps customers, using either a subscription model or one-time payment, and accommodating both free trial and freemium pricing plans. We are excited to get it in to developers’ hands.Our current plan is to release it in Q4 for US sellers, and then expand to other seller countries in the following months. Please see our FAQ for more information on supported countries, and watch this blog or sign up to our email announcement list to be notified of changes.Marketplace Payment Policy UpdatedAs a reminder, our Marketplace payment policy launched with a revenue sharing exemption period, which lasts until 3 months after the release of these billing APIs. Upon expiration, all installable apps sold through the Marketplace are required to integrate with these billing APIs and bill new customers acquired through the Marketplace exclusively through these APIs.However since our seller country list is may be smaller than the list of countries where our vendors are located, we have updated our payment policy to extend the revenue sharing exemption period until 3 months after it is released in a country where you are located.Put more concretely, if you are a Google Apps Marketplace vendor located in Australia or India or any other country not currently on our seller list, your revenue sharing exemption period remains in effect until 3 months after the billing API supports your country.We encourage you to read the payment policy in full to make sure you understand it, and consult our FAQ for more information. Note that the availability of the revenue exemption, including the determination of where a developer is located for purposes of the exemption, is entirely at our discretion.
Posted by Tim Grow, Google Apps Marketplace Product Manager
Want to weigh in on this topic? Discuss on Buzz
<link>
Posted by Steven Bazyl, Google Apps Marketplace Team
In the last 5 months, we've worked with over 150 companies who have launched apps in the Google Apps Marketplace. In our conversations with developers, marketing teams, and business execs, it's become clear we would all benefit from a wider conversation and debate -- beyond one-on-ones.So we took the logical next step and created an email-based Google Apps Marketplace forum, and then embedded it in our documentation and program sites so it’s easier to find. Starting today, it's the best place we know of to engage folks in the Apps Marketplace community to discuss trends, pricing models, brainstorm features, or just gripe about stuff.Join the forum and dive in!But wait, there’s moreThere’s a wider Google Apps solution provider community beyond Marketplace developers however. Google Apps resellers, integrators, and consultants are equally passionate about innovating with customers in the cloud. And here at Google, we’re growing an equally passionate team to work with you all, our extended community.But our team has a problem: we have a lot of news and observations to share, large and small, but no good way to share them in a way that enables an easy conversation. You know, Twitter-style, but with the ability to actually find the comment thread that develops around an interesting post. So we created a Google Apps Ecosystem team Buzz stream for that very purpose.Follow us on Buzz and share your thoughts in the comments!We like shaking hands tooWe love the Internet, but sometimes we would rather meet face-to-face. We do that too when possible. For example, we recently held a Google Apps Hackathon here in Mountain View, where dozens of cloud app developers, IT developers and systems integrators joined together to code and learn about Google Apps APIs.We kicked of the day with great presentations by Jeremy Glassenberg of Box.net on their Marketplace app, and Chris McGarry and Neel Patel from Omnetic talking about opportunities for system integrators to build on and extend Google Apps. There was strong interest in the 9 short technical side sessions on many of our APIs, though a little less coding than expected. Our quick survey of attendees gave us some great feedback, so we plan on iterating and doing more in the future.So please do reach out, both to us here at Google as well as your fellow community members, using these new virtual water coolers.Posted by Scott McMullan, Google Apps Partner Lead
By Jeff Morgan, Senior Technical Consultant at Appirio
$oauthOptions = array( 'requestScheme' => Zend_Oauth::REQUEST_SCHEME_HEADER, 'version' => '1.0', 'signatureMethod' => 'HMAC-SHA1', 'consumerKey' => $CONSUMER_KEY, 'consumerSecret' => $CONSUMER_SECRET ); $consumer = new Zend_Oauth_Consumer($oauthOptions); $token = new Zend_Oauth_Token_Access(); $httpClient = $token->getHttpClient($oauthOptions); $service = new Zend_Gdata_Gapps($httpClient, $domain ); $users = $service->retrieveAllUsers();
Posted by Zhenya Grinshteyn, Expensify
Posted by Ryan Boyd, Google Apps Marketplace Team
Posted by Don Dodge, Google Apps Team
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
