Advogato blog for olea

Algunas reflexiones sobre necesidades formativas FLOSS

Fri, 26 Feb 2010 15:08:15 GMT

El pasado 23 de febrero fui invitado a participar en un grupo de discusión de expertos. La acción está enmarcada en el proyecto del Estudio nacional de necesidades formativas y plan de formación en software de fuentes abiertas. A la sazón hilvané algunos pensamientos, observaciones y recomendaciones. Reconozco que tal vez no responden a una generalidad de casos, pero creo que son completamente válidos y útiles. Aprovecho para compartilos a través de este medio.

La autoformación es continua

Se observa la práctica generalizada entre los profesionales o desarrolladores OSS más reconocidos una constante práctica de autoformación y reciclaje permanente. Posiblemente sea otro efecto de la llamada «ética hacker».

Se recomienda promover y apoyar esta práctica de autoformación con los instrumentos y acciones disponibles.

Promoción de la cantera

Partiendo de las siguientes observaciones sobre las comunidades OSS:

libertad de acceso, no hay puertas o límites artificiosos para el acceso, las comunidades de más éxito mantienen altos grados de transparencia
disponibilidad de conocimiento de primera mano: código fuente, documentos relacionados, comunidades, foros, registro de boletines (partes de error, de mejora, etc)
procesos de admisión y madurez en marcha más o menos explícitos
prácticas de reconocimiento entre pares: prestigio
el aprendizaje es práctico: en las trincheras de la actividad de la propia comunidad

deducimos que:

son un excelente caldo de cultivo para el desarrollo técnico personal de nuevos talentos
son ideales para favorecer la motivación, la superación personal y el aprendizaje
a un coste tan bajo como el conectividad y equipamiento informático casero y la imprescindible disponibilidad de tiempo
superan todas las barreras geo-económicas: minimizan la necesidad de proximidad a los grandes centros de conocimiento o económicos

por lo que recomendamos favorecer «la cantera» de nuevos talentos a través de acciones conjuntas/concertadas/compatibles con comunidades OSS populares.

Del modelo clásico de certificación

Desde un punto de vista de comunidades OSS: no nos gustan, en general, los programas de certificación TIC convencionales.

En la práctica, la mayoría de las PyME OSS no contrata personal certificado. En el peor caso certifican a su personal para cumplir o acceder a condiciones de contratación y posibles negocios, pero no porque sea su forma favorita de adquirir nuevos conocimientos.

Autocertificación

Dado que para ciertos actores es imprescindible garantizar alguna clase de referencia se sugiere crear y promover las prácticas de autocertificación. En este caso una gran implementación es la de CAcert: un cuerpo de conocimiento, cuestionarios basados en el mismo, una aplicación web de autoexamen y generación automática de los cuestionarios usando métodos probabilísticos que complican las trampas.

Reconocimiento p2p

Como se ha dicho, el reconocimiento mutuo, entre iguales, es una práctica generalizada de la ética hacker, heredada de la práctica académica. Probablemente la referencia principal a esta práctica sería la implementación de Advogato.org.

Un modelo, reutilizable y no dependiente de una única implementación software, de prácticas de reconocimiento combinado con el anterior sugerido para autocertificación, parece una idea extremadamente sugerente y práctica.

Buenas prácticas OSS

A la hora de realizar cualquier clase de acción relacionada con la formación o la certificación se recomienda encarecidamente una ejemplar «ciudadanía FLOSS». Esto es: deben hacerse prácticas en el marco de las comunidades OSS vinculadas con los objetos de la acción:

participando, compartiendo y asumiendo los acuerdos y consensos dentro de las mismas
practicando los mismos procesos de trabajo
trabajando sobre las mismas infraestructuras de colaboración
desarrollando, mejorando e incrementando sus actuales acervos

A medio plazo es la forma más eficiente y fortalece a ambas partes.

drobo-utils RPM's for Fedora

Sun, 31 Jan 2010 19:11:28 GMT

I've just released the first draft of the drobo-utils for Fedora (12). As usual there'll be available at my repository: drobo-utils.

If I get satisfied with it I could postulate it to Fedora/RPM-Fusion. Feedback would be grateful.

About Drobo

The Drobo is supposed to be the 8th wonder in backup hardware. It does all the data integrity stuff automagically and only asks to be feeded with off the self SATA disks from time to time. Supposely as easy as your mother could manage it.

For your curiosity, my backup system is composed with Drobo and the desktop application back-in-time (which puts rsync under the hood). Time will say if this is as easy and secure as a soho user (that's me) needs.

Mi dictamen sobre el iPad

Fri, 29 Jan 2010 02:07:25 GMT

Oh sí, yo también puedo escribir sobre el iPad. Y para más inri me autocito (y re-cito) de la lista de comunidad de ASOLIF:

De todas maneras, niños míos, la palabra aquí es «dynabook».

Lleva años inventado y sólo Esteban Curreles es quien lo trae al mercado. Para bien y para mal.

Para los applefanboys: http://rinzewind.org/archives/2010/01/27/guia-visual-para-entender-el-dia-de-hoy-por-lo-menos/

Y para los escépticos: http://es.wikisource.org/wiki/La_zorra_y_las_uvas_(Esopo)
Los demás, a estudiar, que merece la pena.

Y me quedo tan ancho.

Un dictamen sobre el proyecto de licencia pública de marca

Thu, 28 Jan 2010 11:20:40 GMT

Un buen amigo me pidió realimentación para el proyecto de licencia pública de marca que promueve el gobierno de Brasil. De ahí que hiciera algunas disquisiciones al respecto y he aquí algunos resultados. Creo que su lectura será sugestiva al menos.

El análisis SOOS

He repasado los contenidos de http://www.softwarepublico.gov.br y he comprendido que la mayoría de mis conclusiones actuales no encajan en el proyecto de la «licencia pública de marca». Mis indagaciones están concebidas para tratar de identificar y resolver «las ineficiencias del software». En ese sentido hemos trabajado mucho en desarrollar un, llamémosle, punto de vista «SOOS». La aplicación de un «análisis SOOS» genera mucha información sobre los problemas del software y apunta a nuevas líneas de trabajo para resolverlos[1] [2] [3].

[1] http://olea.org/conferencias/doc-conf-soos-escritorio/
[2] http://olea.org/conferencias/doc-conf-hiper-innovacion/
[3] http://olea.org/conferencias/doc-conf-towards-floss-smo-ea/

Es muy interesante descubrir muchos puntos de encuentro entre ambas iniciativas, LPM y SOOS. Por activa o por pasiva aparecen nuevos problemas que realmente siempre han estado ahí. Y un caso muy interesante es el problema que generan las marcas al mundo del software en general y al FLOSS en particular. Me ha alegrado mucho saber que en Brasil se ha decidido trabajar en ello.

El principal problema que generan las marcas, desde el punto de vista SOOS, es que son una terrible, y en la práctica infranqueable, barrera contra la convergencia. ¿A qué convergencias me refiero? En realidad todas las posibles, puesto que a más convergencia, más productividad, en el sentido de la ley de metcalfe. Como es sabido, la práctica en el mundo del software —ambos abierto y privativo— es la de la más absoluta divergencia/forking/fragmentación. Me atrevo a decir que en una enorme cantidad de los casos la divergencia se infiere a partir del principio de mercadotecnia de la diferenciación, del que el concepto marca es el epítome.

En este dictamen mi problema es que no veo que el proyecto de «licencia pública de marca» sea capaz de minimizar las divergencias del software. Desde mi punto de vista eso se explica porque hay una relación 1:1 marca:producto.

Al márgen del análisis SOOS

Por otro lado hago el esfuerzo de olvidar todo el análisis SOOS que realmente tanto me apasiona y mi impresión es que realmente la iniciativa LPM puede proponer una solución legal reutilizable para un problema que no es el más llamativo pero sí claramente recurrente. Está al orden del día saber la mayoría de las organizaciones de desarrollo de software abierto importantes han necesitado escribir sus propios reglamentos y licencias para la creación, uso y explotación de sus propias marcas:

En este sentido parece razonable hacer un esfuerzo de formulación y crear un esquema legal claro, manejable y realista que pueda ser reconocido y adoptado por cualquiera de estas organizaciones, incluso sustituyendo sus actuales reglamentos, y sobre todo capaz de ser adoptado por nuevos actores.

Directa o indirectamente es una ventaja clara para reducir los costes de adopción del software. Para mi corazoncito SOOS es una pequeña decepción porque no sirve claramente para maximizar los efectos de red de metcalfe.

Antecedentes: las asociaciones para estándares abiertos

Me permito llamar la atención de que éste problema de marcas no es nuevo o exclusivo del mundo del software abierto. Existe exactamente el mismo en el mundo de los «estándares»[4] y, como decimos en España, para ejemplo un botón: el Objet Management Group.

Probablemente haya mucha más información que pueda estudiarse en Consortium Info y el propio Andy Updegrove pueda ser un gran experto con quien contar.

[4] http://www.open-bar.org/docs/Implementing-Standards-FINAL.pdf

Conclusión SOOS

La iniciativa LPM nos es interesante en tanto que llama la atención del problema real de la ineficiencia del software. Pero a priori no vemos cómo puede servir para la rotunda transformación del sector que tan urgente nos parece.

Conclusión no SOOS

Dado que hasta ahora yo no he tenido ocasión de estudiar este tema no puedo aportar ni validar cuáles deben ser los requisitos que deba cumplir una licencia pública de marca, o una recomendación legal equivalente, pero sí me atrevo a sugerir algunas acciones:

recopilar las soluciones legales creadas hasta ahora por los colectivos más importantes de creación de software abierto y de estándares;
caracterizar las condiciones de licenciamiento, y en ese sentido el trabajo de Ken Kretchmer para identificar las condiciones para ser abierto es extremadamente inspirador;
replicar la práctica de Creative Commons de crear un esquema legal abstracto, que en este caso imagino debe contemplar tanto la licencia en sí como alguna clase de reglamento que la acompañe, capaz de ser traspuesto a los sistemas legales de cada país, a menos que se demuestre la certeza de que hay suficiente compatibilidad legal internacional;
considerar que tal vez sea necesario replicar el sistema CC de varios grados de licenciamiento diferentes para responder a diferentes realidades; en la práctica ocurre exactamente igual con el licenciamiento de software en el sistema combinado GPL/LGPL/BSD;
validar la propuesta a través de socios comprometidos, idealmente aquellos que pertenecen al primer punto de esta lista;
idealmente, mantener un comité de expertos que puedan evaluar la compatibilidad de los esquemas de licenciamiento de terceros con el esquema del punto 2 y la licencia del punto 3.

LinuxTag CfP ends January 29th

Mon, 18 Jan 2010 12:16:25 GMT

Hey: all of you interested on presenting articles at LinuxTag should be in a hurry. The call for papers finishs Jan 29. Go!

Be your own eID provider

Sat, 16 Jan 2010 00:05:29 GMT

One of my particular interests is to explore the requirements of digital personal sovereign and it's implementation with libre software. I've done some thought about this in the past (what I call the «SOOS Desktop») and I'm implementing little by little on my own server. For me, this is an amazing research line deserving a lot of attention both the formal academic and the technical development side. But everything is still to be made.

One of the pieces needed, getting particular importance from some time to now, it's the authentication services. The most trivial protocol to choose today is OpenID.

I've been using phpMyID as my OpenID provider for some time to now, but some consumers complaint about it. I suppose it's because it doesn't implement OpenID v2. After some research I've found the suggestion to use SimpleID. The list of OpenID provider software, I think all the items are OSS, was helpful too. Seems there are very powerful alternatives for «enterprise» servers. In my case I've prefered a low requirement system so I finally chose SimpleID.

When installing software my usual practice is to install it packaged. It's the easiest way to manage what software is installed, where and to have it integrated with the rest of the operating system... hopefully. So I have made a SimpleID RPM package for CentOS 5. The present form doesn't accomplish all the Fedora Packaging Guidelines but I think is fine enough for serious sysadms. I plan to maintain it through Olea.org RPM's repo.

Seting up your OpenID identity

After installing SimpleID you should configure the webserver name at /var/www/simpleid/www/config.inc and restart Apache.

For each identity you should fill a username.identity file at /var/www/simpleid/identities/. Take care username here should be the user name you want to log against SimpleID and have nothing to do with your identity details. For creating your password hash you can use md5sum:

echo -n "mypassword" | md5sum

An interesting feature is you can create your own Extensible Resource Identifiers (XRI) and add them to your user identity file. I hope to play a bit with this soon.

When ready, log into SimpleID, the default URI I set in my package is http://localhost/simpleid. Now go to the «My Profile» tab, where you can gather all the HTML links tags you should add to the webpage you want to be your OpenID URI. In my case it is in http://ismael.olea.org, which seems to me a meaningful URI. You only need the copy generated code to the HEAD section of the chosen HTML document. It's a flexible way to really decide how your OpenID URI should look like.

When ready you'll can login using your brand new OpenID URI. Enjoy.

Another SimpleID nice feature is the «My Site» tab. When login into your account you'll can track the OpenID consumers you are logged and remove them if needed.

I'm waiting for new SimpleID releases!

Mi blog, mis reglas

Mon, 11 Jan 2010 00:06:29 GMT

Aprovecho para plagiar las reglas de comportamiento del blog de Miguel y esbozar las mías sobre cómo espero que los lectores participen con sus comentarios... si es que hay alguno:

la regla de oro: si deseas escribir algo en mi blog esperaré la misma cortesía que si estuvieras invitado a charlar en mi casa;
admito y aún solicito crítica constructiva, aunque escueza, sólo ruego mantener las formas;
no admitiré insultos ni sandeces, eso lo haces en tu casa, acá los borraré;
si vienes a trolear me reservaré el derecho a eliminar tus comentarios.

La aplicación de estas reglas está condicionada a mi criterio subjetivo. Qué le vamos a hacer si no soy Mr. Spock. Es lo que hay.

Gracias a dios no faltan sitios en Internet donde abusar del derecho a la libertad de expresión.

Cambios en mi blog

Mon, 11 Jan 2010 00:06:29 GMT

Tenía pendientes realizar varios cambios técnicos en mi blog que a partir de hoy, espero, quedan resueltos. En resumen:

actualización a la última versión de LameBlog, con la importante novedad de adoptar Disqus como sistema de comentarios externo, que es más bonito que Haloscan y que además no desaparece como éste; lo ideal hubiera sido poder instalar mi propio servicio de comentarios instalable de forma completamente independiente y autenticando usuarios con OpenID, pero no encontré nada disponible;
migración de los comentarios archivados desde Haloscan a Disqus: el primero permite exportarlos y el segundo ofrece una posibilidad de importarlos, pero diría que es una función experimental porque todavía no he recibido aviso del cambio;
eliminación de referencias a artefactos o servicios que están muertos o lo parecen: coComment o zoomcloud; corolario: no puedes fiarte de una startup;
repaso general a código y estilos, aunque estoy bastante seguro de no ser capaz de generar código XHTML válido, que ya me gustaría;
cambio de la licencia con la que publico en el blog de by-nc-nd a by-nd; he atendido a la sugerencia, fíjate tú, de la FSF a la hora de licenciar la publicación trabajos de opinión; la verdad es que debería añadirla a mis transpas;
y finalmente repaso en busca de enlaces perdidos, pero como gURLchecker no ha acabado de trabajar no sé cómo va quedando la cosal.

En general éste sistema sigue sin satisfacerme. Los que mejor me conocen saben que soy bastante extremista en mis juicios sobre el estado del arte en la publicación electrónica. Al menos soy capaz de controlar todo el entorno de trabajo y no levanto código dinámico susceptible de vulnerabilidades, que son factores para los que nos gustan los «sistemas de publicación desacoplada» (creo que así es como los llama mi amigo Juanpri).

A medio plazo deseo probar algunos artefactos relacionados con Atom stores y con lo que llaman «lifestream».

A partir de ahora espero ser capaz de darle más trajín a los contenidos. A ver cómo se nos da el año.

Sonar Power Manager available for Fedora

Sun, 18 Oct 2009 13:17:13 GMT

The past days the news about the release of the SonarPM had got a lot of attention from the crowd. It's really appealing how a creative idea can got profit from existing infrastructure for creating a new unexpected feature.

So, I've dedicated some minutes and packaged SonarPM for Fedora. As usual it's available through my repository service. I've tested the multiplatform building and seems to be successful. Enjoy!

04 oct 2009

Sun, 4 Oct 2009 02:06:09 GMT

Call for help: Review Request for kompozer

I'm looking for a reviewer for Kompozer, the best OSS HTML editor available. A nice fact is the Kompozer development is very active this days and the 0.8.* series are pretty stable. I think this is a good tool for Fedora .

You'll find the official request at #519521.