Selling App Engine Apps

192 views
Skip to first unread message

Timofey Danshin

unread,
Jan 18, 2010, 10:41:17 AM1/18/10
to google-appengine
Hi. I've written a decent web-app on app-engine. Do i have the right to sell it to others? I mean, not the source code, but install the app onto their app engine accounts?

Thank you in advance,
Best Regards, 
Timofey Danshin.

Nick Johnson (Google)

unread,
Jan 18, 2010, 10:47:18 AM1/18/10
to google-a...@googlegroups.com
Hi Timofey,

You own the app, so you're welcome to do anything you like with it as long as it's not in violation of our TOS. If they add you as an administrator on an app they've created, you can, of course, deploy your app to it.

-Nick Johnson

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.




--
Nick Johnson, Developer Programs Engineer, App Engine
Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047

bFlood

unread,
Jan 18, 2010, 12:05:56 PM1/18/10
to Google App Engine
hi Timofey

that is how we will be deploying our app. Users add a specific email
address as a developer and then we load/maintain the source code
remotely. A simple cron request makes a call back to our controlling
app (on GAE) so we can change limits, upgrade features or turn off the
remote app (in the event they subsequently remove the developer email
account and stop paying). There are probably many other ways to combat
this issue

this setup works well in practice. The user pays Google directly for
usage and then licenses the software from us. It turned out to be a
lot easier then running it as a service (single GAE app) and having to
be the middle-man between the user and Google. Trying to estimate how
they would be billed per month was difficult and seemed like a
duplication of the existing infrastructure. Also, a flat fee might
have been more profitable (or not) but IMO does not play to one of
GAE's biggest strengths, true utility billing.

of course, this all breaks if Google decides to allow code downloads
in the future but we'll cross that bridge if and when we come to
it :)

cheers
brian


On Jan 18, 10:47 am, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:


> Hi Timofey,
>
> You own the app, so you're welcome to do anything you like with it as long
> as it's not in violation of our TOS. If they add you as an administrator on
> an app they've created, you can, of course, deploy your app to it.
>
> -Nick Johnson
>
> On Mon, Jan 18, 2010 at 3:41 PM, Timofey Danshin

> <rus.mcdevelo...@gmail.com>wrote:


>
>
>
>
>
> > Hi. I've written a decent web-app on app-engine. Do i have the right to
> > sell it to others? I mean, not the source code, but install the app onto
> > their app engine accounts?
>
> > Thank you in advance,
> > Best Regards,
> > Timofey Danshin.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google App Engine" group.
> > To post to this group, send email to google-a...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>

Nick Johnson (Google)

unread,
Jan 18, 2010, 12:40:44 PM1/18/10
to google-a...@googlegroups.com
Hi Brian,

On Mon, Jan 18, 2010 at 5:05 PM, bFlood <bflo...@gmail.com> wrote:
hi Timofey

that is how we will be deploying our app. Users add a specific email
address as a developer and then we load/maintain the source code
remotely. A simple cron request makes a call back to our controlling
app (on GAE) so we can change limits, upgrade features or turn off the
remote app (in the event they subsequently remove the developer email
account and stop paying). There are probably many other ways to combat
this issue

this setup works well in practice. The user pays Google directly for
usage and then licenses the software from us. It turned out to be a
lot easier then running it as a service (single GAE app) and having to
be the middle-man between the user and Google. Trying to estimate how
they would be billed per month was difficult and seemed like a
duplication of the existing infrastructure. Also, a flat fee might
have been more profitable (or not) but IMO does not play to one of
GAE's biggest strengths, true utility billing.

of course, this all breaks if Google decides to allow code downloads
in the future but we'll cross that bridge if and when we come to
it :)

We're well aware of this use case. If we ever did add support for downloading code (we have no immediate plans to), it would be with this in mind.

Bear in mind, though, that your users having your source code does not prohibit you licensing it to them!

-Nick
 
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.



Timofey Danshin

unread,
Jan 18, 2010, 2:23:35 PM1/18/10
to google-a...@googlegroups.com
Thank you for your replies. They were most helpful.
I didn't quite understand the "download source code" part. I never gave it a thought before, but does that mean, that the applications are deployed to the server along with the source code (which, probably, would be logical, since they could be compiled there), or are they compiled locally and then deployed as bytecode only?

2010/1/18 Nick Johnson (Google) <nick.j...@google.com>



--
Best Regards,
Timofey Danshin.

Eli Jones

unread,
Jan 18, 2010, 2:44:23 PM1/18/10
to google-a...@googlegroups.com
Timofey,

I'm not sure how App Engine stores the applications on the server, but my assumption is that Nick means that (in the future) there may be some option in the app.yaml (like "source_download: yes") and there would be some link on the Dashboard page that you could click to get the source as long as the flag was set to "yes".

A lot of people seem to want source download, but I can think of a lot of others (myself included) who do not really want our readable .py files to be easily accessible.

I use Mercurial version control to keep track of my source code.. no need for some dinky download source link.

Timofey Danshin

unread,
Jan 18, 2010, 3:52:55 PM1/18/10
to google-a...@googlegroups.com
Oh, i see. 
I forgot that there was Python app-engine as well :) I am writing in Java. 

2010/1/18 Eli Jones <eli....@gmail.com>

Andrew Chilton

unread,
Jan 19, 2010, 1:56:30 AM1/19/10
to google-a...@googlegroups.com
Hi bFlood,

2010/1/19 bFlood <bflo...@gmail.com>:


> that is how we will be deploying our app. Users add a specific email
> address as a developer and then we load/maintain the source code
> remotely. A simple cron request makes a call back to our controlling
> app (on GAE) so we can change limits, upgrade features or turn off the
> remote app (in the event they subsequently remove the developer email
> account and stop paying). There are probably many other ways to combat
> this issue

Wow, cool. I've been thinking of setting up one app for a while and
letting other Google Apps just add it via their accounts. Separating
data for each mapped domain seems to be easy enough, but letting lots
of people from different Google Apps Domains log in seems to be the
hardest thing to do (so your suggestion above seems to get around
this, thanks).

For more information about my login issues/problems, see:
http://groups.google.com/group/google-appengine/browse_thread/thread/a71984d787536d82/d64828849b924b83

Further to this, I tried OpenID and the federated login, but it seems
the IDP stuff (or whatever it is extra in the federated login
(discovery?)) isn't liked by the Python OpenID library (yet?). It
makes me sad this is so hard to set up. It seems the Google Labs
ShortLinks service somehow works exactly how I would like mine to but
I'm yet to find an answer as to how they did it. If anyone knows, I'd
be very grateful :)

> this setup works well in practice. The user pays Google directly for
> usage and then licenses the software from us. It turned out to be a
> lot easier then running it as a service (single GAE app) and having to
> be the middle-man between the user and Google. Trying to estimate how
> they would be billed per month was difficult and seemed like a
> duplication of the existing infrastructure. Also, a flat fee might
> have been more profitable (or not) but IMO does not play to one of
> GAE's biggest strengths, true utility billing.

Maybe this is the way forward for me. I guess there is also some way
to remotely disable the app (e.g. when their license is up) since
otherwise the user could just disable your access to the AppEngine
control panel. I guess your application has something like this in it?
Of course, this solution doesn't scale for hundreds or even thousands
of users so I'm kinda hesitant to do it. I'd love if you could
reassure me it can be done. :)

Cheers,
Andy

--
contact: Andrew Chilton
website: http://www.chilts.org/

bFlood

unread,
Jan 19, 2010, 8:38:39 AM1/19/10
to Google App Engine
hi andy

openid - I really wish Google would just build support for
FriendConnect directly into GAE. I don't have a good answer for you
right now, maybe someone else has done this already. that being said,
Nick built the very useful AEoid plugin: http://bit.ly/75CEy5

remote disable - there's actually two kill switches in our app but
there are probably others you could use. I'm leaning towards 1 now,
its more flexible
1) a cron job contacts our controlling GAE app, it can tell the app to
shutdown. this controlling app has a simple web UI where we store
client information (for instance, our 3rd party purchasing service
Avangate contacts this server with any online purchases for all
relevant accounts). Out clients cannot disable cron jobs and they
cannot see the urlfetch requests to the controlling app (although I
suppose Google could update the UI for this at some point)
2) we will be automating deployment using a native app on EC2. It
powers appcfg.py using additional metadata for each known instance.
Since this is automated, an extra site_config.txt file is (re)written
for each deployment. This file contains license info and a validity
date so the killswitch is hard-coded (note - the only way to update
this file is via appcfg, so if you need more flexibility, the cron
request route may be easier)

and finally, I forgot to mention another pro/con of this setup.
1) since all of our clients have their own GAE app, they also have
access to their own GAE free daily usage limits. Running this as a
service would have eaten these limits up very quickly (we are dealing
with a lot of data) but now they are spread evenly over each client.
over the course of a year, this is significant (although I'll have
better metrics as this year progresses)
2) conversely, each client then has to deal with the dreaded "cold
start" issue. The significance of this widely depends on how their
data is being accesses but I still think it's the biggest issue with
GAE right now (Nick - did I read correctly on the GAE-Java forum that
their instance should be keep alive for an *hour*?)

cheers
brian

On Jan 19, 1:56 am, Andrew Chilton <andychil...@gmail.com> wrote:
> Hi bFlood,
>
> 2010/1/19 bFlood <bflood...@gmail.com>:


>
> > that is how we will be deploying our app. Users add a specific email
> > address as a developer and then we load/maintain the source code
> > remotely. A simple cron request makes a call back to our controlling
> > app (on GAE) so we can change limits, upgrade features or turn off the
> > remote app (in the event they subsequently remove the developer email
> > account and stop paying). There are probably many other ways to combat
> > this issue
>
> Wow, cool. I've been thinking of setting up one app for a while and
> letting other Google Apps just add it via their accounts. Separating
> data for each mapped domain seems to be easy enough, but letting lots
> of people from different Google Apps Domains log in seems to be the
> hardest thing to do (so your suggestion above seems to get around
> this, thanks).
>

> For more information about my login issues/problems, see:http://groups.google.com/group/google-appengine/browse_thread/thread/...

Andrew Chilton

unread,
Jan 19, 2010, 9:29:51 PM1/19/10
to google-a...@googlegroups.com
Hi Brian,

2010/1/20 bFlood <bflo...@gmail.com>:


> openid - I really wish Google would just build support for
> FriendConnect directly into GAE. I don't have a good answer for you
> right now, maybe someone else has done this already. that being said,
> Nick built the very useful AEoid plugin: http://bit.ly/75CEy5

Yep, I've seen Nick's OpenID and I do have a question for him
(probably in a different channel somewhere). Essentially it's OpenID
but of course the Google Apps Hosted OpenID has extended discovery
which I don't think (or can't get) the Python OpenID library to do.

Anyone had any success doing this? Especially with the endpoint
https://www.google.com/accounts/o8/site-xrds?hd=example.org

> remote disable - [snip]

Thanks for your descriptions Brian, they were pretty helpful
(especially from someone actually doing it). I still really want to
just have one app with proper login from their own Google Apps but
still haven't come across a solution to do it!

Nick Johnson (Google)

unread,
Jan 20, 2010, 5:23:48 AM1/20/10
to google-a...@googlegroups.com
Hi Andrew,

On Wed, Jan 20, 2010 at 2:29 AM, Andrew Chilton <andyc...@gmail.com> wrote:
Hi Brian,

2010/1/20 bFlood <bflo...@gmail.com>:
> openid - I really wish Google would just build support for
> FriendConnect directly into GAE. I don't have a good answer for you
> right now, maybe someone else has done this already. that being said,
> Nick built the very useful AEoid plugin: http://bit.ly/75CEy5

Yep, I've seen Nick's OpenID and I do have a question for him
(probably in a different channel somewhere). Essentially it's OpenID
but of course the Google Apps Hosted OpenID has extended discovery
which I don't think (or can't get) the Python OpenID library to do.

That's a good point. I'm not sure if the janrain openid library supports XRDS. Feel free to file a bug against aeoid, especially if you discover more details.

-Nick Johnson
 

Anyone had any success doing this? Especially with the endpoint
https://www.google.com/accounts/o8/site-xrds?hd=example.org

> remote disable - [snip]

Thanks for your descriptions Brian, they were pretty helpful
(especially from someone actually doing it). I still really want to
just have one app with proper login from their own Google Apps but
still haven't come across a solution to do it!

Cheers,
Andy

--
contact: Andrew Chilton
website: http://www.chilts.org/

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.



Rajkumar Radhakrishnan

unread,
Sep 8, 2011, 4:06:30 AM9/8/11
to google-a...@googlegroups.com
Updating this thread with a link to related feature request : Marketplace for Google App Engine apps, so that you can star it if you are interested in selling app engine apps in a cleaner way.

Thanks & Regards,
R.Rajkumar
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Build online database applications, over Google App Engine.
iFreeTools Creator - http://creator.ifreetools.com


Reply all
Reply to author
Forward
0 new messages