• Intro
• Downloads
• Community
• Development
• News
• TALK

Talk:Task:Open Source Proof Points

Actually doable?

Are there any examples where open Maemo components have helped drive the platform forward? The App Manager is open source, but who's going to get up to speed on hacking on it and submit patches upstream when:

• There's no patch policy.
• There's no clear direction (until the summit) as to what the future plans of the platform are, let alone this one small part of it.

Some people have done small hacks (disable the irritating Nokia-Legal-enforced "warning" when installing packages) and published them on ITT, but real open source contributions happen when it's collaboration. Code can be open sourced - and thrown over the wall - but without open development, the real successes are yet to be seen. --Jaffa 21:02, 30 September 2008 (UTC)

I basically agree with you - I'm happy collecting objective proofpoints of failure if you wish (seriously). Task:Mapping_openness was a first step needed as a foundation, but once that it is in a maneagable state we need to get serious into the 2010_Agenda where collaboration is at the center point of all the objectives. "Review the Maemo contribution guidelines" needs to be recovered from Maemo.org_proposals and be put in the backlog, although Nokia is doing steps forwards working on a common policy for all its open source projects, including Maemo, Qt and the many tiny Linux projects around. Task:Maemo_public_roadmapping_process also needs to be in place, as well, as an open development process and setup for Maemo open source projects lead by Nokia. Still, I think some progress has been done and I hope we can extract proofpoints already, even if not as strong as you would wish. Note that these proofpoints help us getting approval and resources for next steps... Or better said, the lack of proofpoints won't help us working more and better with open source and in the open.--qgil 05:26, 7 October 2008 (UTC)

There is a clear counter-argument. Without open source end-user application development there'd be no Firefox, there'd be no Evolution; so there'd be no Gecko, no Camel (and so no libtinymail). So, there'd be no microb and no modest. Nokia's "differentiation" argument is built-on the shoulders of giants. Open source UIs - in general - aren't great, with high profile exceptions. However, in the versions of Maemo to-date, I don't see the benefits of this differentation. All it does is prevent community solutions to "popular" problems (I won't mention 12/24 hour clock again; oops, too late ;-)). From what we've seen and heard of Fremantle, this differentiation could finally appear (as a user, I hope so). --Jaffa 21:11, 30 September 2008 (UTC)

Turning the omelette, you are proving that there are indeed proofpoints, like microb and modest. :) Nokia has invested significant resources, directly or indirectly, pushing the development of the underlying technologies and contributing to the related community projects you are mentioning. Nokia wouldn't have the browser and email client Maemo is shipping now, but those community projects wouldn't probably be where they are now without those contributions. About differentiation, I agree the "benefits" are not clear at the moment. As you see we are cleaning a bit the house, opening some components while defining better the areas where Nokia decides to go on its own. Fremantle is seeing significant changes and I'd like to think that the picture will be clear and solid in Harmattan. Everybody agrees that there is nothing more pointless that a differentiation that doesn't differentiate  ;) but I think Nokia is correcting and updating the picture with a consistent strategy (you may or may not agree with).--qgil 05:35, 7 October 2008 (UTC)

Ports section

I tried to clean this section up, but there's so much wrong here that it might be better to remove it altogether. It's fine if there will be no decisions made using the info here, but I fear someone with little knowledge except this section might use it to make an important decision. That would be bad. --qole 05:58, 31 March 2009 (UTC)