We get it. Open source development can be hard. It sounds great – developing Free Open Source Software (FOSS) means that your code is licensed to be free to use, modify, and distribute. Think of it like this: you’re not only sharing a loaf of bread that you baked, but also the recipe so that others can make it themselves – what a lovely concept! But open source development can be intimidating. Opening your code for the world to critique can be uncomfortable, and successful collaboration is a lot of effort. Your team needs to be responsive, humble and open – and that’s not easy! But we at HURIDOCS are here to say: it’s so worth it. Here’s why:
We want to build solutions with the human rights community, not as experts for them. Open source developments provides an opportunity to learn what your users actually need, thus improving the final product. It’s what provides a bridge between human rights defenders and tool developers because there are public channels for ongoing interaction. This interaction is what drives future planning and product roadmaps.
By keeping your code closed, you are sending the message that you don’t trust their abilities and that, “we are the experts and you will likely make mistakes.” But these users probably have a really good reason for wanting to adapt the code, and that they will likely want to find a good solution with you if you have the appropriate channels to take that on. With open source development you are more likely to have those open channels for collaboration available from day one.
We produce better products. We believe that in the long run, open source projects are more likely to produce better technology.
- When the code is open for any developer to provide feedback on and contribute to, it can only get better. It’s about acknowledging no one (team) knows it all and knows it better, but that together we can come up with ideas that are more than the sum of its part.
- It forces us to have transparency and humility about error and sources of vulnerability.
- We get better at what we’re doing because we get more feedback.
- And it allows for the ongoing exchange of knowledge and inspiration – what better way to learn how to code, than by looking at how others have done it!
We need to use our limited resources wisely and responsibly. It’s important to be good stewards with the limited resources available for human rights technology development. Many of these initiatives are grant-funded and are created for the public interest, so we feel it is our responsibility to share the code back to the public. And it’s good to know that the code will remain public and available for other developers to pick it up where we left off.
It makes our tools more secure. Now this is where there is some debate. There’s a lot to consider related to security when building tools for human rights defenders: anonymity, privacy, sustainability, accessibility, consent, etc. Open source development does not guarantee security, look at the HeartBleed bug for example, but we strongly believe that in order to address any of these security issues, the technology must be free and open source. Some may disagree because:
- if you open your code, you may be exposing hints to attackers who can find and exploit your vulnerabilities, or
- if anyone was able to modify your very complicated code, they may inadvertently put themselves at risk.
We don’t think these arguments hold up. Security by Obscurity, the reliance on the secrecy of the design, can lead developers and users to a false feeling of security. We believe it’s more risky to keep the code hidden and rely on the good intentions (not to mention the excellent coding skills) of the organisation, developers, and hosts. In the long run, it’s best to have a community of allies and users to help you find and fix flaws and vulnerabilities throughout the life of your project. Ultimately, we believe our users have the right to know what the application is doing with their information, and we have the responsibility to be transparent about this.
There is a lot that we have learned about open source development over the years. We have learned how not to open source your code and how to start a new project as open source from day one. We know there’s still a lot that we can improve and we’re applying these lessons to the way we are developing our newest tool, Uwazi. We also know that developing these tools as open source is better in the long-run – it lays the foundation for high quality, secure, collaborative results. We wouldn’t have it any other way.
This blog post was written with valuable contributions from: Tom Longley, Gabriela Rodríguez, Seamus Tuohy, Dirk Slater, Jaume Cardona and Friedhelm Weinberg. THANK YOU!