Introduction: It seems that at any given time there are at least 2 threads on the first page of the general chat forums which start from the negative stand point of how some program on the GP2X “sucks” and then proceeds to demand that someone makes a better one. This is extremely disrespectful to the developers that have put time and effort into getting their programs this far. When someone makes a complaint post like this in no way provides any value what so ever to the community at large. In fact these posts are actually less than worthless since they discourage developers, and thus have the opposite effect of what the offending poster wanted. If posters would instead get a little perspective, provide constructive criticism, and support the developers, it would go a lot further in getting quality software on the GP2X. Get a little perspective: You, the GP2X owner, are entitled to the GP2X hardware, the GP2X GPH Firmware, and the source code to said firmware. That’s it. Every other scrape of code running on your GP2X is a gift from the talented, hardworking, developers who do what they do “for the love of the code”. They don’t owe you anything, and you should be very thankful that these people have given what they have to you. Your GP2X would be a crappy portable media player and nothing more if it wasn’t for them. So before you even think about how some program on the GP2X could be better, first remember that you should be thankful you have that program at all. This isn’t to say that every program on the GP2X is perfect, but rather that your perspective should be one of thanks not entitlement. Before asking for a new feature or improvement to a program, thank the developer for what they have done so far. Don’t just say “your current program sucks, make me a better one”. Constructive Criticism: Most developers like feedback in the form of ideas for new features and or reports on bugs you have found, but these need to be given in a constructive way. You need to provide the developer with enough information that you’re actually communicating something to them beyond “your program suck”. For example, if you find a bug in an emulator where the status panel in the game isn’t displayed, do a little digging before sending the emulator’s author a message about it. Try playing some other similar games to see if they have the same problem- games of the same genre or games by the same company. Try using the same rom file on various other emulators on your desktop to see if the other emulators have the same problem. Try using a different dump of the rom in question to see if it’s just this one particular version. In the case of a missing graphic, try using an emulator on your desktop that allows you to toggle on and off the different layers to see if you can get the same effect as what you see on the GP2X emulator. Keep notes of everything you’ve tried and what the results were. When telling the developer about the problem, give them this information. If the bug is the program crashes when you perform a particular action, provide the developer with the exact steps necessary to reproduce the crash. Confer with other users to see if they can reproduce the problem before you bring the developers attention to the problem. It’s possible that it’s just a configuration problem on your end, and not really a bug at all. In short, thoroughly research and document the problem before contacting the developer about it. When asking about a new feature, approach it with the same rigor. Thoroughly explain your idea and how it would work. If you know of another program that does something similar tell the developer about that program. Support the Developers: Time is money and conversely money is time. If you don’t have the time to program gives money to somebody who does. If you don’t have talent to program give money to somebody who does. Keep in mind that donations don’t entitle you to anything, but are just a way of supporting developers and showing some respect. Another way to support developers without being a developer yourself is to lend help in the non-development aspects of the program such as tech support. If you use a particular program a lot and know to use it well, try to answer forum post by other users of the program that are having trouble. Or you could write up a guide on how to use the program and contribute it to the wiki. When you do these things it helps the developers focus on development instead of support and documentation. Summary: Get a little perspective, provide constructive criticism, and support the developer, that’s how you improve a program on the GP2X, without ever writing a line of code. Just remember, don't be a dick and show some respect.