Linux Compiler will remain an Enterprise Only Feature

In case you have not been watching RSP-17195 Marco just closed the ticket yesterday. Apparently EMBT has decided that the Linux compiler will remain an Enterprise edition feature and will not appear in the Pro edition as requested.

I have written before as to why I think this a major marketing mistake, so just briefly, Linux is used by more hobbyist programmers and IoT/SBC developers than most other OSes, and there are many FOSS solutions available. Few people interested in targeting Linux will pay for the Enterprise Edition as they can target a Windows machine and pay the M$ license cheaper than buying an Enterprise edition. It also makes no sense to allow the targeting of Windows and MacOS in the Pro edition, but not the other desktop target. I think this is the same mistake that was made when originally selling the Mobile AddOn, which EMBT later decided to include in Pro in order to limit development costs and increase the user base. Licensing FMXLinux will likely not amount to much of an incentive as my understanding is most developers who have currently licensed the Enterprise edition are writing server apps. Increasing the cost of writing a desktop app will not encourage the uptake of hobbyist or professional developers looking to monetize apps on a platform that users typically prefer FOSS solutions.

Other vendors like REMObjects do not charge additional money for a product edition to target a supported platform. You get all platforms for the same subscription price, and they have now written an RTL and WASM support which makes their platform that much more attractive to Delphi developers. REMObjects also has 64 bit ARM target support today.

.NET cannot be ignored now that .NET Native and Core have been released and are rapidly maturing. Delphi’s “native” compilation is no longer an advantage and the C# code generated tends to be more efficient than Delphi’s various compilers by all accounts.

You can have the greatest product in the world, but if you cannot sell it to a sufficiently large user base, it will not be self sustaining. Marketing decisions like this IMHO will negatively impact the Delphi user base.

7 Responses to “Linux Compiler will remain an Enterprise Only Feature”

  1. Hoppy Package Says:

    Delphi has always been what is called a very special Enterprise technology. Since you don’t need to touch the OS it simply is. The question today is ‘What can be considered as an OS’.

    Another question is if Windows on a PC has been considered an Enterprise technology and if yes since when. You still need to be in full control of the hosting environment.

    Since the tradition of full stack competence turned into a dying art control has been taken away from the developer, two processes accelerating each other.

    So Professional today is what is left from full stack competence. This partially matches the demands of what was Enterprise in the late 80s/90s.

    There has always been a difference between tools for Professionals and Enterprise class tools. An Enterprise tool allows you to do less. If you consider Delphi it’s just the edition label that has to be exchanged and then you are almost there.

    The difference between Enterprise and Professional is shifting competences concerning technological decisions especially about the place where technologies are hosted (in a broader sense, not about infrastructure decisions solely).

    Usually the shift happens when technological areas don’t intersect. The role of the professional is to bridge the gap. The bigger the gap the more flexible Delphi and it’s ECO system is perceived. The bigger the intersection the less attractive Delphi is considered as a whole.

    Delphi is one of the best technologies to build bridges to the past. These bridges are added and finally make up the Enterprise version and a bridge to the future or two have been added too, three included the connectors.

    I agree that Delphi Professional plus connectors is what is required for an Enterprise. Delphi came alive when the race for Y2k came a full speed ahead which was just another step towards getting rid of the IBM host and other legacy technologies like the good old UNIX vendor solutions.

    There was a need to have an intermediate something similar at hand.

    The Delphi promise just means to stay in the position to retain as much as possible from the existing codebase even if the underlying OS changes, which goes far beyond what portability demanded.

    Today you face different OSes no one every would have expected especially web-browsers and various kinds of virtual machines. So the original definition of the Delphi promise changed dramatically or what the way people expect this promise to become redefined.

    Most people used Delphi in an Enterprise style anyway, think of DCOM, COM+, MIDAS (Add On), MIDAS replacements and ORBs. When web development moved into the focus middle-ware became less attractive and people partially moved back to C/S and app server technologies started to move into the focus.

    Delphi was and still is one of the most flexible and extensible development environments. It’s all about vacuums.

    a) the well know add-ins that make up the professional’s development tool (see above)
    b) the vaccum between Windows 2 up to Windows XP SVP2 when Windows became finally accepted as an Enterprise technology that made Delphi legendary and very prominent.
    c) the vaccum between yesterday and today, as well as today and tomorrow or yesterday and tomorrow. The big advantage of native technologies is to be in the position to bridge the gap to yesterday. What happens now cannot be a result of things that happen tomorrow.

    The real bridge for today to yesterday is C/C++ but plain ‘C’ is about I can do it. Other bridges are about I can do what the briding technology allows me to do - yeah so I’m great if it allows me to do or even more greater if allows me to do more. Delphi is sometimes about I could if I could or the briding technology provided by me, the community, EMB or third-parties allow me to do.

    For 15 years now Delphi is a big melting ice cube and the vendor has to cool the environment so that the ice cubes does melt slowly. EMB is definitly pretty successful at cooling the water the ice cube orinigally way put into in order to cool the water, but it’s getting warmer and warmer. Makes the one or the other feel like the frog.

    Of course Lazarus is a lot closer to the OS compared to Delphi Firemonkey which makes it more attractive to people who just want to keep in touch with the OS and the evolutions there apart from the fact that a shell allows you to achieve alomst the same and so Instant FPC finally is what is required to address this issue (parts of FPC/Lazarus).

    At the moment most of the prominent IDEs are children of the Y2K and beyond evolution.

    Remobjects stuff in this area is a child of the Y2K aftermath. Mono & friends and Jetbrains (Topspeed approach).

  2. John Says:

    1. I was very disappointed to see that all the connectors are VCL only. This really put me off

    2. There’s another option for hobbists who want Linux on Delphi. They can download a cracked version which is very easy to find (sadly)

  3. Thaddy Says:

    I do not understand it either. Anyway, the FreePascal compiler is superior on Linux. (And can now also use a LLVM back-end)

    Frankly the Linux compiler disappoints.

  4. Ken Randall Says:

    I totally agree that the linux compiler should be in the pro version. EMBT decided to make Android, iOS, etc. available in the pro version and this seems to go against that logic.

    Ken

  5. Larry Hengen Says:

    @Thaddy,

    I was not aware that FPC can now use an LLVM backend. Thanks for the info. Unfortunately many Delphi projects cannot be actively ported to use FPC due to the language differences. I am also unsure that LLVM will really provide much overall benefit compared to the FPC code generation, which apparently is quite good. The website (https://wiki.freepascal.org/LLVM#Build_FPC_with_LLVM_support) indicates at best 18% on the limited platforms currently supported (which do not include Windows). Definitely something to watch as it matures, especially if WASM can be supported via this avenue.

  6. stamf Says:

    I understood the Linux compiler is primarily intended for use with the RAD Server, which is delivered only in Enterprise. Did I get that wrong?

  7. Larry Hengen Says:

    @stamf,

    Sorry but I can’t speak to EMBT’s intent. It is a reasonable assumption though, but does not necessitate that the compiler only appear in that edition of the product. In fact, tempting people to try the Linux compiler and imagine the possibilities, would likely improve adoption of both the Pro and Enterprise SKUs. That is assuming the compiler was present in both.

    Developers need to play with technology to determine what it can be used for. If they play with someone else’s compiler they might adopt that instead (think RemObjects). That is why Turbo Pascal and the initial versions of Delphi were so successful; it cost very little to play with it.

Leave a Reply