My estimate is that Oracle support adds about 50% overhead to the ongoing maintenance of a package. Less for new development.
We used an automated convertor when first porting ACS to the OpenACS dual-RDBMS support environment. For ongoing support, it's not as big a win as you might think because the tricky things can't be automatically translated. Anything that has to do with the tree structure of objects, in particular.
Now, at the same time we've been talking about dropping Oracle support, we've been moving more and more of the API into Tcl. Use of Tcl API makes support of Oracle easy during development.
BUT, as you well know, adequate testing takes time. Automated tests only take you so far.
There's also the administrative overhead of managing releases and the like.
Now, the current .LRN 2.2 release has gone well for both Oracle and PG. That's because we have ORACLE CONTRIBUTORS WILLING TO DIRTY THEIR HANDS ALONG WITH US INCOMPETENT "HOBBYISTS".
You guys step to the plate and help out, then Oracle support needn't end.
The dialogue over the past two years has taken the following form:
IF Oracle users don't step forward and contribute to Oracle support THEN we will probably drop it.
No one steps forward.
Repeat: IF Oracle users ...
No one steps forward.
OK, we'll drop Oracle support in, oh, a year or so, since no one cares enough to help support the platform.
SCREAMS OF PAIN AND ANGUISH! Oh Lord, we've stabbed you in the back!
