- Don't communicate with them
- 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
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...
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?
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.
Lets hope Google learns to be a little more responsive.
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.
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."
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.
Regardless, it's not be "sold" at all yet. :)
"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*.
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.
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!
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.
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.
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
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.