National Geographic photographer Ciril Jazbec was in town capturing the tech entrepreneur feel of Nairobi and surrounds.

I’m about a week late on my post, but thought I’d round up some of the news from the crazy week that ended with the Global Entrepreneurship Summit (GES) in Nairobi. With US President Barrack Obama in town, bringing some of the biggest names in tech and business with him, it was bound to be a circus.

We embraced the madness at the iHub and there were a great many events.

One of the highlights for the week was seeing our very own Judith Owigar, co-founder of Akirachix and long-time iHub member, up on stage seated between President’s Uhuru and Obama on the main GES stage.

IBM partnered with the iHub to launch the innovation @ iHub space, so we’ll be working a lot closer with them going forward and that means members of the iHub community will get a lot more access to IBM, its partners and its resources.

Jean and Steve Case, AOL Founders and investors, came to the iHub and ran a social impact tech pitching competition. They brought with them other investors, including Jim Sorenson, and Nina Tellegen CEO of the DOEN Foundation. Here’s Jean’s writeup on the week.

The full Ushahidi team met yesterday (many virtually, of course), and we talked about many issues surrounding the Westgate siege. Not least amongst them was the fact that we had a hard time checking in with each other. And then found out that one of our team’s wife and 5 children were inside of the mall, while he was traveling out of country. They eventually got out a few hours later, to which we were relieved.

This lead us to then think through our skills and tools, and where we could be useful.

In an emergency, how do you find out quickly whether your family, your team, your friends are safe?

The Ping App – a group check-in tool for emergencies

How About a Way to “Ping” Your Group?

There was a consistent problem in every disaster that happens, not just in Kenya, but everywhere. Small groups, families and companies need to quickly check in with each other. They need to “ping” one another to make sure they’re okay. It has to be something incredibly simple, that requires little thinking to use. People have been doing some stuff in this space in the past, the best like “I’m Ok” are focused on smartphone users, but we have a need to make it work for even the simplest phones. Our goal is to have this available for anyone globally to use.

“Ping” is basically a binary, multichannel check-in tool for groups. The idea is that families and organizations could use this for quick headcounts on how everyone was, then use it as an on-ramp into a Red Cross missing persons index or something like Google’s People Finder app.

You create a list of your people (family, organization), and each person also adds another contact who is close to them (spouse, roommate, boy/girlfriend, etc).

When a disaster happens, you send out a message for everyone to check-in. The admin sends out a 120 character message that always has “are you ok?” appended to the end.

This goes out via text message and email (more channels can be added later).

The message goes out three times, once every 5 minutes. If there is a response, then that person is considered okay. If no response, then 3 messages get sent to their other contact.

We file each response into one of 3 areas: responded (verified), not responded, not okay.

Every message that comes back from someone in that group is saved into a big bucket of text, that the admin can add notes to if needed.

Ping Notes, Features

Ping Architecture – rough draft

Yesterday we quickly wireframed out a list of needs, some design basics, and an architecture plan (images above), got a rough product going on it (code is on Github). We now need to make it look better, so some designers are working up some stuff to make it work well on both phones and computers.

Mockups of the Ping app, still undergoing some design tweeks

Final touches are to add in:

Account creation, we’re using our CrowdmapID tool for this, since it’s already out

Message “send” page

Archive old campaigns feature

Wire into text messaging service (Nexmo or Twilio), and then testing it out internally

Designing it so it looks good (responsive design, so it works on mobiles and PCs)

If you’d like to help out, jump on the Github repo, and get in touch with us about what you can do. What we have here is a minimum viable product (MVP) right now, open source, so anyone can make it better by branching the code and adding in features, etc.

Finally, a HUGE thank you to the people who have been burning the midnight oil to make this all happen in 24 hours:

UPDATE: Here’s the report put together by the iHub Research team (3Mb PDF): Uchaguzi Kenya 2013

The elections in Kenya this year have had a lot of drama, nothing new there. As I wrote about last week, Ushahidi has been involved quite heavily on the crowdsourcing side via Uchaguzi, which meant that we had an exhausting week as the results kept getting extended each day.

Uchaguzi Update

Some basic statistics:

5,011 SMS messages sent in (that weren’t spam or junk, as those got deleted)

Just over 5 years ago, I was just like everyone else tuning into the social media flow of blogs, tweets and FB updates along with reading the mainstream media news about the Kenyan elections. We all know the story – thing fell apart, a small team came together and built Ushahidi, and we started building a new way to handle real-time crisis information. We were reacting and behind from the beginning.

Now, the day before Kenya’s elections, I’m sitting in the Uchaguzi Situation Room, we’ve got a live site up already receiving information, 5 years of experience building the software and learning about real-time crowdmapping. There are over 200 volunteers already trained up and ready to help manage the flow of information from the public. This time Kenya’s IEBC is ready, they’re digital, and are doing a phenomenal job of providing base layer data, plus real-time tomorrow (we hope).

In short, we’re a lot more prepared than 2008 in 2013, everyone is. However, you’re never actually ready for a big deployment, by it’s very nature the crowdsourcing of information leads to a response reaction, you’re always behind the action. So, our main goal is to make that response processing of signal from noise and getting it to the responding organizations, as fast as possible.

Uchaguzi 2013

If you’d like to know more about the Uchaguzi project, find it on the about page. In short, Uchaguzi is an Ushahidi deployment to monitor the Kenyan general election on March 4th 2013. Our aim is to help Kenya have a free, fair, peaceful, and credible general election. Uchaguziâ€™s strategy for this is to contribute to stability in Kenya by increasing transparency and accountability through active citizen participation in the electoral cycles.This strategy is implemented through building a broad network of civil society around Uchaguzi as the national citizen centred electoral observation platform that responds to citizen observations.

The next couple days I’ll be heads-down on Uchaguzi, running our Situation Room online and Twitter account (@Uchaguzi), and troubleshooting things here with the team. We’re already getting a lot of information, trying to work out the kinks in how we process the 1,500+ SMS messages that people have sent into our 3002 shortcode, so that tomorrow when things really get crazy we’re ready.

I’ve already written up a bunch on how Uchaguzi works, so I’ll just post the information flow process for it here:

Uchaguzi’s workflow process

Your Job

As in 2008, your job remains the same; to get the word out to your friends in Kenya, to get more reports into the system, and to support groups working towards a good election experience.

A huge thank you to the local and global volunteers who’ve put in many, many hours in the workup to tomorrow and who will be incredibly busy for the next 48 hours. Besides the hard work of going through SMS messages and creating geolocated reports out of them, some of the geomapping team have been busy taking the police contact information and mapping it. They’ve created an overlay of the data, it’s on this page right now, but our plans are to put this on the main map later.

Just as in 2008, a few people are making a big difference. All of the volunteers doing the little they can to make their country better.

I’m disconnected. Off-grid in the usually dusty and dry (though green currently) Tsavo region of Kenya with seven others from the Ushahidi team as we look into whether or not technology can be useful on the Rukinga Sanctuary.

We’re here to see if our technology, or the knowledge of what can be done with tech, is useful in carbon monitoring of deforestation, security operations with rangers and/or better engaging with the surrounding community?

David Kobia talks to Dr Mwangi Gichiru of Wildlife Works carbon project

The Wildlife Works team has an extensive for-profit program around carbon credits, carbon offsets, and small factories in an EPZ where brands like Puma get their “made in Kenya” stamp. It’s maybe the most impressive example of what could be termed a “social enterprise” that I’ve ever seen. Over 300 people have jobs due to their presence, and all in the community monetarily benefit from their activities.

The 75,000 acre sanctuary sits just south of Voi, off the Mombasa road. Rukinga was the first place in the world to be VCS (verified carbon standard) verified and REDD (Reduced Emissions from Deforestation and Degradation) certified by the UN, and has since grown to encompass the 13 other ranches and 1/2 million acres surrounding them. 60,000 people in the communities surrounding them are financial beneficiaries from the project.

Last year they sold sold 1.4 million tons of carbon credits for around $6-8 per ton. The revenue from that is split into three parts; 1/3 goes to the land owner(s), 1/3 goes to the managing company (Wildlife Works) and 1/3 goes to the community. Interestingly, unlike a lot of NGO work, the team doesn’t decide how the community should benefit. The community decides how to spend the money, through their own local committees, and it’s led to a huge amount of school bursaries (2,000 kids now in secondary and tertiary schools), water catchements and other public works.

It’s impressive.

So, what does Wildlife Works really do at Rukinga?

In short, they try to increase the amount of trees, protect the animals, while balancing that with the local community.

An elephant in Rukinga Sanctuary, Kenya

This is where the problems arise as there are encroachments for wood by charcoal burners and poachers killing the elephants. Due to the community benefiting from the ranches, there has been a decrease in the amount of charcoal burners and even the local poison-arrow elephant poachers and bushmeat hunters have reduced.

However, there’s a much bigger problem, that of commercial poachers (mostly of Somali descent) who come down from NE Kenya, with sophisticated weapons and who are experienced in tactical movement. They come in teams of 2-10, using their mobile phones for coordination, moving fast and anchoring off the Mombasa Highway. Often they have buried caches of guns and ivory on the ranch, so they don’t even carry those in or out with them, and they can blend in easily.

18 rhinos have been killed since the holidays in Kenya alone, and elephant tusks sell for around $300/kilo, so provides a massive incentive for income for anyone.

“Weâ€™ve been working in Kenya for the past 17 yearsâ€¦ We lost 10 elephants to ivory poachers in the first 15 years, and 45 in the last 18 months, and this is despite being a relatively well-funded organization with extraordinary relationships with the local community members who benefit from wildlife,â€ says Wildlife Works founder and CEO Mike Korchinsky.

The rangers have no weapons. They are highly skilled at finding and tracking the poachers, but need the Kenya Wildlife Service (KWS) to come if they’re going to catch someone. KWS is sometimes slow to respond, and they’re not willing to put their life on the line in order to catch or kill the poachers. When a poacher is caught, the laws are not stiff enough to disincentivize others.

Talking with the Wildlife Works security and operations team

The Tech

So, where can tech help? We don’t know yet, is the answer.

To frame the problem of biodiversity protection, if you get to the animal or tree after it’s dead, then it’s too late. What you really want is prevention. If you can’t get prevention, then you need swift and effective response.

Prevention
We’re wondering if there’s a way to get the community interacting through SMS to pass on information about illegal activities. Beyond informants, we’re thinking that there might be a useful way to connect the local community monitors and make reporting on human-wildlife conflicts more efficient.

Response
The teams of 100+ rangers are on foot a lot, carry a GPS and do have some mobile coverage. They create reports when they come in, and their goal is to be light, hardy and fast. All of them already carry cheap Nokia-type phones, so can send SMS and call, and we’re thinking that a very simple text messaging system as a hub might come in handy for coordination and archived messaging for later assessment (and possibly mapping).

Other Ideas

There is a lack of information on all types of location-based data, especially once you get off the main road. There’s an opportunity to do a community-level mapping exercise, tied to Open Street Map.

The process for getting GPS-related data from the rangers to HQ and then a map takes a couple weeks. Surely there is a way to make this more efficient.

Related to the rangers data is that they rarely see the output of the GPS data and forms that they fill out. Could we create a faster way to visualize it, and let them see their work?

It seems to me that if you were able to gather the phones and SIM cards off caught poachers, then you could start dumping their address books and pattern matching for similarities. We could also see if it is possible to streamline the process for legally getting call log data for those SIM cards from the mobile operators.

The camp we’re staying at is situated has a generator that provides backup power in the evenings for a few hours, where we get our daily recharge-dose for our gadgets. If you stand in just the right place you get one bar of connectivity on your phone and send out text messages.

It’s a shock to our digitally connected system when we find ourselves without a digital tether. It’s also a wonderful reminder of the constraints that real life problems have, where technology helps and/or hinders and why simple solutions tend to be the best.

While we’d love to just shove an Android phone in every rangers pocket, it’s probably not the answer. Instead, as my battery dies, I sit here thinking that we’ll revert to our simplest messaging solution (aka SMS) for any communications tools. It also reminds me that technology is at it’s best when it’s a small component that makes one thing work better, faster or more efficiently. If all we were to do was take one pain point out of the Wildlife Works people’s lives, then that would be enough.

(Sidenote: Limo rubs it in that his Blackberry gets messages and calls, and much to my shame he’s right, it’s better than any of the Android of iPhone devices for connection on the edge of network connectivity. Maybe there is still a place for RIMâ€¦)

A huge thanks to Taylor Martyn for coming with us and taking some great pictures (seen here)!

I often get asked what the iHub is, what happens here, and why it has worked. Often followed by the question of whether or not this model could work elsewhere in Africa. Here are my thoughts on the matter.

The iHub is Nairobi’s nerve center for technology; a place where we can grab coffee, create apps, find funders and build businesses. It’s where the community of web and mobile programmers connect with each other, businesses, the government and academia.

A brief history

There was a discussion at Barcamp Nairobi 2008 about how valuable it would be for the Kenyan tech community to have a static space of our own. No one would fund that idea. My organization, Ushahidi, decided that we liked it the idea enough that we would fund it. It fit with our overall thoughts on being “open”, it would serve as Ushahidi’s home in the region, and most of all, we thought we could use our good fortune to find and help the next startups in Kenya.

Thus, I moved back to Nairobi in 2009, with funding from Ushahidi via Omidyar Network and Hivos, to build the iHub. I quickly selected a space, and picked the energetic and gifted Jessica Colaco as the Manager. In March 2010 we started work on the space, and in June it was open for use.

Though we had provided funding for the first 2 years, the iHub is an independent Ushahidi initiative. Meaning, that it runs outside of the normal Ushahidi operations and organization. Though the Ushahidi team has full access for the space, we have a very light footprint, and use it the same way everyone else in the community does. We knew that even though we were the most neutral of parties, with a ton of local credibility, trying to “own” the space would fail – just as it would if it had been named the “Google iHub” or the “Nokia Innovation Hub”. It had to be owned by the community, and that meant name and usage both.

The community

At the heart of all that happens at the iHub is the community. They designed the room layout and logo, run the network, hold events, built the website, create the house rules and drive the direction of the space. The management of the space is there to provide basic infrastructure support, a foundation, which the community then builds on to make the space what it is today.

What’s important to understand is that we come from this community too, we are it. We knew it could work because it was ourselves we were building for. When people ask me if I could do the same thing in another city, I respond that it would be questionable. A space like the iHub needs to be put together by someone from that community of techies who understands at a basic level the needs and has the credibility within it to make it happen.

As the iHub grew, we realized that all of the administrative duties, mixed with community interaction, were too much for one person. Thus we brought on Tosh to be the community manager, where he is in charge of working with people, memberships and events. His job is to aggregate, translate and enable the communities needs.

The advisors

That “being part of the community” was what drove me to start looking for a small team of advisors who could help make decisions, especially early on. This iHub advisory board was made up of 4 influential and highly credible technology players from Nairobi, plus myself. The greater community could appreciate that they were being represented well, and it provided a small enough team to move quickly.

Initial roles for this team were to make the final decision on build out design, logo and name, as well as figure out how to deal with an influx of members in a tiered membership model if the need arose (and it did, quickly). With over 4,300 white-level members, this team is also responsible for making the decisions on who gets green-level membership, the people who ultimately get to have free and unfettered access to the iHub facility.

The design

The design of the space was very important, and we were lucky to have Fady Rostom and Kwame Nyongo to lead the design team. They spent a lot of time listening to the ideas and thoughts of the advisory team before they started drawing, and it shows in what was built.

We needed a place that was open, and could be flexibly turned from community commons to event space. We wanted a subsection of the space to be rentable desks, for pre-incubation and co-working activities. At no time was a coffee shop not included – it was seen as core to the vibe and culture of what would happen here. We’d need a secure server room, and plenty of ethernet and electrical points, both inside and outside.

Most of all, the iHub needed to be a place where Kenyan techies were proud of. A place that was uniquely ours, and that we could show off to our visiting friends from abroad. It had to have the feel of being any high-tech community space in the world, with a Kenyan flavor. And it is.

The sustainability strategy

Early on we had no idea how we would pay for things beyond the first 2 years. We projected costs, but didn’t know where the revenue would come from. We had some ideas, but instead of creating a grand plan, we decided to take a very experimental approach, iterating on what worked and killing ideas that didn’t fit.

Right now the iHub has revenue coming in from red members (co-working desk rental), events and the new research arm. Events and desk rental were obvious and worked from very early on. The R@iHub arm didn’t come into being until January of this year, and was very much a big experiment – which appears to be working marvelously well. Jessica’s background is as a technology researcher, and she’s built a brilliant team around her to focus on this. Already we can see that 50%+ of future income will come from this initiative.

The other experiment was taking lead on the m:lab, a space the same size as the iHub which sits one floor beneath us. It’s an incubator. It plays the iHub’s foil, where upstairs is about community, openness and fun, the m:lab downstairs is about professional tech companies building quality products and making it into the market. We took the lead on the consortium behind this, and it is seen as a sister-facility to the iHub, with many shared services between the two.

The corporates

Both the iHub and the m:lab have strong corporate partners. Early on, before the first brush of paint was dry in the iHub, we had started talking to big technology corporates who call Nairobi home. Large tech corporations need an active dev community, and the dev community needs them. Luckily, Kenya is geographically well-positioned for some great companies to make it their home in the region, which worked well for us. We also happened to know a number of them personally, which sped up the discussions and interactions considerably.

We didn’t want to just have corporate partners who were sponsors. We made it very clear early on that their money was less important to us than what value they could add to the space that would help the dev community, but that it was a 2 way street. If we couldn’t facilitate a strong value back to them from the local tech community, then it was a no-go.

Fortunately, despite our lack of a clear idea of exactly how things would work, or what our metrics of success would be, we found some great patners. Nokia, Google, Wananchi and Microsoft are corporate partners with the iHub, and downstairs we have MIH, Nokia and InMobi working with us.

A small aside here, which isn’t corporates, but we’ve also nurtured strong connections with the Kenyan government, though we take no money from them. This also applies to academia.

Final thoughts

By the end of 2010 people were already claiming that the iHub was a model for technology engagement, aid stuff (gah!), etcâ€¦ in Africa. I thought that was a premature statement, it was an experiment and it still is. The success of the iHub has come from a strong foundation of advisors and community members who understand their city, their peers and their region.

The success of other tech hubs across Africa will be based on leadership credibility, and ability to engage their community.

Much of the iHub’s success comes from a community that works together. In that spirit of “harambee” that is so much a part of our Kenyan life. While there is always healthy competition, we would rather work together and celebrate each others success, and ultimately help each other along with the knowledge that if more of us succeed, then we all benefit.

I hope to see many more labs and hubs across the continent, and we’re seeing them grow too, in Cameroon and Ethiopia, Uganda and Nigeria. Though some of them will need financial assistance to get going, like Ushahidi did with the iHub, they’re organic growth is what makes them viable.

Yesterday Ushahidi won the Kenya ICT Award for “Social Equity and Poverty Reduction“, which we’re extremely grateful for. None of us were able to attend the conference in Kenya due to the whole team being at our big annual meeting.

The Ushahidi core team works from 7 different timezones ranging from Kampala to Louisville, soon expanding to places like Brazil and Korea. One weekend a year we’re able to get together, in-person, to solidify our connections with each other and talk through the big strategic topics that are best done face-to-face. It could be argued that it’s the most important 3 days of the year for us.

The First XV

2010 was a big growth year for Ushahidi, where we got up to 12 core team members – doubling in size from 2009. We’re adding 3 more people this year, which brings us to 15, a fortuitous number for the team as many of us are big rugby fans. 🙂

(Caleb decided to have a little fun, putting us all in our positions based on the date that we joined the team.)

12 Months Later

Last year we met in Miami, as we are this year, and a lot has happened since then. To name the big ones:

Plugins – extensible way to add new functionality without bloating the core

Crowdmap – maps for non-developers, also a means to quickly collect reports giving deployers time to install their own server

Looking at the historical record, it’s been a good year. However, there’s a lot more to do. At this meeting, besides drinking a Mojito on South Beach, we’ll get into some of the big future-looking issues, such as:

Visual Reporting: What’s the perfect Ushahidi dashboard? How do we surface “power stats” for Ushahidi deployments and metrics. Swift-Ushahidi integration visuals on the front and back end.

Knowledge Management: How do we come up with a plan to capture information that we know internally, so that it is shared with deployers and developers better?
The inverse, how do we handle and capture information that our *users* know regularly?

Crowdmap Scalability & Migration: Making sure that even the biggest deployments work on Crowdmap. Adding in new a la carte features, etc.

Of course, this is a chance to discuss some of the more mundane items as well, around operations, funds and how we work towards organizational financial sustainability as well. It also means that we’ll be offline from today until about Tuesday of next week. We’ll be a little slower on email and other communications mediums, but bear with us as it’s for a good cause.

In Cape Town, Google has initiated a tech incubator that gives 6 months of free space, $25-50k startup funding and access to an extensive mentoring network. The secret sauce here is in the angel & mentor network, who will be providing 50% of all investment money, while Google provides the rest. Johanna Kollar leads this initiative, and tells me they’re looking for at least 5 companies to get behind in this first go at it, though if there are enough exceptional applicants, they might do more. If you’re a registered business in South Africa, then you can participate. (more on the Google Africa blog)

Deutsche Welle runs the “Best of Blogs” awards each year, showcasing excellent blogs from all over the world. If you haven’t yet, take a few minutes and vote for your favorites. There are quite a few from North Africa.

I’ll be a guest to the Royal Geographic Society in London on May 18th for a discussion on technology in Africa with Nicholas Negroponte, Herman Chinery-Hesse and moderated by Bog Geldof. Our main topic:

“Can digital technology such as laptops and mobile phones offer the countries of Africa realistic economic and educational opportunities?”

If you’re in London, you can get a ticket to the event and join us.

Ushahidi moves

There are over 10,000 deployments of the Ushahidi platform around the world, and as you might imagine, a lot has been happening at Ushahidi, including:

The launch of Crowdmap Checkins at SXSW, a way to “roll your own Foursquare-type service”. It’s in it’s beta stage, but you can play with it now, as others have already using the Ushahidi Android or iOS apps.

One of our volunteer deployers, Anahi Ayala Iacucci, spent a great deal of time and created a 90+ page Ushahidi manual for anyone looking to deploy Ushahidi. Having worked on over 20 deployments of her own, she’s one of the best placed people in the world to do this.

Samsung Seeks to Grow in Africa

Samsung is opening a new Electronics Engineering Academy for youth in Boksburg, South Africa. As Afrinnovator states, they have about 20% of the market, which will only increase as they’ve been smart enough to get behind Android in their devices (currently with 22 models). We’ve felt this presence at the iHub in Nairobi as well, where Samsung has a great interest in reaching out to Android programmers.

9 months ago that is just what Jon Gosier set out to do as he took over the reins of the SwiftRiver initiative at Ushahidi. Today he announces the Beta release, and unveils the new website at Swiftly.org.

What is SwiftRiver?

“SwiftRiver is an open source intelligence gathering platform for managing realtime streams of data.”

Using 5 different tools in the toolbox, you can create a host of useful applications. Tools ranging from natural language processing to handling duplicates, or a source’s importance in the ecosystem. Much like a box of Lego’s, the value and usefulness of the apps created are up to the creator.

SwiftRiver lets users:

Manage realtime data streams (e.g. RSS, SMS, Twitter, Email)

Identify relationships between content (e.g. email and tweets)

Set parameters to auto-filter incoming feeds

Curate content based on preferences

Swift code and web services

Like all Ushahidi work, the code is free and open source, anyone can download it, contribute to the code, and run it on their own server. Due to it’s complexity, SwiftRiver also offers a software as a service solution, allowing you to tap our servers for your own needs. Swift Web Services (SWS) is our cloud platform. The platform offers a number of different APIs to developers. With this platform you can easily beef up your applications with natural language processing & active learning, reverse geocaching, distributed reputation, content filtering and web analytics.

This first app, called the Sweeper is the first project to enter Beta and now ships with SwiftRiver. Sweeper, is a term Ushahidi uses to refer to people who â€™sweepâ€™ through a system, performing certain tasks, and it was for this reason that we put the Ushahidi resources behind the whole initiative.

SwiftRiver | Sweeper

History, contributors and code

The origins of SwiftRiver are in the community of Ushahidi developers and users. Chris Blow and Kaushal Jhalla asked some hard questions after the Mumbai terrorist attacks in 2008, discussing the need for something that can help with this information overload we have in the first few hours of an emergency or disaster. Today, we’re seeing the first fruits of that technology, and it’s exciting to know that the potential for it’s use goes far beyond the crisis scenarios that we first envisioned.

Matthew Griffiths (Uganda) and Neville Newey (South Africa) have done a great job hacking out much of the code and designing the architecture for the platform. They’ve been joined by an army of volunteers and contributors, including: Joshua Bronson, Soe, Nishith Rastogi, Mang-Git Ng, Josh Bronson, Ivan Kavuma, Andrew Turner, Chris Blow, Kaushal Jhalla, Ed Bice, Moses Mugisha, Victor Miclovich, Wolfgang Werner, M. Edward Borasky, Maarten J. van der Veen, Ahmed Maawy, Colin Meinke. A huge round of thanks to everyone who gave freely of their time and energy to move this project forward!