Over the last several months there has been a lot of time put into the thirty bees store getting it ready for launch. Some of the features we have been developing took a bit longer than we thought, but we feel the wait and extra development time is well worth it. As most of you know, we are a very small team with a few outside contributors. So we have to maximize our time usage to get the most bang for our time buck. But what does this have to do with free modules? A lot.
Free module repository
We want our thirty bees store to be a free module repository. Some platforms use forum posts to house their free modules. This makes it hard to search for and use the modules. You never know when a module has been updated or what was updated in the module. You might get an email if you have commented on the module thread. If not, then no email. No notice, you might even forget where the module came from.
This is something we are setting out to change with our store. We want to give a place for developers to upload their free modules where they can be kept up with and where they can grow. Other platforms charge the developer if they want to put a free module on their official store. We are not going to do that. But we do have some simple requirements that I think most developers will be able to live with.
Licensing
For a module to be listed on our store as a free module it will need to carry one of three open source licenses. The licenses we are supporting are:
- OSL licenses
- MIT licenses
- AFL licenses
One of these licenses will need to be included in the free module covering the module as a whole. This way users and other developers will know their rights in using the module.
A readme.md
All free modules will need a readme.md file, if you are not familiar with md files, they are markdown files. The file will need to be in the root of the module, the standard place for the readme.md file. The file will need to explain what the module does and is basically the copy text for the description of the module, or long description for the module to be used on the stores module page.
A GitHub repository
When we think of free, we think of open source. That is why we require a compatible open source license to be considered a free module in our store. GitHub has quickly become the standard for most developers, that is why we are requiring a repository for the modules. This allows other developers to look at the code, fix bugs, and make the free modules better. It also opens the code up for review for security reasons. If anyone can see the code, anyone can help fix security issues with the modules.
Why GitHub?
As I mentioned at the beginning of the article, we are a small team, we have to automate as much as possible. This is why we are requiring GitHub. We will be drawing the modules directly from GitHub using their API. That is where we will be drawing the descriptions, from the readme.md files, that is why we are requiring them. At the same time we will be using the release history in GitHub to offer the module releases and change log as well. This will create a centralized space for module developers to develop their free modules, receive bug reports, and also help or new features from other developers that love your module.
At the same time, the automation will give a better user experience for thirty bees shop owners. To release a new version of a module all you have to do is make a new release on GitHub, the webhook will feed the new release directly to our store. Need to change some text for your modules description? Do it in Github. Have a typo and someone else catches it, they can simply make a pull request against your repo and help you out.
At thirty bees we have a commitment to open source, we believe that it can help us create better software and a better user experience. It is something we are passionate about, something we feel that works.
