Sunday 30 December 2018

Community Inside

Community inside
Parody of "intel inside®" logo,
a trademark of Intel Corporation.
Image SVG.
"Community inside" is the "intel inside®" of Open Source Software. It's an indicator of quality and long term sustainability.

Why? Because in the digital economy, collaboration out-competes competition!

So prioritise software developed by healthy communities. Look for diverse, supportive, meritocratic, productive, welcoming and inspiring teams. Then engage productively with them.

More ...

Saturday 15 December 2018

Catching the elusive Episodic Volunteer

Fairy catching kit
Understanding the science of volunteer contributions is key to the success of Open Source projects. A comprehensive study of episodic volunteering, which drew upon our OSGeoLive experiences, provides insightful advice for anyone wishing to build sustained and successful Open Source Software:

Contributor Motivation

Findings: Episodic volunteers with intrinsic motives are more likely to intend to remain, compared to episodic volunteers with extrinsic motives.

  1. Lower barriers to entry through:
    • Accepting contributions directly through GitHub,
    • Good documentation,
    • Task–finding dashboard,
    • Simple workspace(s).
  2. Offer guided introductory events to help newcomers get started and to introduce the social element.
  3. Provide opportunities for social interactions, such as:
    • Interactive sites, including localised options,
    • Hosting local meetups.

Social Norms

Findings: Although Open Source episodic volunteers were unlikely to see their participation as influenced by social norms, personal invitation was a common form of recruitment, especially among non-code contributors.

  1. Encourage existing volunteers to talk about their Open Source involvement by:
    • Highlighting the benefits of advocating broadly,
    • Providing digestible information for sharing.

Psychological Sense of Community

Findings: Psychological sense of community is more common among long-term participants;
A policy of inclusion was a commonly mentioned reason for feeling welcomed in the community.

  1. Use a code of conduct to express the community’s intentions, allowing potential episodic volunteers to determine their similarity to the community.
  2. Give potential episodic volunteers the opportunity to identify alignment with the community through awareness of non-coding activities:
    • Collaborate with organisations with a different focus but shared values,
    • Recognise all forms of contribution.
  3. Re-enforce the psychological sense of community by:
    • Hosting local events,
    • Issuing personal invitations to episodic volunteers.


Findings: Satisfaction was most commonly cited as a reason to remain;
Episodic volunteers derive satisfaction from knowing that their work is used, enjoying the work itself, and feeling appreciated.

  1. Encourage satisfaction by increasing feelings of appreciation, by recognising all contributors and their areas of expertise.
  2. Being aware of episodic volunteers’ areas of expertise and requesting their assistance, sparingly, can:
    • Make episodic volunteers feel appreciated,
    • Encourage episodic volunteers to return to the community.

Community Commitment

Findings: Episodic volunteers who talk about their involvement are more inclined to continue participating;
Long-term episodic volunteers often have community commitment;
Community commitment is less common among episodic volunteers with extrinsic motives.

  1. Encourage long-term episodic volunteers to talk about the community to strengthen their commitment to the community and:
    • To utilise Social Norms to recruit friends/family,
    • To recruit from similar organisations through Psychological Sense of Community.
  2. Consider time-based releases for large projects to allow episodic volunteers to plan their return.
  3. Use opt-in platforms to broadcast calls for participation for specific tasks to encourage episodic volunteers to return.

Episodic volunteering

Findings: Episodic volunteering is widespread in Open Source communities, but Open Source communities are often not strategically engaging with episodic volunteers;
Open Source episodic volunteers are often habitual volunteers in other communities.

  1. Evaluate volunteer assets, volunteer availability, and potential assignments to find opportunities for episodic volunteers.
Reference Source: Barcomb, Anne, "Uncovering the Periphery: A Qualitative Survey of Episodic Volunteering in Free/Libre and Open Source Software Communities", 2018. Anne Barcomb is affiliated with the Open Source Research Group at Friedrich Alexander-University Erlangen-Nurnberg, Germany, and Lero, The Irish Software Research Centre at the University of Limerick, Ireland.

See also

Sunday 9 December 2018

Open Government's back slapping report

The Australian Open Government Partnership (OGP) have given themselves a glowing report card. Yes, it is great that Australia is working through OGP goals, but I wish they'd acknowledge the difficulties in achieving the goals so that we can focus on real solutions. I'll pick on just one report item:

  • OGP Commitment 5.2: Enhance public participation in government decision making. 
  • OGP Assessed Progress: Substantial. 
  • My Assessment: Tick the box participation has been achieved, but effective public participation is hard and there is much more to be done
Along with a number of technologist and open source community members, we responded to the OGP's last call for comment with a detailed set of practical recommendations? We are yet to hear if our report was understood, or considered. To be fair, our recommendations are detailed, are contrary to current government practices, and would be difficult to investigate and address. But the potential to become as effective as open communities is huge and worth investigating.
So before claiming "substantial progress" in public participation, please assign someone with sufficient technical capability to understand our report, and sufficient mandate to initiate improvements.

Reiterating our prior recommendations:
  • 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.

Saturday 1 December 2018

OSGeoLive in 4 minutes

Here is our OSGeoLive lightning talk, stripped back to 4 minutes, and presented at the FOSS4G-Oceania conference. The OSGeoLive talk starts at 7mins 45secs.
The slide deck and notes are here.

Friday 12 October 2018

The Open Business - Business Case

Despite many attempts, large companies and governments’ rarely achieve the level of collaboration experienced by Open Source communities. Why?
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 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.
Backing successful collaboration within traditional business requires us to write compelling, counter-intuitive business cases which explain and justify the elusive practices of collaborative communities.
This presentation explains the subtle magic of open strategies in business terms, and will help you convince your boss to back them.

Presented at World Commons Week, November 2018. Youtube recording and slide deck are available online.

Fifty years ago Garrett Hardin described the tragedy of the commons,
where people acting in their own self-interest, inevitably will deplete or spoil a common resource, as each acts in their own self interest.
He argued that the tragedy can only be prevented by private property rights or government regulation.
And yet, within the last fifty years, we’ve discovered exemplar counter-examples where altruism trumps selfishness. Let’s look at the business case behind one of these examples - the Open Source movement.

Despite governments’ and businesses acknowledging the value of Open Source in policies and initiatives over the last decade. And despite numerous attempts. They rarely achieve the level of collaboration experienced by Open Source communities. Why?

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 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.
Backing successful collaboration within traditional business requires us to write compelling, counter-intuitive business cases which explain and justify the elusive practices of collaborative communities.
This presentation explains the subtle magic of open strategies in business terms, and will help you convince your boss to back them.
I’m going to focus on Open Source Software, but the principles translates across all types of Creative Commons - Open Data, Open Government, Open Standards, and other Open approaches.

This is what we will be covering today:
  • The digital economy,
  • Complexity,
  • Trust,
  • Motivations,
  • Innovation and Obsolescence.

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.
Solving problems requires the collective brain power of many people.

To understand this, we’ll introduce the Cynefin framework, developed by Dave Snowden when he worked for IBM Global Services. It describes how different decision methodologies should be applied at different levels of complexity.
The framework is broken into four decision-making domains.

The Obvious domain is the area of "known knowns".
The relationship between cause and effect is clear.
Establish the facts ("sense"), categorize, then respond, by following established rules and applying best practices.
This is the province of standard operating procedures and legal structures.
Beware of complacency, over-simplifying or creating volumes of processes and unwieldy red tape.

The Complicated domain is the "known unknowns".
The relationship between cause and effect can be deduced from analysis or expertise and there are a range of right answers.
Assess the facts, analyze, and apply the appropriate good operating practice.
This is the province of experts.
Be aware of the trustworthiness of advice, influence from vested interests, and balancing short versus long term goals.

The Complex domain is for the "unknown unknowns".
Cause and effect can only be deduced in retrospect, and there are no right answers.
Instructive patterns can emerge by conducting experiments that are safe to fail.
This is the provenance of hypotheses and the scientific method.

In the Chaotic domain, cause and effect are unclear, and events are too confusing to wait for a knowledge-based response.
Act to establish order; sense where stability lies; respond to turn the chaotic into one of the other domains.
This is the domain of firm leadership, tough decisions and action.

Open source collaboration has proven to be very effective within Complex and Complicated domains, which begs the question of “why”?
Why is an open approach so effective within complex domains, and conversely, why aren’t open approaches as dominant in Obvious and Chaotic domains?

Let’s start by looking at the characteristics of Open Source.

Firstly, most projects are abandoned, and of those that succeed, most only have a few developers, with the extra developers often coming from another country.

On this graph we’ve drawn in the success rate for the projects.
As you attract developers, your chance of long term success increases dramatically.
This is showing ruthless Darwinian evolution at work.

Effectively, Open Source is an environment where lots of competing ideas are tested.
Only projects of exceptional quality attract sustained growth and large communities.

And this is a key characteristic to notice. When you are giving away your software for free, success depends upon:
  • A compelling vision,
  • Clear utility,
  • And being so welcoming and caring that you attract and retain contributors.
The study also noticed that projects which grow:
  • Typically provide fine scaled task granularity, making it easier for people to contribute,
  • And often have attracted financial backing.
And here we start to uncover the magic of Open Source.
In the digital economy, there are more developers working on your problem, than you will ever have in your team. When projects can tap into this,
Collaboration out-competes competition!

Let’s look at one of the key factors in complicated systems - trust; and question what makes trustworthiness.

It turns out we all make use of a variant of this trustworthiness equation.
  • We trust people who are credible and have a 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.
  • And we are suspicious of people who stand to gain from advice they give us.

We also trust processes.
  • We trust that the scientific method leads to reliable research that we should act upon.
  • We trust that the competition of market economies leads to better products.
  • We trust that the democratic process leads to fair governance and management of resources.
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 include:
  • Freedom and Altruism,
  • Openness,
  • Bottom up decision making,
  • Do-ocracy,
  • Meritocracy,
  • And modularity.
Let’s look at these in more detail.

… starting with Freedom and Altruism.
Open source, by definition, is given away for free, with the freedom to use and extend it as you see fit.
Why are open source developers so altruistic?
It turns out that it is wrong to assume that we humans are only driven by self interest.
As noted by Dan Pink in his book Drive, after our basic needs are met, we are also motivated by …

Autonomy. The desire to be self directed.

Mastery, the urge to get better at stuff.

And Purpose,
The desire to do something with meaning and importance.
Such altruistically motivated people, who provide significantly more value to the receiver than to the giver, increases the trustworthiness of the giver.

Then there is Openness.
Openness and transparency is almost universally applied to all Open Source development and communication.
  • Conversations are public; Everyone has the opportunity to join and contribute;
  • Decisions are made openly;
  • And issues and limitations are published and shared.
Being transparent and open to public critique reduces the potential for hidden agendas and creates trustworthiness.

And within Open Source communities, decisions tend to be made bottom-up rather than top-down.
When you can trust the motivations of your community, you are empowered use of bottom up decision making.

This is important, because in a complex system, the person closest to the problem is usually the best qualified to make decisions.

It creates a culture of “do-ocracy”.
Within a do-ocracy the person motivated to do the work decides what gets done. Their commitment is a better indicator of true value than a person at the top saying “someone should fix this”.

This leads into Meritocracy.
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.

But we should be careful not to suggest that open practices easily solves all problems.
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. Volunteer become overwhelmed leaving insufficient capacity to cover essential business-as-usual tasks.
Don’t to 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.)

Using modular architectures, connected by open standards:
  • Reduces system complexity,
  • Enables interoperability,
  • Which reduces technical risk,
  • it enables collaboration,
  • 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.

Effectively, we are talking about monopolies.
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 is likely to 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 unless a product is part of your core business, you should try to own as little of it as possible.
The question is: should you select Proprietary or Open Source as the alternative?

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.
It enables everyone to share in the value created by technology.

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.
These are typically people and organisations who have mastered the Complex domain.

Let’s take a quick look into the indicators for successful open projects.

To get insights into project health, you can look at Open Hub metrics. In particular, look for signs of sustained collaboration and growth.

Another strong indicator of a project’s success is whether it has completed an Open Source Foundation’s incubation process.
I’ve been involved with the Open Source Geospatial Foundation’s incubation process where we look for indicators of:
  • Quality
  • Openness
  • Community Health
  • Maturity
  • And sustainability

Bringing this all together into a concise elevator pitch:
  • 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. 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.
  • For the long term play, Collaboration trumps Competition.
  • Truly care about your community, and they will care about you.
  • Learn how to describe the business case for good behaviour. It is counter-intuitive, but it is the foundation for long term successful business strategies.

© 2018 Cameron Shorter. The text behind these slides, is licensed under a Creative Commons Attribution 4.0 International License.

Friday 7 September 2018

Child friendly conferences

We have introduced a Child Friendly policy at the FOSS4G-Oceania conference as part of our "diversity" focus. We are quite proud of it, and think we have reached an effective balance between the competing priorities of:

  • High cost of dedicated childcare.
  • Variability and unpredictability of different aged children.
  • Retaining a professional conference environment.
  • Respecting needs of children, parents, and conference participants.
  • Making our conference accessible to a diverse audience, which includes those responsible for children.
Hopefully other conferences will draw inspiration from our work embrace something similar. This is what we have come up with:

Child Friendly Conference

A child-friendly FOSS4G SotM event

FOSS4G SotM Oceania is aiming to be a child-friendly conference. This means we encourage parents to bring their children (still young enough to require minding) to the event, and for those children to be able to integrate with the community.

How does this work?

The conference Code of Conduct describes expected behaviour for everyone at the conference:

Here are some additional principles for considering children.

As parents, we all know that it is impossible to expect our children to sit quietly for any length of time unless they are engaged with whatever is going on. As such, we request that parents:

  • Be prepared to move in and out of sessions as required by their children.
  • Occupy seats near exits in sessions.
  • Self-organise with other parents to manage children if there is a must see session or talk.
  • Be aware of the needs of other conference attendees, who have also paid to turn up and hear people speak.
  • Extend the principles of the conference Code of Conduct to children, both yours and others. Treat them respectfully, and avoid corporal punishment.
In kind, we request that everyone:
  • Be patient with children. They are our future leaders and learn by modelling what we do.
  • Be patient with parents. Children are not robots and don’t have ‘quiet now’ buttons.
  • Leave seats near exits free, for use by parents and children (see above - they may need to make quick exits)
  • Assist. If you see a child looking lost or distressed, get down to their level and ask them how you can help. Find a conference volunteer to hand over to.
Remember parents are doing the best they can. At the conference, if you have issues with children or parents, please contact the diversity team (as per the Code of Conduct).

If you feel that your child will not disrupt your presentation, you are welcome to bring them on stage (if they want to). Please organise this with your child ahead of time, so that you can arrange a carer or some other way of occupying your child while you speak.

For parents wanting tools to assist with helping their children get through a conference, there is a wealth of material that may be useful here:

What does it cost to bring children?

Children can attend for free. The catering cost is covered by the Good Mojo program. Please let us know as soon as you can if you are bringing your child(ren) so we can adjust numbers appropriately.

We all know that children can eat in amazing disproportion to their physical size, and we will cater for them as adults.

What facilities are available for parents?

The conference will aim to provide a ‘chill space’ - a refuge for parents and children at the venue. The University of Melbourne has fantastic outdoor spaces (please use them!); but Melbourne weather is not always friendly.

We are also looking into a specific space for breast pumping/feeding - however, breastfeeding mums are welcome to feed wherever they feel comfortable doing so (with respect also to the needs of your child).

While we will do our best to provide spaces away from the buzz, this is at present a work in progress - look out for updates!

Please use the foss4g-oceania-discuss e-mail list or join us on the Maptime Australia Slack to discuss with the FOSS4G organisers and coordinate with other conference parents. (Many of the organisers are also parents)


Special kudos goes to Adam Steer who has been the primary driver behind getting this initiative off the ground.

Saturday 7 July 2018

Commenting on Australia's draft commitments to the Open Government National Action Plan

Australia has a draft of commitments for our Open Government National Action Plan, and have asked for comment. The plan has some wonderful goals, but I wish the authors had a more practical understanding of the workings of digital economies and open source communities. The commitments could be made so much more implementable and impactful. I've provided the following specific comments, along with a reference to my previous submission which is more comprehensive.

Improve the sharing, use and reuse of public sector data

Government's draft commitment: 
… consult across government, through the new National Data Advisory Council, with the Open Government Forum and with the public including businesses, civil society groups and research and non‑profit sectors. The National Data Advisory Council will be a multi-disciplinary expert panel drawn from public sector and civic society organisations.

My comment:
Sharing public data provides noble goals, but as written, government can claim this commitment complete merely by opening access to datasets without addressing the more challenging task of making sure the data is usable.
For this policy to be implemented effectively, it should tie back to measures of data use. This requires an understanding of the characteristics of data management, and should mention measures such as: quality, fitness for purpose, ability to integrate with other data sources, standards based data structures, relevance, usability, timeliness, sustainability of maintenance.

Enhance public engagement skills in the public service

Government's draft commitment:
  • Develop and implement an Open Dialogue Roadmap
  • The Establishment of an APS Engagement Hub
My comment:
In order to be impactful, this commitment needs to extend beyond dialogue and facilitating the sharing of ideas. It needs to extend to the more important issue of collaboration during acquisition, implementation and deployment.
We need to recognise that governments around the world are all solving very similar problems, and the most efficient way to address these problems is to work on them collaboratively. However, cross-agency and cross-jurisdiction collaborative implementation is the exception rather than the rule. This can usually be traced to the difficulty of explaining and applying collaborative techniques within government frameworks.
I recommend this commitment be extended to cover the providing of tools to measure and implement cross-agency collaboration. This commitment will require a lot of work, however many of the techniques needed can be derived from Open Source community processes.

Enhance state and territory participation in the Open Government Partnership

Government's draft commitment:
  • Establishing a framework and mechanisms to facilitate communication between state and territory governments and Australian Government officials responsible for Australia’s Open Government commitments to support collaboration and learning on open government matters, and highlight the opportunity for formal subnational cooperation and membership in the Open Government Partnership, and 
  • To demonstrate the benefits of enhanced collaboration on open government matters: engaging with state and territory Information Commissioners to seek agreement to conduct surveys to measure citizens’ awareness of the right to access government information, and their experiences and outcomes in exercising that right.
My comment:
Enhancing state and territory participation is a good start, but the scope of this commitment should be extended up to international collaboration, and down to local government and further. Note that there will always be more people with great ideas who are outside your organisation than can ever mustered from within. So with every policy and procedure you write, and every application you build, do it collaboratively. 
Use, Extend, or Create, in that order:
  • Use existing material if it exists;
  • Otherwise extend and give back;
  • As a last resort, create your own, share, and endeavour to attract collaborators.