Cocomo Vs FMS?

I had a different topic lined up for this morning, but Stefan Richter beat me to a more interesting subject. I'm not going to comment on Pacifica, since it's not mine to comment on. I know there was a fair amount of confusion related to the 2 offerings (especially lined up back to back at the Keynote). Suffice it to say that we're talking internally about how all this fits. I think the positive takeaway here is that everyone involved wants to make the right choices for our developers.

..Which is a fine segue to what I really wanted to talk about here. Stefan is posing a very important question. It's great for us to get on stage and show a fancy demo of a disruptive technology, but I fully respect that what we're talking about here could affect the way people earn their livings. It's a serious topic. And this is one of the driving reasons I'm blogging rather than fixing bugs right now (which I should be doing, or Cocomo won't be disrupting anything any time soon).

So, why? What are we trying to do here? I'll put it in my words here (not Adobe's), and take a stab :

a) We're demonstrating Adobe's commitment to Hosted Services.

There's a lot of competition in this space right now, and it will benefit our developers to have Adobe focus on finding the right places to fit. Now. Connect is already a natural fit, and extending what we can offer with it is a natural progression.

b) We want to lower the barrier to entry in pushing Flash/Flex as an enabler in Real-Time Collaboration and Multi-User applications.

I think everyone can appreciate the capabilities we know are in this platform; but complexity and issues of the economy of scale make it really hard for your average developer to use them. I'd like more feedback on this front, but my sense is that it's just difficult and expensive to set yourself up as a Flash RTC specialist. This is great if you can get there yourself, as you get a captive audience; but making it more widely attainable seems like a way to prove the platform in more minds, and help fuel a market I think is waiting to take off. Which should lead to more work for more people.

c) On a more personal level, I've been working (as Stefan points out) in RTC/FMS apps and components for a bunch of years, and frankly, it's time there was a really concrete AS3 framework and methodology for writing these.

The fact that none have emerged, to my mind, speaks largely to point b). And I'm sick of writing the same base functionality over and over again. As someone who's had a very large amount of experience in both Flash Component frameworks and RTC, I feel like the timing and the stars are aligning on this front. Peldi and I (and a team of talented folks who can't be bothered with blogs) wrote this, and we're opening it early for people like Stefan and Brian Lesser to rip apart; it has a fair chance of being good. I've got some posts on the features of Cocomo, the client framework, queued up, so I'll have more on this subject in the next week.

Misconceptions and Ambiguities

I also wanted to take some time to address things I saw over on Stefan's page that seemed incorrect, or at least that I couldn't fully understand. I really regret that I was forced to leave my MAX session as the Q&A started (because another team had an emergency with one of my servers), so I didn't get a chance to chat with Jim Phelan. I wish I had, because I'm not sure if I understood some of his concerns. I hope he comes back here to read this, and I get a chance to hear them.

1) Cocomo is built on top of Adobe Connect (formerly Breeze).

This is upside down. The next version of Adobe Connect is built on top of Cocomo. You won't need to be a Connect user to use Cocomo. Your users certainly won't need to either. We want developers to come in and build apps that are full siblings to Connect. Or little mini-apps that you put inside your existing apps or sites. Yes, we'll have to figure out a way to recoup our investment and make some money from those applications eventually, but we're aiming here for a model that makes that money proportional to your app's success. If you're not using a ton of our backend resources, you're not going to be paying much, or potentially anything at all. It's also early enough that we're still looking for your feedback in how this can be a winning proposition for you as well. If it doesn't help developers, no one will use it, and how are we going to benefit?

2) Adobe will discourage you from buying and using FMS and wants you to use Cocomo.

Now, I'm not a financial wizard, but.. That doesn't seem like it's in our best interests. Cocomo is definitely great tech, but not everything will be possible. If you need a deep back-end integration with FMS, a Hosted Service isn't a good fit (yet). But I'm looking at a banner ad RIGHT NOW on Stefan's page that reads "Can't Afford FMS?". It seems like there may be a market out there
for what Cocomo does.

3) Cocomo is a "bunch of components" for "pseudo develop[ing]" your own flavo(u)r of Connect.

I think this underplays the value a fair bit. We will be offering bunches of components, but as a framework, I'd like to think it's much more robust than just that. The fact we were able to build Connect with *no* special server code (just the same framework and services we're offering you) suggests to me that you'll be able to build quite a lot of different apps with it. Hopefully, you'll be able to tell us soon. I'm still trying to figure out what "pseudo develop" means, as it might make me a "pseudo developer" :-).

4) Pacifica taking web conferencing, Cocomo collaborative apps, etc. Resources shifting away from FMS, couldn't FMS fulfill all this?

I'm going with disagreement on all these fronts. I'll write another post soon about FMS' role in Cocomo, and some of the stuff I think FMS doesn't fulfill, but that comes later.

5) We're trying to compete with developers. We're trying to outsource Connect Professional Services.

Emphatically, No. If anything, and I'm a developer who truly believes this, we're trying to give a more equal playing field to developers who feel Connect/Breeze was eating their lunch. We are doing it in a new way, with Hosted Services (see point a) above), so that might mean some change in methodology for some, but change can be ok sometimes. You tell us. I'm still not sure I understand the Prof. Services argument Jim makes. I hope I've somehow answered the concern, and/or he comes here to clarify.

Anyhow, If you've made it this far, thanks for sticking with it. For some reason, I can't turn off comment moderation, but rest assured I'll let anyone with an opinion speak here. Please do.