police hack day ideas

Just finished a G+ Hangout with a few police peeps and we strayed onto the idea of a hack day. This came from a conversation where the advantages of free and open source sites, apps and software was being compared to the commercially developed products sold into the market to do a specific job.

My experience

My comment on this (from experience) is that it is more dangerous for a government organisation to venture into the world of free, open source products than it is to stick to the tried and tested model of writing very complicated specification documents, three-way tender processes, months of shortlisting, more scrutinisation, fine tuning, financial checks and finally a procurement contract. My rather cynical view of this process is that we've over-engineered the process to the point where the more a project costs to deliver, the more interest it generates internally and along with that, a label of importance.  A lone internal developer using open source software could easily create a killer app which would be largely ignored internally because no actual money appeared to have been spent on it.  My argument is that this should be reversed; if someone creates a killer app for nothing, it is a double win and should be regarded as such.

Hack Day

First comes a set of requirements for what WE want to do, not what the company is trying to sell us.  My experience with Microsoft Word is that 95% of users tend to only use 5% of the product's potential (glorified typewriter).  This suggests that we'd be better off in the main with a free equivalent for 95% of users and only pay the expensive software licenses for the 5% or power users who actually needs those advanced facilities.
So we determine what we want.  Then we share it with others to see which features are common to all.  At this stage we should not expect 100% of what we feel we need.  We should be aiming to be happy if the proposed solution does at least 70% - 80% of what we want.  Once this is off the ground, the rest will follow very quickly.
Next, we bring in the techies/geeks/coders/hackers who are usually less interested in ideas and more interested in making stuff.  We let them soak for a while and then the fun starts.  The ideas people and the techies start working together to develop the protypes.  We need people to comment on the functionality, others to keep usability in mind, others who can design lovely buttons, graphics and banners and the coders to pull it all together.
I'd say this could easily be a 2 or 3 day event.  It could be a Thurs/Fri worksday followed by an optional Saturday or it could start at the weekend and continue into a Mon/Tues. If it is kept to a single day event, I'd say it would need to be preceded by a few weeks of online conversation with proposals and votes to determine up-front what people want to 'hack'.  This could be done in two stages with a public policecamp/copcamp to tease out the ideas and crystalise the requirements followed by a period of online discussion and culminating in the hack day where something is actually built.

An idea as an example

My starter for 10 would be a very simple police application which is designed to enable multiple members of staff to contribute to a single Twitter page.  The idea being to moderate posts where necessary and also to add or remove functionality like posting tweets, links or images.  Another key requirement is for the system to store who tweeted what so that any post, reply, mention or direct message can be attributed to a specific member of staff if disputed at a later stage. Other ideas for Twitter-based functionality is the monitoring of search terms (like Tweetdeck), sentiment detection, pre-crime predictions and analysis tools for retweets and reach.

And another one

Another approach could be solving the problem of reducing time posting updates to multiple channels.  The list of potential places to post updates is growing fast - Website, email, SMS texts, Facebook, Twitter, FourSquare, Flickr, YouTube, AudioBoo, Pinterest, Storyfy, Google+, So.cl, Bambuser, Cover it Live, Ustream . . . the list gets every longer. When you break these down, there are some areas where duplication could be streamlined - headline, short text (140 characters), long text, links, photos, caption, video, metadata, tags.  If we could build an application where each of these fields can be filled in only once depending on the content available, it could save a lot of time. The same approach could be applied to the engagement messages posted back.  If someone asks a question about a post via Twitter but not Facebook, we could build in the ability to re-post the Twitter question to Facebook and then use the same answer on both Twitter and Facebook.

This isn't a new idea

To finish, I'll revisit my long-term aim which was to consolidate the hosting of police websites and the Content Management Systems used. I think there is little chance of achieving a single solution for anything but perhaps it would be reasonable to strive for 4 or 5 main systems shared between all 43 forces rather than 43 separate systems?  For hosting we could look at one ASP solution for internal police server hosting (which one force has already offered), an open source alternative and the same for external hosting.  That is four basic hosting solutions to suit most forces.  The same combination of internal/external, commercial/opensource CMS would also offer flexibility but also reduce costs significantly.  The final frontier is then to get force experts to share their knowledge of these systems which would save significant external support contract costs.