Feb 15 2012

GYGO - A Post-mortem

Permalink | Tags: tech, gygo, eqnz

After two years where I was working on Get Your Game On largely alone, Martyn finally finished up at Catalyst a few weeks ago to work on it with me. One week later, we decided to give up.

On the surface, this sounds mad. Did Martyn throw in his job for nothing? Do we not have an ounce of intelligence between us? What happened to our big dream? As of a few months ago, we were still evangalising GYGO; we were even preparing to bring another co-founder on board. Now... it's over. The site lives on only to serve our customers while they decide what on earth to do, a conundrum I now share with them.

Some background. Martyn and I have shared a journey for a while now: can we use our skills to fashion a future where we no longer exchange hours for dollars? To me, this is a powerful form of freedom; while you can live in a free society and learn to think for yourself, not having to worry about money multiplies your options. It is the oxygen of modern society, and it seemed (note the past tense, I'll return to that later) to me that having piles of it would leave you free to make whatever kind of difference you wanted in the world.

GYGO failed not because the idea sucked, but because we didn't comprehend how hopeless the idea was for achieving this goal.

It's not that it would never work. We have two paying customers who love it (and so do _their_ customers - players etc.), a bunch of interest from others who run sports competitions, an existing market to resegment and the positioning to do it (all online, easy/professional system - as opposed to the free, ad-sponsored or windows-centric competition). What we don't have is $500K, and quite frankly, if I want to pop my angel investee cherry and throw away five years, there had better damn well be a $100mil company at the other end. The market for GYGO is far too niche for that.

Our mistake: we underestimated the work involved in beating Excel. Here's an example. In a kid's football league, a good team is scheduled to play a bad team, and the bad team defaults. This would normally count as a 3-0 victory to the good team, but they complain that "we would have beaten them by much more!". The solution? Count the game as a 7-0 win for the good team, but a 3-0 loss for the bad team. I know, I cried into my relational database too [1]. Then I added support for it, because massaging results is rife in social competitions. It's the kind of thing you do in excel simply by changing the number in a cell. Excel matches how most people think about data - hack and kludge until it says what they want. This is precisely why it's so hard to beat.

Perhaps if the real world was sane, we could have developed GYGO on the cheap, and turned it into a 4-5 person company doing $1mil turnover. That would have suited me fine - we could have automated it to the point where I was drawing a salary for doing nothing: mission accomplished. It seems obvious now that targetting SMBs would result in a massive support headache [2], which we couldn't spread over thousands of customers, and as you just heard, real world data laughs at your attempts to corral it. Large support costs, a small market and investment required are a fatal mix.

So, what next? I have no idea. Between this and general life upheaval, I'm not even sure that my goal of being free from money is a good one. I was just at the most excellent kiwifoo, and it's got me thinking again about New Zealand and earthquakes, and whether we couldn't prepare to save some lives. If Wellington was flattened, I'd love to be able to tweet from beneath a crushed building, and know that volunteers would see it and alert first responders who could dig me out. No money in it, but frankly right now, I'm not sure I give a shit about that.

Postscript: Reading through this again, it occurs to me that I didn't say anything positive about the experience. I don't regret a single day I spent doing it. I've learned a lot about business, relating to people, solving problems; I've joined twitter and absorbed heaps of great lessons from inspiring people via it; I felt what it was like to be wildly optimistic about the future; I gained heaps of life experience I never would have gained otherwise; made heaps of friends, and played a lot of football!

Yes, I do recommend you start your own business, especially if you have a skill and want more out of life. Treat it as an investment in yourself, and you won't be disappointed.

PPS: My largest regret is letting our customers down. They're fantastic people, and they struggle with high workloads and sometimes angry people so that our kids and community can have fun. They both took the news gracefully, and one of them even gave me a jigsaw puzzle as thanks. If I can give you one piece of advice, it would be to to always tell them the truth and work your ass off for your customers. It's not just good business sense - when they're trusting you, it's the right thing to do.

[1]As Martyn dryly observed, we should have used MySQL.
[2]I envy Xero, they have an army of accountants with a vested interest in supporting their userbase.

Like this post? Subscribe to my RSS feed and follow me on twitter to hear about new posts early.

Want to share this post?

Nov 4 2011

Realtime Conversations Made Easy (my latest job)

Permalink | Tags: tech, buzzumi, disasters, eqnz, mahara

Why is it so hard - technically - to have a realtime conversation with people all over the world?

"It's easy, just use Skype!". Not so fast. People need to install Skype - this is a task too hard for Grandma (unless you visit first and do it for her). And there's the whole contacts process. If you want to talk to me, we have to find each other and add contacts. After that, Skype will bother you when it's my birthday even though you only wanted to have one little chat. I could go on... [1]

"You're a geek, use IRC!". Of course, IRC is basically unusable by many people whom you'd like to talk to - some co-workers, your family, certainly not Grandma. At least there's no contacts to manage. But there's no audio/video, and you can't "drop in and out" of an ongoing conversation very smoothly - if you lose your connection to the chat, you lose the messages sent while you were gone [2].

"Use google chat/jabber!". Worst of both worlds. Low penetration, high complexity.

OK then, just use... hmm. Exactly.

Ad-hoc & Easy

There are two problems that current solutions have. One is that our conversations are ad-hoc, sometimes with people you've never met before and only have a fleeting connection to. Skype's contacts are not ad-hoc.

The other is that people need easy. Configuring IRC is hard. Heck, installing a damn program is hard for many people. Twitter and Facebook get close, but holding a decent conversation on Twitter is impossible, and Facebook is too autistic for people to use for ad-hoc communication. Besides, even signing up is often too hard. How many services do you not use because you would have needed to sign up first?

When I worked on Mahara, we used IRC. A few enthusiastic types joined us, but in large, IRC remains to this day inaccessable to many people. Not all users of Mahara are willing, or capable, of using it.

And when the Christchurch Earthquake hit this year, the response team that built eq.org.nz used Skype - which was by most accounts a terrible solution. Skype chat simply has too many bugs when you get to rooms of more than a few people - and we had over a hundred. Richard wrote a post-mortem that lays out the issues for communicating in a crisis.

Introducing buzzumi

So it's been my great privilege to have worked on a new service that addresses these problems. With Richard (a fantastic webapp developer who happens to be my cousin), we've been the tech team behind buzzumi, which just launched (he's lead, I'm wingman). It's a webapp that lets you create ad-hoc discussions - text chat, audio and video (A/V is completely optional). Your chat is accessible to anyone who can click on a link, without them logging in [3]. It's simple, beautiful, and lightning fast.

http://f.dollyfish.net.nz/5d7c4c http://stuff.nigel.mcnie.name/buzz-video.png

The chat host can set the background, and it changes for everyone in the chat. There's no limit on participants, and up to six people can use A/V at once [4]. It's great for team meetings, one on one discussions, and even webinars with hundreds of guests watching a broadcast. There's nothing to install (except flash), and no barrier to entry. You don't have to know the other participants, and when you're done, you can close the chat and never see them again.

Perhaps one of the coolest features is that you can make a chat have a fee for entry. buzzumi handles all of the payments for you. So you could hold a webinar on a topic you're an expert in, charge $50 to enter, and simply collect your profits when you're done (buzzumi takes a 10% cut).

Please Try It Out!

If you're in education, how could you use this for your school/university? If you're in disaster response, can we please ditch Skype for this? And if you know me from somewhere else, I'd love to hear your thoughts about it, technical or otherwise.

Give it a try, and let me know what you think! I have created a chat which I'll hang out in for a while as well, come by and say hello if you have a second.

ps: Get Your Game On is still rolling, we are busy running much of the summer football around Wellington.

[1].. in this footnote :). Skype can suck bandwidth when you're not around, the new UI is crap, it promises encryption but has flaws including rumoured government backdoors, and it's now owned by Microsoft. Eew.
[2]Geeks have ways to get around this, through hax that allow them to use IRC on internet connections more reliable than their own. This is a workaround, not a true solution.
[3]To create chats, you do have to sign up - but your guests do not.
[4]Just quietly, the real limit is quite a bit higher, although we give no guarantees that it'll work properly beyond 6. I think the current record is 14. And note that this limit applies to people publishing their A/V, so you can have just one or two publishers with many more watching.

Like this post? Subscribe to my RSS feed and follow me on twitter to hear about new posts early.

Want to share this post?

Sep 5 2011

Closing The Loop - The Canterbury Quakes, eq.org.nz And The SBTF

Permalink | Tags: tech, sbtf, ushahidi, eqnz

Image Source

http://stuff.nigel.mcnie.name/ccnz.jpg

It's been a year and a day since the first of a series of earthquakes hit Canterbury, which peaked in February this year with a 6.3 magnitude quake that took over 180 lives. While I was unaffected by the quakes themselves, I have since thought that I (along with everyone else in Wellington) have "gotten off lightly", due to the simple fact that Wellington straddles a known fault line with an 11% chance of rupture in the next 100 years [1].

The events following the quakes show that Wellingtonians, and indeed all New Zealanders, take this risk seriously. The eq.org.nz project was a fantastic grass-roots effort that showed the "can-do" attitude in our country. People weren't happy just to donate or leave it to the government - instead they pitched in and did something that helped everyone.

After eq.org.nz was shut down, there were some postmortems. Richard Clark wrote on realtime communication in a crisis, development at crisis speed and a look at how technology could automatically swing into effect in a disaster. InternetNZ facilitated a discussion between the internet community and the Wellington City Council, and a great video was made summarising the project. As I was a part of the tech team for the site, I took one lesson away in particular - the tech was not as ready as it should have been.

Yes, we managed to set up a site in a matter of hours after the quake. Yes, the site got significant use, and yes it was helpful to some. But I feel that we can do much better in the future, particularly with regards to the technology. The two areas we could improve on are being prepared and improving the tools.

Being Prepared

From quake to functioning map took us a few hours - a commendable effort, made possible thanks to Ushahidi, their hosted Crowdmap product, and of course the efforts of everyone involved. However, I feel this was much too long.

Firstly, we were working in an emotionally charged, chaotic environment - one in which mistakes would have been easy to make. Second, we were given a lot more luck than we may have otherwise expected, thanks to the Ushahidi team co-operating with us over the migration away from Crowdmap, and the help of CrisisCommons in getting us started [2]. And third, during the first few hours, stuff.co.nz and NZHerald (the two major online news sources in NZ) both set up their own maps, and had it not been for our connections and their willingness to help, three competing maps could easily have sprung up, none of which would have been much help at all.

Spending hours setting up the site manually is the wrong way to do things, and we all know it. However, we can't predict disasters in advance. So it seems to me that we either need the ability to set up a site in minutes, or a "general" site prepared in advance, which can be adapted within minutes for whatever disaster is taking place.

Let's explore both options briefly. The ability to set a site up in minutes requires some prior planning, however it makes no assumptions about the nature of the disaster, and allows us to set up and tear down sites as we see fit. Disaster hits two cities? Just deploy two sites. During down time, as long as a minimal amount of maintenance is done, we can keep the process well oiled. Furthermore, we can develop "template" sites - one for earthquakes, one for tornadoes etc., and deploy the right "type" of site during a disaster, providing great agility.

Setting up a site (or sites) in advance has a different set of complications and benefits. A URL can be published in advance of any disaster, that everyone knows, so when a disaster hits more people know where to go (e.g. wellington.disaster.org.nz [3]). However, it may take more work to be able to re-configure the site for different disasters, as opposed to simply deploying a fresh site. And naturally, the site will need maintaining during the time between disasters, which could be many years.

The other aspect of being prepared, as alluded to here, is having data prepared. That doesn't just mean having categories prepared - that means having map data for everything of significance ready. Why should it take until a disaster for us to plot Wellington's ATM locations on a map? Why can't we prepare this data beforehand, ready for use the moment it's needed?

Improving the Tools

We made great strides towards improving Ushahidi for the task of disaster mapping on the eq.org.nz project. However, I fear that a lot of our good work hasn't made it as far as it could. The code sits (rots?) in a github repository, many of our changes having not made it anywhere near upstream - despite still being needed.

I've helped out with a couple of disasters since the quakes, and in each case, I found myself doing the same setup work, then fixing the same bugs, as we did previously. Clearly, pushing some fixes upstream would be a good start. However, the issues with using Ushahidi for crisis mapping run deeper than just a few fixes.

We made many changes that improved the usability of the map and homepage, the stability/scalability of the platform, and to streamline the workflows of people approving reports. We didn't push these changes upstream, and I'm reminded of this with every disaster has occurred since then. The eq.org.nz site really did finish as a much better product, but it's a height we haven't attained since.

To be clear, I'm not blaming anyone for this. People burned out, interest waned and we all had our lives to get back to. But I think it would be great if we could "close the loop". After all, you never know when it's you who will be needing the map...

Closing the Loop

I found out about the Standby Task Force after the Christchurch Quake. They're a network of "adhoc groups of tech-savy mapping volunteers that emerge around crises into a flexible, trained and prepared network ready to deploy." In other words, they're the eq.org.nz team, except larger, more organised, and with a global focus. When disaster strikes, if the locals ask for help, the SBTF are ready to respond, providing a map, volunteers and expertise to get things rolling. Now I think of it, they're a little like Internation Rescue (from Thunderbirds), in its infancy. No rocket ships I'm afraid ;), but a group of people willing and able to help in times of emergency.

Somehow, through a combination of my motivation to improve the tech for future disasters, and the prodding of George Chamales and Kirk Morris, I've fallen into the position of SBTF Tech Team Leader. My plan is to, as part of this team, work on both of the technical aspects outlined above. The goal: that anyone will be able to deploy a map ready to handle a disaster within minutes of it occuring.

I've donated some code from Get Your Game On to get started on a system for performing one-command. We're also planning on maintaining a branch of Ushahidi [4] optimised for crisis mapping, to which I hope we can apply many of our patches from eq.org.nz and other sources over time.

With this, I hope we can truly close the loop - so that when Wellington, or anywhere else, is struck by disaster, our response will be as good as it can be.

Final thoughts: I'm only focusing on the tech. There are clearly other issues we need to work through, not least the political ones. I hope next time to see a much closer relationship between government and such volunteer efforts, although it's not an issue I feel I can influence personally.

[1]In researching this I was glad to discover that the 11% figure is a 50% decrease in what was commonly believed before the "It's Our Fault" study. All the same, 11% is not a particularly comforting figure.
[2]In comparison, imagine what it would have been like if the disaster had struck 10 years ago. No CrisisCommons, no Ushahidi, barely any internet to speak of. We are truly lucky.
[3]Naturally, something shorter would be better!
[4]Naturally, we will try and push as much upstream as possible, however there's a simple reality that not all patches may be suitable.

Like this post? Subscribe to my RSS feed and follow me on twitter to hear about new posts early.

Want to share this post?