This time in 2014 I was working the Ashoka Globalizer team in preparation for the Globalizer Summit in Bonn in June of that year to evaluate the work we were doing in terms of its readiness for global scale. The Globalizer exercise came with the great privilege of working with a world class consulting team comprising of one global entrepreneur and Ashoka fellow and two analytical experts from McKinsey and Co. Working with this distinguished team, we crunched up the numbers from our work with CGNet Swara, a pioneering citizen journalism effort and our flagship project at the time. Our goal had been to analyze whether the model, i.e. using a localized interactive voice response system to create a voice based bulletin board or “audio portal” for newsgathering and community interaction from remote areas where media and the Internet had not penetrated, was ready for global application and scale.
The indicators at the time seemed to suggest that it was, since we had replicated the technology successfully for use-cases in Afghanistan and Indonesia. However, on analyzing the numbers we realized that while the model was very successful in terms of bringing content out of and into media/connectivity dark regions, the cost at which it did so was not strictly sustainable unless an external party or parties were willing to support it.
While differential costs of communication and data access as well as policy plays a major role in determining the cost of a technological intervention of this nature, an equally significant role is played by the design of the system and its intended scaling strategy.
For a system that seeks to retain its character through the course of scale, whether in the interest of maintaining quality or preserving brand value, the costs of scaling are significantly higher.
In the case of CGNet Swara, what we learned was in line with what we had been told by experts from Google fairly early on. The two major impediments to scale were 1) the fact that the project sought to remain completely free for access by users, on the pretext that they would otherwise find it too expensive to use and 2) the need to maintain a centralized moderation strategy that filters content prior to release.
Both of these strategies were initially employed to engage users and maintain quality.
To attract a largely low income population to use the system, the design was set up to respond to a “missed call” placed by end users with an outgoing call from the system. The end user therefore ended up paying nothing. Had a telecom operator been supporting the system, this would have been infinitely sustainable. However, the project was paying retail prices to purchase telephone airtime, which while infinitely cheaper than broadcast media was still quite expensive at scale, resulting in a large cashflow requirement. Had this been distributed by encouraging more replications, the costs of data collection could have been distributed.
Since the platform was initially implemented by individuals who were solely liable for the content being released, the choice to filter certain content was made to ensure continued operation of the platform free from state intervention. What the team failed to take into account was that this was relevant only as far as the platform was publishing news anonymously on behalf of callers. When the decision was made to publish the users name in the interest of transparency, the responsibility of the content was already on the user. At this point, the filtering mechanism could have changed from a “screen and release filtered content” to “publish and remove reportedly offensive content”. The requirement would have been to explain the liability of publication clearly to users via a terms of use communication.
Had these two mechanisms been employed, the system could have evolved to being an aggregator of content from several replications, which would have been a far more sustainable and scalable option.
We have seen similar patterns in most other technological interventions. The need to maintain centralized control and ownership often prevents organic scale that could come from free replication.
With this learning, we have since been working on ways to enable more replication than growth in our projects. The growth element is now redirected towards growing capacity as well as enabling growth in numbers of replications rather than growing a single system
For example, with our COWMesh project , we have taken the approach of not directly implementing solutions for communities but to enable communities to set up their own systems after observing what is possible on demonstrative systems which Mojolab maintains and travels to community locations with.
Given the gap in skill availability at the grassroots and skill requirement to use open source tools, we have simultaneously been working on setting up mechanisms to train more and more people at the grassroots who can then utilize their skills locally. This element of our work is where we currently need the most support.
We therefore invite collaboration from anyone who wish to improve skill availability at the grassroots.