GSoC 2020 Ideas: Ushahidi

NOTE: This ideas list is under development and will likely be changed up through the official announcement of GSoC 2020 projects. Please also visit the Google Summer of Code 2020 @ Open Source Center page for other sub-org information and details.


Ushahidi Overview

For all projects, we recommend the following steps to get started:

  1. Set up the Platform dev-environment (instructions are here:, most of us use the Vagrant setup)
  2. Play around with the platform, login, change settings, add posts and surveys. There is a user-manual to be found here:
  3. Grab one of the issues marked with the label good-first-issue here: All issues for both the Platform-API ( and for the web-client ( are stored there.

Potential mentors for all project ideas on this page are available to answer your questions! Connect with us on Chat with general questions, or contact any of the Ushahidi Mentorship Team (subject to change!):

2020 Potential Project Ideas List

Project 1: GMail™️ data source

Many of the current Ushahidi Platform deployers who use the POP/IMAP e-mail data source are configured with GMail servers.

Due to security concerns, there’s only a couple very specific ways in which Google allows this to happen. This can be either of these two ways:

  1. Using the associated google account password. This is only possible if downgrading the security of said google account, enabling “Less Secure App” access.
  2. Enabling 2-step verification and App passwords. Using this approach an app-specific password for POP/IMAP access can be generated and used to access the server.

Google has recently announced that the “Less Secure Apps Access” setting will be completely phased out by February 2021. This will render the first approach unavailable.

We have observed that many deployers don’t use the second (arguably more secure) approach due to the inconvenience / overhead of using 2-step verification in an ad-hoc account that has been opened for the specific project or deployment , which may also be shared with other project volunteers.

This will effectively impose a barrier to use the free, convenient and reliable GMail service as a data source for the Ushahidi Platform.

Proposed solution
We are proposing to introduce GMail specific support into the Ushahidi Platform code, as its own specific data source.

This new data source would be implemented interact with the GMail service using its API. This should ensure better support and integration with the service.

Implementation guidelines

  • The objective is to significantly advance the project to a state where it can be used by the community at large and in production systems used by grassroots organisations over the globe.
  • It will be necessary to store GMail API credentials on the platform database.
  • The datasource shall provide both incoming and outgoing functionality.
    • Incoming e-mail messages are sent by deployment reporters.
    • Outgoing e-mail messages are sent to reporters by deployment administrators and volunteers in response to the original messages sent by reporters.
  • OAuth2 flow for Web server applications to be implemented in the Ushahidi Platform backend.
  • The data source component should use refresh tokens with the GMail API in order to keep authenticated.
  • The data source will be checking with the GMail API in the background, most often executed as a cron job (artisan datasource:incoming and artisan datasource:outgoing)
    • A current shortcoming of the data source system is that there is no way to surface to the end-users errors that happened in the background execution. It may be necessary to coordinate with other project developers to improve this.
  • Bonus: integration with Laravel/Lumen mailing system for sending other messages (i.e. notifications)

Skills: PHP, Laravel , HTTP, API, HTML / CSS / Javascript

Difficulty level: Difficult

Related readings:

Project 2: Ushahidi Platform Voice integration

Currently, the Ushahidi platform supports data collection via SMS, Email, Twitter and smartphone apps.

Even with this different available alternatives, there are circumstances where reporting is still not feasible or sufficiently convenient. Some individuals may not have the required literacy skills to write their report, or may not be able to operate the necessary devices in order to input data. During a natural disaster, infrastructure may fail, leaving no internet or cellular connectivity working in the area.

Proposed solution
A type of data that is currently not being enabled for Ushahidi Platform deployments is voice.

Voice has the advantage to being accessible to individuals regardless of their literacy skills and can be less cumbersome to produce than typing into a device. Also, there have been instances of natural disasters where the only remaining infrastructure were landlines and radios.

Implementation guidelines

  • This project’s aims to complete an experimental / proof-of-concept exercise
    • The purpose is to explore the idea and possibly try it out with a small controlled group of end-users.
  • We suggest (not enforce) receiving the voice data from a voice phone API , such as i.e. Twilio Voice .
    • Other alternatives (i.e. based on radio technology) welcome to be mentioned in the application.
  • Due to the experimental nature of this project, there is a certain latitude here and we are glad to hear of any specific implementation ideas in your application.
  • Rather than re-inventing the wheel with the speech-to-text transcription, it’s expected to interface with one or several of the different speech-to-text services available out there.
  • The minimal necessity at this point is for the service to be able to deliver a single message per report to the Ushahidi Platform.
    • This is similar to the functionality currently provided by the SMS data source.
    • As opposed to the more complex mode of operation, which we refer to as structured data capture. In that case, several messages are to be received from the reporter for each submission, in order to fill a survey form. This would usually require a more sophisticated, conversational (IVR system) approach.

Skills: PHP, systems design, HTTP API

Difficulty level: Difficult

Related readings:

Project 3: Content disclaimer + work in platform

The Ushahidi Platform is a crowdsourcing tool where users can collect, visualise, analyse and share information. The information can sometimes be of sensitive, objectionable or offensive by some readers and therefore we want to provide the possibility for the deployers of the tool to choose to turn on a “Content disclaimer” (similar to what Wikipedia uses:

Implementation guidelines
The project aims to create a Content disclaimer that deployers can turn on,off and adjust the content in. The project can potentially use the existing notification-bar we use in Platform when showing error-messages and information to the user. The project will include

  • Creating this disclaimer in our web-client
  • Creating a way for the deployer to turn on and off the disclaimer and adjust its content in the settings
  • Making needed changes to the backend and database to save the settings

Depending on the level of the intern, this could take the full internship or be finished earlier. If it is finished earlier, the intern will work with front-end issues creating features and bug-fixing together with the Ushahidi team.

Skills: Javascript (AngularJS, version 1.5.6), php, mySql

Difficulty level: Intermediate

Related readings:

Awesome!! Thanks for sharing @angela
I’ve joined the Gitter channel and currently reading the docs. Really excited to learn more about Ushahidi and it’s global impact.

1 Like