Home > Uncategorized > Only compiler vendor customers, not its users, count

Only compiler vendor customers, not its users, count

The hardest thing about working on compilers is getting somebody to pay you to do it (its a close run race against having the cpu instructions chop and change under you during initial development, but that’s another story). The major shift of compiler vendor business model from proprietary to open source has significant implications for users of compilers. Note I said user not customer, only one of them pays money. Under the commercial model there was usually a very direct connection between compiler user and customer (even in large organizations users rather than the manager who makes the purchase decision are often regarded by vendors as the customer), while under the Open source model most users are not customers (paying money for a distribution does not make you a customer of the people maintaining the compiler who probably don’t receive any of the money you spent).

Like all good businesses compiler vendors don’t want to make their customers unhappy. There is one way guaranteed to make all customers so unhappy that they will remember the experience for years; ship a new compiler release that breaks their existing code (this usually happens because their is a previously undetected bug in the code or because use is being made of an implemented defined/undefined part of the language {the compiler gets to decide what to do when it encounters such code}). Not breaking existing customer code is priority ONE in any commercial compiler development group.

Proprietary vendors have so many customers its almost impossible for them to know in advance what changes will break existing code and the only option is to be ultra conservative about adding new code optimizations (new optimizations can so easily change how source containing undefined behavior is processed). Ultra conservative is the polite term, management paranoia would be more accurate. There is another advantage to vendors for not breaking their customers’ code, they are protected against competition by new market entrants; a new vendor with a shiny go faster compiler doing all the optimizations the existing vendor was not willing to do in case it broke existing code will quickly find out that the performance improvements they offer are rarely big enough to tempt potential customers to switch compilers. Really, the only time companies switch compiler is when they have to port to a new platform to make a sale or their existing vendor goes bust.

Open source vendors (e.g., those commercially involved in support/maintenance of gcc or llvm) have relatively few customers (e.g., big companies paying them lots of money for specific reasons) and as always these customers want existing code to continue to work. If the customer is paying for a code generator for a previously unsupported processor then there probably isn’t any existing code for that processor; it is a fact of life that porting source to a new processor always involves work. Some Linux distributors (e.g., Suse and Redhat) are customers in the sense that they pay the salary of developers who spend a lot of their time in compiler maintenance/upgrades and presumably work to try and ensure that the code in their respective Linux distributions does not get broken.

Compiler users who are not customers don’t count on the code breakage front (well, count for very very little, if an update broke lots of different developers’ code and enough fuss was made there might well be an update than unbroke the previous one).

What can a user do if code that used to work ok is broken when compiled with a later version of the compiler? The obvious answer is to continue using the older version that produces the desired behavior, fixing the code causing the problem is a better answer (but might involve a lot of work). There is no point in flaming the compiler developers, you are not contributing towards their upkeep; Open source does not give users the consideration that a customer enjoys.

  1. Mehdi Amini
    January 26th, 2013 at 19:29 | #1

    Isn’t there a confusion between “open source” and “free” (as beer)? The problem is unrelated to open source but to the fact of paying. It seems to me that this issue is not tight to compilers but touches also a wide range of software. If I am a user of a free (as beer) version of a proprietary software (a compiler or other), the “regressions” I may have when upgrading to a newer version won’t get the same level of attention from the vendor when compared to a regression to a paying customer.

  2. January 26th, 2013 at 19:57 | #2

    @Mehdi Amini
    Yes, I have been sloppy with my use of the term “open source”. The user/customer issue can certainly apply to more than just compilers; the format of OpenOffice documents could be changed to satisfy customer demand and cause some users to lose the ability to read their older documents. I have a source code orientation and so tend to talk about what compiler vendors get up to.

    Also, breaking changes need not be customer driven as such; the Gnome 3/Gnome 2 radically user interface change has generated a lot of plenty of controversy.

  3. tomByrer
    April 7th, 2013 at 20:31 | #3

    Great insights!

    One also has to consider if the compiler may be free, but the hardware or OS to run the resultant software is not. EG Apple comes out with new models of i* devices at least 2 times/year. If app programmers recompile under the newest builder (Xcode IDE), often the newest version will not work on older devices. Thus, if you want to use the newest version of the app, you tend to have to upgrade your hardware every few years.

    I assume other vendors do this also; eg SQL…

  1. No trackbacks yet.

A question to answer *