• Treat the user's calculator with respect. Don't use any code that will put THEIR calculator at risk! Test your programs extensively and remove any holes that could potentially cause a major error. Even if you're not liable for damage, these types of incidents can tear apart communities.
• Applications need to be free. I shouldn't have to even say this one because it rare to happen on a calculator and no good distribution method currently exists. Do note that if you choose to follow this path, few if any people will buy your apps.
• I can't force you to do this, but open source really is a good idea. Source stealing is very rare these days and you really shouldn't care too much if someone borrows a routine. Yes, they should credit you but it's not like your losing any money by their doing so. These are free apps, by the way, so any sharing is only benefiting the common good and remember that our goal is not to please ourselves but to please our users.
• If you choose to follow an open-source approach, keep your code very clean and well commented. Explain what each function does and how the more complicated algorithms work. Additionally, you should provide documentation for the user on how to compile the application or, better yet, provide a shell script and makefile.
• Do everything you can to remove bugs. The best way to find bugs is to try to purposely break your programs to see how they respond to odd conditions. If a program asks a user to enter in how much money they would like to bet, enter a negative number and see what happens and if needed fix the resulting bug or glitch. Another good way to test for bugs is to release alpha and beta versions of your apps because others may find issues you never knew existed.
• Provide a line of communication for your users. Not everyone has an account on Omnimaga or Cemetech, so you need to provide an email, not only so you can provide the occasional help but also so users can report those all-important bugs.
• Your distribution file should include a readme. This should contain usage instructions, compilation directions, and how you can be contacted. Make it easy for the user to find what they're looking for and don't make it too long.
• Value user friendliness over extreme optimization. I'm not condemning optimization—in fact, every program should be extensively optimized—but what I'm warning against is overdoing it. You should always program in extensive exception handlers to prevent the user from breaking your apps. Graphical appearance should also be focused upon. Most users would prefer a sharp UI over an additional frame per second.
• If this is an ongoing project, updates should be regularly released and easily available. Even if an update only fixes a few minor bugs it is still worth it to release.
• Maintain a project topic on a calculator forum. It is recommended that the first post contain all of the most recent updates, screenshots, and information as it is easiest to find in that format. It is also a good idea to have a change log there or in your readme file as it provides a full development history.
• Remember to credit everyone who helped with development of your project. This includes programming, graphics, ideas, music, etc. This should be done in the readme, the project topic, and if possible within the application itself.
• Design your programs to have full forward compatibility and, unless it would hinder application development, full backward compatibility. Don't assume that Casio will never modify the Prizm in the future because chances are that we will see some major changes just like we've seen with every other calculator in history. How you do this is up to you, but one way to do this to make effective use of syscalls as they are pretty well written in stone; a well designed program or routine will also stand the test of time.
• Keep a common user interface. Just like most Windows, Mac, or Linux apps have a similar feel within their own OS we ought to do the same. The best way to keep the look and feel of apps the same is to use either OS or shell calls to draw windows and other UI elements.
• Keep backups of your projects! This cannot be stressed enough. Store updates frequently on multiple computers, on flash drives, online, or in that cloud thing. One thing I recommend is forming an account on GitHub (https://github.com/). You can keep your projects in an online repository and it can also make distribution easier too. Many major open source projects are also stored here including the Linux Kernel which it was originally designed for.

Here is a list of rules and suggestions that I believe those who develop for the Prizm should keep in mind for their apps. Many of these apply to all platforms whether it be other calculators or computers but a few are more targeted at the Prizm.

• Treat the user's calculator with respect. Don't use any code that will put THEIR calculator at risk! Test your programs extensively and remove any holes that could potentially cause a major error. Even if you're not liable for damage, these types of incidents can tear apart communities.

...

• Value user friendliness over extreme optimization. I'm not condemning optimization—in fact, every program should be extensively optimized—but what I'm warning against is overdoing it. You should always program in extensive exception handlers to prevent the user from breaking your apps. Graphical appearance should also be focused upon. Most users would prefer a sharp UI over an additional frame per second.

Well, that's not really optimization at that point. That's a poor choice of speed optimization over the more sensible size optimization. (You seem to have ignored that programs can also be optimized for size. )