Forum OpenACS Q&A: Re: Template contract for OpenACS projects

- I find the following statement a little too strong:

"However, the copyright holder (enjoying guardianship, if not ownership, of the open source code) is obliged to maintain the code in the OpenACS environment."

as it might be taken to mean legal obligation. Also, there is no clearly defined ownership sctructure for OpenACS software, at least not tied to any sort of obligation. Contributors and companies come and go but the code lives on.

- "Under no circumstances will a new package be accepted as an OpenACS package until it has documentation."

This statement is simply not true today and never has been AFAIK. It may be an ideal worthy of aspiring to but it's not a claim we should make presently. Can you soften this sentence a little?

- "The universal aspect of an OpenACS project business relationship is that the COMPANY provides highly specialized code development services (not products) paid by the CLIENT."

I'm not sure what you mean by "highly specialized" but I'm not convinced this is a universal aspect of what we do. Rather, the emphasis is on generic code that is useful to many parties. Examples of such projects include I18N, workflow, and time logger.

- Your section about business relationship layes down sound principles about communication confidentiality etc. However, none of this is strictly speaking related to OpenACS. I guess I am not comfortable with the idea of bundling a web platform like OpenACS with a certain business practice not to mention trying to enforce such a practice. You can recommend or even dictate business rules to your clients, but don't do so under the name of OpenACS - I find it confusing.

- "When the project starts the CLIENT shall make a public announcement of this in the community forum on the OpenACS website.".

This is really an excellent guideline that I wish all projects would follow! If community involvement was bigger we could reach much higher levels of reuse and synergy. Again though, I would soften the language and say "should" instead of "shall", "are encouraged" instead of are "obliged" etc.

- "The COMPANY shall post an initial RFC to the forum, and from then on weekly or biweekly status reports, continuously (intermittently) commit the development code to the development branch of the OpenACS CVS tree, and in general refer development issues to the open forum, where community members can offer answers, suggestions, comments, and other feedback."

Once again, I couldn't agree more with the spirit of these sentences. However, as general guidelines, I think there is a too high level of detail here. The frequence of reports and which branch is used may need to vary from project to preject.

The general problem I have with your documents is its lack of cohesion stemming from it trying to cover at least three somewhat unrelated things - the GPL licence, sound business pratices of a consulting company, and desired behaviour within the OpenACS software project (how we want the community to function). Also, I would like the document to have a more positive encouraging tone rather than the dictating tone of a legal text. I guess the purpose of the document is somewhat unclear to me.

Ok, that's enough random rambling from me 😊 I hope I don't come across as overly critical as I really want to applaud your efforts and I hope that my feedback gives you some new perspective and ideas for improvement.