Re: Delphi and the .Net platform

Troy Wolbrink wrote:
From my personal perspective (a Delphi developer with alot of code that I
want to port into the .NET environment), the approach CodeGear has taken has
been very appreciated. As far as I'm concerned, the less I have to rewrite
already working code, the better. But you're debating this from the
perspective of ROI, etc. from the perspective of what's going to keep
CodeGear competitive.

Yes, I'm debating that because a healthy product and company serves all
of our self interests. I'm looking at it from a long term perspective
and the simple desire to use the "best" tools. :)

1. New young developers are not going to be that attacted to native Delphi.
This is probably the major customer base of Delphi, but I believe that .NET
will be more appealing to the new generation. This was my hunch when I read
this: http://blog.marcocantu.com/blog/ekon11_day3.html "...a clear sign
that Delphi is not attracting new developers...".

There is no way CodeGear can attract new customers with Delphi for .NET.
That's simply a pipe dream.

VS.NET is the standard .NET development environment and it's better for
..NET development: more up to date, more full featured, used more broadly
commercially, etc. Schools are going to use the *FREE* Express versions
and be done with it. Students interested in .NET will want to use
VS.NET too. They aren't going to use the outdated Turbo editions that
don't even support .NET 2.0. There is literally *no* room for CodeGear
to compete there.

The only way to appeal to *new* customers is to be significantly better.
If CodeGear wants to compete on .NET, they have to be better. Right
now, they aren't.

2. It's too late for CodeGear to radically change their .NET
backward-source-compatiblity strategy.

Why? If the strategy is a poor one, admit the mistake and do something
that makes sense.

It's insane to keep investing good money after bad. They've had enough
releases to write it off. If they'd separate the SKUs they could get a
clear look at the ROI. Then if they consider how far behind they are in
supporting .NET, the decision is easy. Right now they're just in denial.

And this isn't about giving Delphi for .NET enough time to get some
traction. IMO, they didn't give products like CBuilderX enough
time/investment and probably Kylix as well. But Delphi for .NET has had
more than enough time.

If they were to change everything
around now, they would really lose their customer base.

The vast majority of the Delphi customer base is native, not .NET.
Sure, some people will be upset, like when they discontinued Kylix,
CBuilderX, C# Builder, WinForms support, etc. Tough. It's the right
thing to do.

But they could
begin refactoring some of their lower level System.pas and SysUtils.pas
stuff to use the FCL more and P/Invoke less.

They should do that anyway; it's not that much effort.

So I think CodeGear should pour *more* resources into developing and
improving the .NET side of Delphi to entice new customers,

Again, IMO, this is investing good money after bad. They tried, it's
over. Move on, find another way to compete. Make something better.
Make something compelling. It doesn't have to be .NET, but it does have
to be better than VS.NET.

Looking at the roadmap is telling though. There's no .NET 3.0+ on it.
Hopefully, this past release will be the litmus test for .NET and
they'll kill it and try something different instead (mixed-mode, Chrome
like VS.NET plug-in, etc.)

but they should
also keep the Win32 side of Delphi running strong for the long time
customers.

Sure, that's their cash cow. They'd be foolish not to keep that going
and their roadmap indicates that they're doing that. I just wish .NET
didn't take resources away from that progress and I wish it weren't
neglected for so long, but that's all in the past.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: D2007
    ... There there are two brands out here.One is the brand name of the company & ... 2005.Though it improved a little with BDS 2006 many customers were still ... I am aware that developers are running the show in CodeGear now. ... How ever i can not help being harsh on CodeGear since I want to use Delphi ...
    (borland.public.delphi.non-technical)
  • Re: Wine release
    ... customers would be willing to pay for a Delphi for? ... A better question to ask is "what percentage of all developers would become ... If Delphi is to succeed in the long term, CodeGear needs to bring in new ...
    (borland.public.delphi.non-technical)
  • Re: Delphi 2007 Confusion
    ... Rich Davis wrote: ... inform your customers, but anyone who is anxious for the newest ... Delphi has a tough choice. ... Delphi Product Manager - CodeGear ...
    (borland.public.delphi.non-technical)
  • Re: The New Roadmap
    ... Tiburon sounds very interesting, but as for Highlander, I fear it will be ... I really think CodeGear would do best to concentrate ... already committed to a large Delphi codebase. ... I think it is indeed important to consider the needs of existing customers, ...
    (borland.public.delphi.non-technical)
  • Re: Make Help Docs Priority #1
    ... BE BOTHERED TO PROVIDE A WAY FOR YOUR CUSTOMERS TO CONTRIBUTE to the products that THEY'VE ALREADY PAID YOU FOR! ... I snipped a lot - I think it's a fair rant, but Borland has offered some way to contribute. ... John Kaster has promised that a CodeGear supported, somewhat moderated, wiki-style community documentation site is coming. ... I, for one, do *NOT* want any old user to come in and edit the site, telling every new user that records with classes are the preferred way to do OOP in Delphi, or that the BDE is the best way to access MS SQL Server databases. ...
    (borland.public.delphi.non-technical)