Proposal: The open sourcing queue

[Stskeeps]

I've lately been working on the maemo.org Open Sourcing Queue.

The idea of the open sourcing queue, is to have the ability to prioritise what components should be sent through the machinery that in the end decides if something is open sourced or not and in which order.

The important thing is to spend more time on the actual open sourcing process than in time consuming discussions.

The idea is that we need to get things prioritised in an order as to make it possible for a Nokian to be able to look at a page, select one or more of the top licensing change requests and then without bigger effort send this through the internal machinery for open sourcing and hence getting it to happen (or a decision made that the change won't happen). Keep in mind such a process can take quite a while.

My proposal for implementing this queue is to do it on top of bugs.maemo.org. The idea would be to add a product dedicated to Licensing changes where the default assignee would be me, as maemo.org distmaster.

To be able to structure the work better, a form for licensing change requests would be used:

* What component(s) or source packages/etc is the licensing change request regarding?

* What component area is the component in? (See the openness reports)

* What is the current licensing of the component?

* What licensing would you like it to be and why? Examples can be:
open source and openly developed (move to gitorious), open source (select a license), non-free but redistributable, non-free, published in nokia-binaries, document the functionality, etc.

* What project(s) would have benefit from this licensing change request?

* What technical purpose do you/your project(s) have for wanting the licensing change?

Upon receiving a request, I will then:

* Verify if a request has already been filed (marking DUPLICATE if so) or evaluating if we need to reevaluate the licensing request due to changed circumstances.

* Evaluate the technical purpose and see if the end result of open sourcing the component would actually make this possible (marking INVALID if it doesn't make this possible and encouraging filing a request against another component that has the functionality)

From then on, the idea is to determine the priority of the request (High, Medium, Low)

* If open source replacements exist (counting down in priority)

* If it aids the implementation of open source replacements (counting up in priority)

* Give a preliminary evaluation on potential problems regarding
http://wiki.maemo.org/Why_the_closed_packages#Reasons - these reasons count down unless it's worth exploring if it is actually problematic.

* Give a preliminary evaluation on the technical purpose regarding reasons mentioned at http://wiki.maemo.org/Why_the_closed...sed_components - these reasons count up in determing the priority.

* Is there one or more projects that would have benefit of this? (Counting up)

The idea is then that people/projects can indicate interest in the licensing request happening either through bug votes or by adding additional information to the original form which may change priority.

The result would then be a dynamic queue, where it would be possible like in http://tinyurl.com/ykfexsb to take those with high priority and votes and send through the machinery and then churning through the queue. When a bug has been taken into the licensing machinery, the bug will be assigned to the person who began the process internally.

While this goes on, I'll be assisting to help the open sourcing process in case of lack of resources to do this and serve as a bridge for trying to approach an ideal solution.

The challenge is, on both sides, to be willing to compromise as to fullfil the technical purpose. While a full open sourcing may not always happen, there might be other possibilities and we should be willing to explore these.

So, my question is - how do you developers feel about going about this difficult topic this way? Any suggestions for improvement, etc?

[Luke-Jr]

From my perspective, all the relevant bits have already been given a "no, we won't concede control of the hardware you purchased!"; will this new process give any reconsideration to those components (IIRC, this is mainly just BME and gpsdriver for N8x0)?

[Stskeeps]

Originally Posted by Luke-Jr

From my perspective, all the relevant bits have already been given a "no, we won't concede control of the hardware you purchased!"; will this new process give any reconsideration to those components (IIRC, this is mainly just BME and gpsdriver for N8x0)?

Personally I wouldn't mind to revisit some discussions as there might be more reasons now to aid community projects and maybe learn from these to help future choices.

[ArnimS]

Thumbs-up!

in some cases (e.g. media player) someone might request or vote for open-sourcing the whole thing, however what they want to change only requires opening a component of it (e.g. frontend). I think Stskeeps or an other moderator should be able to reassign votes to the proper component if they were submitted misplaced.

[Andre Klapper]

I don't know what "reassign votes" means here.

[SD69]

Originally Posted by ArnimS

Thumbs-up!

in some cases (e.g. media player) someone might request or vote for open-sourcing the whole thing, however what they want to change only requires opening a component of it (e.g. frontend). I think Stskeeps or an other moderator should be able to reassign votes to the proper component if they were submitted misplaced.

Whether reassigning votes or something else, I think there should be some way to translate imprecise requests so that the intent is not lost.

What if someone wants the stylus keyboard (closed in Diablo, removed from Fremantle) opened up, but doesn't know what component(s) that implicates? What happens? Does their vote get discarded because they haven't made it correctly? Do they get a PM asking them to identify the component(s)? etc.

Edit: refer to prior comments here:

http://talk.maemo.org/showpost.php?p...6&postcount=16

[luca]

Maybe this isn't the right thread, but what's the situation with the kernel?
I see that mer is still stuck with 2.6.21, so I suppose that there's nothing new on that front.

[qgil]

Now the MeeGo picture puts this in the right perspective: clear open trend for platform and clear no-open trend for applications coming purely from Nokia. Some core apps might come from MeeGo (where OSS reference apps will be developed for anybody willing to deploy them) and some core apps might come someone else (e.g. Browser, where the collaboration with Mozilla upstream increases).

[lma]

Originally Posted by luca

Maybe this isn't the right thread, but what's the situation with the kernel?
I see that mer is still stuck with 2.6.21, so I suppose that there's nothing new on that front.

See http://kvalo.wordpress.com/2009/07/1...nline-kernels/ (and the links therein). I'm not sure whether work is ongoing though.