Forum OpenACS Q&A: Drop Oracle support
Due to the fact that most core developers do not have access to an Oracle server and not necessarily the time to test patches for Oracle (though we normally are able to write them), I'd like to drop Oracle support.
As a less drastic move I would be happy to see the TIP rules changed in a way that the requirement for *testing* on Oracle is dropped (I agree with the writing part).
Another thought would be to have seperate releases for Oracle and PostgreSQL. After all, "OS X" version of programms usually come out later due to additional testing and development, so why not apply the same model to OpenACS.
I know some folks think that Oracle support is a selling argument. So maybe those who do business with OACS should speak up. I remember Dave saying that there is a TCL-API to ACS objects available or was it for the content repository?
On the one hand there is no doubt that supporting Oracle is causing a lot of problems. Using OpenACS with Oracle these days is basically a crap shoot - what is going to break this time? And generally speaking the person installing it is on the hook to fix any problems that come up, since we already know the person who created the problems does not have an Oracle installation.
On the other hand, in some areas Oracle is a *huge* selling point. Many universities and larger companies out there have site licenses for Oracle and trained staff to support it. These folks will be reluctant, and sometimes completely unwilling, to install Postgres. We (furfly) are doing a fairly large project for the Army Corps of Engineers, and although I tried to convince them to use Postgres, the manager told me that due to internal politics it would be much better for them to use Oracle. If this change had been seriously under discussion when we landed that contract, we probably wouldn't have it. Big-name clients like this help the entire community, not just furfly, because everyone else can point to them to give OpenACS/dotLRN credibility.
I guess it boils down to this: dropping Oracle support will increase overall code quality, and will yield a big boost in programmer convenience/productivity if the xql files are done away with. Those are good things. But IMHO the community will be limiting the toolkit's appeal to mostly the middle and low end of the potential customer base. Although I'm sure there are exceptions, there are going to be relatively few large companies and institutions that are going to be willing to bend their IT rules to accomodate our decision. This is especially true in the US, where fewer IT managers have drunk the FOSS koolaid so far.
Personally, I would prefer to see some sort of quality standard that all commits have to meet, one aspect of which would be proper Oracle support. But that is clearly not going to happen any time soon. :)
In broad terms I see OpenACS as expanding from where we have been since the ArsDigita days…
1. a great platform that will cut 6 months off of your development time for a custom web application.
To also be:
2. A great the foundation for a set of complex, feature rich, "out of the box" applications that are immediately and directly useful for specific market verticals.
We are an open source project. As we move in a new direction we do it in a very distributed and diverse open source way. It doesn’t look and feel like a company that makes a plan and a roadmap and then executes against it. It looks like a thousand flowers blooming. Maybe some of them not so pretty, not so good smelling, and probably some of them die. I see dotFOLIO, dotKNOW, Project Open, dotLRN and even all the thread of people installing openacs and trying to install every package out there as all examples of flowers in this new field.
If we look at oracle support from this perspective. Oracle support in the platform world is a sellable, valuable thing with a good market nitch. If an organization needs to use oracle, for historical reasons, for political reasons, or because they need very close integration with an legacy and/or proprietary oracle app, then OpenACS is a great tool. This has been true for years and will remain true for some years to come.
What is new is the OpenACS is is in fact supporting a number of “out of the boxish” products. Our struggle is that we really not being able to take Oracle support with us into this new arena. If you look at this from an economic perspective this makes sense. If you have a free alternative and an expensive alternative for the same out of the box product why would you pay for oracle?
As we embrace and struggle with more out of the box usefulness lets not forget that we remain a great platform for custom web app development.
I think we need to separate Oracle and Postgres support. We can’t let oracle be a stone tied to the ankles of our products, especially during this critical thousand flower period as we find out what is and isn’t going to make it long term. However, what we have in Oracle is still valuable for some organizations. We just need to advertise it truthfully, yet with a positive spin.
The glass is truly half full, probably even three quarters full, if you want to develop a custom app using Oracle. If you expect to run the latest out of the box functionality on oracle without hiring a vendor or making a programming investment…well maybe the glass is not so full.
And here's a counter proposal: How about spending some time thinking carefully about just what makes supporting both Oracle and PostgreSQL difficut, and possible ways to make it easier, and then explain what you've figured out to us? Until that's done, don't you think dropping all Oracle support might be just a little premature?
I honestly don't know what the major stumbling blocks in efficiently maintaining support for both RDBMSs are, and I'd like to hear about them from someone who does.
Even for those who make the effort to get it right, xql files are a pain in the behind. I have complete sympathy for those who see no value in supporting Oracle and view the overhead of xql files as an unnecessary waste of their time. I have suggested in the past that since we're not likely to support more than two databases, it might make sense to pull all the PG queries back into the Tcl scripts, and only have Oracle queries in their own files.
I really don't know what the solution is. Having separate release tracks for Postgres and Oracle might work, but my gut feeling is that there are not enough Oracle users to keep the Oracle version in usable shape. I can tell you from my recent expeirences with project-manager and photo-album that it can be a *lot* of work to clean up after someone who only supports PG, and I'm not optimistic that there are enough resources out there to keep up with it, especially now that, as Carl said, Sloan is no longer going to be contributing significant funding.
A requirement for building better multi-db support is clearly to have an in-depth hands-on appreciation of the problems with the present support. To that end, I link to my proposal to Extend Forums to suport Email List archives.
I tried to download it, and never got farther than 25% before the download died, even though I have a great connectok 500KB per second download until then.
Next I tried to see if I could order a CD, but spend about a 1/2 hour navigating the Oracle online store before giving up until another day.
So if this is any indication, its not as easy as I would have hoped. Hopefully the actually install once I obtain it is easier.
Most core developers don't necessarily have extra free time to devote to Oracle support they, or their clients will never use.
Wouldn't this mean that we could drop it now :)
MIT Sloan is in minimal maintenance mode as far as I can tell and I _seriously_ doubt we will see any investment going into migration to Postgres.
UNED is a BIG installation that just recently upgraded from ACES to .LRN and they are using Oracle (I am sure some of you noticed Emmanuelle's contributions over the past few months). Anyone from UNED have something to add here?
Are we talking about core support for Oracle or are we talking package support?
Can't we just dichotomize the new QA tags for Oracle/Postgres and label packages so they reflect reality for Oracle and be done with it? This way if someone wants to, they can go back and work towards moving the lagging behemoth forward (people are much more likely to help laggards than they are to help those that have been expelled).
We have a lot of dark matter (invisible but interesting sites/institutions) using Oracle with various versions/branches of OpenACS. If this is about core and there is a relatively clear path to simplified Oracle support (e.g. slight increase in DB abstraction), I am sure it would not be hard to get funding for it (assuming there is someone willing to do it). The .LRN Consortium could serve as a place to combine funds to make this possible (again, assuming there is someone willing to do it and a champion willing to put time into oversight).
P.S. They say that 90% of the universe is made up of dark matter: http://en.wikipedia.org/wiki/Dark_matter
This would only work if someone helped test and get releases prepared for Oracle.
The situation at UNED is the following: As Carl said, we've just migrated from ACeS to dotLRN and we are using oracle. We choose to go on with Oracle for many reasons, some of them are: it is the database used by the University IS so it is easier to do the integration with it, we have legacy developments on ACeS/oracle that we included in our dotlrn installation, our team has experience with Oracle. We don't discard to move to postgresql but not in a short term, at least, not this year. First we have to improve our new dotlrn installation to fit university needs.
I'm not sure that having 2 different release processes or schedules for oracle and postgresql would be a good solution. There's a risk of fork. I don't have the solution neither but what we can offer from Uned is some human resources for testing and debugging dotlrn on oracle.
I look at it as a resource issue, pure and simple. Those who claim to want Oracle support have not, in practice, been willing to either take it on or pay for others to do it. They've wanted a Free Ride, in many cases.
In fact, when I raised the issue in Madrid, a spokesperson from one of the universities using .LRN (not Heidelberg, not Sloan) said "well, we use Oracle because we have a site license, therefore it's FREE".
Well ... it's only free because a handful of us have continued to fix Oracle problems on our own time, unpaid.
I've taken the uncivil step of telling people I will no longer help test or fix Oracle releases unless I'm paid to do so. I'm not trying to be mean, just practical.
It sounds like that faced with Oracle support disappearing, at least a handful of folks in the community are willing to step forward and lend a hand. That's great. If supporting Oracle doesn't cost those of us who only use Postgres time and money, I doubt any of us will care if Oracle's supported.
BTW we have, in the .info file, the means to state "this package only supports Postgres" (or Oracle). That's not an issue. If someone extends a package for (say) PG and breaks Oracle, they should remove the db tag for oracle from the .info file. They should probably announce what they're doing so someone from the Oracle community can pick up and fix the package if they so choose (as Janine has chosen to do with project manager, for instance).
As far as comments like "I honestly don't know what the major stumbling blocks in efficiently maintaining support for both RDBMSs are, and I'd like to hear about them from someone who does."
Well, it should be clear that testing for two RDBMS's takes twice as long a testing for one RDBMS. Add to that the overhead of maintaining query files and the fact that there are really large differences in any hierarchical query (just one example) and you see that supporting both is non-trivial. Supporting both is probably about 35% harder than supporting one.
The need to do so is, in essence, a tax ... with the web development industry being much more competitive than it once was - $300/hr contracts appear to be a thing of the past - it's becoming harder and harder to pay that tax.
Folks might want to keep in mind that I (along with Ben Adida) was the originator of the notion of supporting both RDBMS's. Our support for OpenACS 4 began as a PG port only, but from almost the very day that aD announced they were dropping ACS Tcl our project announced we'd figure out a way to support Oracle as well as PG with our port of ACS 4.
And I did the hacking on the boostrap/installer, APM and other components that guaranteed that our first release of OpenACS 4 would support existing ACS 4 custom packages without any modification whatsoever.
I only point this out to make certain that folks who might be newer to the project understand that my wish to drop Oracle support is a huge turnaround in my original position.
Regarding Oracle and institutions/companies ... PG is making significant headway in that regard, as of course is MySQL. And SQL/Server for that matter ...
So I don't see it as being as huge a marketing advantage as it was six years ago. Large, yes, just not AS large.
As for Oracle, I had a painful experience installing oracle 8 on linux 4 years ago. I installed it, but I haven't used Oracle since. I haven't come across many clients that prefer Oracle over PostgreSQL, so I've been lucky. :)
Many of us prefer PostgreSQL for reasons that have nothing to do with money, BTW.
Do you know if OpenACS will install on Express Edition? I suspect it doesn't include full text search though.