Relación entre licencia, modelo de negocio y sostenibilidad de un proyecto de Software Libre

La gran mayoría de proyectos de Software Libre tienen a su alrededor una comunidad, más o menos grande, que se debe mantener de alguna forma para que el proyecto sea sostenible y perdure en el tiempo. Esta necesidad de sostenibilidad es la que hace que la elección de la licencia o licencias bajo las que se va a distribuir el producto sea muy importante.

Licencias y modelos de negocio

Con respecto a esto, hace unos días navegando por Internet me encontré con el artículo Open Source and Bussiness Model Innovation. The Funambol case de Alberto Onetti y Fabrizio Capobianco que, a pesar de ser de 2005, hace una descripción, a mi entender, muy buena de la relación entre licencias y modelos de negocio en proyectos de Software Libre y por ende de la sostenibilidad del proyecto.

Primero, define dos grandes grupos de licencias:

  • Licencias de tipo recíprocas o copyleft, como la GPL (GNU Public License) que aseguran que cualquier obra derivada va a mantener la misma licencia que la que le dio el autor original.
  • Licencias permisivas o tipo BSD (Berkeley Software Distribution), que permiten que las obras derivadas puedan tener cualquier tipo de licencia, incluso privativas.

Y en relación con estos dos grupos de licencias define tres grandes tipos de modelos de negocio:

  • Modelos de negocio GPL/LGPL (Lesser GPL): Las licencias tipo GPL limitan la adopción comercial del software ya que obligan a liberar también las modificaciones o mejoras realizadas. Las compañías que usan estos tipos de licencia tienen como modelo el servicio a la comunidad y obtienen beneficios de los servicios profesionales que prestan tales como: mantenimiento, personalización, consultoría y formación. Ejemplos de este tipo son el kernel Linux, Gimp, Red Hat, que obtiene sus beneficios de contratos de soporte, consultoría y formación, entre otros.
  • Modelos de negocio BSD/Apache: Este tipo de licencias permiten a las empresas convertir al software en privativo habiendo o no, realizado modificaciones al mismo. El código creado o sus derivados, bajo este tipo de licencias,  puede ser comercializado por cualquiera, incluso sin ser el desarrollador original. Los beneficios pueden entonces venir tanto de la venta de licencias como de servicios profesionales igual que en el modelo GPL. En muchos casos la licencia es usada para el núcleo (core) de la aplicación y así favorecer su difusión y las licencias privativas para módulos o extensiones del mismo denominándose este modelo open-core. Un ejemplo puede ser Zend creadora de PHP que tiene el núcleo libre y un montón de herramientas privativas alrededor.
  • Modelo de negocio de doble licenciamiento: Se basa en disponer de dos licencias una tipo copyleft  fuerte y otra privativa y es el cliente quien elige cual quiere usar. Las organizaciones que quieran desarrollar aplicaciones de software libre obtendrán el código como si fuese un producto más de software libre con todos sus beneficios y obligaciones y las que no quieran liberar sus productos adquieren una licencia privativa que les da derecho a no abrir el código. Esto sólo funciona con licencias copyleft fuerte como GPL ya que las licencias BSD lo permiten directamente sin comprar ninguna licencia privativa. Las empresas que usan licenciamiento dual obtienen sus beneficios principalmente de la venta de licencias. Un ejemplo típico de este modelo en MySQL y entre otros está también Funambol.

En el modelo de software privativo el beneficio económico viene fundamentalmente de la venta de licencias mientras que en el Software Libre puede venir de la venta de licencias pero fundamentalmente viene de la venta de los servicios que rodean al propio software.

Conclusión

La decisión del tipo de licencia que vamos a elegir para un proyecto de Software Libre va a depender no solo de nuestra filosofía de vida si no que también de la forma en la que queramos hacer sostenible al proyecto. Si queremos que un proyecto se extienda mucho la elección es BSD pero corremos el riesgo de que alguien lo coja y se aproveche de él, eso sí, nuestro código seguirá siendo libre y si queremos que todas las mejoras reviertan en el código original usaremos GPL pero para las empresas no suele ser atractivo GPL ya que les obliga a liberar sus modificaciones, que pueden ser un activo importante para mantener a raya a la competencia

Bueno, cada uno que tome su decisión según lo que quiera hacer.

Hasta otra …

Publicado en Aspectos económicos, Aspectos legales, Gestión de proyectos | Etiquetado , , , , , | Deja un comentario

¿Hemos llegado al final de Camino?

El 30 de mayo de 2013 apareció publicada en la web de Camino, navegador web con más de 10 años de vida para entornos Mac OS X, que llegaba a su final.

Es una mala noticia que un proyecto de Software Libre con tantos años detrás desaparezca, pero las premisas básicas para que un proyecto siga vivo son que existan desarrolladores que puedan y quieran mantenerlo y que existan usuarios que lo usen, si falta cualquiera de los dos elementos la balanza se desestabiliza y el proyecto desaparece, bueno un proyecto de Software Libre nunca desaparece ya que el código sigue ahí y cualquiera con interés y ganas puede reflotarlo de nuevo.

Por ejemplo, cuando Oracle compró a Sun Microsystems adquirió una serie de proyectos de Software Libre en el paquete, como es sabido o por lo menos intuido, a Oracle todo aquello que no le reporte un beneficio económico no le interesa, con lo que algunos proyectos como OpenOffice quedaron de lado y de ahí surgió LibreOffice, más tarde, Oracle le cedió los derechos de OpenOffice a la Apache Foundation pero eso ya es otra historia. Es curioso pero con MySQL, otro paquete dentro del lote, no ocurrió lo mismo ya que al poco tiempo las licencias empresariales del producto cuadriplicaron su precio y Oracle sigue manteniéndolo, esto implica que la intuición anterior era bastante acertada.

Los datos

Vamos a realizar un análisis somero de las causas que indican los desarrolladores de Camino para no continuar con el proyecto. Ellos dicen que:

“Después de una década larga, Camino ya no se encuentra en desarrollo e instamos a los usuarios a cambiarse a un navegador más moderno. Camino se está quedando cada vez más retrasado por la rapidez de los cambios en la web y no está recibiendo actualizaciones de seguridad, lo que lo hace cada vez más inseguro.”

Además también indican que:

“Afortunadamente, los usuarios de Mac tienen muchos más navegadores donde elegir de los que había cuando Camino comenzó hace diez años. Algunos de los antiguos desarrolladores de Camino han ayudado a crear los tres navegadores más populares actualmente  - Chrome, Firefox y Safari – así que mientras que este es el final de Camino en si mismo, la gente que ayudó a construirlo aún seguirá ahí para seguir haciendo de la web lo mejor para los usuarios de Mac.”

El análisis

Por lo que puedo extraer de estos dos párrafos el problema puede venir de que actualmente la comunidad de usuarios no debe ser lo suficientemente grande como para mantener a los desarrolladores con interés en el mismo, con lo que el número de desarrolladores decae, no es posible mantener el ritmo de la competencia y así los usuarios disminuyen y entramos en una espiral que lleva al fin.

También ayuda a este paso que existan otras opciones al alcance de los usuarios y que así  éstos no se vean desamparados ante la desaparición paulatina del producto por su falta de mantenimiento.

Al principio era el único navegador serio para usar en Mac OS X (los demás estaban todavía en pañales) y es posible que esto y no abrirse a otros sistemas operativos no ha ayudado a seguir en pie. Como podemos ver en la gráfica siguiente, obtenida de Netmarketshare sobre uso de navegadores en sistemas de escritorio en mayo de 2013, sólo los más fuertes sobreviven.

E incluso ellos, tienen que tener cuidado y si no, echad un vistazo a las tendencias indicadas en la gráfica siguiente. Nota: No he podido encontrar las diferencias entre la gráfica anterior y ésta aunque supongo que en ésta no solo se tendrán en cuenta los equipos de escritorio.

Fuente: StatCounter.

Conclusión

La balanza entre desarrolladores y usuarios en los proyectos de Software Libre debe mantener una proporción equilibrada tanto para que los desarrolladores se sientan a gusto y sigan haciendo su trabajo, como para que los usuarios sigan usando el producto y como decía Lord Kelvin “todo aquello que no se mejora se degrada siempre” y por ende tiende a desaparecer.

Hasta otra …

Publicado en Gestión de proyectos | Etiquetado , , , , , | Deja un comentario

El uso del Software Libre en las empresas españolas

Según el último dossier sobre el Uso de Software Libre en la empresa española 2010-2011 de CENATIC (Centro Nacional de Referencia de Aplicación de las Tecnologías de Información y la Comunicación basadas en Fuentes Abiertas), haciendo referencia a la Encuesta de Uso de las TIC y Comercio Electrónico en las Empresas (ETICCE) 2010-2011 del INE (Instituto Nacional de Estadística):

  • El 91% de las empresas TIC usa software libre en su infraestructura tecnológica.
  • El 53,4% de las empresas españolas utiliza ofimática libre.

Esto nos confirma que realmente el Software Libre además de proporcionar un ahorro de costes en licencias, ofrece una fiabilidad y robustez adecuadas para su uso en entornos empresariales, aspecto que ya conocíamos los que nos dedicamos a esto, y también nos indica de que hay un nicho de negocio importante para los desarrolladores de productos y servicios relacionados con él.

Datos de la encuesta

Según el dossier, la encuesta se realizó a 28.980 empresas (16.715 de 10 o más asalariados y 12.265 de menos de 10 asalariados) y en el apartado B.2 de su cuestionario, se hace referencia a los siguientes tipos de productos de Software Libre:

  • Sistemas operativos
  • Navegadores web
  • Aplicaciones ofimáticas
  • Servidores web/Internet
  • Otras aplicaciones de Software Libre para procesado de información (bases de datos, gestores de contenidos, …)
  • Otros (como software de seguridad, plataformas de enseñanza, …)

Resultados obtenidos

Las resultados principales obtenidas del dossier indican que:

  • Utilizan Software Libre tres de cada cuatro (75%) empresas españolas con más de diez trabajadores y cinco de cada diez (50%) micro-empresas.
  • En las grandes empresas es donde más extendido está el uso de los sistemas operativos libres (47, 2%), los servidores web (47%) y las aplicaciones de tipo ERP o CRM (34%).
  • Las aplicaciones ofimáticas de código abierto son las soluciones libres más utilizadas entre las pymes (53,9% de las pequeñas empresas y 51,5% de las medianas).
  • Nueve de cada diez empresas TIC apuestan por el uso del Software Libre en sus infraestructuras de TI.
  • En todas las Comunidades Autónomas, el Software Libre está ámpliamente implantado en la infraestructura TI de las empresas.
  • El porcentaje de empresas que utilizan sistemas operativos libres ha aumentado del 9,5% en enero de 2010 al 26,40% en enero de 2011

Creo que salta a la vista que el Software Libre goza de buena salud dentro de nuestro tejido empresarial, aunque todavía quedan cosas por mejorar, sobre todo vencer el recelo de los que desconfían del Software Libre, principalmente porque no hay detrás una gran multinacional (eso ya no es así en los grandes proyectos libres) o una persona física a la que abroncar en caso de que se produzca algún problema. Señores seamos serios, los problemas se solucionan si hay buena voluntad por las partes y no son necesarios chivos expiatorios.

Conclusión

Ahora que tenemos las fuentes: CENATICINE, habrá que estar más atentos a estos informes y encuestas para saber la evolución del Software Libre en las empresas de nuestro país. Aunque, eso sí, habrá que hacer un máster para saber como obtener los datos de la encuesta del INE, por más que lo he intentado no he conseguido ver nada relacionado con el Software Libre, problema mío, seguramente.

Hasta otra …

Publicado en Aspectos económicos | Etiquetado , , , , , | Deja un comentario

El Software Libre y el ahorro de costes en la Administración

Según el Diccionario Espasa de dichos y frases hechas, dar una de cal y otra de arena significa:

“Actuar alternativamente de forma positiva y negativa. ‘El equipo no funciona bien. Un día gana y al siguiente pierde. Está dando una de cal y otra de arena’. Antiguamente, cuando no existía el cemento, los ladrillos o piedras se fijaban con mortero, un compuesto que se hacía con una palada de cal -el material caro y más noble- y otra de arena, lo más abundante y menos importante.”

Vamos a empezar por la arena

A finales de año pasado veíamos como un ingeniero freelance, en poco más de una semana de trabajo (según indica él mismo), había hecho, configurado servidores y desplegado un desarrollo  ”similar” al de la nueva web del Senado. Esto no hubiese sido noticia si no fuese porque el coste de la nueva web del Senado había rondado el medio millón de euros, de los cuales la mitad eran para licencias de software, y el desarrollo del ingeniero, realizado completamente con Software Libre, había rondado los 0 euros de coste en licencias, total, un ahorro de 250.000 euros que tal y como están las cosas es para tenerlo muy en cuenta.

En un documento, el autor contaba el por qué de la existencia de la web alternativa a la del Senado, explicando costes, soluciones alternativas usadas y también decía que el principal problema era el pliego de condiciones donde se especificaban las tecnologías a usar: Oracle, BRS, etc. , siendo éstas privativas y cuyo coste de licencias nada despreciable. Según se desprende del pliego solicitan estas tecnologías porque ya las tienen y las están usando pero ¿el ahorro de costes tan brutal no compensaría el cambiarse a productos libres? o ¿los productos libres no dan la suficiente fiabilidad para usarlos?, que se lo digan a muchas de las grandes empresas privadas dentro y fuera de nuestro país que los usan a diario.

Y ahora, la cal

En contrapartida acabo de leer la noticia donde se dice que 40.000 ordenadores del Gobierno Extremeño tendrán software libre en 2014. El proyecto, que tiene el nombre de LinGobEx, comenzó en 2012 auditando el software en los puestos de trabajo y finalizará, como muy tarde el primer trimestre de 2014, con la implantación de la nueva solución.

Según reza en el Plan Estratégico de Sistemas de la Información (2011-2015) de la Junta de Extremadura, en el apartado relativo a LinGobEx:

“Los beneficios de adoptar código abierto en el sistema operativo de los puestos de trabajo son claros, especialmente en tiempos donde la reducción de costes es una obligación. El ahorro económico en hardware y licencias de software puede alcanzar hasta un 80% del gasto en este capítulo (fuente IDC).”

Conclusión

Menos mal que hay cal porque si no se nos derrumbarían todas las casas.

Hasta otra …

Publicado en Aspectos económicos | Etiquetado , , , , | Deja un comentario

Análisis de repositorios de Software Libre. Primeros pasos con CVSAnalY.

Alguna vez nos hemos interesado por un programa de Software Libre para usarlo en un proyecto pero no sabemos como respira su comunidad, es decir, si disfruta de una salud de hierro o está herida de muerte. Esto es importante porque si implantamos un proyecto con dicho software y desaparece su comunidad nos encontraremos con muchos problemas: de seguridad, de mantenimiento, de soporte, de nuevas funcionalidades, …

En este post os presento CVSAnalY, un paquete que nos permite analizar un repositorio de software y almacenar la información obtenida de él en una base de datos. Entre dicha información podremos encontrar autores/committers, número de commits, número de ficheros, … y, por supuesto, todas las relaciones entre ellos. Por ejemplo, una cosa que me pareció muy interesante para saber como respira un proyecto es saber como va su comunidad y para ello un aspecto llamativo es la territorialidad (también conocida como, knowledge concentration), es decir, cuántos ficheros de un proyecto son tocados única y exclusivamente por un solo desarrollador, esto es importante ya que si ese desarrollador desaparece, el proyecto podría quedar “cojo”. Bueno, no me lío más y como ejemplo final os pondré las consultas para obtener la territorialidad de un proyecto.

CVSAnalY, historia e información básica.

CVSAnalY, como no podría ser de otra forma,es Software Libre y nació , en su nueva versión, en julio de 2006 de la mano de Libresoft y entre sus desarrolladores están: Carlos García Campos, Gregorio Robles, Alvaro Navarro, Jesús M. González-Barahona, Israel Herráiz, Juan José Amor, Martin Michlmayr, Álvaro del Castillo, Santiago Dueñas y Daniel Izquierdo (ya que son pocos, espero no olvidarme a ninguno) con la función de analizar repositorios de código. Esta desarrollado en Python, tiene licencia GPLv2.0 o posterior y su última versión estable es la 2.1.0 de finales de octrubre de 2011.

Requerimientos de CVSAnalY.

Para funcionar, CVSAnalY, tiene las siguientes dependencias:

  • RepositoryHandler ** git clone git://github.com/MetricsGrimoire/RepositoryHandler.git
  • cvs (optional, for CVS support)
  • subversion (optional, for SVN support)
  • git (optional, for Git support)
  • Python MySQLDB (optional but recommended)
  • Python SQLite (optional)

Insatalación de CVSAnalY.

Antes de instalar CVSAnalY debemos tener instalado MySQL. Después crearemos un directorio donde instalarlo, realizaremos una clonación desde su repositorio y, para finalizar, ejecutaremos la instalación:

$ mkdir CVSAnalY
$ cd CVSAnalY/
$ git clone https://github.com/MetricsGrimoire/CVSAnalY.git
Cloning into CVSAnalY...
remote: Counting objects: 2802, done.
remote: Compressing objects: 100% (782/782), done.
remote: Total 2802 (delta 2000), reused 2795 (delta 1993)
Receiving objects: 100% (2802/2802), 1.48 MiB | 117 KiB/s, done.
Resolving deltas: 100% (2000/2000), done.

$ git clone https://github.com/MetricsGrimoire/RepositoryHandler.git
Cloning into RepositoryHandler...
remote: Counting objects: 584, done.
remote: Compressing objects: 100% (160/160), done.
remote: Total 584 (delta 421), reused 565 (delta 414)
Receiving objects: 100% (584/584), 115.33 KiB | 73 KiB/s, done.
Resolving deltas: 100% (421/421), done.

$ cd RepositoryHandler
$ sudo python setup.p install
$ cd CVSAnalY
$ sudo python setup.p install

Para comprobar si funciona ejecutar desde dentro del directorio CVSAnalY lo siguiente:

$ ./cvsanaly2 --help

NOTA: Si no está instalado el conector de Python con MySQL instalarlo con:

$ sudo apt-get install python-mysqldb

Teóricamente ya lo tenemos perfectamente instalado. El siguiente paso es descargarnos un repositorio y analizarlo.

Analizando GIT con CVSAnalY.

Primero nos descargaremos el repositorio de GIT, después crearemos una instancia de base de datos vacía en MySQL y para finalizar ejecutaremos CVSAnalY para extraer los datos del repositorio.

$ mkdir analisis

$ cd analisis

$ git clone https://github.com/git/git.git
Cloning into git...
remote: Counting objects: 146525, done.
remote: Compressing objects: 100% (48847/48847), done.
remote: Total 146525 (delta 107068), reused 133313 (delta 95748)
Receiving objects: 100% (146525/146525), 33.65 MiB | 67 KiB/s, done.
Resolving deltas: 100% (107068/107068), done.

Ahora creo la instancia de base de datos

$ mysql -uroot -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 114
Server version: 5.1.61-0ubuntu0.11.04.1 (Ubuntu)

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights 

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input 

mysql> create database master_log_git_2013;
Query OK, 1 row affected (0.04 sec)

mysql> exit;
Bye

Y, para finalizar lanzo el análisis. Ojo, tenemos que saber el usuario administrador de la base de datos, su contraseña y el nombre de la instancia que le dimos anteriormente.

cd git

/analisis/git$ 

$ /home/suso/CVSAnalY/CVSAnalY/cvsanaly2 --db-user=root \
--db-password=XXXX --db-database=master_log_git_2013

Parsing log for /home/suso/analisis/git (git)
Warning: Detected empty branch 'master', it'll be ignored
Warning: Detected empty branch 'maint', it'll be ignored
Database looks empty, removing cache file /home/suso/.cvsanaly2/...
Executing extensions

Y, ahora, ¡A jugarrrrrrr!

Primero accedo a la base de datos, selecciono la instancia creada y después, por ejemplo, consulto el número de commits.

suso@capta-ud32:~/analisis/git$ mysql -uroot -p
Enter password:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 122
Server version: 5.1.61-0ubuntu0.11.04.1 (Ubuntu)

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights 

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input 

mysql> show databases;

+--------------------------------+
| Database                       |
+--------------------------------+
| information_schema             |
| db_prueba                      |
| fm3_audacity_cvsanaly2_cvs_scm |
| fm3_brasero_cvsanaly2_svn_scm  |
| fm3_evince_cvsanaly2_svn_scm   |
| master_log_git                 |
| master_log_git_2012            |
| master_log_git_2013            |
| master_log_hg                  |
| master_log_svn                 |
| mysql                          |
| testing_project                |
+--------------------------------+
12 rows in set (0.05 sec)

mysql> use master_log_git_2013;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

mysql> select count(*) from scmlog;
+----------+
| count(*) |
+----------+
|    32866 |
+----------+
1 row in set (0.00 sec)

mysql>

NOTA: la documentación la podemos encontrar en el directorio: CVSAnalY/help/doc

 

Lo prometido es deuda.

Al principio os prometí que os indicaría como obtener la territorialidad de un proyecto, en este caso para GIT y sólo para el año 2012, ¡pues vamos a ello!

La territorialidad se podría definir como:

Territorialidad = (Ficheros_tocados_único_desarrollador/Ficheros_totales) * 100

Lo primero es saber cuántos ficheros han sido modificados por un solo desarrollador, eso se puede hacer con la siguiente query:

mysql> select a.file_id,count(distinct(s.author_id))
    -> from actions a, scmlog s
    -> where a.commit_id=s.id and year(s.date)=2012
    -> group by a.file_id
    -> having count(distinct(s.author_id))=1;

|    3340 |                            1 |
|    3352 |                            1 |
|    3353 |                            1 |
|    3354 |                            1 |
|    3356 |                            1 |
+---------+------------------------------+
534 rows in set (2.24 sec)

mysql>

Ahora obtenemos el número total de ficheros modificados:

mysql> select count(distinct(a.file_id)) from actions a, scmlog s
    -> where a.commit_id=s.id and year(s.date)=2012;
+----------------------------+
| count(distinct(a.file_id)) |
+----------------------------+
|                       1046 |
+----------------------------+
1 row in set (1.16 sec)

mysql>

Entonces la territorialidad quedaría como:

Territorialidad = (534/1046) * 100 = 51%

Esto significa que más de la mitad de los ficheros han sido tocados por un único desarrollador. Según lo que nos han indicado en clase un valor por debajo del 80% es aceptable, con lo que GIT, en lo relativo a la territorialidad está bien.

Conclusión final.

Esta es mi primera incursión en el análisis de repositorios y me parece muy interesante. El principal problema que me encuentro es saber construir la consulta (query) de forma correcta para obtener lo que quiero, no sé si existe, pero creo que sería una buena idea crear algún interfaz con las consultas más típicas para extraer dicha información de la base de datos de CVSAnalY, bueno, aunque no soy programador a lo mejor me animo.

Espero que os haya resultado interesante, hasta otra …

 

Enlaces de interés:

 

Publicado en Casos de estudio I, Evaluación de proyectos, Gestión de proyectos | Etiquetado , , , , , , | Deja un comentario

¿Cuál es la razón del poco uso de Software Libre por la Administración?

Hace tres o cuatro días buscando por Internet me encontré con una entrevista a Ramón Ramón Sánchez, Consultor Internacional en Tecnologías de la Información, dónde le preguntan sobre este asunto y me ha parecido interesante comentarlo.

Además, en él aparce un vídeo de la comisaria europea Neelie Kroes donde habla de la necesidad de implantar el Software Libre en Europa y de los proyectos que ha estado realizando la Comunidad al respecto como OSOR.

 Solo quiero daros unas pinceladas extraídas del mismo y os recomiendo que lo leáis.

  • Según el BOE la Administración va a gastar este año 30 millones de Euros en licencias de software privativo, fundamentalmente de Microsoft.
  • Deberían cumplirse las leyes que garantizan la libre competencia e imparcialidad de la Administración ante licitaciones públicas pero realmente no sucede así.
  • Las grandes marcas y consultoras se ven favorecidas porque no se cumplen las leyes de forma correcta y transparente.
  • El desconocimiento y la mala información interesada son factores fundamentales que cierran el camino del Software Libre en la Administración.
  • Las grandes consultoras y empresas internacionales del sector tienen muchas más ventajas debido a sus casi ilimitados recursos y al chantaje que ejercen debido a su importante número de empleados. Saben usar muy bien sus caramelos envenenados.
  • Latinoamérica en general y Brasil y Paraguay en particular se están convirtiendo en potencias mundiales gracias al impulso del software libre aunque la falta de técnicos cualificados está frenando un poco este proceso.
  • La Junta de Andalucía se ha ahorrado 180 millones de Euros al usar software libre, pero ha habido otros tipos de ahorro debidos a un funcinamiento más eficiente de los productos.
  • Microsoft presentó una denuncia el pasado 26 de marzo reclamando sus derechos patrimoniales a la Junta de Andalucía, incluyendo en su reclamación a los 600,000 ordenadores con el sistema operativo libre llamado Guadalinex. Las Administraciones deberían luchar todo este tipo de casos ya que están jugando con el dinero de todos.
  • Con los convenios Gobierno-Microsoft se dan “caramelillos envenenados” para mantener a las sociedad esclava del software privativo.
  • Esto llega a su máxima intensidad en los colegios donde nuestros niños, desde su más corta infancia sólo pueden ver una cara de la moneda y no precisamente la mejor. Con esas técnicas se mantien cautivas a las generaciones venideras.
  • Microsoft está viendo que el software libre está ganando reputación y tiene que subirse de alguna forma a ese carro si no quiere quedarse atrás en un futuro.
  • La seguridad jurídica del software libre se basa en tres pilares: las licencias libres, las leyes que favorecen la independencia y el uso desde hace años por parte de algunas empresas y organismos oficiales.
  • La entrada en juego de Android ha tirado por tierra una serie de leyendas urbanas que asimilaban al software libre como algo poco eficiente y difícil de usar.
  • Más del 90% de servidores usan software libre.
  • Google o Pixar también lo hacen.
  • El 29% del software que se desarrolla en Europa es libre y el 43% en USA.
  • Las empresas privada colaboran en un 15% al software libre
  • El promedio de participación del software libre en la economía era el 4% del PIB europeo para el año 2010.

 

Conclusiones

Está claro que el software libre puede hacer mucho por la sociedad, si le dejan, aunque hay muchos intereses creados que ponen palos en la rueda para que la bicicleta vaya más despacio.

Hasta otra …

Referencias:

Publicado en Aspectos económicos, Aspectos legales, Casos de estudio I, Introducción | Etiquetado , , , | Deja un comentario

El repositorio de código distribuido Git, primeros pasos.

Es este post voy a hablar un poco de los sistemas de control de versiones (VCS), fundamentalmente de los repositorios de código distribuidos y en particular de Git.

Repositorios de código distribuidos

En los últimos años la tendencia dentro del desarrollo de software es pasar de repositorios de código centralizados a repositorios distribuidos.

En los repositorios centralizados, como su propio nombre indica, hay un único repositorio central contra el que se sincroniza todo el mundo y es en este repositorio donde se almacena el código y se mantiene toda la información del proyecto: histórico, ramas, etiquetas, etc.. Sus principales ventajas son que todo desarrollador sabe donde está el repositorio y además “puede saber” lo que están haciendo los otros y para los administradores es fácil gestionar los permisos y el propio repositorio en si. Y las principales desventajas son que al ser único cualquier problema en el mismo puede llevar desde su posible inaccesibilidad temporal hasta la pérdida de toda la información, si no se tienen unos correctos y probados  procedimientos de backup y recuperación. Son ejemplos de este tipo: CVS y Subversion.

Los repositorios distribuidos  son aquellos en los que la idea de un repositorio central no existe como tal, éste está distribuido, es decir cada uno de los desarrolladores tiene una copia en local con toda la información: históricos, ramas, etiquetas, etc. con lo que no se necesita estar conectado para realizar operaciones contra el repositorio. Cuando el grupo de trabajo es grande se puede disponer de un lugar donde mantener una copia pública del repositorio, como GitHub o Gitorius, para no tener que estar sincronizando continuamente con el de los demás miembros del grupo, pero no sería imprescindible. Una ventaja de este sistema es que si hay algún problema con el servidor donde se mantiene la copia pública del repositorio se podría montar uno nuevo simplemente copiando el contenido de “cualquiera” de los repositorios locales de cualquiera de los desarrolladores. Al trabajar contra el repositorio local también se gana en velocidad ya que no es necesario acceder a la red para realizar las actualizaciones pero al cargarlo por primera vez se descarga una copia completa con lo que esta primera acción puede ser costosa. Que cada uno disponga de una copia del repositorio podría llegar a crear grandes divergencias en el código si no se realiza de forma cuidadosa y organizada, pero esto también puede suceder en los repositorios centralizados es, en principio, una cuestión de trabajo organizado en grupo. Son algunos ejemplos de este tipo: Git, Mercurial, Bazaar y Darcs.

Git, un poco de historia

Git fue desarrollado en 2005, inicialmente por Linus Torvalds, creador del kernel de Linux, para el mantenimiento de dicho kernel. Para su creación surgieron dos razones fundamentales, la primera que se rompió el acuerdo para usar la licencia de forma gratuita con, BitMover, la empresa que desarrollaba BitKeeper, software privativo de control de versiones distribuido que usaban desde 2002, por desavenencias con la comunidad de desarrolladores ya que dicho acuerdo les impedía trabajar en productos libres que fuesen competencia directa suya, siendo la gota que colmó el vaso para BitMover el desarrollo por parte de Andrew Tridgell  de un cliente libre de BitKeeper. Y, la segunda, que ninguno de los sistemas de control de versiones que existían en esos momentos cumplía los requisitos que necesitaban que eran fundamentalmente:

  • Velocidad
  • Diseño sencillo
  • Fuerte soporte para desarrollo no lineal (cientos de ramas en paralelo)
  • Totalmente distribuido
  • Capaz de manejar grandes proyectos de forma eficiente (velocidad y tamaño de datos)

Por tanto, Git es un sistema de control de versiones distribuido diseñado para gestionar proyectos grandes y pequeños de forma eficiente y rápida. Es software libre con licencia GPLv3. Hay disponibles versiones para Linux, Solaris, Mac OS X y Windows.

Instalación de Git

La instalación de Git es muy fácil, en Ubuntu sólo hay que hacer:

$sudo apt-get install git-core

Configurando Git

Lo primero es decirle a Git quienes somos para que sepa quien está realizando la tareas sobre el repositorio. Esto se puede hacer de forma global  (–global) o por repositorio independiente.

$ git config --global user.name "Suso"
$ git config --global user.email "suso@suso.com"

De forma global crea el fichero .gitconfig en el home del usuario. Si queremos sobreescribir esta información en alguno de los repositorios locales ejecutaríamos lo mismo pero sin la opción global dentro del directorio raíz del repositorio, de esta forma se modificaría el fichero .git/config.

Inicialización del repositorio

Lo primero que vamos a hacer es crear un directorio donde realizaremos el desarrollo de software y del que queremos generar el repositorio. Mediante init vamos a crear el repositorio local asociado a ese directorio. Con este paso hemos creado ya el repositorio local.

$ mkdir android
$ cd android
$ git init

Trabajo en repositorio local

Git tiene una forma de trabajar peculiar porque usa una especie de índice intermedio donde vamos añadiendo los ficheros antes de subirlos al repositorio local. Esa tarea se hace mediante la opción add. Una vez finalizada la edición de los ficheros, todos los que queramos subir al repositorio antes tienen que ser añadidos de esa forma. Para saber que ficheros están esperando a ser subidos se puede hacer de dos formas, bien con la opción diff o con la opción status. Para finalizar, mediante la opción commit se suben o actualizan en el repositorio local.

$ git add main.c server.c server.h

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   main.c
#   modified:   sercer.c
#   modified:   server.h
#

$ git commit

De esta forma ya tenemos nuestro repositorio local actualizado.

Trabajo con repositorios remotos

Pero si queremos tener una copia de nuestro repositorio en un lugar público para compartir nuestro código o para mantener una copia de seguridad podemos usar:

  • git pull . Bajamos las actualizaciones de un repositorio remoto.
  • git push. Subimos nuestras modificaciones a un repositorio remoto.
  • git clone git://github.com/suso/Git_test.git. Hacemos un clonado en local del repositorio remoto Git_test

Aquí os dejo un gráfico explicativo del funcionamiento obtenido de wikipedia.

Conclusiones

Para los no expertos en estos asuntos es un poco lio esto de los sistemas de control de versiones, además escoger bien la forma de trabajar en grupo es fundamental para no llevarte sorpresas desagradables. Todavía sigo buscando un documento fácil y conciso de buenas prácticas en el desarrollo de software en grupo usando sistemas de control de versiones pero no consigo hallar nada que me convenza, a lo mejor es porque no soy programador y no los comprendo bien, ¿quién sabe? de todas formas prometo no cejar en el empeño porque el tema es realmente interesante.

Hasta otra …

Referencias:

Publicado en Casos de estudio I, Evaluación de proyectos, Gestión de proyectos, Herramientas de desarrollo, Introducción | Etiquetado , , , , , | Comentarios desactivados

R y RStudio, instalación y primeros pasos.

En este post voy a realizar una pequeña introducción a R y RStudio, dividida en tres partes: definiciones, instalación y primeros pasos.

¿Qué es R?

R es un proyecto de software libre de GNU y se podría definir desde dos puntos de vista, por una parte es un lenguaje de programación y por otra un entorno de trabajo, estando ambos orientados al cálculo estadístico y a la generación de gráficas.

Como lenguaje de programación proporciona una amplia variedad de técnicas y recursos para el trabajo con gráficas y análisis estadístico y, a su vez,  es altamente ampliable. Cuenta con una comunidad extensa de desarrolladores, investigadores y usuarios. Se distribuye con licencia GNU GPL v2 y está disponible para distintos sistemas operativos de tipo Unix y similares  (FreeBSD y Linux), Windows y  Mac OS.

Como entorno de trabajo se entiende como un sistema totalmente planificado y coherente y no una acumulación incremental de herramientas muy específicas y poco flexibles, como es frecuentemente el caso con otro software de análisis de datos. En este caso el entorno de trabajo R nos proporciona una serie de utilidades para manipulación de datos, cálculo y representación gráfica.

¿Qué es RStudio?

RStudio es un entorno de desarrollo integrado (IDE) para R. Es software libre con licencia GPLv3 y se puede ejecutar sobre distintas plataformas (Windows, Mac, or Linux) o incluso desde la web usando RStudio Server.

Instalación de R y RStudio (en Windows).

Aunque Windows no es software libre, R y RStudio sí lo son y si os pasa como a mi, que el portátil que uso es compartido y tiene Windows, pues habrá que obviar el sistema operativo y usar software libre para todo lo demás.

En este apartado voy a describir la forma de instalar R y Rstudio.

Primero hay que instalar R y para ello descargamos del  sitio oficial de R la última revisión estable, la 2.15.0, pulsando en  Windows (en mi caso) y después pulsando en base y de ahí nos bajamos R-2.15.0-win.exe. Haciendo doble click sobre el fichero comenzamos la instalación. Saldrá el típico aviso de Windows de que no se puede comprobar el editor, no le hacemos caso y pulsamos en ejecutar. A veces también sale otra ventana indicando que hay que permitir la ejecución del paquete ya que requiere privilegios de administrador.

Después solicita el idioma de instalación

A continuación, arranca el Asistente de instalación, pulsar siguiente.

Después informa sobre el tipo de licencia, pulsar siguiente.

A continuación nos indica la ruta de instalación, pulsar siguiente.

Ahora seleccionamos los paquetes a instalar, pulsar siguiente.

Después nos pregunta si queremos usar las opciones de configuración o no, por defecto aparece no y aquí tampoco nos vamos a complicar demasiado, pulsar siguiente.

Elegir la carpeta del menú inicio donde colocar los accesos directos a los elementos del  paquete, pulsar siguiente.

Selección de las tareas adicionales: crar icono en el escritorio, …, pulsar siguiente.

En este preciso instante se inicia el desempaquetado e instalación de la aplicación que tardará muy poco, en mi caso uno 50 segundos apróximadamente.

Una vez finalizada el proceso de instalación sale una ventana indicándolo. Pulsar Finalizar.

Ya nos aparecerá el correspondiente icono en el escritorio.

Ahora sólo nos falta arrancar y ver que pasa.

Ahora voy a instalar RStudio, para ello descargo la última versión estable (0,96 en estos momentos) del sitio oficial de RStudio. En mi caso he descargado RStudio-0.96.304.exe para Windows, si tenemos R corriendo en un servidor Linux, existe una versión para  instalarla en dicho servidor y ejecutarla desde un navegador web que no voy a describir en estos momentos.

Comienzo ejecutando el instalador anteriormente descargado y, como en el caso anterior, nos volverá a salir el típico aviso de Windows de que no se puede comprobar el editor, no le hacemos caso y pulsamos en ejecutar. A veces también sale otra ventana indicando que hay que permitir la ejecución del paquete ya que requiere privilegios de administrador.

A continuación, aparece el Asistente de instalación, pulsar siguiente.

Después nos pide el lugar de instalación del paquete, pulsar siguiente.

Elegir la carpeta del menú inicio donde colocar los accesos directos a los elementos del  paquete, pulsar Instalar.

Y comienza la instalación que dura menos de un minuto (en mi caso).

y, para finalizar aparece el asistente indicando que ha finalizado la instalación. Pulsar Terminar.

Como no marqué la opción de Accesos directos tres pantallas más atrás me he tenido que crear a mano el acceso en el escritorio, pero ese no es un asunto de este post. Quedando como sigue.

Al arrancar Rstudio nos aparece lo siguiente:

Como podemos ver y si no queremos complicarnos mucho, esta es un típica instalación en Windows del tipo siguiente, siguiente, siguiente.

 Primeros pasos con R

Vamos a realizar RStudio para dar estos primeros pasos ya que es un entorno más amigable que R.

Comencemos por describir someramente lo que tenemos en pantalla. Aparte de la línea de menús en pantalla aparecen cuatro ventanas: Ficheros abiertos (superior izquierda), Workspace-History (superior derecha), Console (inferior izquierda) y Files-Plots-Packages-Help (inferior derecha).

Nosotros vamos a introducir los comandos en Console y los resultados, bien se obtendrán en la misma ventana bien en la que está justo encima, a no ser que sea un gráfico que aparecerá en la sección Plot de la ventana inferior derecha.

Si necesitamos ayuda podemos ir directamente a la sección de ayuda (Help) del menú de opciones para resolver cuestiones sobre R o Rstudio y en la pestaña Help de la ventana inferior derecha es específica de R. Otra forma muy rápida consiste es ecribir ?plot() en la Consola y nos saca la ayuda de la función plot en la ventana inferior derecha.

Vamos a comenzar escribiendo el típico “Hola Mundo” de todos los inicios de programación con un lenguaje nuevo. Para ello vamos a Console y escribimos:

> hola.mundo <- function() {cat("¡Hola Mundo!\n")}
> hola.mundo()
¡Hola Mundo!

Con esto (la primera línea) lo que hacemos es crear un nuevo objeto hola.mundo que es de tipo función y al que le asignamos una tarea (lo que hay ente llaves) y al ejecutarlo (segunda línea) se le dice a R que realice la tarea asociada a dicha función, es decir, que escriba ¡Hola Mundo!

Bueno ahora vamos a ver algo más “interesante”, es decir, voy a usar R como una calculadora básica.

> a=1
> b=2
> c=3; d=4
> a+b+c+d
[1] 10
> a-d
[1] -3
> c/d
[1] 0.75
> a
[1] 1
> b
[1] 2
> 2 * pi
[1] 6.283185

En este ejemplo asigno valores y realizo operaciones matemáticas básicas con ellos. Algo muy sencillo y básico para lo cual no necesitamos tanta potencia de cálculo.

Damos un pasito más y vemos una parte muy interesante, la generación de gráficos. Para ello voy a generar el fichero de texto que os muestro a continuación.

Ahora lo importo a R y genero la gráfica correspondiente.

> datos <- read.table("D:/MSWL/datos_R.txt", sep=";", quote="\"")
> View(datos)
> plot(datos$V1, datos$V2, "h", xlab="Animales", ylab="Unidades", main="Arca de Noé")

Con la primera línea importo los datos a R. Con la segunda los muestro en la pantalla de salida de datos y con la tercera genero la gráfica.

Bueno, con esto último ya podemos dejar de usar MS Excel para generar gráficas.

Hasta otra …

Referencias:

Publicado en Casos de estudio I, Herramientas de desarrollo, Introducción | Etiquetado , , , , , | Deja un comentario

Organización de la Comunidad KDE

Nos presenta la charla Albert que nos va a hablar de la organización de la Comunidad KDE.

Albert Astals Cid, es presidente de KDE España y lleva colaborando con KDE desde el año 2003. Es coordinador de las traducciones de KDE, mantenedor de Okular (visualizador de documentos),  poppler (librería de renderizado de ficheros pdf) y actualmente trabaja en Canonical.

 

¿Qué es KDE?

Es un equipo internacional, con matriz en Alemania, como se puede ver en la tabla de más abajo (obtenida del número del 27/05/2012 de commit-digest.org), que desarrolla software, hasta hace poco sólo desarrollaba el famoso escritorio de GNU/Linux pero actualmente el escritorio es sólo una parte de KDE (todavía sin nuevo nombre definido).

KDE es software libre bajo múltiples licencias, todos los servicios que ofrecen están sustentados a su vez por software libre y todas las herramientas que se usan para su desarrollo también son software libre.

KDE tiene fundamentalmente un escritorio que funciona sobre distintos plataformas, teléfonos móviles, tablets, ordenadores portátiles, etc., pero KDE tiene más aplicaciones con el objetivo de proporcionar al usuario todo lo que necesite para trabajar. Entre ellas cabe destacar un visor de documentos, un navegador web, un reproductor de música, una tabla periódica, juegos, etc.  Existen traducciones a 70 idiomas y está portado a distintos sistemas operativos, fundamentalmente GNU/Linux, pero también Mac OS X, Solaris, Windows, entre otros.

 

Un poco de Historia

KDE nace el 14 de octubre de 1996 cuando Matthias Ettrich lanza una llamada al colectivo de desarrolladores  a  través de Usenet (comp.os.linux.development.apps) para crear un escritorio para el usuario final ya que lo que hay en ese momento en el mercado o es muy caro (CDE) o no se adecua a lo que el usuario final necesita. En agosto de 1997 se realizó la primera reunión de programadores (KDE-ONE Meeting) con 15 asistentes de todo el mundo y en diciembre del mismo año y para evitar posibles problemas de copyright, patentes y marca se creó la asociación sin ánimo de lucro KDE e.V., con base en Alemania, y que representa de forma legal a KDE siendo también la dueña de la marca en Europa y EEUU, no toma parte en el desarrollo pero sí ayuda económicamente y en tareas de organización. Está compuesta por 162 miembros entre los que se elije a la junta directiva de 5 miembros en asamblea general por un periodo máximo de 3 años. Unos meses después, abril de 1998,  se creó la KDE Free Qt Foundation, formada por 2 representantes de Qt (Nokia) y 2 de KDE, para evitar problemas debidos a Qt que no dependía de KDE. Y en Julio de 1998 salió KDE 1.0, casi dos años después de su nacimiento. En octubre de 1999 se realiza el segundo encuentro con 40 participantes. En septiembre de 2000 Qt se pasa a licencia GPLv2 ya que tenía anteriormente una licencia propia denominada QPL aunque reconocida por la OSI y anteriormente FreeQT no reconocida ni por la FSF ni por la OSI. Después se van sucediendo las versiones y los encuentros que en 2004 empiezan a llamarse aKademy. La versión actual estable es la 4.8 de enero de 2012.

 

Licenciamiento

KDE, al ser un elemento tan complejo está liberado bajo múltiples tipos de licencia dependiendo del tipo de elemento de que se trate, entre las que están:

  • LGPL versión 2.1 or later
  • BSD
  • MIT
  • X11
  • GPL 2 or later
  • FDL 1.2 or later

 

Comunidad KDE

  • No existe un dictador benevolente, tipo Linus Torvalds en el proyecto del kernel de linux que mande en el proyecto
  • Lo que sí existe es un equipo Core, que marca pautas, que está basado en la meritocracia y al que pertenecen los miembros por su valía y por el tiempo que has estado colaborando.
  • Existen varias subcomunidades: KDEGames, división de juegos; KDEEdu, división educativa; amarok, reproductor musical; etc.
  • Las comunicaciones se realizan mediante listas de corro e IRC. Existen foros pero para usuarios, los desarrolladores no se suelen pasar por él.
  • En KDE a los desarrolladores se les conoce como sprints.
  • Suelen ser amigables con la gente nueva.
  • En KDE hay sitio para todos: traductores, artistas,  comprobadores de usabilidad, probadores, documentalistas, promotores, empaquetadores, desarrolladores, …

Estadísticas de commiters que colaboran en KDE. Fuente ohloh de mayo de 2012.

Estadísticas de commits en KDE. Fuente ohloh de mayo de 2012.

¿Relaciones empresariales de KDE?

  • The Kolab Konsortium: Trabajan para la administración alemana.
  • KO GmbH: Da soporte comercial a Calligra.
  • Collabora.
  • Distribuidores y que hacen despliegues.
  • Compañías cuyos dueños son desarrolladores de KDE.

 

KDE España

  • Representa a KDE en España.
  • Tiene 30 miembros en la actualidad.
  • Han organizado 4 Akademy-es (2 no oficiales).
  • Reune a todos los colaboradores y entusiastas de KDE para promover KDE en España.

 

Referencias:

Publicado en Aspectos legales, Casos de estudio II, Desarrolladores y su motivación, Evaluación de proyectos, Gestión de proyectos, Herramientas de desarrollo, Introducción | Etiquetado , , , , , , | Deja un comentario

Del caos al orden. Cómo funciona y se organiza Wikipedia.

Presentación realizada por Miguel Vidal.

En esta presentación Miguel Vidal nos habla de la Wikipedia y de su experiencia como bibliotecario en ella.

Miguel Vidal estudió Filología Hispánica y es docente e investigador en LibreSoft, grupo dedicado a la ingeniería del software libre en la Universidad Rey Juan Carlos. Ha participado en el diseño y despliegue de la infraestructura de proyectos como OSO-R (Open Source Observatory Repository) y de Morfeo; también se ha encargado de la infraestructura y los sistemas de apoyo a proyectos de investigación de GSyC/LibreSoft. Ejerce docencia en algunas de las asignaturas del Máster oficial de Software Libre de la URJC y en el Master en Economía Digital e Industrias Creativas de la Escuela de Negocios EOI. Es a su vez, el responsable del Curso de Arquitectura de Servidores con Software Libre, un título propio de la URJC. LLeva desde 1999 participando en actividades diversas de la comunidad del software libre española y en proyectos de difusión del software libre y de la cultura libre. Es experto en temas legales relacionados con el software libre y es  bibliotecario (sysop) de la Wikipedia en español desde 2007, donde ha realizado más de 11.500 ediciones , ha contribuido en más de 2500 artículos y creado más de 158 artículos nuevos. Ha pronunciado numerosas conferencias divulgativas en ámbitos muy diversos sobre todos estos temas, en particular sobre licencias libres, software libre y Wikipedia.

 

 

La Wikipedia no es

  • Wikipedia NO es un diccionario ni es de papel. No se dedica a definir lingüísticamente las palabras y al no ser de papel no hay limitación al número de palabras o artículos. Se pretende hacer una eniclopedia.
  • Wikipedia NO es un editor de pensamientos originales. No se pretende buscar puntos de vista originales. Se levanta acta de un conocimiento en una materia determinada sin aportar nada extra. Los artículos enciclopédicos deben describir y explicar y no calificar o valorar.
  • Wikipedia NO es una tribuna de opinión. Al principio aparecieron muchos blogger que se pusieron a editar artículos dándoles su  impronta personal pero esa no es la idea, como he dicho antes, sólo se pretende dar una información sin adornos que la modifiquen, por eso el uso de muchos adjetivos y especialmente los epítetos no está bien vista.
  • Wikipedia NO es un almacen de enlaces, imágenes o archivos. No es un repositorio de nada. Los enlaces sirven para ilustrar el contenido del artículo con referencias
  • Wikipedia NO es un alojamiento de paginas web, blogs o una red social. No tiene como propósito conocer gente, el fin de wikipedia es hacer una enciclopédia libre. Las polémicas que se suscitan referentes a artículos son sobre la forma del mismo, es decir, sobre la redacción y no sobre el contenido del mismo.
  • Wikipedia NO es una colección de información sin criterio.  No es Google ni pretende serlo. La información está organizada.
  • Wikipedia NO es una bola de cristal. No se pueden anticipar acontecimientos, no se puede escribir sobre acontecimientos que no hayan sucedido todavía.
  • Wikipedia NO está censurada.  Si algo se borra es porque incumple alguna política. Pero sí se deja publicar, no hay un filtro previo a la publicación para permitir o no la publicación y al detectarse se borra pero se ha llegado a publicar. Las páginas están siendo vigiladas por personas registradas para evitar la inclusión vandálica de contenidos.
  • Wikipedia NO es un experimento de anarquía.  Se dice que es anárquico porque cada uno hace lo que quiere aunque eso no es realmente cierto ya que hay unas normas que cumplir y unas conductas que mantener.
  • Wikipedia NO es una democracia. Tampoco es una burocracia. No es un sitio dónde se realizan experimentos democráticos, se intenta llegar al consenso sobre los artículos y en último caso se realiza una votación.
  • Wikipedia No es una plataforma educativa. Sirve para muchas cosas pero su fin u objetivo fundamental no es educar por lo que no tienen estructura docente, no hay ejercicios ni ejemplos ni estructuras en temarios o similares. Para eso está el proyecto de la Wikiversidad.
  • Wikipedia No es una fuente primaria de información. Su función no es crear un foro de desarrollo del conocimiento ni para desarrollar ideas originales o novedosas. No es un lugar para realizar ejercicios o experimentos ni para realizar revisiones o evaluaciones científicas.
  • Wikipedia No es una fuente de información autorizada. Es un punto de partida donde comenzar una investigación pero no puede ser referenciada como una fuente de información válida en si misma. Siempre hay que cotejar los datos obtenidos con otras fuentes para confirmar su validez, pero esta debe ser una forma de actuar común cuando se localiza información por Internet y no sólo con la wikipedia.

Tipos de fuentes de información:

  • Fuente primaria: un documento, por ejemplo una sentencia judicial.
  • Fuente secundaria: cómo un periódico explica la sentencia.
  • Fuente terciaria: es una obra de consulta, por ejemplo al Enciclopedia Británica o la Wikipedia.

No debemos incluir en la Wikipedia artículos que:

  • mencionan hechos o eventos no refrendados por ninguna fuente.
  • introducen nuevos métodos o técnicas no documentadas.
  • introducen nuevas teorías, conceptos o términos.
  • rede finen o reformulan de manera original términos y teorías ya existentes.
  • argumentan en contra de una teoría o idea documentada sin hacer mención de una publicación aceptable como fuente de los argumentos.
  • contienen documentos históricos de primera mano; si la licencia lo permite, estos pueden trasladarse a Wikisource.

 

La wikipedia es

  • Una enciclopedia libre escrita de forma colaborativa por miles de voluntarios de todo el mundo usando tecnología wiki, que facilita la construcción de la enciclopedia siendo éste un medio y no un fin.
  • Disponible en numerosas lenguas, autónomas entre sí, que comparten ciertos recursos. No están divididos por países sino por lenguas.
  • Todas las ediciones comparten 5 pilares básicos.

Los cinco pilares de la Wikipedia

  • Wikipedia es una enciclopedia.
  • Wikipedia busca el punto de vista neutral. Es decir, recoger todos los puntos de vista relativos a un tema con sus correspondientes pesos para que quede constancia de la fuerza de cada punto de vista.
  • Wikipedia es de contenido libre.
  • Wikipedia sigue unas normas de etiqueta. Presumir buena fe, no sabotear, etc.
  • Wikipedia no tiene normas firmes, a parte de estas cinco.

¿De quién es la Wikipedia?

Wikipedia pertenece a todos los wikipedistas aunque la Wikimedia Foundation es la dueña de la marca y la encargada de gestionar y mantener  la infraestructura que da cobijo a la Wikipedia.

Tipos de usuarios en Wkipedia.

  • Anónimo: Puede editar artículos o crear artículos nuevos.
  • Registrado: página propia, preferencias, lista de seguimiento, uploads.
  • Bibliotecario (admin, sysop)
  • Burócrata (bureaucrat)
  • Bots: automatizan tareas tediosas (typos, interwikis, enlaces muertos, reversiones. . . )

El papel de los bilbiotecarios en la Wikipedia

Los bibliotecarios, como hemos visto anteriormente, son usuarios con una serie de tareas reservadas entre las que están la posibilidad de borrar páginas e imágenes, bloquear y desbloquear usuarios registrados e IPs de usuarios anónimos, proteger y desproteger páginas, editar páginas bloqueadas, ver y restaurar páginas e imágenes borradas, ver las contribuciones borradas de un usuario y ver la lista de páginas sin vigilar.

Lo bibliotecarios no son dueños ni empleados de Wikipedia y tampoco tienen más derechos o autoridad que cualquier otro miembro y tampoco ponen normas. Las normas se fijan por consenso o votación entre todos los wikipedistas.

En febrero de 2012, en la Wikipedia en español hay 139 bibliotecarios, 91 de ellos activos. Uno de cada 15.190 usuarios y uno de cada 110 usuarios activos (realizan 2 o más ediciones al día de media) es bibliotecario.

Los bibliotecarios se eligen entre cualquier usuario con 100 ediciones y un mes de permanencia. La comunidad valora el trabajo realizado por el candidato en Wikipedia y se realiza una votación entre los miebros de la comunidad que dura 15 días. Si el candidato obtiene al menos un 75% de votos a favor es elegido. Pierde su condición de bibliotecario de ofi cio si no edita en dos años.

Conclusiones

El fin de la Wikipedia pretende ser una enciclopedia de contenido libre que puede usarse como fuente de inspiraciópn para iniciar una investigación pero no como fuente de información autorizada. Como en todo lo que hay por internet, siempre hay que cotejar las fuentes para poder obtener datos correctos.

Una forma muy buena de colaborar con la Wikipedia es traducir artículos de otros lenguajes que tengan una calidad ya contrastada antes que iniciar un artículo propio de menor calidad.

Hasta otra …

Referencias:

Publicado en Aspectos legales, Casos de estudio II, Desarrolladores y su motivación, Herramientas de desarrollo, Introducción | Etiquetado , , , , , | Deja un comentario