MeeGo DE - *THAT* is how you do it ....

Over the past several weeks I've been hitting one concept over and over again: "reference".

I'm talking here about the idea of a reference implementation; and I don't mean something so comprehensive that it's almost useless... rather a manageable set of information aimed at easing entry into a project.

I've been accused of being a bit long-winded :) So let me offer a short proposal:

Justify the DE project by extending the "DE Project Vision" to include "Be a reference vendor". Extend the deliverables to include documentation about processes, organisational layout and tool usage. Test, challenge and improve the MeeGo <-> Vendor interface.

I put this to Carsten and Jukka a while ago and they were very positive about it - so if it sounds intriguing then here's my thinking:

MeeGo is (or should be) aimed at vendors. So what is a vendor? Or perhaps, in this context, what aspects of a vendor are we interested in? I think the following three areas are relevant:

• The Veneer ("Value Add Layer" if you're marketing a device)
  
• Hardware Adaptation
  
• Contributing Back (A phb may prefer to hear: "Influencing MeeGo's direction")
  

As a vendor newly arriving at MeeGo I am going to need to work in one or more of these areas - so what do I do? What systems do I need? How do I setup teams, OBS projects? How do they interact with MeeGo? What testing processes should I use? What tools and systems are already available? How do I avoid re-inventing the wheel? How do I link to the core OBS? How do I get a feature included in the core?

Answering these questions correctly is vital if a vendor is to effectively assess the cost of operating in the MeeGo ecosystem; and that assesment should influence their decision to work with MeeGo. Quite simply: the lower we can make barriers to entry, the more vendors will join MeeGo. Not only that; if we can identify and resolve problems with them then that will improve satisfaction. It is also worth remembering that many vendors will be new to working in the open - using the reference project may help to overcome 'shyness' be it cultural or confidentiality based.

This is not just about vendors either. MeeGo as a project has to support the vendor ecosystem - and whilst we do want a diverse community out there, we don't want to support needless variations in process or even terminology. Providing a "suggested way of working" and ensuring that all our tools and processes work with it means that we can minimise the cost of these interactions from MeeGo's point-of-view.

MeeGo also provides interfaces to these vendors - but has no real mechanism for reviewing or testing them (although I'd like to address that in my BoF session at MeeGo 2011). For example

• the handling and communication of significant API changes during development;
  
• simple operational communication;
  
• how are vendor products supported *after* a MeeGo release?
  
• how should vendors operate near releases (forks);
  
• I need a change to a MeeGo component : it's not going to be accepted this release; what do I do?
  

DE operates in all of the layers I mentioned but it's not clear what activity is related to what layers. I'd like to see:

• DE provide some clarity around the three roles: particularly a review of the OBS project structure and role-specific processes.
  
• Clear product-oriented and release-managed deliverables in the veneer layer with testing and automation
  
• Documentation of a requirements driven approach to MeeGo core contributions
  
• Documentation of a requirements driven approach to hardware adaptation
  

Of course the objective of these deliverables is to support new vendors and contributors to DE/MeeGo; not to overburden the contibutors. bearing in mind that

I think the success criteria in this ares would be if any organisation can quickly and easily setup a new initiative to thoroughly evaluate MeeGo for a new product.

There are other areas where we can support vendors by pursuing this model; the use of the MeeGo community OBS mimics the separation between the MeeGo OBS and the vendor's internal OBS. This allow issues dealing with the relationship to MeeGo to be examined openly: what is the recommended link to the core OBS; how are vendors impacted by downtime; what's the best approach to provide a reasonably stable MeeGo base to build the 'veneer layer' on during a sprint whilst still allowing the vendor to be aware of emerging issues in Trunk.

MeeGo also has other system tools: BOSS, REVS, IMG and OTS are freely available and were designed at Nokia using their product building expertise - how can we offer these to the MeeGo vendor ecosystem to once again reduce cost and probably more importantly: time to market. These tools are used in MeeGo core - but they are not documented or discussed (and are probably not relevant to vendors anyway since their business goals are different). Using them in DE allows increased public scrutiny.

So here's another success criteria (for both DE and MeeGo tools): is DE using MeeGo tools to deliver their product? Do the managment reports from REVS provide useful data? Is BOSS automation effective and sufficiently low-overhead? Does OTS work in resource-limited environments?

Finally - you have to ask what the point of the DE project is? I think if it can be held up as an example of "How to work with MeeGo" and has real deliverables beyond supporting an aging device then it provides a tangible benefit to everyone in MeeGo.

A little post-script too : whilst I've focused on DE here this concept applies to a lot of what's done around MeeGo. Opensource succeeds because we stand on the shoulders of midgets - a *lot* of midgets. We should each aim to ensure that when we 'deliver' something to the opensource community we ask "how easy have I made it to let someone else improve on this?"