Wednesday, 1 May 2019

OSGeo selected for Season-of-Docs 2019

The OSGeo Foundation has been selected to participate in Google's Season-of-Docs initiative. We've identified tasks based on OSGeoLive, QGIS and GeoNework.
Our approach is a little different. It is not just about searching for paid superstar technical writers. (Although superstars are welcome). We also want to support and expand our existing volunteer community. These are ordinary people, gifting bursts of effort, toward small, discrete and achievable tasks, to collectively achieve an extraordinary impact.

Ideas we'd like to explore:

  • Open source projects face sustainability challenges. How will docs developed during Season-of-Docs be maintained long term?
  • Can a writer’s expertise be amplified to help community users and developers write good docs more effectively and efficiently?
  • Could best practices developed in one project be applied to the greater open source eco-system?
Are you interested? If so, please introduce yourself on our email list, or contact me directly.

Cameron Shorter

Thursday, 4 April 2019

Amplifying Google's Season of Docs

Google has initiated a Season of Docs collaborative program aimed at improving open source documentation. It provides a great opportunity for us involved in open source and documentation to focus on big communication challenges.

Challenges

  • Vision: Does everyone know the characteristics of good open source documentation? Does anyone know? Let’s collate research and best practices into accessible guides and templates.
  • Targetted: Projects communicate with a range of personas. They have different technical backgrounds, attention spans and information needs. A range of documentation types are needed. Each requires different levels of depth, specificity, currency, narrative, personalisation, examples, and more.
  • Empower everyone to contribute: Good documentation benefits from cross-disciplinary contributions: from developers, users, domain experts, teachers, technical writers, graphic artists, and translators. Ramp-up time is high for any group attempting to learn another’s skill-set. Open source documentation processes are typically set up by developers, for developers, and have a significant barrier-to-entry for others. How can we fix that?
  • Attract volunteers: How can we apply our knowledge of collaborative and volunteer communities to attract documentation teams? How can we help volunteers maximise the impact and effectiveness of their contributions?
  • Current and Sustainable: How can we sustainably keep documentation synchronised with rapidly evolving software? How do we help users find current material and archive outdated docs? How do we minimise maintenance?

What to focus on?

To maximise value, I suggest promoting initiatives which:
  • Use and contribute to documentation best practices.
  • Use templates and guides for key documentation types to help cross-domain collaboration.
  • Attracts volunteers, from multiple user profiles.
  • Applies multi-directional mentoring.
  • Refines workflows and tools to reduce barriers-to-entry.
  • Focuses on a specific initiative which tests the bounds of these ideas for a specific project and captures lessons learned.
This might involve:
  • Auditing existing documentation.
  • Defining a writing strategy.
  • Developing or refining a specific documentation type for a project.
  • Mentoring a project’s community, increasing the initiative's sustainability.
  • Contributing to best practices.
If we can achieve this:
  • Writer contribution impact will be maximised,
  • Community writing will become more effective,
  • And documentation maintenance will become more sustainable.

Further Reading

The OSGeo Foundation's focus in Season of Docs 2019:
General:
Documentation Strategy:
Research into building open source communities:

Tuesday, 12 March 2019

Google Season of Docs Announced

Google has just launched a Season of Docs program, designed to bring open source and technical writer communities together, to the benefit of both. Awesome! I reckon our OSGeo projects should get involved, and I'm personally keen to be part of it. Anyone else want to join me?

Sunday, 3 March 2019

Starting build cycle for OSGeoLive 13.0

Are you interested in joining our Open Source GIS experience? The build cycle for the next OSGeoLive release 13.0, is going to start. The final version is planned to be ready on 30th July 2019 in time for FOSS4G 2019 in Bucharest. Have a look at our schedule for the detailed steps.
Till then we have many challenges - from simple to challenging, to help describe and train people in the value of Open Source GIS.
For this release, we hope to help OSGeo Community projects join OSGeoLive, and work out how we can keep within our size constraints.
We'd love to build a cloud version of OSGeoLive for this release. It would make OSGeoLive, and OSGeo software much more accessible. It seems elusively achievable, but we haven't worked it out yet. If you think you could help, we'd love to hear from you.

Get involved

Are you a programmer or packager with experience in one of the Open Source GIS applications. Are you a technical writer interested in making FOSS4G accessible to all? Are you interested in helping update translations to latest documents on Transifex.

Contact us

If you would like to add a new project, help us to get in the cloud or have another goal you would like to work on and get involved you are very welcome.

Please join the OSGeoLive mailing list or meet us on IRC at our weekly meeting.

About OSGeoLive

OSGeoLive is a ​Lubuntu based distribution of Geospatial Open Source Software, available via a Live DVD, Virtual Machine and USB. You can use OSGeoLive to try a wide variety of open source geospatial software without installing anything.


Friday, 22 February 2019

Inspiring techies to become great writers

How to attract writers into Open Source communities, have them amplify developers' written impact, reduce tech ramp-up, facilitate growth, while having fun improving the world.

Reading time: 8 minutes

Presented at Write The Docs - Sydney [slides]

My story starts at the international conference for Free and Open Source Software for Geospatial when it was held here in Sydney, ten years ago. We wanted to build a distribution of the software to hand out to conference attendees. Back then when software was expensive to download, it was a useful handout, and it provided an attractive marketing pipeline for these free software projects.

To build the first version of OSGeoLive we followed install instructions, configured applications, resolved dependencies and conflicts, asked questions on email lists, and finally, after much hard work, produced our first release. This was a very important first step as it showed that we had the commitment to follow through and deliver.
Install Script
However, it also highlighted many of our failings. We had followed a fully manual install process, so when the next software releases came out, we had to start the installation process again, from scratch. It was completely unsustainable. We needed to automate the install process, and we needed projects to show us how.
But our first calls for help were embarrassingly underwhelming. You see, the perceived learning curve for packaging was considered unacceptably high and volunteers were not stepping up.
To fix this, we wrote an example install script along with clear, step-by-step instructions. We then went back to developers with the message of "if you can spend a couple of hours writing a short install script which looks like this, then we will market your application through our OSGeoLive distribution". Small effort / High Value. And it worked! 28 projects packaged their applications for our version 2 release.
Using a document template
In following releases, we applied the same process to documentation. Our first docs were written by developers and as such were quite ... variable. So we created skeleton outlines for Project Overviews and Quickstarts, along with clear writing instructions. We then asked projects to write documentation in line with these outlines. We followed up with reviews, and a publishing pipeline, to produce consistent, quality material. So by applying an outline / write / review / publish process, we were able to achieve significant efficiencies by allowing experts to focus only on the bits they do best and thus reduce contribution effort.
Translators later adopted the same formula to create multiple language variants.

Unpacking the story

Ok, let’s unpack this story from the perspective of technical writers. Firstly, we should acknowledge the significant efficiencies software enables. Four out of the ten richest people in the world are self-made software entrepreneurs.
However, while proprietary businesses centralise captured wealth, open source software, like other creative commons works, is given away for free. This act of sharing has far-reaching consequences. Tools and knowledge created can be used and built upon by everyone. This democratises knowledge, wealth and power.
So if you want to positively improve our world, supporting Open Source projects is a good place to start.

The Research

So what makes a successful Open Source project; one which is sustained in the long term? Research provides some answers, An analysis of over 170,000 Open Source projects to identify success factors, and a study of the success factors of episodic volunteering in Open Source both highlight the importance of:
  • Clear utility,
  • Lean governance,
  • Clear vision and goals,
  • Marketing and a quality website,
  • Good user and developer documentation,
  • Digestible information,
  • Guided introductions,
  • Simple workspaces,
  • Task–finding dashboards,
  • Financial backing,
  • Fine-scaled task granularity, making it easier for people to contribute.
And on the social side:
  • Leaders who lead by doing, by putting in the hard work,
  • A virtuous and supportive community,
  • Attracting external contributors,
  • Advocating broadly, by all involved,
  • A sense of collective ownership,
  • Hosting of meetups,
  • Recognising all forms of contribution,
  • Personal invitations for help,
  • Showing appreciation.
Notice the prevalence of communication within these characteristics?

Communicators Needed

Communicators helping the world
Where I’m heading here is that while the Open Source story usually focuses on software developers, equally important are communicators and community builders. So for you folks who are technical writers, Open Source communities need you! Your involvement can significantly amplify a project’s impact, and by extension, your help will be:
  • Making the world more egalitarian,
  • Reducing wealth inequality,
  • And democratising knowledge and power.

Bridging the tech gap

I’d like to touch on inflection points. As a project’s technology and user base matures, community success factors move. An early inflection point with Open Source projects happens when a project attracts external contributors. These contributors increase the size of the workforce and add extra skills, but they lack the deep domain expertise of the core team.
To attract contributors, projects should reduce ramp-up time; and good documentation is key. Poetically, the documenters who are most qualified to help are typically the least technical, and face the greatest ramp-up time.
Johanna Botman
To help explain this problem, I’d like to introduce you to Johanna Botman. She started her working career as an English teacher, then moved into IT, website design, and is now a geospatial officer in local council. I met her at a spatial conference’s community day when she joined other volunteers in updating our OSGeoLive documentation. It was a humbling experience for me. I saw such an accomplished person, with oodles of commitment, struggling to use our documentation tools.
Johanna reviewed an early draft of this presentation and observed that ...
Some of the issues relating to getting started are about bridging the gap between developers and writers. Developers write code in coding tools. They collaborate, they are used to versioning and are at home with unformatted raw text and automation tools. Writers? They work on Windows machines in Word – maybe in Google Docs if they are lucky. They don’t know about running build scripts, running Linux variants, Github, chat programs, HTML, RST, Wikis and the variants of markup languages.
It’s one thing to work with the Open Source software, another to write about it, and a third thing to work out how to write it so that it fits in with the project. It seems as if the developers have created the writing system in a way that they are used to working, not necessarily in a way that works for writers.
And I think Johanna is right. I’ve found many users and writers who are keen to help but feel overwhelmed, don’t know where to start, don’t want to burden the existing community, and so are shy to ask questions.
Writers need to be sought out, welcomed, encouraged, supported and publicly appreciated if projects are to attract good documenters to help them grow.
In turn, I’d encourage writers to proactively reach out to development communities. I’d expect you’ll find them very welcoming and appreciative, especially if you are volunteering to tackle key documentation pain points. And together we need to help bridge the gap between writers and developers.

Documentation Strategy

So what should writers expect to see when joining a project. Typically, emerging projects have patchy documentation, in various stages of currency, completion, relevance, verbosity, and quality. The challenge is to consolidate it so that it becomes concise, intuitive, accurate, minimises learning and ramp up time, and sustainably maintained to match continually evolving software releases. This is non-trivial and requires good writing skills, planning, leadership, commitment and follow through to do it well.
The problems are that:
  • Software is complex. It’s hard to understand, and harder to explain.
  • Software continually evolves, meaning documentation needs to be continually maintained.
  • Projects have a range of audiences, with differing information needs, technical backgrounds, and attention spans.
Daniele Procida provides valuable advice in an article titled:  What nobody tells you about documentation.
Document structures recommended in What nobody tells you about documentation.
Daniele is an open source developer, technical writer and teacher and he explains that:
There is a secret that needs to be understood in order to write good software documentation: there isn’t one thing called documentation, there are four. They are: 
  • Tutorials, 
  • How-to guides, 
  • Explanations and 
  • Technical references. 
They represent four different purposes or functions, and require four different approaches to their creation. Understanding the implications of this will help improve most software documentation - often immensely.
Daniele is on the right track although I feel his list should be expanded to include other forums.
Placing documentation types
Raw image (in draw.io format)

Writers should identify and define the characteristics of their communication mediums.
The front web page and elevator pitch should be concise, highly polished and target first-time visitors, while community forums are good for once off questions and can be rough around the edges.
For each medium, define:
  • Personas for your target audience,
  • Document structure,
  • Technical depth,
  • Quality requirements, and
  • Maintenance strategy.
Then aim to:
  • Write timeless material to minimise maintenance.
  • Only write as much as your team has the capacity to maintain.
  • Help techies become great writers. Provide skeleton docs and writing instructions, then review, mentor and publish.
  • Work within a release cycle, which ideally synchronises with the project.
It’s worth noting that most of what I’m talking about here is relevant to all sorts of technical writing - not just for Open Source communities.

Getting Started?

Tech Writer Heros
Image source
Okay, so maybe you’d like to get involved and are wondering where to start? I’d suggest:
  • Focus on one project instead of many, as your ramp-up time will likely be high.
  • Acknowledge the value you bring. Use it as motivation because you’ll have many challenges and the inner motivation will really help.
  • Demonstrate commitment. It’s contagious.
  • Ask for help, you will need it, and you’ll likely be surprised how supportive people will be.
  • Don’t be daunted by your lack of domain knowledge. It’s actually an asset when writing to a broad audience.
  • Help developers become great writers. Great impact comes from amplifying the effectiveness of others.
  • Be part of the team; help paint the vision; be inspirational.
  • And most of all, have fun while you are doing it. Because believe you me, it is hugely rewarding to share the team camaraderie involved in building something that is much bigger and more impactful than you could possibly create by yourself.

    Sunday, 20 January 2019

    Toward a universal Style Manual

    The Australian Digital Transformation Agency plan to improve the Australia Government's writing style manual. Great. Can I help?

    Worst user, best friend

    I'll be your most demanding user. I'm technical, have no writing training and won't want to read the manual. And yet, this manual should be written for me. Why? Because people like me write policies, code, manuals, business cases, standards, designs,  requirements, tutorials. We write for government, industry, open source and international organisations.

    Writers shouldn't read your manual

    Auto-correctors fix spelling and grammar; templates help writers with headings and writing tips. The best way to reach us technical writers is to embed style guidance into these tools and templates. (Could you please also fix their formatting bugs, which seem to be in every word template I've ever used.) 

    Go universal

    Please avoid the temptation to create an Australian specific Style Manual. The inevitable inefficiencies caused by integrating local and international style variants will be painful. Draw inspiration from the Creative Commons licenses. They are internationally recognised, widely used and widely understood.  

    Collaborate

    Collaboration mitigates against being out-innovated, as in the digital economy, collaboration out competes competition. There are more smart people in the rest of the world, thinking about your problem, than can ever be mustered in your own team.
    • Use, extend, create - in that order:
      • Use existing material if it exists;
      • Otherwise extend and give back;
      • As a last resort, create your own.
    • Evangelise; encourage other nations to adopt the manual. Like language, the manual becomes more valuable as more people use it.
    • Use collaborative tools and methodologies to engage communities and evolve material.
    • Share ownership and control.

    Modularity

    Let's make the style manual extensible, to support domain specific requirements and individual flair. For instance, the international manual will need to support toggling between American and British spelling, and agencies will want to add domain specific acronyms. 

    Don't finish

    People will continue innovating. Establish a sustainable project, owned by multiple stakeholders, with periodic release cycles, which will last beyond your current funding cycle.

    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


    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.

    Recommendations:
    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.

    Recommendations:
    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.

    Recommendations:
    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.

    Satisfaction

    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.

    Recommendations:
    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.

    Recommendations:
    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.

    Recommendations:
    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.

    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


    Abstract:
    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 is 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 Chaotic 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 Hubmetrics. 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.