Collaborative Methods

As a step towards finalizing the AFCS pricing model last week we launched a pricing survey. We reached out to some of our beta participants directly and thank you all who’ve already taken the time to complete it.

For those of you who haven’t completed the survey, please take the time to give us your feedback as it will directly impact the AFCS pricing model. For those who’re interested in providing us feedback, here’s the link to the survey.

While the biggest benefit in taking the survey is for you to influence AFCS pricing, we’ve added one additional perk — you will have the option of participating in a drawing for a chance to win one of five $100 USD gift checks or one $500 USD gift check!

Lastly, I must confess, the survey is rather long and takes about 15 minutes to complete — the statisticians insisted that for the demand curves to be robust we need to incorporate a series of scenarios =).

Thank you for taking the time — the survey will be open through Friday, June 19th.

You can see we are coming up for air (see Nigel’s blog post and Varun’s blog post), so I thought I’d jump in too and share some more information with you all.

As the team chugs along, we continue to receive questions on how the Adobe Flash Collaboration Service fits into Adobe’s overall collaboration strategy and existing offerings such as Flash Media Server, ConnectNow and Connect Pro. Well, Peter Ryce, Sr. Technology Evangelist here at Adobe, has created an awesome presentation explaining it all.

Take a look… and thanks, Peter!!!

It had been quiet around the blog for a few weeks, we know; but consider it an above-water view of the proverbial swimming duck – our feet are paddling furiously below. We’ve been planning some good stuff that we’re finally able to start talking about. You likely saw Varun’s post earlier this week, aiming to get your feedback around our pricing model (take the survey!). Today we wanted to talk about how we’re driving to commercial availability for AFCS.

Continue reading…

Some of you have asked us questions about how we plan to price AFCS. Through this blog post we’d like to better understand your preferences and opinions and provide enough context for you to map our proposed pricing models to your business plan and monetization approaches. Please take a moment to review our proposal and provide feedback.

Our overall approach to determining the AFCS pricing models is built on four key tenets:

* No Barriers To Adoption: There will be no upfront one-time fees to use AFCS and we will continue to provide free quotas to enable developers to quickly build AFCS-powered applications. Pricing will kick-in only when the free quotas are exhausted.

* Pay-Per-Use: The price you pay to Adobe will be determined a-posteriori; in other words, looking back at the billing period we will determine your total bill based on your usage of the service. We will not force you to commit to a certain number of users or amount of usage.

* Predictability And Control: You can set the maximum bill per billing period you’d like to receive from Adobe. In other word, you don’t need to have sleepless nights worrying about a “runaway application” cranking the AFCS billing meters. One of the disadvantages of a-posteriori pricing is that you typically have little, if any, control over your final bill (E.g., monthly utility bill.) We are erasing this concern by introducing the notion of maximum bill per billing period.

* Options And Flexibility: To ensure that AFCS appeals to a broad cross-section of developers and use-cases, in the long term, we plan to offer more than one pricing model. Factors such as application type (Bandwidth intensive, Message intensive, Connection-time intensive, etc.) and entity type (Individual developer, ISV, Enterprise, etc.) can greatly influence pricing model preferences. The implication is that as a developer you’ll have the opportunity to select the pricing model that best meets your needs. In fact our plan is to eventually allow you to attach different pricing models to your various applications.

So based on these four key tenets we have came up with three pricing models. Let’s now review how each of these pricing models would work and their relative merits:

1. Resource Utilization: Today, through the public beta program, we impose restrictions on the number of concurrent users, bandwidth (in + out), connection time / cumulative user minutes, and number of published messages. In the Resource Utilization model we would remove limits on the number of concurrent users and charge along any two, or all three, dimensions of bandwidth, connection time, and messages. We expose application usage along these three dimensions through the Developer Portal and to some extent through the Developer Console. So today you can monitor and estimate usage – and at the time of AFCS commercial launch estimate expected price – by simply analyzing usage over a period of time. We think that the Resource Utilization model will appeal to individual developers and mid-size and smaller ISV’s who plan to build new applications where it is hard to predict the success [users or usage] of your application. Predictability will be provided by allowing developers to set a “Max Monthly Bill” and developers can rest assured that they wouldn’t end up paying more than what they had originally planned / budgeted for.
ﾠ
2. Peak Concurrent Users: Some developers may find it hard to estimate usage of their application, especially the AFCS-powered components such as chat and webcam video. For example, it may be tough to get answers to questions like how many users will engage in a text / audio / video chat session; how long (number of minutes) will sessions last; or how many chat messages will be exchanged between users. In addition, there is a segment of developers that plans to deploy applications to a known quantity of users such as an internal application targeted at full-time employees in a company. In such situations a developer can approximately estimate the number of users over time. In the peak concurrent users pricing model we align our pricing to the success of your application by allowing you to plan expenses and budgets based on peak user loads. Furthermore to ensure that we protect developers against sudden spikes we can charge based on – just as an example – 95% of peak concurrent users or allow developers to set a maximum number of peak concurrent users per application. Obviously, to ensure that we don’t cause our service to come to a grinding halt we’ll put some really large usage caps on peak concurrent user accounts that will protect us against runaway applications.

3. Subscription Tiers: Subscription Tiers pricing model offers about three subscription tiers, each of which correspond to specific quotas for bandwidth, connection time, and number of messages. This is still a pay-per-use pricing model as developers always start from the lowest subscription tier and if usage during the billing period crosses quotas of the existing tier by more than, as an example, 5% of allotment then we automatically bump you into the next tier. Higher tiers correspond to higher quotas but lower unit price per quota dimension. Once you are bumped into a higher tier you will be billed accordingly unless usage drops to lower tiers for two consecutive billing periods.

Caution: Please note that we are still working through the details and Adobe reserves all rights to launch any combination of these pricing models, including never launching some of these proposed pricing models. Our goal is to prioritize these options and make available only those that appeal the most to you. So here you go… Please take our quick, less than “60 second” survey and vote for your preferred pricing model. We welcome any additional comments in the survey. Click here to take survey. Note: If you are developing multiple applications and think that there is an application that will be better monetized via one type of pricing model and another through some other model then please complete the survey twice – once for each application.

Also, as a heads-up we’d like to let you know that next month we will follow up with a more robust survey on pricing [... to get a read on actual price points] so please keep an eye out on our blogs as we’d very much appreciate your participation. One thought I’d like to leave you with is that any pricing model Adobe implements needs to be competitive relative to comparable offerings in the marketplace and needs to reflect the value-add we provide with AFCS to the developer community.

* If you’re a developer who’s ready to launch a commercial offering in the next couple of months, please email us a brief description of your application, commercial launch timeline, and proposed monetization / pricing model for your application and we will contact you to discuss how we could potentially support your near-term commercialization plans*

Varun

Just a quick post to announce that we’ve launched a Showcase Gallery on Adobe Labs to highlight compelling applications powered by AFCS. We’re starting off with a small list [... thanks to Nisse Bryngfors, Kaushik Datta, Hog Wild Poker Leagues, and Acecis for working with us and allowing us to showcase their cool apps!] This is just the beginning and our hope is that in the coming weeks we can rapidly expand the Showcase to include other community-developed apps. If you’d like your app to be included in the AFCS Showcase then please submit it here. We’re really interested in adding apps that truly take advantage of In-Context Collaboration features provided by AFCS.

Varun

With all the hoopla last week around the name change (Cocomo->AFCS), we neglected to mention that along with the new name, we’ve pushed a new build of the SDK as well as updated the service.

Go get it here

A few words on process – Generally, this build is the result of feedback from the user forums. We take every post very seriously, and spend time considering whether and how we should update the SDK and service. The vast majority of the list below is the result of user feedback. Keep it coming!

What’s new for this release?

• A real, commercial name. Cocomo is now “Adobe Flash Collaboration Services” (AFCS).
• CustomUserField in UserManager is now fully supported.
• RoomManager has been augmented with 4 new settings :
      • guestsNotAllowed: Allows OWNERs to disallow anyone not authenticated to their rooms.
      • roomLocked: Allows OWNERs to prevent any further entry to a room.
      • roomUserLimit: Allows OWNERs to set a user limit on their rooms.
      • roomTimeOut: Allows OWNERs to set timeouts on their rooms (after which the room shuts down).
• Fixed ConnectSession.logout so that rooms can be re-logged in properly. ConnectSession.close() was added to completely clean up a session (doesn’t allow re-login).
• Fixed: Developer Quotas being exceeded was not reported in the AFCS framework (now throws SessionEvents from ConnectSession, or an RTE if it’s not being listened to).
• Management API :
• Server-side: getSessionSecret now returns the current session secret instead of creating a new one.
• Client-side: Added AccountManager.invalidateSession method to invalidate the current session secret
• UserDescriptor.RTMFP added to tell if a user has come in via RTMP.
• Fixed: P2P audio periodically dropping out.
• Fixed: P2P video freezing as it switches to hub and spoke.
• Fixed: Whiteboard not able to set backgroundColor/alpha via MXML.
• Added support for getting/setting nodeConfigurations on every collab and sharedModel component.
• New Examples:
      • MultipleSessions – shows how multiple IConnectSessions can be used in one application.
      • ZoomLayout – builds a custom webcam layout using WebCamSubscriber.
      • PeerToPeerRtmfp – shows how to use P2P/RTMFP for A/V.
• Dev console additions to allow configuration of file and stream groups.
• Dev console additions for managing new RoomManager settings.
• Fixed: XML objects are properly serialized/deserialized went sent via MessageItems.
• Capacity and service performance improvements.

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!

Thought I would drop a quick blog post to highlight the work of Nisse Bryngfors, hailing from Sweden. Nisse’s first Cocomo app is really cool, and quite elegantly designed. Put simply – Sudoku + Cocomo = Sudocomo.

I also wanted to thank Nisse for his continued passion and evangelism – he’s been helping by writing his experiences in the forum, and is helping me monitor the Twittersphere for people looking for Cocomo love. It’s been really great watching community grow up around this project, and we thank all of you for your help!

A micro-post for the AXNA : Ryan Stewart of RIA Evangelism/Mountaineering fame did us the great favor of writing an article on the Adobe Developer Connection. It’s all about signing up for Cocomo and getting your first app up and running.

Many thanks to Ryan for his time and advice – I think this article is a great complement to the getting started section of the Cocomo Developer Guide, and fits nicely with the content of the first MAX Session posted on Adobe TV. Anyone starting out with Cocomo should check out all 3, then head on down to the forums to get any nagging questions they might have answered.

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

ﾠ