Re: Why ...

Hi:

> Why do we need to purchase a new product to get bug fixes?

I have posed this very question to myself in the past and here's what I have
discovered working in product groups for some years now.

In the case of Borland, we do of course put out official patches to support
releases, so I am assuming that your post indicates that not all bugs are
applied to a previous release, but nevertheless appear in a future release.
(In other words, the patches include a subset of bugs, not all bugs.)

A given, we will produce new releases. Our existence depends on new and
renewed licenses, so we build new functionality to support our ever evolving
marketplace. That's our business.

At some point during the development cycle, we must switch from the past
release and focus on the next release. The more time we spend patching a
previous release and responding to bugs (many of which require enhancements
to existing features or even require new features), the less time we have to
build new features for the next release.

Both patching previous releases and building new products at the same time,
continuously, is not feasible. We'd be working on two code bases at a time
(or more depending on how many releases back we need to go). It would be
like going backwards and forward in time--at the same time. Going one
direction or the other is enough of a challenge and requires full attention
to manage the complexity of releases or patches. We only patch when we
really, really need to, because the overhead cost automatically applies
against the next release.

So, we strike a compromise between supporting the needs of existing
customers and supporting the needs of the future customer (who often enough
are the same person).

Of course, it would be ideal if we shipped a product that didn't require any
patches at all, and this is an ideal we strive towards, never really
expecting to reach it as our customer base is wide and needs diverse.
(What's a bug to one person is a non-issue to another or a bona fide feature
to yet another.)

I'm sure there are other factors, but this is what I've observed.

Troy Klukewich
Manager, Product Documentation
Borland Software





"Bill Smith" <bsmith@xxxxxxxxxx> wrote in message
news:436f2302$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> Why do we need to purchase a new product to get bug fixes?


.

Relevant Pages

  • Re: Stimmung auf dem Tiefpunkt 2
    ... Beispiel Bugs fixen, QFEs produzieren, neue Feature bauen -- zurücktreten. ... Support die tiefsten Fachkenntnisse erwarten. ... Der erste war schon für einen anderen Kunden gebaut, ... Du die MFC nie mochtest - war ein besserer und weiterer MFC Support, ...
    (microsoft.public.de.vc)
  • Re: Quality of FreeBSD
    ... Since then numerous bugs were fixed, ... large file systems, 64-bit support on newer AMD and Intel hardware, ... Since 6.x is maturing in pretty good synch with their deployment timeline ... as a virtual server product at an ISP. ...
    (freebsd-stable)
  • Re: Rumors of reduced support for C++ /CLI
    ... almost complete refusal to fix C++/CLI bugs ... ... Because MS decides not to fix them, or considers some idiotic and onerous workaround sufficient, does not make them any less genuine. ... I, OTOH, consider good support the ability to implement features and to fix bugs. ... I've been very favourably impressed by Microsoft's commitment to enhancements, new features, and bug fixes. ...
    (microsoft.public.dotnet.languages.vc)
  • [ANN]: Firestorm 0.5.1 released
    ... Firestorm is a very fast and efficient ... Firestorm has good support for snort signatures, IP defragmentation, TCP ... BUGS FIXED ... o Fix silly bugs in ipfrag which crept in with 0.4.6 ...
    (comp.os.linux.security)
  • [ANN]: Firestorm 0.5.1 released
    ... Firestorm is a very fast and efficient ... Firestorm has good support for snort signatures, IP defragmentation, TCP ... BUGS FIXED ... o Fix silly bugs in ipfrag which crept in with 0.4.6 ...
    (Focus-IDS)