- The “Geo-enabling our communities” conference, hosted by the Australian/New Zealand Surveying & Spatial Sciences Institute, Canberra, Australia, 25 November 2016.
- The International Digital Earth Symposium, Sydney, Australia, 6 April 2017.
- The "Spatial Information Day" conference, Adelaide, Australia, 11 August 2017.
- Slides available at: https://docs.google.com/presentation/d/19fwg23g86PKNNuVlH8BmcWRnA9nwL_tgowJOoFPOLdc/edit?usp=sharing
The Open Source story about creating Free Software sounds a bit like a fairy tale.
Highly motivated developers,
joyfully beaver away,
in the middle of the night,
to create high quality software systems,
which they give away for free.
While this simplistic recount is mostly true,
it glosses over the many subtle details required to create a successful Open Source project.
Why do so many people give away so much of their time?
Why are these volunteers so effective?
Why does open source work?
Why has the business world found the open source formula so hard to replicate?
Surprisingly, many of the answers are found of our core morals and ethics.
The question of Open verses Proprietary actually breaks down into a series of sub questions.
- Should you use Free Software or Free Data?
- Should you design systems using Open Architectures and Open Standards?
- Does it make sense to contribute back to communities?
- Is there a business case to help lead community initiatives?
- And if so, should you help scale community and tap into the world’s collective intelligence?
This is a big topic and we have limited time, so I will focus on some of the key messages, mostly at the “use and implement” end of the continuum.
Lets start by asking why you might use Open Source GIS Software?
If you are starting from scratch, the answer is simple.
There is a comprehensive stack of mature, widely used and widely supported Open Source Geospatial applications, all available for free.
This is a screenshot from the OSGeo-Live software distribution.
OSGeo-Live includes 50 of the best geospatial Open Source applications, along with sample data, project overviews, and quickstarts for each application.
Lets look at a few of the more popular applications:
QGIS is a desktop GIS application similar to ArcGIS with comparable features, but it free.
OpenLayers is similar to Google Maps API, or ESRI’s Javascript APIs, also free.
Cesium provides a 3 dimensional globe of the earth, like Google Earth, but free.
GeoServer is a map rendering server, similar to ArcGIS Server.
It is the reference implementation for a number of the OGC standards, and is … free.
PostGIS adds
spatial functionality to the Postgres
database.
It is comparable in maturity,
stability, performance and features to Oracle Spatial and Microsoft SQL Server, except it is … free.
For free data, you can use Open Street Map, and Open Route Map. This data is typically pretty good, and suitable for most use cases, but still not as consistent as datasets such as Google Maps.
Ok, so the software and data can be free, but there is more to applications than just the purchase price.
There is deployment, maintenance, training, support.
And who are you going to call at 2am in the morning if something goes wrong?
They backfill the capabilities of organisations deploying these free applications with enterprise level support and services.
So we have covered the first obvious question,
“Does open source compete favourably feature-for-feature?” It does.
But we have just started. When considering an organisations’ technical roadmap, there are more reasons for selecting Open strategies.
Lets start by considering some of the characteristics of the digital age.
And the amount of software created is innovating at a similar rate.
Odds are that any software you own will be out-innovated within a year or two.
Your software is not an asset!
Your software is a liability!
It needs to be updated, maintained, and integrated with new systems.
It is technical debt, and you should try to own as little of it as possible.
You can achieve this by purchasing Proprietary Software, by using Software as a Service, or by leveraging Open Source.
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.
Where Open Source and Proprietary business models differ is how they respond to monopolies.
Proprietary companies are incentivised to lock out competition and increase prices as much as the market will bear.
However, the open source licenses are structured such that multiple companies can support the same open source product, so the market self corrects any tendencies toward price-fixing.
This leads us to Vendor Lock-In.
Vendor Lock-In occurs when replacing a vendor’s product would significantly impacts your business.
It is a significant risk, as vendors then have excessive influence on price and your future technical design options.
There are two key strategies to mitigate against vendor lock-in.
- Is to use open source, as multiple vendors can all support the same codebase.
- Is to design modular architectures based on open standards.
Using modular architectures:
- reduces system complexity,
- 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.
Committing to and sustaining a modular architectures requires continual vigilance and forward thinking, especially when acquiring new systems.
There will always be quick fixes and vendors offering more features if you are prepared to accept a level of lock-in.
You should be considering:
- Long term maintenance,
- Ability to integrate with other systems,
- Obsolescence,
- And the cost of a future exit strategy.
What I’ve described so far is practical, main stream advice.
Using open standards, open source and open data is now promoted in government policies and purchasing guidelines, and can be justified based on sound traditional economics.
But the Open Source culture is not based on traditional economics.
Open Source and Open Data communities are usually founded on gift cultures, and continue to retain the principles of the gift culture in their DNA.
If you wish to successfully engage with these open communities,
If you wish to have these communities adopt and maintain your codebase,
It helps to understand and respect these gift cultures.
And this starts by understanding our human desires to do things intrinsically good and valuable.
Which brings us to the topic of motivation. While traditional carrot and stick incentives improve motivation for boring, mechanical type tasks, research has shown it to be counter-productive for higher order thinking, such as creating software.
Dan Pink has collated this motivational research into a compelling book called Drive where
he describes how we humans are wired with deeper and more effective motivations. Namely: …
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.
So if we facilitate the collaboration of highly motivated people, with the interconnectedness of the internet, and provide them with creative tools, amazing things happen.
Like:
- Wikipedia which has displaced Encyclopedia Britannica as the authoritative information source,
- And Linux which is the dominant operating system in IT service centres,
- Open Street Map, which provides detailed maps of the entire world,
- And the OSGeo-Live distribution of Open Source Geospatial Software, a project I’ve been involved in for close to 10 years and which has attracted hundreds of contributors.
So how does this translate to attracting and engaging communities?
Professor Charles Schweik tackled this question. He and his team studied thousands of Open Source projects to identify common characteristics of successful projects, and they came up with some interesting findings. Like:
- Most successful open source projects are small, with just 1, 2 or 3 developers. This is surprising if your exposure to Open Source is through the media stories which almost exclusively reference large projects such as Linux or Android.
- Also, most open source projects are abandoned. 5 out of 6 according to Charle's research.
But this is not a weakness, the low success rate is actually a good thing.
Developers vote with their time, and only great projects survive.
Also, when your developers are also users, wanting to scratch an itch, they are the best qualified to decide what is best for a project.
And when your developers are motivated by Autonomy, Mastery and Purpose, they will be motivated to spend extra time to “Get things right” rather than compromise on quality.
What Charlie's team found from their research was that successful projects usually possess:
- A clearly defined vision,
- Clear utility,
- And leaders who lead by doing.
Then as projects move into a growth phase, successful projects tend to:
- Attract an active community.
- Provide fine scaled task granularity, making it easier for people to contribute.
- And often benefit from attracting financial backing.
Lets expand on this. What attracts community?
Attracting volunteers involves helping maximise the unique, intrinsic value a person can contribute based on their limited time available.
Effectively maximise the usefulness and moral return on effort.
This starts with a clear and compelling vision, inspiring enough that others want to adopt the vision and work to make it happen.
This should be followed by a practical and believable commitment to deliver on the vision. Typically this is demonstrated by delivering a “Minimum Viable Product”.
Then you need to be in need of help, preferably accepting small modular tasks with a low barrier to entry, and ideally something which each person is uniquely qualified to provide.
If anyone could fix a widget, then maybe someone else will do it. But if you are one of a few people with the skills to do the fixing, then your gift of fixing is so much more valuable, and there is a stronger moral obligation for you to step up.
Attracting collaborators means new ideas, new
ideologies, and new visions.
A successful project works out how
to balance competing priorities of adding features, retaining quality,
remaining sustainable, and staying on task.
As projects mature and increase in complexity, reliance on the experience of core contributors increases.
Eventually core tasks for large projects usually becomes more consuming than can be sustained by volunteers.
At this point, sponsorship really
helps.
As an example, I’ll reference the OSGeo-Live project I’ve been involved in.
Ten years ago, the Open Source Geospatial Foundation was a collection of Open Source applications, but lacked consistent marketing and was difficult for new users to navigate and understand.
So we proposed to package all the applications on a DVD, ready to run, with sample datasets and consistent documentation. This was our vision.
We then created a minimal first version of the distribution, demonstrating our commitment.
As some of us were on the organising committee of the next international geospatial Open Source Conference, we committed to hand out the DVD at the conference, creating a targeted marketing pipeline. This provided clear value for the developers we were recruiting.
Then we provided simple guides on how to write installers and documentation and went to the open source developers saying:
“If you package your application and write documentation, like this…, then you can tap into a targeted marketing pipeline”. This made it easy for developers to provide discrete and uniquely valuable contributions.
And it worked. We have attracted 100s of volunteers, to package 50+ projects, with documentation translated into over 10 languages, which is updated every 6 months.
Ok, so maybe you might be thinking that giving back to open communities might be noble, worthy, the right thing to do.
But there is no way you’d be able to justify it to management. You wouldn’t be the first to face this dilemma. We regularly help organisations answer various permutations to this question.
The answer typically references “Opportunity Management”.
Opportunity Management is the reverse of Risk Management. However, instead of identifying what could go wrong and putting strategies in place to prevent it, you identify things that could go right, then put strategies in place to help make it happen.
Help an open source community, and the number of users, developer and sponsors will grow, and you will indirectly reap the benefits.
So what have we covered?
- Software is a liability.
- Minimise your technical debt.
- Design modular architectures with Open Standards.
- It reduces vendor lock-in, increases maintainability, agility and ability to innovate.
- There is a breadth of Open Source applications which are feature rich, mature and commercially supported.
- And there is Open Data available to address many of your use cases.
To take things to the next level, to engage with Open Source communities and tap into their collective creativity, you should re-learn how gift cultures work.
The beautiful part to this is that it involves reconnecting with our inner morals and ethics, and doing the right thing.
