Why open source code sharing works well for social justice organisations.

The four top reasons are:

1. Better code: Sharing means better, more secure code because more people need it to work well. More users in different contexts, more developers looking over the code, means more people to spot problems and raise issues.
2. Lower costs: No arbitrary licence fees or limits.
3. Flexibility: You can improve it and tweak it where you need to.
4. Reduced risk: You can take it with you to another provider, you're not locked-in to one company.

Flexibility

Sometimes you need something to work a particular way. Once you've clarified how you need it to work, there's various ways to approach this.

• Settings. Can you achieve it by tweaking the provided settings/configuration options? Great! All done!
• Maintain your customisations using "hooks" provided by the software. Think of a rubber-duck race, where all the ducks have been provided with hooks on their heads. At certain parts of their journey, you could sit at the side of the stream and hook them out, do what you want, and perhaps pop them back in to continue their normal journey. This is great because your changes will still work over time - as long as the ducks have the same hooks, you can keep doing the same thing. This is a very cost-efficient way to maintain your tweaks. But some ducks might not have hooks you can reach.
• Make changes to the code locally and keep them to yourself. This is great when it's something that only you are going to need. It's cost effective way to customise things in the short term - you're only paying for the tweaks you need, and you can test them to your satisfaction; your changes won't affect other users. Over time, when new versions of the software are released you will need to re-do and re-test these changes though - or avoid updating which is not a good long term strategy.
• Suggest your changes to the project. Maybe you found a bug and got it fixed; you could suggest that your changes are incorporated in future versions of the software, so that you and everyone else will benefit. Likewise if you added a feature that others could use. This option costs a little more - it takes time to negotiate the changes, and it requires time from the project maintainers to consider, discuss and finally agree to include your changes. But it means your improvements are going to be included from now on, so no nasty surprises on the next upgrade! And, you've helped others. It's not a win-lose zero-sum game. Finally, it's also improves the quality of your changes: other people will judge whether it looks sensible and they might spot a problem you haven't!
• "Fork" the project. Think creating a fork in a road, so now there's a choice of 2 roads, which start from the same place, might run parallel for a bit but could go in different directions. Generally it's best to avoid doing this; it's better to work together on one project. But if needs must, forking a project means you take on maintaining a version that works differently. You can do it because of the open source license; a proprietary product would not let you do this.