3rd August, 2013

Technagara has been my primary focus at Mapunity for the good part of my 3 years at Mapunity. I have been the lead developer on the project (and the only developer for most parts) which included Ashwin Mahesh (Mapunity’s CEO), developers, content developers, multiple designers and citizen groups. Let’s get the customary disclaimer out of the way. This essay is purely a personal perspective and does not reflect Mapunity’s official position on the project.

So, Technagara is a collection of domain platforms for cities. To draw an analogy, Stack Exchange for instance, is a collection of Q & A domain platforms such as Programming, Travel, Money etc. Similarly, Technagara encompasses domains such as Governance and Heritage, and is planned to include Transport, Environment, Public Safety etc soon. Further, Technagara’s domain platforms have custom deployments for individual cities. So, Bangalore has it’s own governance system and Chennai it’s own heritage system and so on. You get the idea.

We started the Technagara project with a governance platform for Bangalore called BCity. The aim was primarily to help government agencies manage the city better. Among other things such as news, forms, projects, and maps, the focal point of attention was getting people to report issues in Bangalore. We wanted to then feed these issues into the processes of civic agencies in the hope that they would in turn resolve these issues, hence resulting in a healthy feedback loop of, issues being reported and discussed, and consequently, agencies taking appropriate action.

Civic agencies in India aren’t divided in a way you’d normally expect for the most part. For example, Bangalore’s electricity board is responsible for most electrical supply & maintenance issues but not for street lights maintenance, which falls under the purview of Bangalore’s city municipality, which in turn is responsible for a bunch of other things. So, from a citizen’s perspective, it becomes very hard to even know which agency is responsible for what because of un-intuitive responsibility “sharing” amongst mostly non-collaborative agencies. From an administrative perspective, the biggest problem with this kind of a setup is that, these systems barely talk to each other, hence completely throwing the possibility of “collaborative problem solving”, out of the window.

As a side-effect of this non-collaborative approach to governance, the grievance reporting mechanisms are also, highly fragmented. Technagara’s first intent was to fix this. So, we presented a single interface that only required you to know which category or topic (Water, Roads) this issue was mostly associated with, the location (if any) and contact details. Technagara has an internal system where admins ensure that issues are correctly tagged with the concerned civic agency as well. But, as we expected the most common query regarding the issue reporting system was - What actually happens to the reported issues?

An admin within the system generates reports of issues, which are sorted by agencies and sends them to the respective city’s civic agencies (such as BBMP, BESCOM, BWSSB etc. in Bangalore’s case). The critical part though is, the absence of a feedback loop. Some issues do get resolved, but typically, agencies do not get back to inform Technagara about which issues were actually resolved. In contrast, sites like Public Stuff, SeeClickFix are in sync with their respective government systems in the US i.e they have a healthy feedback loop that updates people who reported their issues, on a regular basis.

Coming back to Technagara, despite the government not being actively involved, I think there’s still value in documenting issues in the city because it gives rise to a new range of possibilities. Knowing actual problems on the ground better informs our dialog and decisions. Let’s say you’re moving into a new locality. It’s useful to get a handle on the kind of issues that are prevalent and know what kind of a locality you’re going to. Even if government agencies do not act upon issues, this data is open to NGOs and other citizen interest groups who can actually go ahead and solve a subset of issues themselves, with minimal or no government intervention. The point being, by bringing more data into the picture, you consequently are involved in more informed discussions.

The “government by the people” part of democracy in India, is largely limited to voting. For instance, unlike a few western countries, there aren’t any referendums on important bills. Effectively, we aren’t tapping into a rich source of information and ideas i.e the public. And essentially, you have a government that attempts to take on a herculean task of bearing all the weight on its own without involving citizens in solving problems. This proposition raises a few questions. What if you could augment the capacity of government agencies with technology and know-how from citizens? Would that enable the government to move faster? I suspect, this was the genesis of Ashwin’s idea of “public problem solving”.

Once we felt we had a relatively stable platform for governance, we set out to build a heritage platform out of Technagara, next. The idea is basically to make it easy to read and learn about a city’s local history and heritage. For a starting point, Bangalore Heritage, for instance, showcases various heritage spots of interest on a map, a set of chronologically ordered events and a gallery of pictures and paintings. People seemed to take notice when I shared Bangalore Heritage on Twitter.

To conclude, developing Technagara has been nothing short of a fantastic learning experience. I’m glad I got the opportunity to develop a product from scratch, be involved in the process of iterating and improving the product based on feedback, experiment with the technology stack and collaborate with a number of talented people on the project. My journey at Mapunity came to an end this July, 2013. I can now only hope that Technagara proves to be useful and continues to grow.

If you'd like to keep in touch, I post updates on Twitter and LinkedIn.