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

The other day Dr Phil explained that the difference between a dream and a goal is a timeline and accountability. A good way to attract the attention of potential clients is to tell them your dreams (or visions). But no actual client will pay for a dream; they pay for goals. No clients hand over money to a company without a signed contract, and a business contract states goals and not dreams - it has a timeline and accountability.

This thread is not about dreams and attracting potential clients, even though that is a very important subject to attend to if OpenACS is going to be successful. This thread is about goals and closing deals with actual clients of a certain type - those who want to extend the OpenACS toolkit. It is a very narrow subject, and the objective I had in mind was therefore very limited: get the community to formulate how we expect business parties in projects that result in an extension of the OpenACS toolkit to behave in relation to the community, in order to improve the work process and its result.

If the community could manage to present such a written statement to professional developers and their clients, they would be able to agree to follow these standards when signing the contract for the project. Exactly how they would include the statement in the signed contract is not yet decided. One way is to append the readymade community statement to the specific contract. Another way is to write a contract template containing the statement and append the specific terms of each individual project to this default contract.

My starter-off draft represented this second model, but it was immediately criticized for not being generic enough. Whether this was because the content was not generic enough (which it wasn't) or because the form of a contract template in itself is not generic enough is not yet clear to me. At any rate, we could start off by getting on print what the community standards are, that is, how we expect companies and clients to behave when they work on extending our toolkit. If it turns out that this statement is easily appended to individual business contracts, that's fine with me - having a contract template covering this kind of projects is not vital to me. And I've never felt a need for a contract template covering projects that aren't affecting the toolkit.

What kind of expectations do we have, then? What minimum standards would we like to set on professional projects? Are the following points valid, perhaps?

PROJECT PROCESS:

- Present project plans to the gatekeepers and wait for their go-ahead before starting.

- Publicly announce to the community when a commercial project has started and who are involved.

- Post continuous status reports that the community can comment on, and meet any feedback.

- Continuously commit development code to the development branch of the OpenACS CVS tree.

- If the project results in a new OpenACS package, write standard format documentation.

- Publicly announce when the project is completed, and summarize what's been done and who's to thank for it.

PROJECT PRODUCT:

- The code is released under the GPL, making it open source.

- The copyright automatically goes to the code-developing author but may be transferred to the client.

- The copyright holder has the primary responsibility for maintaining the code in the OpenACS environment.