FLOSS Lightweight methodologies: QSOS and OpenBRR

libre software, mswl, mswl-eval, mswl-intro

Hi all!!

Following the posts regarding my subject on Project Evaluation, now I’m going to talk about FLOSS assessing methodologies, an to be concrete, about, maybe, the two most important FLOSS methodologies, QSOS and OpenBRR.

These two FLOSS methodologies for assess FLOSS projects are several things in common but also several things that are not common.

To see the differences and a brief study about this two methodologies we can check the slides which are located in my subject website here.

To introduce the reader about this methodologies is good to know:

QSOS is created by Atos Origin and OpenBRR is under developed by Carnegie Mellon West, CodeZoo, SpikeSource and Intel and is ar RFC state.

All both methodologies try to provide a criteria to evaluate FLOSS projects, for instance, if we have to chose a SCM between all of the market basing in a set of requisites, these two methodologies can help us to make the good election.

After that I want to comment something about the main conclusion of these slides:

For instance,  for OpenBRR we differentiate different roles, the user and the developer, this is really good because is not the same the documentation for a conventional user trying to explain how the program can be used, and the documentation for developers trying to explain how you can create a package of the program source code, so this is a good idea to try to differentiate that two different point of views, but as QSOS tries, the QSOS methodology tries to be more global more absolute, trying to create an average between the different points of view but with keep on mind them. Both points of view are good, and I think the possibility to choice between different approaches in different scenarios is really interesting, as the same way we have different operating systems, different text editors, etc.

Regarding the evaluation criteria, there are many things that are covered by OpenBRR and are not covered by QSOS and vice versa, the methodologies should try to cover the most things of every each one, is a good point that that two methodologies may have different criteria but try to adjust to cover more or less the same would be good.

An important thing for me is QSOS is already quite used at least by its creator (Atos Origin) but OpenBRR is at RFC state, under creation, so OpenBRR should be finished completely to may evaluate correctly all the things that this methodology covers.

After check these two methodologies, in my opinion, both are really complicate to use, or much better to use the word complicate, there are a mess, different points of view, different approaches, different attributes to study, different roles, under my point of view, these methodologies just try to use a common framework to study FLOSS as any one can evaluate using his own criteria, I mean, if I try to study and to differentiate three different FLOSS projects, I think I can try to use more or less (maybe less) criteria that these two methodologies use, so these methodologies try to check common criteria and also maybe, stranger criteria like somebody can not think about it if doesn’t have a methodology so there are these things the ones which maybe can put more difficult to understand the methodology itself and the FLOSS study about the projects.

Also as final note, is really interesting to check the licenses used in these methodologies QSOS for instance is under GFDL, and is really good, but the reports and information obtained using this methodology is mandatory to be relased also under GFDL, this is good to preserve the freedom to the community, but maybe in this kind of papers should be more interesting to use a permisive license which allows the user to release the report under a different license or even a privative one.

The ambiguity also is really important, is really interesting if we don’t have ambiguity in the criteria which these methodologies cover, but as we see in the slides, the ambiguity exists, so we need to be careful to understand the little point of difference between criteria (if there is any).

As a bad point if we check the OpenBRR official website we can see how we don’t have too much information about this methodology and the way to use it, if we check QSOS we can see a lot of information, a good website, etc. this is really important if we want to have our methodology as the most used, even under RFC state, this is not an excuse.

And that’s all my friends, see u!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s