[ Liberación de un Proyecto bajo Software Libre ]

Aproximación práctica de algunas consideraciones que se deben tener en cuenta si decides liberar tu proyecto bajo lineamientos de Software Libre.

Primero:

Open Source = Free Software = Free Open Source Software (FOSS) = Software Libre

Los términos significan lo mismo, es decir que "el software" cumple con la Definición de Software Libre (https://gnu.org/philosophy/free-sw.es.html):

• La libertad de ejecutar el programa para cualquier propósito (libertad 0).
• La libertad de estudiar cómo funciona el programa, y cambiarlo para que haga lo que usted quiera (libertad 1).
• La libertad de redistribuir copias para ayudar a su prójimo (libertad 2).
• La libertad de distribuir copias de sus versiones modificadas a terceros (libertad 3).

En líneas generales el término Open Source tiende a estar mas relacionado con una visión 'Corporativa/Comercial', mientras que el Free Software con una posición mas 'Académica/Voluntaria'.

Segundo:

El licenciamiento o licencia que apliques a 'todo' el software es fundamental. Lo mas práctico es aplicar una de las licencias listadas en 'https://www.gnu.org/licenses/license-list.es.html' a todo el software, según las necesidades y objetivos que se tengan planteados. Un buen documento de referencia es este: http://docencia.etsit.urjc.es/moodle/mod/resource/view.php?id=5153.

Es importante que analicen adecuadamente el tipo de licencia que desean desde un principio, ya que una vez liberado y difundido el código fuente, resultaría mas difícil la modificación de la misma.

'Aplicar' la licencia al código fuente consiste básicamente en agregar el texto que describe el tipo de licencia a la cabecera de cada uno de los archivos/ficheros de tu software, o bien incluyendo explícitamente un archivo/fichero llamado COPYING ó LICENSE al directorio raíz del proyecto (http://www.gnu.org/licenses/gpl-howto.es.html).

Tercero:

Publicar y hacer disponible el código fuente. Si realmente desean que el proyecto sea difundido y eventualmente reciba contribuciones (a nivel de aporte de código),  es fundamental que provean mecanismos para que los participantes interactúen (repositorio de software, dominio de internet, sitio web, listas de correo, mensajería instantánea tipo IRC, bug tracking system, foro, etc.) Si por otro lado, lo que desean es tan solo publicarlo y que se encuentre disponible bajo los términos de FOSS, es suficiente con crear una cuenta en servidores tipo Github.com o similares (http://alternativeto.net/software/github/).

Cuarto:

Dependiendo de la plataforma o sistema operativo para el cual esta orientado el software, podrían considerar métodos de empaquetado para el proyecto, es decir, aparte de publicar el código fuente en crudo, también se suele comprimirlo en tar.gz y proveer los respectivos Makefile, producir los respectivos .deb .rpm según la arquitectura/distribución GNU/Linux, etc. (por ejemplo: https://wiki.debian.org/HowToPackageForDebian).

---
URJC - Máster en Software Libre.

[ MSWL - Project Evaluation ]

FlOSS Quality Evaluation Methodologies

With the advent of many FlOSS technologies nowadays and the high demand for IT services, arises the need to implement solutions based on this scheme, taking full advantage of available resources and getting the most profit of the services provided.

Considering that today there are several FlOSS alternatives in so many areas, a proper analysis is critical to choose the right solution, because the costs of selecting the wrong technology could be later unapproachable. Must be considered functional, technical and social requirements to make the most appropriate decision.

To make this analysis posible, emerge both short and broad spectrum standards and methodologies such as the Open Source Maturity Model [1], the ISO 9126 [2], the Goal-Question-Metric (GQM) approach [3], the light weight Open Business Readiness Rating (OpenBRR) [4] or the Qualification and Selection of Open Source software (QSoS) [5], and the heavy weight Quality of Open Source Software endeavor (QualOSS) [6].

Each of these takes care of measuring qualitative and quantitative attributes with the aim of providing a resulting value that facilitates the desicion making in choosing a particular software.

---
References: 

• [1] Duijnhouwer, F-W. "Open Source Maturity Model". Cap Gemini S.A. Nederland. 2003
• [2] ISO/IEC. ISO/IEC 9126. Software engineering - Product quality. 2001. ISO/IEC. 
• [3] Basili V, Caldiera G and Dieter-Rombach H. "The Goal Question Metric Approach". University Of Maryland and Universitat Kaiserslautern. 1994.
• [4] OpenBRR.org. "Business Readiness Rating for Open Source". BRR 2005- RFC 1.
• [5] Origin, Atos. "Method for Qualification and Selection of Open Source Software (QSoS) version 1.6". QSoS.org. 2006.
• [6] Deprez J~C, Haaland K, and Kamseu F. "QualOSS Methodology & QUALOSS assessment methods". CETIC. June 2008.

[ MSWL - Project Evaluation ]

IPython

As comented in previous posts, Python is an exelent interpretive programming language with a powerful object-oriented approach and modular integration capabilities. Inspired by this, Fernando Perez bagan working on IPython since 2001, an enhanced interactive Python shell with improvements such as history caching, profiles, object information, session logging, and tab completion, as an evolve alternative for the default interpreter.

Evaluation or Quality Assurance of FlOSS projects is a must with greater demand every day. It is critical to have tools handling the processes of data analysis and visualization, and there are handful of third-party Python packages that are suitable for this purpose. Including packages like matplotlib, Chaco, PyX or Bokeh, IPython is able to provide powerful visual representations of data, which allows better understanding.

It is possible to generate scientific plots, bars, histograms, trellis, boxplots and scatterplots, which are different ways for low and high level data visualization. Also there is IPython Notebook, a web-based interactive computational environment where you can combine code execution, text, mathematics, plots and rich media into a single document online.

---
Source: http://ipython.org

[ MSWL - Developers and Motivations ]

FLOSS Social Structure Analisys Tools

The FLOSS understood as a development model provides a well-defined or at least can be characterized through social organization established patterns.

A good example of this is shown by "Crowston & Howison" who examined 120 projects from SourceForge and inquired about their social organization, discovering that there are patterns around each project and its members, in fact they found a pattern of stratification baptized as "The Onion Model".

There are specific tools to perform this type of analysis, here we mention two of them based on FLOSS: "CVSAnalY" (https://github.com/MetricsGrimoire/CVSAnalY) y "R Project" (http://www.r-project.org).

CVSAnalY is based on Python under GNU GPL license, and extracts information out of source code repository logs and stores it into a database. This provides the potential to analyze in detail the data contained in the log of a project, doing custom queries and limiting the results to what is really needed. For instance, the database could be MySQL and the repository source could be Git.

The R Project also based on GNU GPL license, provides set of software facilities for data manipulation, calculation and graphical display, based on the R language which is oriented to statistical computing and graphics. With this tool we could generate bar graphs showing the distribution of the bug-threads for certain project, or the top commiters by specific dates for instance.

Obtaining metric statistics and graphical visualization for the activity of developers around free software projects, allow us to identify among many other things: orders of magnitude between the Onion Model layers, determine the existence of "generational relay", do "social network analisys" or identify "developers territoriality" and thereby make analysis regarding the evolution of the project.

---
References:

• Ortega F., Amor J. and Robles G. "The Onion Model in FLOSS". GSyC-Libresoft, MSWL URJC, Madrid, November 2011.
• Crowston K and Howison J. "The social structure of Free and Open Source software development". School of Information Studies, Syracuse University. November 2004.

[ MSWL - Developers and Motivations ]

Free/Libre Software and Education

Last December 12th was held on Fuenlabrada's campus at URJC the GSyC/LibreSoft 2013 Convention, which counted with the presence of Richard M. Stallman (RMS) who offered a talk entitled "The Free Software and Your Freedom" (http://www.fsf.org/events/20131212-fuenlabrada).

In this talk Stallman spoke among other things about the goals and philosophy of the Free Software movement as well as the history of the GNU operating system, with emphasis on the ethical benefits of using this type of software.

The evolution of free software projects depends heavily on the formation acquired by individuals in the education system, but more importantly are the values ​​that govern these projects, which in turn leads the society.

As far as FLOSS would gradually be adopted by formal education systems in society, future leaders will emerge with robust foundations on issues of human rights, freedom, cooperation, and core values ​​for good and human progress. As RMS mention, "Free Software is not just a technical question; it is an ethical, social, and political question."

---
Reference: http://www.gnu.org/education/

[ MSWL - Development Tools ]

Benefits of using git

git is a distributed source control management system initially designed and developed by Linus Torvalds in 2005, distributed under GNU GPLv2 license. Among the main goals of this project was to support:

• Distributed revision control system workflow, synchronizing code by exchanging patches from peer to peer
• Strong safeguards against corruption, either accidental or malicious
• Low latency of patches going into repositories, focused on speed

As Linus mentioned, there is a complete manual and tutorials asociated to this tool in the main website (http://git-scm.com/) that shows many of its features and how to use it, but there is a great Tech Talk given by Torvalds at Google in 2007 in which he emphasizes the following specific benefits:

• Reliable: the system guarantees that the code putted into it, comes out exactly the same at any other time, preventing disc corruption or malicious intent. Get your own branch, doing a great work or a mediocre work, is not relevant, it's your own copy. A good backup way, cloning from trusted sources.
• High performance: allows to track around 22,000 files in 5 seconds top.
• Distributed: no single place of storage, be able to do everything from any location without access to the server, off-line work.
• Disseminated: globally adopted by various systems and infrastructures.

Another important element is the repercussion this project is adopting in different areas of society, since its creation git is increasingly been used even in projects not related to computer science, due to we now live in the information age and require efficient systems to manage it.

Source: https://git.wiki.kernel.org/index.php/LinusTalk200705Transcript

[ MSWL - Development Tools ]

Python: The importance of Docstrings

A docstring is a literal string description or definition of a module, function, class, or method in the Python code. It becomes the __doc__ attribute of that object.

A docstring corresponds to something like the following:

  def function(a, b):
      """function(a, b) -> list"""

Or even something more comprehensive like this:

  def complex(real=0.0, imag=0.0):
      """Form a complex number.

      Keyword arguments:
      real -- the real part (default 0.0)
      imag -- the imaginary part (default 0.0)
      """

On the other hand, unlike the usual comments, a docstring facilitate the task of consulting the description of a module, function, class, or method from the Python interpreter, without requiring access to the source code to understand its operation, facilitating its usage.

All of this is a technical matter, but the real deal about it is to make the code readable and understandable with the intention of attract as many contributors as possible.

If the code of a project is not well documented, commented or described, there is no one who would want to use it or much less contribute to it. So if you're taking the time to code something transcendental or productive, then try to incorporate docstrings in the process, as this will allow a better diffusion of the project, or at least later will allow you to better understand what you did in the past. It is a good practice for you and for everybody in the programing world.

Source: http://www.python.org/dev/peps/pep-0257/