Ogu es un lenguaje con declaración de tipos estáticos, aunque implementa inferencia de tipos. Veamos algunos ejemplos:

i : Int = 0

j := i // j es de tipo Int

s : String = “un string”

t := s

 

Ogu tiene “sacarina sintáctica” para soportar tuplas

naipe : (Int,String) = (10, “espadas”)  // naipe es una tupla

as := (1,”espadas”)

Naipe = (Int,String) // Introduce el tipo Naipe como alias de la tupla (Int,String)

Tambien hay sacarina para listas y hashes:

vocales : [String] = [“a”, “e”, “i”, “o”, “u”]

ListaDeStrings = [String]

mapa : [String : Int] = [“Chile”:56, “Usa”:1]

Las clases pueden ser genéricas:

Stack{T}  : () = {

var _data : [T] = []

push : (x:T) = _data = x :: _data

pop : ()->(r:T) = {

r = head _data
_data = tail _data
}

}

Las tuplas, listas y mapas se implementan en basa tipos genéricos. En realidad al declarar una variable de tipo [T] es lo mismo que declararla como Sequence{T}, y al declararla como [K:V] es lo mismo que Map{K,V}.  Tanto Sequence y Map son clases definidas en el runtime básico de Ogu.

Para crear un stack de enteros hacemos lo siguiente

stackOfInt := Stack{Int}()

// otra manera

StackOfInt = Stack{Int} // type alias

stackOfInt := StackOfInt()

Ogu soporta herencia de clases

// un troglodita es un cavernicola que vive en una cueva

Troglodita : (nombre,grito,cueva : String) > Cavernicola(nombre,grito)  = {
_cueva := cueva

}

 

Interfaces

Consideremos un paquete que trabaja con figuras geométricas

Circulo : (radio:Int) = {

area : ()->Int  = pi * radio ^ 2

perimetro: ()->Int = 2 * pi * radio

}

Cuadrado : (lado:Int) = {

area : () –> Int = lado * lado

}

 

Supongamos que queremos crear una funcion que imprima el area de una figura geometrica:

imprimeArea : (c:Cuadrado) = println(“el area es “+c.area())

imprimeArea : (c:Circulo) = println(“el area es “+c.area())

el problema es que Ogu no nos permite sobrecargar funciones . Hay tres maneras de solucionar esto, la primera es usando selectores de tipo:

imprimeArea : (c:Cuadrado|Circulo) = println(“el area es “+c.area())

lo que hemos hecho es que el tipo de la función imprimeArea puede ser un Cuadrado o un Circulo (Cuadrado | Circulo ).

Ahora si definimos esta función:

imprimePerimetro : (c : Cuadrado|Circulo) =
println(“el perimetro es “+c.perimetro())

tendremos un error de compilación,  Cuadrado no define la función perímetro.

La otra forma de solucionar este problema es declarando una interfaz:

Figura := {

area : ()->Int

perimetro : () –> Int

}

Una interfaz es como una clase, pero no tiene constructor y el cuerpo de las funciones es opcional.

De este modo puedo redefinir las clases Circulo y Cuadrado de esta manera:

Circulo : (radio:Int) ~ Figura = {

area = pi * radio ^ 2

perimetro = 2 * pi * radio

}

Cuadrado : (lado:Int) ~ Figura ={

area = lado*lado

perimetro = lado*4

}

e implementar nuestras funciones así

imprimeArea : (f:Figura) = println(“el area es “+f.area())

imprimePerimetro : (f:Figura) = println(“el perimetro es”+f.perimetro())

La tercera forma de implementar polimorfismo es mediante herencia y esa queda propuesta al lector.

Consideremos la interfaz Dibujo

Dibujo :=  {

dibujar : () = println (“dibuja un ”+nombre)

nombre : String

}

Podemos ahora extender Circulo y Cuadrado para que sean también dibujos:

Circulo : (radio:Int) ~ Figura & Dibujo = {

area = pi * radio ^ 2

perimetro = 2 * pi * radio

nombre = “circulo”

}

Cuadrado : (lado:Int) ~ Figura & Dibujo ={

area = lado*lado

perimetro = lado*4

nombre = “circulo”

}

Este artículo es solo una introducción, y es un complemento a la primera parte de la presentación de Ogu. Espero sus comentarios.

Artículos relacionados

• Simplejizando…
• Compiladores
• Java debe morir

Ignoro por que la Universidad de Chile decidió hacer este ramo optativo, ignoro también cuanta gente toma esta materia cada semestre,también he escuchado que la matrícula en computación ha bajado, espero que algún académico me confirme esa información.

Como sea, creo que la la no obligatoriedad del curso de compiladores es un error, porque es uno de los ramos que mejor sintetiza todo lo aprendido en la carrera.

Cuando haces un compilador aplicas:

• Estructuras de Datos (AST, Grafos de Colores)
• Algoritmos, Teorías de Autómatas, Teorías de Lenguajes Formales
• Fundamentos de Lenguajes de Programación (en el diseño del lenguaje)
• Optimización
• Programación en código de máquina (real o virtual)
• Modularidad, Integración, bajo acoplamiento (la estructura del analizador léxico, sintáctico, semántico y generación de código ayuda a entender y aplicar por primera vez los conceptos de arquitectura del software
• Ingeniería de software, diseño, análisis

Construir un compilador es el desafío que te forma como verdadero desarrollador de software, todo aquel que se quiera desempeñar como ingeniero de software debería intentar hacer un compilador alguna vez en su vida.

En mi vida profesional he construido 2 compiladores y diseñado 3 lenguajes (uno de los lenguajes usaba el pre procesador de C, así que era en realidad un conjunto de macros).

Estos lenguajes son lo que hoy llamamos DSL, lenguajes de dominio específico, diseñados para resolver un problema específico. El primero fue desarrollado en conjunto con Marco Zúñiga. Tenía un compilador, una máquina virtual propia, y hacíamos capacitaciones y lo licenciábamos, ganamos algunos buenos dólares con SanScript, como lo llamamos. Un DSL para automatizar tareas de comunicación de datos.

El segundo compilador era en realidad un traductor, que traducía de una suerte de markup tipo Haml y generaba páginas JSP. Lo divertido era que además eran resueltas con un filtro implementado con un servlet, que interpretaba los archivos con extensión .edc (mis iniciales) y generaba  las páginas jsp en un caché. Las contrapartes técnicas con que interactué en ese tiempo siempre me preguntaba que eran estas páginas con extensión ‘.edc’

Pero nunca he hecho un compilador de un lenguaje de propósito general, a pesar de que tengo la idea de hacerlo desde hace muchos años. Ahora que todo el mundo tiene ganas de matar Java, se me ocurrió que es momento de mostrar mi propuesta, de modo de que la primera versión de mi lenguaje corra sobra la Java Virtual Machine.

Ogu

El lenguaje se llama Ogu, su nombre es un homenaje al personaje creado por el caricaturista chileno Themo Lobos, es un cavernícola muy simpático amigo de aventuras de Mampato[2].

Este es un sencillo programa en Ogu:

println “Akarrú!!!”

Ninguna novedad dirán ustedes, hasta python hace eso, aunque traten de escribir este programa en Java

En este artículo voy a hacer una breve introducción, espero escribir más en los próximos días, donde iré describiendo las características de este nuevo lenguaje. Estoy aún en proceso de diseño, aunque hay ideas que tengo de hace años. Por cierto hay  influencias de otros lenguajes, como irán notando. Lo importante es que consideren de que es muy probable que las cosas cambien.

Lo primero que hay que notar es que es un lenguaje con tipos estáticos, como Java, como Scala o como Haskell, es decir, toda variable debe tener un tipo, así que toda declaración de un símbolo en Ogu debe tener su tipo.

Acá hay un ejemplo de declaraciones en Ogu:

blog : String

ogú : Cavernícola

x, y : Int

Los dos puntos ‘:’ separan a la variable de su tipo.

La asignación en Ogu es con el signo ‘=’, y sirve para inicializar una variable que ha sido declarada previamente, por ejemplo:

blog = “La naturaleza del software”

ogú = Cavernícola(nombre:”Ogú”, grito: “akarrú!!!)

x = 1

y = 2

Por supuesto las variables pueden tener un valor inicial al declararse:

blog : String = “La naturaleza del software”

ogú : Cavernícola = Cavernícola(nombre : “ogú” )

x, y : Int = 1, 2

Pero Ogu tiene cierta flexibilidad, que permite tranquilizar a los amantes de los lenguajes dinámicas, al inferir tipos:

blog := “La naturaleza del software” // blog es de tipo String

ogú := Cavernícola(nombre: “ogú”) // ogú es de tipo Cavernícola

x, y := 1, 2 // x e y son de tipo Int

Habrán notado que el nombre de las variables lleva acentos, esto porque Ogu acepta(rá) código escrito en Unicode.

Otra cosa importante, en Ogu si algo empieza con mayúsculas es la declaración de una clase, si empieza con minúsculas es una variable.

Pero todas las variables son inmutables, es decir, no puedes cambiarles el valor una vez asignada:

x := 1

x = 2 // error!!!

Si necesitas que las variables sean mutables debes declararlas anteponiendo la palabra reservada ‘var’:

var x := 1

x = 2 // ok, porque x es mutable

Esto es importante porque Ogu privilegia la programación funcional, como veremos más adelante.

Ogu es como el lenguaje Scala, soporta 2 paradigmas de programación: funcional y orientado al objeto. En Ogu la diferencia entre funciones y clases es algo difusa (el uso de mayúsculas para clases ayuda a desambiguarla).

Funciones:

Veamos como declarar una función:

factorial : Int –> Int

factorial 0 = 1

factorial n = n * factorial (n-1)

Este ejemplo muestra que Ogu privilegia el paradigma funcional, y sigue una sintáxis muy parecida a la de Haskell.

El valor de una función está determinado por la expresión a la izquierda del signo ‘=’.

Lo que tenemos son patrones, o casos, que definen a la función. Podemos escribir factorial de esta forma abreviada:

factorial : (n:Int)–> Int  =  (n == 0) 1 else  n * factorial(n-1)

Si hay más de una expresión en una función estas deben ir rodeadas de llaves {}.

En la forma abreviada deben ir los argumentos nombrados entre paréntesis, y es opcional nombrar el resultado.

El valor de la función será el valor de la última expresión, a menos que el resultado haya sido nombrado:

suma : (a,b : Int) –> Int = {
a+b // el valor es a+b
}

suma2 : (a, b : Int) –> (resultado: Int) =  {
resultado = a+b
println “el resultado es “ + resultado // el valor de suma2 es resultado
}

Si la función no recibe argumentos se debe usar la expresión () –> Tipo, esto con el fin de resolver ambiguedades:

uno : () –> Int = 1 // siempre retorna 1, pero es una función

uno := 1 //  es la variable uno

Si la función no retorna valores se debe usar –> Void, o solo colocar los parentesis:

saludar : () –> Void = println(“hola” )

saludar : () = println(“hola” )

Veamos como declarar una clase

Persona : (nombre: String, edadInicial: Int) ={

var _edad = edadInicial

saludar : () = println “hola “ + nombre

celebrarCumpleaños : () = {
_edad = _edad + 1
println “¡¡ feliz cumpleaños “ + nombre + “!!”
}
}

Como verán Ogu es un lenguaje que privilegia la economía sintáctica. Los argumentos nombre y edadInicial son atributos de la clase, y no es necesario declararlos en el cuerpo, _edad también es un atributo, pero privado. Los identificadores que empiezan con _ son privados, como en Python.

Los nombres que empiezan con mayúsculas son tipos o clases, y los nombres que  empiezan con minúsculas son nombres de funciones o variables. Si un nombre empieza con _ y luego viene mayúscula es un tipo privado.

Noten que junto con declarar la clase Persona, hemos definido el constructor de la clase.

Ahora podemos presentar la declaración de Cavernícola:

Cavernícola : (nombre, grito : String)

Cavernícola  : (nombre : String)  = Cavernícola(nombre, “akarrú!!”)

Cavernícola = {

pelear : () = {
println “yiko pelea!”
println grito
}
}

 

Fíjense como hemos declarado Cavernícola con dos constructores.

Hay más cosas que contar, pero esto es un anticipo de Ogu, que espero les guste. El proyecto será opensource y se publicará en github. Por ahora sólo existe un parser, el que aún tiene algunos problemas con ciertas ambigüedades. Espero tener pronto una primera versión para que empiecen a probarlo.

Este es el primer artículo sobre Ogu, en la medida que vaya resolviendo problemas de diseño iré publicando más.Espero sus opiniones, preguntas y sugerencias.

Notas

[1] Malla de Ingeniería Civil en Computación impartido por el DCC (para los que ingresaron antes de 2007, y los que ingresaron después de 2007).

[2] En realidad el personaje se llama Ogú (con acento en la u), y su grito de guerra es Akarrú, sí, Akarrú.

Artículos relacionados

• Simplejizando…
• El sistema de tipos de Ogu (1)
• Java debe morir

Actualización

• Red Hat lanza su PaaS, Plataforma como Servicio, justo hoy, se llama OpenShift

Artículos relacionados

• ¿Qué es Cloud Computing? (La presentación)
• Software Everywhere: La Internet de las Cosas en el Chile Post-Bicentenario
• Qué es Cloud Computing

Linus Torvalds y la FSF

Artículos relacionados

• Cuidate del estilista
• Sintel
• Reflexiones

Les quiero hablar de 2 proyectos que deben su existencia a esta idea poderosa del software libre, y quiero, a través de estos ejemplos, descifrar cuál es el secreto del éxito de un proyecto de software libre, o basado en software libre. Mi intención es encontrar los fundamentos que hacen que estos proyectos funcionen. Soy un convencido de que mucha gente que habla del software libre no tiene idea de que habla, y por lo tanto se crean expectativas e ideas incorrectas, las que mal aplicadas pueden ser desastrosas.

En este primer post nos vamos a enfocar en un proyecto que usa software libre, donde el foco no es desarrollar código (aunque sí fue necesario hacerlo), acá el foco es usar el software libre disponible para construir una pieza de arte y compartirla, y por supuesto armar una industria sustentable que permita ganar dinero con el proyecto.

Hablamos del cortometraje Sintel, de cuya existencia me entero gracias a este post en la excelente Bitácora Virtual de Andrés Moya.

Sintel es una OpenMovie, lo que quiere decir que todo el material de producción está disponible mediante una licencia Creative Commons, por lo tanto se pueden crear obras derivadas de esta película.

En las propias palabras del equipo:

“Sintel” es un cortometraje producido en forma independiente, iniciado por la Blender Foundation como un medio para mejorar y validar la suite de creación 3D free/open source 3D Blender. Con fondos iniciales provistor por miles de donaciones vía la comunidad de internet, ha probado nuevavemente ser un modelo de desarrollo viable para la tecnología 3D y para la animación de películas independientes.”

Blender es un software de modelamiento 3D, creado por Ton Roosendaal, un programador y empredor holandés. En 1998 Roosendaal había creado una empresa llamada NaN para vender y distribuir el software. Hacia el 2002 NaN se encontraba en bancarrota.

A pesar de la quiebra Roosendal quería seguir el desarrollo del software, la solución fue pagarle a sus acreedores 100.000 euros por el código fuente de Blender. Para lograr este objetivo crea la Blender Foundation, cuya primera meta fue conseguir el dinero para liberar el código, acá estamos literalmente de liberar el código fuente .

La fundación se mantiene mediante donaciones, cuyo principal fin es emplear a Roosendal como desarrollador lider a tiempo completo. La meta principal de la fundación es “darle a la comunidad de internet mundial acceso a la tecnología 3D en general, con Blender como núcleo”.

La Fundación Blender ha producido varios proyectoso independientes antes, que incluyen cortos y juegos. Blender mismo ha sido usado en películas comerciales, como Spiderman 2, y el reciente film argentino Plumíferos.

Acá les dejo el film Sintel, espero que lo disfuten:

Artículos relacionados

• Reflexiones
• Lecciones de RataTouille
• Hazlo

[...]Por otra parte, el tratar de medir o extrapolar el “estado del software libre en chile”, tiene el mismo valor metodológico que tratar de establecer el “estado de la pintura chilena” contando los cuadros en un museo.[...]

Tiene razón, pero creo que malinterpretó mi intención, o yo escogí mal el título.

De todas maneras, la metáfora de los museos es buena (me recuerda la frase de Indiana Jones: “That´s belongs in a museum“), porque los Forge, efectivamente, terminan siendo sólo museos, lo que se necesita son comunidades vivas y colaborativas. Por eso creo que  la idea de GobForge es una pérdida de tiempo, cuando hemos evolucionado a modelos de redes sociales de desarrolladores, como Git Hub, BitBucket, e includo CodePlex, esto será el tema de futuros posts, así que no se apuren.

El tema de este post era agregar una colita a mi análisis anterior, con una visita al museo del software del gobierno de Chile, o del ministerio de Economía, para ser más precisos (ya verán por que).

Breve análisis de GobForge

GobForge es parte de la nueva iniciativa software público impulsada por la Secretaría de Desarrollo Digital.

El sitio parece haber sido creado en el año 2008.

Usuarios Registrados: 141

Total de Proyectos Registrados: 16

Total de Proyectos Catalogados: 11 (2 en estado Beta, 9 en Producción/Estables)

Actividad

La página inicial contiene varias noticias que dan cuenta de la disponibilización de diversos documentos, o archivos. Sólo hay 6 noticias.

Aparte de las noticias, la única interacción de la comunidad son estos mensajes:

No encuentro Archivos de instalacion [ responder ] 2009-10-20 12:13

Hola descargue el unico paquete publicado pero me encontré con que solo hay imagenes? Donde puedo descargar el paquete de instalacion. Gracias

implementacion del sistema control de nº IP [ responder ] 2009-06-16 13:06 alguien me puede orientar en su puesta en marcha

RE: rrrhh sistema [ responder ] 2010-03-29 15:27

parece que esta comunidad se acabo….. lamentable

rrrhh sistema [ responder ] 2010-03-29 15:24

como descargo la aplicacion

El éxito de los proyectos opensource depende de la actividad de su comunidad, este no sólo es un museo, sino que es un museo que no tienen ni siquiera un guía al cual acudir.

Madurez de los proyectos

Hay 11 proyectos catalogados:

• 2 en estado beta, que no han liberado ningún archivo
• 9 en estado producción.
• 8 de los proyectos en estado producción/estable han liberado archivos
• 8 de los proyectos en estado producción/estable usan Subversion (SVN) para gestionar código.
• Todos los proyectos fueron creados por el usuario administrador Admin. Los 8 repositorios SVN fueron inicializados por el mismo usuario (jhp).
• Casi todos los proyectos sólo tienen 1 miembro (Admin)
• Todos los proyectos catalogados fueron desarrollados en el Ministerio de Economía.

Otras observaciones

GobForge da la impresión de ser un sitio creado rápidamente, como si hubieran dado una orden perentoria. 8 de los proyectos en producción fueron creados el 4 de abril de 2009 durante la mañana. Todos los repositorios fueron creados por el mismo usuario, y no han tenido actividad desde entonces.

Comentario

No basta con pedirle a un asesor de que arme un sitio tipo source forge, que pueble los repositorios SVN para decir que estamos haciendo una buena gestión, y estamos promoviendo el software libre en el estado. Todos los que estamos en este mercado podemos deducir muy fácilmente quien fue ese asesor que se esmero por levantar este sitio (alguien a quien estimo). ¡Que bueno que hizo  bien su trabajo!, porque sino no el gobierno no tendría nada que mostrar, pero los que recibieron este trabajo, ¿qué hicieron después?,  ¿ las autoridades y los responsables que están detrás, qué han hecho para que esta comunidad crezca, y apoye a sus usuarios?  Es linda la iniciativa, pero sólo parece un corte de cinta virtual, de un museo mal atendido.

Artículos relacionados

• El estado del open source en Chile, la comunidad ChileForge
• Convocatoria
• Reflexión sobre MPPC

“Talk is cheap, show me the code” (hablar es barato, muéstrame el código) dice Linus Torvalds.

Recientemente Marco Zúñiga ha levantado un desafío, un test de blancura para la comunidad open source chilena, la idea es poner a prueba lo que dice Linus Torvalds, si en realidad estas comunidades pasan del discurso a la acción.

Resulta que hace unas semanas atrás decidí investigar los repositorios open source que tenemos en el país, principalmente motivado por un curioso incidente ocurrido con el sitio ChileForge (más antecedentes acá). Así que decidí revisar que es lo que había pasado con esta comunidad, y emprendí un  análisis del repositorio ChileForge, A continuación comparto con ustedes el resultado. Creo que es un buen antecedente para aportar al debate sobre la viabilidad del open source en Chile, o al menos para los que están interesados en cobrarle la cena a Marco, ya sabrán donde no buscar

Descripción del Sitio, tomada desde su home page:

“ChileForge es un proyecto impulsado por el Departamento de Ciencia de la Computación de la Pontificia Universidad Católica de Chile, que busca aportar a la difusión y desarrollo de software en Chile, bajo el modelo Open Source.”

Fecha Cierre de este análisis: 16 de septiembre de 2010

Resumen: el 52% de los proyectos ha liberado algún producto, lo que no garantiza que sea algo usable. El promedio de desarrolladores por proyectos es de 2.2. Desde hace 6 meses que no hay actividad en el sitio. Sólo 1 proyecto muestra actividad en el último año, sólo 2 proyectos muestran actividad en los últimos dos años.

Antecedentes:

Usuarios Registrados: 1.096

Proyectos Registrados: 193

Proyectos Catalogados: 106

El análisis se continuó sobre la base de los 106 proyectos catalogados.

Desarrolladores: la idea es ver la participación por proyecto, para determinar que tan comunitarios son los proyectos.

• Total de Desarrolladores: 235
• Tamaño promedio del equipo: 2.22 [desarrolladores / proyecto]
• El 58% de los proyectos tienen sólo 1 miembro
• El 22% de los proyectos tienes sólo 2 miembros
• La distrubución de desarrolladores por proyecto es la siguiente:

Este gráfico muestra la distribución:

El eje vertical es la cantidad de proyectos, el horizontal es la cantidad de desarrolladores (miembros) inscritos en cada proyecto.

Los dos proyectos con más usuarios son:

• Sistema Centro Médico 2005 (http://chileforge.cl/projects/tec) con 16 miembros, creado el 7 de abril de 2005, y cuyo único archivo liberado corresponde a una clase en PHP para enviar mensajes usando SMTP (importada de una versión anterior del proyecto PHPMailer en sourceforge).
• Rizoma (http://chileforge.cl/projects/rizoma/), tiene 15 miembros registros, pero es un proyecto que decidió migrar a Savannah, al parecer por problemas de soporte con ChileForge. Este proyecto al parecer sigue vivo (tienen un blog donde informan que la versión 1.0 fue liberada para la FLISoL Santiago 2009).

Madurez de los Proyectos

El sitio permite catalogar los proyectos según el grado de madurez del proyecto, los estados posibles son: Planning (etapa de planificación), pre alfa (supongo que en este estado habrá algún prototipo), alfa (una primera versión sin mucha depuración), beta (con algunos errores, los usuarios ya empiezan a usarlo), production/stable (el proyecto ya está en producción), y mature (maduro, es decir, ya el producto se sostiene sólo y se aplican mantenciones, o se planifica nuevas versiones). La distribución se resume en el siguiente gráfico:

La clasificación es dudosa, por ejemplo, hay proyectos que han liberado código, que se ve bastante usable, pero aparecen como en etapa planning. En un caso (xanubis), el proyecto aparece catalogado como Production/Stable, sin embargo no ha liberado ningún archivo, y sólo tiene un mensaje que dice “Ya casi comenzamos el Proyecto Xanubis”.

Lo interesante es ver cuantos proyectos han liberado algún producto (archivos descargables). Para esto contamos aquellos proyectos que tenían disponible algún archivo para descargar. Sólo el 52% ha liberado algún producto. Pero, insisto que la calidad de estos entregables es dudosa, habría que descargar los archivos y analizarlos para dar un diagnóstico más preciso de la madurez de los proyectos, de lo poco que revise, puedo decir que casi siempre eran archivos que estaban en su primera versión, o simplemente algunos archivos anexos (como el caso mencionado arriba).

Control de versiones: 7  proyectos (7%) no tienen control de versiones de ningún tipo, 86 proyectos (81%) tienen configurado CVS, pero los repositorios juntan telarañas, pues nunca se han usado. De los que quedan (13), el uso es mínimo, con no más de 2 o 3 commits por proyecto. En este punto donde más se nota la inmadurez técnica de la comunidad ChileForge.

Actividad

El 41% (43) de los proyectos se crearon el año 2004, el 28% en 2005. La siguiente es la distribución:

Para medir el tiempo de vida del proyecto medimos la cantidad de días desde que fue creado el proyecto, hasta que fue liberado la versión más reciente de cualquier entregable del proyecto. Por ejemplo, el proyecto de mayor tiempo de vida (reqadmin), fue inscrito el 30 de mayo de 2005, ha liberado 6 archivos, el último corresponde a la versión 0.4 beta con fecha 8 de junio de 2008, entre la fecha de inscripción y el último beta han pasado 1.105 días (37 meses).

Usando este criterio, el tiempo de vida promedio es de 7,6 meses, la mediana es de 4.5 meses. La distribución del tiempo de vida de los proyectos se muestra en este gráfico (expresada en meses):

La altura de las barras representa la cantidad de proyectos que caen en el rango. Los rangos son de 5 meses. Por ejemplo, la primera barra indica que 55 proyectos tienen una vida de entre 0 a 5 meses.

El otro parámetro es ver cuanta actividad ha tenido el proyecto en los últimos meses, en este caso lo que medimos es la fecha del último producto liberado (el mismo parámetro usado para medir la “vida” del proyecto). En este punto los datos son desalentadores:

• Actividad en los últimos 6 meses:  ningún proyecto presenta actividad.
• Actividad en el último año: 1 proyecto
• Actividad en los últimos 2 años: 2 proyectos

Si medimos las noticias publicadas en portada tenemos que:

• Hay 1 noticia de 2010, informando que se ha recuperado el dominio Chileforge.cl
• Una noticia en 2009
• 28 mensajes en 2008

Conclusiones

ChileForge es  una comunidad con muy poca actividad en los últimos años, si bien en sus inicios (2004) mostró un gran impulso, con el tiempo fue decayendo su uso, al grado que este año estuvo varios meses inactivo.

Para ser una comunidad de 6 años, el grado de inactividad es un mal indicador. Consideren que las comunidades open source tienen un alto grado de participación y actividad (Sourceforge, GitHub, incluso CodePlex, el repositorio open source de Microsoft).

¿Qué es lo que pasa con ChileForge? ¿Será que los usuarios prefieren hostear sus proyectos en los repositorios internacionales? ¿Falta de difusión? ¿O serán otras causas más profundas las que explican esta falta de actividad? Los invito a debatir este caso.

De todas maneras, les prometo que el próximo año voy a repetir este ejercicio, y vamos a revisar nuevamente el estado de esta comunidad.

Artículos relacionados

• Apéndice, el análisis de GobForge-CL
• Convocatoria
• Reflexión sobre MPPC

¿Cómo es posible que exista ese engendro, y que además funcione tan bien? Muy simple, porque  hay gente que es pragmática, que no se enfrasca en discusiones cansinas sobre  si es mejor el software libre, o el opensource, o los sistemas operativos “privativos” (con todas las connotaciones incorrectas, y mal intencionadas de esa palabra).

El software es como la música, sólo hay de dos clases, buena y  mala. No me gusta el regguetón, pero hay reguetón bueno, así como hay rock clásico muy malo. Lo mismo con el software. Hay software opensource (o libre) muy malo, y software propietario (¡ya ok!), digo privativo, ¡muy bueno!

En software lo que importa es que, primero  funcione, que sea robusto, y que de pocos dolores de cabeza. La licencia? la licencia es para tener tranquilo a los dementores auditores. Mucho gerente TI viejo te dirá que lo que importa es que haya alguien que responda, si es una compañía opensource, o más tradicional, no es relevante, lo que importa son las garantías que tienes cuando las cosas fallan. Tener un contrato de soporte, que asegura que una empresa seria te va a responder cuando las cosas se pongan feas, hace que los gerentes TI puedan dormir tranquilos. Antes se decía que a nadie despedían por contratar a IBM, u Oracle. Ahora hay más alternativas en el mundo opensource, a nadie despiden por contratar soporte con RedHat.

Después de todo, sin los miles de millones de dolares que se invierte en opensource,  y sin el sueldo de 6 dígitos que cobra Linus Torvalds, no tendríamos los excelentes productos opensource  como los que que hay ahora.

Las empresas requieren un seguro, el core de los departamentos TI, no es participar en comunidades de desarrollo de productos open source, esos desarrolladores están para dar soluciones, y mantener operando los servicios de sus empresas. Muy pocas corporaciones, pueden darse el  lujo de que alguno de sus desarrolladores dedique horas a participar de un proyecto  opensource, aunque  tengan las capacidades. Simplemente no hay  tiempo. Es más eficiente levantar el teléfono de soporte, o abrir un ticket, para que un ingeniero en alguna parte del mundo resuelva el problema.

¿Y el acceso al código fuente?

La verdad, ¿de qué sirve el código si probablemente no tienes las capacidades para corregir el bug?, o si las tienes, probablemente no cuentes con el tiempo para hacerlo, sobretodo con productos de plataforma, como los sistemas operativos, o los motores de base de datos, que son monstruos de millones de lineas de código, que requieren capacidades de programación superiores. Además, ¿para qué? ¡si estás contratado para otra cosa!

El código fuente es un seguro, nada más, también puedes contratar una póliza en la compañía que más te de confianza.

Lo importante es la gobernabilidad del software, eso es lo valioso.

Artículos relacionados

• Cuidate del estilista
• Apéndice, el análisis de GobForge-CL
• El estado del open source en Chile, la comunidad ChileForge

[...] la imitación se transforma en un instrumento clave de navegación social, imitar al otro implica necesariamente, primero, un reconocimiento de sus señales diferenciadoras y luego una identificación con ellas, constituyéndose en el primer paso en la generación de comunidad la cual termina de constituirse cuando unos y otros hacen suyas y consolidan esas señales como un código compartido o las rechazan estableciendo la diferencia. Es la imitación la que nos otorga esa seguridad de que no estamos equivocados, de que no nos hemos salido erróneamente de los márgenes delimitados por el grupo al cual pertenecemos, o bien no nos alejamos aun más de ese grupo de personas al cual queremos que nos relacionen. Es por tanto la imitación la manera más segura de sentirse parte de algo, y por tanto de sentirse especial y distinguido respecto de quienes aún no logran alcanzar este carácter de especial. Es también desde aquí desde donde buscamos la diferencia, aquello que no nos hace como esos, pero que indefectiblemente busca encontrar su sentido en otros, otros.

fuente: http://www.valevenegas.com/2010/07/un-poco-largo-lo-se.html

La imitación es la base para empezar a innovar. Creo que estas lecciones son importantes, y debemos reflexionar sobre esto, es gratificante escuchar estas lecciones.

Artículos relacionados

• Glee, losers y copyrights
• La Carta de Jefferson (2)
• El copyright del Silencio

Artículos relacionados

• Falso consenso
• El mejor proceso de desarrollo de software
• Linux no es software libre