So, I think it's about time for me to really weigh in why it is I'm pushing MeeGo on N900 and why this is the right direction. This is probably going to be a bit long. Some people asked me to repost it on my blog as to not have it lost in the maelstrom of talk.maemo.org.
This is also probably my last long post on the matter as I'm now fully in a MeeGo role, no longer maemo.org distmaster.
The fact is that the model of 770 -> N800 -> N810 -> N900 has been that of one device per OS version. There hasn't been resources for keeping a full product team for multiple devices at a time.
This has caused what some describe as Rapid Obsolescence Syndrome, where the device OS rapidly goes into maintenance mode after device release while mostly everyone involved moves on to the next product/device. This obviously leaves users unhappy.
Now, there are multiple suggestions around maemo.org:
* Fremantle community SSU
* Petition for open sourcing most of Fremantle to keep it maintained
* Harmattan HE for N900
(etc)
And my main point in the following is that those directions will be like pissing your pants to keep yourself warm. Quick review:
Community SSU can work on the open source parts (it has happened on N8x0 just fine). Maybe you can find some ability together with Fremantle aficionados inside Nokia who could be interested in contributing with upgrades of some binary packages -
I doubt there's any problem if those exist to slip some packages out.
But the main point is: no upstream work will really happen. I highly doubt you can find enough people that are still around to keep things working. Even with documentation, the code can be quite hairy to add new features to. So that bends down to a resourcing problem.
Open sourcing most of Fremantle - I simply don't think it's going to happen. Too much work for too little benefit. And the same problems as with normal SSU when the code does arrive.
Harmattan HE. This would already be obsolete by the time we were done as a more modern platform would be available in MeeGo. As well as at some point, no more upstream development.
The main point - you'll piss your pants with these projects to keep yourself warm for a while, but you'll just keep on feeding the Rapid Obsolescence Syndrome to some extent - that you'll never be able to play catch-up to new technologies and satisfy the requirements of your users. It is a physical impossibility as there's many more man-hours poured into MeeGo than you can provide here.
MeeGo and Qt has changed the status quo that existed that:
* Any Linux-based OS platform from Nokia is tied to a certain device
* Any applications from Nokia is tied to a certain device by fact that they were released for a certain OS platform.
It's a game-changer because now, for any given 'Nokia' OS for these devices, this will after Harmattan be based off MeeGo (platform from MeeGo.com).
Now, what are we actually doing in MeeGo for N900?
First off - we're making the hardware adaptation for N900 maintainable.
This means that we are actively upstreaming N900 drivers to the mainline Linux kernel as well as getting those few blobs we have into the MeeGo non-oss repositories with redistributable license. This is actively happening.
Second, we're running QA daily to make sure that N900 still works with the current MeeGo platform state. This means we're always at the front of the platform development. MeeGo platform doesn't move forward if a change breaks N900 - it is a reference device
That's not pissing your pants to keep warm. That's making a bonfire and collecting wood to make us sustainably warm. And that's one of the reasons why I hope for more people to contribute to the MeeGo effort.
Now for the users. Look forward a bit - Nokia's obviously going to make a OS release based on 'real' MeeGo.com. The same code that'll power future handsets will be based on the same code that N900 already now supports. It's the same infrastructure that builds images and software that MeeGo for N900 is made using, as any given future Nokia OS. Instead of Nokia having applications tied to Fremantle or to Diablo or whatever, they now tie to MeeGo - the same platform you have on your N900.
If you want to make a real bonfire and eat your cake too, you will want to do the following:
* Contribute to MeeGo and MeeGo on N900 in the short term - this will improve matters for Nokia N900 obviously.
* Petition for Nokia early on, to consider providing the following things:
** Executive summary: access to the binaries making up the Nokia differentiation
** Weekly (or other interval) repository releases (binaries) available to Nokia N900 users of their future MeeGo.com-based OS under the usual 'this is not for end-users, bla bla'. Kinda like the old 'Sardine'
** Kickstart files for these weekly releases so you can edit them into your own images for the N900 using the Nokia bits.
** Community can be possibly be more involved in the QA process this way and contribute in general.
** If branding is a problem, have community themes and icons.
** Suggest new ways to have both a 'closed' vendor OS with all the goodies based on MeeGo.com while at same time having your power user community close to you.
Now, this is a way that can keep you ahead of the curve regarding your device. The N900 hardware isn't going obsolete for many years and is still very capable.
I think this might be possible to pull off, but it requires people to start gaining skills within MeeGo - and help contribute to MeeGo on N900. It's a similar approach to Harmattan HE, but more involved and more future proof. So I wouldn't say it's impossible.
So - it's your choice: Live in the future instead of the past.
I'll be working to make the future happen - see you on http://www.meego.com (and http://wiki.meego.com/ARM/N900 ).
Tuesday, August 17, 2010
Thursday, May 20, 2010
First instance of 'What have I done for the N8x0's lately'
So, this is a new series of blog series on what I've done for the N8x0's lately. So people better see what I've actually tried to do for the owners of these devices.
* I've spent a lot of time with the MBX 3d driver to try to get it in good shape and set up gitorious repo for it and forward ported it to 2.6.33. At the current stage,
* Started a page for the MeeGo N8x0 hardware adaptation team and added plans/milestones
* Working on stabilising MeeGo N8x0 startup, building Xomap for it. I have it running with Xfce4 on my device and hope to show it after 1.0 release.
* Worked with tmr to try and get DSP working on 2.6.33 for N8x0. He forward ported the patches himself.
These are fairly technical things, but should hopefully manifest in actual benefits sooner or later.
* I've spent a lot of time with the MBX 3d driver to try to get it in good shape and set up gitorious repo for it and forward ported it to 2.6.33. At the current stage,
* Started a page for the MeeGo N8x0 hardware adaptation team and added plans/milestones
* Working on stabilising MeeGo N8x0 startup, building Xomap for it. I have it running with Xfce4 on my device and hope to show it after 1.0 release.
* Worked with tmr to try and get DSP working on 2.6.33 for N8x0. He forward ported the patches himself.
These are fairly technical things, but should hopefully manifest in actual benefits sooner or later.
Saturday, February 20, 2010
Maemo 6 and/or MeeGo on N900: Or How I Learned to Stop Worrying and Love the Bomb
Since some people don't follow talk.maemo.org, this is to let them know I wrote a quite interesting piece to help calm some of the worries people have been having about N900 future with Maemo6 and MeeGo based on my previous experiences both as community member and as maemo.org distmaster.
You can read it at http://talk.maemo.org/showthread.php?t=45213 and it is very well received so far and covers four questions we should be asking instead of panicking.
You can read it at http://talk.maemo.org/showthread.php?t=45213 and it is very well received so far and covers four questions we should be asking instead of panicking.
Friday, February 19, 2010
The Mer Project - just a bunch of redshirts?
Recently, big news arrived: The MeeGo project. But let me start with some history. In May 2009 some key members of the Mer project met up for the first time 'in real life' at the Mozilla Maemo Danish Weekend. At this event, we got some very characteristic t-shirts - very very red ones, which we since have worn proudly when we were meeting up again at various events and countries, as we could recognise each other.
While we were introduced as Maemo 5 community edition for the Nokia N810/N800/770 Internet Tablets we were far more ambitious - we loved the principle of Maemo so much that we wanted to reconstruct it, in order to make it better, more suitable for the future - because we thought the platform would not survive otherwise.
We wanted to get away from the notion that a tablet was an embedded system - Tablets are not under-powered embedded systems, they are powerful, power-efficient, economical handheld computers. We wanted to make Maemo a general platform for tablet devices. We wanted to Make it more developer-friendly. More hackable. Align with standard Linux distributions. This was to be done by separating the device and platform code - have open development of the Maemo platform - the device-specific and vendor-specific differentiation
development can be closed and many other things.
The goal was for the core Mer system is fully open source and cross-platform, open for anyone to adapt to their devices. We got far, we have something that works, but it isn't ready for users yet - Mer was a research project to try and help Maemo towards our goals.
A comment (as I recall it) from Maemo Summit 2009, where we Mer members met up again, performed several presentations - again, wearing our red shirts - "We're just a bunch of redshirts.", ambitious ensigns in red shirts - did this come true?
Some background, as it might be a bit geeky. Quoting wikipedia:
Redshirt is a slang term for a minor stock character of an adventure drama who dies violently soon after being introduced in order to dramatize the dangerous situation experienced by the main characters. The term originated with fans of the science fiction television series Star Trek, from the red shirts worn by Starfleet security officers and engineers, who frequently meet their demise during the episodes.
Fast-forwarding to this week, when the MeeGo announcement broke. Reading the pages, many things seemed familiar:
From Quim Gil: MeeGo is just like you would expect a free Linux OS to be: based on the standard Linux and Free Desktop technologies and developed publicly in a project open to all contributors
From architecture page of MeeGo:
The MeeGo OS Base layer contains the Linux kernel and core services along with the Hardware Adaptation Software required to adapt MeeGo to support various hardware architectures.
The MeeGo OS Middleware layer provides a hardware and usage model independent API for building both native applications and web run time applications.
From governance:
We showed it was possible to develop for your mobile device just as easily as developing for your desktop PC. That we didn't need Scratchbox: We began every interesting experiments with OBS (Open Build Service), where our build guy - David Greaves (lbt) made some extremely nice experiments, showing that cross-compilation could work without hassle, even for packages normally requiring native compilation. He's BTW, having a day job working with MeeGo and OBS now - helping to bring the Mer development experience into MeeGo.
Power saving and distribution alignment
Showing that it was possible to retain power saving while making porting easy by having easy access to Debian (or any distro's) huge library collection.
That the community was capable of organising OS development too
That multiple device communities could work together on a common base that would benefit them all.
That we were able to help create policy, identify problems
Some of the things coming out of Mer:
The vendor social contract - a social contract for vendors to commit to, in order to have community spending time on them and not waste their time and end up with locked devices with a open system.
Token based access restriction - a way to deal with closed sourced binaries in a open system in a way that is liveable both technically and legally.
Why an upstream basis shouldn't be a goal, but a policy alignment on mobile devices
Immediate involvement of contributors interested, that any contribution is valuable and the list goes on..
So, are we out of the plot now that the main characters have stepped in? No. My experience has been that this is a new house for us to paint and move into. A fresh start - it would first have happened in many years at the pace we were going.
The developers I've met from the Moblin side has been very open, willing to discuss - and even spoken with one of the two top guys in MeeGo. Us redshirts fit in the MeeGo project because we have experience enough now to discuss and argue on equal footing and to help to shape the future - and to create it. Like we always wanted.
For those wanting to pursue the dream (and reality now) of a open mobile Maemo platform - MeeGo is the place and that's where I (and hopefully my fellow redshirts) will go to contribute to the future of mobile Linux.
So, what will happen to Mer? We'll still be a subsection of the MeeGo community arguing for our positions, our ideas, our hopes and helping out where we can. Best way to shape the future is by participating.
Mer as a system will live on in Mer^2. A quick summary is it is a Debian 5.0 system building inside OBS with tricks making it feel like a Scratchbox for the packages, which makes most of the Fremantle platform build on it. It will work on X86 and on N8x0. Mer 0.17 will be imaged up soon and published - those who want to continue with that can. The goal is not to make a fully open source system - it will serve purpose to be a foundation on which to build a backport of Fremantle for N8x0. The hope is to be able to build most of closed things for Fremantle for N8x0 using this.
Thanks for reading. This is a bit of post-mortem for the ambitious part of Mer. Which keeps on living in the MeeGo project. This blog will be mostly devoted to Mer^2 discussions and maemo.org distmaster related issues. A role which I am yet to figure out how fits in the MeeGo community - but I'm hopeful.
While we were introduced as Maemo 5 community edition for the Nokia N810/N800/770 Internet Tablets we were far more ambitious - we loved the principle of Maemo so much that we wanted to reconstruct it, in order to make it better, more suitable for the future - because we thought the platform would not survive otherwise.
We wanted to get away from the notion that a tablet was an embedded system - Tablets are not under-powered embedded systems, they are powerful, power-efficient, economical handheld computers. We wanted to make Maemo a general platform for tablet devices. We wanted to Make it more developer-friendly. More hackable. Align with standard Linux distributions. This was to be done by separating the device and platform code - have open development of the Maemo platform - the device-specific and vendor-specific differentiation
development can be closed and many other things.
The goal was for the core Mer system is fully open source and cross-platform, open for anyone to adapt to their devices. We got far, we have something that works, but it isn't ready for users yet - Mer was a research project to try and help Maemo towards our goals.
A comment (as I recall it) from Maemo Summit 2009, where we Mer members met up again, performed several presentations - again, wearing our red shirts - "We're just a bunch of redshirts.", ambitious ensigns in red shirts - did this come true?
Some background, as it might be a bit geeky. Quoting wikipedia:
Redshirt is a slang term for a minor stock character of an adventure drama who dies violently soon after being introduced in order to dramatize the dangerous situation experienced by the main characters. The term originated with fans of the science fiction television series Star Trek, from the red shirts worn by Starfleet security officers and engineers, who frequently meet their demise during the episodes.
Fast-forwarding to this week, when the MeeGo announcement broke. Reading the pages, many things seemed familiar:
From Quim Gil: MeeGo is just like you would expect a free Linux OS to be: based on the standard Linux and Free Desktop technologies and developed publicly in a project open to all contributors
From architecture page of MeeGo:
The MeeGo OS Base layer contains the Linux kernel and core services along with the Hardware Adaptation Software required to adapt MeeGo to support various hardware architectures.
The MeeGo OS Middleware layer provides a hardware and usage model independent API for building both native applications and web run time applications.
From governance:
There is no admission process or membership fee for MeeGo; just your desire to join the project and contribute.
Any individual or organization can join and get involved in software development. We also welcome other ways of contributing to the success of the project, including writing documentation, testing, and marketing.
And so on - it was like someone had listened to our ideas and wishes..
Basically, MeeGo was what we hoped to achieve with Mer, and it's silly to continue separately instead of collaborating. Now, with the announcement - is the Mer project members then just a bunch of redshirts who helped move the plot along but in the end, is out of the game when the main characters continue with the plot?
No. I don't think so. In Mer, we managed to accomplish many interesting things:
Easy development for mobile devicesWe showed it was possible to develop for your mobile device just as easily as developing for your desktop PC. That we didn't need Scratchbox: We began every interesting experiments with OBS (Open Build Service), where our build guy - David Greaves (lbt) made some extremely nice experiments, showing that cross-compilation could work without hassle, even for packages normally requiring native compilation. He's BTW, having a day job working with MeeGo and OBS now - helping to bring the Mer development experience into MeeGo.
Power saving and distribution alignment
Showing that it was possible to retain power saving while making porting easy by having easy access to Debian (or any distro's) huge library collection.
That the community was capable of organising OS development too
That multiple device communities could work together on a common base that would benefit them all.
That we were able to help create policy, identify problems
Some of the things coming out of Mer:
The vendor social contract - a social contract for vendors to commit to, in order to have community spending time on them and not waste their time and end up with locked devices with a open system.
Token based access restriction - a way to deal with closed sourced binaries in a open system in a way that is liveable both technically and legally.
Why an upstream basis shouldn't be a goal, but a policy alignment on mobile devices
Immediate involvement of contributors interested, that any contribution is valuable and the list goes on..
So, are we out of the plot now that the main characters have stepped in? No. My experience has been that this is a new house for us to paint and move into. A fresh start - it would first have happened in many years at the pace we were going.
The developers I've met from the Moblin side has been very open, willing to discuss - and even spoken with one of the two top guys in MeeGo. Us redshirts fit in the MeeGo project because we have experience enough now to discuss and argue on equal footing and to help to shape the future - and to create it. Like we always wanted.
For those wanting to pursue the dream (and reality now) of a open mobile Maemo platform - MeeGo is the place and that's where I (and hopefully my fellow redshirts) will go to contribute to the future of mobile Linux.
So, what will happen to Mer? We'll still be a subsection of the MeeGo community arguing for our positions, our ideas, our hopes and helping out where we can. Best way to shape the future is by participating.
Mer as a system will live on in Mer^2. A quick summary is it is a Debian 5.0 system building inside OBS with tricks making it feel like a Scratchbox for the packages, which makes most of the Fremantle platform build on it. It will work on X86 and on N8x0. Mer 0.17 will be imaged up soon and published - those who want to continue with that can. The goal is not to make a fully open source system - it will serve purpose to be a foundation on which to build a backport of Fremantle for N8x0. The hope is to be able to build most of closed things for Fremantle for N8x0 using this.
Thanks for reading. This is a bit of post-mortem for the ambitious part of Mer. Which keeps on living in the MeeGo project. This blog will be mostly devoted to Mer^2 discussions and maemo.org distmaster related issues. A role which I am yet to figure out how fits in the MeeGo community - but I'm hopeful.
Wednesday, February 17, 2010
MBX/3D drivers out for N8x0 (and other OMAP2)
In other news, the drivers was uploaded to TI extranet yesterday - this is something people have waited for, for a long time. And you need to create a TI (my.ti.com) account for this. For those who want to have access the SDK need to send a mail to gamingonomap@list.ti.com stating your need for the SDK mentioned below.
You need to then click "Extranets" on my.ti.com and then WTBU-OMAP Gaming SDK and then OpenGL®ES Graphics SDK for OMAP2420 Nokia N800 OpenGL ES v1.1 and OpenVG 1.0 SDK based on Linux kernel 2.6.21
A fair warning: These drivers are not for the weak at heart. You need to flash a new kernel. You may need to fix up some build scripts and run some mysterious commands. They will not work that easily out of box.
While I kinda assume this will be drowned out in Meego announcements and discussion, well, I got the mail last night
Thanks to qwerty12, javispedro, lardman, the TI guys (Girish, Ameet) and the Nokians helping out to make this reality and others.
You need to then click "Extranets" on my.ti.com and then WTBU-OMAP Gaming SDK and then OpenGL®ES Graphics SDK for OMAP2420 Nokia N800 OpenGL ES v1.1 and OpenVG 1.0 SDK based on Linux kernel 2.6.21
A fair warning: These drivers are not for the weak at heart. You need to flash a new kernel. You may need to fix up some build scripts and run some mysterious commands. They will not work that easily out of box.
While I kinda assume this will be drowned out in Meego announcements and discussion, well, I got the mail last night
Thanks to qwerty12, javispedro, lardman, the TI guys (Girish, Ameet) and the Nokians helping out to make this reality and others.
Wednesday, February 10, 2010
Mapping openness of Maemo 5.0 PR1.1 and Maemo 4.1.2 - we're moving in the right direction!
One of the tasks I've been doing in the last couple of months has been to try and refresh the openness data for Fremantle. This has actually been quite a challenge as I've had to retrieve a lot of different sources to make a proper description of what is actually open and what is not.
The openness reports
For Fremantle PR1.1, you can find the openness report here - this is for a PR1.1 image actually installed on a device.
As per request and for comparison, I've also generated one for Maemo 4.1.2 (Diablo)
It has been difficult finding categorisation for Diablo so a lot of it is in 'Other' as I used the package categorisation from Fremantle in this.
This is supposed to be raw data for further discussion and as such there'll be subsequent analysis on top of this, explaining some of the areas and why things are as they are. Please read through this blog post for further explanation of what the data represents and how it is represented.
This openness report has the purpose of:
The purpose is not:
Classification of packages
So, to start describing what these openness reports contain. I have chosen to classify source packages into seven levels - this will also explain the headers of the table.
L1: Developed openly, no closed source dependancies
This means that the source package is developed either in garage.maemo.org, maemo.gitorious.org or some other place. This means that you can follow development and contribute patches to it, without having to wait for new releases
L2: Source published in SDK, no closed source dependancies
This means the source package is published in SDK releases. This means that you usually have to wait for a new SDK release to get updates to this package and there's no clear way to submit patches beyond bugtracker
L3: Developed openly, closed source dependancies
This means that the source package is developed either in garage.maemo.org, maemo.gitorious.org or some other place. This means that you can follow development and contribute patches to it, without having to wait for new releases
However, this is usually important for system integrators and porters of Maemo, this package depends on a closed source package to build or run. Which means it is difficult to take the package and use it outside Maemo.
L4: Source published in SDK, closed source dependancies
This means the source package is published in SDK releases. This means that you usually have to wait for a new SDK release to get updates to this package and there's no clear way to submit patches beyond bugtracker
However, this is usually important for system integrators and porters of Maemo, this package depends on a closed source package to build or run. Which means it is difficult to take the package and use it outside Maemo.
Total L1-L4:
This is the percentage that is open source in this particular component. It is red if it's below 80%
L5: Binary-only package published in SDK. Source may exist but may be non-free
This means the package is published in SDK, but may be non-free and hence not possible to use outside Maemo.
L6: Package published under EULA in nokia-binaries
This means the package is published as binary-only in nokia-binaries, which you can get under EULA at http://tablets-dev.nokia.com/eula
L7: Not published except on device and SSU repositories
This package is only published in SSU repositories and as such you cannot get to it without a device.
In each component area, for each level, there is a percentage and a number. This is percentage of components in this area that is in this level and how many source packages. If you click it, you will see the packages from that component area in that level.
If you click this, you will see information about the package, it's level, where it is openly developed if so, where you can retrieve it, etc.
Key numbers
Along with the openness report, there's a few key numbers, which are completely unweighed regarding lines of code, importance, etc.
Total L1+L3 compared to L1-L4:
This is how many % of the open source packages of Maemo that is actually developed openly on maemo.gitorious.org, garage, etc.
Total L1-L4:
This is how many % source packages of the image which is open source
Total L5-L7
This is how many % source packages of the image which is closed source
Total L1-L4 compared to L1-L6
This is how many % of the published source packages that are open source.
The future of openness reports
The idea is to publish these openness reports quite often, as to keep a understanding on the direction we're going in. I plan to do one every PR release for Fremantle and when Harmattan SDKs starts appearing, doing the same. I plan to shine up the CSS a bit as well as it's not the prettiest currently.
I will very soon start maintaining a open sourcing queue and the hope is to release as many L3-L4 packages as possible to become L1 and L2 packages. And L4 and L2 packages turning into L1 and L3 packages.
Please comment any changes or ideas for future improvements, or questions. If there's components that are openly developed that are not represented, let me know as well. I'm 'Stskeeps' on #maemo and feel free to come and discuss with me there.
The openness reports
For Fremantle PR1.1, you can find the openness report here - this is for a PR1.1 image actually installed on a device.
As per request and for comparison, I've also generated one for Maemo 4.1.2 (Diablo)
It has been difficult finding categorisation for Diablo so a lot of it is in 'Other' as I used the package categorisation from Fremantle in this.
This is supposed to be raw data for further discussion and as such there'll be subsequent analysis on top of this, explaining some of the areas and why things are as they are. Please read through this blog post for further explanation of what the data represents and how it is represented.
This openness report has the purpose of:
- Giving exact information of what is open, what is not, if it's openly developed
- Help prioritise what should be opened and in which order
- Help giving arguments towards why things should be opened
- Help new developers find out where components are developed
- Help making Maemo more open
- To aid open sourcing discussion where we go to the technical heart of a problem, not the ideological one and save all of us precious time that could be used to open source things.
- Get information about what components may not be so interesting as to open source and what is kept closed source in those component areas and help to give an understanding of why it is so.
The purpose is not:
- To be a fight over numbers and percentages of openness
- To be a discussion over open sourcing policies (what Nokia chooses to open source and what not)
Classification of packages
So, to start describing what these openness reports contain. I have chosen to classify source packages into seven levels - this will also explain the headers of the table.
L1: Developed openly, no closed source dependancies
This means that the source package is developed either in garage.maemo.org, maemo.gitorious.org or some other place. This means that you can follow development and contribute patches to it, without having to wait for new releases
L2: Source published in SDK, no closed source dependancies
This means the source package is published in SDK releases. This means that you usually have to wait for a new SDK release to get updates to this package and there's no clear way to submit patches beyond bugtracker
L3: Developed openly, closed source dependancies
This means that the source package is developed either in garage.maemo.org, maemo.gitorious.org or some other place. This means that you can follow development and contribute patches to it, without having to wait for new releases
However, this is usually important for system integrators and porters of Maemo, this package depends on a closed source package to build or run. Which means it is difficult to take the package and use it outside Maemo.
L4: Source published in SDK, closed source dependancies
This means the source package is published in SDK releases. This means that you usually have to wait for a new SDK release to get updates to this package and there's no clear way to submit patches beyond bugtracker
However, this is usually important for system integrators and porters of Maemo, this package depends on a closed source package to build or run. Which means it is difficult to take the package and use it outside Maemo.
Total L1-L4:
This is the percentage that is open source in this particular component. It is red if it's below 80%
L5: Binary-only package published in SDK. Source may exist but may be non-free
This means the package is published in SDK, but may be non-free and hence not possible to use outside Maemo.
L6: Package published under EULA in nokia-binaries
This means the package is published as binary-only in nokia-binaries, which you can get under EULA at http://tablets-dev.nokia.com/eula
L7: Not published except on device and SSU repositories
This package is only published in SSU repositories and as such you cannot get to it without a device.
In each component area, for each level, there is a percentage and a number. This is percentage of components in this area that is in this level and how many source packages. If you click it, you will see the packages from that component area in that level.
If you click this, you will see information about the package, it's level, where it is openly developed if so, where you can retrieve it, etc.
Key numbers
Along with the openness report, there's a few key numbers, which are completely unweighed regarding lines of code, importance, etc.
Total L1+L3 compared to L1-L4:
This is how many % of the open source packages of Maemo that is actually developed openly on maemo.gitorious.org, garage, etc.
Total L1-L4:
This is how many % source packages of the image which is open source
Total L5-L7
This is how many % source packages of the image which is closed source
Total L1-L4 compared to L1-L6
This is how many % of the published source packages that are open source.
The future of openness reports
The idea is to publish these openness reports quite often, as to keep a understanding on the direction we're going in. I plan to do one every PR release for Fremantle and when Harmattan SDKs starts appearing, doing the same. I plan to shine up the CSS a bit as well as it's not the prettiest currently.
I will very soon start maintaining a open sourcing queue and the hope is to release as many L3-L4 packages as possible to become L1 and L2 packages. And L4 and L2 packages turning into L1 and L3 packages.
Please comment any changes or ideas for future improvements, or questions. If there's components that are openly developed that are not represented, let me know as well. I'm 'Stskeeps' on #maemo and feel free to come and discuss with me there.
Tuesday, January 19, 2010
Dual-booting Mer on Nokia N900
As of Mer 0.17testing10 we have an image that is fairly easy to try out on Nokia N900. This guide is for advanced users and there is NO WARRANTY. It might turn your N900 back into the crazy guy from this video or chew out your microSD, so be careful.
You will need:
* A microSD
* A SD/microSD card reader for your PC
* A Linux installation on your PC.
* A copy of a Mer rootfs for N900 (0.17testing10)
* A copy of the files in your /lib/firmware from your N900. This includes WiFi and Bluetooth firmware.
* PR1.0, PR1.0.1 or PR1.1 on your N900
* That you have installed fanoush's bootmenu (dpkg -i it and run 'Install bootmenu' application icon)
Instructions (must all be done as root):
* Partition your microSD to first partition being Linux and format it as ext3 using mkfs.ext3.
* Mount the ext3 partition on your PC, let's say in /mnt/mer.
* Make sure using 'mount' that your ext3 partition is -not- mounted 'nosuid' or 'nodev'
* cd /mnt/mer
* tar --numeric-owner -pzxf /full/path/to/mer-armel-n900-rootfs-v0.17testing10.tar.gz
* cd lib/firmware
* cp in the files from /lib/firmware from your N900
* umount /mnt/mer
* Make a file "mer.item" in /etc/bootmenu.d on your N900, containing:
ITEM_NAME="Mer (external SD, partition 1)"
ITEM_ID="mer"
ITEM_DEVICE="${EXT_CARD}p1"
ITEM_MODULES="mbcache jbd ext3"
ITEM_FSTYPE="ext3"
ITEM_FSOPTIONS="noatime,ro"
* Reboot your device, have the keyboard slid out. A bootmenu will appear where you can select Mer with the cursor keys.
* Mer booting.. wait for touchscreen calibration step
* And then you can run through the first boot wizard
* And a non-accelerated Mer desktop appears.
What works:
* WiFi
* Touchscreen
* Charging
* Watchdog handling
Of closed source blobs used in Mer (for N900):
* DSME (open source) with libcal (closed source) running from the Maemo5.0 rootfs
* BME running from the Maemo5.0 rootfs
* Firmware files for WiFi and Bluetooth chip amongst others.
Either way, I hope you enjoy playing with an alternative OS on your N900. Feel free to report bugs at http://wiki.maemo.org/Mer/Releases/0.17 and talk to us on #mer on irc.freenode.net if you'd like to contribute to Mer.
To shut down Mer, either sudo reboot or pop the battery.
You will need:
* A microSD
* A SD/microSD card reader for your PC
* A Linux installation on your PC.
* A copy of a Mer rootfs for N900 (0.17testing10)
* A copy of the files in your /lib/firmware from your N900. This includes WiFi and Bluetooth firmware.
* PR1.0, PR1.0.1 or PR1.1 on your N900
* That you have installed fanoush's bootmenu (dpkg -i it and run 'Install bootmenu' application icon)
Instructions (must all be done as root):
* Partition your microSD to first partition being Linux and format it as ext3 using mkfs.ext3.
* Mount the ext3 partition on your PC, let's say in /mnt/mer.
* Make sure using 'mount' that your ext3 partition is -not- mounted 'nosuid' or 'nodev'
* cd /mnt/mer
* tar --numeric-owner -pzxf /full/path/to/mer-armel-n900-rootfs-v0.17testing10.tar.gz
* cd lib/firmware
* cp in the files from /lib/firmware from your N900
* umount /mnt/mer
* Make a file "mer.item" in /etc/bootmenu.d on your N900, containing:
ITEM_NAME="Mer (external SD, partition 1)"
ITEM_ID="mer"
ITEM_DEVICE="${EXT_CARD}p1"
ITEM_MODULES="mbcache jbd ext3"
ITEM_FSTYPE="ext3"
ITEM_FSOPTIONS="noatime,ro"
* Reboot your device, have the keyboard slid out. A bootmenu will appear where you can select Mer with the cursor keys.
* Mer booting.. wait for touchscreen calibration step
* And then you can run through the first boot wizard
* And a non-accelerated Mer desktop appears.
What works:
* WiFi
* Touchscreen
* Charging
* Watchdog handling
Of closed source blobs used in Mer (for N900):
* DSME (open source) with libcal (closed source) running from the Maemo5.0 rootfs
* BME running from the Maemo5.0 rootfs
* Firmware files for WiFi and Bluetooth chip amongst others.
Either way, I hope you enjoy playing with an alternative OS on your N900. Feel free to report bugs at http://wiki.maemo.org/Mer/Releases/0.17 and talk to us on #mer on irc.freenode.net if you'd like to contribute to Mer.
To shut down Mer, either sudo reboot or pop the battery.
Friday, January 15, 2010
Making flashable rootfs's for the N900
For the N8x0 the way to create flashable rootfs's - that is, rootfs's usable in flasher-3.5 -r rootfs.jffs2 -f -R was through these two steps:
mkfs.jffs2 -d $ROOTFS_DIRECTORY -l -n -e 128KiB
-o rootfs.jffs2.raw
sumtool -l -n -e 128KiB -o rootfs.jffs2 -i rootfs.jffs2.raw
Now that the N900 uses ubifs for rootfs instead, how do you do create a flashable rootfs?
You need to make a file, ubinize.cfg:
[ubifs]
mode="ubi"
image="/full/path/to/base.ubi.img"
vol_id="0"
vol_size="200MiB"
vol_type="dynamic"
vol_name="rootfs"
vol_alignment="1"
vol_flags="autoresize"
Then, you run these two commands - you have to grab mtd-utils - Ubuntu Karmic has mtd-utils with ubifs support.
mkfs.ubifs -m 2048 -e 129024 -c 2047 -R 4MiB -r $ROOTFS_DIRECTORY -v /full/path/to/base.ubi.img
ubinize -o /full/path/to/ubi.img ubinize.cfg -m 2048 -p 128KiB -s 512
You can now run flasher-3.5 -r ubi.img -f -R.
What can this information be used for?
* Generate a full snapshot of your NAND rootfs and restore it with flasher after trying out something stupid that failed.
* Flash alternative OS'es onto your N900 NAND.
* Possibilities in rescue menu as in my previous post about bootmenu.sh hook - dump my rootfs to SD and I'll fix it on my PC and reflash it back to my N900.
mkfs.jffs2 -d $ROOTFS_DIRECTORY -l -n -e 128KiB
-o rootfs.jffs2.raw
sumtool -l -n -e 128KiB -o rootfs.jffs2 -i rootfs.jffs2.raw
Now that the N900 uses ubifs for rootfs instead, how do you do create a flashable rootfs?
You need to make a file, ubinize.cfg:
[ubifs]
mode="ubi"
image="/full/path/to/base.ubi.img"
vol_id="0"
vol_size="200MiB"
vol_type="dynamic"
vol_name="rootfs"
vol_alignment="1"
vol_flags="autoresize"
Then, you run these two commands - you have to grab mtd-utils - Ubuntu Karmic has mtd-utils with ubifs support.
mkfs.ubifs -m 2048 -e 129024 -c 2047 -R 4MiB -r $ROOTFS_DIRECTORY -v /full/path/to/base.ubi.img
ubinize -o /full/path/to/ubi.img ubinize.cfg -m 2048 -p 128KiB -s 512
You can now run flasher-3.5 -r ubi.img -f -R.
What can this information be used for?
* Generate a full snapshot of your NAND rootfs and restore it with flasher after trying out something stupid that failed.
* Flash alternative OS'es onto your N900 NAND.
* Possibilities in rescue menu as in my previous post about bootmenu.sh hook - dump my rootfs to SD and I'll fix it on my PC and reflash it back to my N900.
Thursday, January 14, 2010
A small but important update in PR1.1
This is slightly technical, but PR1.1 included a small but interesting patch to /sbin/preinit (part of getbootstate). /sbin/preinit is the first thing that gets run on Maemo5 for N900. Some history first: In the past we've always had to patch initfs or /sbin/preinit in order to get any sort of bootmenu on 770/N8x0(W)/N900. This has changed with PR1.1 - the patches are now part of Maemo5.0!
Besides some patches to aid MMC booting, what is added is few very important lines:
SLIDE_STATE=`cat /sys/devices/platform/gpio-switch/state`
if [ x"$SLIDE_STATE = "xopen" ]; then
echo_g "slide open, attempting to use bootmenu"
[ -f /bootmenu.sh ] && . /bootmenu.sh
fi
What does this mean? This means, that when you have the keyboard slid out at power on, it will look for /bootmenu.sh and try to include it in the boot process. If it doesn't exist, it goes on with business as usual.
This means, you can add have fanoush's bootmenu or your own rescue menu, or whatever could be interesting to have this early in the process.
Thanks to fanoush for his bootmenu and to Peter De Schrijver from Nokia for applying my patches.
Besides some patches to aid MMC booting, what is added is few very important lines:
SLIDE_STATE=`cat /sys/devices/platform/gpio-switch/state`
if [ x"$SLIDE_STATE = "xopen" ]; then
echo_g "slide open, attempting to use bootmenu"
[ -f /bootmenu.sh ] && . /bootmenu.sh
fi
What does this mean? This means, that when you have the keyboard slid out at power on, it will look for /bootmenu.sh and try to include it in the boot process. If it doesn't exist, it goes on with business as usual.
This means, you can add have fanoush's bootmenu or your own rescue menu, or whatever could be interesting to have this early in the process.
Thanks to fanoush for his bootmenu and to Peter De Schrijver from Nokia for applying my patches.
Tuesday, January 12, 2010
A creative use of MADDE: A new way for theme makers to make themes for Maemo5
Recently, three source packages that were published in Diablo times was released in their Fremantle versions which I had waited for a long time for. These are:
* A source package which generates a theme, hildon-theme-variant-example
* This is done on the basis of hildon-theme-layout-5 (also published in Maemo5.0 update2 SDK), a package that provides the GTK theming and how to slice and dice a template into the theme elements.
* The slicers and dicers and dithers are provided in hildon-theme-tools (also published in Maemo5.0 update2 SDK).
hildon-theme-variant-example is CC BY SA 2.5, hildon-theme-layout-5 is CC BY SA 3.0 and hildon-theme-tools is GPL 2.0 for those who are interested in that.
Now, on to what this article is actually about.
What I am going to provide you theme makers of Maemo, is a way to make theme packages similar to how the vendor-provided themes on your device is made. We had this ability in Diablo and now we have it in Fremantle.
There was a catch with the Diablo method - it required you installing Maemo SDK, well, under Linux and this isn't always commonly found on graphics designers computers which typically ran Windows or MacOS X.
Thus, cross-platform solutions like Kontorri's Theme Maker was made which emulated what these packages described are doing. It made a binary Debian package, which could only be uploaded to Maemo Extras in the non-free section.
Normally, developers upload a source package to Maemo Extras and the autobuilder builds it for us.
Now, the ballgame has changed with MADDE. MADDE is a cross-platform Maemo SDK (Linux, Windows, MacOS X), which basically implements just about enough to cross-compile a Qt application. But why is this interesting for theme makers?
I've discovered that it is possible to generate the source package for a theme package within MADDE. What does this mean for your workflow as designers? Let me guide you through a workflow of theme design with the help of MADDE and the Maemo Extras repository.
Requirements:
* Install MADDE on your computer - it's a quite big download but it may be useful when you'd like to wander into Qt development as well. In this example I will be referring to paths from Windows MADDE but it should be transferable to your
* Something to open tar.gz files, such as WinRAR or similar.
* The garage.maemo.org and Extras upload invitation from http://wiki.maemo.org/Uploading_to_Extras-devel. Currently you will need to set a SSH key (write 'blahblahblah' if this is nonsense to you)
* Patience and willingness to learn :)
Workflow when beginning a new theme:
Step 1: Downloading the theme source package template
On this page there is a link that is called Download master as tar.gz. What is this? This is a theme template source package which you can customize to your own needs. Unpack the directory inside this into C:\MADDE\0.5\home\your username. Feel free to rename the directory to your intended theme name.
Step 2: Executing MADDE
In your start menu (or whatever your OS calls it's launcher), there should be MADDE -> MADDE Terminal.
You will now end up in your 'home directory' in MADDE, which is C:\MADDE\0.5\home\your username.
In there, you can 'cd directory name' where directory name is the name you gave the folder/directory from before.
Step 3: Customizing the source package template, basics
In the folder you should now 'sh try_it_out.sh'. This will ask you a couple of questions. You only have to do this once.
It will ask you the following questions:
* What should the package name of your theme be? (Example: hildon-theme-example)
* What should be theme name be? (Example: My example theme)
* Who is the maintainer of this theme?
* What should the directory name be (Example: example)
It will then set up the theme template.
Step 4: Customize the graphics - the fun step!
You can see in the directory several interesting places. The primary place for your work is in the template directory. This contains template.svg (SVG version of the basis template) and template.png (PNG version of the template). While it is up to you which one you want to edit, remember to always export template.png from the SVG.
Similar directories, icons, background images and other things to customize can be found in the applications directory.
Step 5: Building the source package
When you're done customizing, you can finally build your source package. In MADDE, you can do this:
username $ mad dpkg-buildpackage -S -us -uc -d
This will generate a .dsc and .tar.gz in the parent directory which you can use in the next step.
Step 6: Uploading to Maemo Extras
You can now upload this .dsc and .tar.gz file to Maemo Extras through the Maemo Extras Assistant. The autobuilder will then build the theme package for you and your theme will show up in Extras-devel.
As a bonus, anyone can base their themes upon yours as they have the 'source code' of your theme (under CC SA BY 2.5 conditions) - something not possible with ThemeMaker.
There are probably more maintaining issues which I hope the real theme makers will explore such as adding new versions to changelogs and such and tell about in their blogs.
If you have problems with any of the steps, prod me (Stskeeps) on #maemo , irc.freenode.net or comment this post.
* A source package which generates a theme, hildon-theme-variant-example
* This is done on the basis of hildon-theme-layout-5 (also published in Maemo5.0 update2 SDK), a package that provides the GTK theming and how to slice and dice a template into the theme elements.
* The slicers and dicers and dithers are provided in hildon-theme-tools (also published in Maemo5.0 update2 SDK).
hildon-theme-variant-example is CC BY SA 2.5, hildon-theme-layout-5 is CC BY SA 3.0 and hildon-theme-tools is GPL 2.0 for those who are interested in that.
Now, on to what this article is actually about.
What I am going to provide you theme makers of Maemo, is a way to make theme packages similar to how the vendor-provided themes on your device is made. We had this ability in Diablo and now we have it in Fremantle.
There was a catch with the Diablo method - it required you installing Maemo SDK, well, under Linux and this isn't always commonly found on graphics designers computers which typically ran Windows or MacOS X.
Thus, cross-platform solutions like Kontorri's Theme Maker was made which emulated what these packages described are doing. It made a binary Debian package, which could only be uploaded to Maemo Extras in the non-free section.
Normally, developers upload a source package to Maemo Extras and the autobuilder builds it for us.
Now, the ballgame has changed with MADDE. MADDE is a cross-platform Maemo SDK (Linux, Windows, MacOS X), which basically implements just about enough to cross-compile a Qt application. But why is this interesting for theme makers?
I've discovered that it is possible to generate the source package for a theme package within MADDE. What does this mean for your workflow as designers? Let me guide you through a workflow of theme design with the help of MADDE and the Maemo Extras repository.
Requirements:
* Install MADDE on your computer - it's a quite big download but it may be useful when you'd like to wander into Qt development as well. In this example I will be referring to paths from Windows MADDE but it should be transferable to your
* Something to open tar.gz files, such as WinRAR or similar.
* The garage.maemo.org and Extras upload invitation from http://wiki.maemo.org/Uploading_to_Extras-devel. Currently you will need to set a SSH key (write 'blahblahblah' if this is nonsense to you)
* Patience and willingness to learn :)
Workflow when beginning a new theme:
Step 1: Downloading the theme source package template
On this page there is a link that is called Download master as tar.gz. What is this? This is a theme template source package which you can customize to your own needs. Unpack the directory inside this into C:\MADDE\0.5\home\your username. Feel free to rename the directory to your intended theme name.
Step 2: Executing MADDE
In your start menu (or whatever your OS calls it's launcher), there should be MADDE -> MADDE Terminal.
You will now end up in your 'home directory' in MADDE, which is C:\MADDE\0.5\home\your username.
In there, you can 'cd directory name' where directory name is the name you gave the folder/directory from before.
Step 3: Customizing the source package template, basics
In the folder you should now 'sh try_it_out.sh'. This will ask you a couple of questions. You only have to do this once.
It will ask you the following questions:
* What should the package name of your theme be? (Example: hildon-theme-example)
* What should be theme name be? (Example: My example theme)
* Who is the maintainer of this theme?
* What should the directory name be (Example: example)
It will then set up the theme template.
Step 4: Customize the graphics - the fun step!
You can see in the directory several interesting places. The primary place for your work is in the template directory. This contains template.svg (SVG version of the basis template) and template.png (PNG version of the template). While it is up to you which one you want to edit, remember to always export template.png from the SVG.
Similar directories, icons, background images and other things to customize can be found in the applications directory.
Step 5: Building the source package
When you're done customizing, you can finally build your source package. In MADDE, you can do this:
username $ mad dpkg-buildpackage -S -us -uc -d
This will generate a .dsc and .tar.gz in the parent directory which you can use in the next step.
Step 6: Uploading to Maemo Extras
You can now upload this .dsc and .tar.gz file to Maemo Extras through the Maemo Extras Assistant. The autobuilder will then build the theme package for you and your theme will show up in Extras-devel.
As a bonus, anyone can base their themes upon yours as they have the 'source code' of your theme (under CC SA BY 2.5 conditions) - something not possible with ThemeMaker.
There are probably more maintaining issues which I hope the real theme makers will explore such as adding new versions to changelogs and such and tell about in their blogs.
If you have problems with any of the steps, prod me (Stskeeps) on #maemo , irc.freenode.net or comment this post.
Thursday, January 7, 2010
Enabling RTC (clock), battery charging and watchdogs on alternative OS'es on N900
Just spent a day getting RTC (clock), battery charging and watchdogs working for Mer on N900 and I thought I'd like to share how it was done for those of you wanting to run other OS'es on N900. The watchdog package in typical Debian does not by default work with two watchdogs, so we are using DSME.
This example assumes that you have made a /mnt/initfs directory on your rootfs and that you're running this from fanoush's bootmenu which will put the Maemo5 root file system in /mnt/initfs
You should as early in your boot process (after udev has been started), run the following script:
# Set up initfs environment
hwclock --hctosys
chroot /mnt/initfs mount -n -t proc proc /proc
chroot /mnt/initfs mount -n -t sysfs sysfs /sys
mount --bind /dev /mnt/initfs/dev
chroot /mnt/initfs mount -n -t tmpfs -o size=1M,noatime tmpfs /tmp
chroot /mnt/initfs mount -n -t tmpfs -o size=256k,mode=0755,nosuid,noatime tmpfs /var/run
# Check current boot state. Could be 'USER'
export BOOTSTATE=`chroot /mnt/initfs getbootstate 2>/dev/null`
touch /mnt/initfs/tmp/$BOOTSTATE
echo $BOOTSTATE > /mnt/initfs/tmp/STATE
chroot /mnt/initfs /sbin/dsme -p /usr/lib/dsme/libstartup.so &
until chroot /mnt/initfs waitfordsme; do
sleep 1
done
LOGGER='/usr/bin/logger -s -tBME'
SYSFS_VBUS_PATH=/sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus
# check dead battery pre-charge
if [ $(cat $SYSFS_VBUS_PATH) -eq 1 ]; then
chroot /mnt/initfs /usr/sbin/bme_RX-51 -b
case $? in
0)
$LOGGER -pdaemon.notice 'precharge -> ok'
;;
2)
$LOGGER -pdaemon.crit 'precharge -> power off'
exit 1
;;
*)
$LOGGER -pdaemon.crit 'precharge -> failure'
;;
esac
fi
# Start battery management entity
chroot /mnt/initfs /usr/sbin/bme_RX-51 &
# Bonus: To get hald-addon-bme working (bad bad voodoo). We need to test if toggles_w's hald-addon-bme replacement works on N900.
# dpkg-repack hald-addon-bme from rootfs and dpkg -i it
mount --bind / /mnt/initfs/mnt/new_root
chroot /mnt/initfs ln -s /mnt/new_root/tmp/bme-dbus-socket /tmp/bme-dbus-socket
ln -s /mnt/initfs/tmp/.bmesrv /tmp/.bmesrv
ln -s /mnt/initfs/tmp/dsmesock /tmp/dsmesock
This example assumes that you have made a /mnt/initfs directory on your rootfs and that you're running this from fanoush's bootmenu which will put the Maemo5 root file system in /mnt/initfs
You should as early in your boot process (after udev has been started), run the following script:
# Set up initfs environment
hwclock --hctosys
chroot /mnt/initfs mount -n -t proc proc /proc
chroot /mnt/initfs mount -n -t sysfs sysfs /sys
mount --bind /dev /mnt/initfs/dev
chroot /mnt/initfs mount -n -t tmpfs -o size=1M,noatime tmpfs /tmp
chroot /mnt/initfs mount -n -t tmpfs -o size=256k,mode=0755,nosuid,noatime tmpfs /var/run
# Check current boot state. Could be 'USER'
export BOOTSTATE=`chroot /mnt/initfs getbootstate 2>/dev/null`
touch /mnt/initfs/tmp/$BOOTSTATE
echo $BOOTSTATE > /mnt/initfs/tmp/STATE
chroot /mnt/initfs /sbin/dsme -p /usr/lib/dsme/libstartup.so &
until chroot /mnt/initfs waitfordsme; do
sleep 1
done
LOGGER='/usr/bin/logger -s -tBME'
SYSFS_VBUS_PATH=/sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus
# check dead battery pre-charge
if [ $(cat $SYSFS_VBUS_PATH) -eq 1 ]; then
chroot /mnt/initfs /usr/sbin/bme_RX-51 -b
case $? in
0)
$LOGGER -pdaemon.notice 'precharge -> ok'
;;
2)
$LOGGER -pdaemon.crit 'precharge -> power off'
exit 1
;;
*)
$LOGGER -pdaemon.crit 'precharge -> failure'
;;
esac
fi
# Start battery management entity
chroot /mnt/initfs /usr/sbin/bme_RX-51 &
# Bonus: To get hald-addon-bme working (bad bad voodoo). We need to test if toggles_w's hald-addon-bme replacement works on N900.
# dpkg-repack hald-addon-bme from rootfs and dpkg -i it
mount --bind / /mnt/initfs/mnt/new_root
chroot /mnt/initfs ln -s /mnt/new_root/tmp/bme-dbus-socket /tmp/bme-dbus-socket
ln -s /mnt/initfs/tmp/.bmesrv /tmp/.bmesrv
ln -s /mnt/initfs/tmp/dsmesock /tmp/dsmesock
Monday, January 4, 2010
On the perceived openness of Maemo, part one: Your target audience
Some time ago, I stumbled over a rather aggressive comment in Quim's blog, which made me wonder if we are approaching the topic of open sourcing Maemo components in the right manner.
The comment in question took big offense to the way the page Why_the_closed_packages presents reasons for keeping things closed source and it appeared to me that the meaning of the different reasons in his world view was completely different to how I perceive them. I usually classify myself as a open source lover with a realistic sense of why there sometimes has to exist closed source software but I'll try to remain objective and respectful to both sides of the spectrum in this article.
To further understand this problem, I asked Paul Fertser of #maemo – one of the people I've had most intense debates with about licensing issues in Maemo and why things are the way they are, to read Why_the_closed_packages sections 1 and 3 (Reasons, Requesting the opening of closed components) with his bias towards free software and document his thoughts of it. The quotes are presented with his permission. His background is in the OpenMoko community which is on the more liberal end of the open source software spectrum in the mobile Linux space.
Why did I ask someone with a huge bias to do this? Because he has been showing willingness to try to understand why things are they are in order to make more sense of the open source situation in Maemo – and that is something I respect. In his reaction to WTCP, he writes pretty clearly why it is useful to approach it with this angle:
“I assume that the purpose of the page is to make the process of open-sourcing in particular and development in general efficient and constructive.
That means that neither your time, nor time of your colleagues should be spent on void talks about something you can't change anyway and that people proposing opensourcing a particular component should concentrate on providing the most relevant arguments instead of taking part in religious debates.
To fulfill this purpose the page should be understandable and acceptable by the target audience.“ --Paul Fertser
The people who are going to make the most noise about open source policies are who our target audience of this page should be in order to be able to move away from time consuming religious debates and into constructive debates and discussions. That said, the page should also target developers for whom open sourcing a component would help their development.
The important thing is to spend more time on the actual open sourcing process than in time consuming discussions.
PF suggests some guidelines for the page, which I quote verbatim as see mostly no argument in what he states, emphasis mine:
First of all, you mainly target developers. And you take into account that among those interested in open-sourcing there will be a considerable amount of "free software zealots" who are sceptical and irritated about the proprietary software by default. So to avoid aversion that will be later reflected upon you and your fellows in form of negative emotions and useless quarrels i think it would be beneficial to follow several guidelines:
* Write from a hacker point of view, that way they'll feel you're "with" them and not "against", that makes people feel much more comfortable, take emotional response of your readers into account.
* Avoid buzzwords and formal style, a convincing page should look nothing like a press-release as we all know everything that comes from a PR department smells like(added by editor) lies.
* Add technical details, that makes you look understanding the issues in deep, increasing credibility of other information.
* Do not use really questionable arguments, that's like a red flag to a bull.
* Take into account many developers do not understand business and business reasons, so those should be explained in a more detailed way.
To me it seems it would be nice to have some introductory words on the page, at least that would make me less irritated and more constructive right from the beginning. I would gladly accept something like:
"We all know proprietary software sucks. Indeed it does, many of the headaches could have been avoided if there was less of it. Unfortunately, the reality is working in such a way we have to make compromises, that's unavoidable. On the other hand, there are actual possibilities to free more of Maemo and Maemo-related software, read on to find out what can be done and how to perform that."
That would make me feel comfortable because it looks informal, friendly and understanding. Also it gives hope. A nice way to get a pleased and listening reader.
While I don't fully agree with the wording of the text or opinions of PR departments, there's some parts I do find worth to mention. The best way to deal with an emotional response due to a default irritation of proprietary software is to provide technical details how the process actually work.
Like what happens when someone requests the open sourcing of a component. Does it go to a manager who agrees or disagrees or is there a wider process of checking with lawyers etc?.
These processes are not documented and transparency of these processes will help understanding how things are proceeding and provide examples of how open sourcing is done in practice from within a company. It is important to note that open sourcing does not happen overnight and present the practices.
The next part of this series will be about the exceptions to open sourcing and discussing the different reasons for having some components closed source.
Thanks to Paul Fertser for his input to this article.
Subscribe to:
Posts (Atom)