Calls for more collaboration are quite common, but I can't help but feel that people assume it is easier than it actually is. There is the GMAE effort which tries do achieve exactly what is mentioned here, which is further codesharing between all these efforts.
Whats holding up collaboration is rarely ever ill will or lack of seeing how collaboration is useful. I mean these people choose existing open source technologies just because they could see such benefits. But in reality a lot of issues makes it a slow process, like internal time constraints, disputes about code quality, licensing challenges, disagreement about technology choices and so on. For instance I wouldn't be surprised if OpenMoko face the challenge of needing most of their components to be LGPL/BSD licensed instead of GPL, which puts a lot of code out of their reach. Cause even if the OpenMoko phones will be shipping with all free software there might be further stuff getting integrated downstream for which a demand for GPL licensing would be unacceptable. Like Vodafone or some other network operator putting some branded special software on phones distributed through them as one example. Another good example is that a 'competing' project might have a piece of code which supposedly do what you need, but your engineers when looking at it decides that its coded in a shoddy fashion and thus will risk getting your project bogged down in trying to bugfix it. Or the code is Java based and your platform doesn't ship with Java etc. So please be aware that 'duplication' of effort isn't just because people are stupid or selfcentered, its often happens due slightly different needs or things which can't be easily publicized. So as someone who have been to multiple GMAE meetings I know that people like OpenMoko, Maemo, Sato, Hiker and so on are trying to increase code sharing, but it does take time. Christian > > This is something someone else touched on. If you're writing an application, > abstract all the complicated stuff away from the UI code, then you can make > whatever kind of UI you want. NetworkManager I think is a perfect example of > this. It would be good to have a defined interface to access PIM info, make > calls etc. I believe LiPS has been set up to do just that. So perhaps it > would be better to make moth OpenMoko & Qtopia PE LiPS complient. I heard > that the LiPS forum hired a load of GPE PE developers to develop a reference > implementation. It might be worth looking at GPE PE and lifting some of the > standardised bits. I don't know, perhaps this is happening already? > > One more thing on duplication of effort... It's nice to see OpenHand > developers working on OpenMoko, are there any plans to merge Sato into > OpenMoko? There's currently 4 GTK+ mobile phone frameworks I know of (GPE PE, > Sato, OpenMoko & Hiker). Surely no one can claim that much duplicated effort > is a good thing? I can see the argument for KDE/Gnome, GTK+/QT, but not 4 > projects all relying on the same technology all doing exactly the same thing. > > > _______________________________________________ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community