Adobe Flex Price to Drop! Finally!
I was reading an article on News.com about the declining costs of development tools when I came across this quote from Adobe's Jeff Whatcott:
"In another example, Adobe Systems on Wednesday is expected to revamp the pricing for its Flex Flash development tools.
The first version of its Flex tool set was about $15,000, but the price was throttling its adoption, said Jeff Whatcott, senior director of product marketing at Adobe's enterprise and developer business unit.
"The goal is to get to a million developers building rich Internet applications," said Whatcott. "To do that, you need a good product line. But you also need a licensing model that supports viral, development-to-development marketing. That doesn't happen with a $15,000 product."
Having had a chance to try it out in the early v1.5 days, I think Flex is absolutely awesome but I've always felt that MM priced themselves out of the market. This was definitely not a product for the typical small to medium size dotcom or brick-and-mortar business. This was a product specifically focused on the enterprise market and unless you consulted at that level, there was no need to even bother trying to sell this to your clients. Additionally, a plan for hosting providers was never clearly defined which essentially placed the nail in the coffin for the average web developer to use Flex.
Hopefully, Jeff can motivate Adobe to put it within a price range that makes selling solutions to smaller companies a true viable option. Otherwise, guys such as myself will stick to learning and using AJAX for RIA implementations.
Good work Jeff and I look forward to seeing the results!
When Flex first became available the excitement was there. Test apps were put together, tears of joy were shed, but all interest stopped when it became apparent that even working for a government agency with a lot of developers it was priced out of our budget.
Flex 2.0 SDK will be FREE (as in beer)...
that is what he means with viral...
go out and build apps with flex 2.0 today!
Yes, that is correct, you can build and deploy Flex applications on your existing infrastructure without licensing the server. In this configuration, Flex doesn't even care what technology your infrastructure is leveraging. If you can expose your data as XML and/or SOAP web services, then you do not need the server license.
In fact, you don't even have to pay one dime if you don't want.
Step 1) Build your wonderful application in Wordpad or other IDE of your choosing.
Step 2) Compile your application using the Flex Framework SDK (free as mentioned).
Step 3) Deploy SWF to web server running CF, ASP, .NET, PHP, CGI, whatever.
Step 4) Done! Okay, I guess you had to at least pay for a domain and hosting (smile).
Of course if you want more intelligence to your IDE, we'll be there for you with Flex Builder 2 (standalone pre-built on Eclipse, and Eclipse plug-in options). We've announced that Flex Builder 2 will cost less than $1,000 per developer seat.
If you want more intelligence to your applications, the Flex Data Services (J2EE-based server) will take you there to include direct access to Java objects, implicit paging of large data sets, data synchronization across connected clients, externally-originating data push, collaboration (i.e. chat, interactive applications and co-browsing) and more (i.e. security, history management).
Oh, and by the way, for departmental applications (limited conncurrent connections), there will also be a free version of the Flex Data Services.
Hope this helps,
Kevin
Thanks again for chiming in.
Technically server-less deployment has always been possible with Flex. Some of our customers deploy their existing Flex 1.5 applications to Akamai (edge) as an example, and since they don't control the server farm, there's no way to install Flex. They also wouldn't want to pay licensing for Akamai's ~14k servers. This was accomplished in the past through special licensing arrangements, but the price was still very much inline with the current Flex 1.5 server retail cost (~$15k/CPU).
To be sure though, that's an extreme case, and for the most part, the server is required for Flex 1.5. With Flex 2 this really has changed to eliminate pretty much all barriers to entry. So, yes, this is "new" to Flex 2. Flex Data Services is also the "new" name for the server. For clarification however, when you say just "Flex" nowadays, you might be talking about any number of products:
- Flex Framework SDK (Framework and command-line compiler)
- Flex Builder 2 (IDE that includes Framework and compiler)
- Flex Charting 2 (highly extensible charting components)
- Flex Data Services (server infrastructure and integration)
Let's be fair too, the server does add value, and in Flex 2, there's an entirely new set of very advanced features - it's not just a new name.
Take for example when you build an application with Flex Builder 2, pointing at XML/SOAP services, compile the SWF and deploy to your server (as outlined above). The service endpoints you put in your code are compiled into the SWF. The SWF file format is public and there are decompilers available. Somebody might decompile your SWF, pull your endpoints, and reverse-engineer your infrastructure.
Couldn't you build your own solution around this problem? Sure, but the Flex Data Services provides an abstraction that protects against not only decompilation, but also port sniffing. This is done by routing calls through an HTTP/S proxy that is part of the Flex Data Services. That proxy also allows you to go to endpoints that don't have a "crossdomain.xml" security file. Again, could you build it yourself? Sure!
That's a very simple scenario, but what about some of the problems that arrise from developing rich internet applications (RIA)?
The world of HTML for example is very transactional, and you're constantly refreshing against the database. In an RIA, you may not need to hit the server at all beyond an initial fetch of data. An end-user might be merrily changing/creating data on the client, without talking to the server, step out for a cup of coffee, and at some point in the future, come back and hit the application's figurative "Save" button. What if somebody else, somewhere else, is working with that exact same data (or even related data)? How do you maintain parity of the data the users are viewing against what's in the database?
Again, can you solve this problem yourself? Can you architect your application around such scenarios? Sure!
Keeping the data synchronized across those client applications (and in the database) is a feature of the Flex Data Services. This is accomplished through a very sophisticated data management feature that rides on top of a messaging bus (another great feature in it's own right). This along with security abstraction/integration, proxy services, and much more are all features of the Flex Data Services.
We haven't even talked about what happens if your server goes down while your users are working in your application, which won't immediately know it's been disconnected since it's intelligent enough to do quite a bit on it's own. There's a Flex Data Services feature for this too.
Will your application(s) need all these features? Maybe, maybe not; and that's fine. Right tool for the right job I always say. The good news is that now, with Flex 2 you have an extremely low-cost (free potentially) option to get started! Now you can build Flex applications to your hearts content and use no server but your own existing infrastructure! Or thanks to the myriad of web API's that are appearing (Google, Y!, Flickr, etc.), you don't even need to write your own server code! Yippee!
Kevin
Rey...
I read InfoWorld and Information week and every week there is a .net ad in there. Where's the Adobe Flex ad? Review? Why should I use it? What is it? What will it do for my business?
Adobe needs to actively get the word out so people in management, etc notice and say "We should use this!"
Jim