In the last week, I experienced two completely opposite reactions, from two different partner organizations, to what was nearly the same discussion about how to proceed with the research and design of a mobile solution for a real-world human rights and internet freedom context. I wanted to reflect on these here, as I prepare to head west to Non-Profit Technology Conference in San Francisco to accept the 2012 Antonio Pizzigati Prize for Software in the Public Interest. I wish I had the chance to know Tony Pizzigati, but in lieu of that, I’ll do my best to represent the spirit in which his family honors him through this award. I also think that we would have gotten a long well, both as precocious kids hacking on neat problems at an early age, and as young adults eager to make an impact on the world.

What is most important to state is that the vast majority of what I have been able to accomplish in my efforts to apply technology solutions to social change needs, was due to relationships built, trust earned, support requested and problems presented, by real people in need of help to solve real problems. While some might see my work with the Guardian Project as the realm of myopic, open-source hackers locked away in a room trying to realize a crypto-anarchic nirvana, the truth is far from it. In truth, we have spent as much time talking with people, working through problems, proposing and testing solutions and  dealing with the true drudgery of real progress, over the last two years, as we have in front of our keyboards and screens.

standing on the roof of the world, with a mobile gadget in hand

For now, back to our previously mentioned partners. The first partner, after working on a variety of projects and proposals with them for the last year, clearly enunciated back to me, the exact view I hold on how the relationship between a non-profit and a software tool developer, should work. They said, and I paraphrase, “You see what we are doing here, together, is a process, trying to understand what it is that should be done, and for who, before we do it, and we need to communicate that to our larger community.” In this context, driven mostly by our partner, we were trying to understand the type of mobile technology available to their target community, and the existing interests people had in using mobile technology. It should be noted that this community is spread around the planet, separated by various cultural issues and dialects.

The other partner, an admittedly much newer acquaintance, was extremely confused when my team and I proposed a “phase 0” that would help us begin the collaborative process that we saw the entire partnership engagement becoming. Instead, we were told that this would not work, and that we were the experts, and should provide a full specification of what we proposed to build, and they would review and hopefully approve that, and then we would build it. As long as the spec was approved, and we built to it, the partnership would be determined to be a success.

I share these two extremes because they will help demonstrate to me a few points about the difference between developing software in a non-profit, social change context, versus a corporate, commercial or traditional software consultancy.

To some, especially those used to working in a typical client-consultant environment, the example of the first partner sounds like a disaster waiting to happen. Unclear goals, extended periods of open-ended discussions, too many stakeholders, and what is essentially a long “spec” phase. Even for those used to working in a non-profit environment, where budgets are traditionally tight, there is rarely the luxury to spend too much time engaging in this way. Still others might see the first partner as an easy gig, someone to milk money out of, while not really delivering anything substantial.

The second situation, might alternatively seem like an ideal one, where you have full reign to implement a nearly turn-key solution, based on existing components, and drive the process to maximum advantage and benefit. The less you are told by them, the better, because this is an opportunity to fund your vision for what you think they need. If the partner, truly just a client in this manner, has any issues, they should have raised them at the beginning, and it will cost dearly for any change to the plan down the road.

It may surprise you then, or it might already be obvious, that from my perspective, the first partner is the ideal one to work with in a social change context, while the latter is a much greater challenge. This is because our goal is to actual make change happen, and not just complete the client engagement successfully. Our duty is to determine if technology can plan a role in addressing a need, and if not, to walk away. The best way to work is to constantly revise what you are building, based on the latest information, feedback from the ground, and to constantantly iterate and tweak what you are supposed to be building. The second partner mostly just wants you to deliver on a contract, and when that is done, perhaps there will be an additional support contract for bug fixes, or another RFP to respond to.

Even more importantly, the partner, the people in need, should feel like they have a share in ownership of the process, and that the resulting product is as much theirs as yours. Rarely will the first version of what you develop be the big breakout hit or complete solution you expect it to be. All must be prepared to continue on a road map that includes multiple releases over a decent amount of time, that takes in account time it will take for users to adopt and share the tool. This could be a few months, or a couple of years. To support this, the partner should engage in the effort with the willingness to commit to ongoing support of not just the financial commitment, but the spirit of the project. If the effort is a core part of their plan, their campaigns and their process, the likelihood of adoption and overall success will be much higher.

Underlying all of this, is that, when you are doing this work as freely licensed, open-source software, the solutions you implement need to be more than just opaque, black-box products. To be truly open, and not just a dump of source code, they must be designed in a modular way that promotes re-use, be well documented, properly licensed, and shared in an easy to access public site. They should, when at all possible, make use of existing code from other projects, such that you work more efficiently, and support efforts of other tool developers and non-profits who support them. There should be some attempt to engage a community of developers and users around the code base, such that sustaining the work extends further than just the amount of money you can pay someone to bug fix it. Again, this is all perhaps counter-intuitive to a traditional consultant model, where investing time and energy into code you are going to give away for free, while also re-using other peoples code to reduce the amount you have to charge, does not always compute financially.

I will wrap this up by making a request to all of those eager hackers, developers, designers, consultants, companies and corporations out there, who have in the last few years begun to realize that doing work that does some good, can be a good thing for their businesses and reputation. Even if you come to this world of social change with the best of intentions, the process you may engage in may not be compatible or mutual beneficial to those you are trying to help. Please take a step back, and think about your goals, commitments, and the ability for the work to be sustained beyond this one hackathon, camp, event, or pro-bono engagement, before you promise to change the world.

Many thanks to the Pizzigati family for their support of my own personal attempt to change the world, slowly, one mobile phone at a time.

I’ve been thinking about some ways to improve a user’s understand or perception of what an app or service does or does not provide in the way of security, privacy or protection. This work is inspired by other efforts, including Mozilla’s Privacy Icons and the television and video game labeling standards. I think it is time that developers come up with a way to accurately communicate the benefits and risks their app brings, especially one it comes to personal or sensitive information, or users in high risk situations.

I began by breaking down the areas of possible concerns into three groups: User Identity (including location), Network Connectivity, and Data Storage & Access. These represent, collectively, who and where you are, how and when you are connecting and what you are accessing or sharing. I came up with a brief description of the positive and negative impact an app or service could have in each area. I then designed a basic icon for each, came up with a color scheme and a matching positive or negative charge indicator.

The goal of the icon design below is to indicate whether an app or service deals with these three areas of possible concern in a positive (go green!) or negative (warning yellow!) way. Very rarely will an app address all three, though sometimes used in combination a
solution can be made to do so. In some cases, an app might provide a benefit in one area,
while proving detrimental in another. We might also include one or two more icons to indicate how the security of the app was verified, a + meaning open-source, fully commercially audited, and a – meaning it only has a “trust us” model for security.

I hope to begin using these to label the apps and libraries provided by the Guardian Project to help better educate our users. If there are similar existing ways to label apps out there, we would be happy to consider them. Otherwise, please provide feedback below, or steal our cc-licensed SVG file, and make your own variations.

Mobile App Audit Icons SVG