Here in Australia we like our public health campaigns graphic and blunt. This is what our cigarette packaging looks like and we have a long running TV campaign based around the slogan of “if you drink then drive you’re a bloody idiot“.

I have a new public health warning to add to the list, this one designed to help preserve the future sanity of Delphi programmers.

After today, if you buy Delphi without also buying maintenance you’re a bloody idiot*.

So what happened today to prompt this warning?

Statements today from an Embarcadero representative on a public mailing list indicated that the soon to be released update providing support for iOS7 will be for XE5 only, XE4 users will not receive it. Apparently this is due to it building upon changes introduced in XE5.

I don’t know whether this means XE4 can’t be used to build iOS7 applications or if apps built with XE4 will just appear a bit like a fish out of water when run on iOS7. We’ll find out soon enough though I’m sure.

Either way if you purchased XE4 to do iOS development and you don’t have a maintenance contract or a free upgrade to XE5 you have a good reason to feel shortchanged and I’d encourage you to let Embarcadero know it.

After today though if you buy Delphi without maintenance and find yourself in a similar situation I’m sorry but I won’t have much sympathy for you. Here’s why.

At the recent XE5 preview event in Sydney the question was asked if the 6 month release cycle was here to stay. Malcolm Groves with David I in attendence told us that more likely than not, yes the 6 month release cycle would continue and that was how they would keep current with the many different releases of Windows, OSX, iOS and Android. Today’s iOS7 support news confirms this, XE4 released only 6 months ago has been effectively retired.

Delphi as far as I’m concerned is now a subscription only product. Other modes of purchase no longer make sense.

Personally I’m fine with that. I’ve been on maintenance for longer than I can remember and I’ve found it to be overall a good deal. It’s also the model used by most of the third party vendors whose products I use. Adobe’s move to subscription only model for their development tools has also been well publicised although their model requires you to keep paying or you lose complete access to the products which I would never want to see for Delphi.

What I’m less enthused about is that Embarcadero is still today selling Delphi licenses without including mandatory maintenance subscriptions as part of the deal. Developers who today buy XE5 without maintenance will in 6 months time most likely find themselves with a similar issue to this upcoming XE4/iOS7 situation. And that cycle will continue, with the shine taken off every new release by a flood of complaints from upgraders who aren’t ready to pay for another upgrade just 6 months later.

If this is really our new reality Embarcadero needs to start factoring in mandatory 12 month maintenance subscriptions to the price of all Delphi upgrades, along with some generous introductory discounts and amnesties to ease the financial impost of starting a maintenance subscription. I’d also hope that having all their customers move onto maintenance would allow Embarcadero to introduce some across the board price drops which will benefit both existing users and make Delphi more competitive when it comes to attracting new developers.

* I won’t really think you’re a bloody idiot, just not all that well informed.

36 Responses

  1. Since we only do Windows development and I think FireMonkey is an insult, I would have felt like a bloody idiot if we hadn’t canceled our SA after XE.

    Embarcadero won’t get a nickel from us until they start fixing existing bugs in the area of Delphi that matters to us.

    1. Yes there hasn’t been much VCL work done in the past few releases and if you aren’t someone who takes the longer view (i.e. learning mobile dev proactively and/or supporting the product), then canceling your SA was probably the right course of action for you back then.

      I wouldn’t recommend VCL developers cancel their SA today though, the wheel has to be turning back to a focus on VCL soon.

        1. Primarily because the existing customer base is demanding it. Mobile is going to part of almost every developer’s job sooner rather than later and it’s great that Delphi is there now but Embarcadero can’t ignore the fact that many Delphi programmers aren’t there yet.

          1. >Primarily because the existing customer base is demanding it.

            If that were a driving factor for them we’d have seen Unicode and 64bit support years earlier.

          2. For some people 64 bit and Unicode were essential. Personally I could have quite happily continued without them (I still haven’t built a 64 bit application).

            Everyone’s needs are different and it’s Embarcadero’s job to balance them and deliver what is needed by the most number of people.

            Right now the anecdotal evidence leads me to think the demand we’re seeing in all the forums and blog posts is that they’ll go back and revisit the VCL before the VCL crowd (i.e. everybody) starts to feel too unloved.

          3. I’m afraid that becouse FM also alows development of Destop applications EMT will only stick to that and forget about VCL.
            Lets face it if they focus on FM they are fixing isues for both Desktop and mobile enviroments.
            I myself would rather see them to focus on VCL becouse by my opinion FM si terrible.

            But more than that I would rather see them to go and focus on adding new features which would make application development easier for us.
            Which features I have in mind?
            – compleetly rewritten code insight and error insight which would actually work as they should
            – adding ability to profile your code out of the box without using third party components or writing tons of code to make it work.
            – ability to make code gaphs (code dependancy graph and flow graph) out of the box without using third party components
            – and I could probably think of of even more features.
            The best thing about these my features is that they would benefit to all developers on all platforms. And yes they might even benefit guys at Embarcadero itself.
            I posded my sugestion several times now but for now I never got any response from EMBT about them. Not even saying “theese suggestions are good”, or “theese suggestions are bad” or anything. Like I have never even written my sugestions.
            And this is what pisses me off as it clearly shows that guys from EMBT are prepared to listen to only certain pepoles suggestions and it seems I’m definitly not one of them.

          4. With the vast majority of their users working in the VCL they aren’t going to forget about it, they’ve just had to focus resources on FireMonkey for a period to deliver the mobile versions.

            In regards to feature requests I don’t think it’s just you, I can’t remember them commenting on feature requests from anyone so it’s probably their company policy not to.

            They do sometimes explain why they chose one implementation over another, there was a lot of discussion from them why they didn’t implement Unicode as a compiler switch for example.

            As for the feature requests you just listed, personally I’m only interested in the first.

            When it comes to a profiler there are already 2 excellent options that I know of. A profiler Embarcadero produces is unlikely to be as good as these.

            As for your third suggestion, code graphing tools, there are similar modeling, metrics and audits in Enterprise already and I’ve never heard of anybody using them. It’s a niche requirement and the sort of thing better handled by a third party e.g. CodeHealer, Peganza, ModelMaker.

            Many years ago Nick Hodges started for suggestions and I can see there is a profiler request there you could vote on.

            You can’t go just by that site though to judge popularity of feature requests. For starters I have no idea if it’s official status within Embarcadero these days and I’m sure most people don’t even know it exists.

  2. I think you need to correct your statement to :”After today, if you buy Delphi you’re a bloody idiot.”
    Simply put, for the cost that you must pay the value of the product just isn’t up to standards.

    1. I simply can’t agree. Yes there are issues but none that prevent me earning a living using Delphi and the new mobile platforms are opening up new opportunities for my business.

      1. +1 again. I have 3 potential enterprise app sales for my firm already. Based on working prototypes that look good and perform well.

        Is it perfect? No, far from it. But usable and valuable? Definitely.

      2. This doesn’t address the post you’re replying to. That post was about “value”. It wasn’t about whether you can compile your code with Delphi. You could probably write it with COBOL too. The reality is that other products offer far more for far less, and in fact many developers can function entirely with open source development tools.

        And that’s without getting into the fact that Delphi has an almost non-existent ecosystem today – no commercially published books or magazine, no free online courses, not taught in academia, no more jobs, marginal 3rd party support, etc. Competitors using mainstream tools can purchase off-the-shelf libraries that don’t exist for Delphi, can use official SDKs for their mainstream languages rather than having to roll their own, can easily find developers, can actually attend a conference (which are completely dead in America now), etc.

        It’s the elephant in the room and you can’t get an Embarcadero employee to address it and it seems they have no plan for dealing with it. Adopting a tool without a functional, growing ecosystem would make one a bloody idiot today. In fact, some of the major startup gurus talk about ecosystem as one of the primary factors in choosing a development language – one of which specifically cites Delphi as a language with a dying ecosystem you wouldn’t want to bank on!

        1. Value is a subjective concept and I addressed it from my point of view. The value I receive from each version of Delphi far outweighs the financial cost of renewing my maintenance agreement. Could Delphi be cheaper? Certainly and I think it needs to be to attract new developers who are less likely to perceive the same value in the product as a long term user.

          As for Delphi’s ecosystem, well this bloody idiot is doing his best to help rejuvenate it and I am most certainly banking on it.

  3. i like your comments…. but i think that bloody idiot are the people that continue using products from embarcadero. I think that is the moment to change your way of thinking and look for another products, probably not better, but more cheaper.

    1. We should look for “probably not better, but cheaper” product!?

      No thanks. I’m a professional developer and I want the best tools available to me that money can buy.

      Delphi needs to start to come down in price to become more competitive and attractive new developers but as an existing professional Delphi programmer it repays its annual maintenance costs to me many times over.

      1. >No thanks. I’m a professional developer and I want the best tools available to
        >me that money can buy.

        That’s an old way of thinking, from the days when Microsoft and Oracle ruled the Earth. Many of the best tools available money can’t buy, because they’re free and open source. 🙂 Spending money doesn’t make you better, or smarter. It can make you more foolish if you spend more than you have to.

        >Delphi needs to start to come down in price to become more competitive and
        >attractive new developers but as an existing professional Delphi programmer it
        >repays its annual maintenance costs to me many times over.

        This isn’t the only consideration. What if an alternative would repay its costs more times over? The questions you need to ask include what Delphi provides/can do that others don’t and vice versa, and then factor cost in as well to arrive at a value proposition. Of course, factoring in ecosystem, reliability of the provider (Embarcadero) and customer treatment, and Delphi faces one heck of an uphill battle to come out as a value leader.

        1. Alright then. I primarily write Windows desktop applications with a bit of experimenting with mobile applications that supplement those desktop applications.

          What is the alternative development tool you suggest I move to for this sort of work?

          Note that since I don’t find my Delphi maintenance renewal costs excessive I’m not satisfied with the tool just repaying its cost many more times over than Delphi does. For me to make the decision to shift purely on a financial basis it will have to increase my income significantly.

  4. Agree with all of that. Like you I’ve had maintenance for years and thought it a good deal.

    It’s not as if they’ve been shy about pushing the benefits of maintenance over the last few years – even since Nick H’s day, I think.

    It would seem to me the fairest way to proceed now would be allow people, as far as practicable, to retrospectively buy Maintenance. So if you bought XE4 in May 2013 without it, you should be allowed to buy it now – with renewal in May 2014.

  5. Visual Studio is sold at the price of maintenance contract. I agree that maybe double the current maintenance price for the first time buyer is an attractive choice. I think one year granted to EMB in order to substitute that contract should be enough. That’s just fair.

    The biyearly delivery is a result from the reduced innovation cycle times too. 8 – 4 – 2 – 1 – 0,5 – continuous delivery. (length of the innovation cycle in years). When various platforms offer continuous delivery Delphi developers as well as EMB will have to find a compromise.

    It’s no longer SA it’s CIA. Continuous Improvement Agreement. That’s maybe a new foundation the relation between the EMB customer and EMB as the technology provider. Well funded on a solid commitment to quality from both sides. I agree – for the Delphi developer the bi-yearly release cycle is little bit surprising. So huge discounts should be granted.
    (Carrot crazy)

  6. Ha, ha, ha… We are all bloody idiots, smart ones are long gone…
    You are bloody idiot if you don’t pay for SA because you get stuck with old bugs, and you are bloody idiot if you pay for SA only to enjoy seeing your working code gets screwed with brand new bugs.

    1. Ah yes the smart ones who left long ago for this mythical bugless development tool.

      Are there bugs that annoy me, yes.

      Are there bugs that prevent me from earning a comfortable living using Delphi, no.

      Your own experience may vary of course.

      1. Well, I am obviously still here and I plan to stay here at least for the Windows part. Delphi still offers me more value than other mythical bugless development tools.
        But there is very little value in new mobile tools for now: too buggy, too big, too slow, not running on the devices I need to support, too incompatible with existing code and at the end just too expensive. And Windows part that I use every day is standing still or getting worse.


  7. Yes, SA rocks!

    The only reason someone shouldn’t get it is if they intend to skip several releases at a time.

  8. Interesting. I’m currently doing c++ and PHP in Eclipse on Ubuntu as well as Delphi in Win8. I’ve been surprised a few times at the relative stability and maturity of the two environments. But then, I am using Delphi 2010 for the most part with occasional use of XE3, so I’m also missing out on a lot of the new bugs. Even so, with the exception of MySQL Workbench (which I use, but it crashes most days) and the Zend extensions to everything (which are unweildy and have a huge learning curve, plus their Eclipse mods crash a lot), the LAMP stack has been brilliant compared to the Windows-Delphi one.

    In terms of setup time and initial productivity Delphi is a complete pig of a thing, plus those experiments are often very expensive – buying something it turns out you don’t need, taking days to find that out. I’ve been shamed a few times by taking days to discover that there’s an easy way to do something in LAMP that Delphi can barely do at all.

    The thing Delphi does that’s awesome and there really isn’t a good LAMP competitor for is WYSIWYG GUI design. There are tools, they’re mediocre.

    1. And if the cost of a Delphi maintenance subscription was the equivalent of a few week’s earnings or more that might bother me.

      As it stands though I can recover the cost of my annual Delphi maintenance subscription in far, far less time than that so it really isn’t worth my time trying to pick which versions to buy and which to skip.

      1. >As it stands though I can recover the cost of my annual Delphi maintenance
        >subscription in far, far less time than that so it really isn’t worth my time trying to
        >pick which versions to buy and which to skip.

        I’ve been advising some potential start-ups. Skipping the details, I became alarmed that one’s business model seemed to be “rich people have a lot of money so they just won’t notice that we sell them a lot more than they actually need.” I thought it was untenable and told them so. Now I’ve read this post and I’m starting to rethink my position. 🙁

        It isn’t worth your time to choose your tools carefully? And you have no problem throwing away hundreds of dollars you might not need? What about potential bugs or breaking changes that may affect your existing code? It’s somewhat disheartening to find that one of the last people advocating Delphi doesn’t actually examine his own tool, let alone do a survey of other available tools on the market, before buying. I strongly suggest conducting a general development tool survey; I did one in 2012 for two start-ups and you might be very, very surprised (and if you’re a Delphi hand, disheartened).

        1. Anyone who runs a Delphi programming shop that has ample work and still can’t find the money to renew their maintenance agreements is doing something wrong.

          I’m a self-employed Delphi programmer (very far from rich) and I have no problems whatsoever quite easily paying for my annual Delphi renewal.

          For me it’s important that I have access to every Delphi version, both the good and the bad ones, so that I can learn the new features inside and out and so that when I come across a job that is using a particular Delphi version I’m ready to go straight away.

          Do I wish every Delphi version was bug free and usable from day 1? Of course I do. I take the longer term view though and value the benefits I receive from that more than the “few hundred dollars”.

    2. 🙂 No. You always by the next year anyway. EMB are here, the budgets are assigned, they develop and very likely the next version. No one payed for version one. The only thing remaining – LachlanG pointed out correctly – the price is too high in the meanwhile. EMB raised the price and did produce something that made the product look worth the money. A software vendor sells to you what customers financed last year (not considering fixes). If you don’t participate in financing the next version other will have to. That’s the disadvantage of this strategy. No result for no money is a perfect match but no helpful at all.

      1. You always buy the next version anyway and finance next year’s development. (*corrected the first sentence *)

  9. “I wouldn’t recommend VCL developers cancel their SA today though, the wheel has to be turning back to a focus on VCL soon.”

    Oh my! Do you have any basis for that theory? Cornered the market in rose-coloured glasses, perhaps?

    EMBT and its predecessors has steadfastly refused to fix – or sometimes even acknowledge outstanding VCL bugs. I even saw recently that attempting to recompile the VCL now contravenes the licence agreement – This is despite the opinion of none other than Marco Cantu “Delphi is the VCL”

    The reason given is some folderol about ” prevent problems with different versions of the packages on client PCs”. Apparently a problem with VCL, but not RTL (for which a recompile project IS available, at least in XE2.

    The user community has been demanding action for nearly two decades on the VCL shortcomings. I’ve said many times that the supplied code for VCL/RTL should be a shining example of clear, WELL-DOCUMENTED code. As it stands, it’s just a fog-shrouded minefield. You’d have to be a bloody idiot to use it rather than spending even more money on buying packages to implement the basic functionality that doesn’t work out-of-the-box from third parties who are actually interested in building a reputation for reliability.

    As a simple but well-worn example – why does TButton have a Color property the doesn’t work? What is the point of exposing what is essentially a storage field with a misleading name? Hasn’t been fixed since D1 – and now no doubt the excuse would be that it might break existing code.

    Get a fix from the net? What happens if the version I choose fixes bug A and B but not C and introduces D – that are only detected by my customer in Slobbovia using a hardware platform I’ve never heard of and his complaint isn’t in a language I understand? Why should every Delphi programmer (including both of the new recruits attracted by the new target platforms) have to endure this bizarre initiation ceremony of (repeatedly) researching the bug in their code to find that it’s a bug in the supplied codebase?

    We’ve heard a lot about “one code base” from a particular quarter. How about one RELIABLE Thread-safe non-inflated component set? We’re faced with a ransom demand for XE3 (XE2 + bugfix – iOS) and XE4 (XE2 + bugfix -iOS +bugfix +iOS) and XE5 (XE2 + bugfix -iOS +bugfix +iOS +bugfix + Android.) Even the compiler back-end is now (we’re proudly told) LLVM – not an EMBT product. Yet what we’ve asked for and WERE willing to pay for is a reliable RTL and VCL (insert sounds of crickets chirping.)

    Negative? That’s an easy, predictable, vacuous non-constructive criticism. The issue is how to enhance the product and grow the userbase to ensure the future of Delphi and our individual investment. As ever, that means delivering to the customer what the customer wants. Fitting a sunroof and chrome exhaust pipes and twin overhead foxtails is all very fine and good, but in the end, you’ve still only got a three-wheeler. What would you prefer to do? Rewrite in some other language or retire?

    I’m opting for retire. VCL revision?

    1. I think it’s pretty clear that the recommendation that has so offended you is just a personal opinion and isn’t based on any hard evidence.

      As for the rest of your comments I’m not sure what you expect me to say. Yes Delphi, like all other software has bugs. Yes upgrades fix some bugs and introduce others. Yes third party stuff is often better than what you get in the box, but if it wasn’t who would buy it.

      Yet despite all that I still manage to make a comfortable and enjoyable living working as a Delphi programmer. You’d never think it was possible reading some of the comments that have been posted here in the past 24 hours. 😉

  10. Lately I also have held myself from recommending an upgrade since XE3 to my bosses. And the 6 month cycle has really hurt what little credibility EMB had in my company’s eyes.

    My company isn’t rich and only due to my strong recommendation that we bought XE3 Architect (The first Delphi IDE we bought) after getting discounts due to reasons similar to being the first company to buy in the region.

    We mostly use FM for 32-bit windows and I know we will get good money out of it, still I don’t see myself recommending an upgrade anytime in the next couple of years. Rather I am getting hinted all the time that I recommend a version which is available through torrents in the nearing review.