You are going to pay for bug fixes. And you’re going to like it.

58 Replies to “You are going to pay for bug fixes. And you’re going to like it.”

1. As long as it worked like a magazine subscription where I can continue to read (use) the thing that I paid for I’d be fine with this model. But my suspicion is that it’s really more like renting, once you quit paying you’re done. Which is fine as long as I can still use the artifacts created by the software. Would Embarcadero build a check into your executable that checks to see if you the author has an active subscription and not let the executable run if you don’t? I can easily see that happening.

   • Any product you get under the Embarcadero Update Subscription is perpetually licensed. The only things that stops when your subscription ends is getting updates. So your magazine analogy fits nicely.

     • This is sad news sir. I do not like that policy . I believe once you have a major version you should get the updates everyone does else the whole software does suck and does not meet the Quality Assurance in such cases better use Free Pascal i would say this is the compiler Embarcadero is using and you know it very well as i do. Charging people for updates that they have already payed is not something nice. We are talking about fixing bugs for something you bought. We are not talking about new versions with new features. I Totally do not agree with this approach and i believe its a MILKING THE CUSTOMERS APPROACH maybe kick some hungry mongers from the company to get it nice and clean. If you got a Million you ask for another one because you want to live to a more expensive house? How much money have you made so you cant support that?

2. My main issue with subscription only software (ie software that stops working when you fail to renew) is that removes the customer’s ability to vote with their wallet. If you are dissatisfied with the direction of a product, the most powerful signal you can give a vendor is to stop buying (upgrades). With a subscription you are locked in, you have no choice but to keep paying, otherwise you are left with inoperable software and unable to actually do any work. In delphi’s case, it’s not like you can just switch to another vendor’s product.

   Can you imagine the furore if your accounting department forgot to renew, someone was away and your renewal didn’t get approval etc. We see this all the time, but in the mean time while they get that sorted, the product they have has to continue to work. That’s what we do with FinalBuilder.

   • Luckily RAD Studio continues working if your don’t renew as well. All the update subscription brings the updates.

     I’m pretty sure Office 365 and Adobe, that Nick mentioned in his post, stop working if you don’t renew, but you would need to check their documentation to be sure.

3. You want more money for the same service.

   And you promise better service… later, maybe. If you have time for it.

4. I agree with this. Even in development shops for companies, bug fixes have to be paid for by customers, even if those customers are within the same company. Why should it be any different for commercial software?

5. I think Appmethod is good system that rent a software, people can pay every year and dont think about update or new version. Rad studio must be like this.

   • RAD Studio and Appmethod are based on the same technologies. You have the choice about how to purchase and use them. RAD Studio – perpetual license. Appmethod – subscription. You have the choice.

6. I cannot express how much I disagree.

   You show how companies and their behavior have changed your brain and way of thinking. No software works right out of the box? You must have been using really shitty software in the past if you say such a thing. Does software has bugs? Yes, of course. But none of them should be deal breaking as it is usual nowadays. I wonder if you would still say that when all the cars and other vehicles are completely controlled by software. “Oh, the car did drive off the bridge. Well, no surprise, it just had version 1.0 installed. But I am paying some cash every month to my car seller to make it safer later. It also just stopped working on the middle of the road because its memory consumption was not properly tested… no big deal, future version might have fixed it!”

   Remember the days of gaming consoles that just had a cartridge? There was nothing to patch and games had to be as bug free as they could. And most of them were even if they contained some glitches sometimes. And today? Everything comes with “day one patches” and some things don’t even work then just because you can, everything is connected to the internet and can patch all the time.

   The same is the case for other software. If the pressure to deliver as bug free as possible is lowered by the possibility of being able to “fix things later” you automatically will care less – subconsciously.

   And in fact I always could upgrade all my Microsoft software without some subscription (even the Express editions *hint hint*).

   • I cannot disagree more with you here.

     Comparing MS and Embarcadero is like comparing apples to bananas.
     THe apparent inability of very experienced and good developers like yoi to not realise the humongous differences between back then and now always startles me.

     The times you talk about were very different. We have, today, loads of interconnected systems, lots of moving parts and a complexity unknown of even 5 years ago, let alone 10.

     The two situations are utterly uncomparable.

     I agree, if you so wish, that there are lots of bugs from past versions that need to be resolved. The company I work for, as well, has a huge backlog of “known behaviours” which are less than ideal 🙂
     So, why don’t we drop everything and fix those? It boils down to priorities. You see, for as much as we’d like to be able to do it, we have just a certain amouint of time to do the coding, the testing, the QAing and the research. Yes, we also do lots of research for various reasons, because otherwise our competitors will catch up to us and we will be driven out of the market. Hence, we have to choose: do we fix that bug that looks easy enough but could potentially be a drain of our time, or do we rather put in that small little feature that we already know will take this amount of time? The call, of course, isn’t the developers’ but the Project Managers’ or the CTO’s depending on the situation.

     As usual, I might be wrong, but this is my experience 🙂

     A

     • I am not talking about cleaning up the backlog in one go. I am talking about awareness for quality code, and using modern tooling and practicing the so called dogfooding. Thinking and more thinking before coding, clearly defining specs and writing tests does not take more but less time in the long run. Well designed and tested code does not require as much fixing and maintenance. Unfortunately most project managers and CTOs often fail to realize or ignore that and raise technical debt. Despite the fast pace of the IT industry and its technology a huge part of software development is still like a bunch of cavemen hunting a mammoth with sticks and stones.

       • Hi!

         That works well for cases where you can actually do that.
         Please keep in mind that there are many, many, many applications that were written in the 90s and that are still going strong. There are systems which have a massive internal library which makes those a complete platformm unto themsevles. For those cases, knowing Dekphi is only part – often the easiest – of the journey.

         I have never worked on the IDE’s source code, but I am willng to bet that there is stuff there which fundamentally dictates how things are done. Changing anything that deep would have ripple effects all over the place. I can understand that nobody’s willing to mess with that. Do you think Allen Bauer is a throglodite? I don’t think so, I think he’s got lots of balls in development. But at a certain point you have to make a choice: do we definitvely break out from the past and essentially rewrite it from scratch, or do we plough on and try to add value? The problem here is that doing a rewrite means adding value olnly in the very, very, very long term whereas adding features and options adds value now, which is what most customers want. Would you be iok to wait, I’d ssay, at least 2 or 3 years for a complete re-write? i mean, look at the pace of technology: do you REALLY think they can stop for 2 or 3 years? Seriously?
         I don’t think so and, after a bit of reflection, so do you, I am sure 🙂

         By the way, this is the same reason why the VCL can’t be ported to multiple platforms and hey needed to make a completely new framework based on entirely different concepts and philosophy. When they tried to fit a square peg in a round hole using CLX, it failed. That was partly due to the fact they, once more, were well ahead of time, and partly was due to the fact they were trying to shove the VCL concepts in completely different environments where those concepts didn’t exist in the first place.

         Opinions?

         A

         • I don’t know why you bring up specific companies or developers.

           I was commenting on software development and the behavior of the industry in general.

           As for rewriting. I also never said that and in fact unless a software is completely dead (which happened to enough software out there in the past due to technical debt, that’s why I brought that up) it would be a stupid idea.

           I also really believe in “do one thing and do it well”. I know that when you start doing several things at the same time they won’t be as good.

           Also you should not hide behind a pseudonym but post with your real name when arguing with me.

         • LOL!

           I bring up specific companies and developers because the original post revolves around… uhm.. a specific company 🙂

           As for the fact you don’t know my nickname, it means you weren’t around the Borland Forums in, like, 2002+ because everybody knows my name associated to this nick 🙂

           It’s Andrea Raimondi here 🙂

           Anyway, the thing you do not seem to grasp is that lots of customers need to advance their products. This means they need new, shiny features that do something for them which they can integrate easily.

           Now, for as much as I’d like that the old mantra were maintained (i.e. When it is ready) I do not think this is possible anymore in lots of cases. There are cases where this can be done, but they are becoming fewer by the day, especially in a highly competitive field like software development, where every other day a new language or library is born which purports to revolutionise the way developers work.

           Then, if you think of stuff like FireMonkey, it beggars belief that they managed to get as far as they have in so little time. It’s so incredible it’s mind-boggling.

           I have said this numerous times: try to create a multi-line TEdit control for the VCL. That’s the stuff of nightmares. And the VCL is a proven framework with years and years of improvement. And yet, you get there, and it’s awful. Seriously awful.

           The sheer number of things you have to do to make it work is unbelievable.
           And that is for one, well-defined and proven platform. Now transfer this onto a field where you have different platforms with different needs, philosophies and technical subsystems. I would rather run off for the fields than trying that.
           And that is just a bloody text input control, nothing fancy.

           Add to that that the IDE is an extremely complex beast, and there you have it. You have to choose.

           Some people say that after all this time, Error Insight still does not work properly. That is true, but I can tell you it has had lots of improvements, because it fails a lot less in XE than it does in BDS2006 for me. Will it ever work perfectly? My guess is no, simply because language features will be added, new stuff will come in and it is not guaranteed that there will be time to put in that small change which will make it “better”.

           That’s not to say that, in an ideal world, you are wrong. Quite the contrary, I think you are absolutely right “in theory” but there’s this nasty thing called “reality” that we have to face and that holds us back 🙂

           As I have said, there is stuff out there that comes from the ’90s. It’s just… it’s just impossible to add new ways of developing software to systems that old, simply because at some point, your beautiful classes will have to live together with the trolls from the ancient times and that just does not work, because in the end, bugs will slip in simply because you have to actually use those classes with older code.

           Come on people, I can’t believe we are having this discussion,. Seriously. I thought that this kind of stuff was a given. I can’t believe we are still at this.

           A

         • I suggest reading “Working Effectively with Legacy Code” if you think that you have to keep old crap around poisoning all the other code in your application and infecting new parts.

         • Stefan, for Heaven’s sake, that “old crap” is WORKING CODE.
           It is generating REVENUE for the company and the customers.
           Some of it has been doing so for a decade or more.
           Touch it, and your bets are off. You might be lucky, yes, but you might not.

           That is my point. You do not touch working code unless there is a good reason.
           You do not touch it. That’s a simple lesson you learn very early in the career.
           You don’t play games with it, because it is WORKING CODE. You don’t try to
           adjust it, you leave it alone until it breaks.

           WHEN it breaks (because, at some point, it always does…) then you can have a look around and see whether you can do something to improve it. Sometimes, you can.
           Other times you can’t, because it’s intertwined with other working code.
           So you fix the bug and get out.

           That is how it works when you have a compiled application with several millions LOC that has to go to thousands of customers.

           But I’ll buy and read that book, I am always keen to learn something new 🙂

           A

         • Actually I am referring to broken code when I say “crap” and not working one. And you were also mentioning code that was broken and was constantly being fixed to be less broken.

           Also the don’t touch working code rule is not true. But that is only the case if you can be sure to not break anything. And that is where tests come into play – but you will learn that when you read that book.

         • The post neither refers to nor mentions any specific company other than MS and Adobe.

         • Nick, you know I like you – but that is simply not true 🙂
           We all know which elephant is in the room, even though you were clever and managed not to mention it once 🙂 But we all know that 🙂

         • Well I don’t know that you like me because I don’t know who you are. ;-). But the fact remains: the article isn’t about any particular company.

         • It’s Andrea Raimondi.
           The article was written on April, 23rd after an increaingly vocal outrage from developers 🙂
           The fuss was kicked up on Apr 17th so it’s pretty incriminating evidence 🙂
           If you’d written it on Apr 16th, I would agree with you 😉

           A

     • Yes, yes. 10 buggy features are a lot better than 1 that works solidly.
       Not.

   • I HATE you. I just wrote a 15-page reply to Nick that said what you said in four paragraphs. 🙂

     But I’ll reiterate that Nicks “all software has bugs” line is a strawman. No one expects literally zero bugs in all software. But they DO expect that all existing bugs be trivial and non-obvious. Severe bugs hurt and prevent you from using the product, and obvious bugs mean proper testing was never done. Nick’s also used “road maps change” before to justify massive failures to deliver as promised. These arguments just don’t work.

     >You must have been using really bad software in the past if you say such a thing.

     I had the courage to suggest what that software was. 🙂

7. OK, let’s transfer this “philosophy” to Embarcadero. Up until a couple of years ago, they came up with one Delphi Version per year and provided some bug fixes for that until they started serious development of the next release giving the user…oh, seven to eight months – in some cases even longer. Then more recently they started to spit out major releases every six months. These got fixed perhaps three to four months into their tiny lives. Then the next release had to be prepared hence no manpower to fix what customers had to put up with up until then. Moreover bugs tend not to be fixed in the new relases either plus the creativity department at Embarcedero throws in more bugs to make things less boring. And all this customers don’t get for free, they pay for the software – for every single release. That was a truckload of money coming in. There will be less money coming in with the subscription model.

   Who would really expect that softweare gets better with less money coming in? I certainly don’t. And that is just common sense.

8. I like the idea of software subscriptions in general. Software is always a process. It’s not a product that can be finished. Software always interacts with an evolving technology environment and it should evolve with it continously.
   As a software developer I know there can’t be a product without bugs. But I must disagree to your basic point. There are bugs which _must_ be fixed for free to everybody. Especially when you’re referencing to Embarcadero. I’d like to see a real subscription for Delphi. No XE8, no XE9. I want a simple update subscription that keeps me always on the newest version without setting up a new IDE. I’d like to pay for it. But honestly – I’d _never_ buy a Delphi subscription from Embarcadero. The quality of their products is way too bad compared to Visual Studio, Xamarin, IntelliJ etc. There are tons of serious compiler bugs, VCL bugs and IDE bugs which are being ignored for many years now. These kinds of bugs need to be fixed for free. They break the promises which are made on the product website and the feature matrix. As a Delphi customer I feel betrayed to get almost the same product (including new 70% finished features I’m not interested in) with the same bugs year by year. As long as Embarcadero’s update poitics and quality ensurance stay like this I can’t advise anybody to buy a new Delphi subscription.
   An update subscription is always based on a big trust into the company. When I buy a MSDN subscription for example I always know I’m going to receive bug fixes as well as great new features every year. What can I expect from Embarcadero? Embarcadero didn’t release any great product over the last 7 years. Every single version of Delphi IDE and compiler seemed like an unstable beta. I’m sorry to say it like this. New language features are only developed at its surface. Generics are still full of bugs. Anonymous functions often leak memory. There are no class helpers for interfaces etc. etc.
   Why should I trust this company and spend my money year by year for a product like this?

9. I respectfully disagree. What I have learned as a developer is that 90% of developing software is easy (or easier) but that the last few percent is HARD. Doing the last tasks that turn your software from a cool but flawed product or prototype to a professional product is slogging, slow, hard work. It requires fixing all serious bugs, filling in the edges so that your software is easier to use or can be used in unexpected ways without consequence, doing that annoying unglamorous testing, writing *complete* documentation, etc.

   It used to be that you could tell the difference between the free/open source and the professional software developer by who did this last 10%. Unfortunately, in the last couple decades companies learned that they didn’t need to do this last 10%. First, they learned they could shove their product out the door and do the last 10% later. Now, they have learned they can get you to pay to do that last 10%, or maybe not even do that last 10% and just push out 90% of the next upgrade instead. it is not all the companies fault; equally unfortunately in the last couple decades, consumers showed they didn’t want to PAY for this last 10%. They wanted the free software or the cheap software or just give me what you have now I want it I want it I want it! 🙂

   The subscription model is great for companies but bad for consumers. Once Adobe switched to subscriptions, I stopped buying Adobe products and started buying the alternatives. I tend to avoid Delphi component developers who do everything by subscription; not *once* has it worked out to getting better value for money. Perhaps my experiences have been different from yours Nick, but the subscription model has most definitely incentivized companies to do less, especially if the company feels like their consumers don’t have good alternatives. If you are lucky, you get the same value for the money, but you never get more value for the money.

   Now, I am not knocking Embarcadero specifically. This is the direction that the software world has gone. And unlike some, I think Embarcadero has been mostly good for Delphi. Unlike Borland/Inprise/Borland/CodeGear, they poured money into making Delphi better and not just milking it to fund other projects.

   But I won’t pretend the subscription model is for my benefit. And I don’t have an alternative. It was love at first sight with Delphi. She is a sometimes difficult lover but she is too beautiful to give up. 🙂

10. Don’t not have problem paying for bug fixes and future features thru an annual maintenance cost or such.
    I do have a problem if company allows you to buy the product without it – i.e. we license lot of software in our company and all except the one this article likely was inspired on force year 1 maintenance in the initial price.

    Nothing wrong with it and in fact represents the proper cost of ownership. If the reason for charging for this is the financial viability of the vendor of such software to provide support/fixes then one more reason it should be included as in my view it reduces risk to me by ensuring company has adequate resources.

    Discussion of the subscription has to depend on the perpetual license side of things. Any company that has to use a quality management and risk models (we happen to be one) assumes additional risk with non-perpetual license subscription so the decision for the dev tool choice (or staying on old version) now moves to management and risk officer role. Individual hobbyist/small shop might prefer subscription so vendor of product has to decide on the market they are after and which model (or ideally both) to provide.

    • You get a perpetual license with Delphi, C++Builder and RAD Studio.

11. All bug fixes to features that were initially advertised should be fixed FREE; otherwise, the company basically misled the purchaser in to paying for something that was misrepresented.

    NEW features should be charged for. But one you make the initial payment for these new features, any fixes to these should also be free.

    Therefore, there should be two updates – a bug fixing of existing, but buggy features, and a second update that provides New features to the release.

    • Did you read the article, or just the title?

      • I read the article, and the comments before mine.
        Did I miss something, Nick?

        • I guess you missed my point about the fact that all features will have bugs.

          • I agree that all code is prone to bugs.
            But, should customers pay for features that don’t work as expected out of the box?
            An example would be the Error Insight feature Mykhaylo comments on below.

    • i agree with you Wilfred.

      the Error Insight feature is first implemented in Delphi 2005 if i’m correct.
      since then there was 12 releases more
      (2006, 2007, 2009, 2010, XE, XE2, XE3, XE4, XE5, XE6, XE7, XE8).

      and it still works incorrectly (shows error while compiler compiles the code successfully)
      and slows down the IDE.

      how much money must pay one to get it working?

      same thing with Structure Pane. how many years it must take developers to stop
      updating it every time you switch units and update it only when unit is changed (while when it is not to remember current state)?

      there are many, many places in the IDE that just must be done correctly and that were paid for many times.

      • Mykhaylo, we as both asking for quality in the software tools we purchase.

    • I agree with you sir. They inject Bugs to make customer pay for fix this is not only a scum but it violates the Quality Assurance when you buy the software. I have seen Bugs that do not exists in previous versions to exists in future versions.

12. “Yet people still argue that the product should be bug-free and that they should be entitled to free bug fixes because they “paid for a product that should work out of the box”. ”

    Yes, why not? Many, many, companies sell their products with guarantees, which mean that if something is not working properly, it is fixed. Further, depending on jurisdictions, by law they have to. If you advertise your product as doing x, and it doesn’t do x, that is false advertising or the company has to fix it, replace it, or refund the customer’s money. They have absolutely no right to charge more money for fixing it.

    There may be some qualifications to that in some cases, but the principle is there.

13. I want !!!

14. Hi! I would have to disagree on this. At the company I work for now, we charge customers *a lot* for the clients the first time, then they pay support. The catch? The catch is that it’s a specialised kind of business we serve and there’s a lot of revenue and profits involved. Just like in programming. Once you create something, if you do it right, you can re-sell it over and over again as it is. Yes, people will want bug fixes. of course, but that’s what support is for. It’s different for stakcs and utility applications though. Why? Because stacks will not, generally, solve a specific BUSINESS problem but rather a TECHNICAL one, for which there are no customers until someone comes up with an idea to solve a business problem. This is why stacks are going open source. So you might ask, what is the BUSINESS problem that Rad Studio solves? Put it simply, it’s creating quality applications. By using Rad Studio, you know your customer will get what he/she wants a lot faster than the competition. This is the software houses’ business problem. The SalesForce API, for example, does the same: they solve the business problem of connecting to SalesForce reliably and predictably.

    Now, you might say that MS has made its Professional Edition of VS free and I would very much agree with that, but this is not related to solving the business problem of its customers: it is related to the fact they also have a PLATFORM they want developers to adopt. Since a platform is a stack, i.e. it solves a technical and not a business problem, they need to reduce friction to adoption.

    This becomes startlingly clear when you consider that the Enterprise editions of VS are still for a hefty fee (and with good reason, because they solve a business problem: that of creating integrated and reliable systems for customers).

    A

15. It was even earlier: Borland C++ 3.0. A picture is here: http://www.steeletechproductions.com/sell/

16. You should not call it paying for support since money cannot pay support. Money cannot even pay your work. Money can indirectly pay other people’s work. Since this problem is well known it’s addressed buy giving employees the opportunity to somehow grow a certain kind of ‘fortune’ (in comparison to real wealth created when looking at results from a trades). Otherwise you are never paid for work.

    Economy is never about money it’s about goods. Profit as a measure doesn’t work anymore since the concept of the fair price has been beaten to death by the neo-liberals (debt socialists). Prices influence cultivation especially the structures.

    You can pay/finance support with apples that grow in your garden. Interest is the very nature of a banks business so it’s no surprise that my approach making money in the finance business first and spending for tools in a second step leads to a more relaxed view. I simply write software on my own serving my purposes which cuts off division of labor. There is no competition. In that situation you get most out of Delphi.

    Investors will never and in the end cannot pay bug fixes or finance bug fixing. The problem the investor solves is – Where do the new things come from.

    The price for Delphi is a certain kind of contribution. That’s all. The very nature of software development has unfolded right before our eyes. Humans are still mentally bound to the concept of the trade. RAD Studio from my perspective is a certain kind of San Francisco IDE. That’s not bad. The question is – is joining the club worth the contribution.

17. The variation of the model that Nick is suggesting for Delphi can work quite well – Cakewalk (http://www.cakewalk.com) has instituted a subscription model this year with their flagship DAW software, Sonar, that is (after the initial announcement trepidations) being viewed positively by their end users. With their variation you can subscribe either monthly or annually. With annual subscriptions (or monthly after a year) you keep whatever materials (perpetual license) have been available during your subscription period.

    On the other hand the Adobe subscription model (which Nick said they are not going to model after) sucks.

    • Just to be 100% clear, I’m not advocating any type of subscription model for any particular software application. I’m speaking in general about the notion of subscriptions.

    • well, for Sonar there are new features coming every month as well as bug fixes.
      so if count subscription model as an ability for company to work on features one by one rather than to release a bundle every year, then it may be better both for company and for customers.

      but if you consider subscription model as an excuse for having buggy software, just like Nick does, then it is not something good.

18. I agree with Nick. The validity of his argument lies in the perspective taken. Let me elaborate… I have been on both sides of the coin. On one hand, I am a developer with really constrained resources and on the other hand I am businessman who wants to generate revenues to keep things going and well.. Make some profits.

    I had written a product for an industry which did quite well to be honest. I started with the old school… Buy it once and it’s yours model. And then of course, I had to support it whenever bugs came up. Like nick said, when economics catch up, I realised that the model doesn’t make sense financially. Developers became support staff and the product stalled. After about 2 years, I told my clients that I would no longer be developing this product but I would support them until they moved to new software. The fact that 80% of the clients are still on it after 4 years of me telling them that… Thats a different story. But I did stop… And that’s an important decision.

    Last month, I released the same product… Monthly subscription model. It’s too soon to say anything but this time it feels right. The entry fee is super low… And the clients don’t feel the pinch of a major investment and if they want to get out, they can… At a very low risk.

    Purchase feels like marriage while subscription is like friendship.

19. WARNING long post!

    @NickHodges0702:disqus How can you be so naive to believe that switching to subscription model will lead to more bugs being fixed?
    Switching to subscription model won’t lead to more bugs being fixed until the mentality of those software developers that are developing the software you are paying for won’t change and they start giving higher priority to fixing bugs.

    Do you want some examples where you get all the bug-fixes without any subscription? I can give you tons of them.
    Just check out the game development, more specifically Indie game development.
    There are tons of Indie games out there that you buy once and get all the updates and bug fixes for as long as game development isn’t abandoned. And you don’t need any kind of a subscription for this.
    In fact when I think closer I can’t remember any Indie game that would even be using subscription based model. And I do own many of them.
    One of them I bought approximately seven years ago and I’m still getting access to all its updates and bug fixes. And no in all this time I din’t have to pay the developers any additional money. Not even a cent. But if you look at the state of the game at the time I bought it and state of it now you could hardly believe that is the same game.

    The hard truth is that subscription model is not intended to offer any benefits to the user but to the developer only.
    And the main benefit that it offers is that you are getting constant money flow from all of your software users whether your newest version did provide them with new features that they wanted or needed or not.
    But they won’t keep paying you if you won’t provide them with at least some of the features that they desire.
    You see no-one is prepared to pay for newer version of the some program if it doesn’t add any value to it either by offering new features or fixing old bugs.

    But don’t get me wrong. I’m not totally against subscription model. If I’m honest I’m in Embarcaderos subscription model since Delphi XE2.
    With subscription model I expect to get something worth in return whether this are bugs or new features that come in handy for me.
    But the sad truth is that Embarcadero didn’t provide many bug fixes or new features that would be useful to me lately. Yet I’m still supporting them but the question is for how long.

    So I’m all up for subscription model if I’m paying for what I need or what I use but current subscription model is forcing me to pay for features that I don’t need or use.

    For instance now as an owner of Pro version of Delphi I’m forced to be paying for development of database components even thou I don’t use databases in my projects. Well if I’m honest I do have one project that uses database but it uses custom build database that I created myself (I won’t go into details of why I did this).
    At the moment I’m developing my applications for Windows only which means that I’m also being forced into paying for development of Mac OS X support and FMX development even thou I don’t use them.
    Now someone might ask why I’m using the Pro version and not the Starter version instead. That is because of the great limitation of the starter edition where most important limitation is no 64 bit support which I do need.

    Now in the future I might need to use full database support. And for that I will be forced into upgrading to Enterprise version of Delphi and by so also into paying for development of many more features that I don’t or probably won’t use.
    So I will be considering really hard whether I should upgrade or just spend some more time extending my custom build database to support all required features.

    Let me say this again. I’m perfectly fine with subscription model if the money that I pay during the subscription goes into the development of the features that I need the most.

    And now some words about bug fixing and bugs in general.

    First of all it is possible to create a bug-free application. But this does becomes exponentially harder and harder with the size of your application. Why? Because bigger your application is there are more possible scenarios you need to predict and test for.

    Second of all I hate when development companies follow the
    “Fix critical bugs, add new features and if there is time fix other bugs”
    pattern. Why? Because in the long run this pattern always lead to some bugs never getting fixed.

    Instead I think the
    “Fix critical bugs first and then if the code you are going to be extending with new features doesn’t contain any more bugs in it no mater how trivial they are continue with adding of those new features otherwise fix those bugs first”
    pattern. Why? Because this pattern will never lead to the scenarios where fixing a small bug could lead into breaking bunch of features that are depending on your bogus code.

    And this is the main problem of Embarcadero.
    They have been postponing of fixing of some bugs that might have even seem trivial at the time but now fixing of them could lead into breaking of many features that were added on top of that bogus code.
    And what is worse is that this is becoming worse and worse every time they implement new feature instead of fixing old bugs.
    So sooner or later this will lead to the state where fixing of that bug would no longer be viable so the whole chain of features that spread from that bogus code would simply be replaced entirely.
    And that means that all the code of Delphi developers that use those features will have to be redesigned as well.

    Now I would really like to link you to an article that I read some time ago named “How trivial bug can become real pain in the ass to fix” but I can no longer find it.
    Now that that article did show was real example of a software developer where fixing a small trivial bug lead to rewriting the large part of his application not to mention that instead of predicted one day time to fix the bug he actually spent two months redesigning all those features that got broken with fixing of that trivial bug.
    And the conclusion of the articles author was: “I wish I would have fixed that but the same dame I found it. It would have saved me lots of work and nerves that lost in these last two moths”.

20. How things are priced should reflect how customers perceive them to provide value. Meaning that if customers think they are buying intellectual capital, they should pay for anything that requires intellectual capital, like bug fixes. But if customers think they are buying a finished good piece of software then bug fixes should be free. The costs faced by the producer are not necessarily the relevant driver of pricing; if this were the case, then profit should by all rights be eliminated wherever it occurs. It is not, as we allow firms to be wildly popular when they produce something people want a lot.

    I have seen no move in customer sentiments toward a subscription model. What I have seen are companies seeking the steadier less risky revenue stream that subscription models offer, irrespective of what their customers actually want.

    But if every company does the same thing, customers have no choice. Then it is silly to suggest that the market has spoken. I think that is what is happening with SaaS. I think companies are finding it more economic, and since most companies now use or soon will use a subscription model, the customer soon has nowhere else to go. Competition will not then fix this issue.

    When you talk about SHOULD, that is different than what IS. What is, is that companies are moving to subscription models, period. What should they do? In the long run I think they should do what customers want them to do. If customers don’t want a subscription model, give them an alternative.

    Now, I bet I could tell you exactly what went on in the EMBT executive boardroom. I bet it went a little somethin’ like dis:

    “Hey look at this. Our operating margins and profits are far higher for those accounts that are subscription accounts!”
    “Well then, lets make all our accounts into subscription accounts!”
    “We so smart!”

    Which is actually really dumb. The fact is that pushing everyone into the most profitable type of account does NOT necessarily increase profits. If the customer base is divided into two different types of customers, as this one seems to be, then the most profitable thing is to provide two different pricing strategies, not just one. The customer segment that prefers buying software outright in the traditional fashion might be generating lower margins and lower profits, but many of them will leave and go to another product if they can no longer get their traditional pricing. Why? Well it is obvious why. When they were given a choice, they did not want the subscription model, they chose the other one. If enough of the traditional-pricing customers leave, that more than offsets the higher profit from the ones that migrate to the more profitable subscription model. Thus, paradoxically, it could be the case that forcing everyone into the more profitable type of account actually reduces profit.

    This is actually basic ECON 101, but you’d be surprised how often these geniuses, these “captains of industry”, these John Galts of the world this stuff wrong
    .

21. If bought professional XE5 and an year of updates, XE6 and XE7.
    Result?
    I have to use XE1 version due to bugs of XE5, bugs of XE6, bugs of XE7; bugs that are not something you can add exceptions, bugs that make unusable software (something like encoding and decoding etc.).
    I disagree about microsoft and adobe: their software isn’t so buggy critical neither not documented (from context help to simple examples, from years actually not present in delphi).
    If you think that a product should not work and someone pay to make it works, my answer is I will not buy a software that says it does many things and then it doesn’t.
    But I thank you for EMBT plans, I will not have XE8.
    Filippo Forlani

22. Soooo, this just in: http://stackoverflow.com/questions/29906723/delphi-xe8-bug-in-tlistt-need-workaround
    You mean to tell me, that the fix for that will not be free, and I should be happy about it? Well, sorry but no. And I am really pulling myself together to stay PG13 here. I am looking in my crystal ball, and see no bright future for Delphi… oh, sorry… Object Pascal.

    • I didn’t say anything about Delphi bugs.

      • In deed you have not, but you do see why I would not like that model being introduced into the Delphi world? Even more, you see why that model is flawed due to human nature? When I can get money for a reasonably bug free product, but more money for a product that is bug ridden, now what will I (the average greedy human) try to sell?

23. I pretty much agree with Nick: I have a subscription for MyDac and TMS Component Pack for example and I get all fixes AND new features all the time, as long as the subscription runs. And if it runs out I can decide: Is this product still ok for me? Do I need/want new versions and functions in the future? If yes I renew the subscription. I don’t have to decide on one or two big releases in the year if I’m willing to pay for this big step forward or not. Because in case of the subscription (at least in the mentioned examples) you get new features all the time and have plenty of time to decide if you are willing to proceed with the subscription. Many of the negative posts here do as if subscription was something bad per se. It’s not. With a subscription your paying partly for the current product, partly for bug fixing and – what would make it so good for companies like Embarcadero – partly for the future development. They don’t have to release THE 5 new super features the marketing guys need to make a big enough wave in the web. Instead they have to make satisfy the customers the whole package over a longer period: Features, fixes and support. I really think that this could be a benefit.

    But apart from all that: The current idea to pay normally for the software and ADDITIONALLY for the fixes is ridiculous of course…

    • I will ask you similar thing as I asked Nick

      Why do you think that switching to subscription model Will provide any more frequent feature releaes or bug fixes?

      Why do people still think that the way how you are paying for software developers affect their development cycle?
      Well it doesen’t unless the development company goes into red during such development cycle in which case you usually get rushed out products.

24. What bothers me about this business model is that it concentrates in cashing out the same bunch of guys that had been Delphi customers for years. Is there really no room for growth? Can not all these nice multiplataform capabilities attract a whole new set of fans?
    I have been using Delphi for ages, and have a significant investment in it so I probably stick with it no matter what, but I can’t convince new software developers to use this wonderful tool at this cost, and I still face a huge problem everytime I need to hire somebody to program in delphi.

25. >The day is coming when you are going to have to pay to get bug fixes.

    Heh. The day is coming much sooner when you’re not going to have to pay for most software at all. It’s already here for developers.

    >…but that is the way things are heading.

    It’s heading the exact opposite direction; I’ll supply numerous surveys showing major, continuing uptake of open source in the enterprise if you wish and we can also discuss how this is providing so much pressure that even Microsoft, which called the GPL “a cancer” has begun open sourcing its software and making other software free (including Windows 10 for existing users, even for pirate copies!).

    >I can remember the day when software came with free support.

    I call that “every day”. 🙂

    >You had a problem, you called up the company and spoke to a tech support representative who would help
    >you with your problem. For free. For hours if need be.

    Pfft. I was working from home 1995-2003 and I had a dedicated phone line for support installed at home, and dealt with things like getting calls from California at 8PM EST. 🙂

    >It was expected. Of course a company should support a product that they sold. If it wasn’t easy to use or
    >didn’t work right, they need to make good on it.

    Absolutely. That’s what we did for 8 years – support was free for the life of the product *so long as the problem was our fault*. Anything else was simply immoral – selling something that failed to do what you promised it would. And I’d have no problem doing the same thing today either.

    >Then, of course, economics caught up with the marketplace, and companies began to charge for support,
    >sometimes upwards of $100 an hour.

    It wasn’t economics. Free support provided a powerful disincentive to ship less than thoroughly-tested software. If your product was solid and your documentation was written better than Twilight, you didn’t need to charge $100 an hour.

    >I can remember the day when software came with a stack of manuals, sometimes two feet high. Anyone
    >remember the Borland C++ 4.0 box? It was so big it had a handle built into it.

    I never saw that, but when I ordered Borland Pascal 7.0 at the company I was working for in early 1995 the owner carried the box to my desk after it was delivered and announced “Your bowling ball is here.” 🙂

    >Then, of course, economics caught up with the marketplace, and companies couldn’t afford to ship all that
    >paper with the product, and the documentation became digital and shipped with the DVD.

    Again, I think it was more a matter of convenience than economics.

    >Then, of course, economics caught up with the marketplace, and now, you don’t even get that DVD.

    Again – convenience, or, for the cynical, a way to save an extra buck.

    >People didn’t like it at first.

    I sense a pattern, but I’m not sure a lot of people really didn’t like these things at first. Being able to download an ISO meant getting quick access to the software rather than waiting for your product in the mail.

    >But the economics of that are going to catch up with everyone, and soon companies are going to stop selling
    >licenses and start selling only subscriptions. And in order to get updates – including bug fix updates — you
    >will have to have a subscription. People
    > won’t like it at first.

    Is the depressing moral of your tale “A Delphi user can acclimate themselves to any level of abuse?” 🙁 Or “things seldom get better, but they can always get worse?”

    >The future is already here for many software tools. Adobe sells only subscriptions for their highly popular
    >graphics tools.

    Many? You can count the entire set of products that do this on your fingers, even if you’ve been convicted of theft in Saudi Arabia. 🙂

    >This is a trend.

    “Two” isn’t a trend. Two is coincidence; three is a pattern. 🙂

    >Microsoft and Adobe are not small software vendors

    Ding! Ding! Ding! Ding! THAT’S the point you’re missing. They’re more than just not small; they’re MONOPOLIES. The only two companies that can get away with this – the only two PRODUCTS, actually – are monopolies in their fields; Adobe’s imaging tools and Microsoft Office. No one else can do this because customers can walk away and choose their competition. Remember when Microsoft initially announced some type of system for the new X-Box that would lockea game to a specific console once you played it so you couldn’t sell it later? Sony had their PS4 unveiling and when the VP announced that there was no lock-in on the system the audience started cheering, gave him an ovation, and he broke out in a huge grin! The same with MS’ plan to require always-on Internet. Sony didn’t require that either. Guess what? MS had to retract both of those “features” before XBox One shipped. That’s what happens when in a non-monopoly or non lock-in software environment when you introduce user-unfriendly features. The competition exploits it and you have to roll back or lose market share.

    >You will see more and more software tools being sold this way.

    In a world where everything is becoming free (at the individual user level)? No way. Visual Studio Community Edition is the exact opposite of what you’re predicting. Instead of required subscriptions, you got free copies! MS can’t play that game in the development tools sphere; too much choice.

    >All software is buggy.

    Speak for yourself. 🙂

    >Yet people still argue that the product should be bug-free

    A product should do what it promised to do. Who thinks you should be able to sell a product that doesn’t work as advertised?

    People don’t argue that a product should be “bug-free”. They argue that shipped bugs should be trivial and non-obvious. When you click on a menu in XE8 and the IDE crashes, that’s neither and “all software has bugs” in no way rebuts this.

    > and that they should be entitled to free bug fixes because they “paid for a product that should work out of
    >the box”. Well, I hate to break it to you, but no software “works right out of the box”

    The second sad moral of this tale: “Delphi users have begun to believe that half-baked software is the norm.”

    Nick, you better not drive a car or fly on an airplane because they’re running software.

    You’re presenting a strawman.

    > and there is nothing that developers can do about it.

    Test. Complete Code coverage. Fix. No, this doesn’t eliminate all bugs (code provability is still something being worked on in computer science) but bugs can be reduced to trivial and corner cases.

    This is like when you argue that roadmaps slip. They do. But if your roadmap slips by 50% that’s not normal slippage; that’s poor planning. Software can have bugs. The more complex the software, the more chance of bugs. But if the software fails to install or crashes when it tries to start up, that’s not “all software has bugs”. That’s “we never tested the final copy before releasing it”.

    PC Gamer once published an anonymous developer diary from a company that made budget game titles. The dev revealed that they had so little time and resources that major corners were often cut. PC Gamer reviewed their paintball game and said they couldn’t test the multiplayer because the server was down. The dev revealed that they simply didn’t have time to put it in! They kept it listed on the box, but hard-coded a server error message when users selected it! PC Gamer felt the AI seemed almost random. Again, the dev revealed they had no time for it, so the AI LITERALLY was random! On and on. It was funny and horrifying at the same time. Do you see the difference? Your articles often try to defend inexcusable code quality with “all software has bugs”. Yes – but all software doesn’t have THAT MANY/THAT SEVERE bugs. Same with road map slippage.

    >I’ll say it again: all non-trivial software has bugs and there’s nothing to be done about that.

    So all the practices in software development literally can’t stop bugs from appearing?

    >Bug fixing requires intense human labor. Companies cannot afford to do things for free.

    Companies that contribute to open source can and do afford to do things for free. Your broad statement needs to be constrained to certain particular busines models, else it’s trivially shown to be incorrect.

    If your commercial software revenue can’t support the cost of developing the code and fixing it later, then it simply should not be introduced into the marketplace in the first place. It’s the same as buying a dog and then saying you can’t afford the shots or vet visits. If you can’t afford to do it right, you can’t afford to do it, period. Stay out of the market and let companies with higher quality development (and higher quality, better paid developers) do the job.

    >Good developers and QA people are not cheap.

    What about if you offshore them from Romania? 🙂

    >Thus, as we saw with free support, documentation, and DVD’s, something has to give.

    Sigh, another story for another time, but to prove a point I’d often made online, when I built my new PC in December I started with a flash drive with a (free) OS ISO on it. With just this flash drive and an Internet connection I proceeded to set up my system. Now 100% of the software on the system is free or open source! (Probably about 99% open source). I have more software than I have time to learn how to use! I’m using it 8+ hours a day for work and home use and haven’t needed to spend one penny on software in 5 months. This is the future I see and I think it’s already here – and I bet it won’t be too long before MS makes Windows free for home users either. I’ve got free support. I’ve got free documentation – heck, I’ve got free BOOKS. And while I have an optical drive, I’ve no need for any more DVDs. That said, I can use SUSE Studio to create my own live/installable OS image with all of my software on it that I can run from my flash drive or burn it to a DVD if I want. 🙂

    So no, nothing *has* to give. Users simply have to learn how to say “no”, and to do that they need to avoid vendor lock-in. Once they do, they have the power of choice, and it’s a fantastic power to have. As tech writer Trevor Pott gloriously put it when observing that mobile broke the Windows monopoly and how almost all of his work can be done today on Android and ChromeOS and in the browser:

    >Apple, Google, Microsoft? Who cares? I – like so many others, it seems – am going to use the
    >device/software/ecosystem that works best for me. I am going to look for return on my investment, and
    >actually care about the total cost of ownership. I am going to assign
    > some value to how I am treated by a company, and whether or not my needs are being met.
    >The days where I simply do what I am told, eat what’s put in front of me and like it are over. I don’t have to
    >learn to use whatever interface Microsoft chooses to foist on me. I don’t have to use their codecs or live with
    >their DRM or give up my privacy or useonly approved apps from only one walled garden store.
    >I’m the f*****g customer and you will make what I want, or I’ll take my custom somewhere else.
    >We can’t all do that, yet. Some of us are locked in to one platform or another. But when you get there, when
    >you finally get there and realise that this is the power you have; the choice that you can actually make…it is
    >intoxicating.
    >Choice. What a novel concept. About f*****g time.

    I hope you get there someday Nick. 🙂

    >and they are being driven to a subscription model

    They’re not being “driven” anywhere. They see a chance to make an extra buck and they take it. No one’s forcing these changes on them.

    >And yes, companies will be more motivated to fix bugs – perhaps even bugs in previous versions.

    It’s the opposite. Going back to games – you had to test a lot in the old days because there was little to no way to patch software. Once the Internet came along, “ship now, patch later, make the release date” took over. Again with PC Gamer, it got so bad one company shipped a FPS game where mouse support didn’t work out of the box and it needed a patch. You literally could not play the game out of the box (again, “All software has bugs” rebuts nothing here). PC Gamer, instead of saying, “People didn’t like it at first”, decided not to suck up to the software studios. They instituted a new policy: no game would get a second review after being patched (which was becoming the industry norm at the time). If it didn’t play out of the box, it would get a zero and never be covered again. Studios howled about this (and used your “all software has bugs” line) but PC Gamer stuck to its guns and users became quite devoted to them for their courage to take a stand for the readers. Subscriptions will be like internet access – “Hey, they didn’t pay for the software, they paid for a time period, so it doesn’t matter if we ship junk now and patch it all later”.

    > Because they will have a steady stream of revenue

    Precisely. And while in NEITHER SCENARIO does bug-fixing produce revenue, in the traditional model there’s still an incentive to fix (avoiding negative consequences due to needing users to pay the next upgrade fee). Here, users are more locked in.

    >Because they can bring features to market sooner than they might have before, they can spread the
    >pressure of releasing new features over longer, less focused periods of time. Removing shipping pressure
    >increases quality.

    Pressure will continue to be exerted by competitors’ rate of feature introduction and release schedule, unless again we’re talking about a monopoly and/or a locked-in user base. Look at mobile – could Apple or Google arbitrarily change their release schedule? Could Samsung skip a release and update their Galaxy two years from now instead? Their competition would leapfrog them if they did that.

    >This is nonsense. It will incentivize them to care more about quality, because there will be no more excuse >not to increase quality.

    There’s never a good excuse for poor quality.

    > If quality doesn’t increase, people won’t renew their subscriptions.

    They’ll be told it’s coming at some nebulous point in the future, and meanwhile the vendor will be trying to lock the customer in with proprietary formats, embrace-extend-extinguish or other tools.

    >Low quality will not be a good business model while providing subscriptions.

    Again, it’s never a good model.
    >But I think we all see the benefit of free internet support like StackOverflow, online documentation like wikis,
    >and software downloads that get you your software immediately. Those were changes that we didn’t like at
    >the time, but that we see the value in now.

    We all liked these things – and Stack overflow does not *replace* support for commercial products, so it’s an irrelevant example. Same with the idea of a user-edited Wiki *replacing* formal documentation. No one likes those things, but I’m not sure any commercial software vendor does either.

    >And so it will be with software subscriptions. So, yes, you are in essence “paying for bug fixes”. But bug
    >fixing is both inevitable and costly.

    It’s no less costly, and possibly more, that proper development and testing in the first place. Consider nuclear reactors – they have a limited lifespan for many reasons (including simple design obsolescence). When companies budget for building a nuclear reactor, they also include the inevitable cost of shutting it down, decommissioning it and cleaning up the site afterwards. A reactor is only economically feasible if income surpasses not only the construction and operating costs, but the cleanup costs as well. It’s the same with software – the cost of ongoing support needs to be included. If it’s not feasible, you don’t release the product, at least at that price point.

    Developer Bryan Lunduke produces cross-platform software. He was going through support data one day and made an interesting observation: Linux users didn’t need support. AT ALL. Not one single Linux user had ever availed themselves of his company’s free support. Taking support costs into account, he then did something very interesting: if during the ordering process the user’s browser reported it was running on Linux, the user was given a discount in the shopping cart under the expectation Bryan would not need to provide support! Of course this means that Bryan factored the average cost of support (and bug fixing) into his product.

    If you suddenly find you can’t afford to fix bugs, there’s something wrong with your pricing, your development process, or both.

    > However, you’ll also be getting

    You conjecture; there’s no guarantee of any of this.

    > more frequent updates, more frequent new features, higher quality, and more openness about the future. >You’ll always have the latest and greatest version of your software package.

    Not paying a subscription fee – or any fee at all! – also gets you these things today via open source. How is the subscription model superior and how will it compete?

    • @jgmitzen:disqus I do like reading your posts but doesn’t you free your open source experiment leave you making choices that have compromises. For example, I know you develop in Python as well, but IMO there isn’t a Python IDE that matches the all round excellence of the commercial version of PyCharm (at least I haven’t one). If you want to use the best tools you have to mix in closed source commercial offerings. I’d rather have best in class than good enough.

26. I do not agree with you sir … i think DELPHI OPEN SOURCE will have a better chance to this. Bugs are not even part of the quality assurance when you buy a product. I do not agree with the policies of Embarcadero and i state it clear. There are many dangers for this approach. Thus i would advice people if this is the case to move on to Free Pascal and Lazarus IDE that the bugs are fixed for free.

Comments are closed.