Hello, just my thoughts on google and beta products for developers, Google has historically used an approach of rapid early releases and then rapid improvements.
Their strength is the speed at which they can innovate, because they don't need to manage client software. (Compare MS release cycle with Googles). However, when people are building technologies on beta releases, there is a serious tension between getting something in peoples hands, and making it clear what the offering is. At the beginning they don't really know what the offering is. Google is like many tech companies, some of its lofty ideas don't do as well in the market. (Hi Wave and Buzz!). So it must be difficult when they release an early tech as a beta, not sure of exactly how it will be used by the web at large. Even more so when this is a technology that developers will use, and build upon. I personally am ok with how Google has approached this, but I am doing a free time project, and I joined the party quite late. Judging by the various voices on this list, it would appear that there is a significant sized group that agrees with you two. J. ps.. This post is mainly a procrastination excercise to avoid the coding I know I should be doing. On Jul 4, 8:30 pm, Kaan Soral <kaanso...@gmail.com> wrote: > 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.workbe...@gmail.com> 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 google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
