Skip to main content

How to piss off your customers in two easy steps

  1. Don't communicate with them
  2. Treat them like they owe you something

Google is off to a good (bad?) start with both of these in its management of the App Engine release.

Of the 120+ issues logged by beta testers, a few have been closed as wontfix or duplicate; most have no response at all from the App Engine team. I can't think of any other company that I've filed an issue with that took that long to get back to me. The good ones get back within hours.

The one exception I have seen is for the urllib issue, where gu...@python.org, presumably Guido, wrote

Providing a urllib replacement implemented on top of urlfetch shouldn't be particularly hard. If someone is willing to produce one, I'd be happy to review it and, if it passes muster, try to get it added.

Paraphrased: "maybe if you do our work for us we'll consider it."

WTF!

This isn't OSS, where "if you want something, do it yourself" is at least a semi-valid response. App Engine developers are all currently beta testing a product that Google hopes to eventually charge for. We're doing google a favor. (Context: the replacement Guido wants is a piece of code that will only ever be useful on app engine, and is something Google should have done in the first place instead of making urlfetch a public API. This is not code with a use case outside of App Engine.)

Maybe I'm over-sensitive, but this really rubs me the wrong way.

I hope Google can (a) put enough engineers on this that they can actually respond to issues, and maybe start closing some, and (b) remember that when you're selling a product, "why don't you fix it if it bothers you" is a poor response.

Comments

Anonymous said…
Youre right it isn't OSS but you are getting a lot for free and maybe the kudos alone might be worth it :)
Richard said…
I don't mean this as a troll, but as an honest opinion. I don't see what you are describing in the same light you do. When I read your post I feel you have a large amount of unjustified entitlement.
Dennis Peterson said…
Don't just blog it, post an issue! :)
Ranger Rick said…
As annoying as it is, I think that when any huge project gets announced and within a couple days has over 100 issues, you can assume they're getting slammed from all sides and have barely had a chance to look at them. When they do, they have time to do a quick triage type message "yeah, that would be nice, but there's no way we have time for it right now, if you submit something we *might* have the time to code review it and put it in."

Not that a lack of responsiveness is ever a good thing, but you have to figure things are crazy there right now and they're just trying to keep their heads above water...
Shub said…
Your post leaves out some important information. Guido (I assume) said "I don't have time to implement this. Wrapping urllib2 around urlfetch is trickier than you might think. However, if someone does our work for us we might add it."

Definitely a suboptimal response, but I trust the GAE guys to appropriately value urllib. So you live with it.

Someone is going to develop "urllib for GAE" if Google doesn't. Wouldn't you rather have it blessed by Google?
Bill said…
I took Guido's comment in a slightly different context.

This is the issue system for the AppEngine - which means both end users and developers are using it. Guido probably isn't even a dev on the project, but if he is it doesn't matter - he still needs to put his thoughts and comments about each issue in the issue.

His comment could just as easily be directed at Google Devs as it is to the end users. That is the problem with transparency though; it is hard to tell who he is talking to.

I'm not defending the Google teams lack of communication - but I do think you might be taking Guido's comment the right way. He is probably offering to help out the Google Engineer who takes a swipe at fixing it rather than asking the end users to create the new code.
cowmix said…
While I love Google, this seems to be a theme with some of their high profile projects. I seem to recall the same 'lack of responsiveness' with public issues and recommendations regarding their Android mobile phone platform.

Lets hope Google learns to be a little more responsive.
Justin Driscoll said…
URL Fetch works, so they're asking for them to "fix" or change something that from another perspective isn't broken. I see no disrespect in saying "if urllib compatibility is required for your existing app and you don't want to port it that's not our problem, but we'll help if we can.".

App Engine isn't managed Python hosting. It's a new development framework that happens to use a large subset of the Python language for scripting and it was never promised to be anything other than that.
Jonathan Ellis said…
Richard: perhaps you're right, but if you take the "Google" and "Guido" out of the equation and think about it in terms of beta testing for any other BigCo, do you feel the same way?

Rick: sure, that's possible, but if that's the case the professional thing to do is to at least post a blog entry giving a high level picture of what they're working on. (App Engine does have its own blog already.)

Bill: at Campfire One Guido said he is on the App Engine team.

Justin: that would be fair except that's not how Google is selling it. Quote [from the Campfire One introduction]: "The Python that we use in App Engine is the same Python that you've grown to know and love."
Justin Driscoll said…
http://code.google.com/appengine/docs/python/

They state very clearly during the Campfire introduction that the provided runtime environment is sandboxed, does not allow access to sockets (hence urllib), write-access to the file system or OS processes.
Jonathan Ellis said…
Justin, I was rebutting your claim that "App Engine isn't managed Python hosting. It's a new development framework that happens to use a large subset of the Python language." Again, that may be true, but that's not how it's being sold.
Justin Driscoll said…
I thought they made it very clear off the bat that it was going to be unique environment where if you were willing to play by their rules you would get to play with some BIG toys.

Regardless, it's not be "sold" at all yet. :)
jek said…
The stance isn't isolated to the urllib issue. The App Engine materials state that:

"Google App Engine supports any framework written in pure Python that speaks CGI (and any WSGI-compliant framework using a CGI adaptor), including Django, CherryPy, Pylons, and web.py."

And ticket #33 was opened because that isn't really the case. Guido responded:

"I'm open to suggestions for specific changes that will make Pylons etc. work. E.g. if (as Ian suggests) a stub version of subprocess.py will help, please produce one and I'll review it, and if it passes muster I will try to get it added. Ditto for missing os functions."

I have a hard time reading that as anything other than "If Google's customers want the product to work as advertised, they'll have to fix it themselves on their own time." I guess there is an element of entitlement to my reading- App Engine is a *paid service*.
Ian Bicking said…
Yeah, I must admit I kind of feel the same way. I understand why they can't keep up with the tickets or the list, since I imagine there's work we don't even know about as they try to figure out the system they've just deployed.

The framework thing is rather frustrating, though. They claimed other frameworks would work, when apparently they never actually tried them. Isn't it just basic due diligence to make some attempt to do what you say can be done? I'm not saying they should have held back the release, but I also feel like if they'd tried these things some of the small, basic functionality that needs to be there would have been added in.

As for urllib, I am a bit baffled by their decision. I know why they implemented it like they did, but I can't fathom why they created a new module to do so. Reimplementing existing interfaces just seems like the obvious strategy. But, eh, they made a mistake, that's fine. And maybe realistically it will be done faster and everyone will be more productive if someone outside of Google fixes that mistake, because perhaps people don't want to wait based on the Google team's schedule. But that doesn't keep them from acknowledging the problem, which I think is all they'd have to do to make people feel better.
Anonymous said…
I am confused about your article. My understanding is that it is free to use GAE, given the caps on storage and bandwidth that they have alloted. You mention that you are a customer, and in fact your whole article seems to be predicated on this fact. I would suggest you contact their customer support and see if you can get an invitation for a free account as the rest of us have done. I would definitely advise against paying for this service at this point in time since it's really hot off the press and will probably have a number of known issues and limitations.
Another piece of advice - if you're a paying customer for a service and not happy with it, I would recommend you try to get your money back and take your business elsewhere. In other words - DON'T USE IT!
Also, it seems like you may have misunderstood what the Google App Engine is. It's not Python web hosting. It is an application platform that lets developers use Python syntax to create applications that run on their platform. This is not the same as installing Python on a server and then running your applications where you are free to install 3rd party libraries to your heart's content, run background (cron) processes and the like. If that's what you're looking for, there are a number of web hosting providers that provide such services (see djangofriendly.com). Google is not one of them. If you decide to build an application on Google's platform, you play by their rules. If their rules don't suit your needs... DON'T USE IT!
The tone of your post almost makes it sound like Google owes it to you to roll out this new service according to everything just as Jonathan needs it. I'm sure you've already directed hundreds of thousands in revenue their way so you feel a little spurned. Let me guess, you were just about to roll out a new app on GAE that was going to make Google a few billion and then hit a wall with their sandbox limitations. Guess what? Don't partner with them for business anymore!
cowmix said…
Brian: I think most EVERYONE here *wants* to partner with Google.. We just want to make this product better..

It seems like Google, in general, isn't used to dealing with outside developers yet like other software companies.. We're try to voice our concerns now.. hopefully they will listen.
Anonymous said…
I'm all for making products better, and I'm not saying we shouldn't critique the products and offerings that companies put out. But what does "better" mean?
Remember, Google is a for-profit company and they have their own agenda. I think it is unfortunate that the initial press compared GAE to Amazon's EC2 and all that. It could be that Google does want to compete in this arena and maybe they are going down the wrong path. But we (at least I) can't say with any certainty what Google's motivations were for releasing this service.
One thing I haven't really seen mentioned is that Google really wants to chip into the MS Office monopoly. Do you really think it's a coincidence that GAE limits your interaction with general web services, but the Python GData client was updated to work on GAE and ready to go at the release? Would you really be that surprised if the early samples and tutorials for GAE focus on consuming Google's services and extending their Apps applications?
Did you really think it was a coincidence that one of their early sample apps on GAE was a clone of the 37Signals Campfire collaboration application? Folks, Google would love nothing more than for legions of developers to create all kinds of plugins and extensions for their own Google Apps. They're not complete idiots. They saw how Salesforce exploded when they opened up their platform and they're in a pretty good position to grab a piece of that pie. Hey, if the GAE platform flops in its current incarnation, I'm certain they'll look to retool it to make it more attractive. But I can guarantee you their goal was not to open a free, infinitely scalable platform just so Python hackers could have a place to host their weekend projects and all the whining in the world isn't going to make that happen.
Anonymous said…
I am a bit surprised as well by the lack of feedback on the issues posted by early experimenters.

I raised two and haven't heard anything back, maybe taking part in a blogging conversation will work better:
- Invited developer can delete the project "owner"
- urlfetch - SDK and appspot out of sync
Jonathan Ellis said…
Boa Constructor is really the only free one with a full-on cross-platform gui builder now that Komodo dropped theirs, although others incorporate standalone builders to one degree or another.

Unfortunately, when I looked at BC a couple years ago it was very buggy. There's been one release since then so it may be worth re-checking, but the project really doesn't seem very active anymore.

If you're only interested in a specific platform then XCode or Visual Studio may be worth a look.
Anonymous said…
I am very much disappointed to know that you no longer intend to do further development on Spyce. It is a great piece of work! Why would you go for Django if your requirements are very simple? Simple requirements should be simple to do and I don't think any of the other frameworks out there is as simple. Can you cite reasons for other developers not using it other than lack of popularity? BTW, I regularly visit this site just to know any new developments with Spyce. I actually used it together with SqlAlchemy/SqlSoup and Postgres for my brother's business.

Popular posts from this blog

Why schema definition belongs in the database

Earlier, I wrote about how ORM developers shouldn't try to re-invent SQL . It doesn't need to be done, and you're not likely to end up with an actual improvement. SQL may be designed by committee, but it's also been refined from thousands if not millions of man-years of database experience. The same applies to DDL. (Data Definition Langage -- the part of the SQL standard that deals with CREATE and ALTER.) Unfortunately, a number of Python ORMs are trying to replace DDL with a homegrown Python API. This is a Bad Thing. There are at least four reasons why: Standards compliance Completeness Maintainability Beauty Standards compliance SQL DDL is a standard. That means if you want something more sophisticated than Emacs, you can choose any of half a dozen modeling tools like ERwin or ER/Studio to generate and edit your DDL. The Python data definition APIs, by contrast, aren't even compatibile with other Python tools. You can't take a table definition

Python at Mozy.com

At my day job, I write code for a company called Berkeley Data Systems. (They found me through this blog, actually. It's been a good place to work.) Our first product is free online backup at mozy.com . Our second beta release was yesterday; the obvious problems have been fixed, so I feel reasonably good about blogging about it. Our back end, which is the most algorithmically complex part -- as opposed to fighting-Microsoft-APIs complex, as we have to in our desktop client -- is 90% in python with one C extension for speed. We (well, they, since I wasn't at the company at that point) initially chose Python for speed of development, and it's definitely fulfilled that expectation. (It's also lived up to its reputation for readability, in that the Python code has had 3 different developers -- in serial -- with very quick ramp-ups in each case. Python's succinctness and and one-obvious-way-to-do-it philosophy played a big part in this.) If you try it out, pleas

A review of 6 Python IDEs

(March 2006: you may also be interested the updated review I did for PyCon -- http://spyced.blogspot.com/2006/02/pycon-python-ide-review.html .) For September's meeting, the Utah Python User Group hosted an IDE shootout. 5 presenters reviewed 6 IDEs: PyDev 0.9.8.1 Eric3 3.7.1 Boa Constructor 0.4.4 BlackAdder 1.1 Komodo 3.1 Wing IDE 2.0.3 (The windows version was tested for all but Eric3, which was tested on Linux. Eric3 is based on Qt, which basically means you can't run it on Windows unless you've shelled out $$$ for a commerical Qt license, since there is no GPL version of Qt for Windows. Yes, there's Qt Free , but that's not exactly production-ready software.) Perhaps the most notable IDEs not included are SPE and DrPython. Alas, nobody had time to review these, but if you're looking for a free IDE perhaps you should include these in your search, because PyDev was the only one of the 3 free ones that we'd consider using. And if you aren