Open source innovation

Rethinking the path

Lawrence Meckan

Absalom Media

In a galaxy far, far away..

To understand the future, you have to understand the past.

Started coding for online environments in 1993
Mosiac 1.0 on Mac was the base.
Early adoption of new technology along the Sleeper curve (e.g. HTML in 1993, CSS design in 2001, accessibility in 2002/2003, sIFR in 2003, AJAX in 2003)
Background in UNIX / System 5 / Wintel / Linux sysadmin with talker/MUD coding "superuser".
Also trained within psychology, primarily dealing with HCI, cognition, perception, conflict resolution and crisis counselling.
Professional OS and commercial lead development on software, hardware and IT management

So what does this all mean?

Reality redux

The state of open source is dependent on the primary resource it has. That resource is people, not attention or focus. Why ?

Codebases come and go. e.g. C++, C#, ASP, .NET, PHP, XML, XAML, XSLT, HTML, Ruby, Cocoa, AJAX
Within each codebase, you have users, members and owners, as per the 90/9/1 rule.
The more voices there are in any one project, the greater the risk of conflict.
Even the smallest collaborative project can face conflict
The same problems in terms of how to manage people appear in various projects in the same ways

The open source "smoothie" approach

In order to create a successful open source project you need:

"Benevolent" dictators to manage the project
An open mind. Obviously you're solving something with what you're building.
The ability to listen as well as lead
The ability to handle dissent and conflict in an appropriate manner.
A means to get the project out there

Open source: benevolence

What is benevolence?

disposition to do good ..an act of kindness.. a generous gift

Benevolent dictactors inside Open Source have key outcomes:

Goodness.. epitomised in the Google "Do no evil"
Leverages a certain level of trust.
Comes with the responsibility to not abuse / do no harm.

Open source: dictatorship

Most, if not all, OS projects retain a small core locus of control. Most people feel unsafe losing that control.

The ego associated with control and power can cause harm.
Conflict causes anxiety and stress. The trick is how to deal with it.
Relying on 'pop psychology' to resolve issues won't help either.
Censorship, banning and other forms of 'punishment' towards dissenters harms any project.
Online behaviour is no different to offline behaviour whenever tradition / status quo is questioned.
Poison can start at the top. It's not always those associated with the project that are at fault.
Parallels with Galileo and Copernicus (dissenters) to the Roman Catholic Church

Open source: The dissenter

We can learn from Galileo's experience inside the OS movement.

Galileo facing the Roman Inquisition, 1857 painting by Cristiano Banti.

Open source: leadership

To be a leader, like Galileo, requires both vision (risk or dissent) and direction (control)

The code you use at the end of the day doesn't really matter.
How you deal with fellow developers and peers will matter.
Self-mediation shouldn't be the only solution when things go wrong.
Leadership require collaboration, dedication and delegation.

Open source: listening

A challenge to all hard core developers: Listen

Deliver what your customers need
Deliver it simply
Misunderstandings happen. Get over yourself and your bruised ego, and keep on listening.
Fail fast. Growth takes time.
Merely because someone disagrees doesn't make them your enemy.

Open source: conflict

Conflict will happen in any relationship. Any amount of change will raise concerns.

Handle it in a way that ends up with win/win in terms of relationship dynamics.
Don't resort to name calling, dirty tactics or misinformation.
When the developer or project becomes stressed out, get someone else to mediate the issue.
Learn from and document your mistakes. People are meant to learn by failing.
As a leader, it is in your best interest to acknowledge when you have done wrong.

Open source: mediation

The mediation process should be as follows:

Able to stand up to peer review and transparency tests.
Bias towards leadership or project is unhealthy.
It's not about a "win" for either side, it's about rebuilding common ground.
Impartial third party should be managing the process.
Will take time and effort away from coding.
Developers do get offended easily, so train them in people skills.

Open source: governance

Each project requires some rules and ideals for governance.

Those ideals must be outward and growth focussed.
The rules should then encourage fostering of those ideals, not harming them.
The rules are there to help, not to enforce status quo.
Examples where rules come before people: Banning or censoring dissenting views
Negative publicity on a product can be devastating (e.g. the Mambo brandname post-OSM fork)
Value scale: People first, ideals second, rules last.

Open source: the wheel

So why do the same problems keep appearing?

People mistake critiques for personal attacks.
If they remain within the locus of control, they can blacklist.
People mistake dissent for destruction / poison.
Without dissent, people or projects cannot grow beyond themselves.
Dissent and conflict are part of the human condition.
It's how you deal with these things that count.
Benevolence doesn't equal silencing dissent.

Open source: the wheel turns

What factors play a part ?

Geekdom - pride of place/ego in taking "lead".
Inability to listen to competing or contradicting viewpoints.
A strictly hierarchical and authoritarian worldview.
Ethical development at the "reward and punishment" stage: morality must be defined and enforced by an external authority (moderation, censorship).
Low tolerance for ambiguity. Everything must be clear cut, black and white. Nothing can be "possibly true but unproven at this time, we're still studying it."
Long working hours / involvement for little gain

These factors are also seen inside fundamentalism. So where does this lead us?

Open source: evangelism

Being an advocate requires:

Sound reason - not claims that do not match reality
Credible evidence - code, demonstrations of ideals and ethics in place
The ability to recognise the imperfections of OS. We're not perfect. Deal with it.
The ability to grow beyond a single point of view.
Listening and fostering the discussion with others.
Learning from the mistakes of evangelism done by OS advocates in the past.
An appropriate work/life balance. Some OS leads suffer here.
Building up trust amongst the marketplace.

Open source innovation

Recognising all these areas, innovation covers:

The ability to dissent as well as lead. Sometimes things don't go as planned.
The humility to learn from those around you.
The maturity to rectify wrongs you or your project has done.
The honesty to sit down and 'break bread' with those you don't understand.
The freedom to recgonise the people who work and use your product are the project, not the codebase.
The liberty to be an advocate for your product, recognising the path is still maturing.

Open source: Predictions

So where to from here?

Natural selection will reduce immature applications into more mature products.
Convergence and interoperability on the web are key issues for 2007 onwards.
The focus is always the end user, not the developer or the project.
The 2006 bubble has been and gone. Now make sure the work already delivered helps people.
Learn from the mistakes of AJAXing everything.

22nd March 2007