Generally speaking, it is a good idea to publish complete packages for others to learn from. This page is about sharing tips and tricks for doing this. If you are into the prop (and that's a safe bet if you are here reading now), adding this value will grow the community of Propeller enthusiasts. The more the merrier.
Identify target Propeller Setup(s) and Clock speed(s)
With all the boards and home-brew setups out there now, it's beginning to make sense for this to occur. Demo board & Hydra both run @ 80Mhz. Hybrid and some others run @ 96Mhz. If your program is easily configured for multiple boards, that's great and can easily be put in the self-documenting code options. If this is not the case, then others will know what setup to use, or that they might need / want to port it to their setup.
Other things to include are the video output standard(s), such as NTSC, PAL, both!, VGA, etc...
eg: some_game_HYBRID_96_PAL.zip
Propeller IDE Tool Archive function
The propeller tool has an archive function that will grab all the objects needed for a particular project and zip them up into one simple package for others to try out, without having to locate dependent packages. Highlight your main program, then choose FILE, ARCHIVE and go from there. Archive includes a name and time stamp for easy tracking.
You must have successfully compiled your code, in order for the archive function to work. Just load your main program, and compile, then archive.
Additional documents, in the form of spreadsheets, text documents, screen captures, sample assets, etc... can be bundled with the archive created with the Parallax Propeller IDE tool, using your archive manipulator of choice.
Combine everything into one SPIN wrapper
Bundling things together as a demo that can also be used as a building block object is another ready option. This may require some greater effort, on the part of others, to utilize the work. YMMV.
Self-documenting code options
The Propeller tool includes a nice font that can render schematics, flow charts and general ASCII text comments. Consider verbose comments in your code, particularly if you elect to produce one combined file. Users can then run the demo, read the comments, tweak, then apply the bits that make sense.
Use the SPIN block comment to embed HTML documentation right in the program file. Good for simple graphical elements, color palettes, etc...
Hydra CD
Really great games and game related utilities, well packaged and documented, is likely to end up on the HYDRA CD. Quick and easy fame can be yours!
Some objects are distributable, some are not.
The sample code on the HYDRA CD, written by Andre's demo team is not freely distributable. Note these files in your code documentation, by name so users can locate them after having obtained their own copy.
Hanno has given permission to include the 'Conduit' object to provide ViewPort support in your packages. This means that all of the ViewPort code used to test the spin code can stay in the distributed version, even if the end user does not have ViewPort. Since the name 'Conduit' is the same across all versions of ViewPort, but the software interface that it supports does not, be careful not to have users place the copy of conduit that you provide anywhere that it might over-write a previously installed version. if the user already has ViewPort and Conduit installed, then they should just delete the version that you have packaged up.
Other files, published in the Parallax Object Exchange are distributable, as is the Parallax reference material. Web forum code postings vary considerably on this, making it best to just ask before distributing these. If your project modifies something, it is a really great idea to modify the name so people do not confuse objects. It is also a good idea to reference the original in the program header as well, so people can follow the logic later.
Consider staking out a name space prefix for your code, and use version numbers or the archive timestamps for people to track changes.
eg: potatohead--wonderdriver_001.spin
Consider not removing incremental code changes from the Wiki or forums. These are often very helpful to others for learning how things evolved in addition to just learning how to use the code in it's current release form, The HYDRA book and CD illustrate this idea perfectly, with incremental changes to drivers both in the text and on CD. You may also find your own pre-release efforts useful at some later time. If nothing else, it makes a great off-site backup lest disaster strikes!
Include running screen shots
It's helpful to see what the expected result is! A coupla JPEGs from your capture card, camera, or screen capture code running on the Propeller itself, help the potential user to see what it is they will be running. Colors, etc... can be compared to, just in case setups differ somehow.
Specify your license
By default, everything is copyrighted. Take a moment to include your intent in the program header, along with version, purpose, name, date, etc... This simple bit of meta data makes things easier for everyone. Hobby level developers are not often concerned with these matters, but a great many others are.
The share and share alike culture surrounding the Propeller is a big value add. While not always possible, where it is, an explicit statement can save someone some grief and maybe see your code used, improved on, or just found useful by others.
As the software creator, you are entitled to specify most any conditions of use. Code lacking such specifications may not be useful to others having to work in a more formal environment. This can be a simple note, to a fairly complete specification, such as BSD, GPL, Creative Commons, etc... If you can, keep this really simple. Others looking at the code, for the first time, can grok right away, what their options are, and can know to ask for greater permission, if their intent warrants that.
Choosing a License
The complexities of licensing and implications of particular licenses are subjects which cannot be fully covered here, but authors of software should bear in mind that a chosen license does not just grant permission for things which can be done, but also places restrictions on what cannot and may also have consequential impact on anyone using your code which they, or you, may find undesirable.
Many software authors place their work in the public domain so others may use that code and benefit from it, however, a poorly chosen license may restrict its use more than intended. Some licenses may require anyone using your code to also publish the work in which they use your code. This may be unsatisfactory for some who may wish to use your code but will be unable to do so. You may wish to impose such obligations or you may not ( it is a matter for the author to decide ) but the author should be aware of the consequences of whatever license they choose to use and ensure it is suitable for and matches what they intend.
Before choosing a license, it is recommended that software authors decide what they wish to allow and what they wish to prevent and researches how any particular licenses match with their desires. Do not choose a license simply because it is the 'flavor of the month' or others say it is the preferred license to use; choose a license which matches your own intent.