Posted by Ryan Boyd, Google Apps Marketplace Team
Want to weigh in on this topic? Discuss on Buzz
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
<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 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
