Open Question – Persevering Through Technical White Water Rapids

By Scott Fairbanks and Rose Shuman – Question Box 

Our organization, Question Box, spent years creating and running local hotlines in rural, developing world communities. In 2010, the Question Box team agreed upon a major shift in direction. To achieve a real shift in development practice we needed move away from being implementers, and towards being a tool-provider. That way, we could spread and scale the promise of low-cost hotlines by taking what we had learned and creating a way for NGOs to build and manage their own hotlines.

Open Question, our software concept, was a keystone to building a hotline toolkit. Open Question is a software program that helps community organizations record data from incoming hotline calls, efficiently search for answers, and track call times, caller demographics, and answers to survey questions. The spec demanded a simple desktop interface that could work on offline, outdated computers in developing countries. Meaning, it had to be compatible with the likes of a Pentium II PC with 128 MB of RAM running Windows XP.

Almost two years later, the road we’ve traveled to arrive at the beta launch of the software has been anything but simple. The project involved four teams of programmers, three vanished third-party platforms, and countless hours of research, coding, and development.

We discovered that desktop software technology has become marginal in the developed world, while remaining critical in the developing world.  In the 21st century, the capacity to develop desktop-based software has been rapidly evaporating with the advent of web-based applications. Programmers today are generally not as fluent in Objective-C or Java as they are with web and mobile application development. That meant that our Open Question product is rooted in a disappearing art. Many programmers wanted to be a part of our project, but they were not able to build desktop software that met our spec – some worked on it up to a point, and others did not even get started.

We finally found a duo of programmers who did not in fact know how to build desktop software, but the grant from The Indigo Trust allowed our team to spend months learning how to do it. Eventually, they discovered a web-based engine called WinBinder that turned PHP code into desktop code.  Our team built code for the entire software program. After literally hundreds of build hours, we hit two major walls:

  1. We had built Google Desktop, a local file search engine, into the program. Google announced it was pulling Desktop, leaving us with an unusable software product.
  2. Furthermore, our spec was more like a web app than a desktop software spec. WinBinder was optimal for simple program creation, like To-Do lists. Our programme’s complexity was causing difficulties.

We had to scrap our entire work up to that point.  While building Open Question, our team was essentially sprinting across a bridge as it collapsed behind us. We learned a huge lesson about the risks in depending on third-party applications, particularly in the desktop space, where the economic incentives were not there for platform providers to keep the platforms open as more of the developed world migrated to the web.

This was a crucial juncture where The Indigo Trust’s support made a great difference.  Even though morale was a bit low, we had made a commitment to see the project through.  That extra accountability helped keep the team going.  Back at the drawing board, our programmers found a more robust open-source development kit called Appcelerator. They went back through the process of spending hundreds of hours writing code to rebuild the Open Question program, this time in a JavaScript-based platform and without the integrated local search function.

Just as we were working through the bug tests and nearing the end, the lights went out on Appcelerator.  The company developing the engine decided there was no reason to keep their desktop application service going – after all, the developed world had done away with desktop software years ago.  The company ceased to support desktop code creation, and stopped maintaining their servers.

This was a significant problem. The build got stuck for over two months. Having invested over a thousand hours writing code so far, our technical team was in a very tough position. The team began searching for a way around the Appcelerator shut down. Eventually, they found a hacker work-around, downloading pieces of the code-transforming engine from an open source website. They turned sections of their own desktop machines into servers that could handle the code-packaging load locally.

Over the past month, we’ve been through what we hope is the final round of bug testing on the software before the beta launch. We would not have invested so much of our resources were we not confident that the Open Question software has the potential to dramatically improve the effectiveness of organizations around the world by giving them the tools to run their own hotline.

The perseverance of our technical team has been tremendous, and they are the true heroes of this story, as there were several junctures where it was perfectly reasonable to call the entire enterprise “impossible.” It also would have been impossible without support from the Indigo Trust, which took a stake in a very challenging project.  We share the Trust’s belief that access to information leads to empowerment of communities, and as we share our technology with organizations around the globe, that same belief continues to guide our mission.

If your organization is interested in beta access to Open Question, kindly send a note to