[maemo-developers] Double checking free/nonfree packages

[From: Eero Tamminen]

Hi,

ext Christopher Allan Webber wrote:
> For now there seem to be two main pages on which the documentation of
> what is free/nonfree is:
>  - http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Top_Level_Architecture
>  - http://wiki.maemo.org/Why_the_closed_packages
> 
> The first contains that rather informative graph, but I suspect that the
> intended purpose of that page would be made less useful if we put all of
> the documentation of free/nonfree components on there.  The second one
> seems to be a good start,

I think main issue is that it's not really updated for Fremantle, a lot
of the stuff there would seem to be Diablo release specific...


> but I think the naming of that particular page
> helps defeat our purpose, as it seems to say "here is why these are
> closed" as just an explanation, and does not indicate "this is a record
> of pieces that we are working to free."  So, unless there are any
> objections, I think it would be better to start a page with a name such
> as Free_Maemo or something similar that indicates a kind of "free and
> open source todo-list" that I think everyone here seems to want.  I'll
> work on incorporating the "Why the closed packages" page within that
> document, and if that proves to be satisfactory, we can probably have
> the Why_the_closed_packages page redirect to the new one.


What about following page structure?

Index page:
* with explanation about:
   - Why it makes sense to open sources and what should
     be prioritized (the list below)
   - Why Nokia has some packages closed
     (top part of existing page)
* Link to page listing closed packages in Diablo
   (bottom part of existing page)
* Link to page listing closed packages in Fremantle
* Link to TODO list(s) about opening or replacing above packages
   with free alternatives


>> The criteria to prioritize components could be (improvising a bit, feel
>> free to suggest improvements):
>>
>> 1. Fixing a bug. I mean a real objective bug: package is in non-free
>> although it looks like it's actually an open piece of software.
>>
>> 2. Nurturing application development. There is a strong argument proving
>> that opening a component will bring more and better apps for end users.
>>
>> 3. Spread of Maemo driven technologies to other platforms. A component
>> fits well in a gap existing in other Linux/OSS based projects and there
>> is a concrete interest on collaborating and contributing to a component
>> if it's opened.
>>
>> 4. Community maintenance. A component is receiving low attention from
>> the official maintainers even if it has high attention from the
>> community and there are developers volunteering to contribute to it if
>> the source code is available.
>>
>> 5. Better architecture. Probably covered by 2 or 3 but just in case. A
>> closed component is sitting in the midle of open components making
>> things more difficult that needed to developers interested in that area.

Good list!


	- Eero