The house that open source built: why release modules?

SilverStripe loves open source. We've built a framework and content management system on the idea that everyone can share and build meaningful things through shared effort.

If you've got a website, there's a good chance you love open source too. Maybe you use projects like SilverStripe, WordPress or Joomla. There are many of these open source projects powering modern business.

Open source has proven to be an excellent way to write code.  And there are tangible benefits to making your code open source.  You don't have to create the next Apache web server, or Wikipedia. The code you're creating today could be just as valuable to the developers facing the same problems as you. It could be something as small as a module.

Modules

Photo by ozz13x

Let's take a step back and talk about modules. What is a module? I guess we could define it as a small set of reusable functionality. Something that could be neatly packaged and reusable in many different situations.

Say you have a blog, and decide to make a comments section for it. You could build it so that comments could be made on things other than blog posts, like images or products. You'd have to design your comments code so that it could be neatly packaged, and reusable in many different situations. That is what a module is.

And when you start to think in modules, instead of monoliths, your sites become glue between reusable code and business logic. You no longer have to settle for core functionality that hasn't adapted to changes in your business. Is your site using an outdated module? Get rid of it! Found another module that is better? Use that instead…

Benefits

Photo by Mikael Miettinen

Another  benefit of making open source modules is increased visibility for your code and organisation. Good developers know to look for alternatives before building their own code. When you start to release your modules to the world, people start to see you as part of the community.

More than that, other developers will start to use your code, and may spot errors. We're part of such a vibrant, helpful community. When these developers spot errors, they'll tell you about them, and offer suggestions for how to fix them.

So, instead of spending the time reinventing the wheel; you can use that time to build new software. To innovate in ways you might not have had the resources to before. To make your sites faster and more feature-rich.

Feed those improvements back into the open source community and you can be part of a virtuous cycle of improvement. Others may find your improvements free them up to work on the code underpinning your sites.

Collaboration

Photo by BiblioArchives / LibraryArchives

Tools like Github (a social code hosting platform) are ideal for these kinds of interactions. Github accounts are free, as is hosting for open source code. When you host your code there, you invite this kind of help from the community, and the benefits are worth far more than the effort you put in.

Be careful not to go overboard though. When you get excited about modular, open source development, it may be tempting to make everything a module. Some parts of your site are just too specific to your requirements for them to be useful to the wider community. You need to question whether those parts can actually be reused in many different situations. If not, perhaps they belong only as part of your project.

Common Concerns

What am I responsible for? Do I have to maintain/fix/improve this code?

You are responsible for as much or as little as you want to be. The main thing is to communicate this to developers/organisations who want to use your code. For example, we have a standard for the modules we commercially support. This standard explains exactly how much responsibility we take for our modules.

If you plan on adding new features, and/or fixing security issues, then say as much in the description of your module. If you just want to throw the code over the wall, that’s ok as long as you are clear about it. You aren’t obligated to support code you open source. But you’re being a good community member by avoiding potential misunderstandings.

Will people be able to hack me if they can read my code?

That depends on what you open source. Avoid publishing any sensitive data, like database backups or keys/passwords to third-party services. That kind of thing is more likely if you’re trying to open source a project. On the other hand, modules don’t often contain large amounts of sensitive data. If you wouldn’t tell it to a stranger, don’t put it on Github.

Can I be sued if someone uses my code illegally?

Again, this is about communication. When you open source your code, you can choose which license applies to it. We recommend a permissive license, like MIT or BSD 3-Clause. These are clear when it comes to misuse of your code.

If you use one of these licenses, you are not responsible for how someone else uses your code. When they use your code, they do so under the license you have chosen, and that includes a disclaimer to protect you from any problems they cause as a result of using your code.

Conclusion

Hopefully you're excited about the thought of creating your first module. Or maybe you've been reminded why you created your first module. Look out for our upcoming video series on how to create awesome, open source modules!