Community-sourced recommendations on sustaining open source products

At the Internet Freedom Festival, we had the opportunity to host a session on the sustainability of open source products. Here are some resulting insights.

By Friedhelm Weinberg on

Most of the technological aspirations and objectives that we pursue in the human rights and internet freedom communities–transparency, security, openness for modification/adaptation to different contexts, etc.– are necessarily based on Free and Open-source Software (FOSS). However, launching a successful FOSS project can present significant challenges.

This March at the Internet Freedom Festival (IFF) in Valencia, we had the opportunity to host a session that we lovingly entitled FOSS or FOSSIL: How can we ensure the sustainability of open source products?  The session brought together people who are working on FOSS development projects to share their challenges, experiences, and ideas. In this blog post, we wanted to capture some of the very helpful recommendations that participants offered.

On financial sustainability:

  • Crowdfunding can be good for transparency, accountability, and sustainability. Seeking funding from the community of users and contributors can help to validate the need for your specific tool (conversely, if no one wants to contribute financially to your tool, then it may not be that important), and can help ensure that your tool development responds to actual user needs. It can provide more transparency on where money is spent, including for vital but unsexy things like maintenance. This can be good for accountability and can educate users about true operating costs (i.e. maintenance is not free!).
  • Keep funders and clients engaged and informed. Contracts based on agile development methodology are often poorly understood by funders and clients. One approach that can be helpful is to explain to the funder/client that s/he can define two of the following three parameters: timeline, cost, or features. That offers the funder/client an opportunity to establish his or her priorities. When speaking with funders/clients, it’s also important to focus  on the goal(s) of the development project and not on building a tool that is fully pre-defined.

On sustaining contributors (users and developers):

  • Motivate and inspire your team. Give your development team opportunities to learn about FOSS development and why it’s important. One idea is to encourage them become a mentor/coach for Google’s Summer of Code. Through this opportunity, developers learn about distinct roles within a FOSS project (e.g. product owner), how to be a good mentor, and what it means to get involved in a FOSS project. Bringing developers and users together often has an amazing positive impact on developer motivation. Similarly, matching programmers with designers can be a fun and effective way of tackling problems.
  • If you have to choose, focus on user community over developer community. Why? Because if you spend your energy exclusively on building a community of developers, then you risk creating something far enough away from users’ needs that no one actually uses your tool. By contrast, if you spend your energy building  an active user base (and useful tool), it will be that much easier to motivate developers to contribute.
  • Make clear how users can contribute and what is needed. For non-developers, it can be hard to know how to contribute to a FOSS project, beyond filing a bug report. It can be helpful to have contributor champions, who model good participation (such as submitting feature requests, posting questions, adding to the user guide, and responding to questions in the issue queue). While it can take time to mentor these champions, it is usually worth the effort. Also, invest time and effort in curating your Github issue queue. Use smart tags that make issues understandable to new contributors. Think of yourself as a teacher, not a developer. Small tasks provide an easy win for someone who wants to get involved. Make it easy for busy contributors by providing crystal clear documentation on issues, and breaking them down into tasks that can be accomplished in a week.
  • Be accessible! Be active on IRC and other communications channels where your contributors are spending time. If possible, offer your documentation in other languages than English. This will provide an opportunity for non-English speakers to get involved as contributors and users. Participating in an open source project can be intimidating for beginners; just imagine what it is like to contribute in a language that isn’t your native tongue!
  • Identify a Product Owner. This is an important role in a FOSS project – the product owner bridges the gap between users, development, and strategy.

One challenge that panelists were unable to offer recommendations for was securing funding for maintaining FOSS tools. Without ongoing and consistent maintenance, software is exposed to security vulnerabilities; yet even though maintenance is an important part of FOSS development, it is the hardest activity for which to secure funding.

If you have ideas or recommendations to share on how to sustain FOSS products, please let us know!


Posted in: