Steve Bennett blogs

…about maps, open data, Git, and other tech.

Category Archives: Open Knowledge

2015’s proudest moments

Self-doubt is awful, so this is for Future Steve: here are lots of things you did in 2015 that you can be proud of!

  1. Created Swagger API documentation for PTV’s real-time API, as part of the VicTripathon hackfest. PTV’s documentation is a developer’s nightmare. My version has live testing of the API built in and links to various wrappers in different languages.
  2. Designed a process for judging mobile apps (way outside my area of expertise!) for VicTripathon, across 4 different platforms, with help from Installr. Measure of success: the devs said it was ok.
  3. Created a fun way to explore the combined tree inventories of a dozen councils across Australia.
  4. Created uses open data published by councils in standard formats to tell you if it’s bin night where you live. Provides a nice incentive for councils publishing their first datasets.
  5. Created lightweight, open standards so that councils publishing the same data can do so in an interoperable way. And some of them are actually using it!
  6. The OpenCouncilData toolkit (co-created with Ellen Bicknell), provides a lot of guidance and useful background for councils embarking on the open data journey.
  7. A constantly updated map showing exactly how many datasets each council is currently publishing.
  8. csv-geo-au: A standard for publishing spatial data that refers to regions such as ABS statistical divisions or Australian commonwealth electoral divisions.
  9. Helping get VicRoads and Geelong’s street-level imagery on Mapillary.
  10. Building an automatic feed of real-time environmental data into City of Melbourne’s open data portal.
  11. A proof of concept for a super trail finder, which won a GovHack prize with help from Matt Cengia.
  12. Built 5 Terria-based maps: NEII Viewer (BOM), City of Sydney Environment and Sustainability Portal, a proof of concept for the Greater Sydney Commission, Northern Australia Investment Map, and ParlMap. The last is not public, but a really nice clone of NationalMap providing access to historical election and electoral boundary data for parliamentarians and the Parliamentary Library staff.
  13. Helped organise HealthHack: we had 10/10 happy problem owners in Melbourne, 60 participants, and a really awesome atmosphere.
  14. Wrote the definitive guide to YAML multi-line strings. (Ok, I started it last year, but most of the grunt work was this year).
  15. Participated in developing the next version of Fiscal Data Package, including a major change in presentation.
  16. Got a photo I took on the front cover of a book, Exploring the Jagungal Wilderness. (It’s also a physical book).
  17. Spoke about open data and National Map at lots of events: Local Government Spatial Reference Group, forum, MAV Technology forum (local government),  WebNetwork (local government), NewTech (state government), Open Data Government Community Forum (federal)
  18. Organised a Spatial Analytics for Policy Makers Workshop in the Victorian Government, with speakers from four different mapping platforms represented.
  19. Taught mapping workshops at La Trobe and Victoria University.
  20. Refactored and seriously improved part of the TerriaJS code that that deals with region mapping CSV files, plus much better choroplething.
  21. Designed and launched the GeoNext hackfest.
  22. Co-organised 5 cycle tours: Moe-Inverloch-Port Albert-Rosedale, Nelson-Warrnambool, Geelong-Rye-Melbourne, Tallarook-Jamieson-Benalla, Mt Beauty-Hotham-Falls Creek-Wangaratta.

After the hackathon: 4 classic recipes


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 hack 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.

Snap Send Solve - hackathon to start-up success story

Snap Send Solve – 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 - a government app in waiting? – 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 “” 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

Eventable would make a great community project.

Eventable 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

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” 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 journalists

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.