Curation and standards

There are several million public repositories on GitHub, Source Forge and Google Code. Everyone can publish their projects there regardless of their experience level or scope of project. Binpress is a marketplace for professional open-source projects. In order to maintain a level of quality and reduce noise levels and curation efforts for our visitors, components are reviewed for coding standards, documentation and best practices.


Component guidelines

What follows is what we look for in submissions:

  • Non trivial functionality - we do not publish snippets or simple scripts as Binpress components. If you have code that you think is useful but does not offer significant functionality, you should create a tutorial instead.
  • Reusable code - component should be useful in multiple scenarios and not offer fringe solutions to uncommon problems / needs. It must also be ready for reuse - if you want to publish a codebase for an existing app, please make sure to properly prepare it for customization and reuse. We do not accept application source-code "as-is" just because the application itself is published.
  • Working code - make sure the package you upload works on a standard environment, as-is and out of the box. If there are any special requirements or setup steps, make sure to specify it in the component documentation.
  • Coding standards and conventions - The provided source-code package should conform with an accepted coding conventions for the language it is written in. This includes indentation, header and inline comments, file and folder structure and formatting, variable names and more. For a partial list of coding standards, see below.
  • Documentation - Code should be thoroughly commented and documented. Component package should include complete non-technical documentation for basic setup and any relevant integration / customization / modification.
  • Copyright violations - Please make sure you do not submit material that you do not own the copyright for or have permission to publish. This includes stock photos and images (icons, logos are included) as well as copyrighted source-code.

Component subjects to avoid

Component ideas that you would do best to avoid unless the execution is exceptional (we get many derivatives of those). Notice how most of them violate the first guideline above (non-trivial functionality)

  • Database wrappers
  • URL shorteners
  • Social link widgets
  • Caching solutions
  • General purpose loggers
  • Image galleries
  • UI effects with no specific purpose

For component inspiration, check out our most popular components and visit our component proposals.

Avoid Submitting Existing Components

Go over our existing inventory and look for components similar to what you want to submit. This is especially important for commercial components - we want to avoid cannibalizing our own inventory, so please avoid submitting components that do not have significant differentiating features from existing components. When in doubt, contact us.


How the review process works

  • When your component is ready for publication, submit it for review and it will enter the review queue.

  • One of our reviewers will go over the component source and profile.

  • If the component has minor issues in the source or profile (including documentation), you will be given a list of review notes for you to fix.

  • If relevant, we will deploy your package on a standard environment for the language it was published for, using the installation instructions you provided.

  • This process will continue until component passes quality review by our reviewer.

  • If component is too far away from meeting Binpress guidelines, it will be rejected outright (see soft and hard rejections below).

Passing and failing quality review

  • Passing review

    After your component has been reviewed and complied with all of the above criteria, you will receive an Email notification and your component will be published on the Binpress marketplace.

  • Soft rejections

    If the component generally meets Binpress quality standards, the reviewer will help you go over and fix any issues that were found during review. We also try to help you improve the marketing aspects of your component profile.

  • Outright rejections

    If the component is too far away from meeting our guidelines and the reviewer deems it will take too much work to make it comply, the component is rejected outright. Please read this page in detail and make sure you understand the requirements before submitting in order to avoid time loss and frustration.


Coding standards and conventions

Every package published on Binpress must meet industry standards and use good development practices. Our reviewers will inform you if you fail to meet some of those standards, but please consider the following guidelines before submitting your package for approval:

General programming guidelines

  • We expect well-designed and clean code. Use abstraction and modularity as needed, separate application and presentation logic, implement design patterns where appropriate.
  • Component should provide beyond trivial functionality. A short, basic script will not be accepted as component on Binpress.
  • Documentations and comments should be included according to the conventions of each language (see specific language sections).

Code should follow the security conventions of the platform it's intended for (web, mobile, desktop).

  • Properly filter and validate user input
  • Escape dynamic parts in database queries or use prepared statements
  • Escape / filter when outputting user input to avoid XSS attacks
  • Do not store passwords in plain-text or in decryptable format
  • Code should be covered by unit-tests where appropriate (such as libraries and general purpose components).
  • Easy to integrate - package should be integrated with minimum difficulty. Detailed integration and configuration instruction need to be provided.
  • The use of globals is highly discouraged (global scope pollution).
  • Don't ignore or suppress errors - make sure they don't happen in the first place.
  • Don't submit your package with commented out code and incomplete sections (TODO notes and the like).


  • Code formatting should follow the PSR-1 and PSR-2 standards. Indentation can be 4-spaces or tabs (but must be consistent)


  • Avoid global scope pollution and override - wrap your code in a closure and use the 'var' declaration when creating new variables.
  • For anything above very simple scripting, we advice using one of the popular libraries to ensure cross-browser compatibility. You are responsible for your code running the same in every browser.
  • Do not use inline Javascript inside HTML markup - use event binding instead.
  • Code should not depend on script tag placement - use document load event (using event binding).
  • Try to avoid browser detection in Javascript whenever possible - use feature detection instead.
  • If possible, try to use progressive enhancement. For example, forms that have client-side validation should also be validated server-side. Links that load content asyncronously should perform an actual redirect if Javascript is disabled (context switching).
  • Javascript does not have a formal style guide, but please examine the jQuery style guide for an example of a consistent, readable format. Use indentation for control structures and function / class defintations, use comments where appropriate, give meaningful names to your variables and functions.







HTML markup

  • Markup should validate against W3 standards. We won't penalize you for HTML5 markup that is not yet recognised by the validator (such as the meta tag error Binpress markup currently receives).
  • Markup should be consistently formatted and indented. Try to avoid lines that are too long and align opening and closing selector on the same indentation level.
  • Tables are to be used for tabular data only. Tables used for page structure will not be accepted.
  • Try to use semantic markup whenever possible such as <h1>,<h2>,<h3> ... <p>, <cite>, <blockquote>, <ul> instead of the generic <div> and <span> tags. When not possible, use meaningful class names and identifiers as shown in the wikipedia examples and the various microformats.
  • Avoid using more elements than necessary. Don't wrap elements in other elements unless there is a reason to do so.
  • Use of deprecated elements will not be accepted. This includes the <center> and <font> tags. CSS should be used to achieve the effects those tags used to apply.


  • Try to avoid using inline CSS - use stylesheets instead.
  • Functionality should not be broken in any modern browser.
  • Progressive enhancement using modern selectors and properties is encouraged.