Re: article: "Borland going after services revenue"

From: Peter Sleuth (nomail_at_nospam.com)
Date: 01/23/05 

Date: Sun, 23 Jan 2005 17:46:15 +0100

"Captain Jake" wrote ...
> Peter Sleuth wrote
>> Jake,
>>
>> as I see the word RemObjects is obviously a red flag for you ;-)
>
> No, not at all. I think RemObjects is an excellent product in every sense
> of
> the word, including the code itself. But a red flag for me is when
> programmers continually ignore economics and think everything is just a
> matter of technical know-how and ability, or avenging their anger at
> Borland.

There is more to entrepreneurial activity then just economics. Some
entrepreneurs have a longterm vision, to make the world a better place,
whatever their vision is. They are even willing to risk for failure just to
realize their vision. Even if chrome shouldnīt bring in a single cent of
revenues for RemObjects, as long as RemObjects can finance their chrome
activities with cashflows earned on other products, as a customer I donīt
see any problem with that. And even if they should go bancrupt about their
chrome activities, at least they tried, and might still be satisfied about
it, even if it didnīt pay off and in the end the company died. But to
understand this, you would have to be an entrepreneur yourself.

>> Still, for what I would wish as a customer, meaning support for .NET2.0
>> once
>> it is released, backporting of features to Win32 (generics, attributes),
>> a
>> Win64 compiler, updates to the linux compiler, I would wish they had more
>> resources working on this. I donīt see all of this happen in a reasonable
>> time-frame (next two years), and I think that lack of resources is one of
>> the main reasons for that.
>
> I am not going to be so silly as to predict what Borland will or can do in
> the next two years, but I think that every company on the planet has
> limited
> resources, even Microsoft. There are a lot of things I'd love to see
> Microsoft do, that they don't do either. Limited resources are a fact of
> life, and the reason why economics exists in the first place.

It is not only a matter of limited resources, but also of the allocation of
existing resources. There are business units at Borland that are getting
more resources then before (professional services etc., but also their
liquidity in their balance sheet has increased from a bit less then USD 200
million 2-3 years ago to currently about USD 210 million, so obviously
management thinks it is more worthwhile to invest into money market accounts
instead of their point-products). Economics are also about efficient
allocation of resources, and as a customer I would wish their would allocate
more money to their point-products instead of money-market accounts.
Obviously I wonīt be able to convince top management to do otherwise as long
as I am not a majority shareholder of Borland, and I am probably never going
to be one ;-)

>> I think you are overevaluating compiler work here. If you want the latest
>> advanced optimization techniques, you need excellent staff. But to keep
>> different compilers on par regarding syntax support, backporting existing
>> features et al., it will probably take less then a genius for that.
>
> I didn't say anything about genius. I was talking about experience.
> Experience counts far more than innate intelligence (and education) when
> it
> comes to getting any particular type of software developed.

Here I agree.

>> As a customer, it is actually very easy for me, I donīt need to speculate
>> about any theoretic questions, I just need to evaluate past performance.
>
> Borland's past performance has always been a poor guide to the future.
> Just
> before Delphi 4 was released, their past performance would lead you to
> expect
> that D4 was going to be a magnificent release. It was just the opposite.
> Just
> before Delphi was released in 1995 their past performance would lead one
> to
> think they had no clue about RAD or GUI development. And so on.

Well, we will see. For now I would be surprised to see more then 50% of the
following from Borland within the next two years:
a Delphi .NET2.0 compiler, a Delphi-Win64 compiler, a Delphi32-compiler
language-wise on par with the Delphi.NET2.0 compiler, and a kylix compiler
on par with the other two compilers.

>> Instead I see aquisitions of consulting boutiques, sigh. While I canīt
>> evaluate if this is a good decision for Borland or not (it probably is),
>> as
>> a customer that is interested in the so called "Point-release"-products,
>> this is just not relevant for me.
>
> Maybe, but it is relevant to a lot of senior software developers and
> CIO's.
>

Well, the question is how ALM and SDO suites are seen in the market. There
are two different buying strategies, either buying "best of breed", or
buying the "all-from-one-vendor" approach to get a tightly integrated
ALM/SDO suite. As an example, buying "best of breed" might mean to buy one
component from Borland, another one from Microsoft, one more from Rational
and another one from Sun and so on. The all-from-one-vendor strategy means
you buy all or nothing from the same vendor, that means you buy either the
entire ALM/SDO stack from Borland, or the Atlantic stack from Rational, or
the teamsystem stack from Microsoft.

Quite a few corporations are buying into the all-from-one-vendor strategy,
as you can see in Borlands quarterly press releases (increasing numbers of
customer deals worth more then USD 1 mio, typically a stack sale) and
similar statements from Rational.

Once we agree that a good amount of corporate customers buy into the
all-from-one-vendor strategy instead of a best of breed-strategy, the
question remains what is going to influence the decision for an
ALM/SDO-stack most. Is it the CIO that makes the decision based on what
toplevel reporting he personally can get out of the stack (see Borlands SDO
vision including the Themis, Hyperion and Prometheus milestones), or is it
the business unit heads that will make the decision based on what they see
makes their developers most productive?

Personally, I think that the IDE (and the supported compilers) is still one
of the key factors. For my own company I can say that the day we standardize
on VisualStudio, we will buy into the TeamSystem stack, the day we would
standardize on Eclipse/Websphere developer we would buy into the Atlantic
stack and as long as we are working with Borland IDEs there is a good chance
we buy into Borlands ALM/SDO stack. So for us the IDE (and the compilers) is
the main factor, every other stack decision will be derived from that.

>> There is not only Microsoft and Borland out there.
>
> True, there is also IBM and Intel.

and a few others.

-Peter

Relevant Pages

  • Re: Compiler optimisation
    ... > Borland have very tiny resources, and that resources Borland need to buy ... because Borland cannot make money selling compilers. ... If it had spent 10% of that money on improving the Delphi compiler ...
    (borland.public.delphi.non-technical)
  • Re: An alternative future for the native Delphi compiler <LONG-ISH>
    ... That's a big gain given ... > Borlands lack of resources. ... If Borland are still managing the compiler updates, ... Borland - adding a new resource actually uses up some of the resources ...
    (borland.public.delphi.non-technical)
  • Re: article: "Borland going after services revenue"
    ... >> else) working on the compiler, ... Still, for what I would wish as a customer, meaning support for .NET2.0 once ... resources working on this. ... As far as I can see as a customer, I wish Borland could add some additional ...
    (borland.public.delphi.non-technical)
  • Re: A question for Borlands Tasm5.0 users -- Some sort of bug ?
    ... for the compiler here one double is 64 bits ... this is for all the Borland C/C++ compilers on a 32 bit cpu ... push pop of Dword push pop of 32 bits data ... the main problem is this macro not reset the stack ...
    (alt.lang.asm)
  • Re: made it to page 4 of gforth tutorial
    ... the stack space anyway. ... And there are clearly going to be some platform ... came with an embedded C compiler once. ... like I've written before, if one *really* needs recursion (as I have, ...
    (comp.lang.forth)