XAF: a jigsaw piece or the whole puzzle?

19 December 2006

Now that we've released the first beta of eXpressApp Framework (XAF), we should explain our thinking about how we're going to position it. After that, I'll briefly talk about pricing.

First off, we're of the firm belief that XAF will be able to target a different customer base than we've been able to focus on before. Our traditional customers — and if you're reading this, I'm going to guess that you're one of them — are expert developers who know how to get the best from the components we sell. We sell our components as "pieces, parts" and rely on the ability of our customers to configure them, resize/dock them, link them up, and extend them with code to produce awesome applications with a great UI. That kind of demographic will be interested in XAF, certainly, but not to the same extent as someone else who's not so comfortable with this "Lego- like" methodology.

And that's the kind of customer we see as being of primary importance for XAF. The customer who doesn't want to drop components on a form and link them up and write glue code. The customer who wants a pre- configured, works-out-of-the-box application generator, even though to the purist it may seem too restricted or limited. The customer who doesn't have time for tweaking the flexibility knobs and dials we're known for. The customer who doesn't want to pay a contractor to create a small application but also doesn't have the resources/time to do so himself using our traditional offerings.

That's not to say that someone from our traditional customer base is not also one of this type of customer as well. There will be some overlap. However, I can imagine that the majority of our current customers will see XAF as being some kind of "cute toy" and never use it because of its perceived limitations, real or not. It may even be that, when part of DXperience, XAF just won't get the exposure that it needs, that it just gets hidden amongst all the other great stuff in there.

Then there's also the issue of releases. Although we could force XAF to have the same major release schedule as DXperience, we've already found that it doesn't mesh well with that timetable. XAF features tend to require more "architecture", be harder to implement, and require more time to bring to market. Constraining ourselves to the quicker release schedule of DXperience will produce XAF features that are not as well thought-out, that have more subtle issues, than we would like.

So, all in all, we've decided that XAF shouldn't be part of DXperience Enterprise, but should be a separate product altogether. Those customers who need the flexibility of writing their own applications with all the knobs and dials at hand will choose DXperience; those who want to generate business applications quickly but aren't too worried about the "sameness" of them all, XAF. You don't need DXperience to use XAF, since it comes with all the controls it needs in several run- time assemblies, and certainly you don't need XAF to use DXperience.

Now, let's talk about pricing. So far we've given away the CTPs and the beta to XAF, but, pretty soon we're going to have to charge for it. Therein lies a problem: I just don't know what the pricing plan is going to be. We are still discussing it internally (and the release this morning prompted yet another chat about it), but it seems likely that we would have some kind of promotion whereby you can get a discount on XAF if you own DXperience and vice versa. However, I have no idea what those discounts might be, nor am I aware of the final cost for XAF on its own. As soon as we have more details about pricing, I'll let you know.

UPDATE (same day, couple of hours later): Actually the first commenter reveals he knows more about this than I do, so I'd better stick to technical things in the future :-). XAF without source will cost $799.99; with source, $1499.99. This is the first year subscription price, with further renewals being at 40% of the first year's cost. If you own DXperience Enterprise between now and the time of XAF's release you will get a free year's subscription to XAF (to satisfy some promises we made very early on). Still no news about discounted promotions though (I'm on safer ground there...).

6 comment(s)
anonymous
At 7:55pm EST on Dec 19, 2006 the DevExpress web site below states that XAF will be free for existing DXperience subscribers. I think your traditional customer base could welcome the product to serve clients who want quick deliveries. The XAF technology may also offer the potential for a market in pluggable/re-useable XAF components  developed by your existing customers (WWF has a similar potential). I think these are a couple of good reasons for making the product easily accessible (free or heavily discounted) to your traditional customers. As a current DXperience subscriber was happy to read the XAF policy stated below.

Thanks.

http://www.devexpress.com/Home/Announces/XAFBeta1.xml

Those customers who purchase DXperience Enterprise between now and the release (or have an active DXperience Subscription) of the eXpressApp Framework will receive XAF for free. After the official release, the eXpressApp Framework will not be included in DXperience Enterprise and must therefore be purchased separately.
19 December, 2006
Julian Bucknall (DevExpress)
Very good point. I'm amended my post to reflect this.
19 December, 2006
Ben Hayat
>>If you own DXperience Enterprise between now and the time of XAF's release you will get a free year's subscription to XAF <<

Julian, for DXperience Enterprise customers, will "the free XAF" be offered with source or w/o source?

..Ben
19 December, 2006
Julian Bucknall (DevExpress)
Just to confirm: the free XAF for DXperience Enterprise customers will include source code.

Cheers, Julian
21 December, 2006
mark s
Will you support Microsoft CAB (Composite Application Block) for the more "advanced" developers who do not want to use XAF? I say this, because I love your product, but I have not heard anything about your plans for CAB. The other control vendors have already expressed their support.
Thanks
Mark
3 January, 2007
Jascha
Julian,

I realise that it is hard to make general statements like this without "generalising" but I think you may be unnecessarily limiting the scope of XAF. Focusing solely on the expertise of your developers ignores the fact that a very significant number of the business applications that "expert developers" produce are composed largely of simple functionality with only certain functional areas that are more complex. XAF looks to be eminently suitable for rapid development of those simple areas (and possibly some of the more complex ones as well). As long as the framework allows the integration of more complex areas (developed using the "traditional" development toolset) you have a win-win situation. This really could be as simple as allowing the developer to show a "traditionally developed" form from a controller method - although the more of the framework that can be accessed and reused in this scenario the better.

Maybe a better description of the limitation of scope should focus on the type of applications that are targeted (which I believe is mentioned in Oliver's blog) and the environments in which they run. I.e. bespoke, data-centric "business" applications with limited requirements for distribution. So, if the requirement is for an n-tier, enterprise-style, service-orientated application then XAF is probably not going to be too useful. But, let's not be blinded by the hype - there are plenty of cases where distribution, service-orientation etc. are not required. however, if you could add the facility in XAF to create a "proper" middle tier then all the better...

So, please don't unnecessarily limit the resource that you put into this framework by assuming that the target audience is defined solely by developer expertise. I have seen a few frameworks come and go overs the years and, admittedly on first impressions, this looks to be the most promising so far. By a long way. Also, don't underestimate the degree to which "expert developers" will jump at the chance to avoid the drudgery of churning out all the boring bits of systems that are necessary to support the more interesting bits.

Jascha
18 January, 2007

Please login or register to post comments.