Alex Barnett blog : Google

Open Source in a SaaS World

alexbarnett — Fri, 16 May 2008 03:01:00 GMT

About a year ago, I took part in a meeting where the question: "What does open source "mean" in a SaaS world?" came up in conversation.

A year later, that same question is becoming increasingly pertinent as the IT industry's move to Software-as-a-Service (SaaS) and cloud-based computing accelerates.

For Bungee Labs (I work there), where

we provide an entire platform-as-a-service (PaaS)
developers create, share and re-use code and deploy apps in the cloud
developers "consume" and program against third party web apis and will create their own

...the "meaning" of FOSS is central within these different contexts and has many possible answers with many non-trivial implications...Three dimensional chess as it were.

(pic source: Memory Alpha, the Star Trek wiki)

For this post, I want to share some of the considerations relating to # 1) above: the context of open sourcing Bungee Labs' own system (Bungee Connect). Last month we stated that:

"Bungee Labs is evaluating several Free and Open Source Software (FOSS) licenses for the software components that comprise the complete Bungee Connect system. However, the task of reviewing the various FOSS licenses, and then identifying which of them best aligns with the software components and subsystems created by Bungee Labs–as well as ensuring compatibility with third-party components upon which Bungee Connect relies–requires considerable review and source code preparation. And we want to do this right, with the community’s involvement."

Since and before that announcement, Ted Haeger (who runs the Bungee Connect Developer Network) has been discussing some of the issues at hand and some of the options we see before us with some very "FOSS savvy" communities at events such as Socal Linux Expo, LugRadio Live USA and LinuxFest Northwest and of course with Bungee Connect's own growing developer community.

Today there's an interesting conversation going on between Ted and Simon Wardley, ex-COO of Zimki / Fotago who resigned last year over the company's decision not to open source their platform (the video of his announcement at a OSCON 2007 talk he gave "Commoditisation of IT and What the Future Holds" makes for entertaining and informative viewing all of its own...Simon discusses open source in a SaaS context. Update: Simon let me know of this video which also includes the slides

Anyway, back to the thread:

Simon wrote a post this morning providing his thoughts on the some the FOSS options available to Bungee Labs
Ted wrote back responding to Simon sharing his point of view
Then Simon responded to Ted

All three posts (and more to come no doubt) make an informative and interesting read, but I want to highlight one of the key issues in discussion.

The SaaS Loophole

The issue goes back to the question: "What does open source "mean" in a SaaS world?" and specifically the licensing issues. I'm going to quote and edit from Ted's post somewhat liberally (Ted owes me a Sushi, so we're quits now :P ) and isolate an (if not "the") open source licensing issue in the context of SaaS (my emphasis):

"Personally, I think that GPLv3 is the wrong license for freeing any SaaS or PaaS offering. The Free Software Foundation has a better license for this purpose.

GPLv3 is inadequate because it does not mandate that modifications that others make be opened. Originally, GPLv3 was planned to close up the “SaaS Loophole” (a.k.a. the “ASP Loophole”) in GPLv2. However, as I understand it, several large companies pressured the FSF to remove the key clause that would have closed the loophole.

What is the loophole? It’s this: if you take free software and offer it as a hosted service, then you are not conveying the software, and are therefore not obligated to reciprocate your modifications to the original code. In the context of service providers, GPLv3 is effectively the same as the BSD license. Many companies, Google among them, live inside this loophole. (For now, Bungee Labs is also in that camp.) Some remain there deliberately. Others are in it simply as a matter of course…that is, where they are in their business development process."

So that's the "SaaS loophole". Where's the loophole now? Ted explains:

"Perhaps the argument could have been made in the age of GPLv2 that the SaaS Loophole was an oversight, but now that GPLv3 has the loophole by design, it’s really no longer a loophole. The latest version of the license supports the practice. (And just to be clear, I am not advocating this for Bungee Connect.)

...Say Bungee Labs opens Bungee Connect under GPLv3. Is there a danger that small companies could replicate our offering? I don’t think that’s the case. But could a well-funded company do the same, fork the code, and then fund an engineering team to outpace the original inventors?

...The Free Software Foundation also provides the GNU Affero General Public License version 3, or AGPLv3. AGPLv3 specifically closes the SaaS loophole. Instead of being triggered by conveying the software, AGPLv3 is triggered by accessing the service. This helps to reduce the risk that a company could not branch the code and then out-engineer the originators, as the vulture company would be obligated to share-alike terms with their derivations."

So, is the AGPLv3 the right license for Bungee Labs to pursue? Is it the right license for SaaS providers? Is it enough on its own? (back to Simon Wardley's point in his post). Each company has their own unique circumstances and they each need to think through the 3D chess game. We're still working it out at Bungee Labs.

For us at least, I think some of the potential answers are becoming clearer, and others not yet. But it is the kinds of discussions that Ted is having with Simon that are a critical part of Bungee Labs' decision making process around FOSS. It cannot be an insular process.

Chris Anderson: Charlie Rose interview discussing FREE

alexbarnett — Sat, 03 May 2008 16:51:00 GMT

I spent some time this morning watching the Charlie Rose interview with Wired's editor, Chris Anderson, discussing FREE.

The interview covers the economics and ideas driving the Internet's current (and future) state: the Gift Economy; the Attention Economy; and the Reputation Economy. Rose leads the conversation into topics such as covering the Freemium business model and consumer perceptions about the value of privacy (or lack of thereof).

The interview also moves to the topic of the Yahoo! and Microsoft merger. Rose asks: "Why is it that Yahoo! can't recruit the people at Google - through some extraordinary salary offers - that would let Yahoo! replicate what Google has?"

Anderson's answer (paraphrased): "There is a basic philosophical difference between Google and Yahoo! Google is a Machine company. Google believes that data, machines and the Algorithms will drive the company's growth. Yahoo! is a people company - it believes content created by people and the conections made between them with its drive growth."

"And what about Microsoft?", Rose asks. Anderson responds (again, paraphrasing) - "Microsoft is a pre-web software company that philosophically wants to be somewhere in between Google and Yahoo!" An oversimplified analysis, surely (hey, it's a TV interview answer), but I think the Anderson's conclusion is pretty accurate at its heart.

So what is this Platform as a Service thing?

alexbarnett — Tue, 08 Apr 2008 14:54:00 GMT

The "platform-as-a-service", or PaaS meme is getting more air play the last 24 hours as news of Google App Engine makes its way through the tech media and blogs. ReadWriteWeb has a good write up and Phil Wainewright's summation by declaring "Let the PaaS wars begin" I think fairly captures the mood and reaction to the news.

Exciting times ahead no doubt, and pretty cool that Bungee Labs is getting mentioned in a number of blogs reacting to the Google App Engine news an example of the new generation of companies emerging in the PaaS space.

So, what is Platform-as-a-service? And why is PaaS interesting? Last week I had the opportunity to talk to Dana Gardner and Phil Wainewright in this sponsored podcast - full transcript available here - all about PaaS. I've taken the liberty of copy and pasting a snippet of the conversation below that speaks directly to the whole notion and definition of PaaS.

"Gardner: Okay, we’ve established that the tide is turning to the Internet, that there are some great Web-based services available, that technologies are now bubbling up to allow for better and easier connectivity. And yet, there is still a need for the right platform and the right infrastructure to make this all mission-critical and enterprise-ready.

So let’s get into PaaS as a possible stepping stone that, in a sense, bridges the best of the Web-oriented architecture and the available SaaS and the APIs-world with what developers inside organizations -- be they ISVs, service providers, or enterprises -- need to make these approaches acceptable and within the acceptable risk parameters.

I noticed that Bungee Labs does not call this "Development-as-a-Service" or "Deployment-as-a-Service" or "Integration-as-a-Service" -- but "Platform" as a service. Alex, give us the primer. What does "Platform-as-a-Service" really mean?

Barnett: That’s what we are trying to define at Bungee Labs. PaaS is one of those terms that we’re going to be hearing more and more. And they are going to be different -- varying levels of definition and interpretation of what that means.

But what we’ve done is put a stake in the ground in this respect, and then saying that in order to really be a PaaS -- and not just any one of those single pieces that you’ve mentioned plus more individual pieces -- that you need to be able to provide the end-to-end services to really call it a "platform."

From the developer’s standpoint, which is the development cycle, this means the tools that they need to develop applications, to be able to then test those applications, to be able to connect to Web services and to combine them, and to have all those kinds of capabilities -- and to then deploy and to make those applications instantly available to the business users.

Literally, we mean a URL that is the end-point for the end-user. From that, they can start consuming the application.

So, PaaS means having an environment in which you deploy inherently and have built-in scalability, reliability, and security. Once you’ve deployed your application, you know that you don't have to take care of all the infrastructure in the datacenter and the capital investments and the bodies that are required to make it scale when newer applications increases in use.

There is also the ability to connect to the various distributed data sources or functionality that the application needs to be able to consume. You can get that inside of that platform, the ability to be able to do that in a Web-native way, and so take advantage of the architectures we descried earlier, such as SOA.

There is also the ability -- and we touched on it earlier -- for developers to be able to collaborate on projects that are built-out in the cloud. They can share code, check in code, do all the standard revisions and collaborative-type functionality that developers need when they’re working on projects with teams distributed across the world or across your offices. And they can do this without having that entire infrastructure on-premise.

And then, the last, but critical, piece is having deep instrumentation and an analytics ability around the use of the application -- of how it’s being used, of where the connections are -- right across the board from the "glass of the window," the browser, for example, and right on through to the Web services in the CPU, or the rest of it.

As a result, you are able to understand performance. You are able to understand your billing, if it’s a billing proposition that you have. And all of what I described is comprised within six pillars [of Bungee's offerings]. All of that is delivered and available purely as a service, so there are no on-premises requirements for any of those components across the development and platform used in a utility model. You use it as much as you pay for, or as much as you use in a utility-based model -- all in the cloud. No bit needs to be installed on any machine at the enterprise in order to take advantage of all those Web services and functionalities.

Gardner: For our listeners who are just getting used to this concept of PaaS, let’s just get right in quickly and describe what Bungee Labs is. It’s a young, innovative company. And you’ve come out with a service called Bungee Connect. This is essentially one place online where you can go to develop, mash up, and access data, to put together Web-based applications and services, and then instantly -- with a click of a button, and perhaps I am oversimplifying -- develop and deploy in basically an integrated continuum. Is that correct?

Barnett: Yes, and provide very rich user experiences as part of that, with highly interactive application functionality. We’ve built out essentially that stack that I’ve described earlier. We've made that available for organizations to take advantage of. We're specifically targeted at developers who really want to be able to build very sophisticated Web applications that leverage orchestration workflow around connecting to Web services.

We are not in the business of being able to provide non-programmers with the ability to do these nice simple mashups.

Gardner: Well, if you can do that, let me know, because that would be a very good trick. I am sure the world would love to have development by anybody!

Barnett: Yeah, and that’s a great dream to be able to have, but inherent in that is inflexibility, because you are simplifying it all for the end-user. What we really offer is for the developers who are tasked with building sophisticated Web applications to do just that, deploy that, and then deliver very rich user experiences out on the Web.

Gardner: And to be clear, this is not just open source. This is commercial code, if they wish. The people who develop on this system, that code is their intellectual property. Is that right?

Barnett: The intellectual property of the code that is developed by the developers is absolutely their own intellectual property and remains so. We do have a community side of things that allows developers -- just as in the open source world -- to be able to share code and even entire applications as open source running on our grid.

But in terms of a company, it’s entirely their intellectual property that they developed and they are able to literally export the code. And if they want then re-factor that for a different kind of a grid or runtime, it’s their property.

Gardner: Phil, how do you see the relationship between PaaS and what Bungee Connect is doing, and then the larger SaaS trend? Do you see a relationship of one aiding and abetting the other? Or are they in separate orbits? How does that work out?

Wainewright: I think they are very much in a similar orbit. And to an extent, I don't think of PaaS as being part of SaaS or vice versa. It’s just everything moving to the cloud. These are two examples of that happening.

One of the things I want to highlight, as Alex was saying, is the useful experience. When people start developing for the Web, for the cloud, then it’s not just building the infrastructure -- it’s also learning what is involved in writing applications for that environment.

There is much more emphasis on the user experience. There is much more emphasis on reusing what other people have done, whether it’s by mash-ups or by reusing other people’s code, as opposed to reinventing the wheel every time. There is much more emphasis on developing applications and programs that can adapt and change to future opportunities in business conditions.

All of those things also have to be learned, at the same time as building the infrastructure. Using PaaS enables you to tap into that shared expertise in a way that you can’t do, if you try all by yourself.

The other thing that’s happening here is that we’re connecting into the resources of the Web, and getting onto the Web, so that we can interact with partners and customers and connect into those other Web resources. This is what we're really expected to do as businesses today, in order to stay competitive. So, there’s a tremendous pressure building to be able to do this kind of thing.

Now, there are three ways you can get onto the cloud. You can go to a cloud-computing provider and basically build your stuff in that cloud, which gets to some of the infrastructure, but, there's still the issue of how do I write applications in this environment and connect to other client resources.

Second, you can go to pure SaaS whereby you get a ready made application and you can do some customization, but there are going to be quite a few gaps around what that provides and what you actually want to do. There are going to be quite big gaps in terms of integrating that into your existing on-premises applications and to the other client application that you use.

Third, where PaaS comes in, it allows for the ability:

A) To get much faster to the custom applications that you need to build for that environment

B) To do the integrations to fill in the gaps and to access other SaaS applications and services, and to patch and connect back to the existing on-premises applications. "

Full transcript available here and podcast here. Bungee Labs' definition of Platform as a Service here.

Sync Google Calendar with Outlook and more with WideLens

alexbarnett — Thu, 06 Mar 2008 05:37:00 GMT

Google has just released a very cool utility (.exe download for Windows) providing users with the ability to synchronize their Google Calendar with Outlook.

Some nice features in their 0.9.3.0 release:

schedule the sync frequency: every x minutes
define directional flow: 2-way, and 1-way (either way)

A bit of a buzz going on about this...

Now, what if you could do the same over the web - no download, just use your browser (IE, FF, Safari)...? And not just Google Calendar <> Outlook, but others too...?

Well, it's certainly possible...First, watch this screencast I put together tonight (apologies for sound quality...done from home equipment):

About WideLens

A couple of weeks back Bungee Labs released a reference calendaring application, called WideLens, designed to show off some of the power of the Bungee Connect platform, from the kind of rich AJAX UI experiences delivered through to the high level of functionality developers can create by wiring up and integrating multiple web services and distributed web data sources into a single web app.

Video: WideLens User Experience
Video: Developer Overview

WideLens connects to Microsoft Exchange calendar, Google Calendar, Salesforce.com, Facebook, MySQL and iCalendar feeds, representing a variety of protocols and authentication schemes. MS Exchange is accessed through WebDav, Google Calendar through gData, Salesforce.com via SOAP, Facebook through REST and MySQL connectivity is based on client libraries provided by MySQL (integrated directly inside Bungee Connect).

WideLens is an uber-mashup.

WideLens connects to each of the sources in real-time, presenting the user with live data. With the exception of Facebook and iCalendar, users can create and modify events and those changes are immediately posted back to the source. MySQL pulls double duty, serving as both a WideLens native calendar source and as the persistence layer for all kinds of application data including user preferences and credential information for each service.

Developers: Have At it!

As mentioned above, WideLens has been released as a Bungee Connect reference application where we're encouraging Bungee Connect developers to customize the WideLens application as much as they want, deploy their own version of the app as their own app - to their own domain, at no charge, branded however they want and with whatever features / cuts / modifications / extended they want - the WideLens code is released under a BSD licence (read more here).

To get going with Bungee Connect and develop your own vision of what WideLens could do, sign up for your Bungee Connect account.

I think I might have failed the Turing test.

alexbarnett — Fri, 29 Feb 2008 04:08:00 GMT

I think I might have failed the Turing test.

Video demo: REST Describe & Compile for WADL

alexbarnett — Tue, 22 Jan 2008 01:08:00 GMT

In March 2007, I naively asked if REST needs a WSDL and if yes, was WADL the one (Web Application Description Language). The conversation goes on, but I thought the video below and pointers might be of interest to those who have an opinion one way or the other.

The video Google Chalk Talk was published last week and shows Thomas Steiner demoing REST Describe & Compile, an online editor and a compiler for REST Web services based on SUN engineer Marc Hadley's Web Application Description Language (WADL).

(huh? video not available as embeded??? wtf? Here's the link to it)

"ABSTRACT

REST Describe & Compile is an editor and a compiler for REST Web services based on SUN engineer Marc Hadley's Web Application Description Language (WADL). REST Describe & Compile is implemented using the Google Web Toolkit (GWT) and is split up in two sub-apps:
REST Describe:
This component takes a (set of) URL(s) as input and tries to analyze the parameters regarding parameter types and Web service structure. It then generates a WADL representation for the given URL(s), represented in an editable, tree-like form. Typical input would be GET
http://webservices.amazon.com/onca/xml?Service=AWSECommerceService=0ZMFM7HPBYYY0SPERCR2=ItemSearch=Enterprise+Integration+Patterns=Books
or GET http://picasaweb.google.com/data/feed...%7BuserID%7D/albumid/%7BalbumID%7D/photoid/%7BphotoID%7D?kind=kinds=0=1{userID}/albumid/{albumID}/photoid/{photoID}?kind=kinds=0=10

REST Compile:
This component allows for the WADL representation of a Web service to be "compiled" to working programming code in various languages (for the moment these languages are Java, PHP5, Python, and Ruby). The idea is thus similar to WSDL2Java, however in a more general WADL2Anything way.

The application can be tested online:
http://tomayac.de/rest-describe/latest/RestDescribe.html

There are some screencasts available on YouTube: http://youtube.com/profile?user=tomayac

Speaker: Thomas Steiner
Thomas Steiner works as a Customer Solutions Engineer from Barcelona, Spain, and has joined Google full-time only since October 1st. However, he has been with Google first as an intern and then as a temorary contractor since February 2005. During his time at Google, Thomas has created the Google APIlity PHP Library for the AdWords API, as well as the APIlity Agua Ajax application, which can be seen as an Ajax GUI for AdWords. From January 2007 till July 2007, Thomas did his Final Year Project with Google, where the REST Describe & Compile application was to be developed, hosted by Googler Patrick Chanezon."

Related, last week Assaf (a true web pragmatist) wrote in his post REST IDL, substance over style

"So far most of the suggestions I saw are turf wars in disguise, arguing for this syntax or that, but never for what it should describe. WADL so far looks like one of those best-for-my-platform choices, the constant mentioning of Microformats, which are not optimized for this task, is another danger sign.

It has to start somehow, but it better start with substance, not with style."

I agree with the last statement...

Now, I don't know if Assaf has seen the above video or not, and if not, whether the video would further sway him one way on WADL or not...anyone else have thoughts on what's in the video or tool demo'd, or WADL itself?

Podcast interviews - smart people in the world of the web

alexbarnett — Sun, 20 Jan 2008 15:41:00 GMT

One of the fun parts of my job at Bungee Labs is to partner up with Ted and interview some smart people in the world of the web. We publish these as a podcast series (the Bungee Line - podcast feed here) over on the BCDN blog.

If you have ideas about someone you think we should interview, let me know! We're focusing on topics we think web developers might be interested in the worlds of software as a service and web app development, in particular profiling web apis. Related topics are good too.

I've listed out below our most recent podcasts below...plenty more in the works (previous podcasts are listed here). Hope you like :-)

Alan Lewis on eBay Desktop and eBay APIs

"As product manager for eBay Desktop, Alan Lewis relies on the same web APIs that eBay makes available to all developers. In this edition of the Bungee Line, Alan tells us about what the eBay Desktop is, how it came about, and various details about eBay’s developer program and web APIs. We ask Alan about eBay’s position Oauth and on open source."

Toby Segaran on “Programming Collective Intelligence”

"Since the publication of his O’Reilly book Programming Collective Intelligence: Building Smart Web 2.0 Applications, Toby Segaran has become well noted for his ability to explain easily-understandable algorithms for the kind of deeply complex problems involved in social applications. Toby joins Alex and Ted to discuss some of the high-level concepts that he tackles in his book."

Jon Aizen of Dapper.net

"Jon Aizen joins Alex and Ted to explain how Dapper.net provides a no-fee tool for making almost any structured web site data accessible via a REST API. In a past life, Jon was involved in creating The Internet Archive. Jon also helps the Bungee Line introduce romantic intrigue into the podcast.

Punditry Alert! At the end of this show, Ted and Alex speculate a bit about Android, Google’s open source mobile device platform, the Apache License, and whether Robert Love is involved. Please consider this as another demonstration of Ted’s idiocy, brought to you by the Bungee Line."

Jeff Barr on Amazon Web Services (Part 2)

"In part 2 of our interview with Amazon Web Services evangelist Jeff Barr, Alex and Ted ask Jeff about Flexible Payment Service, virtual user group meetings in Second Life, the Startup Project, and pry at Jeff’s views of possible futures of technologies that developers might anticipate."

Jeff Barr on Amazon Web Services (Part 1)

"Developer evangelist for Amazon Web Services, Jeff Barr tells Alex and Ted about how he became a native Amazonian, his recent visit to “The Business of API’s Conference,” and a bunch of stuff on Amazon Web Services, including: Mechanical Turk, EC2, and S3. Additionally, Jeff explains the newly announced S3 Service Level Agreement*."

Podcast with John Musser of ProgrammableWeb.com

alexbarnett — Wed, 19 Sep 2007 16:38:00 GMT

A couple of weeks back John Musser of ProgrammableWeb.com joined me and Ted for a chat to discuss the state of web APIs and the API trends as he sees them.

We've now recorded the conversation and published as the first of a newly launched Bungee Line podcast series.

Topic covered include Facebook APIs, Amazon's recently launched Flexible Payment Service (FPS) , Google Base, Microsoft's Astoria and relational-data-in-the-cloud programming models and services, SaaS models and API SLAs, REST vs SOAP, "Closed is Still the Old Closed" and plenty more.

Thanks to John for his time.

6 Google APIs - the Lesser Known

alexbarnett — Thu, 09 Aug 2007 13:46:00 GMT

Adam Ostrow at Mashable has written up a non-technical introduction to Google's most popular APIs and links to some applications built using these.

His post prompted me to revisit Google's own Google APIs page this morning which lists some 36 services available to programmers. Although they are not all strictly APIs (some just provide RSS / Atom outputs) I thought I'd call out some of the lesser known Google APIs, six in all:

1. YouTube API

The YouTube video repository and user community are accessable via an API interface and RSS feeds (REST Interface or XML-RPC Interface) . Developers need a YouTube Developer Profile to gain access.

Example apps using YouTube API:

YouTube Coverpops
Creates a mosaic of video stills; mouse over the one you want to pop up and watch.
YouTube Badge Maker
Makes a code snippet that you can add to your website that shows stills from your six latest-uploaded videos.
Virtual Video Map
Integrates video location with Google Maps—click on the map marker to see a video from that location.
YouTube Video Gallery Plugin
Enables easy setup of video embeds and galleries into WordPress blogs, using video IDs.

2. Google Notebook API

Google Notebook is an online service (requires browser plugin) where you can store and organize clippings of text, images and links from web pages. The Google Notebook data API allows apps to view public notebook content in the form of Google data API ("GData") feeds such as request a list of a user's public notebooks, or query the content of an existing public notebook.

3. Google Search History Feeds - Feed your attention.

Not really an "API", but...you probably knew Google tracks your search history. Did you know you can track your "web history" via an RSS feed?

4. Google Checkout API

"Start selling on your website"

There are two types of Google Checkout implementation options:

XML APIs enable merchants to access all Google Checkout features. XML implementations are recommended for merchants who need to be able to digitally sign orders before sending them to Google. XML implementations are also recommended for merchants who want to offer coupons or discounts and for merchants who plan to integrate Google Checkout with their internal order processing and billing systems.
HTML APIs enable merchants to send information to Google Checkout and receive information from Google Checkout using name/value pairs rather than XML. HTML implementations are recommended for small merchants who do not want to generate XML. Merchants can not digitally sign orders in HTML implementations, so merchants who use this implementation should plan to review orders manually.

Example of companies using Google Checkout include the merchant Skates.com and ecommerce solution company Volusion (see this article at ecommerce-guide.com).

5. Google Mapplets

Google Mapplets are mini-apps that can be embedded within the Google Maps. This implementation has examples include Gas Prices, Crop Circles (!) and real estate search. "Mapplets" are Google Gadgets that can manipulate the map using Javascript calls that are derived from the Google Maps API - but beware, there are differences.

(update: Read/Write has just written up a post covering some uses of Mapplets here.)

6. Google Talk XMPP

Developers can integrate their own applications into the Google Talk (its instant messaging service) connect (federate) their service with Google's (allowing "service choice". The "XMPP" bit of Google Talk is used for voice signaling and peer-to-peer communication...in addition, Google plans to support SIP signaling in the future.

Today, the Google Talk service is built on the following open-source protocols:

XMPP - Extensible Messaging and Presence Protocol; an IETF standard for instant messaging. XMPP was originally called Jabber, and the XMPP enhancement proposals were previously called Jabber Enhancement Protocols (JEPs). They are now called XEPs.
Jingle - A family of XMPP extensions that make it possible to initiate and maintain peer-to-peer sessions. Specific Jingle extensions support voice streaming, video streaming, and file-sharing sessions. (Watch out for the Google-specific non stardard XMPP extensions)

I could only find three mashups as examples using the Google Talk service (courtesy of ProgrammableWeb) - Gtalkr, Imified Instand Messenger Buddy and Jabber Google Map.

Google Maps API support for the hCard microformat to Google Maps results - jolly good!

alexbarnett — Tue, 31 Jul 2007 21:37:00 GMT

The Google Maps API blog has announced support for the hCard microformat to Google Maps results.

I won't go into why I think this is cool right now (no time!), but it is cool. If you haven't heard of microformats or understand why the standard is getting attention from a huge player like Google, then check out the links and the microformats podcast I did about a year ago.

RESTpectful comparison of Microsoft's Astoria and Google Base Data APIs

alexbarnett — Fri, 13 Jul 2007 06:36:00 GMT

Dare has written up RESTpectful comparison of the programming models of Microsoft's Astoria and Google Base Data API for querying relational data over the web (RESTful data services).

Both these APIs also happen to support operations for changing the data - inserting, updating, and deleting - Google's details here and Astoria's in this .doc, where in addition Astoria allows associations between entities to be created and deleted). These aren't mentioned in Dare's analysis (I'm sure he knows of the ability to change the data via the APIs, not just query), however the article is worth a read nonetheless.

More Google / Salesforce.com partnership rumours

alexbarnett — Sun, 03 Jun 2007 03:21:00 GMT

It looks like the Google / Salesforce.com partnership rumours are stirring up again this week, with a conf call scheduled for this Tuesday AM causing the renewed suspicions.

Normally, I wouldn't be so interested in "gossip" until I hear actual announcements made, however this potiential partnership intruiges me. Some of the speculation reported this weekend includes variatons on the following themes:

Integrating Google's Apps suite with Salesforce.com's hosted CRM
Google potentially looking to acquire Salesforce.com at some point
Google to get an anti-Office toehold in the enterprise out of the deal and Salesforce would get an in with SMBs
Apex, Salesforce's software language, might be part of the deal and be used to create business applications for AppExchange, Salesforce's online marketplace for third-party software programs

Given previous partnership efforts between Google and Salesforce.com around Google's Search Appliance and AdWords, Salesforce.com's focus on the SMB space and Google's intent to develop further its B2B market opportunities, I'd say #1 is most likely, #3 would make sense but I don't see how the pieces would fit together, #4 as unlikely and #2 (Google acquires Salesforce.com) as highly unlikely. I'd also add my speculation - that new APIs might be announced as part of whatever the news is on Tuesday.

Update 6/4/2007:

The actual news turns out to be much less interesting than the speculated outcomes: Adwords integration with Salesforce Group Edition.

At Google Developer Day 2007

alexbarnett — Thu, 31 May 2007 18:09:00 GMT

I'm at the San Jose-based Google Developer Day, hearing more about the news that's been getting the blogosphere and media pretty excited, especially the news of Google Gears - their first foray into the Occasionally Connected Computing space (or RIA), a model that's getting more and more interest by those wanting a piece of the developer hearts and minds.

Philipp Lenssen was at Hamburg's Google Developer Day event earlier today where he has written up his reaction to the news and Robert Scoble has a useful summary of the various Google announcements.

Gears is definitely interesting, but the Google Mashup Editor story provides further clues as to how the "widgetsphere" wars might play out over the next couple of years.

Google Mashup Editor

In the scenario they demo'd of Google Mashup Editor they showed how ~~are mashup can built~~ a mashup can be created that consumes a feed from an external source, overlays that data's feed over Google Maps, how a simple UI interaction be defined (click and focus on map) and then lets a user search Google Base. You can then deploy the mashup on Google infrastructure that will then serve your app from their servers. It's a text-based programming UI (coding in html + JavaScript + CSS + "extended XML tags") - all through the browser. You can see the product tour here.

As Tim Heuer notes, it's in beta.

The session closed with Sergey Brinn making a brief appearance - no announcements, no news - more of a "thanks for being here".

Let me know if you're also here at San Jose.

Update 6/3/2007:

I missed this bit of news on the day - Google launched a Directions API, allowing third-party sites to offer directions directly on their site. Via Mashable:

"The API features include the ability to request directions between a pair of points or a longer sequence of points, and multiple language support like English, French, Spanish, German, Italian and Japanese.

Google has launched a Directions API at its Developer Day, allowing third-party sites to offer directions directly on their site.

The API features include the ability to request directions between a pair of points or a longer sequence of points, and multiple language support like English, French, Spanish, German, Italian and Japanese."

Also, Stephen O'Grady of Redmonk has written up an excellent analysis on Google Gears.

Microsoft grew a whole Google last quarter

alexbarnett — Sat, 28 Apr 2007 04:23:00 GMT

Good thing I held on to those MSFT stocks - Microsoft grew more than a whole of Google's sales this last quarter:

"Of course, even Microsoft's growth pales in comparison to Google's, which posted a 66% rise in sales in the quarter, from $1.5 billion to $2.5 billion. But Google is still, of course, a much smaller business, and it's worth noting that the $1 billion that it added to its sales is a fraction of the $3.5 billion that Microsoft added. To put it another way, the increase in Microsoft's sales during the quarter is greater than Google's total sales - by far ($3.5 billion vs. $2.5 billion)."

Microsoft and Google join OpenAjaxAlliance

alexbarnett — Wed, 21 Mar 2007 15:25:00 GMT

I missed this yesterday, but biggish news in the Ajax-o-sphere - Brad Abrams and Brandon Le Roy announced Microsoft is joining the OpenAjaxAlliance. From the press release:

""Microsoft is joining the OpenAJAX Alliance to collaborate with other industry leaders to help evolve AJAX-style development by ensuring a high degree of interoperability," said Keith Smith, group product manager of the Core Web Platform & Tools to UX Web/Client Platform & Tools team at Microsoft Corp. "By joining OpenAJAX, Microsoft is continuing its commitment to empower Web developers with technology that works cross-browser and cross-platform.""

This OpenAjaxAlliance blog post also mentioned the confirmation of Google's membership, joining a growing number of Ajax players (full list here).

In case you are wondering what the OpenAjaxAlliance is, here is the blurb on their site:

"The OpenAjaxAlliance is an organization of vendors, open-source initiatives and Web developers dedicated to the successful adoption of open and interoperable Ajax-based Web technologies. The alliance's prime objective is to accelerate customer success with Ajax by improving the customer's ability to mix and match solutions from Ajax technology providers and helping to drive the future of the Ajax ecosystem. "

In a nutshell, Interop.

Thanks to Tommy for the heads-up.