[maemo-developers] [maemo-developers] Too busy -> abstraction layer and process

[From: Risto Varanka]

Carlos:
>However, as Tommi pointed out, an equality important factor here is that
>our product development processes and infrastructure are not yet fully
>adapted to open platform development. 

Yes, I would assume it could take a decade or more to fully adapt. Especially as there aren't too many success stories in the industry on projects similar to Maemo/770? People just should not underestimate this challenge - I think Nokia  will eventually get there, but there will likely be some hurdles along the road. Ultimately radical organization-level change is required.

As noted, one of the current tasks is to develop a two-way development abstraction layer: on one hand the Nokia developer inside will need to be able to concentrate on developing the software, so the standard software process and infrastructure needs to be in place, but on the other hand also the community developer outside will need to be able to concentrate on developing the software. This can mean various strategies and concrete measures - of which Devesh listed a few already. 

But the key point is that now it must be easy for the 770 enthusiast to start development. This could mean even hand-helding prospective programmers - Maemo is probably still so far away from its golden age as a platform that many developers have time to learn the skills from the ground up (Movial seems to agree, judging by their recent recruiting campaign). Nokia is by no means totally new in supporting developers - they already have the huge Forum Nokia community for Symbian.

The two-way abstraction layer is a two-way learning process. Nokia needs to adapt to the community but also the community needs to adapt to Nokia. Eventually the commercial and the community side would provide highly optimized and tailored services to each other. For example, does available open source have quality issues and does it lack a proper software process? Nokia could help to implement these. For example, there could be some kind of a test stub or an automation suite, which the open source component could be run against, and when a 99% pass level is achieved in the tests it would be sent by the open source developer to Nokia for integration. The test suite could be written by Nokia, even run by Nokia. Or it could be done by the community as well if the community does it better...

Murray:
> I think Nokia needs to assign a dedicated community liaison, full time
> or part time, while still demanding that all developers are involved
> with the community as much as possible. This person would maintain the
> web site, and help the community to maintain it by extracting
> information from Nokia. This person would also do simple patch and bug
> triage and apply obvious changes without bothering the developers with
> trivial stuff.

I think just one community liaison would be a bad idea because it would create the implicit assumption that this person is responsible for handling all the 'community stuff' while everybody else does not need to be bothered. On the other hand forcing all developers to interact with the community might not succeed, on one hand because it is acknowledged that it is good for a developer to concentrate fully on his/her core tasks, on another hand because some developers may find it easier to interact with the community alongside their core tasks while others probably are just so much more productive if they need not think of all the community stuff and other little things for a while.

Based on what I heard on #maemo, Nokia took a bit better route, with more specialized roles for people. For example there is tigert, who helps the developer community in UI related issues, helps maintain the web site, and no doubt extracts information from the other technical people at Nokia. Then there are certain developers who check and filter through submitted patches and are responsible for doing commits into the cvs. I think it is a better solution that a developer dedicated to the component commits the patch, because - at least from a QA person's PoV - there are no trivial patches. In an advanced software product, the defects can be somewhat complicated and even a one-line fix can break something else, and a committer would not know this unless he/she was quite familiar with the part of software in question.

If all these arrangements by Nokia appear to produce little visible effect, there could be several reasons. Approaching deadlines, or not enough work for a given role to recruit a full-time worker, or the person is recently recruited and is yet picking up the pace...

Just my 2 cents as a software process enthusiast and speculation as an outsider to the said process. Overall I'm very happy with how open the Maemo platform is and how much one can actually communicate with Maemo developers inside Nokia. I know from experience that extracting information from a software vendor can be a pain, but in case of Maemo I'm hopeful that any information that does not need to be confidential would eventually be available in one form or another.

Risto Varanka
http://icct.blogspot.com/

...................................................................
Luukku Plus paketilla pääset eroon tila- ja turvallisuusongelmista.
Hanki Luukku Plus ja helpotat elämääsi. http://www.mtv3.fi/luukku