When a company is formed, individuals within must cooperate for it to succeed. As the company grows, the chances that not cooperating can be more rewarding for an employee are increased.
We are all too familiar with the examples of this behaviour: Developers short-cutting test efforts, delivery promises not kept at the last minute or the dreaded “office politics”.
A clear difference between a collaborative project and an “uni-lateral” project is – how to establish a level of confidence on whether all the parties involved on the project will deliver their contributions as intended. I don’t think this problem is unique to Open Source Software, but in fact can be found in many “trust-based” transactions. By “trust-based” transactions, I mean exchanges where the completion can not be warranted beyond relying on the other party to do the right thing.
Prisoner's dilemma depicted by scs.imsa.edu
Few decades back, a field of mathematics called Game Theory modelled this situation in “the prisoner’s dilemma“. Imagine that you and your best friend have been arrested by the police for a crime to which both of you were part to. You are put into different interrogation cell’s and offer the following deal:
“At the moment, neither of you is talking… but we have enough evidence to put both of you prison for 2 years. However, If you are prepare to incriminate your accomplice, we will cut your sentence to 1year community service and he will spend 5 years in jail. But you must hurry, because we are offering the other guy the same deal. If he gives you up, you will spend 5 years inside…you have 5 minutes to decide” But you know that if both of you talk, the jail term will be 3 years for both of you… so what do you do?
There is no clear cut answer to the question, hence is called a dilemma 🙂 In fact, John Nash identified a theoretical equilibrium point at the “guilty-guilty” scenario. This is the only scenario where, considering the other person’s choice, you couldn’t have been better of if you had chosen differently. However, actual lab experiments showed that “real” people don’t tend to choose the Nash equilibrium more often than the other 3 scenarios.
A variant of the problem is the “iterated prisoner’s dilemma” , this is when the game is played repeatedly and the impact of the decision into future transactions is taken into account in the current “game”. It’s this version of the dilemma that in my opinion applies to collaborative development projects.
In collaborative projects the 2 players are the contributor and “benevolent dictator“/project lead. Will the contributor keep to his/her public commitments? Will the project lead accept the contribution and give the kudos where is due?
Ultimately, the attitude of both players will be influenced by the prospect of future collaborations. If you are trying to facilitate these kind of relations, here my views on how to make it successful:
Iterated the Game as much as possible: Ensure the collaboration is not based on a one-off interaction. The easiest way to do this is to have a multiple-deliveries integration plan vs big bang approach.
Raise the stakes: The prisioner’s dilemma is based on the fact that the reward of defecting is far larger than cooperating. You can alter the situation by raising the stakes for mutual cooperation, making it much more attractive to both parties. (i.e. in a situation where “if nobody talks, you are both free” there is no dilemma)
Lastly, make sure common sense prevails. Although game theory is a fascinating subject, proposed solutions to this dilemma have failed to consistently predict how real human (i.e. not only rational but also emotional) beings actually behave.
Before I joined the Symbian Foundation, I was working on improvement programme for Nokia. During that time, I learned and observed the impact of change in people.
Theory says that a person normally goes through 4 stages/moods before it fully embraces the change. The first two stages consist of denial: either that the change exist all together or that, even when we accept its existence, it is going to impact us at all. This is also true of communities migrating from a close to an open source model.
While, technical changes are easier to accept, the hardest challange remains in encouraging ‘once upon a time’ customers to now be equally responsible for the development of the platform and reminding suppliers that are no longer bound by SLAs, only by common sense.
In a way, that is probably why open source projects with one major member contributor and many users, that limit their collaboration to minor updates, seem easier to accept (maybe because they feel more familiar). However, what are we really trying to achieve by going open source? Will this really unleash platform innovation?
The next stage to denial is exploration. When you start asking yourself what opportunities I can seize if I jump deep into this change. Is it possible that by investing some resources into improving the Symbian Platform I can open up larger opportunities for me and my company?
Start planning what contributions you need to make in order to enable your business model. You can not assume that someone else is going to do it for you, as everyone scratches their own “itch”. You can hope that you will find common ground with other contributors, allowing you to share the “scratching” cost. Recognising the advantage to the community of coordinating “scratching” efforts, the Symbian Foundation has set-up a centralise Release Management and Planning function. We are a growing team of 4, currently working towards building delivery plans for Symbian^2 and Symbian^3.
I guess the last stage is when the change feels so natural that you can not even imagine how you use to survive doing things the “old” way.
Victor Tuson Palau 