30 NovFiled under blog
p>Ken Banks recently wrote on kiwanja.net about the philosophy and niche of the core FrontlineSMS platform. He addressed five issues that are central to our field, and he called the post a social mobile line in the sand. While we work closely with the core FrontlineSMS team and share much of their philosophy, our motivation for forming our spin-off health oriented community was that we wanted to focus on a slightly different niche. Hopefully this post will help you understand how were are similar to and different from the core FrontlineSMS team, and every other mobile tool out there.
1. Who are your target audience?
The Frontline Philosophy: To begin with, we’re focused on serving organizations that work to improve human health. And like Kiwanja.net and the core FrontlineSMS team, we focus on the “long tail.” This graph sums up the long tail idea well:
Our team differs from Kiwanja.net’s approach to the long tail in one important way. Ken Banks usually talks about where organizations sit on this graph. Instead, we look at where specific use cases or projects sit on the graph. If you’re a grassroots NGO with 2-3 people on staff, no tech experience, and a shoestring budget, then all of your projects and capabilities should fall in the green part of this graph. You might also be an international NGO with a multi-million dollar budget and a big IT team, but chances are you have some use cases or projects that your IT experts can’t contribute much time to, or where you need to stretch every dollar a very, very long way, or where you work in an impossibly remote and low infrastructure area whose needs are entirely different than other parts of your service area. These are what we’d call long tail use cases. Such organizations might find a rewarding cost/benefit equation for implementing expensive, complicated medical record systems at referral hospitals, perhaps even district hospitals. But for long tail use cases at remote health centers they will need a tool with a frontlines philosophy (whether or not they end up using FrontlineSMS).
2. What is your position on scaling?
Like Kiwanja.net, we focus on horizontal scale, rather than vertical scale. For a generic example of horizontal scale, think of ten independently managed platforms serving 10,000 people each, as opposed to a single centrally managed platform serving 100,000 people. We choose the horizontal, modular approach because we do not want to centralize:
knowledge transfer, learning, and the empowerment that comes from a job well done.
use of gathered data
user ownership and enthusiasm
decision making authority
funding requirements (and potential for failure if they aren’t met)
We also like it when end users can make their own technology decisions (rather than having to defer to an official who will never actually use the tool directly), and we like it when ambitious groups can charge ahead without having to wait for their entire country/district/the domain of any vertically scaled system to catch up.
We do, however, find it absolutely essential to be able to centralize one thing: data. For a huge number of reasons, from pharmacy and supplies procurement, to fund-raising, to disease outbreak management, to research. Exchanging data, of course, can be achieved by representing data in agreed upon formats and transferring via a variety of channels – from Internet, to SMS, to USB sticks carried by bicycle.
3. How does it replicate and grow?
Kiwanja.net couldn’t have said it better: “growth is based on patience, and a “pull” rather than “push” approach, i.e. awareness-raising and then letting NGOs decide if they want to try out the tool or not. Those that do then go and request it from the website. Everything is driven by the end user.”
At the request of partner organizations, we do have a core team of experts that manage a small number of implementations. The majority of implementations, however, only rely on us for the free software and a lot of advice and support (mostly via email). As an organization, we have plenty of growing up left to do, and we’re still figuring out how to portray to the public that we don’t want to (and frankly can’t) manage or direct most implementations of FrontlineSMS and associated tools in health care settings.
We recently decided to start using the term reference implementations to describe the small number of programs that our core team of experts oversees directly. Moving forward, reference implementations will be selected because they pioneer a new piece of software, an important new use case or methodology, or in some way contribute substantially to the larger Frontline community. All other projects are community implementations, and we are pleased to support them with free software, direct email with our team, and upcoming public email lists and a wiki-based field guide. Hat tip to the OpenMRS community for the framing of reference and community implementations.
4. What is your position on open sourcing?
In addition to sharing source code, we strive to live up to principles that are common among community developed projects, such as openness and transparency, bias towards collaboration rather than reinventing the wheel, and sharing the fruits of our labors as freely and widely as possible. That said, we prioritize impact for our users, and we are realistic about the substantial resources required to collaborate – to license code and make sure it’s commented and documented thoroughly enough to support developer collaboration. We sympathize with the many young and low resourced open source projects that are so busy supporting users that they leave something to be desired for strict open source advocates. We’re still in the process of working out licensing of PatientView and setting up our wiki and public mailing lists. We hope you’ll give us the benefit of the doubt and (collegially) hold us accountable in this regard.
5. Does access to “the cloud” matter?
Yes, the cloud matters; it is the future, but not the present on the frontlines of global health. I mean this more as an observation than as an opinion – the cloud simply cannot be accessed with any regularity in the vast majority of places where we work. We want everything we do to accelerate movement towards sophisticated use of low cost, easily accessible cloud based apps, but starting with apps that work exclusively in the cloud or even rely on the Internet just isn’t the best way to do this. Paper based societies need to get their feet in the door with tools that work NOW, but have been designed to point the way to cloudville. How can an SMS platform built on disconnected laptops point the way to cloudville? Under the “scaling” section we hinted at the importance of data standards and platform interoperability. We’re making sure FrontlineSMS plays nice with various cloud based apps. We may even start working in the cloud ourselves someday, but not just yet.
So, that’s our line in the sand. If anyone else has a mobile tool – or is working on a mobile tool – I’d encourage them to clear up any possible confusion and write a post outlining their thinking in these five areas.