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?"

Comments

Drop it

[SeanTobin]

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.

Re:Drop it

[Anonymous Coward]

Exactly. If your application uses a database only to persist objects and doesn't use a persistence layer like hibernate, jdo, or jpa to automatically support a bunch of databases; your application is probably crap anyway. Drop support for Oracle, and encourage those users to move on to something better than OpenACS.

Re:Drop it

[Anonymous Coward]

LOL! knuckles79 tries to get publicity for his boneheaded project by posting a trivial problem, and you're the only person so far who made fun of him for it. Good on you.

Re:Drop it

[Decado]

That's the beauty of the evolution of open source software.

And also the horrer of open source software. 2006 and people are still developing code without a database abstraction layer. That is so ridiculous as to boggle belief in this day and age. Ok, we all know the developers are working for free but if they cant simply abstract the database code (and lets face it, we are talking Postgres and Oracle here, it isn't exactly a minefield of interoperability issues to do that) they probably wouldn't be able to get paid for the work anyway.

Re:Drop it

[rsborg]

And also the horrer of open source software. 2006 and people are still developing code without a database abstraction layer.

Do you know how expensive it is to abstract away differences in database syntax (especially when large companies like Oracle make significant ca$h intentionally making their syntax different/nonstandard)? If you think it's so easy, perhaps you should write it yourself for OpenACS instead of bitching about why it's not there...

Re:Drop it

[Decado]

Do you know how expensive it is to abstract away differences in database syntax (especially when large companies like Oracle make significant ca$h intentionally making their syntax different/nonstandard)? If you think it's so easy, perhaps you should write it yourself for OpenACS instead of bitching about why it's not there...

Both Oracle and PostgreSQL put a lot of effort into standards compliance. Contrary to your unfounded claim Oracle has better standards compliance than pretty much any other database out there and has always been the benchmark against which other databases are judged, I will be very surprised if you can point to any reputable source that claims Oracle deliberately violates SQL standards.

In fact Oracles implementation of the SQL-92 standard is better than PostgreSQLs, better is probably the wrong word, more feature complete would be more accurate since both databases are highly compliant where they implement the standard. They do differ somewhat in the various implementation defined parts, but that is mostly to do with data definition and not the normal query/update syntax where both oracle and postgresql behave very closely.

Re:Drop it

[TheLink]

When I last checked in Oracle a zero length string = null

That's a biggie (and stupid IMO).

Not sure what happens if you concat a string with a null or do other similar stuff.

Then there's DECODE.

Re:Drop it

[cerberusss]

2006 and people are still developing code without a database abstraction layerThat is so ridiculous

I assume you are a developer. If you have more than 2+ years experience, you really shouldn't be saying this.

Lots of projects have a history and start with an itch. And when starting with, say, 15 screens in mind, I'm not going to set up a database abstraction layer. However, the project can grow beyond those initial 15 screens. In that case, yeah it might have been better to layer the DB away. But that's history.

Also, lots of people happen to like the versatility of plain ole' SQL. They just use Perl's DBI or PHP's MDB. Layers where they can still use SQL.

Re:Drop it

[big ben bullet]

I assume you are a developer. If you have more than 2+ years experience, you really shouldn't be saying this.

Lots of projects have a history and start with an itch. And when starting with, say, 15 screens in mind, I'm not going to set up a database abstraction layer. However, the project can grow beyond those initial 15 screens. In that case, yeah it might have been better to layer the DB away. But that's history.


Wrong! You just gave the best argument one can think of to ALWAYS write a database abstraction layer.

It doesn't even have to be all that abstract either. Just make sure all data access is done in a separate replacable layer (your 'data access layer'). If the application needs to support another dbms in the future just write a new dal and that's it.

Or... you could use an orm thingy like (n)hibernate, but thats a completely different story.

Re:Drop it

[markhb]

Plus, AFAIK, Ars Digita didn't start as an "itch" so much as a commercial venture; one of the founders discusses his POV here. My point being, that "scratching an itch," while it may make a passable excuse for poor design in a small (initially) private project, shouldn't apply when you're bringing in over $1 million/month in revenue.

Re:Drop it

[Anonymous Coward]

Contrary to your unfounded claim Oracle has better standards compliance than pretty much any other database out there and has always been the benchmark against which other databases are judged, I will be very surprised if you can point to any reputable source that claims Oracle deliberately violates SQL standards.

I have mod points, but I have to reply. Ways in which Oracle violates (or doesn't fully support) SQL:

1) Zero-length strings ("") are stored as NULL.

2) Doesn't (didn't? supposedly fixed in 9i) support SQL-92 syntax for { LEFT | RIGHT | FULL } OUTER JOINs. Yeah.

3) Lacks support for SQL transaction isolation levels other than READ COMMITTED and SERIALIZABLE. This kills performance of EJBs (which already suck).

4) Doesn't correctly support SQL92 TIMESTAMP, DATE, or TIME fields. Oracle has DATE which corresponds to TIMESTAMP, but nothing like the other two fields -- this makes separate columns for DATE and TIME impossible.

This is the top-of-my-head list of things we had to abstract away just for Oracle's sake. Then there is the nightmare known as the Oracle BLOB: is it small enough to fit in a LONG RAW, or should we abstract away the entire mechanism to use real BLOBs (since ResultSet.getBlob() doesn't actually work)?

DB2 and even Cloudscape worked correctly out-of-the-box.

Re:Drop it

[Doctor Memory]

2006 and people are still developing code without a database abstraction layer.

My impression was that ACS was built using mostly stored procedures. Kind of hard to abstract away your execution environment...

Re:Drop it

[Decado]

Maybe I wasn't being clear, the whole purpose of a database abstraction layer is to manage all these issues. They are only an issue if your code is too closely coupled to an individual database.

1 is the kind of issue that can be readily managed through a database abstraction layer, having code where '' and NULL differ is a bad idea anyway which is why so many programming languages treat them as the same anyway.

2 and 3 are all fixed since 9i as far as I know, technically oracles READ UNCOMMITTED and READ COMMITTED transaction isolation levels are identical since its internal structure means there is no difference between them.

4 again is data access layer solvable.

I'm not sure what people expect, if everything beneath your database access layer was going to be the same for all databases then you wouldn't need one. All these issues can be solved and have been solved on many projects. If their SQL code is so thoroughly embedded in the app that its easier to fork it than it is to put in a database access layer then thats what they have to do, but if that is the case then it is most certainly a case of being very badly bitten by an avoidable design flaw.

Re:Drop it

[Anonymous Coward]

1 is the kind of issue that can be readily managed through a database abstraction layer,

NULL means something very specific and is absolutely necessary in many places, including strings. Does the user not need to enter a string at all (use NULL), or did they deliberately skip the input field (use "")?

More practically, if you want a database to enforce proper integrity, you simply cannot have empty strings in Oracle. You must either never use CONSTRAINT NOT NULL on a column (yuck), or you must write your application to mangle all empty strings into some string that *means* "empty string" (we initially used "__ORACLE_SUCKS: EMPTY STRING IS NOT NULL__").

Regardless, not being able to support tri-state logic is a gaping hole in SQL compliance. MySQL does this too and people laugh at it, yet Oracle gets a walk.

having code where '' and NULL differ is a bad idea anyway which is why so many programming languages treat them as the same anyway.

Which programming languages coerce "" into NULL? I know these don't: C, C++, Java, Lisp, Kornshell, Perl, VB.

4 again is data access layer solvable.

If you are working with an enormous data warehouse, and you want fast queries on the join tables, and your users need reports that aggregate by day/week/month, then you need a DATE field at the SQL level. Then you can have the server do all the complicated aggregation hundreds of times faster than a data abstraction layer can manage it.

Re:Drop it

[Jeff DeMaagd]

A code fork does need someone to develop and maintain it. If the description is right, the people that won't support that development with money or code really can't do jack about it but complain. I think it's funny that people will pay for Oracle software but not for software that uses Oracle.

Re:Drop it

[marcosdumay]

We have standard SQL for years now. The only problem is that nobody seems interested on fully implementing it, and Oracle seems to want very hard to break it.

Of course, if you want to do anything that standard SQL can't do, you can't have plataform independence also.

Re:Drop it

[Decado]

NULL means something very specific and is absolutely necessary in many places, including strings. Does the user not need to enter a string at all (use NULL), or did they deliberately skip the input field (use "")?

A very good example of a very bad way to use null. A programmer using NULL as a non-entered optional field, '' as a non entered required field may think he is being very clever but it is either a design error (the field shouldn't be required since you are allowing blank values) or a bug (the programmer is using syntax tricks to get around the required field criteria). Of course it is easier to use '' to trick the database or better yet make an arrogant alternative that implies that the programmer is more l33t than the database than it is to do the right thing and go back and make the user actually enter a value for the required field.

Laziness at the data validation level leads to headaches wherever you use the fields later, in SQL NULL is not equal to NULL, so a NULL state field in a users address wont match another NULL state field, and so a guy with NULL for state has no people living in the same state as him but someone with '' as a state has all the other people with '' living in the same state as him. You are forcing every subsequent query to manually check "WHERE field IS NOT NULL AND LENGTH(field) 0" whenever they want to get people with that field set. Whether the field is required or not should not be determined by whether it has an '' or a NULL for blanks, that is a part of your business logic and shouldn't be information you store in the database. Don't get mad when your clever hack to make an end run around the design isn't allowed. Bite the bullet and fix either the design or your input logic.

Also you still don't see that even if you wanted to support the messy tri-state hack you suggested that is something you can do once in, yeah you guessed it, the data access layer and it will never bother you again.

Which programming languages coerce "" into NULL? I know these don't: C, C++, Java, Lisp, Kornshell, Perl, VB.

I didn't say coerce, i said treat them the same. Perl treats empty strings as logically false as do most scripting languages, C treats them as true. A database treats empty strings as logically true.

Finally I won't even bother to dignify an AC claim that Oracle is not usable for "an enormous data warehouse" with a response. Classic programmer arrogance, you don't know how to do something with Oracle, therefore oracle sucks. Whenever I hear a programmer claim "i could do x, y, z except the tools hold me back" I know its time to find a different programmer. If you are talking databases and the tool you have is Oracle then there isn't a team lead alive that wouldn't laugh you out of the room. Grow up, learn to say "I don't know how" instead of "it can't be done".

Re:Drop it

[Ed Avis]

I used to work at ArsDigita and programmed using the ACS. In my opinion the lack of a database abstraction layer is its best feature. It is not often hard to write scalable and simple database code when you have a layer that hides the true queries being sent to the database.

However, OpenACS does take care to keep the SQL code cleanly separated from the program code (in Tcl) or the HTML templates. If you want to make your app support both Postgres and Oracle, you can have two files giving the SQL to use for each database system. Nowadays when standard ANSI SQL 92 is fairly well supported by almost all databases, this is less necessary.

Let the Market decide

[CelestialWizard]

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.

fork away

[bugi]

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.

gah who gives a shit?

[Shut the fuck up!]

Name one open source project that requires the strengths of Oracle. Oh, wait, there aren't any.

Re:gah who gives a shit?

[CelestialWizard]

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.

Re:gah who gives a shit?

[Schraegstrichpunkt]

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.

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.

Re:gah who gives a shit?

[CelestialWizard]

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.

Re:gah who gives a shit?

[Shut the fuck up!]

Bullshit. Postgres/mysql are cake walks to run compared to Oracle. Plus, whatever hardware you have dedicated to your oracle database - divide that power and price by 10 and you will get the same performance with postgres or mysql. And they are not going to need a full time dba to babysit it. In addition, that additional box is not going to cost you another yearly Oracle processor license.

Anyone who uses Oracle in a situation where it is utterly unneeded is a complete idiot. It's like hunting pheasents with a Blackhawk helicopter.

Re:gah who gives a shit?

[bit01]

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.

Re:gah who gives a shit?

[Tim C]

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.

Re:gah who gives a shit?

[bryhemm]

I run Oracle on windows in a production environment. SQL Server isn't even an option for us.

Oracle support isn't much different from Pgsql

[Matt Perry]

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.

Re:Oracle support isn't much different from Pgsql

[Anonymous Coward]

The inner workings of this is not revealed, but it sounds awful. In Oracle it is a must to bind variables, i.e. use prepared statements, or the db app will not work good.

Re:Oracle support isn't much different from Pgsql

[MagicM]

Oracle 9i supports case statements as well.

Re:Oracle support isn't much different from Pgsql

[Matt Perry]

Oracle 9i supports case statements as well.

Yes, I know. My point was about not using Oracle-specific syntax and using SQL92 compliant syntax instead. Case statements and Oracle's decode function both do the same thing, but case statements work in nearly all databases whereas decode only works in Oracle.

Some seasoned Oracle people will still use the old syntax out of habit. But as I said in my original post, if one does some investigation there is usually a SQL92 compliant way to accomplish something where you would have used an Oracle-specific way before.

Our biggest headache before Oracle 9 was supporting Oracle 8's non-standard syntax for outer joins. That meant a lot of duplication between our query catalogs. Oracle 9 supported the standard syntax and we were able to remove most of the Oracle-specific queries.

Re:Oracle support isn't much different from Pgsql

[Matt Perry]

The inner workings of this is not revealed, but it sounds awful.

I didn't write the inner workings. It's communicating with Oracle or Postgres via JDBC and using prepared statements for both.

Re:Oracle support isn't much different from Pgsql

[MarkLewis]

This is pretty much exactly the route that we take. A generic XML file, with per-database overrides if necessary, and keeping the schemas in separate files because they're different but don't change much.

In addition to Oracle and PostgreSQL, we also support SQL Server and IBM's UDB. Supporting Oracle and PG together is almost trivial, because underneath the hood they both use similar concurrency control methods. But don't be fooled into thinking that supporting other databases will be simple.

For us, the biggest hurdle with other databases is transactions; old-style database systems like SQL Server and DB2 use hierarchal escalating locks to manage concurrency, and if you use non-trivial transactions and have any degree of concurrency in your system, you'll geat the dreaded SQL Server error 1205 (or DB2's -911). If you read the MSDN for this one, it basically says that you need to rearchitect your data access layer to support their stupid locking system. I'm sure that SQL Server is a decent database if you design your application around its limitations to start with, but transitioning from Oracle/PG you'll feel some major pain here. SQL Server 2005 is supposed to have somewhat mitigated this, but it's still too new for us to really look into supporting it.

Also, you'll find a lot of other quirks. SQL Server doesn't support sequences, it doesn't support ON DELETE SET NULL, nor does it support ON DELETE CASCADE as well as other databases; in non-trivial schemas it will refuse to create the constraint. SQL Server's UNIQUE constraints are weird when it comes to NULL handling and don't match either the spec or the behavior of any other database I've seen. I still maintain that the locking behavior in UDB and pre-2005 SQL Server bad enough to be considered a design bug (to its credit, I believe DB2 predates MVCC so IBM at least have an excuse). You may notice that I like to slam on SQL Server (who actually PAYS for this crap??).

PG and Oracle have their quirks as well, but they're more in the details and less fundamental. Oracle can't tell the difference between an empty string and NULL, and PG . . . . well, PG is like Mary Poppins, practically perfect in every way :)

Drop Oracle

[porkThreeWays]

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.

Re:Drop Oracle

[KiloByte]

And those who can afford the money for a system that is for most cases inferior anyway, can obviously afford to pay for Oracle support.

Oracle, compared to Postgres, is:
about as fast[1]
con: prohibitely expensive for own use
con: can't be used for replicated software at all[2]
pro: handles big clusters better
con: criminally memory-hungry
con: requires a dedicated DBA just to keep it running[3]
pro: can be used as a ploy to give executives a bonus[4]

[1]. In fact, in most cases Postgres is FASTER. It takes some cherry-picking to create tests which "prove" Oracle's superiority -- so guess why Oracle forbids publishing any unapproved benchmarks?
[2]. One of products of our company, a HR system, is priced at $600, another one, invoicing+stocks, #330 (Poland, so it's way less than it would be in the US). A glance at Oracle's pricing shows that they start at $5000 for the minimal license. This isn't just "expensive", this is "no business".
[3]. If one system needs separate staff for basic operations, and the other just works, which one is better?
[4]. I guess this is pretty much the only reason to use Oracle, ever. And in that case, you do have the money to donate a bit to the Free Software project that handles your mission-critical app, and frankly, the donation needed will be lost in underflow for you.

Re:Drop Oracle

[kurtdg]

[2]. One of products of our company, a HR system, is priced at $600, another one, invoicing+stocks, #330 (Poland, so it's way less than it would be in the US). A glance at Oracle's pricing shows that they start at $5000 for the minimal license. This isn't just "expensive", this is "no business".

That's incorrect, or at least not the whole thruth. First, there's the free Express Edition. Second, Standard Edition One is either $5000 per processor or $150 per user (minimum 5), whichever you choose, which is probably the lowest number.
That's list price. If you ship it embedded with your app, you'll pay far less. If you buy lots, you'll also pay quite a bit less per piece.
Not that _I_ would consider embedding Oracle in a $600 app unless I was _very_ sure that it would never exceed the limitations of Express...

[3]. If one system needs separate staff for basic operations, and the other just works, which one is better?

I'd agree that PostgreSQL has become quite easy to maintain these days. Autovacuum in particular has been a nice improvement. As for Oracle... sorry, no time to comment on that. Too busy with the Oracle client security updates they recently released...

OTOH, the feature set is still not quite the same. Flashback queries, RAC, feature-complete GUI, etc.
(Yes, PostgreSQL has GUIs too, but I've tried most of the free ones, and they are worthless. They crash and burn every five minutes, or generate incorrect SQL, or do not support all data types, or do not generate DDL, or a combination of the above.)

Does It Matter?

[LuNa7ic]

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?

Huh?

[countach]

How can a group of users who contribute nothing "divide the community"? They can go off by themselves, and nothing will happen.

Re:Huh?

[flooey]

How can a group of users who contribute nothing "divide the community"? They can go off by themselves, and nothing will happen.

The community around a piece of software consists of both its developers and its users.

Re:Huh?

[BSAtHome]

But the point being, if you do not contribute, you cannot expect anything.
Otherwise, you need to pay me just for being here and I demand it...

'taking advantage of'

[topham]

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.

Re:'taking advantage of'

[Solra Bizna]

Most of the time, in the F/OSS world, the people writing the code are under no obligation to continue doing so.

This is, at once, the one great strength and one great weakness of the paradigm.

This comment was on topic until it went from my brain to the keyboard.

-:sigma.SB

Re:'taking advantage of'

[LordLucless]

Well, they are taking advantage. However, the people they're taking advantage of are more than happy to help them out. However, these people aren't just using the product in question, they're demanding features from it. Feel free to use what people give you, but if you want to start making demands, then you need to start making some contributions - money or code are generally favourite.

Re:'taking advantage of'

[black mariah]

Because open source twits are hypocritical douchebags. "We want you to use our software! It's so great! Happy happy software for all! But only if you can code. And if you use the GPL. And only if you use GPL v3, none of that DRM and patent enabling v2 shit. And you can't like ESR. And you can't like Red Hat either. They make money, you know?"

Retarded shit like that's why I abandoned Linux after using it for three years. I find the single-mindedness that comes with Windows very appealing. "Gimme money. I don't give a fuck about anything else, just pay me." No bullshit politics with your software.

Re:'taking advantage of'

[boneshintai]

Feel free to use what people give you, but if you want to start making demands, then you need to start making some contributions

The key here is in the word "demand". Asking for features is a contribution in and of itself, but demanding features and complaining if you don't get them, without putting energy into making them happen, is just being a brat.

Target audience?

[jasonla]

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.

Re:Target audience?

[Frumious Wombat]

Because of the real-world equivalent of the one good moment in Attack of the Clones, "If it isn't on Slashdot, it doesn't Exist."

Maybe, maybe not

[jd]

Why would you need to drop Oracle support? If the code is split from the primary codebase, a well-defined API is drawn up that allows a dynamic module to be loaded at runtime, and some sort of exception-handler is set up so that incompatiable or absent routines don't blow everything up, then you get the best of both worlds.

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.

Support Firebird, D3 (Pick) and MySQL not Oracle

[leonbrooks]

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?

Limit choice!

[lisaparratt]

Because nothing says "free" and "open" like coercion and strong arm tactics!

Keeps you honest

[cerberusss]

I would keep supporting it, since it keeps your code 'honest'. No dirty shortcuts just because it happens to work on PostgreSQL but instead a nice clean layer that keeps the queries out of the code. However, the submitter seems to have his opinion already:

They have essentially been given a 'free ride' all this time

I mean, isn't the whole open source thing about everyone getting a free ride?

Re:Keeps you honest

[mrchaotica]

A agree -- keeping a good abstraction layer is important, and ideally they should be able to support not only Oracle and Postgres, but MySQL etc. too.

However, that doesn't mean that it's worth maintaining the particular Oracle-specific glue code that's used in that layer...

The writeup is misleading

[bytesex]

..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.

Drop Oracle...

[bky1701]

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.

Drop oracle

[mtjs]

I don't like them. Period. (ps: seriously... why is this on slashdot...?)

Ask the grand Oracle...

[C_Kode]

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

[paughsw]

mind the lamp

Why not support Oracle?

[ErnieD]

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.

No brainer.

[Roadkills-R-Us]

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.

Make it the choice of the users

[Rob Riggs]

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?"

But you've forgotten /.'s target audience!

[xenocide2]

Which would be people who enjoy making broad and uninformed claims about other people, and what they really need to do.

database abstraction is often a myth

[Stu Charlton]

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.

Drop it

[pestilence669]

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.