Managing Sakai 2.x Going Forward

There is some recent discussion on the Sakai lists about the role of the maintenance team, product council, and product management w.r.t. Sakai 2.x. I have become increasingly frustrated about how this community treating the Sakai 2.x / Sakai 3.x work.
The thing that frustrates me the most is how there is this notion that somehow we need to alter our approaches to 2.x so as to give Sakai 3.x the greatest benefit and most resources. This is really grating to me every time I hear even the hint of a win-lose conversation about Sakai 2.x and Sakai 3.x.
The real problem in my opinion is that we have single management structures that are trying to “define Sakai”.
The real problem is that when you only have one management structure responsible for two very different efforts – it is very natural to spend some time thinking about trade-offs. And because some schools and individuals are a bit “out on a limb” with Sakai 3.x, I see a tendency for people who see themselves as community leaders conveniently conflating the “community will” with their own local risks and issues.
I understand the pressure that people who have bought into 3.x are feeling – it makes perfect sense – the whole community felt that pressure around 2.x in June 2005. We got through that and we are in a good place now with 2.x. That sense of pressure and feeling of risk is what spurs the right kind of investment. I hope that the stakeholders of 3.x see that the only way to reduce their risk must step up and really contribute resources to 3.x. Believing that somehow risk is reduced by making a “really intricate and clever management structure” is usually a recipe for failure. If folks delegate the “worry” to a management structure – they are usually disappointed. They end up with “someone to blame” but not the result they desired in the first place.
So back to my main concern at hand – “What is the right management structure for 2.x?” My primary answer is “Not the same management structure as 3.x”. I would like to see these separated and allowed to evolve to meet the different needs of their real stakeholders for 2.x and 3.x.
There will be overlap – of course with the transition and there will be plenty of folks who will be involved in both – and over time as 3.x matures – people will shift – and as 3.x matures – its own management structure will naturally adjust to meet the new realities of the problems facing the development team.
—– Here is one of my responses to a message thread about this topic
On Mar 13, 2010, at 4:03 AM, John Norman wrote:
Personally, I see it as a valuable function of the MT to ‘tidy up’ the code base. I am not sure I care when a decision is made so long as (a) it is properly discussed and consulted on and (b) all decisions that affect a release are reviewed at the same time. So I can view this as early opening of the consultation (good) and potentially a process that allows decisions to be reviewed carefully without rushing (also good). So, while I accept Stephen’s point, I think I might advocate that we don’t wait to consider such issues, but we do insist that they be recommendations and if acted upon (e.g. for testing dependencies) they should be reversible until the tool promotion decision point.
It feels like the PM and/or Product Council should be able to help here.
— Chuck Says
As I listen to this, it all simply seems too complex – particularly for Sakai 2.x. Sakai 2.x is a mature and stable open source product with solid rhythm and an annual release. There are about 20 people deeply involved in fixing bugs and moving the product forward and getting releases out. I love the notion of some strategic 2.x code cleanup and would like to see a place where the 20 people that are working on 2.x could coordinate with each other so we don’t open too many construction projects at the same time. Communication and coordination are really valuable and necessary and the folks doing the work will naturally want to talk to each other about this.
It seems like we spend way too much time debating the “purpose and authority” of the PC, PM, and MT. That alone suggests a broken structure.
I would suggest that we move 2.x toward a situation where a single named “group/committee/etc” is where 2.x decisions are made – maintenance, release, everything. Like an Apache PMC for 2.x.
If Sakai 3.x wants layers of management and multiple interlinked committees to guide its progress and a marketing plan etc etc – that is their choice. I don’t personally like that approach to software development and so I can choose not to work on 3.x. If there was a single place that 2.x was discussed – I would probably join that group as I am quite interested in Sakai 2.x for the long-term because I think that many schools will be running Sakai 2.x for the next 7-8 years and so some investment in 2.x will be warranted for some time.
I would like to see us starting to apply different approaches to structuring our 2.x effort and 3.x effort – they are at such different phases in their life-cycles and to attempt to come up with the “one true management structure for all time” – seems to be an impossible task – so perhaps we should just accept the fact that 2.x and 3.x are *different* and separate structures for each and let those structures be controlled by the people in the structures and meet the needs of the people doing the work in each activity.
/Chuck