Saturday 26 November 2016

The elusive "Open Business"

Variants presented at:
  • 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: 

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.
  1. Should you use Free Software or Free Data?
  2. Should you design systems using Open Architectures and Open Standards?
  3. Does it make sense to contribute back to communities?
  4. Is there a business case to help lead community initiatives?
  5. 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?

And that is where companies like Jirotech, EnterpriseDB and Redhat step in.
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.
  1. Is to use open source, as multiple vendors can all support the same codebase.
  2. 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.

  • 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.


steve jenkin said...

Great run-down of 'Why FOSS" - standing on the Shoulders of Giants.
Loved the Daniel Pink video: life & work aren't only about Profit at any cost.

longer version at:

Humans in groups benefit more from general co-operation than competing fiercely all the time.
Competition creates 'challenge' and prevents complacency and laziness - it's not a bad thing in itself.

Competition comes with downsides:
it's economically 'inefficient', re-inventing the wheel repeatedly.
In Engineering terms, everyone reinvents the wheel, repeating some, not all, mistakes
and no one group ever learns all the 'good' things. Until they merge or are bought up...

Monopolies, or Oligopolies, actively suppress competitors, reduce diversity and multiply costs to consumers.
They may be 'private', but they are anti-competitive and economically disastrous for the markets they hold captive.
Think "Too Big to Fail" and the 2008 global financial crash to understand it's more than just goods affected.

Open Source actively prevents the worst outcomes & encourages the best that Capitalism has to offer: competition of ideas, sharing of Information and knowledge and building on the work of others.

Open Source scales, encourages invention, diversity, novelty & rewards innovation, hard work & risk taking.
It actively prevents asymmetric rewards and 'winner takes all'.

This is capitalism in action. It's mass competition within truly free markets.

Open Business _is_ risky: you can't be complacent or stop Putting the Customer First.
A simplistic analysis might brand Open Source "socialist", but it is the precise opposite.
Open Source underpins fierce, wide-spread competition, while allowing customers needs to be met.
Open Source truly levels the playing field, allowing anyone to earn money based on merit not an inherited position or privilege.

Open Source is an unfamiliar model to many:
it's fierce competition, that embraces sharing, egalitarian market access and equitable rewards for work.

It's the Epitome of Adam Smith's Free Market, not anything else.
Sharing source code removes information-based market distortions: all sellers and buyers have full market information.

Google, Facebook and Amazon got huge on the back of Open Source and actively contribute their work back.
Notably, not _all_ their work, but key parts.

These big Internet companies have huge turnovers, have made their shareholders rich and are known for being fiercely competitive. Their success is based on Open Source & they know this: actively supporting developers & projects.

To characterise their commercial success as solely due to Open Source, or within the reach of every 2-person start-up is wrong. For every super-large Open Source business, there are tens of thousands of failed startups, thousands of short-lived businesses, hundreds of sustainable mid-scale businesses and a large community of individuals that share and benefit in the work over time.

IBM, HP, Redhat & Canonical/ubuntu, even Intel and Microsoft, collectively spend billions each year on software & testing they seemingly 'just' give away. For them, this is not philanthropy, it's a hard-nosed business investment that repays itself many-fold.

If large Corporations at the heart of the US economy think Open Source makes financial, business and marketing sense, then what is everyone else missing?

Money makes the world go round and Open Source generates stunningly large sales and profits for those smart enough to embrace it and realise it confers a competitive advantage.
It's just good business.

Unknown said...

A very comprehensive story of open (spatial) source development.

I would like to add that open source (OS) disables vendor lock-in only if there are sufficient commercial providers of development & implementation services and - last but not least - SLA's available.

With the dissemination and adoption of OS it cannot be expected that all users are are technically proficient enough to scratch itches and actively join communities. As end-users they just want to benefit from the functionality at their fingertips. That is where commercial service providers with sufficient organisational and financial acumen, which provide continuity of service, come into play.

Therefore, I would like to have more emphasis on the value add of a technical-commercial eco-system: the combination of technical communities (of individual developers) with commercial organisations (multinationals and local businesses). Combined they provide end-users the desired quality of code ('eyeballs') and continuity of service (SLA).

My 2cents.