Marketing a system that relies on a component that is alpha version 0.1

ruby-talk
1

No matter how good the programming language is, no matter how easy it
is to develop database centric application with it, if the application
relies critically on a software component that is alpha version 0.1 the
last 7 years or so, and rarely upgraded, I will be laughed off if I
suggest to use such an application for corporate computing. But such is
the case with Ruby and Ruby on Rails relying on Oracle OCI8. Oracle
OCI8 has been alpha 0.1 since the first time I saw it (7 years ago?),
rarely upgraded (though the last one was May 2005). The perception is
that the developer of the driver perceives the driver to be *that much*
a long way to being production version 1.0, and has no time or desire
to get it to production robustness, and its development progress is
slower than the speed of a snail travelling across a path covered with
molasses.

If OCI8 is ready for production use now, don't be too modest, call it
version 1.0. If not, work to convey that there is a path to it getting
there soon. The battle for tool makers appears to have settled down;
lines have been drawn among Ruby, PHP, Python. The next battle is over
the minds and hearts of business database programmers. There's a lot of
VB, Delphi, PowerBuilder, and Oracle Developer developers to be won
over. You can't even be a contender in this battle if you don't have
database drivers perceived as active players and that perform with
industrial strength.

gk

2

as long as you're going to advocate bleeding edge technology like ruby and ruby-on-rails, why wouldn't you use a robust open source databASe engine instead of Oracle, with its fearsome costs and nightmare complexity?

I make good money building RAC and PDC clusters in my duties as Unix/Linux engineer for a VAR, but for my own business I use Postgresql.

I think you'll find that OS developers in general aren't going to be focusing on Oracle; rather how to get rid of that thing. Getting past the marketing hype, Oracle really is an '80's technology that's had layers of bloat and kludges slapped on over the years, now with a rube goldberg contraption type of clustering cobbled together and a half-baked clustering filesystem that is NOT industrial stength.

Just as corporations are now wising up that there are alternatives to Unix(tm) for the majority of biz apps, so they will with dbms as money gets tighter.

···

On Thu, Jul 07, 2005 at 05:15:45AM +0900, Jenjhiz wrote:

No matter how good the programming language is, no matter how easy it
is to develop database centric application with it, if the application
relies critically on a software component that is alpha version 0.1 the
last 7 years or so, and rarely upgraded, I will be laughed off if I
suggest to use such an application for corporate computing. But such is
the case with Ruby and Ruby on Rails relying on Oracle OCI8. Oracle
OCI8 has been alpha 0.1 since the first time I saw it (7 years ago?),
rarely upgraded (though the last one was May 2005). The perception is
that the developer of the driver perceives the driver to be *that much*
a long way to being production version 1.0, and has no time or desire
to get it to production robustness, and its development progress is
slower than the speed of a snail travelling across a path covered with
molasses.

If OCI8 is ready for production use now, don't be too modest, call it
version 1.0. If not, work to convey that there is a path to it getting
there soon. The battle for tool makers appears to have settled down;
lines have been drawn among Ruby, PHP, Python. The next battle is over
the minds and hearts of business database programmers. There's a lot of
VB, Delphi, PowerBuilder, and Oracle Developer developers to be won
over. You can't even be a contender in this battle if you don't have
database drivers perceived as active players and that perform with
industrial strength.

gk

3

my best work never gets to 1.0. that's because it's simple and stable for the
initial relase and i use versioning (libtool scheme) that has real meaning -
not marketing hype. i've noticed that people that write really good software,
like d.j. bernstein don't release that many versions; for instance cdb is
still at 0.75. that's because it's really good. in any case, unless you
understand the semantics of a particular software package it's kind of silly
to comment on it's robustness. for instance, using libtool versioning

   6.0.4

is probably much better and more stable than

   7.2.0

why? because 6 is backward compatible with 5,4,3 and 2. this is a good
indicator that the code has been very stable and not had it's interface
changed - only added to. 7.2.0, on the other hand wouldn't be backward
compatable at all and this probably means it's full of new bugs.

by the same logic

   0.25.0

would be a fantastic release. this would mean the package had been released
25 times without breaking the interface or adding to it. surely the initial
design must have been good!

in any case commentary on version numbers without including their meaning
isn't a good context to talk about stability or robustness. not that the oci8
lib is either (i don't know) but i thought i'd point out that not all verion
numbers are created equally.

about battling for supremacy: why would rails/ruby developers want all the
vb, delphi, powerBuilder, and oracle developers to jump ship and be
'converted'? if i were competing in the web development arena i'd be quite
happy to let them keep working in their antiquated environments - it'd be that
much more work for me :wink:

cheers.

-a

···

On Thu, 7 Jul 2005, Jenjhiz wrote:

No matter how good the programming language is, no matter how easy it
is to develop database centric application with it, if the application
relies critically on a software component that is alpha version 0.1 the
last 7 years or so, and rarely upgraded, I will be laughed off if I
suggest to use such an application for corporate computing. But such is
the case with Ruby and Ruby on Rails relying on Oracle OCI8. Oracle
OCI8 has been alpha 0.1 since the first time I saw it (7 years ago?),
rarely upgraded (though the last one was May 2005). The perception is
that the developer of the driver perceives the driver to be *that much*
a long way to being production version 1.0, and has no time or desire
to get it to production robustness, and its development progress is
slower than the speed of a snail travelling across a path covered with
molasses.

If OCI8 is ready for production use now, don't be too modest, call it
version 1.0. If not, work to convey that there is a path to it getting
there soon. The battle for tool makers appears to have settled down;
lines have been drawn among Ruby, PHP, Python. The next battle is over
the minds and hearts of business database programmers. There's a lot of
VB, Delphi, PowerBuilder, and Oracle Developer developers to be won
over. You can't even be a contender in this battle if you don't have
database drivers perceived as active players and that perform with
industrial strength.

gk

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso

===============================================================================

4

Assuming the interface to Ruby has a license that allows it, fork the
project, make no changes, and release BusinessOCI8 version 9.5.

···

On 06/07/05, Jenjhiz <jenjhiz@yahoo.com> wrote:

No matter how good the programming language is, no matter how easy it
is to develop database centric application with it, if the application
relies critically on a software component that is alpha version 0.1 the
last 7 years or so, and rarely upgraded, I will be laughed off if I
suggest to use such an application for corporate computing. But such is
the case with Ruby and Ruby on Rails relying on Oracle OCI8. Oracle
OCI8 has been alpha 0.1 since the first time I saw it (7 years ago?),
rarely upgraded (though the last one was May 2005). The perception is
that the developer of the driver perceives the driver to be *that much*
a long way to being production version 1.0, and has no time or desire
to get it to production robustness, and its development progress is
slower than the speed of a snail travelling across a path covered with
molasses.

If OCI8 is ready for production use now, don't be too modest, call it
version 1.0. If not, work to convey that there is a path to it getting
there soon. The battle for tool makers appears to have settled down;
lines have been drawn among Ruby, PHP, Python. The next battle is over
the minds and hearts of business database programmers. There's a lot of
VB, Delphi, PowerBuilder, and Oracle Developer developers to be won
over. You can't even be a contender in this battle if you don't have
database drivers perceived as active players and that perform with
industrial strength.

gk

5

Oh, i'm not advocating the use of Oracle. I'm trying to find a way to
get Ruby in our corporate door. No matter how great the Ruby
application I develop for my company, if it uses a critical component
that is *alpha* and *version 0.1* for many years, it will never ever
get pass the door. No matter how well that component works. If you work
for a company with strict standards, that's the reality. My point is
that it's time for the Ruby community to move away from the hacker's
lair and into, well, an office if not the boardroom. You need to dress
the dress, mate.

The comment about Oracle being an '80's technology is valid, but also
shows utter cluelessness in the context of product adoption. It's not
product superiority, and secondly, the people who decide on these
things do not care whether it has half-baked clustering filesystem. It
works for his competitor, his bank, the regulators, so it will work for
him. Why go against something that works 'good enough'? They are
different, them, from us coders, who are always looking for the best,
the quickest, the cleanest, the most compact, ...

< ... so they will with dbms as money gets tighter. ...>
And a mass exodus to MySQL and Postgres will ensue? Can you imagine the
uncertainty, pitfall, work, and whatever else of converting thousands
of tables and billions of records and thousands of business rules to
MySQL?

There is a reality out there that unfortunately many developers (who do
not risk their career and livelihood on decisions on tool selections)
fail to appreciate.

gk

6

My posting is not about whether a lower or higher version number is a
indication of a product's true robustness, useability, or performance.
It is that if you label your product as alpha version 0.1, no matter
how good it is, it is an uphill battle for anyone to have it approved
by decision makers to be part of its set of corporate tools. It is
perceived to be far, far from finished.

<<
if i were competing in the web development arena i'd be quite
happy to let them keep working in their antiquated environments - it'd
be that
much more work for me :wink:

This view is very likely not shared by Ruby/Rails tool makers and book
writers. And, in any case, I have a feeling that it'd be for their and
the Ruby community's benefit if they fall for the lure of the lustre of
a red jewel than them falling into a nest of snakes.

gk

7

Oh, i'm not advocating the use of Oracle. I'm trying to find a way to
get Ruby in our corporate door. No matter how great the Ruby
application I develop for my company, if it uses a critical component
that is *alpha* and *version 0.1* for many years, it will never ever
get pass the door.

Then your management seems to have missed the point.

This is Open Source software. This means that what you get is what you get.
You get NO WARRANTY (in big capitals in all the licence agreements I've
seen). If it works for you, then great; if it doesn't, it doesn't. But it
doesn't cost you anything either.

If an Open Source person releases a version 1.0, or a version 0.1, you
cannot infer anything from that about the quality of the software. You can
*ask* the author how good he or she *thinks* the software is, if you like.
You can ask other users. You can test and evaluate the software yourself.
You can look at the quality of the coding itself and the documentation. But
the version number is totally meaningless.

FWIW: I used ruby OCI8 *heavily* in production at the place I left two years
ago. It's still working solidly there. I found the program author to be
extremely helpful, and when I managed to find a couple of bugs he promptly
fixed them (even though he said he wasn't really working on OCI8 much any
more)

Generally, you will find open source software authors err on the side of
caution and humility when asked to say how good their software is. OCI8 is
marked "alpha, but usable". In fact, I've found it to be completely solid.
If it were being sold as a commercial product, then of course the marketing
people would tell you it's wonderful (even if it were bug-ridden). Would you
rather hear that?

Version numbers like 1.0, 2.0 are marketing, nothing more.

Perhaps your company won't use OpenSSL, because it's version 0.9.8, but will
use OpenLDAP 2.3.4 ?? What about OpenLDAP 2.2.26, which is marked "stable"
by the OpenLDAP team? Does their definition of 'stable' match with your
definition of 'stable', and is this true for every other software project?

No matter how well that component works. If you work
for a company with strict standards, that's the reality.

Then it sounds like your company's policy will *only* allow you to deal with
commercial software vendors - those who will offer you a guarantee (at a
price). In which case, you don't need to engage the open source community at
all.

My point is
that it's time for the Ruby community to move away from the hacker's
lair and into, well, an office if not the boardroom. You need to dress
the dress, mate.

I can't speak for the author of OCI8. But I can speak for myself: I enjoy
releasing software, and it's nice to know that other people might benefit
from it, the same way as I've benefited from the huge amount of other open
software out there. It's nice to know that other people may find bugs (which
may save me time finding them myself), and even fix bugs for me. I don't
mind offering some support to those who need a hand-hold to start using it;
I have benefitted hugely from such support myself over the years.

But I care very little for commercial entities who wish to use my work for
free, *and* then denegrate me for the way I choose to release or number my
software - without actually taking the trouble to participate in its
development themselves. Sounds to me like they just want to take, and not
give. Well, why should I care about them?

< ... so they will with dbms as money gets tighter. ...>
And a mass exodus to MySQL and Postgres will ensue?

I've seen it happen, although clearly it doesn't happen in every industry.

Regards,

Brian.

···

On Thu, Jul 07, 2005 at 12:30:47PM +0900, Jenjhiz wrote: