You can find this article on my blog too.

This writing is intended for people who may be interested in making "Tech for Good". #Tech4Good

This is also intended for people who may come from a privileged background, consider themselves an ally to under-privileged groups, and who want to help their community and be civically engaged. #Resist.

Also, I know how simplistic and corporately co-opted the term "Tech for Good" is, but I want you to overlook that for the sake of letting me write something that's digestible. #Lunch

Who am I? I'm a freelance developer / houseplant killer who is currently working on the NYC Building Monitor, a tool to help NYC tenants make informed housing decisions and fight for their housing rights. It's a long story, but I essentially made this app to replicate the success I had in using NYC Open Data to win a fight against my landlord.

Here's a quick checklist to keep in mind if you ever find yourself working on a Tech for Good project.

The Checklist

1. Check your bias and priviledge first.
2. Don't parachute in.
3. Be accessible.
4. Let the community steer (but don't exploit them).
5. Protect yourself and your project from being co-opted.
6. Protect your community from being abused.
7. Let the community ultimately solve the problem.

1) Check your bias and priviledge first.

There are an untold number of projects that are predicated by a biased or privileged worldview that end up reinforcing the asymmetric power dynamic that causes social inequality.

I remember attending a hackathon years ago where the theme was to prototype a solution that would help women deal with a social or political issue they're facing. One of the presentations involved an app to combat street harassment by displaying a map that showed people the crime levels on a city block level with the idea being that someone could use this map to avoid walking through a "bad neighborhood".

Let's break down what's wrong with this idea.

• It assumes that we live in a world where catcalling and street harassment gets reported and taken seriously as crime (we don't).

• It utilizes inherently biased crime data in an uncritical way. Using any crime date in a "predictive" way only serves to reinforce racial bias. (Crime data is known to be racially biased just like the police force is.)

• The problem with street harassment isn't that women and gender non-conforming folks are choosing the wrong streets to walk down.

This hackathon project was presented up by a white man and woman team.

Even if you identify as someone that's affected by an issue you're addressing, seek out different perspectives from people who share your identity and who may have other intersecting identities.

2) Don't parachute in.

The first rule of product development in tech is to "know your user" and the second rule of this checklist might have been to "know your community". But that should go without saying.

What isn't so obvious to some people is the inherent problem in working on a project on behalf of a community they don't belong to without that community's support or involvement. This is what's called "parachuting in".

There was a project many years ago called the PlayPump that sought to solve a South African (KwaZulu-Natal) community's water issues. They wanted to harness the "power of children at play" by connecting water pumps to playground equipment. It garnered support and funding from large non-profits like the Clinton Foundation and Save the Children. But why did the project fail?

• Community members didn't want to exploit their children as a labor force to gather water.
• Environmental water scarcity in the region was a bigger problem than the inefficiency of manual handpumps and many wells got pumped dry.

Before embarking on a Tech for Good project, it's crucial to obtain support, feedback, and consent from the community.

It's also crucial to think of the big picture. If you find yourself on the verge of parachuting in, take a step back and ask yourself if your efforts can be better spent finding ways to support the community in coming up with and building their own solutions, rather than risking setbacks or dependence on an outside solution like yours.

Who ultimately benefits from parachute projects like the PlayPump? The community they are trying to help? Or a bunch of priviledged people who managed to secure millions of dollars in funding for something to support themselves while they worked on this project.

(Another parachuting example: Elon Musk's cave "rescue" submarine.)

3) Be accessible

First, accessibilty in terms of useability for people who have disabilities, and second, accessibility to people with less resources than you.

There have been cases of medical apps which have been deemed unusable by members of the elderly population. Countless websites are inaccessible to screen readers for the blind as well, and many are being sued because having an inaccessible website is discriminatory.

One should also be wary of the assumption that everyone has access to the same things that you have. Sometimes, we take for granted what things we have that others may not. Here are a few examples:

• Wifi, a computer, and regular access to either of these.
• A social media account (shame on apps that only let you login with these!).
• An email address or a regular phone number.

4) Let the community steer (but don't exploit them).

Create ways for people to have a say in steering the direction of the project and take ownership of it. This is more than just open sourcing it on Github (congrats Dev.to! btw!🎉). It could mean reaching out to existing organizations, setting up a discussion channel and democratic decision making process, as well as enlisting people from the community to maintain the project and be financially compensated for it.

There may also be times when you need to work with community members to elicit feedback, generate ideas, and conduct useability studies.

It's important to remember that these things cost time and energy. If you have funding, there's no excuse not to compensate people for doing this type of work. If you cannot compensate people, then don't be pushy about getting feedback or ideas. All of this work should be done in a voluntary and consent-based way.

5) Protect yourself and your project from being co-opted.

One thing that governments and corporations love to do is get things for free and then exploit it. Almost every corporate-sponsored hackathon I see is looking to generate and then steal new ideas from free labor.

For the NYC Building Monitor, I quickly realized that there were many services in the commercial sphere that use the same open city data I use but charge people a fee to access it.

On the one hand, making this artificially priced data free and accessible will benefit NYC tenants. But on the other hand, I'd argue that the government should have made their free data more accessible to begin with and I'm letting myself be exploited in some way.

However - I also want my project to hold landlords and city departments accountable. One day, it'll contain data about each building's landlord so we can shame the bad ones. It'll also one day contain analysis on whether city services favor the wealthy and white city neighborhoods over others. Would a city-sponsored tool be this critical of themselves? I doubt it. That's why I think a project like this needs to remain out of their hands.

6) Protect your community from being abused.

I don't mean "don't be awful and abuse people" which goes without saying like with this terrible idea to put a bluetooth tracking beacon on homeless people so passerbys can electronically donate money to them. (Oh! It gets worse. Read that article.)

What I mean is: consider the ways in which your project can potentially backfire and abuse the people it's trying to help.

Does your app store sensitive personal data? If so, what are you doing to avoid a leak? What are you doing to keep that data out of the hands of local agencies that want to surveil and discriminate against people seeking public benefits based on personal and demographic information?

Technology is always a double-edged sword and data projects are no exception. With the NYC Building Monitor, I constantly have to weigh the risks of each new feature to assess whether or not someone can use this information to abuse tenants in some way. For example, it's rightly suspected that some unscrupulous real estate companies have abused the 311 call hotline in the past to try and influence property sales, like with what happened in Queens in 2010. What if my accessible interface made it easier for people to identify vulnerable properties?

As unlikely a scenario as that is, you would be neglectful to embark upon any Tech for Good project if you weren't thinking about the ways that bad actors can use your project for Bad.

7) Let the community ultimately solve the problem.

Your app will not solve world hunger, poverty, or end racism. People will.

One example of a great project is Appolition. This app works really well because it funnels donations to existing groups that provide bail funds to people charged with misdemeanors.

Another great project is Mapping Police Violence which uses crowdsourced data and great data visualizations to enable activists and journalists to be able to report more effectively on police violence against black people.

Do you see the pattern here? These are projects and tools that assist people who are already doing the work to address an issue.

Conclusion

Hopefully this writing encourages tech people to help out in their community in productive and healthy ways. I think that one of the most important things people can do is be open to the idea that the way to help isn't always through technology, but in non-technical efforts like community education, organizing, speaking up, or plain old monetary support for the people already doing the work in their communities. Thanks for reading!

=====

The NYC Building Monitor is conducting a short user experience survey to help improve the quality of the site! If you can help, please visit the link and fill out the survey (should take 5-10 minutes).

Also, if you are a NYC tenant or housing activist and would like to help steer the direction of the NYC Building Monitor, please reach out and email me at hello@buildingmonitor.nyc or message me on Twitter

Yeah, we're also looking for open source contributors on Github!