mx odbc

**M.-A. Lemburg** · Jul 18 '05, 12:23 AM

Re: mx odbc

Kim Petersen wrote:[color=blue]
> Regarding ODBC usage in Python...
>
> it seems to me that there is a couple of ways to use odbc from python,
> one of these is the MX version - now that one has a pretty steep licence
> cost (imho). So now comes my question (from reading this group quite a
> bit):
>
> - what is the basic reason for using MX versus the others?[/color]

Having a maintained and actively supported ODBC interface which
works on all major platforms, not just Windows ?!

--
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source (#1, Jul 08 2003)[color=blue][color=green][color=darkred]
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/[/color][/color][/color]
_______________ _______________ _______________ _______________ ____________
2003-07-01: Released mxODBC.Zope.DA for FreeBSD 1.0.6 beta 1

**trewornan** · Jul 18 '05, 12:23 AM

Re: mx odbc

On Tue, 08 Jul 2003 18:04:11 +0200, M.-A. Lemburg wrote:
[color=blue]
> Having a maintained and actively supported ODBC interface which
> works on all major platforms, not just Windows ?![/color]

Agreed that this must be a lot of work but most of us use open source
software for a reason. Certainly the licensing of mxODBC was the main
reason I choose to use the mySQL module directly instead.

Trewornan

**Kim Petersen** · Jul 18 '05, 12:24 AM

Re: mx odbc

M.-A. Lemburg wrote:[color=blue]
> Kim Petersen wrote:
>[color=green]
>> Regarding ODBC usage in Python...
>>
>> it seems to me that there is a couple of ways to use odbc from python,
>> one of these is the MX version - now that one has a pretty steep
>> licence cost (imho). So now comes my question (from reading this group
>> quite a bit):
>>
>> - what is the basic reason for using MX versus the others?[/color]
>
>
> Having a maintained and actively supported ODBC interface which
> works on all major platforms, not just Windows ?![/color]

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 - i
could and would accept such a cost for the python platform (no trouble!)
[except in the few (from our view) cases where the user just needs a
small tool.

IMHO your setting the value of the package so high, that there would be
better economics in making a rewrite of our database modules every time
a customer needs some new one (porting to a new database specific DB-SIG
compliant module).
[color=blue]
>[/color]

**Paul Boddie** · Jul 18 '05, 12:24 AM

Re: mx odbc

"trewornan" <galen@grex_nos pam_.org> wrote in message news:<pan.2003. 07.08.21.08.42. 395562@grex_nos pam_.org>...[color=blue]
> On Tue, 08 Jul 2003 18:04:11 +0200, M.-A. Lemburg wrote:
>[color=green]
> > Having a maintained and actively supported ODBC interface which
> > works on all major platforms, not just Windows ?![/color]
>
> Agreed that this must be a lot of work but most of us use open source
> software for a reason.[/color]

Yes, mostly for access to the sources, the possibility of
redistribution and the various other freedoms associated with Open
Source/Free Software.

Paul

P.S. Of course it doesn't hurt to get stuff for free, but if that was
the most important thing, you'd surely be content to download
proprietary "free stuff", demos and evaluations (and be at the mercy
of the binary-only distributor in question).

**David Bolen** · Jul 18 '05, 12:25 AM

Re: mx odbc

Kim Petersen <kp@kyborg.dk > writes:
[color=blue]
> 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 - i could and would accept such a cost for the
> python platform (no trouble!) [except in the few (from our view) cases
> where the user just needs a small tool.[/color]

Except that if you're going to resell a product, presumably you'd go
for the per-developer fee ($1250). It'll beat the per-CPU license at
about 18 customers (assuming one CPU per customer), and just continue
shrinking on a per-customer basis after that. In effect, the
per-developer license is a one time, royalty free, license, the
marginal unit cost of which disappears over time. As with anything,
the actual price is up to the owner to set, but on our part, we've
found the economics reasonable for the functionality supplied within
our commercial endeavors.

Is it the only way to go for database access with Python - certainly
not. But for us (Windows platform with ODBC sources) its worth it for
the effort Marc-Andre has put in to best support ODBC in that
environment.

Just another data point for what it's worth.

-- David

**Kim Petersen** · Jul 18 '05, 12:25 AM

Re: mx odbc

David Bolen wrote:[color=blue]
> Kim Petersen <kp@kyborg.dk > writes:
>
>[color=green]
>>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 - i could and would accept such a cost for the
>>python platform (no trouble!) [except in the few (from our view) cases
>>where the user just needs a small tool.[/color]
>
>
> Except that if you're going to resell a product, presumably you'd go
> for the per-developer fee ($1250).[/color]
We work in teams - so that would be 1250*4 making the below calculation
18*4 (and we're not able to pull in freelancers on this kinda stuff then
- other than paying another 1250). [Note: i'm being honest to the gist
of the licence here - you could argue for one developer fee, rest of the
developers run pr.CPU licence, and you build project on the developer
machine for final wrapping]
[color=blue]
> It'll beat the per-CPU license at
> about 18 customers (assuming one CPU per customer), and just continue
> shrinking on a per-customer basis after that. In effect, the
> per-developer license is a one time, royalty free, license, the
> marginal unit cost of which disappears over time. As with anything,
> the actual price is up to the owner to set, but on our part, we've
> found the economics reasonable for the functionality supplied within
> our commercial endeavors.
>
> Is it the only way to go for database access with Python - certainly
> not. But for us (Windows platform with ODBC sources) its worth it for
> the effort Marc-Andre has put in to best support ODBC in that
> environment.[/color]

Not arguing about Marc-Andre's fine contributions - they are excellent ;-)
I have no idea about the support (obviously) - but then i hardly ever
buy/use support for development tools [especially not open-source ones].
[color=blue]
>
> Just another data point for what it's worth.
>
> -- David[/color]

--
Med Venlig Hilsen / Regards

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

**Kim Petersen** · Jul 18 '05, 12:26 AM

Re: mx odbc

Alan Kennedy wrote:[color=blue]
> Kim Petersen wrote:
>
>[color=green]
>>I have no idea about the support (obviously) - but then i hardly ever
>>buy/use support for development tools [especially not open-source ones].[/color]
>
>
> Well, that just about says it all for the theory that "open source
> developers should make their money from services".
>
> What many people seem to forget is that maintaining high quality
> software *is* a service: in the case of mxODBC, a very high quality
> service. If M-A-L didn't charge licensing fees, then he'd be providing
> a high quality service, i.e. well designed, maintained and up-to-date
> software, without any income at all, since, in general, developers
> don't buy support for development tools, unless they absolutely must.[/color]

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!
[color=blue]
>
> Kim Petersen wrote:
>
>[color=green]
>>[snip] 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[/color]
>
>
> It's a free market: pick another (cheaper) ODBC driver and use that
> instead. Just make sure that your customers understand that they will
> get a poorer quality product from you because they're paying you less
> money, so you have to use lower quality components in your software:
> I wonder how long they'll be your customers.[/color]

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...). 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)].
[color=blue]
>
> Kim Petersen wrote:
>
>[color=green]
>>We work in teams - so that would be 1250*4 making the below calculation
>>18*4 (and we're not able to pull in freelancers on this kinda stuff then
>>- other than paying another 1250).[/color]
>
>
> And how much would you pay these freelancers? Probably quite a
> substantial amount over the weeks or months that you retain them,
> and probably *far* in excess of the developer license cost for mxODBC.
> How much improved productivity will you get from those developers
> because they're not spending a week chasing weird bugs in the
> database/ODBC code?[/color]

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].
[color=blue]
>
> I feel quite annoyed when people give out about having to pay money
> for software: someone, somewhere has to write that software: that
> someone has to pay the rent, the utility bills, etc, etc, etc, etc.
> Demanding that everyone work for nothing is completely unreasonable:
> just because you're too stingy to pay for what you get. Some OSS
> developers are fortunate enough that they don't have to charge money
> for their software, because the government, or the education system,
> or some charitable foundation, pays their wages. But that's not true
> for all OSS developers.[/color]

We already pay substantial amounts for software - including donations
for opensource projects - so your tirade falls on a wrong spot. [In our
endsystems i estimate around 60% goes to hardware 30% goes to royalties
etc. (as we implement in OSS software a large amount of this returns -
not as much as i would wish - but then thats something for my boss to
decide)].
[color=blue]
>
> To those who continue to complain about having to pay for software,
> I say: If you don't like paying, fork the software, maintain your
> own product and let it be free (both in the free-speech and the
> free-beer senses): see how you long *you* last.[/color]

Can you mention even on spot where i complained against paying for
software ? (hint: the amount - not that it has a price).

TANSTAAFL![color=blue]
>
> not-biting-the-hand-that-feeds-ly yrs.
>[/color]

**Alan Kennedy** · Jul 18 '05, 12:26 AM

Re: mx odbc

Kim Petersen wrote:
[color=blue]
> 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![/color]

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.
[color=blue]
> 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...).[/color]

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.
[color=blue]
> 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)].[/color]

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.
[color=blue]
> 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].[/color]

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 "uselessnes s" of one's product.
[color=blue]
> Can you mention even on spot where i complained against paying for
> software ? (hint: the amount - not that it has a price).[/color]

Kim Petersen wrote:
[color=blue]
> 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[/color]

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?
[color=blue]
> TANSTAAFL![/color]

I think we definitely agree on that.

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

**Paul Boddie** · Jul 18 '05, 12:26 AM

Re: mx odbc

Alan Kennedy <alanmk@hotmail .com> wrote in message news:<3F0D4728. 45284530@hotmai l.com>...[color=blue]
>
> To those who continue to complain about having to pay for software,
> I say: If you don't like paying, fork the software, maintain your
> own product and let it be free (both in the free-speech and the
> free-beer senses): see how you long *you* last.[/color]

Or in this case, don't fork the product because the licence won't
permit it. Instead, write your own ODBC driver manager package.

I've stated before that vocal critics of mxODBC's licensing could
relatively easily wrap something like iODBC and release the results
under an open source licence, but the fact that it hasn't been done
really says a lot about how much the mxODBC licensing is a "problem"
for those people.

Paul

**Kim Petersen** · Jul 18 '05, 12:26 AM

Re: mx odbc

Alan Kennedy wrote:[color=blue]
> Kim Petersen wrote:[color=green]
>>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...).[/color]
>
>
> 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.[/color]

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.
[color=blue]
>[color=green]
>>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].[/color]
>
>
> 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 "uselessnes s" of one's product.
>[/color]

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.
[color=blue]
>[color=green]
>>Can you mention even on spot where i complained against paying for
>>software ? (hint: the amount - not that it has a price).[/color]
>
>
> Kim Petersen wrote:
>
>[color=green]
>>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[/color]
>
>
> 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?[/color]

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 - Innovationshuse t
Havneparken 2
7100 Vejle
Tlf. +4576408183 || Fax. +4576408188

mx odbc

mx odbc

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment