Wednesday, 28 March 2018

What could Open Government learn from us Open Technology folks?

Despite open government’s best intentions to prioritise collaboration, government bodies consistently duplicate each other’s effort. Collaborating as effectively as open communities is much harder than you’d think.

A number of us “open technologists” have drafted a paper describing the challenges government faces, along with our vision for how to address these. It is being presented as part of Australia’s updated Open Government National Action Plan.

Reading time: 20 minutes (8 pages).

Open letter

This letter is presented on behalf of the citizens, technologists and organisations signed below.

When addressing the updated Open Government National Action Plan, and actions from the plan, we request stakeholders:
  • Acknowledge that the indicators for success are more than just “value for money” and “mitigation of risk”. 
  • Measure and prioritise: 
    • “Effectiveness of collaboration”, 
    • “Sustainability in the face of rapid innovation”, and 
    • “Resilience to monopolistic behaviours”. 
  • Develop an “Open Government Maturity Model” which describes open government goals and the processes required to achieve them.
  • Measure effectiveness at realising open government goals.
  • Arm decision makers with accessible, evidence based research into what works, so they can trust, select and defend collaborative strategies which are often counter-intuitive within traditional hierarchically managed organisations.
  • Use, extend, or create open technologies, in that order:
    1. Use existing open material if it exists;
    2. Otherwise extend and give back;
    3. As a last resort, create your own system.
  • Embrace modular architectures backed by open standards.
  • Prioritise initiatives which can attract and sustain participation from multiple contributors and organisations.
  • Promote collaboration between all levels of government, and between nations.
  • Invest in the communities of the projects you depend upon. Ensure there is funding to maintain a core team. Reduce barriers to entry in order to attract a wide contributor base. Develop indicators for reporting on the success of these investment strategies.
  • Consider strategies to flatten government’s spending cycles, especially for community based projects. 
  • Prioritise agile, iterative development methodologies over “big bang”, “whole of government” purchases.

Background reasoning

Democracy is founded on collaboration

Democratic governments are based upon collaboration. They work on behalf of citizens, for their citizens’ benefit. Based on this social mandate, the Australian government committed to the principles of open government in 2010, and signed up to the international Open Government Declaration in 2015. This declaration emphasises how openness and technology is to be used to make governments more collaborative, transparent, accountable, responsive, effective, innovative, and empowering of citizens.

However, by 2018, government bodies are regularly not collaborating, even though individuals involved want to. Why? Old acquisition processes which prioritise "value for money" and "mitigation of risk" inadvertently cause agencies to duplicate effort. In the digital economy, success indicators additionally include “effectiveness of collaboration”, “sustainability in the face of rapid innovation” and “resilience to monopolistic behaviours”. If governments are to collaborate as effectively as “open” communities, like open source software or Wikipedia, we need to use these additional indicators.
Recommendation 1: Develop an “Open Government Maturity Model” which describes open government goals and the processes required to achieve them.
Such a model should draw from open community processes, such as the Apache Foundation’s open source incubation processes.

The allure of “open”

In the early days of the “open” movement, Eric Raymond prophesied in The Cathedral and the Bazaar:
“Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software hoarding is morally wrong ... but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem.”
Successful open communities have shown it is possible to attract more contributors from outside the organisation than can ever mustered from within.
In the digital economy, collaboration out-competes competition.

Principles of the digital economy

In the digital economy, free copying, free tools, and the interconnectivity of the Internet has made it possible to tap into the world’s collective intelligence. This has led to:
  • Exponential information growth;
  • Exceptionally complex systems;
  • Rapid innovation;
  • And on the flip side, rapid obsolescence.
While it will always be tempting to build your own system, any self-built system will likely be out-innovated and become obsolete.
Recommendation 2: Use, Extend, or Create open technologies, in that order:
  1. Use existing open material if it exists;
  2. Otherwise extend and give back;
  3. As a last resort, create your own, share, and try to attract collaborators.

“Open” is just the start

When adopting open technologies, we embrace “free access” to software, standards, and data. But there is more:
Openness is an enabler. It minimises legal and technical barriers to collaboration and sharing. Sharing ideas spawns more ideas and supercharges innovation. The reciprocity practices prevalent in collaborative communities inspire and empower individuals to contribute what they are passionate about, achieve their full potential, and collectively we all benefit.

The “community litmus test”

The Apache software foundation, like many open source foundations, emphasise the importance of diverse and sustainable communities for each of their projects. This applies the “wisdom of crowds” to validate the value and viability of each project. We believe governments should develop and apply similar criteria to validate the technical viability and community interest in projects they take on.
Recommendation 3: Prioritise initiatives which can attract and sustain participation from multiple contributors and organisations.

“Copying” is not “collaboration”

The Australian Digital Service Standard proudly states that it has been “adapted from the UK Government Design Principles”. This statement highlights a flaw in government’s approach to open principles. “Copying” instead of “collaborating” breaks a core principle of information management:
Retain a single point of truth.
Government employees should be reaching out to their counterparts to collaboratively harmonise policies, processes, guides, best practices, software and more.

“Government collaboration” is not as good as “open collaboration”

Collaboration in the “open” sense involves reciprocity, sharing, peer production, community building, trust, communication, inclusiveness, standards based interoperability, sustainability, and meritocracy.  Everyone involved is empowered to “scratch an itch”, develop an idea, and the community adopts the best ideas. This empowerment is a formula for rapid innovation.
However,
Traditional management views open collaboration as time consuming, imprecise, unreliable, hard to manage, rarely addresses short term objectives, hard to quantify in a business case, and rarely mentioned in acquisition guides. Yet, in a digital economy, collaborative communities are regularly out-innovating and out-competing closed or centrally controlled initiatives.
By contrast, Government’s interpretation of collaboration has typically been based on the International Association for Public Participation (IAP2) using a spectrum of:
  • Inform: You will be told;
  • Consult: Your concerns will be considered;
  • Involve: Your concerns will be options;
  • Collaborate: Your advice will be sought;
  • Empower: You will decide what we implement.
There is no mention of co-development. In all these cases, the sponsoring agency still controls the process; still controls the allocation of funds; and still controls the management of labour. Bureaucratic overhead typically hampers contributions from external individuals or agencies. And here we encounter one of the subtle differences between open communities and open government:
Governments currently organise labour through command and control hierarchies while open communities typically coordinate themselves loosely around principles of self-direction, co-development, volunteering and reciprocity.
When the Digital Transformation Agency was being launched, Malcolm Turnbull (who is now Prime Minister) stated,
"I'm a great believer in being much more global in our approach, ... we're all dealing with the same problems, pretty much. ...  We want to break down silos, break down all of the inertia that comes from empire building, so that citizens or businesses will have a seamless, straightforward way of dealing with government -- federal, state, or local."
The first Open Government National Action Plan focuses at the national level, without mentioning state or local government.
Recommendation 4: Promote collaboration between all levels of government, and between nations.

“Open” by itself is of little value

The Australia’s Digital Services Design Principle 10 states: “Make things open: it makes things better.” As such, agencies have been publishing open datasets and software but have not been evaluating if they are being used effectively.
Making things open and hoping they will be used is like talking into the void and hoping others will hear. It is hit-and-miss.
A digital asset only realises its value once it is discovered, and then integrated with other systems. The more widely it is used and extended, the more valuable it becomes.
Recommendation 5: Measure effectiveness at realising open government goals.

Loving a community to death

Collaborative projects are susceptible to being “loved to death”. This happens when a project attracts an active user base without attracting matching contributions. The core team becomes overwhelmed, leaving insufficient capacity to cover essential operation and maintenance tasks.
Organisations shouldn’t overload a community they depend upon. As well as being not nice, it is bad business. Successful open projects have worked out how to apply a combination of:
  1. Politely saying “no” to “gifts” of unsupported extra functionality;
  2. Helping users become contributors, either in kind or financially;
  3. Minimising the onboarding effort for both contributors and the project’s core team.
If a sponsoring organisation isn’t ready to act as a good community citizen, actively supporting the long term sustainability of a project, then the sponsor will probably have a disappointing experience. The sponsor will make self-centered, short-term decisions, and won’t get the support required when most needed. The sponsor will likely be better off with proprietary systems, and the open community would be better off without the sponsor.

Attracting community

A team from the University of Massachusetts researching the success characteristics of open source projects found that projects which were successful at startup typically possessed:
  1. A clearly defined vision;
  2. Clear utility;
  3. And leaders who led by doing.
The projects which grew tended to:
  1. Attract larger user communities;
  2. Attract external developers, with half attracting a developer from another country;
  3. Provide fine-scaled task granularity, making it easier for people to contribute;
  4. And often attracted financial backing.
There are two approaches to attracting co-contributors to complex systems:
  1. Design modular systems, with fine-scaled task granularity, minimal ramp-up effort, and attract many contributors.
  2. Cultivate and retain core contributors who contribute across multiple years of involvement.
There is an inverse relationship between episodic and core contributors. Making episodic contributions trivial creates work for the core team, and vise-versa. Key to success is sustaining a core team focused on attracting and simplifying episodic contributions.
Recommendation 6: Invest in the communities of the projects you depend upon. Ensure there is funding to maintain a core team. Reduce barriers to entry in order to attract a wide contributor base. Develop indicators for reporting on the success of these investment strategies.

Modularity and standards

A key strategy for managing complexity is to divide large systems into modular subsystems. It means you can improve one module, without impacting the rest of your system. This helps with maintenance, innovation, and keeping up with latest technologies.
Recommendation 7: Embrace modular architectures, backed by open standards.
Modular systems include the following advantages:
  • Enable interoperability;
  • Facilitate collaboration;
  • Reduce system complexity;
  • Mitigate risks of obsolescence and vendor lock-in;
  • Facilitate sustained innovation.

Destabilising effects of episodic spending

Open projects are vulnerable to the destabilising effects of episodic spending.

Organisations are often willing to pay a once-off fee to add extra features to a project, but are reluctant to pay for core project maintenance. Such investment results in high ramp-up costs as developers come on board, and then a loss of expertise when sponsorship ends. Technical debt is created for the new software without resources to maintain it.

Governments are prime culprits of episodic spending. Government budgets are managed around the financial year, with delayed budget approvals, resulting in discretionary spending centered around the last quarter of the year.

Proprietary business models are better structured to handle episodic funding. They can legally restrict software use unless a fee is paid, enabling spreading of development costs over time. Consequently, government’s propensity toward episodic spending inadvertently favours proprietary over open business models.
Recommendation 8: Consider strategies to flatten government’s spending cycles, especially for community based projects.

Fragmented spending

Government taxes are collected centrally then split between departments, then split between divisions, then split between teams, and so on, until a group is funded to address a requirement. This hierarchical breakdown of budgets is appropriate for funding physical tasks such as building roads or collecting garbage; however, for the implementation of generic software functionality, it is usually more efficient for agencies to pool resources and collaboratively work on a common code base.
Fragmented spending results in narrow, short term solutions instead of solving broad, holistic and long term problems.

Think agile instead of “big bang” purchasing

It’s tempting to address “fragmented spending” by aggregating budgets from multiple agencies into a central “whole of government” contract. From an accounting perspective, you’d think that the easiest way to acquire technology is by defining scope, acquiring budget, insource or outsource the work, and then manage the developers implementing the specification.

However due to the complexity of IT, developers and users will continuously provide ideas for improvement. Projects which adopt agile development methodologies, which continuously adjust direction to incorporate feedback, have a track record of producing better quality outcomes than traditional “waterfall” acquisition methodologies prevalent within government.  
Recommendation 9: Prioritise agile, iterative development methodologies over “big bang”, “whole of government” purchases.

Chasing funds instead of collaborators

Open source communities typically become sustainable and scale by attracting a growing pool of collaborators. Government projects typically become sustainable and gain prominence by attracting funding and “empire building”.  Collaborating and sharing credit with external organisations typically weakens the importance of the individuals and teams. We need to adjust recognition and incentives to reverse this.

Call to Action

We need to recognise that government agencies are consistently duplicating effort; that government approaches to collaboration have typically been sporadic and unsustainable; and that best practices in open communities exist but are not readily available to government decision-makers.
Recommendation 10: Arm decision makers with accessible, evidence based research into what works, so they can trust, select and defend collaborative strategies which are often counter-intuitive within traditional hierarchically managed organisations.
Research and guides should be developed collaboratively, between agencies, nations, organisations and citizens.

We need to be bold enough to challenge widely established practices; we need to be aware of established wisdom; we need to be opportunistic and pragmatic; and we need to have the insight to know when to choose one over the other.

Related Reading

  1. Shorter, Cameron (August 2017). Making GovHack (and Open Government) more impactful.
  2. Ward, Dan (October 2011), Lieutenant Colonel, US Air Force. Acquisition Lessons from a Galaxy Far, Far Away.
  3. United States Assistant Secretary of Defense (Networks & Information, Integration) / DoD Chief Information Officer and the Under Secretary of Defense for Acquisition, Technology, and Logistics (May 2011). Open Technology Development: Lessons Learned & Best Practices.
  4. U.S. Public Participation Playbook
  5. Australian Government Digital Transformation Agency. Digital Service Standard.
  6. Australian Government Digital Transformation Agency. Design Principles.
  7. Australian Government Prime Minister and Cabinet. Open Government National Action Plan 2016-18
  8. Waugh, Pia (January 2015). Collaborative innovation in the public service: Game of Thrones style.

Signed

If you are a technologist and agree with this vision, please add your technical credibility by signing. Add a comment below, or email <cameron . shorter AT g m a i l .c o M>. Diverse support will help sponsors wanting to back this vision.

Australia:
  1. Cameron Shorter, Technology Demystifier; spent over a decade consulting to government on implementing Gespatial Open Source Software, Open Standards and Open Data; ex board member of the Open Source Geospatial Foundation (OSGeo); mentor in OSGeo Incubation committee; co-author of OSGeo Incubation processes; co-founder of OSGeoLive Open Source project.
  2. Nicholas Gruen, Chair, Open Knowledge Foundation (Australia), CEO of Lateral Economics, Former Chair of the Australian Government 2.0 Taskforce (2009) and of Innovation Australia in 2013-14.
  3. Arjen Lentz, Exec. Director Open Query Pty Ltd; former Community Relations Manager, MySQL AB; co-founder, Open Source Industry Australia, Inc
  4. Lev Lafayette, President, Isocracy Network; former President, Linux Users of Victoria, 2011-2014
  5. Steven De Costa, Steering Group member, CKAN Association (Open Source Data Portal) & Executive Director of Link Digital
  6. Bruce Bannerman, Director, GeoInnovations Pty Ltd; ex IT Manager, Australian Federal Government; Charter Member Open Source Geospatial Foundation (OSGeo); Mentor in OSGeo incubation committee; Former voting member, Open Geospatial Consortium Technical Committee.
  7. Stuart Guthrie, Co-CEO, Polonious Pty Ltd, Former President Open Source Industry Australia, Open Source Software developer and business owner. Current business, based on Open Source Software with offices in Australia, the US and the UK. Verticals in Case Management, Industries: Banking, Insurance, Government, Universities and Schools.
  8. Luke Carbis, Director of Product & Innovation at XWP.
  9. Evan Leybourn, CEO, Business Agility Institute.
  10. John Bryant, Principal, Mammoth Geospatial & Co-Chair, Free and Open Source Software for Geospatial and State of the Map Oceania Conference, 2018.
  11. David Collins, Independent Developer, Trilobite Solutions
  12. Alex Leith, Principal Spatial Analyst, Auspatious and Co-Chair, Free and Open Source Software for Geospatial and State of the Map Oceania Conference, 2018
  13. Andrew Pam, President, Linux Users of Victoria 2014-present
  14. Tristan Gutsche, Innovation and Integration Architect.
Other nationalites:
  1. Brent Wood, Information Delivery Programme Leader, NIWA. Ex Council member, New Zealand Open Source Society (NZOSS), Charter Member Open Source Geospatial Foundation (OSGEO).
  2. Ivan Minčík, LINZ Spatial IT Solutions Architect. After many years of working for government in Slovakia and 2 yrs of work in New Zealand I am very happy to sign this document.
  3. Dirk Frigne, president Open Source Geospatial Foundation Europe (OSGeo Europe vzw), OSGeo Charter member, Former Vice president of  OSGeo, CEO Geosparc nv.
  4. Jo Cook, Astun Technology, UK, OSGeo advocate, founder and chairman of Open Source Geospatial Foundation (OSGeo) UK local chapter, vice chair FOSS4G 2013 international conference (Free and Open Source Software for Geospatial)
  5. Vasile Crăciunescu, researcher Romanian National Meteorological Administration, Open Source Geospatial Foundation board member.
  6. Suchith Anand, founder of Geo4All, the Open Source Geospatial Foundation's network of educational institutions.
  7. Patrick Hogan, NASA WorldWind Project Manager, NASA
  8. Charles Schweik, Professor, School of Public Policy, University of Massachusetts, Amherst
  9. Sascha Meinrath, founder of the Open Technology Institute in Washington DC; Director at X-Lab; Palmer Chair in Telecommunications, Penn State University. 
  10. Aaron Rodericks, Lead, Open Innovation, Open Government, Chief Information Officer Branch, Treasury Board of Canada Secretariat, Government of Canada

See Also



Text in this document is licensed under the Creative Commons Attribution 4.0 Licence.