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.
Is it me, or is Cocomo to FMS what Flex is to Flash. Just components that make it easier to accomplish a task.
I think you missed the point a bit here. My read is that "competing with developers" is an oblique reference to buzzword and photoshop express. It's not that Cocomo by itself completes with developers - it just a concern that Adobe is pulling a Microsoft. I think there's also some concern that FMS might end up playing second fiddle to Cocomo - leaving the developers who depend on FMS at a disadvantage.
Hmm.. But reading the quote I pulled above, is Stefan really talking about Buzzword or Photoshop.com? If it's oblique, it's reeeealllly oblique.
The concern about "second fiddle" and the FMS disadvantage is more what I think I was trying to address : FMS will always have more inherent power than Cocomo, since it's a lower-level tool that can be used in more ways. Cocomo will likely be more approachable and democratizing. And FMS devs would stand to benefit with either approach. To me this harkens back to the "Flex/Flash" days, where everyone was worried that Flex would take over Flash, which it clearly hasn't. It's definitely brought more people to the platform though, which in itself benefits Flash developers.
Hi Nigel and Stefen, both of you guys are thoughtful and sagacious. I think the target users of Cocomo and FMS is a little different. From a flex developer's perspective, I really love Cocomo because I can do great RTC application without any knowledge of FMS or any other server side technology. (In fact, I'm also a fan of FMS, :P). And most important thing is, I needn't to setup and maintain a FMS server by myself. It's unfeasible with me. So Cocomo is definitely fruitful to the people like me. In other hand, regarding the experienced FMS developers, they can always program on FMS to provide more powerful and specific functionalities. Cocomo is not everything, but really good enough for some people. It should be a considered as a "gap filler", rather than "competitor".
I can relate to the debate over CoCoMo vs. FMS. We are still trying to make a decision about that.
From a reliability point of view, we can maintain our own FMS servers, and therefore we can sign service agreements with our customers to guarantee a certain uptime. With CoCoMo, I don't know whether there could ever be a full hour of downtime, (just like GMail has had on many occasions).
From an architecture point of view, with CoCoMo, you are tied to one specific way of sharing and streaming data. Of course for most business needs, CoCoMo provides a better architecture than what you could build in house. But depending on how unique your business plan is, the SharedModel design might not necessarily fit every possible need.
From a server-side extensibility point of view: Let's say that you still need a very customized registration system, reporting system, or other use-case that CoCoMo isn't designed for. I think your options are to either do a hybrid of CoCoMo + another server technology, or to do everything all on your own servers. So this raises the question of how economical is CoCoMo if you still need to spend the same amount of money on the software/hardware/development costs of your own server infrastructure.
It would certainly be helpful if Adobe were to list all the main use-cases for FMS and CoCoMo, and then compare them so we could be more informed in our decision about which one to move forward with.
Also, I think it would be easier for us to move forward with CoCoMo if it were offered as software that can be installed on FMS. Then we don't have to make such a difficult decision about whether to trust a new company to provide uninterrupted service, or to change our engineering model to work with a managed cloud instead of in-house cloud.
We are an FMS shop, we rolled our own components and our app is AS2.
We've decided to move to Flex / FMS and AS3.0 - a significant commitment for us since we're migrating all our code.
I'd like to think our investment will be worth it, but I'd hate to create our own Flex FMS collaborative components only to find out we should / could have been using Cocomo's down the road.
Nigel - can we / will we be able to take advantage of Flex and Cocomo's components in such a way that we can deploy our light version to Cocomo's online services and our non light version (with our unique server side code) on FMS and behind our customer's firewall?
Thank you in advance
-SR
@ Harry,
Re: Reliability : SLAs are likely something we'll be tackling at some point in the future. So uptime requirements would be part of what we'd offer as part of why we'd charge. If it helps, ConnectNow and Acrobat run on the same platform for us, so we're definitely very committed to keeping it available.
Re: Server-Side - I definitely think Cocomo works best in conjunction with your own servers; for example, provisioning rooms or authenticating users are things *your* server needs to do. But these are relatively easy things to build, compared to load-balancing FMS clusters and providing seamless failover should one go down. There's a certain economy of scale we get from being fully immersed in the problem daily, and having capacity for many times more users than any one of our customers needs individually.
Re: Listing use-cases, I think we definitely should spend more time on this.
Re: Making it available for on-prem installs : well, Cocomo does use FMS, but it's a much broader system than FMS (we have equal numbers of Java to FMS servers). So it's not really an apples-to-apples comparison. And of course I can't really divulge any future plans.
@ Scott,
I wish I could make public promises of what's upcoming, but that's not something I can do. For now, if you've got a problem that needs solving today, I'd consider Cocomo an interesting possibility for the future, and keep on trucking - if the investment was worth it before you heard of Cocomo, it still will be after. I know that I'm currently spending more of my time focusing on hosted Cocomo than designing a deployment model for behind the firewall (see my answer to Harry), although we've certainly paid close attention to requests for both. The model of light/non-light, cloud/non-cloud is interesting to me though - I'd be curious to hear what features you have that require server-side code?
oh wow, look what happened while I was sleeping :-)
Thanks for the thorough response Nigel. I can definitely see how Cocomo complements FMS in many ways, and I can see how it will drive more people towards real time apps and that's a good thing. The bit that I have a problem with is the business model. I can see that the cloud has advantages, but it also makes our efforts dependent on Adobe on a much higher level than FMS would. After all if Adobe discontinued FMS we'd still have FMS. What happens if Cocomo is deemed uneconomical at some stage? I think this was Harry's point also.
Adobe clearly wants a slice of the action, and I do not blame them. However the spanner analogy doesn't hold up. I new type of spanner is just that, a new tool in the box. What if company A was the only one producing a popular type of spanner, now releases a better spanner while still selling the old one, but charges you every time you tighten a screw? I think I'd rather just buy the new spanner outright if I could.
Pricing. We have heard nothing about this yet, but several companies have announced partnerships and are building products on top of Cocomo already. How is that possible when they do not know how much the service will eventually cost?
No doubt I will use Cocomo, but could it also impact my bottom line?
Case in hand: we sell a Flex whiteboard component for FMS, and it sells quite well. Depending on Cocomo pricing we may sell less of those since anyone can drag and drop Cocomo's whiteboard component. Sources come with it. We however cannot afford to give our sources away for free, and I doubt Adobe can safely say that our sales won't be affected by this.
This is not the end of the world, and very few developers offer FMS components for sale. But I hope it makes it clear that Adobe is competing with us in this case, and that's a double blow because they are also the ones selling us the tools (Flex Builder, FMS) that enabled us to do this in the first place.
Do you understand that this does not sit 100% well with some people?
Cheers
Stefan
Hi Stefan,
Glad to hear from you - I do totally understand, and see how Cocomo does pose some competition to your business in selling the real-time whiteboard. I agree it wouldn't sit 100% well with me either, and I don't really have an answer that would "explain it away" for you. I suppose my only reaction is somewhere along the lines of agreeing that there hasn't been a proliferation of rtc components, and expressing a little frustration about that. At a certain point, as a developer, I decided to roll up my sleeves and get it done. The fact that I work for Adobe makes it more complicated than that, I recognize, but please don't take it as a sign that Adobe willingly decides to compete with developers - if anyone, your beef is with me - even then, my intention was never to compete with your offering either, I was just trying to realize the potential I saw out there that wasn't being realized. All this said, the whiteboard we offer is inextricably tied to the service, so it too serves a different audience (in general) than what you offer.
I wanted to respond to a few of your other points too. I think the argument is becoming a bit.. erm, "multifaceted". I'll try to break out the major topics :
1. Vendor Lock-In. Essentially, if you use Cocomo, you're depending on Adobe to keep it running. There's a fundamental tension between "first-mover advantage" and vendor lock-in, and we're definitely thinking about this. I can't describe everything we're doing around this, but a few things worth noting : We're basing some of our own products on the same backbone (see.. Acrobat!), meaning that we're pretty heavily incented to keep it running, and not pull the plug. Secondly, as a first-mover, we're somewhat in the same category as Google App Engine or Amazon S3 were when they started. To a certain extent, we'll end up validating the market, I'd expect. There will be customers who are comfortable with this risk, and see the advantage of getting in early as outweighing it (and some in fact, have bought enough from Adobe that adding service charges is preferable to finding another vendor anyhow). Others always have the choice not to.
2. The wrench analogy and Capital Expenditures vs Operating Expenditures. I agree (and said so as I started it =) that the analogy was weird. But what we're talking about is a choice, and I think you've framed it a bit one-sidedly. Fundamentally, we're talking about a rather expensive tool, which by its nature requires an ongoing commitment to keep it working regardless. The value proposition behind Cocomo says "don't pay anything up front, pay for what you use". Whereas the other model says "pay up front, and also pay for what you use (in maintenance, bandwidth, etc), but have a lot more control over your setup". This is where having someone handle the major capital expenditures (hardware, big pipes, a datacenter) can lead to an economy of scale that can pass savings down to individuals paying for use of the system. Or at least, this is the fundamental idea. We're going to make it as transparent as possible, so that developers will be able to make that choice based on the factors that matter to them.
3. Who are these guys already using Cocomo? I think it would be crazy if we went for-pay on a broad scale without understanding the needs of customers. We crave more data, and the best way to get that data (on usage, on value of the service, etc) is to get some early pilot customers to commit to using us. So yes, some people are getting in ahead of time, and assuming some risk. What we're trying to do is figure out our costs, and figure out how much it would take these customers to build the functionality themselves, and find a line between the two that makes sense. Bottom line, we're not announcing pricing because we need time to work out the numbers while the service is getting used more (hence, public beta and pilot programs). I'd hate to think what would happen if we just took our first guess as to what to charge =).
hope that helps - if there's more we can elucidate, we're here to help =).
Great discussion, and thanks to Nigel for taking the time to explain the position more clearly. I mentioned on Stefan's blog that I thought there are pros and cons to Cocomo's model; we run our own servers but still the value proposition it offers is certainly attractive.
For us though the real crunch feature has always been screen-sharing, without with much of our collaborative applications are limited in usefulness. As of now we could use Cocomo to build most of the functionality available in ConnectNow, but without the custom add-in we're stuck for now with a less-than complete featureset in comparison to Adobe's - for us as an educational institution that's a limitation rather than a deal-breaker but for others it limits what they can offer customers in terms of functionality versus what you offer (for free).
That said, I'm really impressed with the SDK so far - once we know more about the cost model I'm sure we'll be giving it a spin. :-)
Good discussion... but really, I can't say much (but I will anyway) until the license and pricing is announced. I started to look into it and all the technology looks cool (though I have some technical questions I'll hit you with later)... but I had to stop as soon as I saw no details. I get the basic idea: it's a service you pay by the byte or minute or month. But as is, I can't really work any deals with my clients until this is known.
The thing is, this particular corner of the industry has a short history... and a history of quick (almost random) changes. For example, doesn't or didn't the FMS license explicitly say you are not allowed to use it to create an Acrobat Connect competitor? (Tell me if you can't find this and I'll try to dig it up.) And you know the whole screen sharing story. I don't mean to just bring up old wounds--but it's totally hard to really understand Adobe's direction when services such as buzzword and photoshop.com and premeire are coming out. Plus, what was with all the client services crap at the MAX sneaks? I mean, I sat there thinking "wow, cool project... I could have done that... nice to see you did a cool project but where do I fit?".
You make a good point--basically: "so what, if you can use the product now for an immediate need, then go for it--otherwise, don't worry about what could happen". But despite my apparent paranoia, my resistance has little to do with me and everything to do with my clients who ask how can we really depend on Adobe? I guess my concern slips in when I try to see the business model. It's not totally unfair to paint a picture where Adobe sees their #1 long-term opportunity in selling to end users (say Acrobat.com) and #2 selling (to developers) subscription based access to their cloud and #3 selling tools like Photoshop and Flash. It makes sense... I mean, how many dang copies of Photoshop can you sell?
Anyway, I don't mean to frame this unfairly--in fact, without the license and pricing it's all totally moot. But... I liked your session at MAX (though I had to leave before the end)... and I will probably tinker around with cocomo regardless
fwiw... when I tried signing up... I got to the part where you create an account name and I checked the thing saying I read the user agreement...but then it fails when I say "create":
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at com.adobe.rtc.portal.ui::SDKAccountCreate/onCreateAccountResult()
at com.adobe.hs.amfgateway2::AMFConnector/onResult()
When I look at Flash Media Interactive Server, LiveCycle Data Services, Acrobat Connect, and Cocomo I see the realization of many of the ideas that started off with Flash Communication Server 1.0 – especially shared objects (shared models) and the component framework. For years those ideas were largely pushed to the side by Macromedia's limited resources and its focus on FCS/FMS as a profitable delivery tool for streaming media.
Years later I think Adobe has a problem in the real-time space and this conversation is partly a reflection of that. If I want shared record sets with conflict resolution I need LiveCycle Data Services. If I want screen capture I have to create my own plugin or extend Connect Live. If I want to work with well architected pre-built rtc components in Flex I need Cocomo.
When I look at Cocomo I see what FCS 3.0 might have been and what FCS 4.x still might be if Adobe can return to the idea of doing something big, visionary, and audacious in the real-time space. Adobe has all the pieces to deliver a stunning real-time server. The client is evolving nicely. You just need to put the pieces together in one package:
1. a rich collection of real-time datastructures including what LiveCycle, Cocomo, and FMS already offer and then some;
2. a component framework like Cocomo but with a server-side code option;
3. ways to hook into authentication, authorization, and auditing systems;
4. ability to use XMPP, SIP, and other standard messaging systems;
5. ability to handle http request/response calls especially remoting.
Personally, I think FMIS 4 or later is the place to do this rather than in something like a new Cocomo server or new version of ColdFusion. Adobe has enough real-time product fragmentation.
If Adobe doesn't do this, then Stefan and others will be faced with competing choices from Adobe that don't make sense to developers. Do I use LiveCycle but then what about video? Do I use FMIS but then what about screen capture and a component framework? Do I use Cocomo but then what about server side code and shared record sets? Do I need all of them, then how do I glue it all together and what about my budget?
Yours truly,
-Brian
@ Phillip - Agreed, we need to show the pricing model before most of these arguments can be resolved. Which is part of what the Public Beta is about - getting a realistic sense of what our costs are at higher scales, figuring out how much it would cost developers (in time and $$) to build their own infrastructure rather than use Cocomo, and finding some level between the two that makes sense for pricing.
As for the error, we've got a fix for it on staging now - in the meantime, you can register another account or choose a different account name. Thanks for the feedback - I'll even forgive you for leaving my session early...
@ Brian (Hi Mr. Lesser!)
I'm of a couple of minds here - I see that FMS (interactive) is certainly in need of a decent component set, but I don't know if Cocomo is the answer - we explicitly designed for the absence of server-side Actionscript (which is the bane of my developer existence). So even if we said "install Cocomo on your box" (which isn't where we're focusing right now) we'd still need to figure out where your own SSAS could sit, and how to avoid you writing much, if any, of it. And load-balancing, failover, etc, would all still be problems for devs to deal with. I'd wager to say that other than for larger, or more specialized shops (companies in the Telco space, etc) the "super-server" still isn't that accessible. I'd still argue that hosting our own cloud has a fair amount of the big, audacious vision needed to bring this to many more people, even as we need server alternatives as well.
The other thing I'd like to point out is that I think you've missed out on some of the server stuff going on in the Cocomo world - you mention it seemingly as a client-only technology. We do offer authentication and provisioning, and do expect that web developers will integrate from their servers to ours. Some of your requests are things we're thinking about a lot (XMPP, SIP, more high-level datastructures, audting/reporting), so it's good to hear feedback about it.
Last thing - I agree that it's enticing to build one huge server that does everything under the sun, and call the whole problem done. But I still have a nagging engineering voice that says "constrained problem set, done really well!". Offering a server that does everything will be too much for most devs, in terms of features and cost, and might suffer from the "jack of all trades" problem of doing everything, but nothing particularly well. But this is a topic for another day...
Hi Nigel,
Sorry, I should try to clarify. I know Cocomo has authentication and provisioning and lots of other features. My point was that, after all this time, FMIS has little to offer today in that respect. I was trying to list some of the essentials things that Adobe knows how to do but should be brought together into a server product like FMIS 4.x or 5. So in some ways I do think Cocomo - or some of it - is the answer. For example I think you've evolved your component set/api very nicely. If FMIS gets a component set, does it really have to be so different from Cocomo with yet another API? Maybe it does but I hope not. I'd like to be able to build applications in Cocomo where it makes sense and other applications on a server when I need to. It would be great to use common APIs and components to do that.
Also, I don't expect the Cocomo team to launch off in some different direction just because I think Adobe's Real-Time story is bit of a jumble. I'm looking forward to watching Cocomo continue to mature and I've tried to do a few very modest things to help it on its way.
But I do think Adobe has strategic challenges in the real time space and that this discussion reflects that. Maybe I should illustrate that with an example from Stefan's comments. When FCS shipped it had a very crude whiteboard. We all expected it, and all the other components, to improve in later releases. They didn't. Instead Breeze appeared with a new and improved set of components including a better whiteboard. After a while people like Stefan started to fill the gap. Some of us even wrote component frameworks. Now he sells a whiteboard component to people who need one and I help maintain a proprietary component framework. Now here's Cocomo with another generation of components - including a very nice whiteboard that competes against Stefan's product.
I don't want to belabour the history of FCS, Breeze, FMS, LiveCycle DS, Connect Live and Cocomo. But it reminds me a little of what happened to the UI components in Flash. There is still a lack of clarity about their future. Adobe needs to provide better clarity around its real-time story. Will Adobe re-invest in its big ideas around FMS or not? If so how will that fit with Cocomo and LiveCycle DS? Do people like Stefan and I need to put energy into developing on FMIS and Cocomo and LiveCycle DS and Pacifica, and Stratus, and...
...and thanks for listening.
Yours truly,
-Brian