mx odbc

[Kim Petersen]

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