View Single Post
Stskeeps's Avatar
Posts: 1,671 | Thanked: 11,478 times | Joined on Jun 2008 @ Warsaw, Poland
#1
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?
__________________
As you go on to other communities, remember to build them around politeness, respect, trust and humility. Be wary of poisonous people and deal with them before they end up killing your community.. Seen it happen to too many IRC channels, forums, open source projects.
 

The Following 30 Users Say Thank You to Stskeeps For This Useful Post: