Praxis

AppExchange: Tired or Wired?

Mashery was honored to present today at Under The Radar, on a panel called "Mash it Up". We shared the stage with three terrific companies - Teqlo, Proto and LongJump. I learned a lot, and got some great feedback.

One common theme I noticed is that several of the companies going after the "develop mashup applications easily" space are explicitly targeting AppExchange as their competition. After less than a year in existence, SalesForce.com's application development and distribution platform is assumed to be a success and the market leader against whom everyone else is competing.

Pankaj Malviya, LongJump's CEO, didn't even try to hide his disdain of AppExchange, painting it as difficult to develop in, complicated to use, and absurdly expensive relative to his solution. And Jeff Nolan (pictured here), Teqlo's CEO, put up a slide that showed the AppExchange homepage with the AppExchange logo scribbled over in red, and the Teqlo Application Network ready to take its place.

Has AppExchange already become the Google of enterprise mashups?

API Primer at Read/WriteWeb

Alex Iskold provides a great post on the strategic value of data APIs over at Read/WriteWeb.

The most important point Alex makes is the strategic value of offering open data. Amazon and eBay are good examples, but there are plenty of examples in less-known companies and sectors. Domain Tools uses the Compete.com API to provide web analytics as part of its service; in exchange, the obligatory attribution link has driven substantial new traffic to Compete's own website.  In the wine industry, a great service called Wine Searcher has scraped wine retailers' websites worldwide for several years to provide the most complete and accurate database of fine and rare wine values available anywhere.

At Mashery , we're seeing a lot of websites offering web services APIs as a means of more broadly distributing their data while being able to control how it is used. Ultimately, the API is less a technical tool than it is a means of creating a distribution channel and acting as a business development catalyst.

If an API is well-managed, anyone using the API will agree to the vendors' terms and conditions of use before being issued an access key to the API, and usage of the API is tracked and managed by the API provider. Large providers like Amazon and eBay make their data available through APIs, but they do take these steps to manage the data's use. Legitimate users of the data are willing to follow the rules in exchange for the ease of access and flexibility offered by the API.

Mashery has provided API management infrastructure for access control and developer community management companies like Trulia and Compete.com, and are working with others to offer both "open data" and "service manipulation" to developers.

In praise of Beta customers

Fun day at Mashery today. Trulia, our newest client, went live with their Mashery-powered API today. The past few weeks have been intense, working with Trulia. Once they made the decision to open their API, they put a lot of company resources and energy behind the launch, which has helped us immensely.

For Mashery, that meant a lot of interaction with two very talented Trulians, Megan and Lawrence, but it seems like everyone there got into the project. A couple weeks ago, Trulia held an internal "hack day" to come up with a couple sample applications - Truliaholic and PlotOrNot. After that, we worked with their team to make sure that the developer site had all the necessary features and that all of their documentation looked great.

Trulia has been a great beta customer, in the true sense of the word. They have been patient with us as they've uncovered bugs (yep, there were definitely bugs to discover), found places where our documentation could be improved, and asked for us to accelerate development and deployment of features we hadn't planned to release in a few months. In exchange, we've provided a lot of support and responded to requests that take on a great deal of urgency when their launch is also our launch.

This is a critical time in the life of a startup. We've spent six months planning and building a product based on our own experience and the advice of investors and colleagues. But the advice gets a lot more specific when the time comes for real customers to use a product they're paying for. We have learned a lot about our product, our market demand and the kinds of issues our customers will have.

In the end, all of Mashery's present and future customers will benefit from the input, patience and hard work of our first few beta customers...so many, many thanks to everyone who has worked with us at Baynote, Loomia, Compete.com, and Trulia. No way we could have gotten this far without you.   

Mashery Pro Rate Limiting goes live - shows the value of a managed "Free" API

Last week, Mashery's first "Pro Service" rate limiting client, compete.com, went live with Mashery's package of developer key management, access control and rate limiting. Compete's first outside API user is domaintools.com, which offers a nice snapshot of information on an active domain. If the domain you request is in the top million domains, this information includes a ranking pulled from compete's database.

Mashery ensures that only authorized developers have access to Compete's API. Compete is currently running a "closed" developer network, meaning that only developers preapproved by Compete are eligible for keys. I expect that they will move to an "open" network soon.

But even closed networks need control. Domaintools is subject to a Mashery-managed calls-per-second limit, so that excessive traffic to domaintools will not overload Compete's API. We also limit overall number of calls per month per Compete's specification. Mashery allows Compete to set a different calls-per-second and calls-per-month (or per day or per week - whatever time period they want) for each developer key that is issued.

One interesting outcome of this launch is that Compete has demonstrated how to extract value from  an API without necessarily directly charging for access to that API.

A domaintools.com report on "programmableweb.com" generates the page below. Note the contribution from compete.com...the link enclosed links back to the actual compete.com site, which provides more information. We're told that this has turned into a nice source of traffic to compete.com.

David Cowan with the Contrarian View on Network Neutrality

Congratulations to David Cowan of Bessemer Venture Partners for his willingness to write a thoughtful post taking the "dark side" view of the religious war over Network Neutrality. The first post I ever did on this blog made it clear that I am on isen's side of the debate, and a post I wrote almost a year ago about bad VOIP performance on my Comcast cable modem service continues to attract new comments. 

But that doesn't mean that I'm not willing to listen to the other side, and David makes some compelling arguments that are worth considering. I'm a believer in free markets, and his suggestion that companies should be free to innovate as they see fit is appealing.

But the Internet is different. David makes the point that it is not a public utility, and he is technically correct...but in practice, it has evolved into something that resembles one. All businesses, large and small, rely on the Internet today the way they relied on the telephone in the past...and on the US Postal Service before that. At various points in our history, government regulation has had to step in to ensure universal access to critical services even to those users who can not be served profitably.

David's example of Federal Express is an excellent case in point. For the first several years of FedEx's existence, only the largest cities were served. Then gradually service was rolled out more broadly. It was with great fanfare that FedEx announced after several years that they would deliver to all zip codes, but even today, their express service (10:30 am delivery) is only available to certain areas, while others can't receive packages until mid-afternoon. For certain special regions (big cities), even earlier delivery is available.

FedEx is able to make a profit because they cherry-pick the most lucrative part of the Post Office's business while ignoring the astonishing infrastructure needed to deliver a letter locally overnight, and pretty much anywhere in the US in two or three days, for $.39.  I'm not suggesting that FedEx shouldn't be able to do what they do. I am suggesting that it only works if there is a "utility" in place to assure that the "basic" service is still available.

David mentions Akamai and Netli, two companies (uh, well, now it's just one company) that "accelerate" the internet for "premium" customers who pay them. That seems to work pretty well. In fact, Akamai's caching services actually help us to use the backbone more efficiently, so the existence of this "premium" service has a positive effect on the speed of "basic" traffic.

But premium services can't come at the expense of making sure that everyone's packets can move quickly and efficiently. If Telcos are allowed to become "Fedex" without a "Postal service" in place that provides universal access, they will by definition head toward the lowest hanging fruit, which will be large businesses that can afford to pay for these premium services...just as the CLECs did in the early days of telecom deregulation.

David leaves us with a dire vision of the US losing market share to competitors due to an over-regulated broadband carrier market that leads to "creaky, petrified infrastructure". I submit we're already there, and it's not because of regulation. Other countries with far more regulation routinely offer bandwidth rates to the home that businesses in the US can only dream of. Let's focus on building the fattest pipes in the world, so we don't have to spend time debating the need for a "fast lane". If we can't do that, then I believe regulation will be needed to ensure that there is a slow lane at all. 

Steve tweaks Bill. Intentional?

Gotta love the news today that Apple recommends that Windows users wait on upgrading to Vista if they want their iPods to work.  Apple's iPhone clearly overshadowed the Zune launch, and now Apple is very publicly recommending that Windows users need to weigh whether they want "corrupted" iPods and music from iTMS against whether they rush out and install Vista.  How long should they wait? 

According to a company statement provided by Apple spokesman Derick Mains, "although iTunes 7.0.2 may work with Windows Vista on many typical PCs, Apple is aware of some known compatibility issues and recommends that iTunes customers wait to upgrade to Windows Vista until after the next release of iTunes, which will be available in the next few weeks."

In other words, once the excitement has died down...and, depending on which rumors you believe, about the time that Apple announces the release date for the new Leopard operating system.

Meanwhile, Apple has released a patch for iTunes, but it's unclear if that patch fixes all the problems that they say Vista users should fear.

Steve is not only the master of the product launch...he's equally good at interfering with the launches of his competitors. Or do you  really believe that this was a random, unintentional occurrence?  Unlikely.

Making Money from APIs

Sadly, I was not able to attend the recent Mashup Camp at MIT - it would have been great to return to Cambridge, and it sounds like I missed some amazing sessions. But I had to stay in the Bay Area for the First Round Capital CEO Summit, which was time very well spent. Josh, Rob, Howard and Chris may not pick EVERY company right, but the entrepreneurs in that room were an amazing group of people. The presentations were outstanding, and the interactions I had with my fellow CEOs and executives was incredibly useful.  A special thank-you to the speakers who took time out of their day to talk to us - the content was highly useful.

Anyway, as much fun as the Summit was, I missed what sounded like a great panel at Mashup Camp talking about "Making Money from Mashups". John Musser has a great summary here. John's post should be required reading for anyone thinking of exposing an API for adoption by a developer community - all of the concerns, pitfalls, opportunities, and "dos and don'ts" of offering APIs.

The bottom line is that an effective API program is scalable and predictable. Remember, the reason people are embracing web services based application development is that it is supposed to be easy, scalable and economical...and they expect that they can build something successful.

Give developers enough free access to experiment and develop. Make the Terms and Conditions clear, and the opportunity for success real. If you are going to charge for access above a certain level, make sure people know what that charge will be, and when it kicks in. And make it very, very clear that the API is here to stay, and that people can realistically rely on it when building mission-critical applications.

Traditional software development platforms like Oracle or .NET or MySQL would never have thrived if the resulting software had limits set around how much they could be used - restrictions on how successful they were allowed to become. It is the uncertainty of the availability of web service components that cause developers to be reluctant to depend too heavily on an API that could vanish.

I'm reminded of an exchange between me and an audience member at the mapping panel I moderated in New York recently, an audience member asked me  "so we are supposed to rely on these API providers, but how do we know they will always offer these sevices? We're trying to build great applications. How do we know when or if we'll be cut off?

Simple answer - "whenever it becomes mission critical to you, expect it to be cut off by them."

But that doesn't have to be. Many providers understand the importance of  consistency and predictability. At the recent salesforce.com apex gathering in San Francisco, it was clear that salesforce.com is serious about getting a lot of people hitting its APIs heard, and about, as they said, "helping YOU to become the next salesforce.com. 500 applications have been deployed; they are getting over 50 new applications up each month. 

A lot of this will shake out in 2007. Dialogs like this one will be key to managing the transition to this new opportunity. I'm looking forward to it!

Congrats to Rafer and MyBlogLog!

It's official, Mashery Co-Founder and Board Member Scott Rafer has successfully closed the sale of MyBlogLog (of which he is CEO) to Yahoo! It's been great fun watching the process - he met the MBL founders through LinkedIn and convinced them to morph what was a simple analytics play into an innovative approach to building a social network.

At the recent Web 2.0 Conference, I was camped in one side of the First Round Capital Pavilion talking to people about Mashery, while Scott held court across the room and received a steady stream of Yahoos, each of whom would watch the demo and return a few minutes later with others who wanted to see it. The last demo was given to Yahoo co-founder David Filo, and then the corp dev people took over. The deal took some fascinating twists and turns along the way, and the end result was a happy one for all concerned.

Scott and I first began to collaborate almost seven years ago. I look forward to many more years of working together with him. I'm excited that, with this deal closed, he'll be able to focus more effort on Mashery. Today, though, is a day to celebrate his success, and that of the rest of the MBL team, several of whom have helped us out a lot with Mashery. Congratulations to all of you!

When how you launch is bigger news than what you launch...

...you know you must be at web 2.0!

Mashery's launch covered in the Chronicle blogs and on Christine's blog.

Photo is of the House of Shields bar, directly across from the conference hotel entrance.

APIs and Developer Communities In Manufacturing

One of the bloggers who took note of yesterday's launch was Gary Mintchell, who blogs about manufacturing automation and asks what role APIs play in that area. I look forward to watching that discussion play out on his blog and in other communities. It reaffirms my belief that the trend toward offering APIs extends well beyond the "traditional" web service providers and sectors.

Eric Murphy left an interesting comment on Gary's post, addressing the need for standardization (which I agree with) and, in line with Mashery's mission, the need for documentation and community building. The latter point was made very well:

Many APIs are poorly documented, and have little to no sample code, testing tools or use cases on how to properly implement them, so I understand the business case for these API management services. However, in my experience, those APIs that are poorly documented are often poorly written. If a company has not put the time and effort into ensuring their API is well designed, documented and easy to use then ...[h]iring a third party company to put a slick face and documentation on it will not make the underlying API any better...

I couldn't agree more, though I am a bit more optimistic. We are in the early stages of the API world. I have spoken to many companies who have put out great APIs, but don't have the documentation and support done. The engineers and product people who build the APIs are generally not responsible for documentation and support - so you need a different arm of the company to do that, and that generally means resources (people and money) need to be committed to that effort. Companies are still figuring out how to do this; Mashery's point of view is that if you provide a set of tools optimized for this purpose, it will get better. The company can provide the framework, documentation, moderation, and a consistent experience, and if that is done right, the developer community will join in with more sample code, peer help, and feedback for the company. 

And we go one step further, since we're offering all of these community tools to any API developer program at no cost. We want to encourage the growth of the overall web services/API market, which (we believe) will only happen if strong developer communities emerge and grow.  And that's something we will all benefit from.