Planet Linux Australia
We had quite the full day yesterday.
Susanne had arranged with Vincent's school, where he had been going to the holiday program, for Zoe to attend on Friday as well (if she wanted to). We'd been telling Zoe about it since Wednesday, and she'd been saying she didn't want to go, but I wanted her to actually see what she was declining before we made a final decision.
We tagged along on Friday morning when Susanne was dropping of Vincent. Once Zoe realised that it was just like her Kindergarten, and that the teachers seemed nice, she became more receptive to the idea, but in the end still couldn't quite bring herself to stay.
I borrowed Henner's monster pickup truck and Zoe and went to Barton Creek Square to do some clothes shopping. It was good timing, because there were heaps of sales on. I was glad that I had Zoe with me, because that way I could choose outfits for her that she actually liked.
It was the first time I've driven on the other side of the road for over a year, and in a monster pickup truck to boot. It was quite the experience.
We got back just before Susanne was going to head back to pick Vincent up, and Zoe really wanted to pick up Vincent, so Zoe went with Susanne and I popped out to a nearby mall to get something for myself and some lunch at VERTS Kebap, which is apparently a bit of a thing.
We played around in the pool in the afternoon, and then went out for dinner at The County Line, where we caught up with our old next-door neighbours, Neal and Eva and Graydon and their new addition, Wiley. Much meat was eaten.
After dinner, Henner, Vincent, Zoe and I went in to Austin to view the bats that roost under South Congress Bridge. We sat in the park under the bridge and waited for the right time for them to all fly out. There was a lady doing the rounds answering questions, and Zoe gave her a really good grilling.
We got back quite late from viewing the bats, and put the kids straight to bed.
(Robert Collins, HP & Joshua Hesketh, Rackspace Australia) 09:15 – 09:45 #OpenStack Identity and Federation
(Jamie Lennox, Red Hat)
Keystone is the central authentication and authorization point for OpenStack.
It already handles managing users via LDAP and SQL, however, as OpenStack and the number of possible identity sources grows, Keystone is evolving to rely primarily on external sources of identity using protocols like SAML. Keystone’s role then becomes one of pure authorization and mapping those identities into an OpenStack context.
For the unfamiliar, we’ll start with a quick recap of the role of Keystone and
the permission models of OpenStack, then look at the challenges of handling
many distinct authentication sources and the in-development changes required
for federated identity providers.
09:55 – 10:25
#Python Build Reasonableness and Semantic Versioning
Jamie is Australia’s Keystone core developer working for Red Hat in Brisbane and
currently the primary developer on Kite. He enjoys tinkering with anything
security related, and has recently been involved making the client side of OpenStack more usable for developers.
(Robert Collins, HP)
Semver and Python with PBR
PBR – Python Build Reasonableness
PBR is a setuptools plugin which OpenStack developed to provide simple and consistent minimal-boilerplate build definitions for its projects. Now used by all the OpenStack projects, PBR provides integration glue for core features:
– binary package creation for Linux distributors
– inclusion of files in tarballs
– changelog and authors file creation
– pypi summary creation
– version number creation
– sphinx doc stub creation and manpage enablement
– unified requirements management – for both easy-install and pip with single-file control
The most interesting part is the version number creation, since coming up with the right version number can be a contentious discussion in some projects. Semver provides simple and robust rules for deciding on version numbers, and I’m in the middle of implementing automation for these in PBR itself, with integration glue to export them in PEP-440, dpkg and rpm format. The only dependencies PBR has are git + a recent pip, so this should be useful for many attendees – and while PBR is an OpenStack invention we’re very interested in making sure its useful and reliable for anyone that wants to use it.
10:25 – 10:45
10:50 – 11:20
#Tempest: OpenStack Integrated Testing
(Matthew Treinish, HP)
Tempest is OpenStack’s integrated test suite which aims to provide validation that OpenStack is working. As such it is run as a gating on job on all proposed commits to OpenStack. It is designed to run against an operational OpenStack cloud, which includes everything from a devstack deployment to a public cloud. Tempest originally started as just a small number of integration tests to verify that the various OpenStack projects worked together. It has since grown into one of the top 5 most active OpenStack projects with several different classes of testing and validation.
This talk will provide an overview of what Tempest is and how it works. Providing an explanation of the philosophy behind the project, and insight into why things are setup a certain way. Additionally, it will cover some of the features in tempest and how to configure and run it locally with or without devstack.
11:30 – 12:00
#Changing the world with ZeroVM and Swift
Matthew Treinish is a part of the HP OpenStack team working to make OpenStack better. He’s been an active contributor to OpenStack since the Folsom cycle. He is the QA program PTL for the Juno development cycle, a core contributor on Tempest, elastic-recheck, and a couple of smaller projects and a member of the stable-maint team.
(Jakub Krajcovic, Rackspace Australia)
ZeroVM is a new generation of virtualization. It provides a secure sandbox for executing code and is able to spawn in under 5ms. It natively supports python execution out of the box.
This talk aims to outline how ZeroVM and Swift can start changing how we fundamentally think about computing and the consumption of IT resources. ZeroVM could be thought of as a “”micro-hypervisor”” that creates a sandboxed environment for code execution and through python middleware can run natively on top of a Swift storage cluster. This talk will present ZeroVM, describe about how it plugs into Swift and what capabilities the combination of these technologies opens.
The most immediate “”killer apps”” that the Swift+ZeroVM combination offers are in data processing:
– oil, geo, mining
– TV and movies
– photo and picture processing
Some less obvious but even more interesting are things like the possibility to completely redesign an SQL DB and create a structured query language that processes binary unstructured data instead of rows and columns.
12:00 – 13:30
13:30 – 14:00
#Deploy your python app into an OpenStack cloud using Solum
Jakub Krajcovic is a solutions architect with very varied professional experience. He has a background in computer science, started out as a HPUX engineer and Linux enthusiast but over the course of time found himself working on 2 feature films including the first of the Hobbit trilogy and gradually finding home in the world of cloud computing. In his spare time he also worked with the Open Group on translating parts of the TOGAF 9 Framework. He is passionate about complex problems surrounding large quantities of data and making utility computing a reality. Jakub currently leads Rackspace’s cloud architecture team in Australia.
(Angus Salkeld, Rackspace Australia)
This talk will give an introduction to Solum and show how you can use Solum to Deploy an application into an OpenStack cloud.
A short video of Solum in action will be shown to give the audience an idea of the problem that Solum is trying to solve.
The presenter will then go through some of the capablities of Solum and some future features that are been worked on.
14:10 – 14:40
I am a developer at Rackspace Hosting, working on multiple OpenStack projects (Solum, Heat, Mistral). Prior to Rackspace I worked at Red Hat on OpenStack and before that Clustering.
(Grant Murphy, Red Hat)
This session will look at the historical trend of vulnerabilities that have been found in OpenStack, how they are managed and the initiatives that the OpenStack security group currently is undertaking to help reduce future occurrences.
14:50 – 15:20
#TripleO – What, Why, How
Grant Murphy is a security engineer based in Brisbane currently working on product security for Red Hat. He is also a member of the upstream OpenStack vulnerability managment team and Python enthusiast.
(James Polley, HP)
What is(n’t) TripleO?
Why do I want to use it
How do I get started
15:20 – 15:40
15:45 – 16:15
#How to Read the Logs
After spending too many years as a sysadmin, James has forsaken the glorious excitement that is being woken in the middle of the night by broken systems with the glorious excitement that is creating and documenting systems that break and wake other people in the middle of the night. He fully intended to come back and update this bio prior to the conference, but embarrassingly forgot to do so.
(Anita Kuno, HP)
OpenStack generates a lot of log files in its testing process. Learn how to find and identify common patterns in log files from a member of the OpenStack Infrastructure team. Understand the different kinds of log files to expect, how to evaluate them to find why your patch is failing and what steps to take when you identify the failure. Learn how to search for bugs and how to file a bug report. Understanding the value that elastic-recheck provides will also be covered.
Anita Kuno is a Cloud Automation and Distribution Engineer at HP. She works on upstream OpenStack as part of the Infrastructure team. She has mentored many new contributors on how to develop with the OpenStack Infrastructure system which includes Gerrit and jenkins. She is a Gerrit upstream contributor.
16:25 – 16:55
#Large Scale Identification of Race Conditions (In OpenStack CI)
Anita has served as an election official for the OpenStack Program Technical Lead Election and the Technical Committee Election for two consecutive release cycles. She is also an astrologer and acupuncturist.
(Joseph Gordon, HP)
“Does your project have a CI system that suffers from an ever-growing set of race conditions? We have the tool for you: it has enabled increased velocity despite project growth.
When talking about the GNU HURD kernel, Richard Stallman once said, “it turned out that debugging these asynchronous multithreaded programs was really hard.” With 30+ asynchronous services developed by over 1000 people the OpenStack project is an object lesson of this problem. One of the consequences is race conditions often leak into code with no obvious defect. Just before OpenStack’s most recent stable release we were pushing the boundaries of what was possible with manual tracking of race conditions. To address this problem we have developed an ElasticSearch based toolchain called “elastic-recheck.” This helps us track race conditions so developers can fix them and identify when CI failures are related to the failed patch or are due to a known pre-existing race condition. Automated tracking of over 70 specific race conditions has allowed us to quickly determine which bugs are hurting us the most, allowing us to prioritize debugging efforts. Immediate and automated classification of test failures into genuine and false failures has saved countless hours that would have been wasted digging through the over 350MBs of logs produced by a single test run.”
16:55 – 17:10
Joe Gordon works full time on the open source project, OpenStack, on behalf of HP. He has spoken at, and co-chaired at OpenStack summits. And has given talks at such events as Europython 2013, CloudOpen (Japan 2014, Europe 2013), and OpenStack Israel.
(Robert Collins, HP & Joshua Hesketh, Rackspace Australia)
In a comment on my post about Taxing Inferior Products  Ben pointed out that most crashes are due to software bugs. Both Ben and I work on the Debian project and have had significant experience of software causing system crashes for Debian users.
But I still think that the widespread adoption of ECC RAM is a good first step towards improving the reliability of the computing infrastructure.
Currently when software developers receive bug reports they always wonder whether the bug was caused by defective hardware. So when bugs can’t be reproduced (or can’t be reproduced in a way that matches the bug report) they often get put in a list of random crash reports and no further attention is paid to them.
When a system has ECC RAM and a filesystem that uses checksums for all data and metadata we can have greater confidence that random bugs aren’t due to hardware problems. For example if a user reports a file corruption bug they can’t repeat that occurred when using the Ext3 filesystem on a typical desktop PC I’ll wonder about the reliability of storage and RAM in their system. If however the same bug report came from someone who had ECC RAM and used the ZFS filesystem then I would be more likely to consider it a software bug.
The current situation is that every part of a typical PC is unreliable. When a bug can be attributed to one of several pieces of hardware, the OS kernel and even malware (in the case of MS Windows) it’s hard to know where to start in tracking down a bug. Most users have given up and accepted that crashing periodically is just what computers do. Even experienced Linux users sometimes give up on trying to track down bugs properly because it’s sometimes very difficult to file a good bug report. For the typical computer user (who doesn’t have the power that a skilled Linux user has) it’s much worse, filing a bug report seems about as useful as praying.
One of the features of ECC RAM is that the motherboard can inform the user (either at boot time, after a NMI reboot, or through system diagnostics) of the problem so it can be fixed. A feature of filesystems such as ZFS and BTRFS is that they can inform the user of drive corruption problems, sometimes before any data is lost.
My recommendation of BTRFS in regard to system integrity does have a significant caveat, currently the system reliability decrease due to crashes outweighs the reliability increase due to checksums at this time. This isn’t all bad because at least when BTRFS crashes you know what the problem is, and BTRFS is rapidly improving in this regard. When I discuss BTRFS in posts like this one I’m considering the theoretical issues related to the design not the practical issues of software bugs. That said I’ve twice had a BTRFS filesystem seriously corrupted by a faulty DIMM on a system without ECC RAM.
Zoe woke up at around her usual 1:30am, with her mosquito bites troubling her. It seems that it's always around 1:30am that they interrupt her sleep. I put some cream on them and put her back to sleep in my bed.
I think at about 3:30am I awoke to find Vincent at the foot of my bed whispering something I couldn't make out. After I woke up enough to realise what was going on, I tried to talk to him, but he got upset and left. I decided to let him go.
Zoe woke up at around 7am, and went in to Vincent's room and found Henner asleep in there with him, and came back to my room, so it sounds like it was a fun night all round. Hopefully tonight will go better.
After breakfast, Susanne dropped Vincent's little sister Greta off at day care, and Zoe and Vincent had a great time on Vincent's trampoline. I joined in with them for a while and we had much fun just mucking around on the trampoline.
After that, we were going to go somewhere (I've forgotten), but ran into traffic from President Obama's visit, so we aborted that and went to the Austin Zoo and Animal Sanctuary (it's amazing how much my muscle memory wants me to type "Zoe" when I try to type "Zoo").
It was a pretty decent Zoo. Not huge, but not half-baked either. They had a god collection of big cats, with the tigers being pretty accessible. It was hot, in the 35°C range, but the lack of humidity made the heat quite tolerable. Zoe had a lot of fun feeding some (very large) goats.
We had what felt like one of the most long miniature train rides that I've ever had, for the price of $2.50 a ticket, and then headed off to get some sandwiches for lunch.
After lunch, Vincent and Zoe had a splash around in the "splash pad" of a strip mall near Henner and Susanne's house, and then after an ice cream we went home and jumped in the pool.
Another nice day in Austin. I put Zoe to bed early again without any fuss. Hopefully the mosquito bites won't give her grief tonight.
Yesterday was a pretty full day. We were up relatively early to head to the airport for a 10am flight. Chris dropped us off at about 8:30am. Check in was pretty quick, and I had the most amazing TSA experience I've ever had.
I think we must have gotten randomly opted into TSA Pre✓ or something, because I didn't have to take my laptop out of my bag or remove my shoes. It was amazing. We were through security in a matter of minutes. I was so astounded I almost felt the need to find a supervisor and thank them.
We made it to our gate comfortably before boarding time. Unfortunately I hadn't managed to convince Zoe to have a good breakfast, so she was already complaining of being hungry. I didn't want to miss the opportunity to pre-board by going to forage for food, so we just had to ride it out.
After we boarded and were about to push back, the plane's auxiliary power conked out. I was worried the plane was going to be broken and we've have to get off and wait for a new one, but fortunately they managed to just hook it up to gate power and restart it and we continued with our departure without it being too much later than scheduled.
The cabin crew took a while to start the refreshments, and Zoe was politely reminding me every 30 seconds that she was still hungry. The refreshments started, and then while they were half a dozen rows in front of us, the pilot announced we were heading for some turbulence and they were suspending the beverage service. Poor Zoe was very disappointed, but handled it very well.
We eventually got our snacks and drinks, which tided her over until we arrived in Austin. Susanne and Vincent sailed up to the kerb just as we emerged from the terminal, so it was very good timing.
Zoe and Vincent got along like long lost best friends. It was a battle to get Zoe to eat lunch, she was so distracted.
After some lunch and a splash around in the pool, Vincent's swim teacher arrived to give him a lesson. Zoe had been invited to join in as well, and after a few minutes watching and hesitating, she joined in. Having the swim teacher do in-home one on one lessons is awesome.
I put Zoe down to bed about half an hour earlier than normal, because that was Vincent's bedtime, and they were sharing a room. I figured with all the day's excitement, she could use the extra sleep anyway.
Austin is delightfully warm and dry. I think it was around 34°C and not much humidity. The pool was a great place to be.
One of the traditions of linux.conf.au that works really well is called the Ghosts Weekend. This is when the current organisers invite a selection of previous organisers somewhere for a weekend so they can perform a brain dump about things that went right for them, and in some cases, more importantly, what went wrong. They also go over the organisers plans to make sure that they're on track.
This all leads to a pretty intensive weekend!
The ghostsWe started on Friday with picking everyone up from the airport (my final pickup was 00:30, then we had to find some soda water for Ben & Leah's duty free Gin!). Saturday morning was a walk around all the venues, yes they're all within walking distance of one another. After a fantastic lunch at Coyote's we then hit a meeting room and got down to discussions.
If you're running a discussion like this, and most people in the room have laptops then I highly recommend using Gobby to take your notes. Everyone has a slightly different take on things, so note down slightly different things. Fantastic.
Our discussions continued over dinner on Saturday night which was at Fujiyama Teppanyaki, which is certainly a fun place to have dinner. Stewart did an amazing job at dodging the bit of cooked egg that one of the chefs flung his way!
nom nom nomSunday was back in the meeting room for continuing discussions. Followed by a few well earned beers and dinner at Wellington Brewery Bar. nom, nom, nom.
All in all, it was a fantastic weekend and I'd like thank the Ghosts who attended, give apologies to the Ghosts we couldn't invite and give a huge thank you to Susanne for organising a fantastic weekend that went incredibly smoothly!
During our announcement we wanted to show a fantastic little clip from 42 Below about Wellington. But following the tradition of Hobarts annoucement at LCA2008 we had sound FAIL, so it didn't work. Please, go and check out the video clip on YouTube. (But ignore the bit about winning a trip to Wellington, the competition has finished.)
Follow the signs, visit Wellington!
One task crossed off my imaginary todo list!
Nigel Pearson was great, giving us all an insight into the development of MythTV, not only how the development process works, but also the complexitiy of the internals of MythTV. That was really interesting.
An unexpected bonus was that all the talks were recorded. We weren't expecting the A/V stuff to be setup until Wednesday, but it was all ready to go (after one minor cable change) on Monday morning in our room. Fantastic! A big thank you to Josh and his A/V team. The recordings aren't up for downloading yet, I'll post here (and on the mythtv-users mailing list) when they're ready.
At the end of the day we had a large discussion about what features people wanted to see in MythTV, and in particular what features people wanted to see in MythTV for a 1.0 release. The general consensus was that MythTV as it stands has more than enough features for 1.0. Once the recordings are up I'll write a list of the key items that were discussed.
Finally, thank you to all my speakers, and everyone who came along to listen, and who took part in the discussion afterwards.
If you'd like to tell people how great your setup is; your current pet project; or almost anything else, then please let me know.
- by Michael Still
- Transcoding in MythTV
- by Paul Wayper
- MythTV Internals
- by Nigel Pearson
- Debugging DTV
- by Steven Ellis
- MythTV Development from '04 to Now
- by Nigel Pearson
- Lightning Talks
- Presence Awareness
- by Jonathan Oxer
WELLINGTON, New Zealand - Monday 15th June 2009 - Linux.conf.au announced the opening of its Call for Miniconfs for LCA2010. Miniconfs provide the opportunity of hosting 1-day mini-conferences on a variety of topics that run for 2 out of the 5 days during linux.conf.au. The Call for Miniconfs will remain open until 17 July 2009, after which time successful Miniconf Proposals will be notified and the best twelve selected to be included on the programme for LCA2010.
"Miniconfs are an important part of Linux.conf.au each year, and provide a great opportunity to host an entire day of sessions specific to a topic", says Andrew Ruthven, LCA2010 Director. "We're proud of hosting LCA2010 in Wellington, New Zealand and hope to see a variety of Miniconf Proposals to showcase the technical expertise of world's leading experts in free and open source software. When you gather IT experts together like this, the collective energy can help shape the future direction of emerging projects and developing technologies. That's what LCA2010 is all about – people getting together and making a difference".
IT businesses, government and community groups from around the world will also have the opportunity to showcase their work through presentations, displays and demonstrations at the LCA2010 Open Day, which will be held on Saturday 23rd January 2010. The conference will open its doors to the general public and highlight the best of breed Free and Open Source technology.
LCA2010 is easily affordable for professionals and hobbyists alike, thanks to generous sponsorship by leading proponents of free and open source software, and because the conference - much like the software - is largely organised by volunteers. If your business or organisation would like to take this opportunity to support LCA2010, please visit http://www.lca2010.org.nz/sponsors/why_sponsor.
Registrations to LCA2010 will open to delegates in September 2009.About linux.conf.au
Linux.conf.au is one of the world's best conferences for free and open source software! The coming Linux.conf.au, LCA2010, will be held at the Wellington Convention Centre in Wellington, New Zealand from Monday 18th January to Saturday 23rd January 2010. LCA2010 is fun, informal and seriously technical, bringing together Free and Open Source developers, users and community champions from around the world. LCA2010 is the second time linux.conf.au has been held in New Zealand, with the first being Dunedin in 2006.
For more information see: http://www.lca2010.org.nz/About Linux Australia
Linux Australia (http://www.linux.org.au/) is the peak body for Linux User Groups (LUGs) around Australia, and as such represents approximately 5000 Australian Linux users and developers. Linux Australia facilitates the organisation of this international Free Software conference in a different Australasian city each year.
For more information see: http://www.linux.org.au/Emperor Penguin Sponsors
LCA2010 is proud to acknowledge the support of our Emperor Penguin Sponsor, InternetNZ.
For more information see: http://www.internetnz.org.nz/Media Enquiries
Phone/Fax: +64 (4) 802 0422
Sociological Images has an interesting post by Jay Livingston PhD about a tennis final as a ritual . The main point is that you can get a much better view of the match on your TV at home with more comfort and less inconvenience, so what you get for the price of the ticket (and all the effort of getting there) is participating in the event as a spectator.
It seems to me that the same idea applies to community Linux conferences (such as LCA) and some Linux users group meetings. In terms of watching a lecture there are real benefits to downloading it after the conference so that you can pause it and study related web sites or repeat sections that you didn’t understand. Also wherever you might sit at home to watch a video of a conference lecture you will be a lot more comfortable than a university lecture hall. Some people don’t attend conferences and users’ group meetings because they would rather watch a video at home.Benefits of Attending (Apart from a Ritual)
One of the benefits of attending a lecture is the ability to ask questions. But that seems to mostly apply to the high status people who ask most questions. I’ve previously written about speaking stacks and my observations about who asks questions vs the number that can reasonably be asked .
I expect that most delegates ask no questions for the entire conference. I created a SurveyMonkey survey to discover how many questions people ask . I count LCA as a 3 day conference because I am only counting the days where there are presentations that have been directly approved by the papers committee, approving a mini-conf (and thus delegating the ability to approve speeches) is different.
Another benefit of attending is the so-called “hallway track” where people talk to random other people. But that seems to be of most benefit to people who have some combination of high status in the community and good social skills. In the past I’ve attended the “Professional Delegates Networking Session” which is an event for speakers and people who pay the “Professional” registration fee. Sometimes at such events there has seemed to be a great divide between speakers (who mostly knew each other before the conference) and “Professional Delegates” which diminishes the value of the event to anyone who couldn’t achieve similar benefits without it.How to Optimise a Conference as a Ritual
To get involvement of people who have the ritualistic approach one could emphasise the issue of being part of the event. For example to get people to attend the morning keynote speeches (which are sometimes poorly attended due to partying the night before) one could emphasise that anyone who doesn’t attend the keynote isn’t really attending the conference.
Conference shirts seem to be strongly correlated with the ritual aspect of conferences, the more “corporate” conferences don’t seem to offer branded clothing to delegates. If an item of branded schwag was given out before each keynote then that would increase the attendance by everyone who follows the ritual aspect (as well as everyone who just likes free stuff).
Note that I’m not suggesting that organisers of LCA or other conferences go to the effort of giving everyone schwag before the morning keynote, that would be a lot of work. Just telling people that anyone who misses the keynote isn’t really attending the conference would probably do.
I’ve always wondered why conference organisers want people to attend the keynotes and award prizes to random delegates who attend them. Is a keynote lecture a ritual that is incomplete if the attendance isn’t good enough?
-  http://tinyurl.com/m74pc95
-  http://etbe.coker.com.au/2013/02/01/speaking-stacks/
-  https://www.surveymonkey.com/s/RZ958TJ
We have only 1 week of the CFP left, and although we're getting some brilliant proposals we need a great deal more in order to build the wonderful conference that we want it to be. The linux.conf.au 2015 papers committee is looking for a broad range of proposals, and will consider submissions on anything from programming and software, to desktop, mobile, gaming, userspace, community, government, space, and education. There is only one rule:
Your proposal must be related to open source.
This year the papers committee is going to be focused on open source in education as well as our usual focus on deep technical content. We will also welcome presentations on:
- Clouds, datacenters and scalability.
- Community challenges; legal threats; education and outreach.
- Documentation for open source projects.
- HTML5; multimedia codecs.
- Kernel developments; new architectures.
- Open hardware; embedded systems; wearable computing.
- Security; privacy; anonymity.
- Networking; Software defined networking; bufferbloat; network function virtualization.
- Software development; programming languages.
- Sysadmin and automation.
What would you like to present at LCA 2015 in Auckland?
Yes? Then to submit your proposal, create an account, and select Submit a Proposal from the menu on the left hand side.
I don’t have nearly enough time to blog these days, but I am doing a bunch of writing for university. I decided I would publish a selection of the (hopefully) more interesting essays that people might find interesting Please note, my academic writing is pretty awful, but hopefully some of the ideas, research and references are useful.
For this essay, I had the most fun in developing my own alternative public policy model at the end of the essay. Would love to hear your thoughts. Enjoy and comments welcome!
Question: Critically assess the accuracy of and relevance to Australian public policy of the Bridgman and Davis policy cycle model.
The public policy cycle developed by Peter Bridgman and Glyn Davis is both relevant to Australian public policy and simultaneously not an accurate representation of developing policy in practice. This essay outlines some of the ways the policy cycle model both assists and distracts from quality policy development in Australia and provides an alternative model as a thought experiment based on the authors policy experience and reflecting on the research conducted around the applicability of Bridgman and Davis’ policy cycle model.
In 1998 Peter Bridgman and Glyn Davis released the first edition of The Australian Policy Handbook, a guide developed to assist public servants to understand and develop sound public policy. The book includes a policy cycle model, developed by Bridgman and Davis, which portrays a number of cyclic logical steps for developing and iteratively improving public policy. This policy model has attracted much analysis, scrutiny, criticism and debate since it was first developed, and it continues to be taught as a useful tool in the kit of any public servant. The fifth edition of the Handbook was the most recent, being released in 2012 which includes Catherine Althaus who joined Bridgman and Davis on the fourth edition in 2007.
The policy cycle model
The policy cycle model presented in the Handbook is below:
The model consists of eight steps in a circle that is meant to encourage an ongoing, cyclic and iterative approach to developing and improving policy over time with the benefit of cumulative inputs and experience. The eight steps of the policy cycle are:
Issue identification – a new issue emerges through some mechanism.
Policy analysis – research and analysis of the policy problem to establish sufficient information to make decisions about the policy.
Policy instrument development – the identification of which instruments of government are appropriate to implement the policy. Could include legislation, programs, regulation, etc.
Consultation (which permeates the entire process) – garnering of external and independent expertise and information to inform the policy development.
Coordination – once a policy position is prepared it needs to be coordinated through the mechanisms and machinations of government. This could include engagement with the financial, Cabinet and parliamentary processes.
Decision – a decision is made by the appropriate person or body, often a Minister or the Cabinet.
Implementation – once approved the policy then needs to be implemented.
Evaluation – an important process to measure, monitor and evaluate the policy implementation.
In the first instance is it worth reflecting on the stages of the model, which implies the entire policy process is centrally managed and coordinated by the policy makers which is rarely true, and thus gives very little indication of who is involved, where policies originate, external factors and pressures, how policies go from a concept to being acted upon. Even to just develop a position resources must be allocated and the development of a policy is thus prioritised above the development of some other policy competing for resourcing. Bridgman and Davis establish very little in helping the policy practitioner or entrepreneur to understand the broader picture which is vital in the development and successful implementation of a policy.
The policy cycle model is relevant to Australian public policy in two key ways: 1) that it both presents a useful reference model for identifying various potential parts of policy development; and 2) it is instructive for policy entrepreneurs to understand the expectations and approach taken by their peers in the public service, given that the Bridgman and Davis model has been taught to public servants for a number of years. In the first instance the model presents a basic framework that policy makers can use to go about the thinking of and planning for their policy development. In practise, some stages may be skipped, reversed or compressed depending upon the context, or a completely different approach altogether may be taken, but the model gives a starting point in the absence of anything formally imposed.
Bridgman and Davis themselves paint a picture of vast complexity in policy making whilst holding up their model as both an explanatory and prescriptive approach, albeit with some caveats. This is problematic because public policy development almost never follows a cleanly structured process. Many criticisms of the policy cycle model question its accuracy as a descriptive model given it doesn’t map to the experiences of policy makers. This draws into question the relevance of the model as a prescriptive approach as it is too linear and simplistic to represent even a basic policy development process. Dr Cosmo Howard conducted many interviews with senior public servants in Australia and found that the policy cycle model developed by Bridgman and Davis didn’t broadly match the experiences of policy makers. Although they did identify various aspects of the model that did play a part in their policy development work to varying degrees, the model was seen as too linear, too structured, and generally not reflective of the at times quite different approaches from policy to policy (Howard, 2005). The model was however seen as a good starting point to plan and think about individual policy development processes.
Howard also discovered that political engagement changed throughout the process and from policy to policy depending on government priorities, making a consistent approach to policy development quite difficult to articulate. The common need for policy makers to respond to political demands and tight timelines often leads to an inability to follow a structured policy development process resulting in rushed or pre-canned policies that lack due process or public consultation (Howard, 2005). In this way the policy cycle model as presented does not prepare policy-makers in any pragmatic way for the pressures to respond to the realities of policy making in the public service. Colebatch (2005) also criticised the model as having “not much concern to demonstrate that these prescriptions are derived from practice, or that following them will lead to better outcomes”. Fundamentally, Bridgman and Davis don’t present much evidence to support their policy cycle model or to support the notion that implementation of the model will bring about better policy outcomes.
Policy development is often heavily influenced by political players and agendas, which is not captured in the Bridgman and Davis’ policy cycle model. Some policies are effectively handed over to the public service to develop and implement, but often policies have strong political involvement with the outcomes of policy development ultimately given to the respective Minister for consideration, who may also take the policy to Cabinet for final ratification. This means even the most evidence based, logical, widely consulted and highly researched policy position can be overturned entirely at the behest of the government of the day (Howard, 2005) . The policy cycle model does not capture nor prepare public servants for how to manage this process. Arguably, the most important aspects to successful policy entrepreneurship lie outside the policy development cycle entirely, in the mapping and navigation of the treacherous waters of stakeholder and public management, myriad political and other agendas, and other policy areas competing for prioritisation and limited resources.
The changing role of the public in the 21st century is not captured by the policy cycle model. The proliferation of digital information and communications creates new challenges and opportunities for modern policy makers. They must now compete for influence and attention in an ever expanding and contestable market of experts, perspectives and potential policies (Howard, 2005), which is a real challenge for policy makers used to being the single trusted source of knowledge for decision makers. This has moved policy development and influence away from the traditional Machiavellian bureaucratic approach of an internal, specialised, tightly controlled monopoly on advice, towards a more transparent and inclusive though more complex approach to policy making. Although Bridgman and Davis go part of the way to reflecting this post-Machiavellian approach to policy by explicitly including consultation and the role of various external actors in policy making, they still maintain the Machiavellian role of the public servant at the centre of the policy making process.
The model does not clearly articulate the need for public buy-in and communication of the policy throughout the cycle, from development to implementation. There are a number of recent examples of policies that have been developed and implemented well by any traditional public service standards, but the general public have seen as complete failures due to a lack of or negative public narrative around the policies. Key examples include the Building the Education Revolution policy and the insulation scheme. In the case of both, the policy implementation largely met the policy goals and independent analysis showed the policies to be quite successful through quantitative and qualitative assessment. However, both policies were announced very publicly and politically prior to implementation and then had little to no public narrative throughout implementation leaving the the public narrative around both to be determined by media reporting on issues and the Government Opposition who were motivated to undermine the policies. The policy cycle model in focusing on consultation ignores the necessity of a public engagement and communication strategy throughout the entire process.
The Internet also presents significant opportunities for policy makers to get better policy outcomes through public and transparent policy development. The model down not reflect how to strengthen a policy position in an open environment of competing ideas and expertise (aka, the Internet), though it is arguably one of the greatest opportunities to establish evidence-based, peer reviewed policy positions with a broad range of expertise, experience and public buy-in from experts, stakeholders and those who might be affected by a policy. This establishes a public record for consideration by government. A Minister or the Cabinet has the right to deviate from these publicly developed policy recommendations as our democratically elected representatives, but it increases the accountability and transparency of the political decision making regarding policy development, thus improving the likelihood of an evidence-based rather than purely political outcome. History has shown that transparency in decision making tends to improve outcomes as it aligns the motivations of those involved to pursue what they can defend publicly. Currently the lack of transparency at the political end of policy decision making has led to a number of examples where policy makers are asked to rationalise policy decisions rather than investigate the best possible policy approach (Howard, 2005). Within the public service there is a joke about developing policy-based evidence rather than the generally desired public service approach of developing evidence-based policy.
Although there are clearly issues with any policy cycle model in practise due to the myriad factors involved and the at times quite complex landscape of influences, by constantly referencing throughout their book the importance of “good process” to “help create better policy” (Bridgman & Davis, 2012), they both imply their model is a “good process” and subtly encourage a check-box style, formally structured and iterative approach to policy development. The policy cycle in practice becomes impractical and inappropriate for much policy development (Everett, 2003). Essentially, it gives new and inexperienced policy makers a false sense of confidence in a model put forward as descriptive which is at best just a useful point of reference. In a book review of the 5th edition of the Handbook, Kevin Rozzoli supports this by criticising the policy cycle model as being too generic and academic rather than practical, and compares it to the relatively pragmatic policy guide by Eugene Bardach (2012).
Bridgman and Davis do concede that their policy cycle model is not an accurate portrayal of policy practice, calling it “an ideal type from which every reality must curve away” (Bridgman & Davis, 2012). However, they still teach it as a prescriptive and normative model from which policy developers can begin. This unfortunately provides policy developers with an imperfect model that can’t be implemented in practise and little guidance to tell when it is implemented well or how to successfully “curve away”. At best, the model establishes some useful ideas that policy makers should consider, but as a normative model, it rapidly loses traction as every implementation of the model inevitably will “curve away”.
The model also embeds in the minds of public servants some subtle assumptions about policy development that are questionable such as: the role of the public service as a source of policy; the idea that good policy will be naturally adopted; a simplistic view of implementation when that is arguably the most tricky aspect of policy-making; a top down approach to policy that doesn’t explicitly engage or value input from administrators, implementers or stakeholders throughout the entire process; and very little assistance including no framework in the model for the process of healthy termination or finalisation of policies. Bridgman and Davis effectively promote the virtues of a centralised policy approach whereby the public service controls the process, inputs and outputs of public policy development. However, this perspective is somewhat self serving according to Colebatch, as it supports a central agency agenda approach. The model reinforces a perspective that policy makers control the process and consult where necessary as opposed to being just part of a necessarily diverse ecosystem where they must engage with experts, implementers, the political agenda, the general public and more to create robust policy positions that might be adopted and successfully implemented. The model and handbook as a whole reinforce the somewhat dated and Machiavellian idea of policy making as a standalone profession, with policy makers the trusted source of policies. Although Bridgman and Davis emphasise that consultation should happen throughout the process, modern policy development requires ongoing input and indeed co-design from independent experts, policy implementers and those affected by the policy. This is implied but the model offers no pragmatic way to do policy engagement in this way. Without these three perspectives built into any policy proposal, the outcomes are unlikely to be informed, pragmatic, measurable, implementable or easily accepted by the target communities.
The final problem with the Bridgman and Davis public policy development model is that by focusing so completely on the policy development process and not looking at implementation nor in considering the engagement of policy implementers in the policy development process, the policy is unlikely to be pragmatic or take implementation opportunities and issues into account. Basically, the policy cycle model encourages policy makers to focus on a policy itself, iterative and cyclic though it may be, as an outcome rather than practical outcomes that support the policy goals. The means is mistaken for the ends. This approach artificially delineates policy development from implementation and the motivations of those involved in each are not necessarily aligned.
The context of the model in the handbook is also somewhat misleading which affects the accuracy and relevance of the model. The book over simplifies the roles of various actors in policy development, placing policy responsibility clearly in the domain of Cabinet, Ministers, the Department of Prime Minister & Cabinet and senior departmental officers (Bridgman and Davis, 2012 Figure 2.1). Arguably, this conflicts with the supposed point of the book to support even quite junior or inexperienced public servants throughout a government administration to develop policy. It does not match reality in practise thus confusing students at best or establishing misplaced confidence in outcomes derived from policies developed according to the Handbook at worst.
An alternative model
Part of the reason the Bridgman and Davis policy cycle model has had such traction is because it was created in the absence of much in the way of pragmatic advice to policy makers and thus has been useful at filling a need, regardless as to how effective is has been in doing so. The authors have however, not significantly revisited the model since it was developed in 1998. This would be quite useful given new technologies have established both new mechanisms for public engagement and new public expectations to co-develop or at least have a say about the policies that shape their lives.
From my own experience, policy entrepreneurship in modern Australia requires a highly pragmatic approach that takes into account the various new technologies, influences, motivations, agendas, competing interests, external factors and policy actors involved. This means researching in the first instance the landscape and then shaping the policy development process accordingly to maximise the quality and potential adoptability of the policy position developed. As a bit of a thought experiment, below is my attempt at a more usefully descriptive and thus potentially more useful prescriptive policy model. I have included the main aspects involved in policy development, but have included a number of additional factors that might be useful to policy makers and policy entrepreneurs looking to successfully develop and implement new and iterative policies.
It is also important to identify the inherent motivations of the various actors involved in the pursuit, development of and implementation of a policy. In this way it is possible to align motivations with policy goals or vice versa to get the best and most sustainable policy outcomes. Where these motivations conflict or leave gaps in achieving the policy goals, it is unlikely a policy will be successfully implemented or sustainable in the medium to long term. This process of proactively identifying motivations and effectively dealing with them is missing from the policy cycle model.
The Bridgman and Davis policy cycle model is demonstrably inaccurate and yet is held up by its authors as a reasonable descriptive and prescriptive normative approach to policy development. Evidence is lacking for both the model accuracy and any tangible benefits in applying the model to a policy development process and research into policy development across the public service continually deviates from and often directly contradicts the model. Although Bridgman and Davis concede policy development in practise will deviate from their model, there is very little useful guidance as to how to implement or deviate from the model effectively. The model is also inaccurate in that is overly simplifies policy development, leaving policy practitioners to learn for themselves about external factors, the various policy actors involved throughout the process, the changing nature of public and political expectations and myriad other realities that affect modern policy development and implementation in the Australian public service.
Regardless of the policy cycle model inaccuracy, it has existed and been taught for nearly sixteen years. It has shaped the perspectives and processes of countless public servants and thus is relevant in the Australian public service in so far as it has been used as a normative model or starting point for countless policy developments and provides a common understanding and lexicon for engaging with these policy makers.
The model is therefore both inaccurate and relevant to policy entrepreneurs in the Australian public service today. I believe a review and rewrite of the model would greatly improve the advice and guidance available for policy makers and policy entrepreneurs within the Australian public service and beyond.
(Please note, as is the usual case with academic references, most of these are not publicly freely available at all. Sorry. It is an ongoing bug bear of mine and many others).
Althaus, C, Bridgman, P and Davis, G. 2012, The Australian Policy Handbook. Sydney, Allen and Unwin, 5th ed.
Bridgman, P and Davis, G. 2004, The Australian Policy Handbook. Sydney, Allen and Unwin, 3rd ed.
Bardach, E. 2012, A practical guide for policy analysis: the eightfold path to more effective problem solving, 4th Edition. New York. Chatham House Publishers.
Everett, S. 2003, The Policy Cycle: Democratic Process or Rational Paradigm Revisited?, The Australian Journal of Public Administration, 62(2) 65-70
Howard, C. 2005, The Policy Cycle: a Model of Post-Machiavellian Policy Making?, The Australian Journal of Public Administration, Vol. 64, No. 3, pp3-13.
Rozzoli, K. 2013, Book Review of The Australian Policy Handbook: Fifth Edition., Australasian Parliamentary Review, Autumn 2013, Vol 28, No. 1.
I recently had a medical appointment cancelled due to a “computer crash”. Apparently the reception computer crashed and lost all bookings for a day and they just made new bookings for whoever called – and anyone who had a previous booking just missed out. I’ll probably never know whether they really had a computer problem or just used computer problems as an excuse when they made a mistake. But even if it wasn’t a real computer problem the fact that computers are so unreliable overall that “computer crash” is an acceptable excuse indicates a problem with the industry.
The problem of unreliable computers is a cost to everyone, it’s effectively a tax on all business and social interactions that involve computers. While I spent the extra money on a server with ECC RAM for my home file storage I have no control over the computers purchased by all the companies I deal with – which are mostly the cheapest available computers. I also have no option to buy a laptop with ECC RAM because companies like Lenovo have decided not to manufacture them.
It seems to me that the easiest way of increasing overall reliability of computers would be to use ECC RAM everywhere. In the early 90′s all IBM compatible PCs had parity RAM, that meant that for each byte there was one extra bit which would report 100% of single-bit errors and 50% of errors that involved random memory corruption. Then manufacturers decided to save a tiny amount of money on memory by using 8/9 the number of chips for desktop/laptop systems and probably make more money on selling servers with ECC RAM. If the government was to impose a 20% tax on computers that lack ECC RAM then manufacturers would immediately start using it everywhere and the end result would be no price increase overall as it’s cheaper to design desktop systems and servers with the same motherboards – apparently some desktop systems have motherboard support for ECC RAM but don’t ship with suitable RAM or advertise the support for such RAM.
This principle applies to many other products too. One obvious example is cars, a car manufacturer can sell cheap cars with few safety features and then when occupants of those cars and other road users are injured the government ends up paying for medical expenses and disability pensions. If there was a tax for every car that has a poor crash test rating and a tax for every car company that performs badly in real world use then it would give car companies some incentive to manufacture safer vehicles.
Now there are situations where design considerations preclude such features. For example implementing ECC RAM in mobile phones might involve technical difficulties (particularly for 32bit phones) and making some trucks and farm equipment safer might be difficult. But when a company produces multiple similar products that differ significantly in quality such as PCs with and without ECC RAM or cars with and without air-bags there would be no difficulty in making them all of them higher quality.
I don’t think that we will have a government that implements such ideas any time soon, it seems that our government is more interested in giving money to corporations than taxing them. But one thing that could be done is to adopt a policy of only giving money to companies if they produce high quality products. If a car company is to be given hundreds of millions of dollars for not closing a factory then that factory should produce cars with all possible safety features. If a computer company is going to be given significant tax breaks for doing R&D then they should be developing products that won’t crash.
No related posts.