[ubuntu-ar] OT: "GNU/linux para informaticos "

[Pablo Lillia]

El 11/02/2009 15:17, cincoclavos en opcionestelmex.com.ar escribió:
>> 2009/2/11 Marcelo Poli <enzomatrix en gmail.com>:
> 
> Estimado Poli: Con lo que Ud. señala me esta dando un poco la razon, si el
> programador de una determinada area de Mozilla hubiese aceptado todos los
> parches que le mandaban, ( me refiero especificamente a lineas de programa)
> tendria un mambo colosal en la cabeza, por lo que yo creo que lo mas importante
> es brindar ideas nuevas sobre algo especifico a efectos de mejorarlo, el envio
> de errores es comun a todos los programas sean privativos o SL.
> 
El envío de errores es común, pero el envío de parches, no. Con el SP no
es posible hacerlos. Al no tener acceso al código fuente, es imposible
enviar un parche. Se puede colaborar brindando información y pruebas,
pero no se puede enviar "un arreglo".

Con el SL cualquier programador capacitado, puede agarrar el código
fuente del programa, *ver* porqué falla, hacer la corrección para
adjuntarla junto al informe del problema.

Luego, normalmente, un "mantenedor" de ese módulo o sección, evaluará y
probará, y/o comenzará un proceso en el que se aceptará/rechazará el
parche. El proceso concreto depende de cada organización.

Meter a todos los proyectos de SL en la misma bolsa, es lo mismo que
meter a todos los proyectos de SP en otra. La gestión de proyectos es
toda una ciencia en si misma, y hay muchas maneras de triunfar, pero
muchas más de fracasar. Lo que funciona para algunos
proyectos/organizaciones, no lo hace en otras (por las diferencias de
contexto, las personas involucradas, etc.).

La diferencia no es poca, es clave: es entre ser meros espectadores o
*poder* ser participantes activos.

A veces cuando un grupo de gente no está de acuerdo con la
administración de un proyecto SL, se producen las divisiones, los
"forks". Esto también puede suceder. Pero como comenté en mi mail
anterior, aun con el riesgo de dividir esfuerzos, es la vía de escape
del SL, un mecanismo de evolución propio, que no existe en el SP por
definición. En la práctica, cuando un proyecto SL está bien gestionado,
no aparecen forks innecesarios. Si un proyecto SL está mal gestionado,
un fork puede salvarlo, rescatarlo. En cambio cuando hay problemas con
un proyecto de software privativo, o se salva solo o muere solo, y nadie
puede ayudarlo/rescatarlo si este no quiere ser ayudado, y los usuarios
serán cautivos de las decisiones de la empresa.

> 
> Ahí le erraste feísimo. Mozilla no es emplado de Google y no le pueden exigir nada.
> 
> Cuan feo le erre?
> 
> Copie y pegue parte de un articulo (www.genbeta.com) sobre este tema yo creo que
> Mozilla atiende 85 % de razones para seguir el direccionamiento que le envia Google.
> 
> Aqui comienza el articulo
>  
> Mozilla sabe jugar muy bien sus cartas y es por eso que la fundación ha decidido
> ampliar su acuerdo con Google por tres años más, hasta 2011, de esta manera
> asegurándose estabilidad financiera en los años que vienen, ya que Mozilla
> seguirá usando Google como página por defecto en sus navegadores y seguirá
> manteniendo al buscador como opción predefinida en la caja de búsqueda.
> 
> Y es que Google aportó en 2006, 57 millones de dólares en ingresos a la
> fundación Mozilla, lo que representó el 85 por ciento de sus ingresos. Como veis
> por eso decía yo al principio que Mozilla sabía jugar muy bien sus cartas. Así
> la fundación usa esa donación del buscador de buscadores a pagar a sus
> empleados, los recursos propios, el ancho de banda necesario para distribuir su
> software y al final como hemos visto, un porcentaje elevadísimo de su
> presupuesto. Este hecho ha llegado a preocupar mucho a la comunidad open source,
> ya que veían a Google como el amo y señor de Mozilla, hecho que siempre se ha
> desmentido categóricamente desde la fundación, aunque ha levantado sospechas
> como es normal. 
> 
> Fin
> 
> Acaso soy el unico que sospecha?
> 
> Saludos
> 
> 

En la Red se pueden encontrar artículos y opiniones a favor y en contra
de casi cualquier cosa ;) Pero analicemos un segundo: ¿cuál es la
preocupación? ¿que Google dicte el futuro de Mozilla, por ejemplo? ¿que
los compren y cierren el soft bajo una licencia privativa?. Aunque es
improbable, si algo así pasara, o si hubiera cualquier decisión
fuertemente cuestionable, por el importantísimo peso que tiene Mozilla y
todos sus aporte al Software Libre, inmediatamente nacería una nueva
organización o grupo de gente que continuaría el proyecto desde el
último byte del código fuente liberado, porque lo que ya está libre, no
puede cambiarse.

Volviendo al tema de las cuestiones de calidad (perdón por volver),
corren por cuenta y obra de las decisiones de la organización/empresa
que libera una versión final, el producto. Son los usuarios los únicos
jueces al brindarles apoyo o no en el día a día. Si los usuarios
perciben "poca calidad" y se sienten defraudados, seguramente se
volcarán a otro proyecto que tomará su lugar. La diferencia entre SP y
SL, es que con el SL no se pierde todo el esfuerzo humano cuando un
proyecto toma mal camino. En tiempos de crisis, es aun más fácil ver la
economía y moral en esto. Al fin y al cabo, ¡It's the evolution, baby! :)

Cuando se requiere una SLA (acuerdo de nivel de servicio), se firman
contratos de servicio con proveedores, con cláusulas de responsabilidad
como en cualquier caso, y no hay conflicto con que el software sea
liberado bajo licencias de SL. Por eso el SL no significa ni "gratis" ni
que los programadores no comen.

Aunque es un debate interesante y didáctico, propongo discutir estos
temas en la lista general de SoLAR o en un ámbito similar, para no
continuar desvirtuando la lista de Ubuntu.

Saludos,
Pablo