We developed a product specifically for Google Drive using their JavaScript client. We were hoping to make it commercial but had to abandon those plans due to 3 bugs that have been present since around the beginning of 2013.
Also, there's no open bug tracker. The developer relations people are very friendly, but when I ask where to report bugs I'm told "just tell me". So every 2 months I've reported the same 3 bugs in person and they get swallowed up and that's the last I hear about it until my next report.
The silly thing is that we were one of the showcased applications in Google I/O this year, for the Drive section. A number of Googlers came past and said "Wow, cool. Please, please commercialise this". The truth is, we can't and it's because of the bugs in Google's code (well, partly, the other problem is Drive has just been too unstable over the past 4 months, until there's 99.9% uptime for a year, we can't consider it).
Don't get me wrong, I love what Google are doing with their API stuff and the dev relations really go out of their way to help (specifically the Drive SDK team). But, as it stands, this isn't a platform I'm confident in building a critical business product on, currently.
EDIT : That last sentence is wrong. I'm confident to build a critical business product on it, I think it'll get there, I'm just not confident to charge money and have to support it, at this point in time.
The instability/unreliability of the Drive API can't be understated. I used to have almost my entire app rely heavily on gdocs, but the api is far too shaky. Even wrapping every API call in a try_5_times function (which would often take 2-3 requests before getting a non-500), server errors would get through. Critical components of the API would go down for hours -- once, the entire day -- sometimes without even a blip on the status page.
While the api is a little funny, it's clearly very powerful. Anyone criticizing the move to work with Google API's at all should keep that in mind. But the nonexistent service and unreliability of the API are hard to overcome.
Can you link the bugs/stackoverflow you are having trouble with, please? We should be doing a better job of fixing them - especially if they are gating you from releasing a serious app. That is bad, sorry.
Hi Ali. [0][1][2], 1 is actually the dual clicking required on account selection using the JS client. They may seem subtle, but as we reduced our bug count these probably account for 75% of tickets.
TBH, I don't really want it to be that I whine in a very public place and the bugs I personally need fixing get priority.
What I'd really like to see come out of this is a public facing bug tracker for the Drive SDK that people can vote on and priority be given to the most voted for/most critical issues as viewed by the developers.
I can throw one onto github, as long as you don't mind something unofficial.
That's usually acceptable. Annoying, no doubt, but those 45 minutes a month don't usually happen in 45-min blocks monthly. It's more like a few seconds every day, and a sparratic issue once or twice a year causing a few minutes.
SLA's commonly agree to 99.9% (and I've dealt with some picky clients), though 99.99% would be better, it's an acceptable amount. Servers break, people need to deal with it when they do, and we aren't all robots.
After reading through this thread it appears to me that all that is stopping you from launching is a couple of bugs related to multiple Google accounts use case.
I would call that an edge case and launch the rocket. Just drop a comment about it in the FAQ.
Unless, your product is strictly about multiple Google accouncts in which case you are shafted. :)
The part of the Google Drive market you can make money from with our application (it's B2B) is the Google Apps for Business accounts, that means Google Apps domains accounts (not personal ones). The majority of users logged into Google Apps Domains accounts (and we measured this) are also logged into their personal account on that same browser. This means more than 50% of our target market can't share documents through our UI, can't use iOS 6 and get a confusing experience logging in elsewhere.
That's 50% of users. All we needed was one user out of however many were on the domain to remark and the feedback was "sort out the details" and these were the details.
As also mentioned, the availability of Drive documents to our apps and the app integration working correctly was also a factor.
For what its worth I hope you manage to push through.
I think that Google is wasting huge ammounts of goodwil through its lame operation of GAB.
One does not simply not run a customer service.
Edit: To add a bit more substance to this comment. I kinda know wahat you are going through. I took it upon myself (after numerous have failed) to push through something that looked like a pretty nasty bug in Lotus Domino 8 server and client. Basically what I found out during research is 20% of IBM 852 (its internal datatype) was simply corrupt.
And boy for the longest time nobody responded. There were IBM SWAT Team Leaders guarding the sacred Process that would insist on telling me that there is no Bugs in their platform and that it is obviously my fault. It took six months, an extremely detailed testing procedure with test cases and invoking a lot of connections to get my report infront of a person that could actually understand what is going on.
Soon after that I received a hotfix. I had to repeat the whole procedure another two times. And by the third time I could get it done in three months. I basically made the blue elephant dance just for me.
So for what its worth my advice is to invoke every and all connections within Google not to just get your issues within an internal Google issue tracker. You need to find out (from the outside) who is the guy responsible for the general area that is causing you problems, then keep in touch with this person and after some time you will get your fix(es).
"I love what Google are doing" - but of course you do, it is called Stockholm Syndrome. Irony aside, i'm trully amazed of Google. See, the smallest misstep Apple makes, everybody jump to hate Apple. Google on the orher can do whatever they want and nada, everybody jump in to alleviate the evelasting, unconditional love, no matter what. Remarkable achievement, hat off, in todays world.
Don't patronise me. I've been developing commercially for 20 years now, I'm not exactly wet behind the ears, nor easily persuaded by anything but facts.
I've evaluated what they are doing on their technical merit. If you want me to give you a detailed explanation of why I prefer their system, it'd probably take about an hour, so it's a bit much as a HN comment.
I genuinely think their direction with the API I'm using is the way forward, I've been waiting for someone to have the balls to do it for some time.
Any anyway, I must have missed the outpouring of love Google received for closing Reader, for not having a native Google Linux kernel OS Drive client, and so on.
> I've evaluated what they are doing on their technical merit
That's your problem. Google is phenomenal on their technical merit. It's the softer, people skills (support, listening to bug reports, etc.) where they constantly shoot themselves in the foot.
I score Apple and Microsoft pretty low on these two measures also. Support MS are OK to good, but listening to bug reports seems to be hard to do at scale. Can anyone provide any examples of people doing it really well?
Google has flaws like all companies and individuals. I'd be careful to share sensitive information with them. That said, they have a long track record of contributing back to the community (e.g. release stuff as open source like chromium); generally support open and royalty free standards (WebM, SPDY); and generally do nice stuff like Summer of Code.
If they'd turn evil over night or just stop existing, we'd still have a big net positive left. Not something that can be said for some competitors.
This is a joke ? WebM and SPDY aren't some altruistic gifts to the world.
WebM is just an pointless nuisance. The world already has a open, video standard that is widely supported, technically superior and stewarded by a wide array of competing companies. And it's only royalty free because nobody can be bothered to sue them yet. It definitely is patent encumbered (see MPEG-LA's recent 'gift' of patents to VP8).
SPDY was another technology that was developed by Google unilaterally instead of working through the existing IETF process. If Google didn't own Chrome it simply would have never taken of.
To be fair, I think there was a mix of altruism and self-interest with both technologies. Without WebM being a credible alternative, I think we'd have seen H264 licensing tighten up considerably.
And the fact that SPDY was developed unilaterally doesn't take away from Google's generosity in making it available to the world. It's generally well-regarded, and Google haven't attempted to limit it's use by other browsers in any way - much the opposite. Can you imagine Microsoft doing the same when they were the dominant browser?
Again, I'm not saying they introduced either of these technologies from pure altruism. But I am saying I'm glad they exist, and Google's approach to IP is a welcome breath of fresh air (so far).
It's wrong to place SPDY in the same class as WebM: it actually provides a significant, meaningful benefit versus the status quo. The performance benefits alone are worth deploying it for most sites and it's having a big, positive influence on the standards process as people learn from real-world deployment experience and start discussing how it makes web development better.
You're wrong in every detail. Both Google and Apple have a lot of haters and a lot of unconditional defenders. This is, of course, because they both do some shitty things and some awesome things. But good luck with your effort to cram the world into simple black/white cubbyholes!
Heh-heh, this comment of mine has the most interesting history. First it went straight up to +12, and now it has come down to -4. So it has my personal record of minimum 16 downvotes. There were some bumps when it went up, so it is certainly more than 16, only i do not know how many.
Anybody has collected more down's for one comment, or is this some kind of record?
If you build something on someone else's API, you can get fucked in a million ways. They might shut down the API (Google Reader), take away the functionality you relied on (Google Calendar), limit it (Twitter) or deprecate the version you're using, forcing you to do development work to keep working at the worst possible time for you (IOS). They might also decide that your product is very good and build a version of it themselves, using functions not available to you via the public API so that you cannot compete with it (Apple).
So before building something that relies on things entirely outside of your control, consider a few things and the effort it would take for each:
- Can you run it on something else (S3 is a good example - there are several API-compatible competitors)
- Can you replace the service you're relying on with one of your own (e.g. building your own Google Reader sync API)
Then decide if it isn't worth building the whole thing yourself. Heck, you might even want to put an API on it yourself. Feel the power? :)
Oh, and never, ever rely on someone else doing authentication for you. It's just too easy to get your entire userbase taken away from you.
Don't forget "They might break the API without warning. Every two to three months. (Facebook)."
Your argument is exactly why I don't use Google AppEngine. I know there are open-source stacks now that you can use if you want to take your AppEngine code in-house, but trying to build up an AppEngine infrastructure at probably the worst possible time ("we're getting billed @ $10k/month, but only making $8k! getting more popular will cause us to lose more money! quick, switch to custom servers!") when you can build up a solid infrastructure using technology that you can replicate on any VPS or managed box or colocated hardware that you buy seems the easiest way to scale.
AppEngine is stable, but the feature set moves quite slowly. It's the opposite of Google Drive, it seems. It's the opposite of Google Drive, in that respect.
If I didn't know any better, I might think there is some sort of correlation between moving fast and breaking APIs (or "things" as Facebook likes to call them.
Yeah, that's true, but it's also true that you're always building on someone else's API. I mean, even if you build a native desktop application, you're still relying on Windows, Linux or OSX APIs. Granted, those APIs tend to be more stable than the APIs for mobile clients and web clients, but it's not like there haven't been painful breaking changes on that front either.
So what's your solution? Write everything in assembly and run it on your own servers?
I think the way to proceed is to look at the stability of the API and the historical level of backwards compatibility that the API creator has provided and explicitly take that into account when you're developing an application. This is one of the things that Microsoft does very well, better than Linux (where GUI APIs, especially, seem to mutate every few years) and OSX. In general, though, any desktop API is much better, in terms of maintaining backwards compatibility and announcing breaking changes, than any mobile (iOS, Android, etc.) API, and mobile APIs, in turn, are better than web APIs. This isn't a case for never using mobile or web APIs, but it is a case for ensuring that you have enough resources (or a loose enough timeline) to deal with API churn as well as developing new features.
The only way to get away from APIs entirely is to write your own code, run it on your own OS, using custom hardware that you've designed yourself. That way lies madness, or, equivalently, game console programming ;)
If I write an app for Windows XYZ, my users can continue to run it as long as they keep using Windows XYZ, not as long as Google decides to keep running a service.
I thought Microsoft could kill a Windows app they didn't like these days. Maybe I'm wrong, and your point stands for earlier versions of Windows and Linux.
Really? How can Microsoft/Apple/Linus kill an app for recent versions of Windows/MacOSX/Linux? Perhaps I'm getting a different meaning from "kill" ... do you mean it won't be allowed or that the API's would change so much that it's not worth updating the app?
I'm on board with most of your examples, but in my mind the iOS example is different from the rest. iOS is an operating system designed to run native apps with a default UI. Apps can build on top of the SDK and optionally build it using the default UI. I've had apps that did these and they've been fairly stable throughout the years. It's even functional for iOS 7 if I wanted to leave it alone. I also have apps that have its custom UI that won't be changing at all for iOS 7. Of course, the same way that a developer might want to update a Win 95 app for Win 7, he or she might want to update apps when new iOS versions come out.
Is the criticism due to the annual version update? Or is it because there are API changes every new version? If it's the latter, wouldn't updates be expected, and in fact desired? It may just be me, but I've had good experiences when it comes to API stability with iOS. I've been unable to keep up with the newer features (I'm indie and only work on apps jn my spare time) but the new features rarely get in the way of my app being able to run with the calls they are already making.
I'm aware of the UDID deprecation from before, but devs were given plenty of time to transition from it. Actually, I was surprised how much time they gave.
Authentication via third parties are not an inherently Bad Thing. Mozilla Persona shows how third party authentication can be done, without risk of user base hijacking,
While it's true that Mozilla can't maintain a list of what services their users are using, there are still security implications to using Persona. Mozilla (or anyone who with their private key) can still enable access any user account on any Persona enabled site.
Persona is perfect for blogs, but using it for a service people may be paying for, or handles any private user information (postal address, private messages or posts on a forum etc) is a bad idea.
Build your solution suitably decoupled, such that if you lose access to the API you can easily switch to another provided. Ideally build solutions across two competitors services such that if you get any surprises it's clear that your solution works / users are able to migrate to the alternate provider.
For authentication I'd argue in some ways it's better to provide the option of third-party. This means users don't have to submit credentials to you. Given most people (against advice to the contrary) use the same username and password for most sites signing up to an unknown company's service feels riskier as they're then giving that company their credentials, which someone may then try on other sites - having a token which allows them to sign in with their Google/FB/Twitter/etc account saves this worry / only requires the user to hit an "authorise" button.
- Be careful with companies that don't sell the API or SDK as a product (Twitter, Google, Faceboook, etc.)
- Watch out for companies that don't like to publish roadmaps and makes APIs and SDKs deprecated or obsolete with little warning (Apple, and more recently Microsoft)
> They might also decide that your product is very good and build a version of it themselves, using functions not available to you via the public API so that you cannot compete with it (Apple).
The problems with Google start at the very basics of communication, with their policy of providing just one email adress (and nothing else) where you may or may not get an answer, effectively handling incoming requests more like petitions than providing real communication.
This is in constrast to many other big companies where you get at least some reply (although it's often canned and not very helpful, but still more than a generic auto reply), or where you can call a more or less expensive hotline, so you can at least pay them for hearing your voice.
This behaviour of Google is so restrictive that it even violates consumer protection laws in some countries. For example, here in Germany they got into trouble because they violated the so-called "Impressumspflicht". This law requests that they have to provide (among others) at least one postal address and one telephone number on their website, and that they can actually be contacted by those, in 60 minutes or less.
Perhaps slightly off-topic: The name, GmailSharedTasks, doesn't look like one that Google's legal department would agree with. Your brand/product name incorporates a Google trademark. It might have been better to call it "SharedTasks for Google Tasks™" or "SharedTasks for Gmail™".
Office365 customers (all of them are paying customers) who find it useful can install the app on their accounts. You don't have to stuggle with PayPal issues as Microsoft will pay you through the marketplace account after charging the customers.
Office365 support is excellent as well (they even do phone support). No need to chase anyone on Google+.
(I'm not shilling for Microsoft. I have no financial interests here).
Kinda funny. When someone comes on here and writes about how great some Google service is, it's an interesting post. Now someone writes about good experiences with a Microsoft service, and that's shilling.
The title of the post is "Should I stop developing for google?" If you answer it, you're actively dissuading someone. He answered and posed an alternative.
Google are terrible at developer support, but I think it is fair to say that they didn't foresee anybody using the Tasks API in this way, where you are proxying for all your users.
Keep persisting, but as a temporary measure I would prompt your users to provide you with their own API key. Lots of apps do this (such as CMS plugins). You can give them a link to the API portal and explain in 2-3 points how to generate a key and paste it back in your app.
Also, your app is in debug mode, so errors are showing a complete stack trace. Your database is also down right now.
Could you offer arguments or anecdotes about why you think Google is terrible at support? Snarky, four-character comments like yours do not add much value to the discussion.
I had to contact someone about something in regards to my Adsense account. Submitted the ticket 4 times - once every week. Got automated responses, and no human reply.
My G+ account has been "under review" for 4 months (no shit). I feel helpless because there is no way of contacting a human (or even a machine for that matter) about this.
I had a glitch with one of my apps on GAE, again no support!
For a company this big, you'd expect them to have decent support by email AND by phone.
Ever try to contact a human at google regarding their services/products? Or even your account? It's quite difficult to find an email form that will lead to a human let lone a phone number.
I've actually been fairly impressed with the support for Google Apps (paid version). I submit a ticket and a competent human calls me on the phone and usually solves the problem pretty quickly. One time, I got a lousy tech who had obviously not read my initial ticket and I had to go through the whole thing on the phone, but that was an exception.
I think that tedsander would have wanted that your explanation follow the snarky four character comment, so that there would at least be something of merit to respond to. Comments like "this" "lol" "ftfy" "rtfa" "ruh roh" are the kinds of responses that generally annoy users of HN looking for intelligible discourse.
If you work on something for 3-4 months, that's $30-40K at valley rates. To do this for free with the intention to enhance the product offering of a megacorp basically sends the message that you don't value your time. Of course said megacorp is not going to give you the time of day. They start to pay attention when the dollar value of your account is large enough. Start charging for your app. Then you can say, "I want to make us both some more money, could you please help me?"
It is difficult to charge money from India as Individuals, paypal does not accept money for India nowadays and it is near to impossible to attach a international payment gateway. I thought of donation as well but again paypal issue.
That's a terrible idea. Bitcoin is difficult to use for both buyer and seller, has high transaction costs, and is associated in the minds of many customers with illegal transactions.
All that is secondary though to the extreme lack of stability of value, which is pretty important in a medium of exchange. You might as well be telling him to accept tulips.
High transaction costs? Do you have even the slightest idea of what you're talking about? Bitcoin has pretty much the lowest transaction fees of any payment method, and you can even opt out of transaction fees if you're willing to wait slightly longer for processing.
Transaction fees aren't the only cost. You get killed on the bid/ask spread because the USD/BTC market is very illiquid as compared to say USD/INR. The INR/BTC market is so thin you'd be lucky to get fills at all.
I'd be interested to see someone do a USD -> BTC -> INR -> BTC -> USD and see a) if it's even possible in a reasonable amount of time and b) at what cost.
Edit: here's a link to an Indian "local integration partner" of bitpay http://indiabitcoin.com/. They are buying bitcoins for 82% of what they are selling them for.
That's the problem exactly. While I encourage folk to implement bitcoin payment, as a developer I don't expect any significant amount of users to adopt it as regular payment option any time soon. Even my more nerdy friends are being very cautious about it - "regular" people like my parents wouldn't touch it even if they knew what the heck it was.
You should beware that converting bitcoins into INR is going to prove difficult in India. I have not yet heard of a single bitcoin exchange for Indian (INR) users.
(On a bit of a tangent here:) The primary win of BitPay (and bitcoins in general) seems to the elimination of chargebacks. This is good for merchants, but not-so-great for customers.
It especially isn't suitable for an environment like eBay where you could potentially have less than trusthworthy sellers. In such a situation it is necessary and beneficial to have some sort of middleman (could even be the government), that you could go to, in case whatever you "bought" wasn't what the seller represented it to be (or really any other such issue).
Seriously? I accept money using Paypal though 8 percent fee (4% receiving, and 4% conversion) really sucks. Also, it has mandatory daily auto-transfer to your bank which also sucks for things as refunds ETC.
But you can definitely accept money using premium/business acounts. Premium account requires only your PAN.
I don't know how things work in India, but in the US you would definitely want to set up some sort of business entity, even if it's just you for a number of reasons. Is it hard to form a business there, and would doing so help you accept payments? Could you sell it to customers who are in India to get things started?
Never heard of instamojo so I just checked it out.
According to its FAQ [0],
> 5. When do I get paid. .... For offers selling in INR, the amount would be remitted to your Indian bank account if it has crossed minimum payment threshold
of ₹500. For offers selling in USD, the amount would be remitted to your Paypal account
Since most of your customers will be paying in USD (I guess),, Instamojo will anyway be paying as per above to your Paypal account. So, IMO, you should sort out Paypal account. (Or talk to Instamojo if they have this option to directly convert USD payments to INR and remit them to your bank account.)
I put in an API quota bump for Google Calendar a few months back and it was silently accepted after 2-3 days.
Based on my experience, each team individually deals with quotas for their API. Google Tasks is not really a dedicated product so it probably has little to no permanent team behind it. This is probably the cause for the slow response time on quota requests.
Yeah, we requested an API limit increase for Adwords. When we got an email about some specifics and how we stayed within their terms I figured it might just get rejected.
Thankfully it was a real person who actually knew what they were talking about and were able to sort it out over a chain of emails.
Google does give a lot of love to developers. AFAIK, they have dedicated developer teams for developer relations; just look at the quality of their API documentations and support. This one looks like a operations issue. Perhaps they do not have a corresponding relations team focused on operations support.
That simply isn't true. They have support for some very specific areas which they consider of specific importance (e.g. Android), for the rest you're left to rot.
> Perhaps they do not have a corresponding relations team focused on operations support.
This has nothing to do with ops, it's a developer needing a raise in his apps requests quota.
The core areas can have the opposite problem almost. The Adwords API has moved pretty quickly but they are also quick to remove things. Most stuff built in early 2012 would have had to be updated for changed/ removed features by now.
I admit I haven't really traveled much on the less beaten paths. From the quality of what I have seen, I thought they must have policies for the minimum acceptable quality of all the public facing services to developers.
On the other hand, I am happy that even the big G cannot afford to cover all fronts. It means, there is still room for new players to grow and do well in those areas.
> look at the quality of their API documentations
twitch maybe it's a personality clash, but I can't stand Google's documentation style, it's not well explained or laid out.
I know they have one group dedicated to the Android Source and they constantly answer questions related to development on their Google Group and elsewhere (like twitter). AOSP related stuff mostly comes off as good will towards the community as it's mostly those of us modding the source for ourselves and others in the community that are asking the questions.
I have looked it the quality of Google API'S its horrible only partially complete and totally lacking in meaningful documentation.
If some one came to me saying my employer is saying I am a poor performer and trying to sack me and gave the Google apis's and its documentation as an example I would have sympathies with the employer.
I notice you're syncing tasks every minute. Perhaps a short-term workaround is to sync every 2 or every 5 minutes while you wait for the quota to increase?
This is exactly what you should do. Your users will understand -- that's why so many have supported you on the googlegroup. Charge $3/mo and you won't hear any complaints (and if you do, you can point to your googlegroup).
This is by far your easiest and clearest path to monetization, at least that I can see. And it seems you're long overdue for monetization.
Can you adjust the sync rate depending on the time of day where your users live? There are probably certain times of the day when people update their tasks less frequently.
I'm not sure if it works with the Google API's but usually e.g. with the GitHub API you can send the ETag in your GET request header and if nothing changed (304) it does not count to the quota. It wouldn't solve all the problems but could at least help to stay inside the quota.
I am already doing that, because of that only I am able to survive 2000 users. I want to expand and publicize my app and give users an excellent experience.
I know it sucks, but in the meantime have you considered slowing those sync tasks down if the user's "last activity" timestamp is older than a few minutes? You might even be able to make it sync faster for active users with the extra overhead afforded there.
Logins, refreshes, clicks, new things synced, etc... can all update the last activity timestamp.
You're incredible guys. Why wouldn't you reach out to him first? Guy spend two years f with you and now he also have to screen your blog for your email too.
The sad fact that you, a random HN commentor, likely has a better means to contact Google than their official Dev channels, perfectly illustrates the OP's point.
Kudos for assisting, its just frustrating to realize its needed.
I agree about the quality of documentation. If it wasnt for Stackoverflow it would have taken far more effort to develop a iOS quality app for android and this is for a product that they actually push!
This is so tragic but basically verifies my own experiences with Google. If you are not a paying customer, they don't listen to you. Even if you do something that is more to their advantage then to yours. Maybe some paying customers who use gmailsharedtasks could direct their Google support to the thread.
It's been mentioned before that, considering the volume Google serves in all their services, it's unrealistic to expect any sort of customer service beyond the FAQ and bot variety, but I'm sure there are those who are willing to pay for an actual response.
But, as one of my clients would attest, even if you're a paying customer, you may still be left hanging in the wind. I hope they don't start spreading the YouTube feedback treatment to all their services.
Google is on track to see a $14 bil pre-tax profit for 2013.
If they spent 15% of that ($2.1 bil) on support, with say a mix of 2/3 low pay ($100k/yr cost) and 1/3 high pay ($150k/yr cost) people... they could hire 18,000 additional support staff and still show a great profit.
That works out to 30 mil support hours assuming 1680 hrs/yr (35 hrs * 48 weeks) actually spent on support. They could probably hire twice that many people by hiring some people in less expensive areas.
To sum up, Google puts making a more money ahead of better support. It's their right to do so, but it not "unrealistic" for them to provide much better support.
Your numbers don't quite work - Google has to pay taxes, benefits, office space, training, perks, equipment, recruitment costs, and so on. And then, have you tried to hire 18,000 people? Finally, Google's reported head count is around 40K - you are suggesting adding about 50% just for support. That's a tough sell to your investors. Where would all these people go. Mountain View is basically Google these days - the office I am sitting in will be razed for a Google parking lot (goodbye beautiful trees :( ). You have to factor in how many new buildings, how many new buses and bus drivers, city taxes, chefs, HR personnel - it goes on and on. The phrase "google scale" doesn't just apply to their apps.
I'm not disputing that they could improve their support, just the price tag and scale that you have placed on it.
If you see the thread there are "27 posts by 24 authors", many users are supporting my app and are sending thank you email. I have been even trying to reach Google employees personally but having no luck :(
Developed an app for Android and placed it on Android market. It had 5000 users after a week and then it got removed without notice, no email, no reason why, no nothing. First and last time I do anything with Google, malicious company not only for that reason but for many other.
Yes, you saw through me. I created this account 11 hours ago to make a fake response to a news article submitted 4 hours ago. I do not see how my credability increases if its 1 or 1000 days, you are still need to have the trust of an anonymous user which you pick to have or not. Usually you pick not to have to if it disagrees with your already established oppinion.
I usually lurk, I probably make an average of 5 comments per month. When I do make a comment, not only on HN I usually make a new account.
Google always sound to me as the "least" evil. No evil (their slogan) is rubbish, definatly considering the business stakes that are in Android / Google TV / Chrome OS / Youtube ( ebooks, music, movies, series, ...).
The entertainment business will always try to get some influence in the search engine as a "good-will" of Google before negotiating any contracts. To bad that's reality though.
Google's API documentation are generally abysmal. I have learnt not to spend too much time on the docs but rather look at the samples and source code. But there are times like when beta testing the APIs when there are no samples / source code and you mostly sitting ducks unless someone from google helps you out.
This is just another example of Google not caring a single solitary iota about developers who volunteer their time to improve their products and bring value to their platform and ecosystem. Digital sharecroppers, etc.
It's a tragedy. He doesn't want to spend the time to build his own platform, and Google won't enable him to develop effectively for theirs.
Google are tarnishing their brand, eroding their user base, and compromising their platform, all in the name of what? Avoiding the inefficiency of dedicated support for a global brand?
If anyone in Google is reading this please don't mistake me, I know Google is a innovative company and through this post I don't want to give any negative impression about Google.
I want Gmail Tasks to be world recognized and people to use it more frequently.
I see that there are very less standalone apps developed for Tasks, this is a small effort by me to make Google Tasks better and more usable.
If you find value in what I am doing and see it innovative enough, please help.
Thanks for giving me an opportunity to build an app on google.
I also think there are development enhancements you could make to your application to work around these problems. Maybe you won't get any response from Google until you have 2M users? What are you going to do about it? There have been some excellent suggestions in the comments for working around this (longer waits before retries, premium level retries etc). Do these first, increase user base, then contact Google when it's less easy for them to ignore you.
Can someone take the time to explain to me what this means for someone who has an interest in developing Android apps that may make use of Google APIs? I don't know how quotas work and why it sounds like you could request an increase when you hit a limit, wouldn't they want you to move to a paid tier?
Does this mean that as soon as your app becomes popular, you are doomed to fail?
I've looked briefly at a few Google APIs and they seem strange. So there's no longer a straight search API, you have to put some params on a "custom search API" that only has something like 100 searches per day? But on the other hand, hit the Google Local Business API and you can make 10k requests...and then there are APIs that were shut down all together, like translation. This is really weird to me. Is it supposed to make any sense?
Some services have prices over the courtesy limit (Translation) while others just have a max. What happens for like the Books API when you get above 10k/req/day?
Doesn't Google have a way of paying for more usage of the API? I know the Maps Geolocation API does. Maybe I'm naive, but if you're using a free service of a mega-corp I would expect the customer service to be nil. Priority goes to the paying customers.
I have a feeling that Google is not very eager on having 3rd party applications running on their "free" (ad supported) platform. One reason could be that while these are useful for customers, they are not really bringing in any money for Google. Obviously good 3rd party apps would certainly help people to stick with Google services but they seem to be doing that anyways.
One drawback in having people build their apps on top of you platform is that then you are stuck with the way things are. If you have popular apps depending on the current task system, you can't just take it away or move it to Google+ (or you can, but then you get lots of whining).
Google is terrible at support in general. I've been reporting a blogspot website stealing my documents and impersonating me for making money by ads for over two years. I sent my passport two times, and some friends also sent a report for me. Result? not even a verification e-mail. They simply host website that attacks my intellectual property, my name and give me no piece of shit.
IANAL, but I did take an IP law course. If I recall correctly, you have copyright from the moment that you create the work. You can have it officially registered at a later date, however, you might be limited in collecting damages to infractions after the registration date.
I'm not sure what happens if they registered the copyright. Presumably you could sue them if you can demonstrate that you were the true creator.
I don't understand the part about sending a passport.
I do think that filing a DMCA notice is certainly the easiest way. Google has to listen to that.
I sent a copy of my passport to Google since they want me to prove I report impersonation.
I really hate dealing with legal cases and also since I'm a Turkish guy living in US, and the website impersonating me is also Turkish, I don't wanna spend my time on this shitty case.
I just believe this; Google should start being friend with people.
I don't understand what you mean. If the document was written only 8 years ago then its still got decades of copyright protection. You don't need to do anything besides write the document to have those rights.
There is no reason for a platform to be controlled by a single company. If we need a common platform like gmail then it should be open source. I think we really need to push for open source shared platforms and make sure they aren't controlled by a single company. I think that means that engineering leadership in separate companies have to work together. The easiest place to do that under the radar is probably my github.
One missing piece if the puzzle that is really going to make this idea if a shared platform across companies is moving to encrypted data oriented networking instead of server based networking. Not only does that model make vastly more sense in terms of the real topology of internet use now with data being propagated to leaf nodes, but there are also very strong reasons to move to distributed encrypted computing for privacy and economic reasons. A server based internet means server based web apps which is going to continue to result in due facto platforms created by individual companies.
This issue almost took more than a year to get fixed - I had to drop a project midway and start with other technologies from the scratch to build the same thing.
It's not clear how a willingness for the end-users to pay $3-5 monthly would help the situation given that he can't use $$ to increase his quota-controlled access to the api.
I think Google has such a strong consumer following now that it isn't as interested in keeping the developers happy. We were early adopters so got a good amount of attention at the start but that certainly seems to have waned with Google's popularity.
It just doesn't make sense. Without developers all the innovation happens elsewhere, and at some point the consumers will switch. Google cannot keep up with innovation internally, and they're not attracting new talent with such a hostile developer stance.
Oh if its for commercial purpose please stop developing Apps for Google. Usage will increase for a certain period of time, and then it drops constantly...
Comment of the day:
"If you cannot increase his quota, at least give him a job...".
Right, because hiring someone is probably much easier than changing a number in some database.
I find it very hard to believe that a bunch of random people find the time to comment (and all praise that app) on a Google Groups thread. Calling bullshit.
They are not random people, they are the users of gmailsharedtasks. They have used it and love it. They have commented due to my request so that google come to know that the app works great and is loved and needs attention.
1.) You are clearly young and do not know: if there is something on the internet you do not like, go make it yourself. What obligation does Google have to do something for you? None! They are providing mostly free services, but if you don't like it (or the support), go make your own and quit bothering people (and Google).
2.) You have no relation to the GMail Web Application, yet you specify: "Founder GmailSharedTasks" Remove the Gmail from your description and build out your solution without trying to get a free ride.
3.) Your Google Groups post can be summed up: "Cry! I'm not getting any attention for my pet project!" Instead of crying, create your own solution that does not leave you at the mercy of a company or individual who sees you only as "1 of billions". Get over yourself.
4.) You know how to code, you know how to integrate with FREE APIs, now learn what it takes to run a business.
4) Why create my own API ? If someone as good as Google has already build it ? I know how to code and have built this app within 3 months.
and yes I am a young developer and I know what business is. I know about code re-usability and providing a great user experience.
Regarding building of my own API, I could have done that but I always wanted to make Gmail Tasks better, because I have been using it from past two-years.
Learn to praise the people instead of finding negative aspects.
Also, there's no open bug tracker. The developer relations people are very friendly, but when I ask where to report bugs I'm told "just tell me". So every 2 months I've reported the same 3 bugs in person and they get swallowed up and that's the last I hear about it until my next report.
The silly thing is that we were one of the showcased applications in Google I/O this year, for the Drive section. A number of Googlers came past and said "Wow, cool. Please, please commercialise this". The truth is, we can't and it's because of the bugs in Google's code (well, partly, the other problem is Drive has just been too unstable over the past 4 months, until there's 99.9% uptime for a year, we can't consider it).
Don't get me wrong, I love what Google are doing with their API stuff and the dev relations really go out of their way to help (specifically the Drive SDK team). But, as it stands, this isn't a platform I'm confident in building a critical business product on, currently.
EDIT : That last sentence is wrong. I'm confident to build a critical business product on it, I think it'll get there, I'm just not confident to charge money and have to support it, at this point in time.