Today just a quick update on integration planning..Over the last few weeks, we have been working on providing a bit more clarity on what artefacts are we use to plan platform releases, and how do they related to each other:
In a nutshell:
We produce a platform release plan that provides implementation details to the Platform Plan (roadmap)
The Platform Release Plan contains plan per active S^n release
Each Release Plan is informed by the Integration plan and the Test and Quality Plan (not yet available)
The Integration plan is derived from the information available in package backlogs and feeds into the kit schedule
Recently I blogged about using Bugzilla to track features. I am happy to report that things are moving forward really well thanks to the community and Mylyn. We now have created the high-level delivery plan for Symbian^3 in Bugzilla, and completed the details for one of the key features: New Graphics Architecture (NGA – aka Screenplay).
As you can see from the picture, Mylyn makes it really simple for anyone to keep an eye on the plan.
BUG_ID 176 is the top level entry for NGA. In this post, I won’t go into the specific details of NGA, but explain the next step that we are taking in our planning: The Integration Plan.
Having all this data in Bugzilla allows us to build a good view of the progress of a specific release. As we do not want to be monitoring every single submission, we have decided to follow the implementation of “Key Features” (we are currently discussing the key features for Symbian^3)
The aim is to extract all the good information provided by the package owners and put into a format that facilitates the analysis of the health of the release. Taking a leaf from the Agile book, and introducing a 2-week regular heartbeat for our kits releases and tracking feature increments against it (for regular kit updates click here).
Also, any data beyond 6 months from “today” is displayed in quarters since we need to remain flexible and responsive to change (a “scaling agile” practice). Hence, it is understood that the detailed plan beyond 3 months will be fluid and beyond 6 months is only an indication of intent.
It is probably worth noting at this point that the integration plan is based on voluntary contributions, and that we aim to increase the confidence in it by promoting frequent stage deliveries and asking the contributors to provide regular updates when changes occur.
The above table is a section of the full integration plan for Symbian^3
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.
When faced with the option of buying a car, I considered 2 options:
Shall I buy a new or semi-new one from a dealership. Yes, you do pay a premium for the same car but if it is not quite right I have a guarantee and a large company behind it that will provide support and get it sort it. Or,
Shall I buy it on-line from a private party. With a lager market to choose from (with websites such as autotrader), it would allow me to find a cheaper option and to “fix-it up” to my standards. Also, I can normally check the history of the car and have an accurate guess at what might be wrong with it.
What I never considered is to walk-in into a dealership an be confronted with the following scenario: “You can take this car for free, you can inspected if you want. There is one catch, if it breaks down or you want to change anything you need to come to us to fix it!” Clearly, this never actually happened to me.
Lately there is a trend in open source that make me feel like I am walking into that sort of dealership. As a user of platform software, it is great to have access to the code but it is frustrating not to have influence over how it changes. Continue reading “Less Open Source and More Community Source?”→
One of the areas that we are currently working on is the use of Bugzilla to track and manage the integration of new features into Symbian Platform Releases. I have set-up a few examples of real features in Bugzilla for Symbian^3. Here is how we are proposing to use it:
On the verge of complete egotism with this blog entry.. but really it is all about Symbian, honest. Here are my views on my role and working for the Symbian Foundation.
Victor Tuson Palau 