From a comp.lang.tcl posting by Larry Virden
1. Avoid simple, obvious names for your namespace - someone else probably is also using it. Search this Wiki and comp.lang.tcl [L1 ] to check your name is not in use.
2. Avoid global variables, procedures, etc. - they are almost certain to clash with something someone else has done. Likewise, don't export package names that you do not intend as a public interface. This really messes up people attempting to make use of tcl's introspection capabilities.
3. Avoid hard coding pathnames, socket numbers, etc. - they are almost certain to clash with how someone else needs things configured. Trying to force someone else to do things your way is a great way to lose friends and influence enemies...
4. Make a variety of docs available - man pages for Wnix users, winhelp for Windows users (if your package can be used there), html for Mac and other platform users, etc.
5. Make it easy for users to report bugs - and let them know when the bug fixes are available...
6. Keep up with the latest releases of Tcl.
7. I know that for me, I appreciate it when packages use the same terminology in the same manner as Tcl when doing configuration. Moving things around, requiring binaries from the Tcl source directory, etc. is very annoying.
See Extending Tcl for general information about writing Tcl extensions.
For the person new to Tcl, one might wonder whether there is a difference between the use of the term package and the word extension. Generally, no. Tcl actually has a package command, but there is no extension command. So package is probably the better term to use.
LV writes, on comp.lang.tcl, the following comments about taking a script package from the wiki or other places and installing it:
Premise: a user sees a web page, usenet posting, etc. that has tcl code which implements a series of procs. How do they move from this finding into having the ability to package require it?