Forum OpenACS Q&A: OpenACS 5.0 Package Inventory and OpenACS Governance

Towards the end of this thread started by Randy Ferrer there were questions about the obsoleteness of various packages. This reminded me that we need to examine the packages that we have for the upcoming OpenACS 5.0 release and I have therefore drafted a package inventory document.

You will note that the tables on the page are glaringly empty, and this is where I was hoping to be able to draw on the help of the community. Above all I am interested in knowing which packages people are interested in maintaining. Let me know if you need permission to edit the document (it is an Edit-This-Page). In addition to adding yourself as maintainer or clarifying what a package does, also feel free to make corrections, i.e. some package may be missing, or a package may be listed as service that is an application etc.

You might notice that I am referring to an OpenACS core team in the document eventhough formally no such team exists yet (informally one could argue it has existed all along). On the day after the Copenhagen OpenACS social there was a meeting to discuss OpenACS governance where Don Baccus and Jeff Davis presented three different examples of governance, those of the Apache, W3C, and Tcl/Tk projects. The recommendation was that what we need something similar to the Tcl/Tk core team and their process for managing patches and feature changes using maintainers and supervisors. I think OpenACS governance will probably be discussed in its own thread. I just wanted to mention it here and now as it is quite relevant to my package inventory list and the OpenACS 5 release.

For anybody who wants to be involved in shaping the governance rules for OpenACS I highly recommend reading TIP #0: Tcl Core Team Basic Rules. The document is written by John Ousterhout, it is quite terse and well thought through, and the OpenACS governance document will probably borrow many ideas, and also wordings, from it.

Posted by Randy Ferrer on

Peter - I think it's also important to make room in the repository for packages that may not necessarily meet all requirements for inclusion in an "officially maintained" repository which is what you seem to be getting at. There are other packages which might support Oracle or PG only, or developed outside of an "accepted oacs methodology" but would still be of interest to some members of the community.

It would also be nice to have a repository for obsolete packages which I think is being looked at implementing soon anyway.

I would like to maintain the two packages I wrote, namely acs-service-contract and search.
Thank you Peter (??) for updating the document. I forgot openfts-driver. I would like to maintain that as well. New versions of OpenFTS/tsearch have been released since I wrote that package so we'll have to wait until tsearch v2 stabilizes before I submit my changes (including better summarization -- like Google).

I'm currently in vacation in Central Europe but I'll post about my work in the past few months as soon as I return back home (Cyprus) -- either as RFCs or new packages.

thank you very much for stepping up to the plate and taking responsibility for those packages - very much appreciated. I am waiting for others to do the same and have already started making some qualified guesses regarding maintainer and obsoleteness of packages - be warned...

for contributed up-and-coming packages that may not be supported in both databases or haven't been properly tested by the core team yet we have the contrib directory. Packages that have been superseeded or are low in quality and lack maintainer will be phased out in the obsolete directory. A sub-quality package that gets a maintainer could be moved into the contrib package as there is a chance it could one day qualify in to the OpenACS packages directory again.

Posted by Jon Griffin on
Packages I am maintaining

acs-datetime - With Don B,

acs-reference et al.  - I will be updating some of the data for this release.

telecom-number - Complies with HR/XML standards
postal-address - ""
organizations -  ""

Posted by Jade Rubick on
I'm not sure if I like the title "obsolete". If a package doesn't have a person currently in charge of it, does that make it "obsolete". If so, then when someone steps up to the plate and takes responsibility for it, would it be then moved from obsolete to something else.

I'd personally prefer something like unsupported.

I'm not currently using Ticket Tracker, but this could be a good example. There are probably people out there using Ticket Tracker, and not wanting to switch. Let's say in the future they start to clean up the code, expand it, etc.. It wouldn't really be an obsolete package. They may even improve it to the point it would be blessed again.

Maybe I'm raising a stink that doesn't need to be raised. It certainly doesn't affect me much. If so, my apologies. I'd just suggest calling it unsupported, or something else.

Posted by Randy Ferrer on
Jade I do agree with the spirit of what you are saying. The work that others have done on older packages can sometimes be a source of inspiration for example. So, I'm very concerned that packages are visible and available for the community to explore and don't just get relegated to absolute obscurity. As long as deprecated, obsolete or as you propose unsupported packages are available for browsing and download, I think all of us will be happy.
Posted by Ben Koot on
Please confirm the following post:

Ben Koot on Apr 24 2003 17:16:40
Re: OpenACS 5.0 Package Inventory and OpenACS Governance

Jade ,
A good comment. I was wondering about that too. For example the postcard module. The functionality is what end-users like and may need. I have to admit the presentation at moment is minimal, but from a functional point of view we need it. I guess, a simple tweak will be sufficent to add the "Send picture as postcard" to the Photodb module.
- The functionality is saved
- Developers no longer need to maintain a seperate module.
- It's easier to understand for the end user
- It eliminates the need to write documentation for a seperate module.

I am sure similar integration is possible with other functionality, saves developers time, and increases userability. There's quite a bit duplicate features causing confusion to end users because of the seperate module concept IMHO.

Maybe it makes sense to create a "functionality directory" So How can I.... Non techies hope IT can help to solve simple problems. How sytem engineers make it work? ... they couldn't care less. I am using this approach on my site . As of tomorrow I will have my visitors add questions to the "whishlist".

Just a thought

Posted by Talli Somekh on
This may be a consideration for governance, but I'll bring it up here.

OpenFTS and ACS Service Contract are two important packages. It's great that Neophytos wants to maintain them, but he has taken off from the community twice before.

As a result, it might be good to consider other maintainers and have Neophytos be a contributer, at least for a certain period of time.


I'll continue to maintain:

- eCommerce
- Payment Gateway
- Shipping Service Contract
- Value based Shipping
- IRC Logger

and together with Janine Sisk:

- Payment Service Contract


Talli wrote:
"OpenFTS and ACS Service Contract are two important packages. It's great that Neophytos wants to maintain them, but he has taken off from the community twice before."

Well Talli, thank you very much for acknowledging *my* (that *I* wrote) contributions to the community but unless you remember I "taken off" from the community as you say for specific reasons (and I don't want to start that discussion here but if you want to that is fine by myself) which by the way is not true (that I have taken off) since I've been following both development and discussions since the year 2000.

Posted by Talli Somekh on
Neophytos, everyone respects your contributions, but you need to act more responsibly if you are to become a leading maintainer and contributer. Following development and discussions is not enough.

Disagreements occur. No need to start those things again. But withdrawing without fulfilling your stated responsibities and then expecting to return with full privileges again is not.


Talli, your opinion has been recorded so is mine.
I concur with Jade: "obsolete" means that something new is providing the same function.  I think the only stuff that should become obsolete in the near future is all but one each of the email, photo album, and other duplicated packages.  "Unsupported" for packages without a maintainer; "obsolete" for packages replaced by other packages.
Posted by Malte Sussdorff on
Quick questions:
  • What are the responsibilities of a maintainer.
  • How much effort is expected of this person.
  • Is the community (TAB) allowed to transfer maintainership even though the original author is the current maintainer.
  • What would be conditions for this.
  • Should we limit CVS access for maintainers of certain packages only to these packages (which would make it easier for newcomers to upload a package)?
Thanks for all the great feedback! I can't answer all questions right now, just give some quick comments.

I see how we could mark packages as unsupported and reserver obsolete for packages that are superseeded. My main concern is that someone who wants to use OpenACS to solve some problem has a clear picture of what packages to use and how.

I think it is best if everybody who is interested in working on and maintaining a package fills in the columns of that package himself. If you need access privilege to edit the page - let me know.


to address your concern, yes, I think a package should be able to have more than one maintainer (but maybe not more than three).

In Tcl/TK they have the concept of backup maintainers "who can step in when the primary maintainers are on vacation or otherwise unavailable.".

There is also a default maintainer for pieces of code for which nobody volunteers. Who the OpenACS default maintainer should be I don't know, someone in the core team (Jeff, Don, Lars...) would seem to make sense. On the other hand, since I am the proposer in all this I would volunteer for this role.

I would also like to point out that all developers in the community collectively owns / is responsible for all of the code, this is especially true of the kernel. It's just that being a maintainer for a certain package comes with some extra responsibilities as outlined in the Tcl/Tk document.

Peter, having secondary maintainers sounds like a good idea but it should be clear that the secondary maintainer should not get the credit for the work that the primary maintainer did/does for the package and vice versa.

Having said that, I should be a good fit for the secondary maintainer of the workflow package. I did ported the acs-workflow package to PostgreSQL in the past and did make sure that all ramifications to other packages like CMS, Ticket Tracker and Glossary were up to date (which did take a considerable amount of my free time).

Given this opportunity (and partly answering to  Malte's "original author" question): At the time I had finished the work on workflow package Lars (the original author of the acs-workflow package while at arsdigita) became active in the OpenACS community so I kindly stepped back without even asked for such thing.

Here are the relevant threads for my previous posting about the workflow package:

* November 19, 2001: ACS Workflow 4.3 release

* February 11, 2002: Lars is back

Peter, I've updated the document with the packages that have been claimed in this thread thus far. There are still a lot of packages that are unclaimed.

(Peter, I have not commited the changes, just in case you have some more to add.)