Hooray, you’ve decided to open-source a SilverStripe module you are working on! This is an excellent choice. I’ve created a number of SilverStripe modules, and my default is to open source them. Doing so attracts other developers to use and scrutinise your code, helping your code to get better, and helping you to become a better developer.
Hopefully this post will give you a few pearls of wisdom to short cut your way to a great open source module.
DRY: Don’t repeat yourself, or anyone
Before starting work on a module, always check if the same thing already exists. If a particular module doesn’t have the feature you want, check it’s forks to see if someone else has already built the improvements. Choose to contribute to an existing solution before making your own.
- Composer is a must now days.
Automate as much as you can
You’ll save yourself and others hassles.
- Write tests, and run them on Travis CI. I recommend using PHPUnit and Behat.
- Set up scruitiniser to analyse your code.
Document all the things
- Your README is important. This is the go-to for understanding the module, finding out how to set it up, and things like finding support.
- Document your module as you create it, and as you resolve issues. Ask for documentation with pull requests. It’ll save everyone time communicating. Sometimes a short video helps to explain a feature. It could even be a gif file. Using https://readthedocs.org/ , you can have you docs hosted for free, and updated automatically as updates are pushed.
- Use version numbering. Learn semantic versioning. You can update version numbers every time you commit. It helps yourself and other developers know where their code is at in regards to the project status.
- Don’t forget to choose a license.
- Create a model diagram. I have typically used Google docs drawing suite, but have since come the silvergraph module, which will automate this for you.
Do things that will help and give confidence to developers that might use your code
They are more likely to use it if they feel like it won’t cause them hassles. All of the previously mentioned sections relate to this also.
- Keep it simple, and extensible. Often some cool feature will get in the way of using the core functionality of a module.
- Care about code coverage.
- Be a good maintainer. Don’t be afraid of forks, or handing over the project if you don’t have time to maintain it.
- Communication. Gitter is a great way to talk about your work in real time. I’ve downloaded the gitter client, and I get people contacting me periodically about issues, improvements, and even work opportunities.
Further reading
I’ve just glossed over many of these areas, and much of this is just my thoughts from experience. There’s plenty more info out there on running open source projects.