Collaborative Methods

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.