Why Do Companies Stay on Old Technology?

Looking at my responses to my previous post, it seems pretty clear that a lot of people simply don't understand why companies stay on old technology. I have some other thoughts I'd like to give on Mozilla and enterprise, but before I do that, let's talk about the why.

Imagine that you needed a custom web application developed for your company (not a technology company). You would design the solution and build it based on the current technology. You would attempt to anticipate what the future looks like, but things change and you built this based on what you thought was the correct technology. (Remember, this was a couple years ago.) You would build the app and deploy it, and then you would probably move the team on to other things. You might keep one person was kept around, but they only work part time maintaining the app. Over time the app becomes an integral part of your business.

One day a new browser is released and you realize that your app doesn't work with the new browser. Now you have a choice. You can either rewrite the application or use an older browser. Rewriting the app might cost a million dollars. Sticking with an old browser might cost one hundred thousand dollars in support costs per year. Which do you pick?

Update based on a great comment from Wladimir Palant: Or maybe it's that it would be expensive to guarantee the app runs correctly on the latest web browser. Or maybe your app depends on a Firefox add-on that isn't working.

Remember, you're not a technology company. You use technology to run your business. And the job of your technology is to improve your bottom line year to year. So when you make technology decisions, they need to either make money or cause other parts of the business to make money.

Our goal here is to make a profitable business. So you choose to stay with the old technology as long as you possibly can, probably putting off the inevitable, but at least it's saving you money in the short term.

What you need to take from this:

Businesses do not make technology decisions independent of their financial impact!

This is why products like Browsium exist. You may look at a it and say "It seems expensive?" It's actually not expensive at all when you compare it to the larger costs of rewriting your application.

And this doesn't just happen with custom applications. Maybe you bought a particular app from a company that went out of business. Or you bought it at a particular version that only supports a particular browser.

These are the realities of running a business. Technology decisions are never independent of financial decisions.

Discuss.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

35 thoughts on “Why Do Companies Stay on Old Technology?

  1. Microsoft overcame that problem with IE's document modes. E.g. you can install IE9 and have your tools/intranet websites use the engine of IE7 or IE8.
    These modes are not perfect copies, nur are they guaranteed to never change (APIs did in IE9 for example). However, for a lot of tools they seems to work without any problems.
    There are some very good reasons why Mozilla won't support such modes, though.

    I wonder if corporations that built their applications with Firefox in mind were not wrong in the first case?

    Looking at my own company there doesn't seem to be any problems with quick Firefox updates (minor and major versiony are deployed after only few days). Wasn't XUL Runner the tool meant for intranet applications and tools? It wouldn't be necessary to release as often as Firefox/Gecko does. Security updtes would suffice. It could be a stable base for corporations. Not a good idea?

    • Microsoft's document modes are only a partial solution. IE8 (or IE9) pretending to be IE7 is close enough to work with few problems, so applications probably won't need to be changed to support it. But because it's *not* IE7, it still needs certifying separately.

      It's a big word in the corporate environment, 'certification' is. Not important at all to end users, but to corporate IT administrators, it's very, very critical.

    • And the changes from IE6 to IE7 from a web development view are really pretty minor. Most IE-specific features are still supported mostly like in IE6 for example.

    • Netscape 4.x on the other hand had plenty of major features that work in that and no other browser. Luckily, it is easy to keep a copy of that browser around if you still need it. Compared to that, hacking an IE6 web app to work in IE7 is pretty trivial.

  2. While I agree with most of what you say, I don't think you make the problem quite clear. "This app won't run in the newer browser version" is mostly a problem with MSIE updates and causes many businesses to stick with IE6. It is far less of a problem with Firefox, the behavior of Firefox releases is pretty consistent as far as web applications go. Chances are that all web apps will continue working correctly - but it is very hard to verify that they will. And breaking a business-critical web app isn't a risk anybody wants to take because it could cost millions until the old browser version is reinstalled or the web app is fixed. So it is really: "this app *might* not run in the newer browser version" and "how expensive is it to ensure that everything continues to work correctly".

    Things get even more messy if extensions are involved. Internally developed Firefox extensions typically don't follow best practices and are likely to break with a browser update. Which is even worse if third-party products are involved - like the infamous VMWare Server Console extension that isn't working with Firefox 3.6. And the product has been discontinued so there is no solution.

    • Firefox is certainly less likely to break things with upgrades than IE, but that doesn't actually matter when it comes to corporate confidence. It's still a version upgrade, so it's a risk.

      But yeah, the problem basically amounts to the fact that corporates don't want to roll out a new browser version, only to find that a thousand people working in their call center can't do any work, and that tens of thousands of customers can't get any service because the system isn't working. And so they're ultra-cautious - it's cheaper (and better for customer relations) to ensure the new version has been thoroughly tested (including by the vendor) first.

      • I can give an example of the Firefox upgrade breaking things: my company has been holding back from Firefox 4, because our voice mail web pages break under FF4. We buy the voice mail system from a vendor, and cannot fix it ourselves. We need to wait for the vendor to fix it.

        Advanced web gurus can sneer that the voice mail vendor doesn't know how to write portable HTML or future-proof HTML or whatever, but sneering at problems doesn't fix them. We have hundreds of websites and one or two things break each time there is a new browser. Companies delay updates to have time to test the update, discover any problems, and fix the problems before accepting the update.

        Firefox used to understand this.

  3. Honestly, I don't understand why all the development should focus around those big companies. If some old-minded business bigwigs want to use the same browser forever, the hell with them! The web is not about them, it's about us, the home users. We want progressive, modern and personal browser. With Firefox we get it. There is no reason and no sense to turn into the next IE6.

    • No one is saying it should focus on one or the other.

      The goals of both companies and users can be accomplished.

      The question is how to do that.

        • Colby, to whom shall we shell out? And why should I tell my employers to shell out to them -- I'd rather have them shell out to a browser maker whose fixes would go to work for me as a user, rather than only be used for the enterprise.
          Firefox looked like the door to the ideal solution for a long time. Now the door's slammed shut.
          It sucks, because FF's dev team is actually organized very well; they wouldn't have to change at all except to cooperate with an external team that's doing things they don't want to do. The ideal would be to have someone like Debian and Red Hat form a strategy team and build a roadmap to build a browser with major-minor release numbers that reflect that roadmap, and at least one locus of promised security updates. Ideally, the team from RH/Deb and the real Firefox team could cooperate, with the "boring" long-term work happening in the RH/Deb version and the quick-payoff fun stuff going into the Firefox version -- and the roadmap leading to both merging as many features as reasonable and mutually desired.
          -Wm

    • I'm enduser and I'm sick of all the updates. Give me just once a year something new and I'm more then happy
      Most endusers don't give a *#&&& about updates They just want surf, facebook, youtube and facebook. And all these works perfect on 3.6

  4. So how about those businesses just stick with IE6 and leave Mozilla alone to develop a browser for the consumers?

    Why waste resources on these companies?

    i.e. I as a desktop user don't want Firefox retarded by slow moving mega-corps. Thankfully Mozilla so far seems to be taking that approach and I hope they continue to do so.

    Maybe let each business desktop have IE6 for the internal brain-damaged apps and the latest Firefox for browsing the internet.

    • @Anon, so you are a desktop user. Do you use add-ons? Are all of your add-ons that don't come from Mozilla immediately available for use when Mozilla releases a new version? If you use 5 add-ons and just one takes 2 weeks to get a new version out (and not necessarily the same one for each release), with 5 add-ons and 4 Firefox releases per year, you are going to spend 10 weeks per year (almost a whole FF release cycle) without all of your tools.

      I just upgraded 2 machines to Firefox 5. I had to restart the browser on one of them twice, and I have one add-on that's not currently available for FireFox 5. I still have my wife's machine to do, and 4 VMWare VMs, and I need to make sure that both of my kids update their machines because if they end up with a security problem, I'll be the one that has to deal with the cleanup.

      I don't work for a LARGE corporation, just a small one. But I support a bunch of other machines and have 2 volunteer things I do that involve using FF. This decision doesn't make my life easier and means that FF needs more maintenance time from me for just to stay even.

      This isn't just about "slow moving mega-corps". Do you think your mother and father want to deal with a new interface or incompatible "features" every 3 months? How about their parents?

  5. I'm not sure the way (which you perfectly well described) companies handle this necessarily makes makes perfect economic sense.
    It's mostly that the pain of a breaking change is sudden and obvious, whilst the one of outdated software versions is diffused. Nobody gets fired because the accumulated cost of maintaining ie6 over the years has huge (some even justify their workload with it), but if a contract is missed because of the disorganisation caused by a breaking change of ie9 (or if your ceo much above you can't access his mail during half a day because of it) that may very well happen.

    I already suggested on .planning that what companies actually need is something very similar to Browsium, to be able to run seperate versions of firefox depending on the site. This would actually be very significantly easier to do with firefox rather than with ie.

  6. In the end what I see here is a struggle for control.

    For Mozilla, it's about having control over when they get to stop maintaining an older version, which Google Chrome has demonstrated to them that most people who download browsers are willing to accept quick retiring of an old version when a new version is released.

    For IT administrators (and some users who have are averse to new releases due to bad experiences with upgrades), it is about having control over how often they want to go through the trouble with testing, fixing and making sure things work as they expect.

    Some compromise is needed. I'm not suggesting that Mozilla should slow down their development cycles, but they need to provide administrators with a viable way to deploy Mozilla software. And note that it is not just administrators who will find the current setup unacceptable, many (though not necessarily all) Linux distributors and other non-Mozilla supported platform application packagers will find that this does not work for them. Even though they are dwarfed by the number of users that accept the way Mozilla is doing releases, they are still a significant number of users.

    Perhaps the question is if there is enough interest from administrators and others who may find the releases too frequent for their liking, who also would be willing contribute to an effort to make an upgrade process easier and better for them. While Mozilla might want to see if this might be an opportunity for them to grow their development/user community and maybe even resources.

  7. @Wladimir: nope. I know at least two companies here who based their intranets on remote XUL and the decision to disable it (even with the whitelist) was a earthquake for them.

    • I work for a small company that writes apps for larger companies. When we decided to write a new version of our flagship app (actually a suite of 30+ applications) we went for Remote XUL because, at the time, HTML5 wasn't even close. Remote XUL gave us a distinctly more powerful solution than HTML would have at the time.

      Our plan was always to migrate to HTML once it was powerful enough (it still isn't, but it's getting close), and yes, the disabling of Remote XUL was also quite the earthquake for us.

      Now our small team, as well as trying to write new code (to make money), is also busy on a forced and premature migration to HTML (which earns us nothing), and has to certify our software (all 30+ apps) against each new major release of Firefox that comes out (also earning nothing).

      Maybe we shouldn't have based our code on Remote XUL - but that's an easy observation in hindsight. I still think it was a great technology, and once HTML catches up, developing web apps will be much, much easier.

      • @jmdesp - Yes I've heard about that extension - it was written partly as a result of people like me crying out for a whitelisting option when it became clear that Remote XUL would be disabled. It's a viable workaround and has given us a lease of life - but it's just a temporary respite; I've little doubt that Remote XUL will vanish completely in some future release.

        @Errol Mars - It's Mozilla's problem because they decided to remove functionality that had been around for 10+ years with no real warning, no deprecation period, and no help to transition existing code away from Remote XUL. I have no problem with Remote XUL being removed, it's the manner and timescale in which it was done which has caused us significant problems.

    • I would consider disabling remote XUL a good thing in the long term - vendor lock-in isn't what Mozilla should be about and remote XUL never was really encouraged (not actively discouraged either unfortunately). Still, dropping something that was previously supported (remote XUL, XULRunner, Prism) is painful.

      PS: If you wonder why XULRunner is on my list above - I consider it dead and unsupported, despite some projects attempting to continue using it.

      • I agree that Remote XUL should have been disabled in the long term, but it was the nature of the transition that was a problem. Just dropping support at short notice, with no period of deprecation, and before HTML is rich enough to replace it (even for something as minor as a date picker, let alone XUL trees!), has left people who did use it stranded.

  8. The reasons why enterprises want to stay on old software are understood. But why should a browser vendors and the wider Web bear the cost of having old versions around that the enterprises make into an externality?

  9. Mozilla should at least have told in advance that they plan to stop offering security updates for previous versions. Then there would have been time to find a solution. Now the only quick solution is to update from Firefox 4.0.1 to Firefox 3.6.18, what I have done today, and then prepare the move to Internet Explorer.

      • Why is it so hard to understand that mozilla should have informed their users BEFORE they completely dropped support for the most recent version.
        As of yet mozilla has still not told users of Firefox 4, that the reason for the missing patch is not that this version was not affected by the bugs. Instead it's because mozilla arbitrarily decided to force the user to jump to the next major version immediately. So far users had the choice to wait until everything worked.
        Maybe I'm an untypical user. Maybe others see their computer as adventure game. I see it as a tool that has to work, otherwise it's useless. I like new features, but I don't like software with version ending in dot zero. I like fast progress, but I also like choice and reliability.

        Yes, corporate users should move faster, but by reducing the time window from 6 months to zero days, they don't have a chance.

  10. Pingback: How You Stay
  11. Mike, I agree that enterprise shouldn't be your focus, but consider a few things:

    1) If you drop support for an old version of FF so quickly, you will have large numbers of businesses dropping the adoption of FF in favor of crappy browsers like IE. This in turn will make life for developers who still need to support IE miserable for longer periods of time. Are you sure you want to be the guy who is responsible for making developer's lives miserable? :-)

    2) As more corporate users drop FF, the "individual" users (the same guys who championed FF into the corporate world), might end up adopting their work browsers at home too. Especially as the work browsers continue to improve at a rapid pace. Remember, you're also in competition with Chrome.

    3) There might be a happy medium here...you don't need to support older versions for a decade like Microsoft does (are they serious about that? I will personally send hate mail to every user who uses IE 9 in 2020), but maybe you could support older versions of FF for 1 year?

    Here is to you changing positions for the sake of a better future world for software developers everywhere!

  12. So the issue then is that the same program is being used for both internal and external data communications. It's no surprise that shoehorning a program to do many different things can lead to eventual failure. Seems like not a backend software failure (the browser in this case), but of how the tools are being deployed by IT.

  13. This may sound archaic in a certain sense, but this browser ridiculousness has caused my customers to request two things: Linux, OS X and Windows front ends for apps in Qt or GTK, and anything that is a web-based app to generate HTML form-driven pages.

    Sexy? Not at all.

    Guaranteed to run perfectly for the 6-7 years of deployment expectancy for RHEL, the next versions of Windows and OS X? Certainly.

    Two of my hobby projects (Tryton and LibreCAD) are written this way and we have no cross-platform issues... and one is an ERP system and the other is a CAD application. Consider that LibreOffice does this without issue as well.

    The whole concept of writing an app for a browser initially came around as a way to ensure cross platform portability by adhering to HTML standards. We've now gone way beyond that and the ridiculous bloat of web-based extensions, VMs and other environmental cobble have made modern web development environments actually more complex than simply writing a portable application in a cross-compilable language+API. Python+Qt4 or (shocker) GNU GCC compliant C++ on Qt or GTK is more durable, portable and predictable than web apps.

    This is amazing -- and signifies two things:
    1- The browser could actually lose its importance. Today some companies treat the broswer as if it were the platform. For corporate clients this is no longer true (my actual business case that is going on right now is a perfect example) due solely to the current support storm that is brewing.
    2- The browser is very likely to be put back in its place: become an information browser, and step back from being a one-pot-supper-plus-fries-and-a-drink.

    The only way to keep the browser doing all these things would be to move back to having server-side processing dominate once again -- which is not at all impossible considering how environments can be distributed (wasn't the "cloud" fad all about that idea in the first place? So why the rush to complicate and over-burden the browser environment?)

    Browsers are applications -- not environments -- and blurring that concept is what has led us here.

    (Don't tell the Google Chrome team -- they think their application is so special they need to build-in hacked versions of otherwise standard libraries and will flip you the bird if you suggest otherwise... but this has more to do with their lack of age than anything. They've never seen what a huge long-term support monster mutant libraries becomes...)