Google Increases Attachment Size in Gmail

You can now attach up to 20mb files to Gmail messages, that’s up from 10mb. There was a time when a number of services developed that enabled the sending of large files over email, I would imagine their oxygen just got sucked out. To be fair, there are a couple that have developed much richer capabilities than simply sending large file attachments, like YouSendIt.

I have always liked YouSendIt for being drop dead simple to use and later for having some nice features, like the dropbox functionality for business users. The management of electronic documents continues to offer rich opportunities for startups.

Tags: ,

The Business of Mashups: APIs (the Buy Side)

Yesterday I wrote about APIs and mashups, focusing on the publishing of APIs. Today I want to cover some ground from the other direction, building out a business using APIs to access other people’s code (OPC).

Here’s the first reality you should consider, there is no 11th amendment to the Bill of Rights that states your right to APIs shall not be infringed. The cold hard truth about published APIs is that someone is offering them as a courtesy and they can, and sometimes do, decide that it is no longer in their best interest to continue to offer that API. In other words, if you decide to build an application on someone else’s code, be forewarned that you may in fact be on some thin ice.

Here’s a couple of other things you need to think about when building a dependency on another company’s API. The first thing that comes to mind is economics, meaning the API may sit on top of a subscription or licensed service, in which case you will be asking your customers to pay not only for access to your service but to someone else’s as well. In the event that you don’t have a contractual relationship with that entity, well you are basically telling your customer to go sign up for something else and then come back to you.

Some companies identify a loophole in a pre-existing relationship with a vendor that allows them to license a single user and then proxy that user for the rest of their application. Microsoft famously did this against SAP in the late 1990’s when they build a purchasing portal on top of a single user license for R/3. Essentially, these loopholes tend to get closed pretty quickly and in our current day and age I would think it pretty rare that a license agreement or terms of use would allow such usage, and like I said, it can get closed pretty quickly when exposed.

Speaking of contractual relationships, the absence of one causes all manner of complications. For example, usage restrictions ride on most APIs, and even the most primitive hosted apps can identify spikes in usage from a single calling application when it presents itself. No relationship with a vendor means no path to overcome usage restrictions. Early stage companies can often, and should for that matter, just talk to the API provider to get a pass on usage if they are in the proving stage but at some point you will need to formalize things.

Does the API provide all the functions you require? If not, well you are probably out of luck unless you have a clear and obvious use case scenario that benefits the API provider. They may publish their product roadmap, or in the very least just talk to you about it, but they may not and that means you will have zero visibility upon which to base your own roadmap.

Security is major issue, and will continue to be. Any service that is providing named user accounts and private data spaces will have a basic username/password login and authentication system that will be integrated with their API. Do you want take on the responsibility for storing, and protecting, usernames and passwords? If you don’t then you will be asking your users to provide the credentials in addition to what they may require for your service.

OpenID is a starting point but few services support that mechanism today and it’s unlikely we’ll see a movement accelerate to adopt it. The problem is twofold, the first being no sense of roles associated with OpenID credentials, so while it’s handy for simplifying the login process you still have to deal with the user policies on your own, but in all honesty I would not expect OpenID to solve that issue.

The bigger issue that developers looking to adopt face is that there is no way to authenticate that the person claiming to own the OpenID URI actually does own it. The authentication issue rears it’s ugly head in this scenario: someone gains access to your OpenID URI which then gives them access to every website that supports OpenID.

At any rate, storing usernames and passwords on behalf of your customer is walking a high wire without a net. One breach of security and you are dead meat, no one will ever trust you again. Tread carefully here and make sure that when you are asking your users to trust you with their user credentials that you are doing everything in your power to protect them.

Putting aside user credentials for a moment, you are going to need to make yourself familiar with API keys and how each vendor implements them. This is often pretty straightforward stuff for techies but the licensing agreements that you are agreeing to adhere to in exchange for an API key often have interesting non-technical consequences. Check out the language in Amazon’s Web Services license as an example of this.

Lot’s of interesting scenarios come up with regard to API keys and how they are used, and quite honestly most of them get dealt with as they arise, meaning your use of an API could be so unique as to cause an amendment of the usage agreement which could impact you negatively. Make sure you understand the terms of use before committing yourself to a service and if there is any ambiguity it is best to confront the API provider with it rather than hope it works out on it’s own.

Performance is an issue for anyone accessing APIs, if for no other reason than a great many of these mashup applications are NOT asynchronous and that means your overall performance is a function of your most poorly performing service component. Going back to my opening remark, if a service provider is under no obligation to provide the API to begin with, well they certainly don’t have an obligation to provide a high performance service.

Insulate whenever possible your exposure by failing over to a backup service, in the cases where fungibility exists, meaning one service is as good as another. Google Maps not working, failover to Yahoo Maps… and if a service failover is not possible then architect your code so that non-responding service calls are skipped instead of the entire app crashing. BTW, this issue has been coming up more frequently as blogs have begun adopting sidebar widgets and performance has suffered as a result.

ProgrammableWeb lists 441 public APIs and I would bet that in total there is in excess of 1,000 (meaning providers as opposed to individual APIs). Personally, I think building a business on more than a handful at a time is risky business but it is certainly possible if you understand what you are getting into and devote the necessary attention to formalizing your relationship with the provider.

In the case of Google or that means signing up for their developer and partner programs and building relationships with the individuals in those programs, but for smaller companies like Echosign or Freshbooks you will do yourself a favor by understanding how you benefit them and then building a relationship on the basis of mutual benefit. It’s been my experience that hosted application providers are anxious to work with third party developers to integrate their services in application workflows but that effort is predicted on an assumption that you know what you are doing. If they believe in you they will devote time and energy to accomodating your needs.

 Tags: ,

Let’s Count the Hypocrisies

UPDATE: Migden was driving a Toyota Highlander Hybrid, not a Ford Escape… guess she isn’t into supporting U.S. businesses (with taxpayer money). At any rate, my point #3 still stands because California included Toyota in the lawsuit I mentioned. BTW, the Highlander replaced the State purchased 2005 Cadillac STS that Migden was driving up until recently… and was involved in another accident in last year when she ran into a bus in SF.


Carole Migden, California State Senator, gets into a fender bender while weaving in and out of traffic in her state issued SUV and talking on her cell phone:

1) Migden voted for legislation that would have outlawed talking on a cell phone while driving in California, arguing that it was unsafe, which in her case it clearly is. Actually, I should be clearer about this, the law requires handsfree use beginning next year, so it will be illegal to talk on a cell phone without a handsfree option while driving… therefore there is no excuse for her lapse of judgement here.

2) Migden spoke at a ceremony praising the introduction of the 1-800-TELL-CHP phone service for reporting erratic drivers… the same service that was ultimately used to report her erratic driving prior to the accident she was caused.

3) It would be tempting to also point out that Midgen was driving an SUV, but it was a Ford Escape Hybrid. However, there is still some irony in the fact that the State has sued Ford and other automakers claiming that their vehicles are gross emissions polluters while at the same time acquiring vehicles that they claim are not available.


More on this topic (What's this?)
Case Study: Digital Roaming and Cell Costs
Poor Gareth and his H2
Read more on Toyota Motor, Cell Phone Manufacturers at Wikinvest

Google Flirts With Evil

Eric Schmidt, Google’s chief executive, said gathering more personal data was a key way for Google to expand and the company believes that is the logical extension of its stated mission to organise the world’s information.

Personally, I’ve never been much concerned about these issues but I understand that some people are, and it’s entirely within their rights to be so. The evolution of technology to the point that Google envisions it, where they could tell you "what jobs to take and how they might spend their days off" actually sounds pretty interesting. Likewise, their advertising engine being able to better target what I want is something that I would want to be able to take advantage of.

But here’s the thing, the data they are collecting is about ME and as a consequence of that Google is able to piece together things about my life, my online life as a proxy for my real world life, that they are profiting from without my informed consent. They would say "well don’t use Google services and no data will be collected" but that argument rings hollow when Google doesn’t publish what they are collecting, or hold themselves to public review on what they wish to collect.

More to the point, Google is now the tip of the spear for the entire industry so what they do will soon be replicated by every other search provider. The internet is a public utility at this point, like electricity, and the simple fact is that individuals cannot not use it without suffering economic disadvantage.

While I’m not prone to suggesting that government should step in and regulate given their track record, in the words of Thomas Sowell:

"Nothing is more common than political "solutions" to immediate problems which create much bigger problems down the road."

Having said that, Google should heed their own slogan "don’t be evil" and offer all of their users an opt-out mechanism that simply put allows me to flip a bit and delete everything they have attached to my username. Google could actually take a leadership position on this issue and use it for competitive advantage, I would certainly be more inclined to use Google services over competitors, or anyone else for that matter, if this option were to be made available to me, but Google probably isn’t concerned about competition at this point and that should concern everyone.

Tags: ,