Slashdot Mirror
To Support, or Not Support Oracle?
knuckles79 wonders: "The suggestion to drop Oracle support has divided the OpenACS community. OpenACS is a toolkit for building community websites. It was derived from Ars Digita's ACS code base which originally supported Oracle. When Ars Digita went bust after the tech crash, the ACS code was released as open source, and a community of developers continued to maintain and extend the code base. Up until now, OpenACS has supported both PostgreSQL and Oracle. However, the only active development within the project supports PostgreSQL. Now, those with an interest in Oracle support are threatening to divide the community, as they want the community to continue to support Oracle, even though they themselves aren't actively contributing financial or development support for their favoured database. They have essentially been given a 'free ride' all this time. Should OpenACS continue to support Oracle, or drop it in favour of a full open source stack?"
That's the beauty of the evolution of open source software. Unneeded features that slow development can be dropped just as easily (if not easier) as new features can be added. If there is a strong enough demand for that particular feature, the users can maintain their own fork or pay someone to do it for them. No one should expect a free ride, let alone make demands on the developers.
One thing the users of the feature might consider is contacting Oracle. Let them know that the reason they are using their database is because of application X, and application X will soon no longer support Oracle. If this happens, they will no longer be able to continue to use Oracle. See if Oracle can devote some man-hours to contributing patches for their database.
If not, remember that you get what you pay for. You are shelling out $$$ for Oracle, but not spending any on your app. Consider an appropriately-sized "donation" to a project developer to keep the feature that keeps you in business.
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
The beauty of the OSS system is that if there is a wan, need or requirement, then it will ultimately be filled.
If people want to use OpenACS with Oracle then people will support it. Conversly, if there is no reason for it, it will be dropped and die.
The Free Market at work is a thing of beauty.
If the oracle users can't be bothered to scratch their itch, then let them languish with an old version. Maybe they'll fork that and learn how much effort the contributing users have been making on their behalf.
Same goes for all databases, not just oracle.
This issue isn't necessarily that the application "requires the strength of Oracle".
There will be many places where a particular organisation has invested time, money and resources to their Oracle installation for other requirements. If they already have Oracle and Oracle resources why not take advantage of that support in an application rather than learning PostgreSQL, MySQL or some other RDBMS and committing more, possibly stretched or unavailable, resources to another system.
In my experience it's not much harder to support Oracle if you are already supporting Postgres provided that you are using at least Oracle 9 and your apps is well designed to support multiple databases. At work I do some development on a Java-based CMS that has backend support for both Oracle and Postgres. All of the queries are in XML files that the developers call query catalogs. In the code we call queries by name, such as listUsers, and them populate the parameters before executing. Pardon me if this some standard Java technique. I'm still relatively new to Java and haven't seen this before.
Anyway, we have two query catalogs: "sql92" and "oracle". What's nice about the way the system is set up is that we put new SQL queries into the sql92 catalog unless we need to use something Oracle specific (very rare). In that rare case we write the sql92 query and then write an identically named query in the Oracle catalog with the Oracle syntax. When the system is configured to talk to Oracle, it looks into the oracle query catalog first and if it doesn't find the named query there it looks for it in the sql92 catalog. The result is that we can support both databases with minimal duplication. 99% of the queries are in the sql92 catalog. We've found that whenever you want to use an Oracle-ism then applying some thought will usually reveal another way to handle the problem that works in both databases. Example: using case statements instead of Oracle's decode.
Schemas are a different story. The datatypes and details are different enough that we have to keep two copies of the files to create the schema and the schema updates. However, these files aren't changed that much. Also, if you are familiar with Oracle's PL/SQL then Postgres's PL/pgSQL isn't much different.
Because of the way things are abstracted in our app it appears that it would be easy to add support for other databases as needed. It's sure been a breeze to support both Oracle and Postgres.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
Drop it. If something non-essential is stretching your resources too thin and there isn't enough interest to maintain it, it isn't worth it. I think it's really typical for programs like this to use a fully open source stack anyway. It would have been a different story if you were dropping postgres support for oracle. But in this case I think it is perfectly acceptable.
People always want lots of features. But sometimes you just have to decide what you have resources for.
If an officer ever threatens to taze you, say you have a pacemaker.
As far as I was aware, one of the major reasons of having open source was that if someone wanted or needed something, they could make it themselves. If someone needs a feature, it will be added by third parties wether the original writers wanted it or not. Whats so different here?
*runs*
How can a group of users who contribute nothing "divide the community"? They can go off by themselves, and nothing will happen.
Why is it people think that others are taking advantage (in a negative way) when someone uses Open Source, but doesn't have the skills to provide code back?
Ok, I admit that if the audience is big enough, and monetary donations are relevent that code is not the only way to contribute.
At the end of the day isn't it the idea that people are using it that matters?
As for supporting Oracle there are long-term advantages to supporting multiple databases; focusing on a single database allows for taking advantage of it's features, but at the expense of future compatibility with other databases, possibly tying the new versions to too many proprietary features making it diffiicult to support alternatives.
Isn't that the argument generally used when supporting multiple browsers. Supporting multiple browsers, and working towards standards has long term benefits.
Why is this being asked on Slashdot? If OpenACS is "a toolkit for building community websites," then the community at OpenACS's website should answer this. The link to the OpenACS forums shows there is already a large discussion happening people who actually use the system.
Why not? How about long term cost? From what I've heard, Oracle is neither cheap to acquire nor cheap to keep running. At some point you'll have to upgrade, and that will cost more money. The less stuff you have that needs Oracle, the sooner you'll be able to do away with it altogether, or at least reduce the number of CPUs needed in the Oracle server or whatever (you pay per-CPU for Oracle, right?). With Oracle, you don't even have the "I only know Windows" excuse, because nobody ever runs Oracle on Windows in a production environment (is it even possible?).
A reason not to phase out Oracle in favour of free software for things that don't need Oracle would be that you really can't concern yourself with long-term costs (e.g. if you're SCO). Another reason would be that you have literally one or two small in-house tools that are rarely used, and they happen to use Oracle.
Of course, the businessmen among you know that the real answer is to try to account for all the costs, benefits, and risks of each option, and then make a decision accordingly, but that answer probably won't get me mod points on Slashdot.
http://outcampaign.org/
You misunderstood my point.
If you already have a large investment in Oracle and associated resources (trained staff, infrastructure, support contracts) for an application requiring Oracle (for whatever reason) then it is more cost effective to utilise those resources than to retrain and allocate more infrastructure.
Adding another database to an Oracle database run by trained techs on Oracle specialised infrastructure is a lot cheaper than running another database system on that server (NO!) or dedicating another box to it. In addition, you then need to train your tech staff to understand and support that system as well.
In this scenario, the Oracle people get to have an Oracle module that is guaranteed to run within the application for a very reasonable period of time. Well, up until the time that so many functions have changed that there are no salvagable functions in the Oracle module. But that's not going to happen overnight and it gives the Oracle afficados time to reconsider what support they want to give.
On the other hand, because the Oracle code is extracted, the primary developers don't need to give a damn if they break anything in the Oracle code. They don't have to fix the Oracle code and as the code is now compiled seperately, it doesn't break the builds.
On the third hand, by exposing an API via a pluggable module, other people who might well be interested in providing such modules would be able to do so without ripping the code apart and making major changes. Ingres would be a reasonable candidate, now that it is Open Source, as it is pretty beefy. And IBM seem to be making some serious inroads with Linux versions of DB/2 and Informix.
It is a grave error to assume everything in computing is either/or. That may be true of bits (except when they're fuzzy), but it hasn't been true of programs for some considerable time.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
That seems to me to be the appropriate response to jumpy splitters.
Oracle can of course support their own database on the main distro, if they care, yes?
Got time? Spend some of it coding or testing
Because nothing says "free" and "open" like coercion and strong arm tactics!
8 of 13 people found this answer helpful. Did you?
..in more than one way. But my biggest gripe with it is that having an oracle client implementation in your app somehow makes it all of a sudden a non-'full open source stack'. Oracle's client can be downloaded for free; there exist native php, perl, java (that I know of) client implementations on top of that. The one in java is even completely without the use of native machine code. The SQL is free in that it is free of copyrights, patents and is extensively documented. Anything else is just none of your business, as a web-app builder. And, as another poster said: better keep multiple back-ends around, lest you go rely on back-end specific hacks. For me, that's enough reason to say: stick with oracle as well.
Religion is what happens when nature strikes and groupthink goes wrong.
then it is more cost effective to utilise those resources
Not necessarily. It depends on the time scale. Conversion costs are fixed. Infrastructure costs are ongoing. If the cost/benefit of the alternative is better at some point it makes economic sense to accept the short term pain of [partial] conversion for the long term gain of lower infrastructure costs.
This applies whether or not you can leverage existing resources. If you have existing resources available for the new task that means those resources were partially idle and being inefficiently utilized e.g. If the support contract does not increase in price when you take on the extra work that means you were paying too much before. Similarly if the existing box can support the new database without upgrade. New boxes are cheap incidentally.
Your argument makes some sense when considering economic network effects (e.g. 2 oracle DBA's may together give a better cost+benefit than a Oracle DBA plus a multi-vendor DBA) however this argument is often over-emphasised for typically one-off installations like databases. I've seen many businesses that spent way more than was necessary just to conform to an inefficient, self-imposed single-vendor restriction.
The argument also ignores the sometimes high cost of single vendor lockin. By having alternatives in your shop you can sometimes significantly improve the responsiveness and competitiveness of the vendor. It's no secret that vendors work harder for fence sitters than locked in customers.
---
Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.
And add MySQL. Most smaller servers run MySQL, and since it's used on both windows and linux servers, you will be getting many more users then with Oracle.
Great Intellect...
nobody ever runs Oracle on Windows in a production environment (is it even possible?)
Of course it is, why wouldn't it be? I'd be very, very surprised if anyone did, as using Windows Server would seem to imply using SQL Server for the db, but I'm not aware of any technical reasons why it wouldn't work. I certainly know people who run Oracle on Windows in non-production environments.
It's official. Most of you are morons.
Now, those with an interest in Oracle support are threatening to divide the community, as they want the community to continue to support Oracle, even though they themselves aren't actively contributing financial or development support for their favoured database.
Well, if they fork someone from their camp will be contributing both financial support and development. I really don't know much about OpenACS. Looking at the "Sites that run OpenACS" I really didn't see any sites that (in my professional opinion) require what Oracle offers over other databases, though that doesn't mean someone would want to use it.
Put it in the hands of those who want to keep Oracle support to in-fact keep that support. If they don't, then pull it out and let them fork. Or Ask Oracle to support it!
mind the lamp
If the application already has a basis for Oracle support, I can't see the logic of throwing that away instead of continue to support Oracle for new features. The monetary argument really doesn't hold water since Oracle 10g Express edition is free for development, deployment, and distribution, so developers could develop & test against Oracle syntax just as easily as Postgres.
I know that as a corporate sysadmin, I would love to make use of more open-source projects, but I'm not in a position to introduce more database engines into our environment, so most of the time I have to pass. We're an Oracle shop. If I can get an open source app that supports Oracle, fantastic. If not, I'm not going to install MySQL or Postgres just to run one application, so I'll go find something else or get it on our list of internal dev projects.
Keeping the Oracle support there only increases the project's potential exposure, and with Oracle providing a free version of the database, supporting it should not be a huge financial investment like it used to be.
That's for the developers to decide. They're the ones investing their time and lives. If they don't want to support it, then either someone else needs to support it, or someone needs to motivate them to do it, or the support goes away. Without knowing the developers and the community, I don't know what form that would take. Money? Toys? Jolt Cola for life? Ask the developers!
If the people forking out for Oracle can't find a way to motivate the developers, they'll have to switch databases, switch apps, or switch developers. If they're just too cheap (or too broke after paying for Oracle 8^) to help out, they deserve their fate. It's quite simple.
The easiest solution is to make it the choice of the users. The current developers can send out a message to the user community saying "We can no longer continue to support the Oracle backend without additional help from the community. We will continue to maintain it if one or more people commit to supporting the Oracle backend and can contribute in a timely manner. Otherwise we will need to drop support by YYYY-MM-DD."
I am willing to bet that most Oracle users are commercial users. This will give some incentive to those users to go to their management team and request resources to support the product that they use.
I'm willing to bet a few of the managers will ask, "Well, can we just move to this free database, PostgreSQL, when support for Oracle stops?"
the growth in cynicism and rebellion has not been without cause
Which would be people who enjoy making broad and uninformed claims about other people, and what they really need to do.
I Browse at +4 Flamebait
Open Source Sysadmin
Databases are not created equal. Abstraction layers are often more trouble than they're worth., and they encourage doing more work in code instead of letting the database handle the heavy lifting. I'm speaking as a veteren of Apple/NeXT EOF, Persistence PowerTier, CocoBase, Hibernate, Kodo, TOPLink, EJB 1, 2, and 3, and object databases such as GemStone. ADO.NET , as an example, has about the right level of abstraction one usually needs.
This is not to say thay are useless. They are productivity tools, and can be useful ones in certain contexts. But it's a complete misnomer that they should always be used, allow you to not know much about the database, or use the database as a dump object store.
-Stu
If the lead developers don't want to support Oracle, or anything else for that matter, then don't. If your userbase really wants Oracle support, then they can rally some developers together to help contribute to the effort. It's not the lead team's job to support things that are outside their areas of expertise or interest. If the feature has merit, someone will contribute. That's how the opensource ecosystem is supposed to work.
Users tend to have this misnotion that opensource developers are obligated beyond their already immense contributions. They don't understand that this kind of development is primarily a volunteer effort. The demands and expectations they have impose on the contributors' own personal time. I think it's best to let *developers* decide where there efforts are best spent and for users to be more grateful that the project even exists.
I run Oracle on windows in a production environment. SQL Server isn't even an option for us.