Max Nilson [[EMAIL PROTECTED]] wrote:
>There are two main problems with marketing any Delphi component from
our
>experience. One is that the time to properly document a component is
fairly
>long, almost as long as it takes to write them. The other is in having
>enough time to spend actually marketing the component, that is, placing
it
>on all the Delphi sites, sending news messages to the most useful
places,
>trying to get people to link to your sire etc. Then you also need to
>consider the technical support costs as an on going thing for the
company...
All true, but it needs to be balanced against the potential gains that
are available. Perhaps too few of us are prepared to really attempt to
market our own components. You imply that you've tried it, though?
>Because Profax's focus is on products rather than components it become
very
>hard to justify this kind of money for the pitiful returns that can be
>achieved. We are open to offers to handle the documentation and
marketing
>for us from anyone who can provide good references in this area.
Ok, well I can't help you there - we haven't published any components
ourselves (who has, on this list? How successful were you?). But,
correct me if I'm wrong, I think there is a very large and potentially
very lucrative market out there, not just "pitiful returns"...
>After trying a couple
>of the major component libraries, and accessing many of the shareware
code
>our opinion was that most of the Delphi components available were just
not
>good enough.
It can be hard to sort the find the wheat among the chaff sometimes.
But when you find a decent component it does make it worthwhile.
Similarly, I think that only those who do publish decent components make
money out of it.
>As I mentioned in my first message most of the third party components
are
>just incremental improvements on the existing Delphi components (and so
>inheriting all of the default Windows control stuff that we don't
like), or
>are wrapping some Windows control better or differently than Delphi
does.
>As the Profax teams primary contention is that the underlying Windows
>controls are bogus enough to warrant replacing the 99% of the third
party
>stuff is not much use to us.
Well if you can't abide the standard Windows controls then you do have a
problem: you're using an operating system you don't like. I'm not very
fond of Windows myself, but I'm not quite so ambitious as to attempt to
supersede all of the underlying Windows controls with my own versions!
I think you're aiming higher than the average developer, so I can only
wish you luck...
>Now in if two weeks I can implement an entire new data-aware grid that
has
>more features, less bugs and is smaller and simpler than anything else
out
>there then we regard this as *saving* money in the long run. We *want*
to be
>able to maintain the code in house, because that means that if
(Zharquon
>forbid!) a customer find a bug, then we can fix it instantly and not
have to
>worry about mailing component authors (who may or may not do anything),
>maintaining patches on other people code and hideous versioning
problems
>next upgrade.
Ok, to some extent I agree with you. It sounds like this grid was well
worth developing - if you were to develop something all-singing,
all-dancing that you expected to take a lot more than two weeks,
however, and can find something out there that already does a
substantial amount of what you want then you can hardly say that you're
better off developing it yourself. Or certain people wouldn't have had
to switch to programming C++ now... :)
>Now I'm not 100% against third partly libraries, but our experience so
far
>has gone like this:
>Infopower 2/3: Just wraps existing Delphi code (and badly in my
opinion),
>has so many bugs and warts that we gave up trying to fix them, and the
code
>after being hacked over and over from Delphi 1 -> 2 -> 3 -> four is so
>cluttered as to be almost san scrit like.
>QuickReports 1/2/3: After fixing dozens of bugs, and notifying the
>authors )and getting no response or fixes in new code!), and running
into
>terrible design flaws we gave up.
>AdRock components: Again just wrappers extending existing Windows
controls.
>Inherit all the behaviour we don't want.
>All of these products now sit mouldering on our library shelves and
will
>never be used again.
>The only two third-party products that we actually do
>use are:
>RP Pro 3: Gets the thumbs up for good coding, responsive developers and
a
>perfect feature match for what we wanted to do, that is automatically
>generate reports because actually writing reports that a good component
>could write for you is the most boring, time wasting and costly
exercise you
>will ever encounter.
>IB Objects: Jason Wharton provided a very nice connectivity layer to
>Interbase and we worked closely with him to get it working perfectly.
Jason
>has now wandering off into doing custom component development on top of
the
>connectivity layer so we as getting tempted to do a rewrite of the low
>levels of the code that we use and dump having to maintain installed
>versions of all the rest of the code.
Fair enough. I actually think you use an entirely reasonable range of
third party products. We still use the InfoPower suite, and while they
have their flaws they're an improvement on the standard Delphi
components, so I definitely don't regret having them. We decided to
stick with QuickReports - a poor move, IMO. But then, I'd also be
happier if I'd never even seen a 16 bit version of Delphi (or Windows),
much less had to program in it, and QuickReports is more of a benefit
than a pain these days(finally). We gave up on CrystalReports very
early on, thank goodness, and I have horrible memories of it, but from
what I hear it's improved no end as well.
So things were bad before. But they improve daily.
>> So you won't be marketing your grid then. Too bad.
>As I said the cost verses return on component marketing is a problem.
Also
>our grid is closely tied into a lot of our other code by assumption.
For
>example we only have a data-aware grid, because if we need to do non
>data-aware grid stuff we just throw the information into a one or our
memory
>tables and use the data-aware grid and data-aware control with all the
>funkly data validation mechanism we have engineered.
Our own components suffer from similar problems - among the things they
expect is descriptive information of each database to be obtainable from
tables within it, and they also rely on our own memory tables. So
perhaps I should yield the point gracefully! :)
>Perhaps one day we will be able to sell the entire suite, but unless
you
>want to talk real money with us our components must, per force, remain
in
>house.
Cheers,
Carl Reynolds Ph: +64-9-4154790
CJN Technologies Ltd. Fax: +64-9-4154791
[EMAIL PROTECTED] DDI: +64-9-4154795
PO Box 302-278, North Harbour, Auckland, New Zealand
12 Piermark Drive, North Harbour Estate, Auckland, NZ
Visit our website at http://www.cjntech.co.nz/
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
