Build Software Like You Would Build A Hub
Pieter Hintjens, one of my favourite speaker, says that software is people. Hence, the way its developers are organized has an impact on the architecture. That's why Free and Open Source Software are different from closed ones. They are the result of many contributions from different people.
So, to build FOSS software, you should choose an architecture and a behaviour that allows others to contribute easily. To make your project successful, think it as a hub, make it simple for others to connect to your creation.
Architecture
To design the architecture, you can rely on four principles:
- Make an extensible core (put main features in separate files): adding or modifying a feature will be easier. It will allow parallel work ;
- Have a clearly defined API (allow to build something on top of your software): if other tools rely on your application, their authors will help you making it better and will promote it ;
- Join an ecosystem (propose an API based on standard protocols like RSS, ICal, XMPP, etc.): already existing applications will be able to connect with your tool. Existing community could get interested in what you are doing ;
- Allow external plugins (make your soft extensible without modifying the main repository): it is the simplest way for contributors to augment your program, they don't even need your authorization to contribute.
Examples
Task runners are best example of hubs (Gulp, Webpack, etc.). They are based on plugins and they allow people to build their additions in a separate repository. It's easy for people to bring new features without needing intervention from core maintainers.
Another good example is Konnectors, a Cozy app with 25 contributors. Konnectors is a tool that allows to run a bunch of scripts to grab data from websites you use everyday. Here people can add a new script without changing or understanding the core.
Another code you can check, is the one from d3.js. Every part of this library is separated in NPM submodules. A quote from Mike Bostoc, the author, explains his motivation:
«Good software is approachable. It can be understood completely in independent, easy pieces. You don’t need to understand everything before you can understand anything.»
(By the way, I recommend the full article)
Behaviour
Having a proper architecture is not enough to encourage connections. You must have an inviting behaviour:
- Act friendly and integrate contribution you receive as fast as possible. Too much back and forth is repelling ;
- Be nice and express rejection only after admitting that the contributor is right on some way ;
- Emphasize tickets that newcomers can fix ;
- Make sure that you documented everything: license, contributing guide and global architecture. ;
- Add credits for contributions ;
- Offer spaces for people to discuss like a forum or a mailing-list.
The main idea is to make it easy. You should remove every block on the road of the contribution.
To conclude
Let's wrap things up! Making your open source software contribution friendly requires an architecture based on extensibility. Once your program has a basis open to contribution, you just have to make contributors happy. You will ensure that your software will become a hub interconnecting people and used by many.