I couldn't read all of it but I am giving you a +1

And about the wired magazine link, I thought I was the only one who
insult people/companies with pretty urls, but theirs is very very
harsh

On Jul 2, 8:22 am, zdravko <[email protected]> wrote:
> Hi folks,
>
> With regard to the newly proposed GAE pricing changes and other
> related issues ...
>
> IMHO, A this point the minimum honorable thing that GOOG could do is
> to take a gradual phasing in approach along these lines:
>
> a) For the first 3 months, continue charging the old way, while in
> parallel showing what the costs would amount to under the new scheme.
> This would give everyone a chance to see what they will be facing and
> a bit of time to do at least some initial tinkering and refactoring of
> their apps.  I would be surprised to learn that they have not already
> been doing this sort of comparison.  Otherwise, it would mean that
> they did bulk analysis of resources vs revenues and that they
> themselves have no idea how many customers will end up being
> negatively impacted - in which case, it would be just as valuable for
> them as it would be for their clients.
>
> b)  Thereafter, they should start billing according to both schemes,
> where in the first month the customer pays 90% of old & 10% of new
> charges.  The next month it would be 80/20 and so on.  Furthermore,
> they should ensure that for a full year, no customer ends up paying
> more than twice the cost of what it would have been the old way.  The
> reason why they should do at least this much is to make up for *sucker
> punching* everyone - which I will explain.
>
> GAE is not the only way by which GOOG has *sucker punched* the
> developer community because they have already done the same thing with
> the Translation API and just about all other "data retrieval" API.
> The reason why I believe that they have *sucker punched* everyone is
> because it turns out that they have done some quite amazing things,
> either by design or with total disregard to its developer community
> and/or with total disregard to some very basic realities.
>
> It is an economic reality that there was never a way for them to make
> any money with any of the data retrieval or data "transformation"
> API's such as Translation API.  So, what were they thinking or were
> they thinking at all, when they offered such services in the first
> place?  How did they ever hope to make such services economically
> viable when such API services do not provide means for things such as
> ad insertions?  While GOOG has the right to make a profit with
> everything that it does, it has *NO* right (not in the past, not now
> and never in the future) to offer developers what amounted to a "free
> lunch" because too many developers ended up investing their time and
> effort, based on that silly "free lunch" premise.  While many of us
> developers are not too savvy when it comes to issues such as having
> economically viable revenue models, GOOG on the other hand is lot more
> sophisticated and it should have known better from the very beginning.
>
> When Translation API user community cried foul, GOOG knee-jerk reacted
> with a promise that they will offer a paid subscription.  Great !?!
> NOT REALLY !  The problem is just that, in that it was a knee-jerk
> reaction because most developers will not be able to generate enough
> revenue to pay for such services - no matter what they price it at.
> There is a solution that apparently they have not even considered.
> They could have helped those developers in ways by which the
> developers could have displayed advertising within their apps and with
> that ad revenue, maybe they could end up covering at least their
> costs.  However, even with that there would be a huge problem because
> GOOG seems to do nothing that does not scale well without requiring
> lots of human intervention such as reviewing apps for compliance, etc.
>
> Here is a really fantastic article which deals with some of these
> "automated scalability" 
> issues.http://www.wired.com/magazine/2011/03/mf_larrypage/all/1
>
> When all is said and done, has GOOG even bothered to come out and
> state how much more revenue are they trying to generate with the new
> pricing scheme.  Is it 10% or 50% or 100% or 500% or more?  If they
> stated that much and if they gave us 3 months of new billing data
> (before new billing kicks in) then everyone would be able to see if
> they are edge case exceptions or whether they fall in-line to that
> stated average revenue increase goals.
>
> Now, while they have either been totally irresponsible or perhaps they
> just made a callous revenue projection mistakes, the problem is that
> they are evidently continuing to do more of the same with the "free"
> quota offerings.  The fact of life is that while there is no "free
> lunch", GOOG continues to make believe the developer community that
> there is.  It would be interesting to know just how much of the
> overall resources are being eaten by their "free" offerings.  In other
> words, how much of that "free lunch" is factored into the new pricing
> and with that, how much of GOOG's research and development (yes,
> research into what types of apps can be economically viable) and how
> much of their overall business development is being funded by the
> proposed pricing increases?
>
> If I did not know any better or if I did not have too much faith in
> GOOG thus far, I might be inclined to think that most of this mess was
> by design - by which they used the developer community to do just that
> - to flush out and even to poach great ideas that had no hope on their
> own but core of which would indeed be viable within GOOG itself.
> Please tell me that I am totally wrong, before real disillusionment
> sets in.
>
> Sincerely,
> zdravko

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

Reply via email to