Rackspace’s 43,000 cloud-computing customers played a major role in the API specifications. They overwhelmingly preferred the newer lighter-weight REST approach to the older heavy-duty SOAP standard that Amazon uses.

The move follow Eucalyptus being made part of Ubuntu Server, but it will certainly help spur enterprise acceptance of cloud computing, and could also help reinforce Amazon's APIs as leaders in the space. The software is available under the simplified BSD license.

Software companies that provide alternatives to Microsoft Exchange have reported "significant gaps" in the application programming interfaces (APIs) recently published by Microsoft for its volume server products.

When I think of the online storage market, I primarily think of 2 1/2 models. The first is the one that's for developers: services like Amazon's S3 or AOL's X-Drive where, through APIs that are programmatically accessed by their applications, software developers hardwire their software to the storage found in Amazon's datacenter instead of wiring their software to a server in their own datacenter.

As Danny highlights in the latest instalment of This Week's Semantic Web, Marc Andreessen has once more demonstrated that he's not content with co-authoring Mosaic, sneaking around in the 24 Hour Laundry and driving social networking Ning-style. Far from it, as he continues his recent practice of blogging thoughtfully on issues facing the industry of which we - and he - are part. Yesterday's post, The three kinds of platforms you meet on the Internet, touched on a number of issues that we've addressed here on Nodalities before, and it is well worth both reading and thinking about.As Marc suggests in his introduction; “One of the hottest of hot topics these days is the topic of Internet platforms, or platforms on the Internet. Web services APIs (application programming interfaces), web services protocols like REST and SOAP, the new Facebook platform, Amazon's web services efforts including EC2 and S3, lots of new startups talking platform (including my own company, Ning)... well, 'platform' is turning into a central theme of our industry and one that a lot of people want to think about and talk about. However, the concept of 'platform' is also the focus of a swirling vortex of confusion -- lots of platform-related concepts, many of them highly technical, bleeding together; lots of people harboring various incompatible mental images of what's about to happen in our industry as a consequence of various platforms. I think this confusion is due in part to the term 'platform' being overloaded and being used to mean many different things, and in part because there truly are a lot of moving parts at play that intersect in fascinating but complex ways.”How true. The Platform space is a great one to be in and it's brimming over with opportunity and potential; so much so that we're one company staking an awful lot upon the detail of our Platform vision. Traditionally sloppy use of language, however, has led to a situation in which unnecessary confusion is now associated with a superficially straightforward term. Some of this confusion is introduced by innocent drift in the evolving usage of a word, but far more is down to the unfortunate fashion for everyone jumping on the bandwaggon and unleashing a 'platform' of their own. At least we've been using the Platform label for our own endeavours in this area for a number of years.In his attempt to introduce some clarity, Marc's post reiterates his basic definition of an internet platform; “A 'platform' is a system that can be programmed and therefore customized by outside developers -- users -- and in that way, adapted to countless needs and niches that the platform's original developers could not have possibly contemplated, much less had time to accommodate. We have a long and proud history of this concept and this definition in the computer industry stretching all the way back to the 1950's and the original mainframe operating systems, continuing through the personal computer age and now into the Internet era. In the computer industry, this concept of platform is completely settled and widely embraced, and still holds going forward. The key term in the definition of platform is 'programmed'. If you can program it, then it's a platform. If you can't, then it's not.”Check.He then offers three 'kinds' or 'levels' of Internet platform, being careful to stress that one is not necessarily better than those it supersedes; “I call these Internet platform models 'levels', because as you go from Level 1 to Level 2 to Level 3, as I will explain, each kind of platform is harder to build, but much better for the developer. Further, as I will also explain, each level typically supersets the levels below. As I describe these three levels of Internet platform, I will walk through the pros and cons of each level as I see them. But let me say up front -- they're all good. In no way to I intend to cast aspersions on what anyone I discuss is doing. Having a platform is always better than not having a platform, period. Platforms are good, period.”Marc's three levels are;Access API “Architecturally, the key thing to understand about this kind of platform is that the developer's application code lives outside the platform -- the code executes somewhere else, on a server elsewhere on the Internet that is provided by the developer. The application calls the web services API over the Internet to access data and services provided by the platform -- by the core system -- and then the application does its thing, on its own.”Plug-in APISuperficially very similar to the 'Access API', but the host application (such as Facebook) into which a developer's application connects does the vast majority of the work around marketing; “Facebook provides a whole series of mechanisms by which Facebook users are exposed to third-party apps automatically, just by using Facebook.”Runtime Environment “In a Level 3 platform [such as Salesforce], the huge difference is that the third-party application code actually runs inside the platform -- developer code is uploaded and runs online, inside the core system. For this reason, in casual conversation I refer to Level 3 platforms as 'online platforms'.” “Put in plain English? A Level 3 platform's developers upload their code into the platform itself, which is where that code runs. As a developer on a Level 3 platform, you don't need your own servers, your own storage, your own database, your own bandwidth, nothing... in fact, often, all you will really need is a browser. The platform itself handles everything required to run your application on your behalf.”And there's more, and it's interesting stuff that Marc has clearly thought about long and hard.Reading - and rereading - Marc's post, though, I kept coming back to ideas touched upon in two posts of mine about the relative openness of different Platform solutions; “Facebook and Talis might very well be offering 'Platforms', but they're quite different in intention. Facebook's platform seems to be all about making the Facebook site as rich, compelling and sticky as possible; everything is sucked to one point. The Talis Platform, on the other hand, is about providing developers - wherever they are - with the tools and capabilities to easily link and manipulate data across and through the web. The former sits heavily 'on' the web, and feeds upon it to suck ever more into its maw. The latter is truly 'of' the web, giving a distributed community of developers and users powerful new capabilities to enmesh their applications, and to deliver capabilities at the point of need.”Regardless of its position in Marc's levels, I truly hope and believe that the Internet platforms of long-term viability will be those that embrace the Network rather than feeding rapaciously upon it; those that are of the web as we are trying so hard to be.A Platform should give the developer a helping hand. It should lift them up and provide them with a set of tools that make it easier to concentrate upon and deliver their core value whilst the Platform worries about the day-to-day mundanity that is mere context [to paraphrase Geoffrey Moore]. A Platform should enable the developer to realise the benefit of those tools and capabilities in places and manners of their own choosing, rather than expecting or requiring the developer merely to expose their assets within the bounds of whatever site(s) the Platform chooses to offer. Platform providers who realise and embrace that will be the ones to succeed.

I've been hiding in meeting rooms muchof yesterday and today, talking with the press about this week's announcementsand the state of the market. Yesterday afternoon, I met with threeJapanese journalists for what was one of the best interviews I've donein a long time.These guys were prepared! Theyhad excellent questions which reflected the Japanese cultural tendencyto think long-term and in multiple directions. I don't speak Japanese,but I know a few of the key phrases and intonations of the language. Combinethat with the "Engrish" (romanji character) pronunciation ofmany of the technical words, and I was able to understand most of the questionseven before they had been translated. The eye contact was intense,the laughter reflected in the creases in the corner of the eye, and itall worked despite my constant reminder to myself to say "hai"at appropriate points and never to use the word "no".So what was the question worth blogging? It was, essentially -- four years ago, you announced a J2EE-basedcollaboration strategy. It was a two-lane highway. Today wehear a lot of news about ongoing investment and enhancement in the coreNotes/Domino technologies, and no two-lane highway. What has changedand why?I love this question (and I told theJapanese that I do). The question is asked at user groups, by journalists,by CIOs. It requires a philosophical answer, but is one that I getasked enough that I've honed the philosophy.When Al Zollar stood on that stage fouryears ago and announced collaboration for J2EE, a number of things drovethe decision. The primary two still make perfect sense today. 1) Software is becoming componentized. You can see it in the way IBM and others build solutions today.The new Sametime uses an Eclipse framework, a Codec from someone else,etc. Making components to provide collaborative capabilities is agood idea. 2) J2EE, or alternatively .NET, havebecome the primary languages for application developers. The forecastin 2002 was that by 2005, 80% of all new apps would be written in one orthe other. I don't think it happened that way -- for a variety ofreasons, I think the number is lower. But it is still a fact thata new computer science graduate from unversity is more likely to be focusedon Java or .NET than anything else. And convincing them learn todevelop in Domino Designer is a challenge, because it's "proprietary"to one (albeit incredibly popular) platform.So we had to start getting behind oneof these development platforms, and as IBM, it makes sense that we choseJava. The Workplace Collaboration Services, and many of the Workplace-brandedproducts, reflect this. But a funny thing happened on the way toJ2EE-based collaboration -- market adoption of Notes/Domino continued,and more importantly, existing customers grew their Domino investmentsthrough larger user populations and increasing numbers of applications.The problem with the "two-lanehighway" was that there was an implication you would eventually haveto move to the other lane, and it would take some superhuman feat to doso. There's no ROI in migration, and IBM -- unlike our primary competitor-- just don't believe in it. So instead of following separate andparallel development paths, we started finding ways to integrate the new,Java-based, componentized technologies with the existing Notes/Domino products.This results in several things you saw/heardyesterday -- at the client side, Notes integrates with the Workplace ManagedClient as a plug-in. The next version of Domino will integrate portaltechnologies into the server. They are still Notes and Domino-- running every Notes application that you do today, with no architecturalchanges required. But now we integrate the Activities model intoNotes; we integrate the components into Notes (Sametime 7.5 will providethe IM plug-in for Notes "Hannover"). It becomes the bestof all worlds -- continuing investment and innovation for the productsin use by 61,000 customers today, while adopting for the "nextgen"of Java-based programming. Tools like IBM Workplace Designer helpbridge the two, by providing a Java-based development tool that works likeDomino Designer. In a future version, it will even build rich clientapplications.I have been at Lotus through this entiretransition and journey. And when I see what the development teamhas done to leverage our strengths and heritage, combined with toolingfor the future, it makes me incredibly proud to be a part of all of this. We're doing what's right for customers, not just what's convenientfor us (whehter that be a 64-bit migration or an obsolesence of existingproduct APIs). It takes more work, but the best and the brightestare making it happen. And the best part is, it has made Notes evenmore powerful, and more useful, for the next sixteen years of its lifecycle.

Channel9 is featuring its first-everinterview with an Exchange guy. Some great quotes in there: "Almost everybody uses Exchange,they just don't know it" "So far we've given developers42 different APIs...developers have found that confusing""My e-mail server might be down....yup,it's down"Yet at the endthey come back and say that Exchange is stable. heh.Seems like a lot of the "innovation" in Exchange 12 is catch-upwork -- full-text search, incremental backup, typeahead addressing in OWA. All this requiring a hardware upgrade, dropping or stabilizing allexisting APIs, and dropping active/active clustering. At least ayear away. As for "almost everybody uses Exchange", the speaker quotes Gartneras saying that Exchange runs more than half of all business e-mail mailboxes. I haven't ever seen a report like that.(Thanks, Bruce)