Submit to Marketplace

​​​​​​Absolute Requirements

  1. Read the Extension Reseller Agreement. This covers how we work with you legally.
  2. Licensing issues. This goes for any assets, not just code. By submitting your work, you are taking legal responsibility that you own it. If someone else emerges with a DMCA take down notice for something you're distributing but didn't create and take the time to license properly, you'll likely owe them a lot of money and we won't be helping. "I didn't know…" and "I thought it was cool because…" won't help. Before you submit something, be sure of the following:
    1. Do you actually have rights to any third party code?
    2. If you are using any libraries, are they MIT or LGPL licensed?
    3. Do you have rights to any assets you're using: fonts, icons, images etc.?
    4. Did you include whatever license that grants you the right to use whatever you did not create yourself?
    5. If you are offering a third party service, do you have explicit permission to use this service (such as in the form of an email from the service)?
  3. The theme or add-on is packaged correctly and installs cleanly.  The best way to test this is to create a fresh install of Concrete CMS and install it there.  If you have never built a package, read the documentation about packages and download a free add-on or theme to see it in practice.
  4. The package has an icon.  The correct file is a 97x97 pixel transparent PNG fie named "icon.png". (Rounded corner is no longer required). If you like the historical rounded corner icons, you can use this PSD file as a template. For users of Inkscape and other vector graphics programs, check out this SVG file.
  5. Choose a simple license to distribute your work under. The marketplace officially supports the MIT, GPL and our own Concrete Marketplace License. If your work needs custom licensing, we will have to review that on a case-by-case basis.
  6. Realize that this is a product that you will have to support.  For commercial add-ons, we require you to provide support to customers for at least 30 days after they buy the add-on or theme. For free add-ons, it's up to you how responsive you can afford to be for free, but if we see reports of it consistently not working we will yoink it from the marketplace. 
  7. It's our store - you're a vendor. We may choose to not include your add-on or theme. Generally, we try to take an inclusive approach, but we reserve the right to politely pass on any offering for any or no reason. You set the price you want to sell your work for; we take a 30% cut. 
  8. The Peer Review Board (PRB) is a group of volunteers who graciously review add-ons and themes to keep the approval process going. They are in control of you getting your listing live, so be nice. Here's the current PRB members and admin list.
  9. Don't abuse the system. You're joining a pretty tight-knit community here. This is a small group of people who care a lot about being able to use the web to express their ideas. We want Concrete CMS to be a rich ecosystem that enables communication. If you're not on board with that, you will be left behind. If you're just here to make a quick buck, or you're willing to take advantage of your fellow vendors or our customers' goodwill, that will be noticed and your listings and account may be quietly removed.
     

A Few Tips

  • Start your version at 0.9.0. As you update the PRB submission, increment the third digit. When you get it approved, put the version at 1.0.
  • Chime in when you upload a new version to the PRB. Don't be afraid to be specific about what you updated.
  • If the demo site for your add-on or theme is super-awesome, keep in mind that some customers will expect your product to turn their site into the demo site.
  • Be realistic about the required version of Concrete CMS for your add-on. If you developed it on the current version of the core, do you really want someone installing it over code from a year ago?
  • Screenshots get used in the marketplace view from within Concrete CMS's dashboard. The ideal dimensions are 400 x 400. Instead of showing the edit interface, show the product of what the extension does.
  • Be original! We do like competing solutions to the same problem in the marketplace, but please create unique solutions to those problems. 
  • Avoid submitting something with known bugs. The PRB is here to approve working code, not fix known issues.
  • Selling Outside of Marketplace: If your add-on/theme is wrapping a service that costs something, we'd like to explore a technology partner relationship to offer it in our marketplace. We also strongly discourage you from selling your add-on/theme outside of our marketplace. It makes support annoying and isn't fair to the hard work we and the community put into building the core product, providing feedback through the PRB, and marketing the solution as a whole.
  • Extending add-ons. If you are going to extend or enhance an existing add-on, check with the original developer beforehand.
  • Make your names unique and easily owned.
    • It's a good idea to have a brand you can use on your packages. Your package can't be named the same as another package already available in the marketplace. For example: "awesometech_gallery" instead of "gallery." Use non-generic names for your blocks, classes and so on.​​
    • No Borrowed Brands. Unless you work for a brand under a formal relationship that you can document, your listing should not use that brand as a primary marketing tool.
  • Make sure your add-on or theme is described accurately on its marketplace page and at least try to keep your grammar and spelling in check. This also goes for the add-on or theme itself. For the time being, this also means that your add-on or theme will have to be in English to get reviewed.
  • Your add-on should also have some docs for it somewhere. It's fine for the documentation page just to be a link to your own site.
  • External dependencies. If your add-on needs some sort of third-party software, API keys, or it "mashes up" something, try to include those somethings and be ready to explain them as part of your PRB submission.
  • It's just your library of goodies. If you're a developer with some reusable tools others might depend on, you should share those on GitHub. That way other developers can grab a copy, include it in their add-on, and know that their included code will work consistently within their add-on, regardless of what your latest version does. There are no complex external dependencies in our package system by design, not through oversight.
  • Complex setups. Much like using third-party APIs, if your add-on requires additional accounts, connects to another system and so on, please create a staging site that PRB reviewers can play with rather than putting the burden on them to spend hours configuring an environment to test your add-on or theme.
  • Code outside of best practices. Please take a look a the style guidelines and use the Concrete CMS API whenever possible.
    • Whenever you are presenting information to the user, wrap your text in the t() function. It makes your add-on available for translation. So, use t("Click here") instead of "Click here".
    • Avoid using deprecated interfaces.
    • Make sure your PHP files have the <?php defined('C5_EXECUTE') or die('Access Denied.'); ?> at the top of them.
    • Use long tags: '<?php' not short tags: '<?'. Not every server setup supports the short ones.
  • Use Concrete CMS UI conventions appropriate to the core version you are developing for.
  • Keep your packages clean from useless files. Mac users, this includes "dot underscore" files.
  • Abandoned submissions will be removed. Unapproved items with no activity from the developer for a few weeks (uploading new versions, posting messages) will be removed without warning. You are welcome to re-submit your work.

Why All The Rules?

Shouldn't we want as many add-ons and themes as possible?

We have a listing of open-source contributions. If you have something that you think is just fun and exciting but not really a product per se, feel free to fill in the form linked on that page and your project should get a link. Of course, there has always been our how to section, which is another place for sharing ideas.

We absolutely want to have an abundant marketplace representing the interests of our users and developers. That said, we do not intend for the marketplace to be a code repository; much less a jungle of half working ideas.

The hope for the marketplace is that a majority of that work is either a client-ready application or a tool that meets some need of the web professional. What you submit to the PRB should be something that you feel is prime-time ready. It's a cool feature of the Concrete community that you get to have your product assessed by a competent group of people doing the same work you are and hear their perspectives before going to market with it.

All set? Submit your work!