CFOG's PIP, January 1987, Volume 5 No. 3, Whole No. 51, page 4

Suggested Guidelines for the Submission of Software to the Public Domain

by Terry Smythe

From time to time, enthused users make significant contributions to public domain software, and the purpose of this note is simply to encourage more if this, and to help authors package up their offerings according to generally accepted standards.

But what standard? Frankly, I've never seen a standard for this, but I for one would surely appreciate seeing one in place. So, here's a first cut at an attempt to define guidelines. There are certain to be other opinions out there, and this is healthy. Please note that I have called this file PDGIDLIN.001. If you have ideas on this subject, add them in, increment the release number, and uplead it back from where you got it.

I believe all RCPMs should have in place fundamental policies to satisfy the following basic requirements:

1. The contribution will always be in the form of a library file where 2 or more files are needed.
   
   
2. The library file shall have as its minimum content the following:
   a. Executable COM file
   b. Documentation file on what it is for, and how to use it.
   c. History file to record all versions and evolutionary changes.
   
   
3. The documentation file shall contain the full name, mailing address, and phone number of the donor, and shall be dated. A most helpful additional item is your RCPM number for leaving messages.
   
   
4. All files in the library shall be squeezed or crunched. Never forget that your contribution will move around the world on the long distance lines, and that's expensive. Every k you can shave off by squeezing or crunching means that much faster it will move through the long distance lines, and reduce the cost. Not all downloading is done locally.
   

Furthermore, every k you shave off by squeezing or crunching means just that much more that can be loaded into the RCPM of your choice. Space consumption is critical.

OTHER TIPS

1. While pretty formats are nice to look at, they generally consume far more paper than is really necessary, particularly with repetitive page headings and footings, tons of glorious white space, weird print command codes for expanded, bold, etc.
   
   
2. Highly recommend a page format only 52 columns wide, with little or no "fluff". In other words, pack as much as possible into those 52 characters, so that it may be printed out with either DBL401/DUBLSIDE or FANFOLD. The objective is 2 columns, both sides, 8 lpi, 81 lines per page.
   
   
3. Avoid the use of indented paragraphs in your documentations. Wherever possible, use a straight left margin for everything. Find other ways to break up your material, than the traditional OUTLN/TOUR progressive indent format. You never know who might acquire and like your contribution, and may wish to reformat it to match his own documentation library.
   
   
4. Always presume that your contribution will travel around North America within weeks of release. As a consequence of this, your contribution will end up on a totally unpredictable array of computers. So, make every effort to ensure your pride and joy does not have machine specific code in it, or if it does, that it is limited to screen attribute codes, and show precisely where the those codes reside in the executable COM file, what to look for, and what they mean for the host computer.
   
   
5. Wherever possible, include your source code. PLEASE don't keep your product a secret. Nothing is quite so aggravating as to find what appears to be a first class utility, and find it doesn't work because of some unique condition in your operating system, or hardware. Without the source code, corrections to make it work on your system are difficult and often close to impossible.
   
   
6. Forget about copy protection schemes. All they do is make people angry, and they violate the spirit and intent of what Public Domain software is all about. If you are seeking some form of revenue from your contribution, then place it into the world of User Supported Software, and include only the minimum documentation to make it work. Offer a excellent, well thought out User Manual as an incentive for payment. Under no circumstances include a self-destruct mechanism in your system which will limit its usefulness after x times used, or some other such limitation.
   
   
7. Always a good idea to include a copyright notice to provide modest protect of at least your authorship. There is no way you are absolutely going to prevent others from tearing apart your library file, but it surely is a reasonable deterant to include a notice forbiding changes, additions, deletions, of any kind. That even includes changing the name of your file, and perhaps adding in comments as an additional file in the library. Fundamentally, the file is yours, and you should be the only one allowed to make alterations of any kind.
   
   

I hope that this will not deter contributions. The library of public domain software we now have has been totally put there by users such as all of us, from all over the world. Public Domain software lives or dies on the quantity and quality of continuous contributions from all users.

God Bless and let's see these contributions continue to flow!