Wow. Thanks for all the great replies. It looks like there's some interest in this project after all. I scoured sourceforge for other projects like this one and found lots of them but they all seemed to die on the vine.
I have to admit that I'm quite intimidated by OpenACS. It seems very powerful but very complex compared to the other tools I've looked at. I am not a programmer. I can write pretty good HTML and I'm learning PHP but that's about it. The tools I've examined so far have been more user-friendly in terms of setup and administration. They are: Moveable Type, pMachine, geeklog, Slash, and the various Nukes.
Each has strong points such as easy administration, decent to good user interfaces and theme tools, etc. Unfortunately, the all suffer from one huge problem: they're built from lots of unrelated parts and aren't designed to be used as a whole, homogeneous system. OpenACS seems to have the data structures to support what I want but it doesn't seem to be as friendly to non-geeks. This is important because my target audience ranges from 5-year-olds to great-grandmothers.
So, that said, let's talk some more about moving this thing forward...
History: not sure what you mean by history
I should have used a more appropriate term. What I meant was family history in the sense of stories, journals, images, movies, etc. The site would serve as a repository of the shared history and experiences of the extended family. Ideally, a registered user should be able to search for portions of that history and view it in the appropriate format - regardless of which portion of the site it belongs to. For example, a user's search query should be able (by option or by default) to encompass all sub-sites, blogs, galleries, etc.
photo galleries: no problem - photo-album module.
Admittedly, I haven't seen many OpenACS galleries but how does it look compared to gallery or some of the other tools out there? What I've seen so far has been bare-bones as far as graphic design is concerned. Should I assume that it can be styled like anything else?
new user registration: no problem - built-in
family-tree: needs coding. The old aD problem sets had a problem set based on this exact problem. And I built a solution, but it was for Oracle (using CONNECT BY). I ported it to PG, but using PL/PGSQL functios which are probably expensive. I uploaded my port to Roberto's Postgres cookbook. but I should try porting it to PG with TREE_SORTKEY
This is a big issue for me. The way I envision things, new user registration is directly tied to the family tree. New users should have to validate their ancestry (by selecting their parents from a list of pre-entered family members and other registered users) as a requirement for membership. In doing so, they are automatically adding branches to the family tree.
I have a lot to think about, eh? My first task is to d/l and install OpenACS on my OS X Server box and see what I can do with it. I'm anxious to move forward.
