Rules about component hosting at wxCode

These are the basic rules you must agree to if you want to host your component at wxCode.
Please keep in mind that these rules were created to avoid that wxCode becomes a "dump" of unmaintained and thus unusable code... We hope you'll find them to be both reasonable and acceptable.

  1. First and foremost; thank you for making your component publicly available! This means that other people can learn and benefit from your hard work and assist you in making it better.
  2. Each code snippet submitted to wxCode should follow the outlined directory structure of the template sample (you can see this by browsing the wxCode CVS or reading the template guide) to allow for easy integration with the wxWidgets library, people's projects, and the other components. This means that you should create something with the usual "build", "docs", "include", "samples", "src", etc. directories. Please don't call your source folder "mySoUrCeS" or put your public header files in your source directory since people may have header name conflicts when they try to include them.
  3. Inside the components directory there is a subdirectory for each component. The name can be freely chosen but it has to consist of only lowercase letters and has to be unique within wxCode. But as long as nobody objects you're free to choose what ever you like.
  4. Each component gets the following services: webspace dedicated to the component presentation, to its screenshots, and to its documentation; an optional wiki which can also be used for the component presentation; a CVS folder where the component sources must be stored; space in the download server for component releases. Last, the component will be indexed in wxCode project database which is used by this website to list & search the components.
  5. The maintainer must have a SourceForge account (this is required for committing the code in the CVS repository and for the handling of the web services) and should provide a valid email address to allow users of his component to eventually contact you for help.
  6. The maintainer should send a component status report to the wxcode-users mailing list when they provide a new release of their component. This will help to generate interest and show users that your project is active. As SourceForge suggests, "Release early; Release often".
  7. The maintainer should regularly update the component info (wxWidgets supported versions, ports, etc.) and keep their component alive (fixing bugs, making new releases).
    A maintainer may resign at anytime; please have the courtesy to announce your intentions on the wxcode-users mailing list instead of just "disappearing". In this case, your code will be marked as unmaintained and others will be able to take over this maintainance task.
  8. Each component must be made available under the wxWindows license. This is to ensure that there will be no misunderstandings by users of your code or clashes between components that may rely on each other. Remember; this code repository is designed to facilitate code reuse. Small third party libraries that you may include or link with your component will (of course) maintain their original license and you should note that in your documentation.
  9. The basic concepts you should keep in mind when writing your code are:
    • Make it easy for people to understand your code; add comments, documentation, and a sample program.
    • Follow the wxWidgets coding standards.
    • Make your code flexible and extensible.
    • Make integrating your component in other people's projects painless and therefore sucessful.

All these rules have been adopted to maintain high quality code at wxCode. If you think something is missing or that some rule doesn't make sense for your component or it's too strict, please discuss it in the wxCode-users mailing list. We look forward helping you help the wxWidgets community and your advice is appreciated...