You've decided to create a Sitecore module and have developed a great solution. Now it's time to release it to the larger community.
Releasing a Sitecore module is no different than releasing any other software package. You can choose to host a ZIP file on your own website. You can point to the source on GitHub and provide build instructions. You can publish in the Sitecore Marketplace to get great visibility. No matter which route you choose, here are some guidelines for preparing your module so it can be discovered and consumed on other instances of Sitecore.
Preparing a Module
While your module works fine in your version of Sitecore on your local machine, that's no guarantee of success for consumers of your module. In addition to following along with Sitecore's module implementation practices, here are some tasks and guidelines to run through before publishing your module:
Compile against correct .NET Framework
You've probably built your module to work with a minimum-supported version of Siteore in mind (this is most likely because of certain APIs and features). Every major release of Sitecore also introduces updated .NET version requirements. To maximize compatibilty, ensure that your solution is built against the lowest version of the .NET Framework that is supported by your target version of Sitecore. To know what version of the .NET Framework is supported by Sitecore, check the Sitecore compatibility table.
Test across Sitecore versions
Does your module target Sitecore 8.0? Ideally it should work on all versions of Sitecore currently available. Be sure to test all major dot-releases (8.0, 8.1, 8.2, 9.0, etc.) and any secondary releases (8.2 Update 1, etc.) that have breaking changes that may affect your module. Release notes are available on the download page for each version.
The Sitecore Instance Manager (aka SIM Tool) is a great way to quickly spin up different versions of Sitecore for testing purposes. If your module requires xDB or xConnect, you will also have to ensure that the proper MongoDB or SQL Server databases and services are set up.
Open source? Prepare the repository
If your module will be open source, take a few extra steps to be sure your project is ready for others to download and properly build.
Choose a hosting platform that is easily accessible (GitHub is an obvious choice, although BitBucket is fine too). If you want to allow contributions from other developers, ensure that you can use an issue tracker and allow pull requests.
Create a README.md file in the root directory of your solution. A basic readme will have the following sections:
- About / Overview
- System Requirements
- Getting Started / How to Use
- Configuration
- Troubleshooting
- Contact Information
- License
It is critical that you choose a license to prevent your module from being misused, opening you up to legal liability, or preventing people from using your module outright. Your license can be placed in your README.md file directly, or referenced there and placed separately as a LICENSE.txt file in the root of your solution.
Finally, if you're not using a gitignore file for your repository, do it now. Never commit compiled files (such as binaries) or content that can be re-created from a repo (such as NuGet packages).
Publishing a Module
Getting a module published is as simple as hosting the ZIP package file on a web server and announcing to the world how to download it. This can be your personal website or something similar.
The Sitecore Marketplace is the de facto place for Sitecore modules to be hosted and discovered. Anyone can create an account and upload modules (for free!). The Marketplace actually runs on Sitecore and uses workflow to enforce a basic review process, so all content you submit will be reviewed before being published (a process that usually takes 1-2 weeks, so be patient once you submit your changes).
If your module is meant to be integrated with a Visual Solution solution, consider building and publishing a NuGet package.
Once you have a module available for download, it's time to get the word out to the Sitecore community. Share information - including a link to the download, an information page, the GitHub repo, etc.) - and a short summary of what your module does.
A blog post is the best way to introduce your module. This gives you a place to outline what your module does, how to get started with it, and provide screenshots or a brief demoonstration via video.
There are a lot of Sitecore developers, marketers, strategists, and MVPs on Twitter, so get tweeting! Remember to use hashtags such as #sitecore, #module, and any relevant keywords specific to your module. Other good platforms for announcing your module include the Sitecore Slack, LinkedIn, and Facebook.
Maintaining a Module
The Sitecore Marketplace has hundreds of modules that are listed to be compatible with Sitecore version 6, 7, and... not much else. Even though a module written for Sitecore 6 may work on Sitecore 8 or 9, it doesn't look good for a module to appear so outdated. It is important to maintain your module for as long as possible.
You should maintain your module at least once per year. Sitecore typically releases major dot-releases once or twice per year, and these may introduce breaking changes to the platform. With each major release of Sitecore, ensure your module continues to work. If it does, update your website and/or Marketplace information to reflect compatibility with the latest version of Sitecore. If changes are needed, try to make them quickly and announce the updates to the community.
Be sure to fix bugs that are reported by consumers of your module. Catching common issues that arise after release will improve the reputation of your module (not to mention you as a developer).
If you have to move on from your module and can no longer maintain it, there are a couple steps you can take to help current and future consumers of your module. First, make a clear and loud annoucement that you will not be maintaining the module. This prevents the module from ambiguously becoming labeled as "abandonware" and largely ignored. Second, if you haven't already, open source your project with a permissive license so that others can pick up your work and continue to use it - and more importantly - modify and maintain it themselves.