Software libre vs código abierto

A propósito he puesto un título polémico y sugerente de una “guerra santa”, pero sólo con la intención de atraer a aquella gente fanática que gusta de crear polémica con este tema y compartir con ellos mi visión de como enfrentar la diversidad en las comunidades entorno al software libre.

Principios y colaboración

Hay un patrón que se repite en el desarrollo de proyectos colaborativos y tiene relación con la típica misión y visión que se plantean las empresas, pero por el contrario estos tienen una connotación más real que formal, son en general estos principios nacen de las bases y se comparten como una necesidad efectiva en la organización.

No son una careta, son una guía real de empoderamiento, encauzan la toma de decisiones a base del contraste de estos principios con el sentido común, lo que permite la participación de todos agentes involucrados con el progreso del proyecto.

En general en proyectos exitosos, estos principios son:

• Simples y claros.
• Se originan por necesidades fundamentales.
• Se mantienen estáticos a pesar de la evolución propia del proyecto.

En caso que estos principios sean modificados, entonces se inicia una “fork” del proyecto original y se debe dejar claro, para ser transparentes con la comunidad, que al diferir de sus principios estos serán proyectos distintos y no debe existir ambigüedad en eso.

Para aterrizar el tema voy dar ejemplos de los principios en los cuales se basan algunos proyectos colaborativos:

Los proyectos de software libre:

• La libertad de ejecutar el programa, para cualquier propósito (libertad 0).
• La libertad de estudiar cómo trabaja el programa, y cambiarlo para que haga lo que usted quiera (libertad 1). El acceso al código fuente es una condición necesaria para ello.
• La libertad de redistribuir copias para que pueda ayudar al prójimo (libertad 2).
• La libertad de distribuir copias de sus versiones modificadas a terceros (la 3ª libertad). Si lo hace, puede dar a toda la comunidad una oportunidad de beneficiarse de sus cambios. El acceso al código fuente es una condición necesaria para ello.

Si nos fijamos de acuerdo a estos principios el software libre se construye para ser una satisfactor sinérgico de Entendimiento, Participación, Creación y mayor énfasis en la Libertad.

El proyecto de Wikipedia:

• Wikipedia es una enciclopedia.
• Wikipedia busca el «punto de vista neutral».
• Wikipedia es de contenido libre.
• Wikipedia sigue unas normas de etiqueta.
• Wikipedia no tiene normas firme.

Si nos fijamos los principios de Wikipedia no son tan simples de claros como los del software libre, requieren un poco más de explicación y muchas veces la ambigüedad del “punto de vista neutral” ha generado grandes polémicas, pero si nos damos el tiempo de leer los 5 pilares, la robustez de estos depende de que tan explícito es su relación con las necesidades fundamentales, por ejemplo la definición de contenido Libre es simple y clara y es un satisfactor sinérgico similar al software libre. El punto de vista neutral apunta a la necesidad de Entendimiento a través del diálogo y la expresión de todos los puntos de vista posibles, pero esto choca con nuestra concepción de la existencia de la verdad absoluta inculcada en nuestra sociedad temerosa de reconocer que somos ignorantes de los que nos rodea. Lo de las normas de etiqueta es un marco regulatorio para la Participación, pero decir que las normas no son firmes es para evitar que estas restrinjan la Participación.

Otro proyecto no tan conocido son:

Por ejemplo el Agile Software Development:

• A los individuos y su interacción, por encima de los procesos y las herramientas.
• El software que funciona, por encima de la documentación exhaustiva.
• La colaboración con el cliente, por encima de la negociación contractual.
• La respuesta al cambio, por encima del seguimiento de un plan.
• Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

No estoy tan  familiarizado con este proyecto, pero entiendo que busca mejorar de forma explícita la Participación y favorecer la Creación, la Identidad y la Libertad entre las personas que interactúan la solución de un problema utilizando herramientas computacionales.

El proyecto de Python:

• Bello es mejor que feo.
• Explícito es mejor que implícito.
• Simple es mejor que complejo.
• Complejo es mejor que complicado.
• Plano es mejor que anidado.
• Ralo es mejor que denso.
• La legibilidad cuenta.
• Los casos especiales no son tan especiales como para quebrantar las reglas.
• Aunque lo práctico gana a la pureza.
• Los errores nunca deberían dejarse pasar silenciosamente.
• A menos que hayan sido silenciados explícitamente.
• Frente a la ambigüedad, rechaza la tentación de adivinar.
• Debería haber una -y preferiblemente sólo una- manera obvia de hacerlo.
• Aunque esa manera puede no ser obvia al principio a menos que usted sea holandés.[18]
• Ahora es mejor que nunca.
• Aunque nunca es a menudo mejor que ya mismo.
• Si la implementación es dificil de explicar, es una mala idea.
• Si la implementación es fácil de explicar, puede que sea una buena idea.
• Los espacios de nombres (namespaces) son una gran idea ¡Hagamos más de esas cosas!

Muchos de estos principios pueden entenderse sin haber escrito una línea de código en nuestra vida, eso es algo rescatable en una buena redacción de principios, ya que buscamos que sean contrastables con el sentido común de cualquier persona que potencialmente tenga relación con el proyecto.

Pero, ¿Qué pasa con los proyectos colaborativos que abundan en nuestra sociedad?

En general están basados en principios vagos, complejos, nebulosos, cambian por intereses personales, confunden su relación con satisfactores en vez de las necesidades fundamentales, etc.

Por ejemplo: el proyecto país, un proyecto sistema educativo, el proyecto libre mercado, un proyecto de municipalidad, de junta de vecinos, de comunidad de pescadores, de agua potable rural o proyecto de riego. Todos son de alguna forma proyectos colaborativos, que tienen principios, pero que muchas veces son manipulados por quienes los gestionan o ignorados por la comunidad.

Revisemos que pasa con el el La competencia perfecta en un Libre Mercado:

• Muchos productores y consumidores.
• Las empresas vendan un producto homogéneo en el mercado.
• Las empresas y los consumidores tengan información completa y gratuita.
• No haya barreras de entrada o salida al mercado.
• Sin costos de Transacción.

Yo he sido un crítico de la competencia, pues mi sentido común choca con algunos principios, por ejemplo uno que no se nombra es la estrategia competitiva “defraudar sistemáticamente” que daña el Afecto y la Protección, creando un ambiente de desconfianza  y el otro de los productos homogéneos (mercado de las masas) que daña la necesidad de Identidad, para mí los otros principios son razonables y entendibles, lo impresionante es ver las inconsecuencias de estos con la realidad. La concentración de poder de negociación en pocos agentes, las barreras artificiales de entrada y salida que tienen los consumidores, la dificultad para acceder a la información (letras chicas, contratos inentendibles, cobros implícitos, etc.)

Eso me hace pensar que proyecto de gestión de los bienes públicos y privados a través de la Competencia perfecta tiene problemas de fondo y de forma. Los “economista” se han hecho cargo de los problemas de forma, pero obtusa estupidez se niegan a reconocer los problemas de fondo.

Lo importante es diferencias claramente entre la gestión de los bienes públicos y privados a través de la Competencia y el proyecto de Libre mercado, pero eso lo voy a dejar para otro artículo.

Osea, ¿En un proyecto colaborativo todos tomamos las decisiones?

Es este el punto que me originó la necesidad de escribir este este artículo, las mal definidas decisiones democráticas y de consenso. La forma en que se gestiona un proyecto colaborativo debe diferir diametralmente del concepto “gobierno de las mayorías”, pues en general eso atenta con la necesidad fundamental de Participación, Identidad, Subsistencia y Protección de las minorías y genera un fenómeno perverso de homogeneización de la diversidad intrínseca de los seres humanos (somos por naturaleza únicos e irrepetibles), en estricto rigor todos somos minorías y la mayoría es un invento artificial para manipular nuestra sociedad (que pasaría si no existieran medios masivos que constantemente nos imponen una realidad idiotizante). Ese poder homogeneizante que ha mantenido dormido el potencial de la sabiduría de las masas.

Como sociedad compartimos elementos comunes como las necesidades fundamentales y es así como existen principios mundialmente aceptados para proyectar nuestra sociedad, pero siempre existe el riesgo de confundirlos con los satisfactores, es ahí cuando nuestro sentido común debe estar atento a cuestionar aquello que atenta contra los principio que se basa nuestra sociedad.

Por ejemplo, hoy en época de elecciones, existe la falsa dicotomía Política de la derecha y de la izquierda, ojalá alguien pudiera explicarme la diferencia entre estas ideología en base a principios fundamentales. Mi sospecha es que ambos proyectos comparten principios, pero son incapaces de explicitarlos, pues es más fácil manipular a las masas desde la ignorancia y el oscurantismo del circo que algunos llaman “campañas políticas”,   por favor que me perdonen los artistas circenses por la burda comparación.

Lo que no comparten los “proyectos políticos” son a las personas que agrupan y la forma en que éstas pretenden gestionar el proyecto proyecto país, es imposible e ingenuo que nosotros los ciudadanos, leamos los planes de proyecto y tengamos la capacidad técnica de evaluar su efectividad con nuestro voto de aceptación y rechazo del paquete de medidas.

Para disfrazar este problema de fondo de la democracia, nada mejor que desviar nuestro criterio de voto, en evaluar la retórica de los candidatos en los debates, ver cual es más simpático o “carismático”, cual tiene la mejor propaganda en las calles o cual se ha aprovechado menos de su posición para obtener beneficios económicos. Tengo ideas de formas complementarias de democracia a través de la participación efectiva ciudadana, ojalá pueda escribir sobre eso más adelante.

The collaboration project

Desde que empecé la búsqueda de un modelo económico más justo basado en la colaboración, como en muchos otros temas expuestos en esta bitácora, escritos por un joven estudiante utópico, después de 3 años he ido curtiendo mi ingenuidad y aprendiendo de la diversidad del ser humano.

Cada día descubro antecedentes y personas, que de alguna forma van validando mi esperanza que converjamos a una solución, en este caso Howard Rheingold escritor del recomendado libro Smart Mobs: The Next Social Revolution, en el vídeo de más abajo, habla de 3 conceptos que encuentro importante asimilar, para entender los problemas que plantea resolver la colaboración: El dilema del prisionero, la tragedia de los comunes y la estrategia “ojo por ojo” o colaborativa. Para explicar estos conceptos en general he citado el artículo Software Libre: una aproximación desde la Teoría de Juegos, pero quizás para otros les resulte más gráfico ver el vídeo, espero que lo disfruten.

Cooperación en la naturaleza

Siguiendo con la tendencia de la última entrada, quiero compartir un par de videos que ejemplifican un poco la diferencia entre las estrategias egoísta y la del “ojo por ojo”, a las que hago referencia en mi propuesta de un modelo de mercado colaborativo.

Por un lado los chimpancés actúan de manera egoísta, defraudando siempre y por lo tanto no pueden compartir la comida del medio:

Por otro lado están los Bononos, que prefieren utilizar la estrategia del “ojo por ojo”, en el primer turno colabora y en los siguientes repite la última jugada del otro:

Lamentablemente no pude encontrar el video de un reportaje de NatGeo que vi la semana pasada donde mostraban en extenso estos experimentos que realiza el Instituto Max Planck, donde también aparece como los niños ya a temprana edad tienen predisposición a colaborar y como quizás ese instinto primitivo fue el que nos llevó a desarrollar el lenguaje y nos hizo diferenciarnos de nuestros ancestros primates.

Agilidad en la naturaleza

Hace algunos meses descubrí el movimiento ágil en Chile y quedé enganchado, el año pasado había leído algo de XP y me pareció interesante, pero difícil de aplicar para tareas distintas a la programación. Después descubrí scrummanager y he ido aprendiendo que los principios de la agilidad se pueden ocupar en muchas otras áreas del conocimiento y mi interés particular es experimentar su uso en la Ingeniería Civil.

Siempre estoy buscando ejemplos en la naturaleza que tengan relación con los temas que planteo en esta bitácora, porque los seres humanos siempre hablaremos con un sesgo de estupidez y faltos de experimentación, pero la sabiduría de la naturaleza es producto de: principios simples, experimentación intensiva y la evolución libre, como diría Torvalds:

Jamás cometas el error de creer que puedes diseñar algo mejor que lo que obtienes de hacer prueba-y-error en paralelo despiadada y masivamente con un ciclo de retroalimentación.
Eso es dar a tu inteligencia demasiado crédito.

Chile un experimento de democracia

Este es un fragmento del documental The War on Democracy del periodista John Pilger.
Donde se plantea una duda razonable de cuanto a evolucionado nuestra democracia, que algunos la reducen a las famosas elecciones y otros como es mi caso, que creemos que es algo más integral y que nos falta mucho trabajo y aprendizaje para lograrla.

¿Matan las escuelas la creatividad?

Espero que disfruten este vídeo y los haga cuestionar muchas otras cosas que damos por dadas, pero que podríamos mejorar mucho más:

Crear GeoTiff de una cuenca con herramientas libres

Howto generate drainage basins from ASTER GDEM Project data.

Existen varias fuentes para obtener DEM de forma gratuita, pero la página de ASTER GDEM es la que me ha dado mejores resultados ya que entrega una precisión de 30 m. para Chile. Existe información adicional que se puede descargar desde WIST, donde podemos usar la misma cuenta creada para ASTER GDEM.

Lamentablemente para crear el shape de la cuenca aún no he podido investigar si se puede hacer con los módulos de Grass, como por ejemplo r.watershed , r.water.outlet , etc. Por lo que tuve que recurrir al software privativo WMS 7.1 , siguiendo el manual que nos pasaron en el curso de Hidrología CI41C. Este software trabaja archivo en formato GridFloat, por lo que aprovechamos bajar los DEM desde la USGS los cuales tienen una precisión de sólo 90 m. Con esto podemos crear 3 shapes: _arc.shp (líneas con los cauces) , _poly.shp (polígono con la divisoria de aguas) y _pt.shp de la cuenca (punto salida de la cuenca).

Con el polígono con la divisoria de aguas es posible “cortar” desde el Geotiff de la zona la información referente sólo a la cuenca. Para cual debemos seguir los siguientes pasos.

• Descargar los geotiff de la zona desde la página de ASTER GDEM , los cuales descargaremos en pedazos de 1 grado x 1 grado, por ejemplo ASTGTM_S29W071_dem.tif contiene la información del cuadrante comprendido entre S29 – S28 , W071 – W072. Junto a los archivos _dem se encuentra un archivo _num que corresponde al error de la medición.
• Ahora nos toca unir todos los pedazos en uno que incluya toda la cuenca. Para eso no ayudaremos con el comando gdal_merge

# Con el siguiente comando unimos los archivos ASTGTM_S29W068_dem.tif , ASTGTM_S30W071_dem.tif y ASTGTM_S32W069_dem.tif , etc. y los guardamos en el archivo elqui-mosaico.tif ,  en este caso los archivos .tif están en el mismo directorio donde estamos trabajando.
$ gdal_merge.py -o elqui-mosaico.tif ASTGTM_S29W068_dem.tif ASTGTM_S30W071_dem.tif ASTGTM_S32W069_dem.tif
# Para ver la información de los archivos .tif , en este caso gdalinfo usamos el archivo que generamos.
$ gdalinfo elqui-mosaico.tif

Driver: GTiff/GeoTIFF
Files: elqui-mosaico.tif
Size is 14401, 14401
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.2572235630016,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (-71.000138888888884,-27.999861111111112)
Pixel Size = (0.000277777777778,-0.000277777777778)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -71.0001389, -27.9998611) ( 71d 0′0.50″W, 27d59′59.50″S)
Lower Left  ( -71.0001389, -32.0001389) ( 71d 0′0.50″W, 32d 0′0.50″S)
Upper Right ( -66.9998611, -27.9998611) ( 66d59′59.50″W, 27d59′59.50″S)
Lower Right ( -66.9998611, -32.0001389) ( 66d59′59.50″W, 32d 0′0.50″S)
Center      ( -69.0000000, -30.0000000) ( 69d 0′0.00″W, 30d 0′0.00″S)
Band 1 Block=14401×1 Type=Int16, ColorInterp=Gray

Donde podemos ver mucha información interesante, como por ejemplo: Formato GTiff/GeoTIFF, Coordenadas geodésicas Datum WGS 84 , el origen, las coordenadas de las esquinas y más abajo las Bandas de información en este caso sólo 1 del tipo Int16, la cual correspondería a las elevaciones.
Podemos abrir nuestro mosaico verlo en Qgis, en propiedades cambiamos el mapa de color a pseudocolor y podremos ver algo como esto:

Imagen GeoTiff del sector

Ya tenemos nuestro archivo mosaico listo para recortar la información de la cuenca, momento …. no es tan fácil, resulta que cuando trabajamos en WMS transformamos nuestro DEM a WGS 84 / UTM zone 19S y los shapes de las cuencas quedaron en esa proyección.

# Para ver la información de los shapes, usamos el comando ogrinfo, en este caso la divisoria de aguas de la cuenca en el archivo estacion01_poly.sh:

$ ogrinfo -al -geom=NO estacion01_poly.shp

INFO: Open of `estacion01_poly.shp’
using driver `ESRI Shapefile’ successful.
Layer name: estacion01_poly
Geometry: Polygon
Feature Count: 4
Extent: (392889.046537, 6679377.052909) – (415780.512166, 6711932.273227)
Layer SRS WKT:
PROJCS["WGS 84 / UTM zone 19S",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-69],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",10000000],
AUTHORITY["EPSG","32719"],
AXIS["Easting",EAST],
AXIS["Northing",NORTH]]
OGRFeature(estacion01_poly):0
OGRFeature(estacion01_poly):1
OGRFeature(estacion01_poly):2
OGRFeature(estacion01_poly):3

• Con esta información de los EPSG ya somos capaces de reproyectar el tif desde “EPSG”,”4326″ a “EPSG”,”32719″ con el comando gdalwarp :


$ gdalwarp -s_srs EPSG:4326 -t_srs EPSG:32719 elqui-mosaico.tif elqui-mosaico_r.tif

• Necesitamos generar el metadato de su Datum “EPSG”,”32719″, para nuestro shape de la divisoria de aguas de la cuenca estacion01_poly.shp con el comando epsg_tr.py :

$ epsg_tr.py -wkt 32719 > estacion01_poly.prj

• Ya estamos listos para emascarar los datos que están fuera del polígono definido por nuestro shape en este caso el de a divisoria de aguas de la cuenca estacion01_poly.shp , con el comando gdalwarp -cutline :

$ gdalwarp -cutline estacion01_poly.shp elqui-mosaico_r.tif elqui-mosaico_re.tif

Con esto queda un archivo tif con las dimensiones del original, pero fuera de este la elevación está en cero.
Para recortar el archivo tif con las dimensiones del shape, podemos utilizar el comando gdalwarp -te si recordamos que las dimensiones del shape estacion01_poly.shp eran Extent: (392889.046537, 6679377.052909) – (415780.512166, 6711932.273227) , ¿No me creen? revisen más arriba lo que les dio ogrinfo:
$ gdalwarp -te 392889.046537 6679377.052909 415780.512166 6711932.273227 elqui-mosaico_re.tif elqui-mosaico_rer.tif

• Para crear un shape llamado contour_250.shp con las curvas de nivel cada 250 mts. ocupamos el comando gdal_contour -a elev :

$ gdal_contour -a elev elqui-mosaico_rer.tif contour_250.shp -i 250.0

Luego visualizamos el resultado en Qgis:

Geotiff de la cuenca con curvas de nivel cada 250 mts.

BONUS: con el comando listgeo que nos entregan información interesante de los archivos Geotiff:
$ listgeo -no_norm ASTGTM_S29W068_dem.tif
$ listgeo -proj4 ASTGTM_S29W068_dem.tif
$ listgeo -t tabledir ASTGTM_S29W068_dem.tif

Referencias:
Manejando información SRTM con GDAL
Como instalar las herramientas acá utilizadas revisar: Software libre para Hidrología

Software libre para Hidrología

Actualmente me encuentro haciendo mi memoria de trabajo de título en “DESARROLLO DE UN MODELO DE PRONÓSTICO DE CAUDALES DE DESHIELO AFLUENTES AL EMBALSE PUCLARO UTILIZANDO HERRAMIENTAS DE SOFTWARE LIBRE”, para lo cual he tenido que instalar un entorno de desarrollo dentro de mi distribución favorita de GNU/Linux llamada Ubuntu.

Actualmente tengo instalada la versión 9.04 Jaunty Jackalope, pero si están comenzando les recomiendo que instalen la última versión desde ya, para comenzar a disfrutar lo más nuevo que ofrece el software libre.

Los paquetes que actualmente tengo instalados para trabajar son los siguientes:

Para cálculo numérico e interfaz gráfica:
- python (El lenguaje de desarrollo ágil y efectivo Python )
- ipython (Consola interactiva iPython)
- idle (Entorno de desarrollo integrado IDLE ), aunque Geany también me ha resultado cómodo de usar.
- python-scipy (Scientific tools for Python)
- python-numpy ( Numerical Python )
- python-rpy (Interfaz para trabajar con R, pero si instalan Ubuntu 9.10 recomiendo usar rpy2)
- python-matplotlib (Librería matplotlib para graficas 2D en python)
- python-tables (En caso que algún día tengamos muchos datos y desde muchas fuentes podremos probar PyTables Hierarchical database for Python based on HDF5)
- ( Tengo muchas ganas de instalar pytseries , pero sólo lo he visto disponible para Ubuntu 9.10 )

Para análisis estadístico:
- rkward (rkward Frontend de R)

Para trabajo con herramientas GIS:
- qgis (Me ha sorprendido la versatilidad de este programa, nada que envidiar a los típicos ArcGis )
- grass ( El clásico GIS opensource grass, lo bueno es activar los complementos de qgis para trabajar con los módulos de grass de una forma intuitiva y amigable)
- marble (bajar imágenes atlas, el complemento ideal para obtener una imagen de la zona y georeferenciar algunos puntos )

Manipular GeoTiff:
-  gdal-bin
-  geotiff-bin
-  python-imaging  (Python Imaging Library PIL)
-  hdf4-tools (HDF command line utilities )
-  python-gdal Python (bindings to the Geospatial Data Abstraction Library)

Dueños de la verdad

La Verdad, la Historia y el Tiempo

Me quedó un último artículo en el tintero antes de partir y es el referente al perfil de persona que yo llamo “dueños de la verdad” primero aclarar la forma en que entiendo algunos conceptos:

La verdad es un proceso iterativo infinito de comprobaciones y refutaciones de conjeturas temporales, que nos permiten desarrollar socialmente el entendimiento de lo que nos rodea.

Yo pienso que nadie puede ser dueño de la verdad, sólo podemos aspirar a vivir el proceso y no caer en la estupidez de aferrarnos a las conjeturas temporales, para estar abiertos a aceptar nuestra cuota intrínseca de ignorancia.

La sabiduría corresponde a las muchas formas que existen para almacenar un conjunto de verdades.

Por ejemplo: los seres vivos almacenan su sabiduría en sus genes, algunas tribus almacenan su sabiduría en sus ritos o cantos,

La evolución es la adaptación de nuestra sabiduría al cambio de lo que nos rodea.

Por ejemplo: en la medida que nuestro entorno cambie más rápido, es un impulso a evolucionar más rápido, yo pienso que el cambio climático nos obligará a evolucionar en muchos aspectos.