This Blog


Favorite Posts


September 2009 - Posts

  • DevExpress Newsletter 11: Message from the CTO

    My Message from the CTO for the eleventh newsletter:

    Common Codebases

    The topic of "common codebases" came up in a conversation: "Is it possible to have a common codebase for similar controls that target different platforms?" My answer? Of course.

    The common codebase idea is a good one and something we've been doing for a long while (though we tend to call it informally an "engine"). Our charting product XtraCharts, as an example, uses a common engine across WinForms, ASP.NET, and WPF, and we'll be porting it to Silverlight for completeness. The engine is responsible for maintaining data about the chart (labels, legends, etc), calculating chart information based on the various series of data points, and so on. There are then platform-specific presentation models for displaying or rendering the chart.

    A similar structure is present in our reporting product, XtraReports. The printing engine not only loads/saves report definitions and is instrumental in creating a report, but it is also responsible for exporting the report to PDF, DOC, XLS, and the other formats we support. Each platform (currently ASP.NET, WinForms, and, partially, WPF) then has some specific presentation classes to render the report for preview.

    Ditto our scheduling products, XtraScheduler and ASPxScheduler, share common code for maintaining and tracking appointments and resources, and this will be reused in the Silverlight/WPF versions.

    In fact, talking about Silverlight and WPF, the presentation model (XAML) is almost identical (or can be limited and viewed as such), so it makes sense to write Silverlight/WPF controls in tandem, sharing a much larger common codebase than is possible, say, with WinForms and ASP.NET (which use totally different presentation models). Again, something we're taking advantage of.

    Having a common codebase does require some discipline to design and keep the engine "common" across the platforms supported. In a way, it can be viewed as layering the control in a similar manner to how we layer an application into presentation, business, and data tiers.

    Although the code reuse benefit is vital, there are drawbacks too. Using such common code will tend to produce more assemblies, for example. Also, you can no longer have platform-specific releases since changes to common code will affect all platforms (luckily this is not an issue for us, since we only release DXperience as a gestalt, all platforms at once).

    All in all, I think having a common codebase is an admirable goal, one which we'll continue to target.

    As an addendum, only yesterday, during our weekly conference call to discuss R&D progress, yet another example of this came up: it seems the WPF team discovered much common functionality between "docking" and "form layout". So, they're busy adding a form layout component (think XtraLayoutControl for WPF) by first factoring out the common code from DXDocking. It's a little too late for that for our WinForms products though — there would be too many breaking changes at this stage.

    Still it's fascinating that the layering we're all pretty much used to in the context of an application can also be done in the context of controls, even when targeting many platforms.

  • Quick Licensing FAQ

    I received a pre-sales email today that had more than 20 questions about various aspects of purchasing and licensing our products. Since it took me a little while to reply to it, I thought I'd justify the time spent by posting it here as a kind of FAQ. I've taken the opportunity of editing and pruning the questions to make it flow better.

    (UPDATE 22-Sep-2009: Clarified the support policy. I'd been too restrictive in my original answers.)

    (UPDATE 20-Nov-2010: Added a Q&A about build servers. See Q3-B.)

    (UPDATE 11-Jun-2012: Updated prices, products, etc. Added info about deployment servers. See Q1, Q2, Q3-C.)

    (UPDATE 22-Sep-2015: General update to bring the post up to date.)

    Please note: although this post answers some basic licensing questions in simpler language, it does not replace the End-User Licensing Agreement. If anything in this FAQ contradicts the EULA, it is wrong: the EULA is the legal document that you agree to and are bound by. We have several EULAs, one for each product or product type.

    Q1. What kind of packages does your company offer? What are their features and prices?

    JMB. Our packages form a kind of pyramid or a tree. At the bottom are the packages for individual platforms, one each for WinForms, ASP.NET, WPF, HTML5, and so on. Generally these have names of the format DevExpress <platform>, so, DevExpress WinForms, DevExpress ASP.NET, DevExpress WPF, etc. Above this level is DXperience comprising everything we do for .NET on all platforms, except for the eXpressApp Framework (XAF). It includes source for the controls as well as our IDE productivity tools. Finally on top of the pyramid is DevExpress Universal which also includes XAF, DevExtreme, TestCafe, Document Server, and so on. (Please note: for the pricing of all our products, please go to our pricing page. This page also details what each subscription contains.)

    Q2. Do you sell controls individually?

    JMB. No, our products are not sold as individual controls.

    Q3. What kind of development license policy do you offer?

    JMB. Our licensing is per developer. Each developer that uses our products must have their own license. We don't license per machine, per server, or demand any royalties or run-time fees. You should read our EULA (End-User License Agreement) here. If you have a testing team and they need to compile the application, then those testers are deemed to be developers and will also need a license each. Testers who just test the completed, compiled application (that is, use it much as an end-user does) do not need a license.

    Q3-B. If you don't license per machine, what happens with regard to an automated build machine or build server? There's no developer there.

    JMB. Since a developer can install on several machines (see the answer to Q6), get a senior developer to install his license on the build machine. If you like, he becomes the "owner" of the product on that machine.

    Q3-C. Can I install onto a deployment or production server then?

    You should not install our products on deployment web servers. For such servers, it sufficient just to deploy the runtime libraries of our products with your applications.

    Q4. What kind of distribution license policy do you offer?

    JMB. See the answer to Q3. It bears repeating though: we do not charge you for any deployed application, whether that application is a thick client on an end-user machine, or a web application being served to many thousands of customers from one or more web servers. No royalties, no per-server fees, no per-seat costs.

    Q5. Can a license be transferred from one developer to another?

    JMB. Yes. In fact you can do this yourself using our website once your company has purchased more than one license. Log in to devexpress.com, click on My Account, and then Assign Licenses. You can then assign a particular license to a given email address (that's how we differentiate between developers). You also assign a password at the same time.

    Q6. Can a single developer license be used on any number of machines?

    JMB. To a certain extent. The EULA specifically states two, but to be honest we tend not to worry unless there's obvious piracy going on.

    Q7. Do you collect any personal information during activation?

    JMB. No. The only information required to activate (actually, that should be "to install") is the email address and password associated with the license.

    Q8. Is it possible to activate products on a machine that does not have an internet connection?

    JMB. Yes, however the license validation still has to be done. If the machine being activated is not connected to the internet, our installer displays an opaque data blob that should be emailed to us (presumably on another machine), and we reply immediately with another opaque data blob that must be entered into the installer. Once that validation has checked out, the installer will proceed to install the product. The installer will tell you what to do and how to do it.

    Q9. What is the warranty period?

    JMB. Like all software you purchase, we do not provide any warranty. In essence, we provide the software "as is". To be absolutely sure of what we do or do not provide, you must read the EULA.

    However, when you purchase a license, you will have access to all upgrades and updates for a full year. You will also automatically have access to our support team. You can renew after the year is up. If you don't renew, you will no longer get free updates; however, you will continue to get support.

    Q10. Do you provide any discounts based on the number of licenses we purchase?

    JMB. Yes. The discount table is here.

    Q11. What avenues of support do you provide? What's the response time? How long does support last?

    JMB. Support is provided by one of two methods: either by a web-based system we call the Support Center, or by email (support@devexpress.com). We aim to respond to all questions within one business day. Support via phone, IM, or chat is not provided. The support team may, in certain circumstances, decide a problem is intractable enough that they'll have to access your development machine using Remote Desktop or similar, but that's only decided on a case-by-case basis.

    Support is only provided to a developer with a valid license — we may on occasion ask for your license details to check — however the license doesn't have to be active. In other words, if you decided not to renew at the end of a year, you will continue to get support. Obviously, if you don't renew and have an issue with the latest version you have, the support team will endeavor to find a fix or a workaround for that version. It may be that the only solution they find requires you to have the current release, in which case you would then have to purchase the upgrade.

    Q12. What is the delivery mechanism for your products? Do you offer major/minor versions for new releases? What about service packs or hotfixes?

    JMB. Delivery of our products is by download only. We provide 2 major releases of our products a year, with about 3 - 5 minor releases in between. We send you an email when a new release is ready for download. Sometimes we make hotfixes available for certain issues: these are individually downloadable from the issue page in Support Center.

    Q13. Do you charge for minor/major releases? Do the service packs/hotfixes cost extra?

    JMB. No. When you purchase a license, you get the right to download all releases for a full year for free. At the end of the year, you should renew the license in order to receive all the releases for the next year, and so on.

    Q14. Do you offer full source code for your controls?

    JMB. Yes, the higher-level versions of our products contain all the source code for the controls contained in that product. So for example, DXperience and DevExpress Universal contain all the source for the controls for all platforms.

    Q15. If source code is available, are we allowed to change the source code? Are there any limitations to doing so?

    JMB. Yes, of course you can change the source. However, you would be then responsible for applying the same changes to the source every time we release a new minor/major version (and there could be upwards of 15 releases a year). Sometimes, we may rewrite or refactor our code such that it's no longer obvious how to apply your previous changes. Depending on how extensive your changes are, we might not be able to provide support.

    You cannot circumvent our license agreement by providing non-licensed developers with controls you've altered by changing the source. Again, read the EULA to determine what you can or cannot do in this respect.

    Obviously, we will not provide our signing keys for any assemblies you modify, so be aware of possible "DLL hell" problems that could occur on end-user machines if they have several apps from different vendors that use our controls.

    Q16. Are we allowed to give the source code to the controls (whether we change them or not) to our customers?

    JMB. No, the source code is not redistributable, even if you change it. The only files you may distribute are explicitly listed in the EULA. Your customers will have to purchase a license.

    Q16-B. I'm writing an open-source product with your controls, so I'll need to provide your source as well. Can I do this?

    JMB. No. Again: our source code is not redistributable, under any circumstances. For an open-source project that uses our controls, downloaders will have to purchase a license before they can compile it.

    Q17. If we enhance your controls, is there a partnership program or similar to get our changes into the main product?

    JMB. No, I'm afraid there isn't. We do not incorporate other people's code into our own; there are too many legal ramifications to cover, and to be honest we'd prefer implementing the solution to a given issue/suggestion ourselves than paying legal fees to cover those ramifications. We are, after all, developers; it says so in our company name.

    Q18. If a bug is reported in any of your controls, would you give us a hotfix? If so, within what timeframe?

    JMB. There are no hard-and-fast rules here: it really depends on the severity of the issue, whether there is a temporary workaround, etc. In most cases, you will be able to get a hotfix from support, or from the issue's page in Support Center. Sometimes, there's no possibility of a hotfix and you will have to wait for the next minor release. Since we publish releases every three or four weeks or so, it's unlikely you'd have to wait too long.

    Q19. Do you have a premium level of support where you provide dedicated resources to help us or solve the critical bugs we may find?

    JMB. No, there is no such premium level of support. We endeavor to fix critical bugs (that is, those without a viable workaround or those visible to many customers) as soon as possible.

    Q19-B. How about priority support then?

    JMB. Priority support is provided with DevExpress Universal. Those questions that can be assigned to a Universal license are automatically prioritized and will be replied to before any others.

  • Two great new additions to our DXSquad family

    DXSquad is our team of proven developers who are gracious enough to help us and our customers on our forums and in the wider DevExpress community. It's a rare honor to be invited into the ranks (I'm not a member, for example, that's how difficult to get in), and I have the privilege to announce that we have added not one, but two new members.

    Please join me in welcoming Apostolis Bekiaris (known as Tolis) and Gary Cox (known as, er, well, Gary) to the team. If you've been using our forums for a while I'm sure you've come across these two posting away like crazy, only now they can do it with the DXSquad badge prominently displayed. (We do have a badge, don't we, Max?)

    So welcome Tolis and Gary!

  • MonoTouch: Writing iPhone apps in C#

    It's only been three days since Novell and the Mono team released MonoTouch, but I've already had the first email asking whether we're going to be supporting it in any way. Oh, and while we're about it, what about Mono proper?

    First things first: MonoTouch is a technology that enables you to write iPhone (or iPod Touch) applications in C#. No longer do you have to learn Objective-C and grumble about header files and having to develop without a garbage collector: you just write good ol' C# in the same way you already do, and a compiler will compile your .NET application and associated libraries into a native iPhone application (which, incidentally, gets around JITting, something that's not possible with the iPhone run-time, so I understand). Because of this non-JITter approach, there are some limitations with generics — which, if you recall, are instantiated by the JITter at run-time — and there's no capability to generate/emit new code at run-time either. Debugging support is limited too.

    Nevertheless, MonoTouch provides C# 3.0 support, Silverlight capabilities, the usual garbage collector, multithreading support, bindings to the native iPhone APIs, and so on. Even better, you can do things like use event handlers for CocoaTouch controls (and if you know how that all works in Objective-C, you'll be crying with joy). It provides integration into both XCode (fully supporting Interface Builder) and MonoDevelop. And so on, so forth.

    Having said all that, what, if anything are we, DevExpress, going to do about it? Well, I think the only real answer at the present time is to evaluate it. Obviously a great number of our controls would make no real sense on an iPhone: after all the device has no physical keyboard (apart from the on-screen one), no mouse (just your finger!), and there are standard single and multi-touch gestures to support. The user experience is very different and our controls are designed for a different UI completely.

    Sounds negative, however, we've a lot of iPhone fanboys on staff (even Ray has one), and some of us have and use Macs already, so I dare say there might be some experimentation going on to find out whether some of our products would transfer over to the iPhone. An excellent possibility is XPO of course (there's no UI to trip us up), especially since we've been doing some work already on the Silverlight port (AgXPO).

    So, I'd have to say at this stage that there's a possibility, but that an awful lot of research would have to be done first. No promises, and definitely no guarantees. No timetable either, before you ask, because we have our real work to do first enhancing our current line of controls on the standard .NET platforms (version 2009.3 is currently being worked on, of course).

    As for Mono itself, we've been approached by the Mono team to see if we're interested in supporting Mono with our current products, and I'm going to do some research to see what the issues are and where they lie. Again, no promises.

  • DevExpress Newsletter 10: Message from the CTO

    My Message from the CTO for the tenth newsletter:

    Software Engineering?

    Something resonated inside when I reread the last newsletter's Message for some inspiration in writing this one. In it, if you recall, I said that writing quality software was an iterative process that moves your software towards higher quality, that you can't just write "good" software straightaway. Writing software is more like how a painter paints a portrait than how an engineer builds a bridge, more art than science.

    Like a painting, software builds up from the broad background wash to the nitty-gritty fine brushstrokes. Make a mistake, just erase or fix it: software is malleable. In fact, the fix, once complete, won't even be visible. Heck, that's one reason we have version control: it's the institutional memory of how the software got to where it is. The New Yorker has a great series of videos showing the artist Jorge Colombo finger-painting pictures using the Brushes app on the iPhone: that's how I visualize how great software is written.

    I'm not saying that writing software should become this free-for-all, anything goes, Wild West environment. Achieving excellence through iteration is still guided; it's certainly not random. We're pushing the software up the quality slope all the time. But it certainly isn't engineering in the traditional build-something-physical sense.

    Maybe it's time to emphasize Pete McBreen's Software Craftmanship idea again.

    OK, I just had to get a reference to the finger painting on an iPhone, but the point remains. Writing software is an iterative malleable process — building up to a finished product — and the mistakes we make en route aren't even visible in the finished product.


Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners