mx odbc

[Alan Kennedy]

Kim Petersen wrote:

> It *is* a service - i agree completely and even if i don't use the
> support i'll prolly patch the problem and send the result upstream -
> that really isn't an argument to use in the below. The reason for
> that statement was simply that in opensource situations, we'll 
> _maybe_ locate the bug ourselves (or patch the product to do what
> we want - which *cannot* be done in closed-source) and i'm not
> talking beer!

I agree that it's a good thing that you can find and patch bugs
yourself, because it's open source. But I do feel compelled to point
out that if the patch is to be accepted back into the product, that
requires time from the maintainer, to review your patch, and test it
in all scenarios and on all platforms. I'm sure you appreciate this,
but I think a lot of people don't.

> 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.

> So i
> can't even tell my customers that [even if i believed that your
> argument of telling customers about developing methods have any
> substance for them *at all* (its the product that counts - not
> the methods)].

No, it's the method that counts when you're talking about the cost of
development. You complained about how expensive a developer license
for mxODBC was, which is your methods, not your products.

Let's try a simple little thought experiment. Say you hire a
freelancer, and you pay them €1000/week to work on your product. You
hire them for 6 months, or 26 weeks, so that's €26,000 that pay your
freelancer.

Now say you get a nasty little bug, that requires detailed
investigation. You're fortunate enough to have a quality freelancer
that is able to find the bug, after 3-4 days of investigation, fix
the bug in 2 days, and then test the fix for another 2 days. So that's
7-8 days, @€200/day. And that's just one bug.

Seems to me that the cost of your software "developer" licenses are
actually quite cost effective after all.

> 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.

> 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?

> TANSTAAFL!

I think we definitely agree on that.

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan:              http://xhaus.com/mailto/alan