Cocomo

What's in a name? When we first started, Cocomo (Common Collaboration Model) was the codename that we used internally, which also became our public identity. But, we also started to realize that it's heavily overloaded; between the Beach Boys song, the Constructive Cost Model (COCOMO), and our personal favorite, the Cafe Cocomo -- a salsa dance bar that is literally a mile from our office... it's not a name we could really call our own.

As we get closer to offering the service commercially, we knew it was time to adopt a corporate name. We believe the Platform as a Service we're making should be in the toolbox of any Flash/Flex developer, so we wanted "Flash" in the name. From there, it was a matter of describing what the offering is : Adobe Flash Collaboration Service.

Taking on a "real" name is the first in a series of steps toward commercial availability; there's still lots to be done. We wanted to give a look at the AFCS roadmap for the upcoming months, with a rough chronological order:

Proposing the pricing model we've been working on
Putting it out there, and taking feedback. We think we've got something that will work, but we want you to be the judge. We'll be kicking off discussions around this in the next few weeks.

Expanding the availability of early commercial adoption
We've been working with some "lighthouse" customers to validate the technology and the business plan. We're going to open this up some more and let more people build commercial applications w/ AFCS, before it's broadly available.

Working on server-to-server management APIs
We know that developers want to be able to remote control more processes in their AFCS rooms. We've got some plans to allow "bots" in rooms, automate more tasks via HTTPS, and generally make it easier for developers to integrate their back-end business logic with our real-time sessions.

Building an eCommerce infrastructure for services
How many developer services does Adobe currently sell? That's right, none. We're working with various teams inside Adobe to get the mechanics in place so that we can actually charge for usage of AFCS.

Taking a serious look at recording and playback of data and A/V streams
We can't promise that this will happen very soon, but it's something we're actively working on prototyping. Lots of interesting (hard) problems to solve before we can really offer this as a service.

Continual improvements in RAS (Reliability, Availability, and Scalability)
Before we start charging, we want to keep ensuring we've got a rock solid backbone. So far, so good during beta, but we're always working to make sure we can handle demand.

…all the while, we'll continue to take feedback from our forums and add new functionality to the service. As you can imagine, schedules are notoriously hard to predict, but we'll do our best to be open about our priorities and progress.

Thank you all for your help and continued support!

Hi, my name is Varun Parmar and I recently joined the Cocomo team as a Product Manager. From the get-go I've been amazed by the opportunities Cocomo enables for developers and my goal is to leverage my blog postings to engage in regular discussions with you on the business aspects of Cocomo.

New and exciting Cocomo-powered applications are springing up daily and as we look at these applications we can't stop but ask ourselves the parochial question - What type of applications will truly benefit from the rich set of features that Cocomo offers? It's hard to wrap our arms around this question primarily because it is a bit early - given that public beta was launched less than two months ago (whew, it feels like eternity with all the activity on the user forums!) - but there are a few key characteristics of these applications:

* Context-sensitive: It is imperative for some type of applications to ensure that the context is always maintained for the users. For example, if I'm a financial securities trader then it is critical that the live market data feed be displayed to me at all times and any other application that I may interact with be in-context to the market data feed. In other words, other applications need to be embedded into the primary application in a way that users perceive other applications as native to the primary application
* Mode of Collaboration: What is the preferred way to enable collaboration for the specific use-case that the application intends to address for users? Is it text-based chat, VoIP, Webcam video, or all of these? Augmenting the primary application with only those collaboration components that best meet the use-case needs provides a superior user experience
* Multi-user / Social: Some applications become inherently more useful when more and more people use them. Such applications benefit from the phenomena called network externalities. Example of such applications include today's popular social networks like Facebook where the social network becomes more valuable to me as more of my friends and family join the social network

We're taking the liberty to coin the term "In-context Collaborative Applications" which in our view defines the category of applications that exhibit the aforementioned characteristics. Interestingly if we look around we realize that most of today's collaboration-centric technologies and applications are out-of-context (E.g., a separate application window opens up for most text-based chat apps and popular softphones.) And herein lies the untapped and colossal business opportunity for you to develop a new well-differentiated application and/or extend your existing application by leveraging Cocomo.

So unlock your creativity and flex your imagination to come up with the next Cocomo-powered "killer app." Are you looking for ideas? Here are some high-level examples of In-Context Collaborative Application categories:

* e-Commerce Support (E.g., Shopping cart assistance, Payment and billing support)
* Interactive Dashboards (E.g., Decision support systems, Reporting systems)
* e-Learning Enablement (E.g., Multi-user whiteboard, Learner polling / quizzes)
* Social Networks (E.g., Presence, Chat - voice, video, text)
* Virtual Worlds / Casual Online Games (E.g., Enable multi-user interactions)
* Specialized Applications (E.g., Telemedicine)

Go ahead and show us the way! ...And let us know how we can further help you succeed!

Varun

ﾠ

Thanks to Ted, the mastermind/madman behind the idea, all our MAX sessions got recorded and are being posted to AdobeTV. As much as I hate the sound of my own voice, these recordings seemed to work pretty well =).

Real Time Collaboration Applications With Flex and Cocomo

The intro piece - this will show you what Cocomo is all about, as well as how to get up and running with it. You'll see code!

Cocomo Deep Dive : Building Social RIAs with Flex and Adobe Hosted Services

To me, this is the more interesting preso - shows you a reasonably difficult app, and some tips and techniques to building it.

Source Code for the Deep Dive Apps

Enjoy!

A quick post to recognize the crazy-amazing stuff we saw coming from France, specifically Monsieur Erick Ghaumez, this holiday season with Cocomo.

First up, umm.. a Lego Mindstorms Robot which uses a Wiimote and Cocomo to allow users to remote-control the robot across the Internets. Ummm... I have to say this was the least likely thing on my list of Cocomo use-cases, but I'm happy to be shocked!

Watch the video - Essentially, it starts with :

a) WiiMote talks to AIR App 1
b) AIR App 1 talks to Robot.

Then they kick it up to 11, and it's :

a) WiiMote talks to AIR App 2 (somewhere else on the Internet)
b) AIR App 2 talks via Cocomo across the Internet to AIR App 1
c) AIR App 1 talks to Robot

Also cool is that the webcam feed in the Flash Apps is used to allow the remote-controller to see what he's doing with the robot. There's a big "Sound" button there, but I dunno what it does...=)

Secondly, pour tous les francophones in the audience, Erick wrote 3 of the best, most comprehensive Cocomo tutorials I've yet seen online (yeah, it's been a month and a half since beta launch...), including a walkthrough of some of its core APIs, all hosted at Flashxpress. I know, the whole French thing might make it difficult for a few people to read.. Hopefully Erick and his team at La Fabrick feel generous enough to do a little translation for those less enlightened =)

Exciting times!
nigel

A quick Friday entry, with 2 subjects -

First up, I was doing some coding yesterday and wanted to call up the API reference for ConnectSessionContainer, one of the core classes I find myself using with Cocomo.. On a whim, entered "ConnectSessionContainer" in Firefox's search bar, et voila:

Yeah, ok, I might be one of the only people who finds this exciting, but others should at least find it useful.

More relevant for all those of you who've had account registration issues, do us a favor and try again today - we think we've found the issue, and have pushed the fix to production.

One of my favorite features in Flash Player 10 is the ability to stream live audio/video via RTMFP, including "client-to-client direct" streaming, and a sweet new voice codec, Speex. If you want access to these features, there's a way to try it all out in your Flex apps, right now.

First, let's talk a little about RTMFP, "client-to-client" (C2C), and Speex. Lots of new goodies to try, and they all have some subtleties. You can read the RTMFP FAQ for more detail, but let me try to summarize (and then, we'll build an app) :

:: Why RTMFP? Well, the Real Time Media Flow Protocol is UDP-based, rather than TCP-based. Why does it matter? Let's review our old CS Networking classes (way simplified, leaving a lot out) :

TCP is a higher-level protocol than UDP. Some of the features it adds are guarantees on packet delivery and order of delivery. This is accomplished via a system of acknowledgement messages (ACKs) and their evil brothers, messages indicating delivery failures (NACKs). UDP doesn't really have much of this - packets come in when they come in, and are released into the application level of the network stack without guarantees.

So why is UDP a better choice than TCP for live streaming? TCP is a *must* for something like file transfer, where losing any bytes leaves you with junk. For a live stream, however, if I (the receiver) lose a block of packets (say, 250ms worth), TCP would demand that we send a message to the publisher, asking for retransmission, and wait for that retransmission before playing *anything* further. Even if subsequent blocks come in in the meantime, I'm not playing them. So for the sake of avoiding a 250ms gap in audio, I've backed up the *whole stream* until I get it back. What's worse, on congested networks, which can lead to packet loss, all this ACKing and NACKing actually *makes the problem worse*, congesting the network further, and leading you down a vicious "NACK hell" spiral. Using a UDP-based protocol, such as RTMFP, allows for packet losses to be ignored (for cases like live a/v streaming), and for users to get on with their lives. Simply by using RTMFP, latency of audio drops significantly.

:: Why Speex? Speex is a much more focused codec than the NellyMoser codec in older Flash Players. It specifically targets voice encoding, meaning it can encode voice with higher quality, at a lower bitrate (win-win!). What's more, it's designed to be especially effective over UDP, meaning it handles lossiness relatively gracefully,

:: So, what is C2C streaming? Well, they won't let me say "P2P", because then people get visions of file pirating networks (and no, you can't get there from here). But essentially, RTMFP allows clients to stream live audio/video directly from themselves to the recipient, without going through a server. This has the obvious benefit of reducing latency, since you're likely to reduce the number of hops from source to destination. It also means that a hosted service, like Cocomo, doesn't have to maintain as much infrastructure to allow you to stream.

All this said, RTMFP/C2C isn't a panacea, and there are issues you'll likely encounter in the real world. But before discussing that, let's build an app! If you haven't yet, go get Cocomo, set up your FlexBuilder for Cocomo and FP10, and enter the following (use your accountname/roomname, username, and password) :

(download the file here)

Notice the magic here - in order to attempt RTMFP, enter 'protocol="rtmfp"' in your AdobeHSAuthenticator. This will route your traffic to one of our super-secret experimental RTMFP servers, if it's got enough capacity left. Eventually, all Cocomo servers will be of the super-secret RTMFP variety, and you won't need the parameter, but for now we wanted to separate pre-pre-pre-beta machines in our cluster out so that they need to be explicitly requested.

:: Pitfalls of RTMFP and Solutions (in Cocomo)

There are a couple of very interesting problems in using RTMFP. First of all, being UDP-based means that a lot of firewalls just don't allow it. It's pretty common to attempt the connection and fail. Cocomo works around this by attempting a couple of connections at the same time, with a couple of protocols. Whichever succeeds wins the prize of being your session's connection.

Secondly, even if RTMFP succeeds, this doesn't mean every client can use C2C streaming. Firewalls can allow UDP but get in the way of C2C, or, more commonly, publishers can run out of bandwidth; since RTMFP doesn't yet support application multicasting, the publisher essentially needs to pump out more bytes for every subscriber. At a certain point, the publisher's uplink just won't be able to handle it if too many people are on the receiving end.

Cocomo has a bunch of built-in smarts to handle these situations. It can tell if all your clients can handle RTMFP and/or C2C. If they all can, Cocomo's client classes come to this agreement via messaging, and all of them switch to C2C. If someone new enters the room who can't handle it, again agreement is reached among the clients, and they switch down to server-based streaming. Ditto if the number of receivers becomes too high. This is all done adaptively, as various conditions change, and you as a developer don't need to worry about it at all.

So, yeah, it's been fun playing with all the new toys. We still have some outstanding issues to resolve (flaky connections can still lead to sub-par experiences), but we're actively working on these right now. Eventually, we want to see a world where live streaming is a staple capability in any Flex app, and this new goodness brings us one step closer =).

I wanted to take a few minutes today to respond to Stefan Richter's thoughtful posting from last week, responding to our announcement of the Public Beta. I've always followed Stefan's blog pretty closely, and he's definitely on my "top Flash devs I'd like to have a beer with" list. So when he's got stuff to say about Cocomo, I listen.

Reading through Stefan's post, there are a few nuggets that were really satisfying (to me, and yes, I crave validation..).

"Having taken part in the Cocomo pre-release program I have had the opportunity to use the technology first hand and the team at Adobe (many of which are familiar faces) have done an incredibly good job. The platform cannot be faulted from a technical standpoint."

Thanks Stefan! More than anything, I've been focusing on the API architecture, designing the approach we take in exposing the Cocomo platform to developers. Hearing that someone at Stefan's level of experience with FMS thinks we've got a good technical foundation, to me, is nerd manna. To extend the pat-on-the-back-fest for one more quote (then we'll get to the real deal, I promise), I thought this was particularly gratifying - he describes how Cocomo development differs from FMS development :

"A key differentiators is the fact that Cocomo is a pure client side framework, meaning the developer has no access to the server side code. This is not a big issue since Adobe is aiming to provide all required functionality without the developer requiring access to any server side logic."

For me, having been in this game a pretty long time, I can remember when an idea like the above ("no access to server side code!") was laughable, something to be derided. Seeing the world slowly come to accept this idea has been a sea change that we're happy to be sailing in.

But let's not get too caught up in ourselves - Stefan has some pretty pointed commentary around Cocomo's positioning with regard to FMS :

" What concerns me are Adobe's efforts to push further into the domain of their own developers, and potentially competing with them on a playing field on which the referee may be playing for the opponent. I'm not yet convinced whether Cocomo will open more doors than it will close, and it is clear that any application built using Cocomo is competing with applications that were previously built with FMS. Undoubtedly this will drive some developers away from FMS since Cocomo is now the suggested way to build collaborative applications."

I'd like to hear something more clear on this from Stefan, but I can at least offer my point of view [disclaimer, I work for Adobe, but I am not Adobe]. I just don't see how Cocomo constitutes "competing with developers". If Cocomo is the right platform for an application (which it won't always be), then the developer has a choice to use Cocomo or not (be that FMS, LCDS, etc). At no point are we intending to get in that developer's way - we're not about taking away the option to purchase licenses of our server products! I don't anticipate a sudden flight away from FMS - there are tons of great products out there using FMS, and most will continue to do so.

The "referee" analogy seems really emotionally charged, but doesn't fit imo - I don't think there's a competition going on for developers' share of money. If a developer chooses Cocomo, she'll make money. If she chooses FMS, she'll make money. In some cases more, in some cases less, depending on the situation. So I think there's a difference in when you would choose which platform - but they're just tools in a toolbox. To parry with another weird analogy - this is like saying that the invention of socket wrenches hurt everyone who used open-ended wrenches; they do similar jobs, after all.

So, although the use cases have some overlap, I think that the situations and audience we're trying to reach with Cocomo are different than the ones FMS reaches out to. I think there will ALWAYS be a place for FMS - places where server side scripting is required, or a hosted service is unpalatable, or where really customized requirements just don't fit with Cocomo. But the flipside is also true - there will be developers who would honestly never consider putting real-time collaboration in their applications (or even using Flex, period), because it isn't cost effective for their use case or because it was something they weren't familiar enough with to try. These are devs for whom Cocomo is a natural fit.

This is an important point. We'd like to lower the barriers to real-time collaboration, and hosting the service is a piece of that which can't be ignored - it makes some things *really* easy. But in lowering the barriers, it also raises expectations, which I think has the potential to benefit *anyone* doing work in the rtc space; once rtc becomes more common, there will be more demand for it. If you're a kickass FMS dev, you'll most certainly be a kickass Cocomo dev, and for projects where Cocomo makes sense for you, you'll have yet another tool in the toolset to get what you need done. Even if you never want to touch Cocomo, increased demand for rtc will still find its way to you.

I'm sure I haven't fully answered Stefan's concerns, but I look forward to hearing more from him on the subject - ultimately, the team we're both playing for here is "people who want to make the web more immediate and social", and I don't see how recruiting more players hurts our chances of winning.

So we finally made it across the finish line. Well, not "the" finish line, but at least some line where we can take a pit stop, get some fluids, change the tires, etc.

We're really excited because we'd set the goal of hitting public beta for MAX in the spring of this year, but the amount of work it took to get there was pretty intense. Some people have asked "why did it take so long - you revealed this like a year ago!" Well, yes, the backbone has been more or less solid for a year (a good thing!), but more stuff needs to be accomplished than you'd think in order for developers to really benefit, and we wanted to do a lot before Public Beta. To wit :

:: P2P AV Stream support. We knew we wanted to be the first place developers could take advantage of direct client to client audio/video streaming. So we managed to finagle some pre-pre-pre-beta, super-advanced technology from the FMS team, and built a mini-cluster of these servers for devs to pound on. At the same time, we wrote a set of algorithms that make P2P/Hub and Spoke transitions on the fly as network and client conditions change. I'll talk more about this in a future post...

:: Polishing the SDK surface area. We wanted to make sure the API surface was in a reasonably mature state, and not subject to huge changes after public release. Looking back from last spring, there were at least 3 major overhauls to the API, to allow stuff like multiple simultaneous sessions per client, private stream groups, and a move from a 2-project codebase to a 1-project codebase, so that devs would have a hope of being able to browse our source code (yes, source is included!).

:: Documentation and samples. We were lucky to get the assistance of a really great tech writer (thanks Ben!). who produced a 59 page tome on all things developing with Cocomo. Not only this, he spent more time than I ever would have scrubbing ASDoc comments for the Cocomo API Reference. Working with Ben was a pleasure, but time-consuming too - that guy has exacting standards, and it shows in the quality of the docs. Everyone on the team also spent time writing sample apps, resulting in a nice library of 15 apps - we're still going to add more!

:: Metrics and Quotas. We know that we want to keep track of usage, and be able to enforce quotas on that usage, so that no one beta account could take over our cluster and freeze everyone else out. We also wanted developer reports that would let devs see how much they'd used.

:: Provisioning and Authentication APIs. We needed an HTTP based API so that developers could use their own servers to spawn rooms on the fly, and authenticate their users *without Cocomo needing to know anything about those users*. We (including the extended team of Sean Corfield, thanks Sean!) produced sample scripts in 5 languages for showing how this can be done.

:: Developer tools. We built the Cocomo Dev Console as well as the Local Connection Server, so that developers could introspect their rooms and develop Cocomo apps on an airplane (! - because of course this is where most work gets done...).

:: Battle-testing the service. We've built a suite of testing tools that allows us to POUND on the service, pushing it further than we'd ever seen in the wild. We've found several issues over the course of testing, and are still working to figure out exactly where our capacity limits are, and how to raise them =).

:: Releasing a couple of our own products on the thing. Both ConnectNow and Acrobat 9 use Cocomo in the real world. This makes sure that Adobe is actually committed to the infrastructure, since, well, Acrobat isn't going anywhere =).

:: Finding a few kickass partners and working with them to see exactly what needs are there. Acesis and Broadchoice are both using Cocomo, and we have another couple of really cool customers who aren't ready to talk publicly, yet...

Phew. I came into work today a little more refreshed, after feeling really exhausted earlier from all the MAX hoopla. But after detailing all that we did this year, man, I think I need to go back to bed.

Stay tuned - more to come next week.

Just wanted to take a second to highlight that our team is looking for a Flex rockstar to come join us. We're growing, and building some *very* cool new features, both in ConnectNow (the product), as well as Cocomo (the PaaS we built ConnectNow with).

So, if you're into Flex, AIR, "Cloud Computing", Real-Time Collaboration, multi-user social apps, client-server architecture, and are generally into pushing the envelope, we'd love to hear from you - apply here!

Also, for those of you contemplating MAX registrations, don't miss the 2 sessions we'll be giving on Cocomo.

nigel

MAX San Francisco is quickly approaching, and it's one of the highlights of the year for project teams like Cocomo and Acrobat.com. Schedules get set in anticipation of the event, with BIG REVEALS planned and features added in support of the BIG REVEALS. Basically the last half of our year ends up viewed through MAX-colored glasses.

So, it's pretty much guaranteed that by the time we get to MAX, there will be new stuff worth talking about in the Cocomo world. If you check out the MAX session locator, you'll see 2 new Cocomo sessions listed there :

Real-Time Collaboration Apps with Flex and Cocomo

Explore Cocomo, Adobe's new Platform-as-a-Service for developing real-time, multiuser Flex applications. Learn how any Flex developer can use Adobe's services infrastructure to build stunningly rich real-time social apps, including robust data messaging and streaming live video and VoIP. In this session we'll be showing live coding with the Cocomo Flex SDK and Adobe's services. Bring a laptop and be ready to join in.

Cocomo Deep Dive: Building Social RIAs with Flex + Adobe Hosted Services

Learn to build your first multiuser Adobe AIR application using the new Cocomo Flex SDK. In this session, we'll walk you through the philosophy and design considerations of this new breed of application, all the way to the nuts and bolts of coding, debugging, and deploying it. Follow along as a real-time collaborative AIR app is built from scratch and deployed on stage. There will be code — bring a laptop!

The first session is going to be more of an overview, really highlighting the scope of functionality offered by Cocomo, along with a few simple sample apps to get the audience started. For the second session, we're choosing one big sample AIR app that ties a bunch of functionality together, and using it as a framing device for diving into some slightly more advanced topics. Both should be a lot of fun - multi-user apps are so much more interesting to build than single-user apps, "cloud computing" is a pretty hot topic these days, and you'll likely walk out of either session with something.. actually working.

So, go and register for these sessions early - we're hoping for full houses!

A couple of quick items to pump -

First up, eSeminar! If you'd like to hear more about Adobe's platform services, specifically Cocomo, our Platform-as-a-Service for building multi-user Flex apps, come by at 8:30am PST this morning (11:30 on the East Coast, and I'll let you do your own personal timezone translation..), to http://my.adobe.acrobat.com/aclearn/. Anyone's welcome. That's like, an hour from now (prolly less, by the time this hits the aggregators..).

A couple of quick links to share that I thought were relevant :

• Redmond Developer News seems kinda interested in what we're up to.


• Cloud Computing Journal has some interesting thoughts about what it means to do business in "the cloud". Point #4 was especially resonant to me.

Anyhow, hope to see you in there!

UPDATE: If you missed the eSeminar, the recording is available here.

Come join us for a seminar on Tuesday, July 22nd @ 8:30am PDT to learn more about Acrobat.com's developer web services and our progress with “Cocomo.” We’ll discuss the APIs available today and where we are headed, including when everyone will finally be able to try out “Cocomo.”

To join the seminar, simply go to http://my.adobe.acrobat.com/aclearn/. Enter as a guest and you will be taken to a Connect Pro room. The room will be opened 15 minutes before the start of the session. Conference call information will be provided inside the Connect room.

Looks like our Cocomo-enabled Yahoo! Maps application is turning some heads. While trolling the usual news sites and blogs the other day, we came across this -- check it out:

Not exactly sure how we ended up on Yahoo! Gallery, but pretty cool. Anyway, kudos to Yahoo! for providing the AS3 components, and oh – to Nigel for whipping up an ”Editors’ Pick” worthy application over a weekend in his spare time.

Happy New Year, everyone!

We’re back from the holidays and ready to kick things back into high gear. As some of you know, the Cocomo private beta kicked off late last year and we’re off to a great start with good early activity and feedback from participants.

Hats off to the brave souls who’ve already dived in and exposed our oversights!

If you’ve applied, but have not yet received access -- don’t fret! We are opening the beta in phases -- mainly to make sure we can properly support participants and work out the kinks (see above reference) -- and will be letting in more folks in the comings weeks, and throughout the beta.

Lastly, I thought the survey results from the beta application were interesting and thought I’d share the below with you all so you can see the mix of fellow beta participants. Collaborative applications takes the cake, but that’s not a surprise… ;-)

~~~~~~~~~~~~~~~~
Update 10:17am PST -- The major storms here in NorCal have knocked out the power at the office. I've been sitting in the dark for the last hour and keeping it rolling... well, at least until my laptop runs out of juice.

Hopefully you’ve all had a chance to play around with the demo app that Nigel posted a few weeks back, and you are as ecstatic as we are about the opportunities that Cocomo creates for developers.

As we continue to march toward our milestones, we want your feedback and help in making sure that we provide the best kick-ass web services platform for real-time collaboration and social media.

The Cocomo team is taking private beta applications starting today -- APPLY NOW!

So, a random San Francisco rainstorm this morning soaked me to the bone on my 15 minute walk in from work. Of course, as luck would have it, I was scheduled to do a Connect Webinar on Cocomo the minute I got into the office. So, coffee clutched in hand, shivering, with soaking shoes and pants, I ended up giving a one hour, reasonably in depth lecture on the principles of what we're doing here, including a bunch of highly-coveted code samples. Since some crazy guy at Adobe made all Connect Meetings recordable (and wouldn't it be great if you could record and play back this sort of stuff inside your own apps?), the presentation is now online for all to mock me :

Wet And Miserable Cocomo Presentation

(BTW, am I the only one who gets shivers when they see the old Breeze logo? Yeah, I'm prolly feverish).

Continue reading "Cocomo Vs FMS?" »

So, we announced our “Share” beta service and APIs, and sneaked our “Cocomo” technology at the Day 2 keynote. Both were received very well, especially when our Flash preview feature of Share was described as “FlashPaper on steroids.”

This was then followed by an awesome, jam-packed Day 2 session with 78 attendees -- standing room only. Based on some impromptu polls, it seemed that the high attendance was largely attributed to our keynote. Anyway, thank you all for those who participated and made it an awesome, interactive discussion.

Sorry for those who weren’t able to make it to MAX in Chicago or missed the session, but we promise to keep you informed via our blog. For now, I’ve embedded our presentation below (using Share) for folks to read up.

I just go back from MAX, and was blown away by the quality work going on all around, both outside and inside the company. Finally getting to sit down with the Buzzword folks was a huge highlight, as was seeing Fang's disembodied head on a 50 foot screen.

It was also a privilege to be allowed on stage for the day 2 keynote. Is there any doubt that Mr Ted Patrick is some kind of super-being? No? Good, there shouldn't be. Watching the keynote come together for 4 days backstage (from saturday morning to tueday night) was a very surreal experience; the crew (dozens and dozens of people, from Makeup to sound to lighting to IT to catering to security to the guys in the cherry-picker adjusting the screens) really deserve high praise for keeping everything running as well as it did.

So, it seems like people are interested in what we're up to - folks were sitting on the floor in our session later that day; thanks to everyone who came out. Now that I'm allowed to talk about the CoCoMo project (I'm really not sure at what point we started InTerCappIng the name, but.. too late now?), I think I will.

But first, a taste of what some others (with, possibly, more influence than I) are saying about the project, as well as other new Adobe initiatives :

Link 1 (Shantanu Narayen)
Link 2 (Kevin Lynch)

Stay tuned... More to come.