«

Alan Kennedy wrote:
> Kim Petersen wrote:
>>Regarding the free marked - i agree - against the other - what is it
>>*exactly* that makes mxODBC a better quality product - noone has
>>seemed to be able to tell (and yes - you do in the above claim that...).
>
>
> Hmm, I'm not sure I get what you're trying to say here: what do you
> mean by "noone has seemed to be able to tell"? If by that you mean
> "what is it that makes mxODBC a better quality product", try the
> following
>
> 1. Continually kept up to date with all versions of python
> 2. Continually kept up to date with all versions of ODBC standards
> 3. Continually maintained on a wide variety of platforms
> 4. Optimal memory and time efficiency because it's mostly coded in C
> 5. Etc, etc.
>
> If these aren't the kinds of things that make software "better
> quality", then I have no idea what you mean.

Those qualities are all general product qualities, and may or may not
have effect for your development. [hmm - i'm having a hard time
formulating this in english - sorry if it gets out mangled]. A thing
like: the type conversion (to and from) the SQL backend is highly
efficient - would be a quality in my eyes.

In the world where i live, the platforms are fixed and tested for the
software [eg. specific versions (Windows, Linux and SCO (urgh!))],
memory and time efficiencies may have influence but generally don't (one
of the reasons we use python btw. otherwise we'd stick with C/C++ or
Delphi). If a customer upgrade's a system to something not recommended -
well the trouble will come knocking on his wallet and be a welcome guest
in ours.

>
>>essence of my argument - the pricing of this *little* (but
>>essential) component drives the pricing of the end-product up
>>a substantial amount - that imho is not corresponding to the
>>usefulnes of the product.[and to use your argument from before -
>>i need to find another product then].
>
>
> No, you're thinking about it all wrong.
>
> This little component, an ODBC driver, *does* correspond to the
> "usefulness" (i.e. quality) of the product. Or more correctly, if
> one is using a poor quality ODBC driver, then that contributes to
> the "uselessness" of one's product.
>

Let me rephrase the part about why i find the pricing steep:

1 developer licence for Qt: 1550$
1 developer licence for mxODBC: 1025$

from my point of view - there _should_ be a correspondance between
problem-domain and pricing.

>
>>Can you mention even on spot where i complained against paying for
>>software ? (hint: the amount - not that it has a price).
>
>
> Kim Petersen wrote:
>
>
>>I'm not arguing that thats not important - *but* paying 70$ pr.
>>customer, is the equivalent of paying you for 1hr of support for
>>each customer [not installation mind you], where our own
>>licence/supportcost is already getting lower and lower... I find
>>that _extremely_ steep
>
>
> Fair enough, it was the amount you complained about, not that there
> was a cost. But is $70 really such a high cost? What percentage of the
> end-user cost of your product is required to pay for mxODBC?

That certainly depends on the product - if we run our full economics
package for the customer - it would be negligible. If we're talking
about a small contactdatabase (or a minor statistics module to run on a
single desktop) - it certainly is substantial.

--
Med Venlig Hilsen / Regards

Kim Petersen - Kyborg A/S (Udvikling)
IT - Innovationshuset
Havneparken 2
7100 Vejle
Tlf. +4576408183 || Fax. +4576408188