Mapping Fremantle openness
 

As one of my first tasks as a distmaster, Quim put me up to a task where I have to refresh the status of openness of Fremantle.

As I've been one of the people actually having to use the mentioned spreadsheet quite often, I've had some thoughts on how we can do this better.

First off, defining levels of openness of a package. When saying package, I mean source packages.

* 1. Developed openly on maemo.gitorious.org, no closed dependencies.

* 2. Source package published in SDK, no closed dependencies.

* 3. Developed openly on maemo.gitorious.org but directly depending on packages that are closed.

* 4. Source package published in SDK, but directly depending on packages that are closed (level 5 and higher)

* 5. Binary-only package published in SDK (potentially non-redistributable)

* 6. Package published under EULA in nokia-binaries.

* 7. Not published except on device / SSU repositories.

Along with checkboxes for:

* Is the package 3rd party?

And comments:

* If depending indirectly on a closed package, how many 'hops' is the closed source package away?

* If developed openly, where on maemo.gitorious.org?

* If 3rd party, who owns it?

* If closed, why? basing off first list on http://wiki.maemo.org/Why_the_closed_packages

Based on this spreadsheet we can then start prioritizing and determining what levels of openness we need to move some packages to, to improve the situation.

We can then also objectively see what consequences opening a package would have on overall openness of the platform. As well as adding a new statistic, how much is openly developed.

The procedure for generating these will be automated so once Harmattan starts getting released, we can apply same the same procedure to this.

Any ideas for more data that can be interesting to have in the spreadsheet/changes to my suggestions?

Re: Mapping Fremantle openness
 

sts, great! why don't you add an "open alternatives" column which can be used for the closed items to indicate near or complete open replacements.

Re: Mapping Fremantle openness
 

"Developed openly upstream" is also an option, perhaps with some indications of how much the Maemo version differs (eg age of the base upstream package and size of Maemo diff expressed as a line count percentage). There's also the case of "Developed openly upstream but Maemo version is closed" (eg libjpeg, speex. exempi).

Re: Mapping Fremantle openness
 

What about something which is not exactly a package, is this relevant to this task too? Like undocumented data format (FIASCO image structure, config partition), communication protocol/interface etc.

Re: Mapping Fremantle openness
 

Is a speadsheet the best format? Would a software stack in which the components are color coded according to openness status be better?

Re: Mapping Fremantle openness
 

Good point - I've mostly focused on software openness though. In Fremantle I've found that libcal, some communication protocols, etc, are L6, nokia-binaries. It's not perfect, but at least it allows people to write applications that utilize them.

My personal hope (from Mer perspective) is that we can move the interfaces (-dev) into at least L5, so people can make ABI compatible replacements for closed source things.