[@OKau] After the hackathon: 4 classic recipes
pia.waugh at gmail.com
Fri Apr 24 12:07:03 UTC 2015
The main benefits of community run hackfests are community development,
skills, gov engagement, more open data, platform for people to show off
skills and launch startups or research projects, redefining innovation to
be meaningful, and showcasing our awesome tech community and the value of
tech as something to invest in. Also some projects go on to be projects or
commercialised, but the other benefits are significant.
On 24/04/2015 12:24 AM, "Cobi Alison Smith" <cobi.smith at unimelb.edu.au>
> Hackathons can also lead into or contribute to research projects, or
> other collaborative projects independent of government, which are not
> necessarily businesses - I guess that could come under the umbrella of
> community projects; in which case I guess I would that I *have* seen it
> happen :)
> For example, in Geneva last year I was involved in 2 projects that
> developed across multiple hackathons. Geotagx.org a disaster response
> citizen science project, and blindstore.github.io a cryptography tool.
> Things like Mozilla Festival and Wikimania involve hackathon elements which
> are typically sprints on existing projects rather than projects starting
> from scratch. I think such bigger festival-type events are great because
> they allow cross-fertilisation of ideas and skills between communities and
> projects. These "soft outcomes" may be more valuable than new tools or
> projects themselves.
> Thus another aspect of what emerges from hackathons is value & learning
> for individuals, beyond a given project. For example, I was part of the
> flushed.co team at melbournewomen.startupweekend.org. Most people
> involved were time-poor and overcommitted, so there really was a
> one-weekend focus. Because we used data.melbourne.vic.gov.au (which was
> part of our pitch - part of what I wanted to do was to demonstrate use of
> open data), people from council were super-keen to follow up and kept
> trying to organize meetings with our team. However we were all too busy and
> overcommitted with kids, work, study, travel etc. for that to happen. I
> found it frustrating that the council guy didn't seem to understand that
> while the hackathon structure worked for us as a group, we couldn't all
> just magically find some weekday business hours meeting time, especially
> since they weren't offering anything besides a vague meeting (I think our
> team's junior dev may have prioritised the meeting if they'd been offering
> a job or grant or any hard incentive to develop the project).
> That relates to Rosie's recent sharing about community and incentives
> etc. but is mostly unrelated to Steve's sharing. Back to Steve's sharing -
> I learnt in that startupweekend that I had 0 experience with the mapping
> method our main developer wanted to use, so despite getting involved in
> that team partly due to my mapping interests, I ended up focused on
> communications aspects no-one else wanted to do, which I dislike getting
> typecast into (but was also my own fault since I was keen to communicate
> about open data & sanitation).
> That led me to refocus my interest in OpenStreetMap, which led me to be
> interested in geotagx.org as it's underpinned by OpenStreetMap, which I
> consider valuable. So experiencing what I found to be a dead-end in one
> hackathon weekend led me to refocus energies on something I saw as worth
> developing - namely OpenStreetMap applications - which influenced my
> subsequent career path.
> What's the takehome from this braindump? Umm.. if what Steve wrote is
> partly about showing value from Govhack, perhaps another topic could be 4
> classic recipes from the perspective of participants' growth, in contrast
> to project growth?
> /back to thesis :)
> *From:* okfn-au [okfn-au-bounces at lists.okfn.org] on behalf of Steven De
> Costa [steven.decosta at linkdigital.com.au]
> *Sent:* Friday, 24 April 2015 7:35 AM
> *To:* Open Knowledge discussion list for Australia.
> *Subject:* Re: [@OKau] After the hackathon: 4 classic recipes
> Another type is 'collaborative procurement'. It replaces a more
> traditional RFQ process. It requires the buyers to be involved and
> committed to a paid project outcome before the hack starts.
> However, it needs to not be exploiting the talent of hackers by asking
> all to work for free. Rather the event, or part thereof, could be just for
> pitching and team creation (private-public teams). The team selection
> can be facilitated by the organizers, a panel of experts or a third party
> such as NICTA. After that there is a proof of concept phase with no free
> work (that runs foe at least two months). It can be heavily discounted,
> such as by awarding 5, 10, 15k to the three teams in order of success. They
> aren't competing head to head to try and win the same projects in this
> scenario either.
> Importantly the public sector Organisations should be able to direct
> source at the end of the PoC stage for a significant effort - 100k+
> projects should be possible.
> With regard to GovHack I think it needs to remain 99% on creating a fun
> atmosphere for developers. Fun in a challenging, learning and connecting
> way. The Govt interest for Apps and ROI on their sponsorships should be in
> the last 1%. Over the last three years GovHack has needed to raise
> awareness within Govt to get data and get them involved. Now they are at
> the party we just need to keep the right vibe going and let them have some
> And, I still think the DTO will be cool when it's up and running.
> Folks there will get it and help agencies update the way they work with
> creative technical folks.
> On Thursday, April 23, 2015, Steve Bennett <stevage at gmail.com> wrote:
>> Hi all,
>> I've been thinking for a while about the potential directions that a
>> GovHack hack can go (or not) after the event, and have finally written it
>> In the interests of easy reading and commenting I'll paste the text
>> here for discussion. (Obviously this version will be out of date if I have
>> to fix something...)
>> Hopefully more clarity around the different directions available to
>> hacks will lead to greater action?
>> Everyone loves hackathons. And almost as much, everyone loves asking “but
>> what happens to the projects afterwards?
>> There’s more than one route to follow. I’d like to propose four standard
>> recipes we can use to describe the prospects of each project.
>> #1: Start-up
>> The creators of the could form a business. The developers work very hard
>> to polish up what they’ve written until it’s a viable product ready for the
>> marketplace, and then try to build a start-up around it while probably
>> looking for external funding.
>> [image: Snap Send Solve - hackathon to start-up success story]
>> Snap Send Solve <http://www.snapsendsolve.com/>– hackathon to start-up
>> success story
>> This kind of result is very desirable for hackathon organisers because
>> there is such a clear story of benefits and outcomes: “a few thousand
>> dollars of sponsorship paid for a weekend hackathon which led to this $50
>> million start-up which makes the app your grandma uses, which is great for
>> the economy”.
>> *Ingredients required*: Start-up mentors, entrepreneurs, a business
>> focus from the get-go
>> #2: Government app
>> [image: OpenBinMap.org - a government app in waiting?]
>> OpenBinMap.org – a government app in waiting?
>> If you make an interesting and useful app with a government body’s data,
>> then maybe they’d like to take it on board. They might use the code base,
>> but it’s probably better to use the concept and vision and write the code
>> from scratch. Imagination isn’t a government strong suit, but once they see
>> something they like, they’re pretty good at saying “we need one of those”.
>> This also doesn’t seem to happen very often, but can we try harder? We
>> should follow GovHack up with serious discussions between hack developers
>> and the government bodies that sponsored them. Following my cheeky “
>> CanIBoatHere.com <http://caniboathere.com/>” category winner last year,
>> I did meet with Transport Safety Victoria, but didn’t really have the time
>> or motivation to pursue it. But they were very keen, so why couldn’t we
>> have made it work? Similarly, there was potentially money available from
>> the Victorian Technology Innovation Fund to support GovHack projects, but
>> no clear process meant that months of fumbling through paperwork might
>> eventually lead to nothing. Not so appealing to developers.
>> *Ingredients needed: *A solid process, government/developer wranglers,
>> pre-commitment to funding.
>> #3: Community project
>> [image: Eventable would make a great community project.]
>> <http://stevebennett.me/2015/04/23/after-the-hackathon-4-classic-recipes/eventable.in> would
>> make a great community project.
>> If a hack is interesting and important enough to other developers, could
>> it become a self-sustaining open source project? The idea seems plausible,
>> but I don’t know if I’ve seen it happen. The major blockers are the hackish
>> quality of the code itself which typically would require a major rewrite,
>> and the sense that the weekend was fun, and this would be a lot of work.
>> Hacks are a kind of showy facade. Once developers sit down to talk
>> seriously about onward development, all kinds of serious difficulties start
>> to emerge. And between the end of the weekend and the announcement of
>> prizes a lot of momentum gets lost which can be hard to start up again.
>> *Ingredients needed:* Post-hackathon events to explore projects and
>> establish communities.
>> #4: Story
>> [image: Living, Breathing Melbourne - still just a story.]
>> Living, Breathing Melbourne – still just a story.
>> And finally, let’s acknowledge that the most important part of many hacks
>> is their potential as an interesting story in their own right. Anthony
>> Mockler’s GovHack 2012 entry “Is your Pollie Smarter than a Fith Grader”
>> isn’t a failure because it didn’t lead to a start up – it was a great story
>> that captured a lot of attention. My team’s 2014 entry “Living,
>> Breathing Melbourne <http://melbourne.yuri.io/>” has been frequently
>> referred to as a model for actual open data dashboards, even though we
>> didn’t develop it further. We should try to extract as much value as
>> possible from these stories, and preserve their essence, even if only in
>> screenshots and blog posts.
>> *Ingredients needed*: Story tellers, blog posts, active engagement with
>> In summary
>> Let’s think of these different paths early on when discussing projects:
>> “This would make a great *community project*“, “I don’t see this going
>> anywhere, but let’s get the *story* out”, “It would be a shame if the
>> department doesn’t take this on as a *government app*“. And don’t write
>> off a hack just because it didn’t fit into the mould you were thinking of.
> *STEVEN DE COSTA *|
> *EXECUTIVE DIRECTOR *www.linkdigital.com.au
> okfn-au mailing list
> okfn-au at lists.okfn.org
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-au
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the okfn-au