Wednesday, 28 March 2018

What could Open Government learn from us Open Technology folks?

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

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

Reading time: 20 minutes (8 pages).

For the technical reader: If you are a technologist and agree with this vision, please add your technical credibility by signing (see below). Diverse support will help sponsors wanting to back its recommendations.

Open letter

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

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

Background reasoning

Democracy is founded on collaboration

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

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

The allure of “open”

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

Principles of the digital economy

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

“Open” is just the start

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

The “community litmus test”

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

“Copying” is not “collaboration”

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

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

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

“Open” by itself is of little value

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

Loving a community to death

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

Attracting community

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

Modularity and standards

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

Destabilising effects of episodic spending

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

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

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

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

Fragmented spending

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

Think agile instead of “big bang” purchasing

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

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

Chasing funds instead of collaborators

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

Call to Action

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

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

Related Reading

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

Signed

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

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


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

Sunday, 26 November 2017

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 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 what how do we assess trustworthiness?

It turns out we all make use of 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. I believe that climate change is happening and that we need to do something about it, despite the weather seeming pretty similar to me over the last 40 years.
  • 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.
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.
  • 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.



  • Questions and comments are welcomed.
  • Slide deck is available online.
  • An earlier version of these slides was presented at QGIS Conference in Sydney, Australia, November 2017.
  • The text behind these slides, by Cameron Shorter, is licensed under a Creative Commons Attribution 4.0 International License
  • For those of you who already know me, I should point out that I’ve changed jobs. I now have a new enigmatic title of “Technology Demystifier” in the Information Experience team at Learnosity. And while it’s a shift away from my Open Source Geospatial roots, I plan to continue to be actively involved in Open Source.
  • 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:

Friday, 10 November 2017

New career at Learnosity

Testing out the Learnosity Pool Table
I'm excited to have started a new career 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 hired into the Information Experience team to help take Learnosity communications from good to awesome. I'm looking forward to the challenge.

And what about my history with Open Source Geospatial?

I’ve spent the last few decades being passionate about Open Source and Geospatial Software. It is something I’m intending to continue with, although I’ll be adjusting the focus a bit. I’m still crystallising my thoughts on how my path will pan out — so watch this space.

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

Monday, 16 October 2017

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