Forum OpenACS Q&A: Future plan for ACS/Pg

Posted by Karl Tsai on 04/19/00 06:27 PM

As ACS moving along in a fast pace (2-3 releases a month), I'm
wondering what's the strategy for ACS/Pg to keep up? The porting is
no doubt not a easy task and certainly not a process you guys would
like to get stuck with forever; correct me if I'm wrong.

So through my uninitiated eyes I can see 2 paths

1. Convince AD to move the ACS over from Oracle to Postgresql once pg
version is proven competative

2. Steer Pg towards Oracle to make the porting job as painless as
possible. Maybe also enlist some help through automated tools?

Of course manually re-porting ACS upon major releases, probably twice
a year may still be an option but this is rather painful.

Can someone shed some light on this please.

2: Response to Future plan for ACS/Pg (response to 1)

Posted by Roberto Mello on 04/19/00 06:36 PM

This question has been discussed a lot lately...

Ben is probably the best to answer this but I'll give my thoughts anyway...

I am sure aD would like to move to an open source RDBMS, as pointed out by Brent in his e-mail conversation with Lars. The problem is that there's no open source RDBMS to compete fairly with Oracle yet. Hopefully someday PostgreSQL will get there (and I wish some companies would fund the development of PostgreSQL so we could move it faster).

The most annoying thing about PostgreSQL right now is OUTER JOINS. If we could get that, porting would be easier.

If we had more active developers in ACS/pg we could assign a module to each developer and let him take care of it when aD changed something. That would make the job more distributed and easier.

I think ACS/pg will go on and will be very nice. It will be more popular than ACS/Oracle because it won't have the big bucks constraint. That means that we'll have more new modules built for ACS/pg (I personally have three projects in my mind already, will work on them in the summer).

What the ACS/pg community of users must understand is that everyone needs to take care of it and help it.

3: Response to Future plan for ACS/Pg (response to 1)

Posted by Ben Adida on 04/19/00 10:53 PM

There are many, many ways this could go, beyond those two possibilities mentioned. For example, we could convince aD to abstract their SQL out a little better to make our life much easier. Then porting would be much easier, and would certainly be worth the time.

At the end of the day, my motivations are:

- making ACS/pg solid and useful

- allowing outside contributions to ACS/pg in the form of easily installed and configured "modules" in the *real* sense of the word.

- having a good templating system to separate the roles of programmers and designers

- making porting to Postgres and *other* DBs, if not automatic, at least easier by providing some level of separation between Tcl and SQL.

These steps are just ways to make ACS/pg a true open-source system where many can contribute. I'm pretty sure most ACS/pg developers and users agree with this line of reasoning (but if not, please post to the ACS/pg Future forum!). The big question is simply whether ArsDigita wants the same thing. If what they want is close enough, we'll keep porting (and I'll keep doing this porting as long as I possibly can). If not, then we'll have to evaluate our options.

More on this very soon, just let me get all my facts together and I'll post something a bit more coherent :)

4: Who's driving (response to 1)

Posted by Karl Tsai on 04/20/00 12:10 AM

Ben,

Suppose aD suddenly desided to go close source, be it pressure from their VCs or whatever, your vision will make a lot of sense and I believe ACS/Pg will gather a lot of steam.

My feeling towards ACS as a software developer trying to build some different services on top of ACS is rather mixed: ACS is in a state of flux and new features' rolling out and old modules revamped all the time. On one hand I'm hoping they can move faster - there are so many things to do. On the other it will be hard to keep up with them on this pace if my stuff goes live. So for the mean time, my plan is to stay on the tail for as long as possible until I launch.

If you have similar feeling towards ACS, due to the fast pace, unless some of the things you mentioned happen, IMHO, ACS/Pg team may spend most of the time keeping ACS/Pg in sync with aD's release.

The other implication of the things you mentioned seems to suggest to part with ACS/Oracle and continue on your own path. Unless they go close source, this may not be a good news to the still (relatively) small ACS community.

This is why I think there are only 2 viable long term resolutions. Again just MHO.

5: Response to Future plan for ACS/Pg (response to 1)

Posted by Ben Adida on 04/20/00 12:20 AM

The thing that's important to realize is that any open-source community has a will and mind of its own. In this case, the ACS/pg community lives and develops in a direction that we, the core developers, control only insofar as we are in sync with what the whole community wants.

If aD provided a more modular system where developing for the ACS no longer depends on "keeping up" with them, then ACS/pg has every reason to follow ACS/Oracle and to grow into a very successful open-source system. This is what I hope will happen.

However, if aD doesn't do any of this, and we are stuck with massive porting every time they release a new version, you'll see two things happen. First, the core team will disintegrate as the tremendous fun of porting outer joins and poorly abstracted Tcl code wears out. Second, someone out there in the community will start a new and better ACS/pg that *will fork* and become the product the community wanted in the first place. That's how open-source works. Darwinism at its best.

So, in the *interest* of the ACS community, ACS/pg will probably fork if aD doesn't do enough to be in sync with its own community.

6: Response to Future plan for ACS/Pg (response to 1)

Posted by Ben Adida on 04/20/00 12:21 AM

and let me reiterate that I would *much rather* see aD open up to the open-source community than be forced to fork...