A suggested strategy
Here is a possible strategy CodeGear could use to gain interesting short-time revenue and to increase Delphi’s market share significantly long-term. The goal is to keep existing customers by not forcing them to migrate to competitors, to build confidence with today’s customers and to attract new customers who are interested in native cross-platform code. Due to the resource constraints CodeGear currently is facing, this is a phased approach using only minimal investment.
This is important to keep existing customers who got scared off by the “Kylix will remain dead” statement done by CodeGear CEO Ben Smith. Announce that the CLX is dead and will not get picked up again. Announce that you will first focus on Linux as a server target, with support for GUI Desktop applications possibly coming at a later point.
This could be used to give a preview of what’s coming in the next Delphi release and as some sort of “proof” that you are actually working on Linux support.
The sources of the Kylix compiler to my knowledge are to a large extend identical to the Delphi 6 ones. According to information given by ex-Borland compiler engineer Name removed, it would be a rather easy task to merge its code-tree into today’s Delphi compiler source.
This way, cross-platform support becomes a one-time investment – compiler-wise, the Linux and Windows platforms are nearly identical. For the future there won’t be the need to separately maintain the Linux compiler due to it being single-sourced with the Win32 one.
As an additional task the Linux ELF binary format linker must be ported to Win32. This also will be a rather easy tasks, without any complex research work needed or roadblocks being in place. The technical part of this is explained in the following section.
From the CrossKylix work with the compiler it can be said that the whole process of merging the compilers and porting the linker should be no more than 3-5 months of man work for a skilled compiler engineer.
Work on this should be started as soon as possible and be finished by fall 2007.
Many of your Delphi Technology Partners create and sell components and products intended for server usage – Web applications (e.g. IntraWeb), n-Tier applications (e.g. kbmMW), Database applications (NexusDB) – all these areas will highly profit from a native Linux server target, reference to non-public partner statements removed. Together with your partners, it will be possible to make Delphi an important player in these areas. Team up!
Such a release can be done after Highlander is shipped. It should include the Delphi Win32 personality including the Kylix cross-compiler. This way your cross-platform venture will you give you some quick ROI and also provide you early feedback about market interest. Market this product as the ideal tool to create native cross-platform server/n-tier/database/web applications for both Windows and Linux outside of a single Windows IDE.
Also create a free “Explorer” version not allowing component installation that can be used for the creation of CGI web applications and other hobbyists tools.
The version of BDS to be released after Highlander should include the Kylix cross-compiler personality. “Get the full power of Microsoft’s latest technologies without getting locked into those forever” will be a huge selling point and give people a reason to choose BDS over Visual Studio.
There are a big number of CodeGear partners that make a living from selling Delphi components. Using a Linux target, these will be able to increase their market reach in many cases.
The existing PHP4Delphi project for example will enable your component vendors to also sell their components as PHP extension modules compiled with your Linux Delphi compiler. The PHP market is an extremely interesting one for component vendors. Strengthening your component vendors is good for you. Making Delphi a RAD platform for the development of fast native-code PHP modules that then can be used inside PHP scripting also will increase interest in Delphi.
Such a community project could start working on an VCL implementation for Linux. There is a lot of interest in the community for helping out in this area, with several basic implementations already existing. Using this community project, there would unofficial support for the creation of native Linux Desktop GUI applications from inside BDS for those that need this today.
At a later point work from this community project could be merged and single-sourced with the VCL source code, becoming an officially supported CodeGear offering.