Tackling the Open Source dilemma

Here is the dilemma that you and your boss are faced with when considering Open Source:

Looked at through the lens of traditional management, Open Source collaboration is time consuming, imprecise, unreliable, hard to manage, rarely addresses short term objectives, and is hard to quantify in a business case. And yet, in a digital economy, collaborative communities regularly out-innovate and out-compete closed or centrally controlled initiatives.

So how do we justify following a more effective, sustainable, open and equitable strategy?



This is what we will be covering today:

• The digital economy,
• Complexity,
• Trust,
• Innovation and Obsolescence,
• and what leads to Success or Failure.

The first thing to recognise is that the Digital Economy has fundamentally changed the rules of business. Ignore this at your own peril.
Zero Duplication Costs and the Connectivity of the Internet has led to Wicked Complexity, Rapid Innovation, and on the flip side, Rapid Obsolescence.

Let’s start by talking about Complexity.
Software systems have become huge, interdependent and complex.
It is no longer possible for one person to understand all of a system’s intricacies.
So decision makers need to assume, deduce and trust information provided by others.
It means that sourcing trustworthy advice has become a key criteria for success in the digital economy.
So how do we assess trustworthiness?

It turns out we all use a variant of this trustworthiness equation.

• We trust people who are credible and who have have track record of providing reliable advice in the past.
• We trust people who are open and transparent.
• We trust ourselves, our family, our friends, because they look out for us, and we look out for them.
• We are suspicious of people who stand to gain from advice they give us.

We also trust processes.

• We trust that the democratic process leads to fair governance and management of resources.
• We trust that the scientific method leads to reliable research that we should act upon.
• We trust that the “survival of the fittest” competition of market economies leads to better products.

But we also know that all processes can be gamed.
And the more complex a system, the easier it is to bamboozle people and game the system.

Part of the reason Open Source has been so successful is that it’s characteristics lead to trustworthiness.
These characteristics include:

• Freedom,
• Altruism,
• Openness,
• Meritocracy,
• and Do-ocracy.

Let’s break these down one by one.

Open source, by definition, provides the receivers of the software with the four freedoms:

1. Freedom to use the software unencumbered; 
2. Freedom to study the source code and find out how it works; 
3. Freedom to modify, retask, and improve the code;
4. Freedom to copy and share with others.

Providing such a valuable gift, which provides significantly more value to the receiver than to the giver, increases the trustworthiness of the giver.

Additionally, openness and transparency is almost universally applied to all Open Source development practices and communication.

• Conversations are public; Everyone has the opportunity to join and contribute; 
• Decisions are made openly; 
• Issues and limitations are published and shared.

Being transparent and open to public critique reduces the potential for hidden agendas and creates trustworthiness.

In a meritocracy, the best ideas win, no matter who suggests them. It is the sign of an egalitarian community rather than a hierarchical or dysfunctional one.


With a do-ocracy the person motivated to do the work decides what gets done. In complex systems, the person closest to the problem will usually be best qualified to make the technical decisions.



A key strategy for managing complexity is to divide large systems into modular subsystems.
Using modular architectures, connected by open standards:

• Reduces system complexity,
• Enables interoperability,
• Which reduces technical risk,
• And facilitates sustained innovation.

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.

Collaboration is a key focus of both Open Source and Open Standards narratives. Hence, successful Open Source applications usually provide exemplary support for standards.

By comparison, from the perspective of dominant proprietary companies, it makes business sense to apply vendor lock-in tactics, making cross-vendor integration difficult. Adoption of Open Standards threatens vendor lock-in tactics, and consequently dominant vendors are often reluctant and half-hearted in their support of Open Standards.

In the digital economy there are two dominant business models which work well.
Either:

• You solve a generic problem by supplying an awesome "category killer" application which you distribute to the world; 
• Or you provide personalised, specialised or localised services, typically using category killer applications.

There is a natural symbiotic relationship between the two.
If you are solving a generic problem, by yourself, you will be out-innovated!
There are simply more developers in the rest of the world than you can ever muster within your team.

Because software is so time consuming to create and so easy to copy, it is excessively prone to monopolies.
This holds true for both proprietary and open source products. A product that becomes a little better than its competitors will attracts users, developers and sponsors, which in turn allows that product to grow and improve quickly, allowing it to attract more users.
This highly sensitive, positive feedback leads to successful software projects becoming “category killers”.

This means that most of the software you own will be out-innovated within a year or two.

Your software is not an asset, it is a liability needing to be updated, maintained, and integrated with other systems. It is technical debt, and you should try to own as little of it as possible.

The question is: should you select Proprietary or Open Source as the alternative?

Openness democratises wealth and power, which is a good thing for all of us, even those with wealth and power.

Open Source and Proprietary business models differ in how their realised value is shared.

Open source licenses are structured such that multiple companies can use and support the same open source product, so the market self corrects any tendencies toward price-fixing.

Effectively, Open Licenses democratise information.

It enables everyone to share in the value created by technology.

As software markets mature, and components become generic commodity items, the collaborative practices of Open Source moves to becoming the most effective means for creating and managing functionality.

Collaboration trumps Competition for commodity items!

By comparison, the ruthless competition between proprietary companies results in “winner takes all” scenarios. Many of the richest people in the world are self made software entrepreneurs.
Jeff Bezos who started Amazon has recently been ranked as the richest man in the world, stealing the spot from Bill Gates who started Microsoft. Mark Zuckerberg who started Facebook comes in at number 5. Jack Dangermond from ESRI is down at #603, with a mere $3.2 billion dollars to his name.

Lets explain this another way, following the money trail. Proprietary business model favours multi-nationals who establish themselves in big markets such as in the US or Europe.
From our Australian software spend, a small commission is provided to the local sales guy and systems integrator, and the rest is funnelled into the multinational who often farms development into cheap development centres.


Open Source on the other hand favours local business. The software is free, so the majority of money spent is on support and integration type services, which is typically applied locally, keeping money and expertise local.



Let’s look into the characteristics which make projects successful or not.

Open Source projects are highly susceptible to being Loved to Death. This happens when a project attracts an engaging user base without attracting matching contributions. Volunteers become overwhelmed leaving insufficient capacity to cover essential business-as-usual tasks.

Don’t overload the community you depend upon. It is both bad karma and bad business.

Successful projects have worked out how to either:

• Politely say NO to “gifts” of unsupported extra code and excessive requests for help;
• Or how to help uses become contributors, either in kind, or financially.

If your organisation isn’t ready to act as a good community citizen, actively caring about the community’s long term sustainability, then you will probably have a disappointing Open Source experience. You will make self-centred, short term decisions, and you won’t get the support you need when you most need it. You will likely be better off with proprietary software. (And the community would be better off without you.)

The success criteria for Open Source projects was researched by Professor Charlie Schweik who studied thousands of projects. As you can see from this graph, most projects are abandoned. Of the remainder, most projects don’t attract more than one or two staff, and very few attract a large community.

Viewed another way, you can see that:

• 4/5 projects are abandoned.
• 1 in 7 remain with just 1 or 2 developers.
• Only 1 in 100 manage to attract 10 core contributors.

(Source data)

On this graph we’ve drawn in the success rate for projects, and you can see that as you attract developers, your chance of long term success increases dramatically.

This is showing ruthless Darwinian evolution at work. Only projects of exceptional quality attract sustained growth and large communities. They fit in the “magic unicorn” category.

So how do you find these magic unicorn projects?

Charlie’s team distilled further insights from their research. They found that successful projects typically possess:

• A clearly defined vision;
• Clear utility;
• And leaders who lead by doing.

Then projects which manage to attract a medium to large team tend to:

• Provide fine scaled task granularity, making it easier for people to contribute;
• And often have attracted financial backing.

To get insights into project health, you can look at Open Hub metrics.  This slide is from the OSGeo-Live project and shows the status of leading Desktop GIS applications.

And for QGIS you can see that it has a very healthy community with over 100 active contributors. 

Another strong indicator of a project’s success is whether it has completed an Open Source Foundation’s incubation process.

The Open Source Geospatial Foundation’s incubation process covers:

• Quality
• Openness
• Community Health
• Maturity
• Sustainability

Bringing this all together into a concise elevator pitch for your boss:

• The Digital Economy leads to High Complexity, Rapid Innovation and Rapid Obsolescence. Get with the program, or become obsolete.
• Increased complexity requires us to trust more. So increase the value you place on trustworthiness, openness and transparency. 
• Software is technical debt. It needs significant maintenance to remain current. Own as little of it as possible.
• Collaboration and openness fast tracks innovation.
• For the long term play, Collaboration trumps Competition. If you are solving a generic problem, by yourself, you will be out innovated! Value, recognise, select and apply collaborative practices.
• Don’t be naive, most Open Source projects fail. Learn how to pick winners.
• Openness and Collaboration leads to the democratisation of wealth and power. Learn how to be part of the community - it makes good business sense.

• Slide deck is available online.
• An earlier version of these slides was presented at QGIS Conference in Sydney, Australia, November 2017. It was restructured for print and published as an article in the August 2018 edition of Position Magazine.
• The text behind these slides, by Cameron Shorter, is licensed under a Creative Commons Attribution 4.0 International License. 
• If this presentation was of interest to you, then please let me know (use comments below or email address on the slide above). I enjoy hearing from people who share similar interests, or are facing similar challenges, and ideas people have on related topics. 

Related presentations:

• The elusive Open business
• Memoirs of a Cat Herder - Coordinating OSGeo-Live volunteers

New gig at Learnosity

Testing out the Learnosity Pool Table

I'm excited to have started a new project in the Information Experience team at Learnosity, for so many reasons.

Good Karma Industry

Learnosity are building the assessment widgets which enable online learning, the scaling of training, and by extension, the democratisation of education. For me, enabling the next generation ranks highly in the "good karma" stakes. It makes you feel like you are doing something valuable for the world every time you head to work.

Treated Like Family

On my first day at work, I was handed my Macbook Pro with the advice: "Do what you like with this. Just don't do anything that your mother wouldn't be proud of."
No lists of "do’s" and "don'ts", no documents to sign, just the assumption that people treated like adults behave like adults. This was my first taste of a culture of mutual respect which appears to have been wired into Learnosity's DNA.

Everyone is Responsible for Innovation

Everyone is encouraged to share their ideas, recommendations, and provide constructive criticisms. If an idea holds merit, it is implemented, no matter who suggested it.
And in an industry of rapid change, a key criteria for sustained success is a company's ability to empower each and every employee to be creative and innovative. Learnosity has embraced this ethos. Within the first few weeks of onboarding, my opinion was being asked across a wide range of topics. And that wasn't because I was someone special. It is just what is being done in an office full of smart people solving hard technical problems.

Smart Business Model

In the digital economy there are two dominant business models which work well. Either you solve a generic problem by supplying an awesome "category killer" application which you sell to the world; or you provide personalised services for local organisations or specialised use cases. Learnosity fits into the first category, and over the last ten years have established itself as the "category killer" of assessment software widgets. The bonus from an employee's point of view is that you will make a difference to the millions of people who will end up using your contributions.
Further, the supportive culture and mutual respect within the office extends to Learnosity's customer base too, as evidenced by the high customer retention rate. And that is good for employee morale.

Buzzword Compliant

And then there are all the other buzzword compliant employee perks. There are bean bags, standing desks, free fruit bowl, a pool table, a retro Space Invaders machine, a beer keg (we have Irish founders), a "happiness" allowance, free yoga (admittedly provided by our building providers) and more. People work hard, play hard, and support each other. It is a nice and welcoming place to be.

Will I Make a Difference?

I sure hope so. Two of us have been brought in to help the Information Experience team take Learnosity communications from good to awesome. I'm looking forward to the challenge.

A variant of this post was published on Learnosity's blog.

Comprehensive research into Open Source success factors

An insightful, multi-year study of the Open Source Software Commons, led by Professor Charlie Schweik from the University of Massachusetts, analysed more than 170,000 projects, to help explain what leads some open source software projects to ongoing collaborative success and others to early abandonment.

During the project initiation stage (before first release):

• Key success factors were:
• Leadership by doing (working more hours).
• Clear vision.
• Well-articulated goals.
• Minor correlations with success were:
• Project marketing.
• Knowledge continuity: Someone on the project since its early days.
• Specific and general reciprocity.

During the project growth stage (after first release):

• Key success factors were:
• Utility as represented by downloads.
• Slightly larger development teams and attracting outside communities, although development team still can be small (2 – 3 people).
• Clear project vision and goals established and articulated.
• Leadership by doing.
• Open Source Software experience.
• Marketing of the project.
• Minor correlations with success were:


• Task granularity: Projects have small tasks ready for people who only can contribute small bits of time.
• Financial backing.
• A diversity of motivations from within the team.
• More formalized institutions exist in a relatively small number of cases, but these tend to fall in the successful growth class.

Charlie has kindly shared raw data from the study, which I've extracted out into graphs:

Success rate of Open Source Projects (source data)

As you can see, most projects are abandoned. Of those that are successful, the vast majority of them are retain a small, sustained team. However, attracting external developers greatly increases your chance of long term success. (A project which attracts 10 or more developers is a 1 in 100 project).

See also

• Catching the elusive Episodic Volunteer.

The Yin & Yang of OSGeo Leadership

The 2017 OSGeo Board elections are about to start. Some of us who have been involved with OSGeo over the years have collated thoughts about the effectiveness of different strategies. Hopefully these thoughts will be useful for future boards, and charter members who are about to select board members.

The Yin and Yang of OSGeo

As with life, there are a number of Yin vs Yang questions we are continually trying to balance. Discussions around acting as a high or low capital organisation; organising top down vs bottom up; populating a board with old wisdom or fresh blood; personal vs altruistic motivation; protecting privacy vs public transparency. Let’s discuss some of them here.

Time vs Money

OSGeo is an Open Source organisation using a primary currency of volunteer time. We mostly self-manage our time via principles of Do-ocracy and Merit-ocracy. This is bottom up.

However, OSGeo also manages some money. Our board divvies up a budget which is allocated down to committees and projects. This is top-down command-and-control management. This cross-over between volunteer and market economics is a constant point of tension. (For more on the cross-over of economies, see Paul Ramsey’s FOSS4G 2017 Keynote, http://blog.cleverelephant.ca/2017/08/foss4g-keynote.html)

High or low capital organisation?

Our 2013 OSGeo Board tackled this question:

https://wiki.osgeo.org/wiki/OSGeo_Board_:_Board_Priorities_2013#OSGeo_as_a_low_capital.2C_volunteer_focused_organisation

Should OSGeo act as a high capital or low capital organisation? I.e., should OSGeo dedicate energy to collecting sponsorship and then passing out these funds to worthy OSGeo causes.

While initially it seems attractive to have OSGeo woo sponsors, because we would all love to have more money to throw at worthy OSGeo goals, the reality is that chasing money is hard work. And someone who can chase OSGeo sponsorship is likely conflicted with chasing sponsorship for their particular workplace. So in practice, to be effective in chasing sponsorship, OSGeo will probably need to hire someone specifically for the role. OSGeo would then need to raise at least enough to cover wages, and then quite a bit more if the sponsorship path is to create extra value.

This high capital path is how the Apache foundation is set up, and how LocationTech propose to organise themselves. It is the path that OSGeo started following when founded under the umbrella of Autodesk.

However, as OSGeo has grown, OSGeo has slowly evolved toward a low capital volunteer focused organisation. Our overheads are very low, which means we waste very little of our volunteer labour and capital on the time consuming task of chasing and managing money. Consequently, any money we do receive (from conference windfalls or sponsorship) goes a long way - as it doesn't get eaten up by high overheads.

Size and Titles

Within small communities influence is based around meritocracy and do-ocracy. Good ideas bubble to the top and those who do the work decide what work gets done. Leaders who try to pull rank in order to gain influence quickly lose volunteers. Within these small communities, a person’s title holds little tradable value.

However, our OSGeo community has grown very large, upward of tens of thousands of people. At this size, we often can’t use our personal relationships to assess reputation and trust. Instead we need to rely on other cues, such as titles and allocated positions of power.

Consider also that OSGeo projects have become widely adopted. As such, knowledge and influence within an OSGeo community has become a valuable commodity. It helps land a job; secure a speaking slot at a conference; or get an academic paper published.

This introduces a commercial dynamic into our volunteer power structures:

• A title is sometimes awarded to a dedicated volunteer, hoping that it can be traded for value within the commercial economy. (In practice, deriving value from a title is much harder than it sounds).
• There are both altruistic and personal reasons for someone to obtain a title. A title can be used to improve the effectiveness of the volunteer; or to improve the volunteers' financial opportunities.
• This can prompt questions of a volunteer’s motivations.

In response to this, over the years we have seen a gradual change to position of roles within the OSGeo community.

Top-down vs bottom-up

OSGeo board candidates have been asked for their “vision”, and “what they would like to change or introduce”. https://wiki.osgeo.org/wiki/Election_2017_Candidate_Manifestos  These are valid questions if OSGeo were run as a command-and-control top-down hierarchy; if board made decisions were delegated to OSGeo committees to implement. But OSGeo is bottom-up.

Boards which attempt to centralise control and delegate tasks cause resentment and disengagement amongst volunteers. Likewise, communities who try to delegate tasks to their leaders merely burn out their leaders. Both are ignoring the principles of Do-ocracy and Merit-ocracy. So ironically, boards which do less are often helping more.

Darwinian evolution means that only awesome ideas and inspiring leaders attract volunteer attention - and that is a good thing.

Recognising ineffective control attempts

How do you recognise ineffective command-and-control techniques within a volunteer community? Look for statements such as:

• “The XXX committee needs to do YYY…”
• “Why isn’t anyone helping us do …?”
• “The XXX community hasn’t completed YYY requirements - we need to tell them to implement ZZZ”

If all the ideas from an organisation come from management, then management isn’t listening to their team.

Power to the people

In most cases the board should keep out of the way of OSGeo communities. Only in exceptional circumstances should a board override volunteer initiatives.

Decisions and power within OSGeo should be moved back into OSGeo committees, chapters, and projects. This empowers our community, and motivates volunteers wishing to scratch an itch.

We do want our board members to be enlightened, motivated, and engaged within OSGeo. This active engagement should be done within OSGeo communities: partaking, facilitating, or mentoring as required. A recent example of this was Jody Garnett’s active involvement with OSGeo rebranding - where he worked with others within the OSGeo marketing committee.

Democratising key decisions

While we have a charter membership of nearly 400 who are tasked with ‘protecting’ the principles of the foundation and voting for new charter members and the board. Beyond this, charter members have had little way of engaging with the board to influence the direction of OSGeo.

How can we balance the signal-to-noise ratio such that we can achieve effective membership engagement with the board without overwhelming ourselves with chatter? Currently we have no formal or prescribed processes for such consultation.

Reimbursement

OSGeo Board members are not paid for their services. However, they are regularly invited to partake in activities such as presenting at conferences or participating in meetings with other organisations. These are typically beneficial to both OSGeo and the leader’s reputation or personal interest. To avoid OSGeo Board membership being seen as a “Honey Pot”, and for the Board to maintain trust and integrity, OSGeo board members should refuse payment from OSGeo for partaking in such activities. (There is nothing wrong with accepting payment from another organisation, such as the conference organisers.)

In response to the question of conferences, OSGeo has previously created OSGeo Advocates - an extensive list of local volunteers from around the world willing to talk about OSGeo. https://wiki.osgeo.org/wiki/OSGeo_Advocate

Old vs new

Should we populate our board with old wisdom or encourage fresh blood and new ideas? We ideally want a bit of both, bring wisdom from the past, but also spreading the opportunity of leadership across our membership. We should avoid leadership becoming an exclusive “boys club” without active community involvement, and possibly should consider maximum terms for board members.

If our leadership follow a “hands off oversight role”, then past leaders can still play influential roles within OSGeo’s subcommittees.

Vision for OSGeo 2.0

Prior OSGeo thought leaders have suggested it’s time to grow from OSGeo 1.0 to OSGeo 2.0; time to update our vision and mission.  A few of those ideas have fed into OSGeo’s website revamp currently underway. This has been a good start, but there is still room to acknowledge that much has changed since OSGeo was born a decade ago, and there are plenty of opportunities to positively redefine ourselves.

A test of OSGeo’s effectiveness is to see how well community ideas are embraced and taken through to implementation. This is a challenge that I hope will attract new energy and new ideas from a new OSGeo generation.

Here are a few well considered ideas that have been presented to date that we can start from:

• Michael Gerlek July 2015, “We won. It's time for OSGeo 2.0”, https://lists.osgeo.org/pipermail/discuss/2015-July/014521.html
• Darrell Fuhriman: September 2015, “OSGeo is becoming irrelevant. Here's why. Let's fix it.” https://lists.osgeo.org/pipermail/discuss/2015-September/032616.html
• Marc Vloemans, March 2014, OSGeo Marketing Analysis, https://wiki.osgeo.org/wiki/Talk:Marketing_Committee
• OSGeo Board of 2013, “OSGeo Board Priorities”, http://cameronshorter.blogspot.com.au/2013/03/osgeo-board-priorities.html
• (There are a few more which I haven’t located - please do suggest them).

Recommendations

So where does this leave us.

• Let’s recognise that OSGeo is an Open Source community, and we organise ourselves best with bottom-up Meritocracy and Do-ocracy.
• Wherever possible, decisions should be made at the committee, chapter or project level, with the board merely providing hands-off oversight. This empowers and enables our sub-communities.
• Let’s identify strategic topics where the OSGeo board would benefit from consultation with charter membership and work out how this could be accomplished efficiently and effectively.
• Let’s embrace and encourage new blood into our leadership ranks, while retaining access to our wise old white beards.  
• The one top-down task for the board is based around allocation of OSGeo’s (minimal) budget.

Making GovHack (and Open Government) more impactful

I've finally attended the GovHack weekend. As a dad, weekends used to be for taking kids to birthday parties and soccer games. But my boys have grown up, giving me the chance to see how GovHack compares to the Open Source communities I've been involved with for decades. I wanted to see what each can learn from the other and signed up as a coach.
GovHack is an annual event where volunteers band together for 48 hours to write applications with Open Government data. Participants compete for prizes for the most innovative and useful applications. It has grown every year since it started in 2009, attracting thousands of volunteers, running in 36 locations across Australia and New Zealand, and attracted numerous sponsors and an excessive list of open government datasets. Credit must go to the organisers for creating such a sustainable winning formula. But lets ask some tough questions and hopefully help GovHack become more impactful in future?

What is the point of GovHack?

What is the point of GovHack? It wasn't obvious from looking at the main website, but I found an answer buried in the GovHack 2016 Year in Review:

In his opening address, Craig Laundy, the Assistant Minister for Industry, Innovation and Science highlighted that open data was one of the keys to the Australian Government’s National Innovation and Science Agenda. He read a letter from Prime Minister Malcolm Turnbull which paid the following tribute to Govhack:
“Data without ingenuity is like a lamp without power – only when the two are connected do opportunities to innovate become clear. This is why GovHack is so important.”

Recommendation 1: We should be clear about the purpose and value of GovHack. We should prominently promote messages like "GovHack aims to contribute to the government's Innovation Agenda by encouraging and facilitating ingenuity with government's open data."

Is GovHack enabling Innovation?

So how successful has GovHack been at enabling innovation? It's hard to say really. The 2016 Year in Review provides plenty of details about numbers of participants, datasets used, awards, VIP presenters, red carpet events, but there is barely a mention of how successful GovHack has been at enabling innovation. The best I could find was a passing mention of an "IP Nova App" which started in GovHack 2015. I’ve since been told about a couple of others. But the point is that we are measuring how busy everyone is, and how much buzz is being created, but completely failing to report the impact on innovation.

Recommendation 2: Let's measure and report on the realised innovation resulting from GovHack. Let's then assess results and work out ways to improve GovHack's impact on innovation.

Maturing ideas is hard work

Why is it hard to find reports of GovHack ideas progressing into sustained initiatives? I can't say for sure, but suspect very few GovHack ideas actually grow into something. The simple truth is that good software takes substantial effort to design, write, test, deploy and maintain. While a 48 hour GovHack is useful for brainstorming ideas, it stills requires significant follow up if it is to mature into something useful. And here we notice the difference between Open Source Code Sprints and GovHack. On completion of Code Sprints, there are established and experienced communities committed to adopting and advancing worthy ideas. Who in the GovHack community is offering to help take good ideas through to maturity? I don't see such support mentioned in GovHack web pages.

Recommendation 3: GovHack sponsors' should aim to realise true value by helping to mature innovative ideas into reality. 

The majority of people I saw in the Sydney GovHack appeared to be University students or recent graduates. For these young people, GovHack provides a great practical learning experience, some mentoring, and an opportunity to network. However I couldn't help feeling there was an level of exploitation of these young volunteers. Government agencies are gaining significant value from volunteers testing their datasets, something that would cost orders of magnitude more if implemented internally. Morally, I feel these agencies should give more than a free meal and a chance to share in a prize. A good symbiotic relationship would hopefully consider providing more value for our young community.

Recommendation 4: Sponsors should consider formally setting up cadetships or project development opportunities as awards.

How good is the data?

Integrating data into innovative web or mobile applications typically should follow standard design patterns, with data published through a web service, then processed, integrated, and presented in innovative ways. Ideally government agencies should make data really easy to use, setting up data web services and providing clear documentation and examples. Instead teams were spending much of their GovHack time setting up the infrastructure to publish this data rather than spending their time being innovative.
It is worth being reminded of one of The Australian Digital Transformation Agency Design Principles:

Principle 4. Do the hard work to make it simple.
Making something look simple is easy. Making something simple to use is much harder - especially when the underlying systems are complex - but that’s what we should be doing. Don’t take “It’s always been that way” for an answer. It’s usually more and harder work to make things simple, but it’s the right thing to do.

Recommendation 5: Government should define a best practices guide for publishing data services, and then follow this guide.

How does government know if they are doing a good job? Ruthless survival of the fittest principles apply to Open Source and market economies. People don't buy substandard products. Only the best Open Source projects attract communities. Again, refer to the DTA design principles:

Principle 5. Iterate. Then iterate again.The best way to build good services is to start small and iterate wildly. Release minimum viable products early and test them with actual users; move from Alpha to Beta to Live adding features, deleting things that don’t work and making refinements based on feedback. Iteration reduces risk: it makes big failures unlikely and turns small failures into lessons. If a prototype isn’t working, don’t be afraid to scrap it and start again.

Recommendation 6: Agencies should measure the usability and usefulness of their datasets, assess and adjust accordingly. GovHack provides an opportunity to measure these metrics.

How good are we are implementing Open Government?

And so I come to my most pointed point, which was recorded as a video for my GovHack contribution:

Australia has embraced great policies around Open Government. These describe how openness and collaboration enable innovation. However, the practical implementation of these open principles have proven elusively difficult, with reported success stories coming from a few charismatic champions rather than being systemic across all government.
Why is that? Well, it’s complicated. There is a wealth of established wisdom, spread across the domains of Open Source Software, Open Standards, Open Data, Open Government, and more. However, we still lack clear and definitive guides which draws all this wisdom together into practical playbooks which can be easily applied by government agencies. Instead, current government practices and guidelines regularly hinder collaboration. Let’s fix that.

Recommendation 7: Let’s build an Open Government Playbook.

Let’s document the subtle magic which makes open and collaborative communities work.

This Playbook should cover technology, processes, governance, leadership, business paradigms, and ethics. It should be written in simple language, designed to support decision makers, architects, implementers and citizens to understand open principles.

Could GovHack be more impactful?

Acknowledging that GovHack runs impressively efficiently and has attracted a huge ground swell of interest and momentum, could we make it more impactful? I think we can. We should remind ourselves of the Open Government and GovHack goal of promoting innovation. We should measure innovation enabled and adjust accordingly. Adjustments will likely include aligning more closely with Open Source development practices.

OSGeo-Live 11.0 Reboot

Version 11.0 of the OSGeo-Live GIS software collection has been released, ready for FOSS4G which is the International Conference for Free and Open Source Software for Geospatial - 2017 in Boston, USA.

Download

Download the OSGeo-Live 11.0 image at http://live.osgeo.org/en/download.html

Release Highlights

This release has been a major reboot, with a refocus on leading applications and emphasis on quality over quantity. Less mature parts of the projects have been dropped with a targeted focus placed on upgrading and improving documentation.

Dropped

• Windows-only applications/installers
• Overviews of OGC Standards
• Some applications that did not meet our review criteria
• We now only support a 64 bit distribution (32 bit is built but not officially supported)

Added

• Support for isohybrid ISO images with UEFI

Known Issues and Errata

Post release issues are listed here: https://wiki.osgeo.org/wiki/Live_GIS_Disc/Errata/11.0

About OSGeo-Live

OSGeo-Live is a Lubuntu based distribution of Geospatial Open Source Software, available via a Live DVD, Virtual Machine and USB. OSGeo-Live is pre-installed with robust open source geospatial software, which can be trialled without installing anything.
It includes:

• Close to 50 quality geospatial Open Source applications installed and pre-configured
• Free world maps and sample datasets
• Project Overview and step-by-step Quickstart for each application
• Lightning presentation of all applications, along with speaker's script
• Translations to multiple languages

Homepage: http://live.osgeo.org
Download details: http://live.osgeo.org/en/download.html
Credits
Over 180 people have directly helped with OSGeo-Live packaging, documenting and translating, and thousands have been involved in building the packaged software.
Developers, packagers, documenters and translators include:

Activity Workshop, Alan Boudreault, Alex Mandel, Alexandre Dube, Amy Gao, Andrea Antonello, Angelos Tzotsos, Anton Patrushev, Antonio Santiago, Argyros Argyridis, Ariel Núñez, Astrid Emde, Balasubramaniam Natarajan, Barry Rowlingson, Ben Caradoc-Davies, Benjamin Pross, Brian Hamlin, Bruno Binet, Bu Kun, Cameron Shorter, Dane Springmeyer, Daniel Kastl, Danilo Bretschneider, Dimitar Misev, Edgar Soldin, Eike Hinderk Jürrens, Eric Lemoine, Erika Pillu, Etienne Dube, Fabian Schindler, Fran Boon, Frank Gasdorf, Frank Warmerdam, François Prunayre, Friedjoff Trautwein, Gabriele Prestifilippo, Gavin Treadgold, Gerald Fenoy, Guillaume Pasero, Guy Griffiths, Hamish Bowman, Haruyuki Seki, Henry Addo, Hernan Olivera, Howard Butler, Ian Edwards, Ian Turton, Jackie Ng, Jan Drewnak, Jane Lewis, Javier Rodrigo, Jim Klassen, Jinsongdi Yu, Alan Beccati, Jody Garnett, Johan Van de Wauw, John Bryant, Jorge Sanz, José Vicente Higón, Judit Mays, Klokan Petr Pridal, Kristof Lange, Lance McKee, Larry Shaffer, Luca Delucchi, Mage Whopper, Marc-André Barbeau, Manuel Grizonnet, Margherita Di Leo, Mario Carrera, Mark Leslie, Markus Neteler, Massimo Di Stefano, Micha Silver, Michael Owonibi, Michaël Michaud, Mike Adair, Milan P. Antonovic, Nathaniel V. Kelso, Ned Horning, Nicolas Roelandt, Oliver Tonnhofer, Patric Hafner, Paul Meems, Pirmin Kalberer, Regina Obe, Ricardo Pinho, Roald de Wit, Roberto Antolin, Robin Lovelace, Ruth Schoenbuchner, Scott Penrose, Sergio Baños, Sergey Popov, Simon Cropper, Simon Pigot, Stefan A. Tzeggai, Stefan Hansen, Stefan Steiniger, Stephan Meissl, Steve Lime, Takayuki Nuimura, Thierry Badard, Thomas Gratier, Tom Kralidis, Trevor Wekel, Matthias Streulens, Victor Poughon, Zoltan Siki, Òscar Fonts, Raf Roset, Anna Muñoz, Cristhian Pin, Marc Torres, Assumpció Termens, Estela Llorente, Roger Veciana, Dominik Helle, Lars Lingner, Otto Dassau, Thomas Baschetti, Christos Iossifidis, Aikaterini Kapsampeli, Maria Vakalopoulou, Agustín Dí­ez, David Mateos, Javier Sánchez, Jesús Gómez, Jorge Arévalo, José Antonio Canalejo, Mauricio Miranda, Mauricio Pazos, Pedro-Juan Ferrer, Roberto Antolí­n, Samuel Mesa, Valenty González, Lucía Sanjaime, Andrea Yanza, Diego González, Nacho Varela, Mario Andino, Virginia Vergara, Christophe Tufféry, Etienne Delay, Hungary, M Iqnaul Haq Siregar, Andry Rustanto, Alessandro Furieri, Antonio Falciano, Diego Migliavacca, Elena Mezzini, Giuseppe Calamita, Marco Puppin, Marco Curreli, Matteo De Stefano, Pasquale Di Donato, Roberta Fagandini, Nobusuke Iwasaki, Toshikazu Seto, Yoichi Kayama, Hirofumi Hayashi, Ko Nagase, Hyeyeong Choe, Milena Nowotarska, Damian Wojsław, Alexander Bruy, Alexander Muriy, Alexey Ardyakov, Andrey Syrokomskiy, Anton Novichikhin, Daria Svidzinska, Denis Rykov, Dmitry Baryshnikov, Evgeny Nikulin, Ilya Filippov, Grigory Rozhentsov, Maxim Dubinin, Nadiia Gorash, Pavel, Sergey Grachev, Vera, Alexander Kleshnin, kuzkok, Xianfeng Song, Jing Wang, Zhengfan Lin, Jakob Miksch

Sponsoring organisations

• OSGeo - the Open Source Geospatial Foundation provides development & hosting infrastructure for OSGeo-Live and many of the included applications.
• JIROTECH provides sustaining resources and staff toward management and packaging.
• Information Center for the Environment (ICE) at the University of California, Davis provides hardware resources and development support.
• Remote Sensing Laboratory at the National Technical University of Athens, provides hardware resources and development support.
• The Debian GIS and UbuntuGIS teams provide and quality-assure many of the core packages.
• Okeanos is kindly providing Virtual Machines for building the OSGeo-Live iso images.