FrontlineSMS started in 2005 with what seemed like a simple, clear ambition: make a tool that makes it easy for offline communities to communicate. The goal wasn’t innovation or profit, it was simply to get a useful tool into the hands of as many people as possible.
The first attempt—now lovingly called Frontline 0—did a better job of achieving that goal than expected. Frontline’s first user was Kubatana, who began using Frontline to coordinate political activism in Zimbabwe. Not long after that, a group called Nigerian Mobile Election Monitors used FrontlineSMS to monitor the Nigerian presidential election. Those uses garnered press attention, exposing both the potential and the shortcomings of Frontline. We could do better. And so we, mostly unwittingly, began the process of building something very, very different: a sustainable software company.
The moment Frontline became something more than an abstract notion embodied in code was also the moment everything became much more complicated. The ecosystem around the technology, it turned out, was much, much more complicated than building a piece of software. We’ve learned the hard way about limitations as a design philosophy; the inherent catch-22 in open source usability; and, ultimately, about the missing middle in open ecosystems.
Looking back, it feels naive to think that it could ever be simple—that delivering usable, open source, multi-channel tools that drive measurable, positive outcomes through text messaging could have ever felt inevitable. Nine years and many iterations (and tens of thousands of users) later, though, we’re more successful than ever—and mostly for unexpected reasons.
Limitation as a design philosophy
Let’s start at the beginning. Frontline’s original objective was to build communication tools for last-mile communities, meaning that limitations were a fundamental design consideration. In particular, the original design of FrontlineSMS was based on the hardware market as it was at the time. In many parts of the world, very little has changed.
In 2005, the two most prevalent forms of hardware in the world were laptops (PCs) and feature phones, as they are today. The world’s most used data channel was, and still is, Short Message Service (SMS). So, FrontlineSMS was originally designed to connect laptops to mobile networks, using feature phones or USB modems. The significant variation in connectivity hardware was one of our first surprises—as it turns out, the combination of modems, drivers, and carrier settings made it extremely difficult to source locally compatible hardware in last-mile markets. Eventually, we bought hardware that we tested and knew to work, and distributed it to users who were have trouble finding compatible modems in their local markets. Understanding hardware distribution, though, was just the beginning. Even where the hardware did work, average modem speed was 8 messages per minute, making bulk traffic extremely difficult.
Many of our early users were tech-savvy individuals, working with people who had limited experience with digital tools. That meant that we were fortunate to have a community of people who were able to both provide local support and report user feedback. That kind of user acceptance testing was invaluable in refining our interface, modeled after an inbox. We made it as simple and configurable as possible and translated the interface into the world’s most spoken languages. With each use case, we got insight about how to make the product leaner and more usable.
FrontlineSMS, as a file, was kept around 30MBs for most of its life, out of concern for intermittent connectivity and limited hard disk space. The system was designed to work offline, meaning that it created a local server on every user’s desktop, distributing the architecture and giving end users ownership over their own data. We made it free—not free as in speech, free as in beer. We provided as much user support as possible—we had an in-house rule of responding to every request within 24 hours. And, of course, we released it under an open source license (AGPL).
Each limitation became a part of our design standards—Frontline wasn’t ornate, but that was the point; it was as simple as it could possibly be to solve the problem it was designed for. It turns out, Frontline was a great fit for exactly the kind of communication SMS was designed for—local, contextual, actionable messages. Within the first few years, Frontline started to get media attention, attracting a growing diversity of users—both in terms of geography, size, and need.
The usability catch-22
As our user base grew, our team was faced with a fundamental decision: Who did we want our users to be? Targeting the technical community made it a lot easier to get attention and contribution, but much harder to get adoption by limiting the number of people who could use the software. Did we want Frontline to be a product targeted at a specific industry? Or, a platform that enabled users to continue to build on, configure, and apply our tools in their context, wherever that was? In other words, were we building for end users or for the open source community. At first, we'd hoped that we could do both, but learned that at some point in the life of any product, there's the catch-22 of building for developers or building for users.
We understood that the needs of our user base were diversifying—not only across geography, but by sector. The field of mHealth (healthcare supported by mobile devices) was growing rapidly, and so Frontline’s very first project director, Josh Nesbit, started the FrontlineSMS:Medic project (it has since become Medic Mobile, an inspirational clinical healthcare non-profit).
The rapid growth in popularity of the :Medic project served as a sign of what was possible when we paired a strong piece of technology with a more focused brand and a dedicated advocate. Shortly thereafter, through a series of volunteers, Frontline also launched the :Credit, :Legal, :Learn, and, eventually, :Radio projects. Each project was built from a common premise—that open source technology design could also apply to the growth of a brand and an organization. Each project was able to focus on a specific industry and apply, essentially, the same piece of core technology—FrontlineSMS. And that worked for a time.
As our user base grew and diversified, each project began to build new tools. We started with FrontlineForms, then PaymentView, then FrontlineSMS:Learn, which was essentially a grade book for course reminders and quizzes via SMS. Not only was the functionality of the app sprawling, but architecture of the product became harder to manage—we weren’t managing branches effectively and started to strain under the challenge providing a simply usable app with the configurability of visualization, data architecture, and, frankly, even terminology. We needed to start building translatable interfaces, so that one users’ students were another’s patients, and another’s clients.
It wasn’t just industry, though, our users continued to divide along an enormous range of preferences. These preferences aren’t just about rich or poor, coder or user they vary by an almost endless number of variables - role within an organization, custom or configurable, visual or textual, among many, many other factors. We were not only reaching the tech-savvy and open source communities, we were directly reaching people with no tech experience to speak of. And many of these users didn’t just want highly customized user interfaces, they also wanted to be able to connect with online communities.
At this point, the problems we were solving weren’t strictly technical, they contextual. They represent the less-discussed long tail of the open source world, where building a product isn’t just about new features, but about concertedly maintaining, rearchitecting, and scaling existing products. Although we continued to get contributions from the developer community, interest started to fade. In our (anecdotal) experience, it was much harder to attract the open source community to solve human usability problems or build the data architecture to measure (and thus prove) the practical value of implementing the tools we were building. That was an interesting aspect of us being a non-profit—unlike businesses, where convincing a user of the utility is enough, we also had to be able to quantify and prove that value to donors. Unfortunately, the value of Frontline, like the problems it was helping to solve, was almost entirely contextual—and getting good, contextual communications baseline data is really tough, especially in offline environments. Often as not, data generated by Frontline was the baseline.
For us, open source started as a way for us to lower barriers to access and to signal our intentions to the broader community. Unlike many others, we weren’t trying to peer into user data or pursue a commercial agenda, we were trying to build something truly useful. The lesson that we learned, though, was that once you prove your tool is useful, you have to quickly begin prioritizing: Are you serving the open source community, comprised mainly of developers? Or, do you serve non-technical end users, who prove value but don’t contribute code? Is your priority growing your open platform? Or, is it proving that it’s useful to people without technical skills?
The middle, missing mile
So, we chose the latter. We went with building a tool that others could use to prove measurable impact, no matter the context. That decision, probably more than any other, has shaped what Frontline has become.
The projects that wanted to specifically develop technology for one sector spun out, and the rest began contributing to the core code base, primarily from a single, in-house developer team. It was around that time that our culture changed—we were no longer just a product, we were an organization with a product and a mission.
In 2012, we completely rebuilt the platform. Within our first 7 years, Frontline had been downloaded approximately 25,000 times—by mid-2013, the new version of Frontline had been downloaded 200,000 times. We began a consulting practice to help organizations design, build, and apply Frontline with measurable results. We began building a quantifiable evidence base—saving some organizations as much as 97% of their communication costs. At the same time that we were noticing incredible gains in efficiency, we also began to realize something else: the last mile can only accomplish so much on its own.
We decided that it wasn’t enough to reach the last mile—to have real impact we had to connect those communities to to the “first mile.” We have to build the middle, missing mile. Real impact is not just about communicating on new platforms—or even using new tools—it’s about structuring and streamlining the connections between them in ways that create complementary efficiencies. This is just as true in technology as it is with roads, legal systems, governments, and commercial supply chains. Ultimately, communication technologies aren’t about building small, or even large, walled gardens, they’re about connecting people and organizations to maximize output while reducing latency.
As a usability challenge, we are now solving a very different problem. We aren’t designing for the last mile, nor are we designing for the first mile. We’re designing for the missing middle miles between them. From a technical perspective, that means designing for multiple platforms, using common data structures that can be interpreted back across the same, or even different platforms. Similarly, it means creating tool builders that are flexible by context—enabling people without Computer Science degrees to contribute meaningfully to systems built by people with Compter Science degrees.
More importantly, it means that negotiating new allocations of time, energy, and resources to meet common goals. This isn’t a problem that we’ll solve by thinking in databases, nor is it something that we need to tailor or standardize in every permutation or social context. This is a problem we’ll solve by building products that don’t force us to choose between developer interest and user value. It’s a problem that we’ll solve by opening the experience of building communication systems with more than licensing. Ultimately, it’s a problem we’ll solve, not by picking a context to build for, but building frameworks that connect contexts.
The great from here
So, that’s our plan. Frontline is building open, configurable tools that make it easier to connect and translate systems using the world’s most distributed technologies.
Some of those systems will exist in the last mile–whether they’re community health workers or arduino air quality monitors—and they’ll have FrontlineSMS as a free and openly usable platform. For the first mile, we’ll have FrontlineCloud, a cloud-hosted software as a service platform. And for the middle, well, the solutions will be a blend of open and open source, technical and social, free and not free. Just as we’re connecting the miles, we’ll connect more platforms, bridging platform, social context, and usability.
As always, we’ll strive to build tools that make it easy for communities to communicate. By building the missing middle mile, we’ll hopefully make it just as easy for the rest of the world to listen.
FOSS
This article is part of the Humanitarian FOSS column coordinated by Rikki Endsley. To share your projects and stories about how free and open source software is making the world a better place, contact us at open@opensource.com.
1 Comment