Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
PROCESO DE DESARROLLO DE SOFTWARE
O LIBRE EN LA SOCIEDAD BOLIVIANA
W
E
R
E
D
B
Y
G Presentado por:
N Alberto Grájeda Chacó n
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
CONTENIDO
P
O
W
E 1. Breve introducció n al software libre.
R
E 2. Desarrollo de Software Libre.
D
3. Software Libre en la empresa. ¿Có mo nuestro país se
B beneficia?
Y
4. Conclusiones.
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
P
O
W
E
R 1
E
D
B BREVE INTRODUCCIÓ N AL
Y
SOFTWARE LIBRE
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
1 1 PROYECTO GNU
P
O
W El Proyecto GNU comenzó en 1984 con el propósito de desarrollar un sistema operativo
E completo tipo Unix el cual es software libre: el sistema GNU (GNU es un acrónimo recursivo
R para “GNU No es Unix'‘. Variantes del sistema operativo GNU, que utilizan el núcleo Linux,
E son bastante utilizadas hoy día; aunque estos sistemas son frecuentemente referidos como
“Linux'', deberían llamarse más exactamente sistemas GNU/Linux.
D
B Sitio web: http://www.gnu.org
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
1 2 SOFTWARE LIBRE
P “ Software Libre” es cuestión de libertad, no de precio. "Software Libre“ se refiere a la libertad
O de los usuarios de correr, copiar, distribuir, estudiar, cambiar y mejorar el software. Mas
W precisamente, se refiere a las cuatro libertades de los usuarios de software:
E
R • La libertad de correr el programa, con cualquier propósito (libertad 0).
E • La libertad de estudiar como funciona el programa, y adaptarlo a sus necesidades (libertad
D 1) El acceso al código fuente es una precondición para esto.
• La libertad de distribuir copias de manera que se puede ayudar al vecino (libertad 2).
• La libertad de mejorar el programa, y liberar las mejoras al publico de tal manera que toda
B la comunidad se beneficia. (libertad 3). El acceso al código fuente es una precondición para
Y esto.
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
1 3 GPL
Licencia Pú blica General GNU (GPL)
P
O La Licencia Pública General GNU, llamada comúnmente GNU GPL, es usada por la mayoría de
W programas GNU.
E
R Esta es una licencia de software libre, y licencia de copyleft. GNU recomienda esta licencia para
E la mayoría del software que se realiza con éste propósito.
D
Esta designada para tener la libertad de compartir y cambiar el software.
B Distribución libre de copias, no gratis.
Y
Para la protección del autor, todos deben entender que no hay garantías para el software libre. Si
G el software es modificado por alguien y redistribuido, el proyecto GNU quiere que los que
recibieron el software sepan que no es el original, de esta manera en caso de problemas se salva
N la reputación del autor.
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
1 4 LGPL
Licencia Pú blica General Reducida GNU (LPGL)
P
O La Licencia Pública General Reducida GNU es usada por algún software. Esta licencia fue llamada
W en un principio GPL para bibliotecas pero se cambio el nombre debido a que el nombre antiguo
E animaba a la gente a emplear esta licencia más de lo debido.
R
Esta es una licencia de software libre, pero no una licencia de copyleft, porque permite el enlace
E con módulos no libres. Es compatible con GPL. GNU recomienda su uso en circunstancias
D especiales solamente.
B Esta licencia se aplica a las personas que designan módulos de software, normalmente librerías.
Y Otras personas pueden decidir usar este software.
Si se distribuye copias de una librería ya sea gratis o por un costo, se debe dar a los que reciben el
G software todo los derechos del software original, deben poder tener el código fuente o una
N referencia de donde se encuentra.
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
1 5
FDL
Licencia Libre de Documentació n GNU (FDL)
P La Licencia Libre de Documentación GNU es una forma de copyleft para ser usada en un manual,
O libro de texto u otro documento que asegure que todo el mundo tiene la libertad de copiarlo y
W redistribuirlo, con o sin modificaciones, de modo comercial o no comercial.
E
Secundariamente, la licencia preserva un crédito del trabajo realizado por parte del autor y del
R publicista. Mientras no se considera las posibles modificaciones hechas por otros.
E
D Esta licencia se ha designado principalmente para los manuales que se realizan del software libre.
B Copyleft
Y Copyleft es la forma general de hacer un programa software libre y requiere que todas las
modificaciones y versiones extendidas del programa sean también software libre.
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
1 6
Libre no es gratis
P
O no libre, gratis :
W Internet Explorer, MacTCP, Acrobat Reader, freeware, etc.
E no libre, pago :
R [sin comentarios] . . .
E
D
B libre, gratis :
Y Mozilla, Linux, FreeBSD, OpenBSD, sendmail, perl, etc.
libre, pago :
G distribuciones comerciales de Linux, el software que usted va a encargar a un programador, que
va a contratar, . . . y pagar!
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
P
O
W
E
R 2
E
D
B DESARROLLO DE SOFTWARE LIBRE
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
21 SOFTWARE LIBRE VS SOFTWARE
PROPIETARIO
P
O
Software libre (acceder/modificar el có digo fuente):
W •Ventajas pedagógicas indiscutibles : se crean ingenieros mas competentes
E •Multiplica los verificadores, divide los piratas: el acceso al código fuente atrae a los
R programadores competentes
E •Devuelve el control al usuario
D
Software propietario (ni acceder ni modificar):
B •No permite personalizar el software, ni estudiarlo
•Ningún control de la evolución tecnológica
Y
•Multiplica los piratas, divide los verificadores
•Facilita la creación de monopolios que cobran un impuesto a la información.
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
AMBIENTES DE DESARROLLO PARA
22
SOFTWARE LIBRE
Existe una buena cantidad de ambientes de desarrollo de software libre para diferentes lenguajes
P de programación.
•Editores modo texto
O •Editores modo gráfico
W
E
R Ambientes de desarrollo modo texto
E
D Los editores de texto utilizados con mayor frecuencia
para desarrollar software son vim y emacs. Ambos
editores suelen ser un poco difíciles de utilizar (sus
B comandos son poco intuitivos) pero muy eficientes
Y una vez que el usuario se ha familiarizado con ellos.
Ofrecen las principales características que se pueden
esperar en un editor de software moderno. Por
G ejemplo, tienen coloración de sintaxis para una gran
cantidad de lenguajes de programación, permiten
N editar archivos remotamente (sobre FTP, Secure
U Shell u otros protocolos), etc.
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
AMBIENTES DE DESARROLLO PARA
23
SOFTWARE LIBRE (2)
•Para compilar los archivos se suele ejecutar GCC, el
P compilador del proyecto GNU, capaz de compilar
O código en C, C++, Fortran, Java y otros lenguajes. La
integración entre GCC y estos editores les permite a los
W últimos reportar los errores detectados en el proceso de
E compilación de manera eficiente.
R
E Para manejar programas con varios archivos de código
D fuente se suelen utilizar archivos Makefile, manejados
por GNU Make, en los que se describen las
dependencias entre los archivos. Para proyectos de
B gran tamaño es recomendable utilizar Autoconf y
Automake, dos herramientas también del proyecto
Y GNU, que ayudan con la generación de los archivos
Makefile.
G
•Para depurar código de C o C++ se suele utilizar GDB. La integración de
N Emacs con GDB permite controlar el proceso de depuración enteramente
U desde Emacs de manera bastante práctica.
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
AMBIENTES DE DESARROLLO PARA
24
SOFTWARE LIBRE (3)
Otra alternativa diferente es utilizar un ambiente de desarrollo integrado (a éstos se les suele llamar
P IDEs, del inglés “integrated development environment”). Entre algunos de los IDEs disponibles en
O software libre se encuentran los siguientes:
W
E
R Anjuta
E
D Un ambiente de desarrollo pensado
especialmente en C y C++. Fue escrito por
B el proyecto GNOME utilizando GTK+ y
Y provee manejo de proyectos, guías
(wizards) para guiar la creación de
aplicaciones, depuración interactiva y
G edición de código.
N http://anjuta.sourceforge.net
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
AMBIENTES DE DESARROLLO PARA
25
SOFTWARE LIBRE (4)
Eclipse.
P
Un avanzado ambiente de desarrollo, que suele ser muy utilizado para proyectos basados en Java. Es
O bastante modular y existe una gran cantidad de plugins que aumentan su funcionalidad, excelente
W herramienta para trabajar J2EE. http://eclipse.org
E
R KDevelop
E
Un ambiente desarrollado por el proyecto
D KDE. Provee manejo de proyectos
(generación de archivos Makefile),
B integración con herramientas de traducción
e internacionalización, depuración interativa,
Y control de versiones, edición de código y
generación de interfaces gráficas (tanto
para KDE/Qt como para GNOME/GTK+).
G Soporta proyectos basados en C, C++,
N Java, Add, Perl, Ruby y Pascal.
U http://www.kdevelop.org
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
AMBIENTES DE DESARROLLO PARA
26
SOFTWARE LIBRE (5)
GPHPEDIT
P Excelente herramienta para editar código en php, presenta coloración de sintaxis, verificación de código
O fuente, panel clases, etc. http://www.gphpedit.org
W
E
R
E
D
B
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
27 ¿QUÉ SIGNIFICA UN PARADIGMA DE
PROGRAMACIÓ N?
P
O
W Un paradigma de programación, refleja la manera de pensar de los desarrolladores, la
E manera en que afrontan los problemas y construyen sus soluciones.
R
E Los principales paradigmas de programación son la programación orientada a objetos,
D la programación funcional, la programación orientada a tablas, la programación lógica, la
programación orientada a aspectos y la programación imperativa.
B Algunos paradigmas son muy profundos y tienen muchas implicaciones sobre la
Y actividad de desarrollar software, mientras que otros se centran en aspectos mucho
menores pero que, según sus proponentes, hacen que este proceso sea mucho más
eficiente.
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
28 ¿QUÉ PROGRAMAS DE SOFTWARE LIBRE HAN SIDO DESARROLLANDO
UTILIZANDO PROGRAMACIÓ N ORIENTADA A OBJETOS?
P
O Muchos programas importantes de software libre han sido desarrollados utilizando
W programación orientada a objetos.
E
Por ejemplo, para los dos proyectos de escritorios gráficos de software libre más
R importantes:
E GNOME http://www.gnome.org
D KDE http://www.kde.org
B La metodología de programación orientada a objetos ha sido fundamental y está
Y presente en sus librerías más importantes. Otros ejemplos importantes los constituyen:
Mozilla, uno de los más importantes programas de navegación, http://www.mozilla.org
G OpenOffice, la suite de herramientas de oficina de software libre más avanzada,
N http://www.openoffice.org
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
29 MODELO CATEDRAL VS. MODELO BAZAR
Eric S. Raymond
P MODELO CATEDRAL DE LA MAYORÍA DEL SOFTWARE COMERCIAL
O CONTRA EL MODELO BAZAR DEL SOFTWARE LIBRE.
W
E
R
E Modelos opuestos en la depuració n de software
D
• Linux apareció a principios de 1993
B • Estilo de desarrollo de Linus Torvalds: "libere rápido y a menudo, delegue todo lo que pueda,
Y sea abierto hasta el punto de la promiscuidad"
• El bazar parecía funcionar bien, comunidad linux colmado de individuos y con diferentes
necesidades.
G • Pensamiento de los programadores, analistas de sistemas, ingenieros de sistemas y todas
las personas envueltas en el proceso de desarrollo de software.
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
210 PROCESO DEL DESARROLLO DE SOFTWARE
EL CICLO DE VIDA CLÁ SICO
P
O •Requisitos del sistema.
W •Análisis
E •Diseño
R •Implementación
•Pruebas
E •Mantenimiento
D
Requisitos del Sistema
B Abarca la recopilación de requisitos globales a nivel del sistema
Y
Análisis
Comprender el ámbito de información, así como la funcionalidad.
G
N Diseñ o
Cuatro enfoques: Estructura de los datos, Arquitectura de Software, detalles procedimentales
U y la interfaz.
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
211 PROCESO DEL DESARROLLO DE SOFTWARE (2)
P Implementació n
Llevar a código de máquina el diseño del paso anterior.
O
W Pruebas
E Pruebas de validación del programa realizado.
R
E Mantenimiento
D El software probablemente sufrirá cambios, debido a nuevos requerimiento o errores
encontrados.
B
¿Y EN EL SOFTWARE LIBRE...?
Y
• Análisis y diseño, normalmente por el impulsor del proyecto a desarrollar.
G • Implementación, por un número indefinido de programadores.
• Pruebas, por un número indefinido de usuarios que se interesen en el software.
N • Mantenimiento: Nuevos programadores que interesados en el software, así como todos los
U antiguos.
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
212 PROYECTO DE SOFTWARE LIBRE
Todo buen trabajo de software comienza a partir de las necesidades
P personales del programador (o la empresa).
O Todo buen trabajo empieza cuando uno tiene que rascarse su propia
W comezó n.
E
R
E Pasos a seguir en un proyecto de software libre
D 1)Hacer el planteamiento del problema. ¿ Qué problema, que necesidad satisfaceré con el software?.
2)Análisis y diseño siguiendo cualquier metodología de software
3)Implementación:
B a) Usar un lenguaje de programación estandard
Y b) Pensar en una implementación abierta (bases de datos, paradigma de programación,etc)
c) Desarrollar una codificación fácil de entender (tabulaciones, comentarios)
d) Documentación muy importante (cualquiera puede ver lo que hacemos)
G 4)Subir el proyecto a internet, por ejemplo a http://www.sourceforge.net (sitio completo que brinda
administración del sitio, estadísticas, etc).
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
213 PROYECTO DE SOFTWARE LIBRE (2)
5) Coordinación entre los programadores del software. (CVS)
6) Publicar versiones de los adelantos realizados. Versiones beta(en desarrollo) y versiones estables.
P 7) Hacer un seguimiento y mantener informados a los clientes de las mejoras hechas, así como escuchar sus
O nuevos requerimientos.
W 8) Tener publicado un seguimiento a los huecos de seguridad y actualizaciones. (Bugzilla)
E 9) Cuando se haya llegado a una meta cambiar la versión del software
a) Versión 0.1
R b) Versión 0.11
E c) Versión 1.0
D d) etc
10) Repetir desde paso cinco.
B ✔ Dada una base suficiente de desarrolladores asistentes y betatesters, casi cualquier problema puede ser
Y caracterizado rápidamente, y su solución ser obvia al menos para alguien.
✔ La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo
G que quitar.
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
214 BUGZILLA
HERRAMIENTA PARA LA PUBLICACIÓN DE BUGS
P ✔ Permite a los usuarios, testeadores y programadores reportar un bug de la aplicación.
O ✔ Ver un listado de todos los bugs encontrados en la aplicación.
W ✔ Permite buscar bugs.
E ✔ Permite ver diagramas de los bugs.
✔ Permite a los programadores publicar las mejores hechas de los bugs encontrados.
R
E
D
B
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
215 BUGS
P
O
W
E
R
E
D
B
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
216 BUSQUEDA EN BUGZILLA
P
O
W
E
R
E
D
B
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
CONFIGURACIÓ N DE SOFTWARE Y
217
MANEJO DE VERSIONES
El desarrollo de software en equipo debe tener coordinación cuando se trabaja sobre el mismo material:
P
O
W
E
R
E
D La complejidad de interacción incrementa cuadráticamente con el tamaño del equipo.
B DOBLE MANTENIMIENTO
Y
✔ Mantenimiento de múltiples copias idénticas del programa.
✔ Escenario típico:
G ✔ Programador X descubre un paquete para formatear fechas.
✔ El paquete de X corre bien hasta feb. del 2005
N ✔ Mientras tanto, el original ya había sido corregido
U ✔ Inevitablemente múltiples copias divergen.
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
CONFIGURACIÓ N DE SOFTWARE Y
218
MANEJO DE VERSIONES (2)
DATOS COMPARTIDOS
P ✔ Cuando muchas personas acceden y modifican los mismos datos
O ✔ Escenario típico:
W ✔ En un proyecto el código y los ejecutables son almacenados en un espacio compartido.
✔ No hay múltiples copias.
E ✔ Programador Y arregla un bug, introduce uno nuevo, sobreescribe el anterio código.
R ✔ Programador X encuentra un código malo, usa el bug de Y.
E ✔ Cambios compartidos pueden interferir
D ACTUALIZACIÓN SIMULTÁNEA
B ✔ Cambiar una copia, modificarla, testear y luego reemplazarla con la original parecería una buena práctica.
✔ Escenario típico:
Y ✔ No hay dobles copias ni datos compartidos.
✔ X e Y tienen la copia del mismo módulo
✔ X reescribe archivo original.
G ✔ Y hace cambios y reescribe archivo original, los cambios de X no estan en ese archivo.
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
CONFIGURACIÓ N DE SOFTWARE Y
219
MANEJO DE VERSIONES (3)
REQUERIMIENTOS
P ✔ Identificación: esta X usado por Y??
O ✔ Seguimiento a los cambios: Esta el problema B resuelto por C??
W ✔ Selección de versiones: La última versión, bugs arreglados.
✔ Desarrollo
E ✔ Actualización simultánea: Están incluidas las modificaciones hechas por P y Q.
R
E
D CVS
Concurrent Versions System: http://www.cvshome.org
B
Y ✔ Inicializando un repositorio: cvs d DemoCVSRep init
✔ Usando un repositorio como cliente: cvs d :local:DemoCVSRep ...
✔ Importando un proyecto: cvs import m “Inicial” Proy SE v_1_0
G ✔ En la modificación del proyecto: cvs checkout Proy
✔ Actualización de una copia local: cvs update
N ✔ Actualización de un archivo: cvs add src/text.c
✔ Commit cambios: cvs commit m “adicionar test.c”
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
EMPEZAR EL DESARROLLO DE SOFTWARE
220
DESDE CERO
¿DEBEMOS REINVENTAR LA PÓLVORA?
P ✔ Pensamiento japones: Observa al mejor de la competencia, iguala y luego mejora.
O Los buenos programadores saben qué escribir.
W Los mejores, que reescribir (y reutilizar).
E
R ✔ Existe un costo grande en empezar un proyecto, muchas horas destinadas
E ✔ Si necesitamos un software, el mejor lugar para buscar internet (http://www.sourceforge.net), bajamos el
D software, instalamos, usamos, chequeo del código fuente y decidimos adaptarlo. (ver estadísticas de uso,
historia de modificaciones y bugs en su sitio web)
B
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
P
O
W
E
R 3
E
D
B SOFTWARE LIBRE EN LA EMPRESA
Y
¿COMO NUESTRO PAÍS SE BENEFICIA?
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
31 SOFTWARE LIBRE EN LA EMPRESA
Coste del software
P
O Uno de los apartados que sin duda han contribuido al éxito del software libre es su bajo coste,
W tanto para el cliente como para la empresa
E
R • ¿Quién quiere pagar por la herramienta?
E • El hecho de la piratería informática
D • Minimizar los costes de instalación
• IMPORTANTE: tomar en cuenta el coste de pagar a gente especializada.
B Motivaciones para usar software libre
Y
• Motivaciones personales: el afán de superación, la necesidad de reconocimiento, la mejora de
currículum, adquisición de conocimiento
G • El software libre como potenciador del ego
N
U ¿Pero la empresa tiene ese tipo de motivaciones?
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
32 EMPRESA Y SOFTWARE
P
O El concepto de la venta de software de por sí, deja de tener sentido, dando paso a otras
W alternativas. El software deja de ser un producto, sino que se convierte en un medio para
E vender otros productos.
R
E Es una práctica muy común pues, sin llegar al uso del software libre el hecho de regalar el
software, como estrategia de captación de clientes, de creación de usuarios cautivos, y sobre
D
todo, de crear necesidades alrededor del software que se regala, como pueda ser
documentación, cursos, mantenimiento, etc.
B
Y Por todo ello no es de extrañar el apoyo de muchas empresas al software libre: Apoyo puede
realizarse de múltiples maneras, bien colaborando con algún proyecto, directamente o
mediante financiación, bien creando servicios de valor añadido entorno a un proyecto de
G software libre. Otras veces el método consiste en la utilización pura y dura del software libre.
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
33 EMPRESA BASADA EN SOFTWARE LIBRE
PRIMERO Y MUY IMPORTANTE
P Concientizar a todo el personal de la empresa (especialmente a la gerencia) de las
O consecuencias, tanto a nivel organizativo, como de metodología de trabajo, que debe asumir y
W hacer suyas. La primera , y principal es la de adaptar el modelo de trabajo de sus
E programadores al modelo de software libre.
R
E
D Estrategias de desarrollo
Debido que el modelo de desarrollo de software libre es contrapuesto al del software tradicional,
los conceptos de planificación de trabajos, reparto de tareas, integración, paso a producción,
B etc. difieren de gran manera con el desarrollo de software tradicional.
Y
Bazar
Modelo bazar funciona bien en entornos no empresariales, una empresa no puede dejar al azar
G el desarrollo y evolución de su software. Pero siempre debe hacer que el proyecto este dirigido
N a sus intereses. Por ello el modelo bazar "puro" no es aceptable, sino que el grupo de
U desarrolladores de la empresa debe asumir las funciones de un "supervisor de proyecto"
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
MARKETING Y “VENTA” DEL SOFTWARE
34 LIBRE
P
O Tenemos una empresa organizada entorno al software libre, y con un
W producto. Ahora toca venderlo y ganar dinero. ¿Có mo se puede vender un
E producto que es "libre"?.
R
E
D
• Una primera aproximación consiste en ahorrarle al usuario trabajo, a cambio de un mínimo
coste. El concepto de "distribución de paquetes" sigue este modelo.
B • La segunda alternativa es la venta de funcionalidades añadida.
Y • Una tercera vía es la venta de documentación.
• Por último: la de dar cursillos y entrenamiento a los usuarios
• Como efecto marginal, los responsables del proyecto tienen: conferencias, charlas exposiciones,
G etc, son también fuentes de ingreso para la empresa.
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
35 RECURSOS ESCASOS!!
P
O Cualquier empresa que normalmente comienza con el desarrollo de software libre tiene escasos
recursos, algunas técnicas para captar recursos:
W
E • Esponsorización o apadrinamiento.
R • Empresa invierte dinero en una fundación, o asociación, o incluso en un proyecto de
E investigación de una universidad
D • Optimización de recursos de la empresa, mediante técnicas de inversión de capital.
• Valores en la bolsa de (solo para empresas grandes, ejemplo: netscape, RedHat).
B • Liberalización de software
• Restricción a la distribución: se suele prohibir el uso comercial del código fuente liberado
Y • Restricción al formato: los parches y añadidos deben ir aparte de la distribución oficial
Clausula de terminación: La empresa puede restringir sin previo aviso el uso del software
G liberado, tanto en fuentes como en ejecutables
• Captura de proyectos. Venta del producto a otras empresas. (Tora)
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
36 ALGUNAS CONCLUSIONES
Software libre como modelo de desarrollo sostenible
P Se puede afirmar, sin temor a equivocarnos que este modelo es viable, y que constituye un modelo de desarrollo
sostenible, basado en que compartir información constituye una manera de aumentar el bienestar colectivo, y
O que con una adecuada orientación y gestión, el modelo es, no sólo productivo, sino también rentable
W
E No perder el objetivo: obtener beneficios
R
E Focalización de objetivos
D •Los proyectos coordinados por organizaciones sin ánimo de lucro se centrarán en el software como
herramienta, esto es:
o El núcleo del sistema operativo
B o El entorno de trabajo
o Las herramientas de desarrollo
Y o Las aplicaciones de productividad
o Control de estándares y modelos de implementación
• Las empresas obtienen más beneficios del software de valor añadido, tales como:
G o Herramientas de administración y gestión
N o Soluciones a medida
o Proyectos de integración
U o Herramientas específicas para soluciones particulares
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
DESARROLLO DE SOFTWARE LIBRE EN
37 NUESTRO MEDIO
Con la apertura del software, se observan los siguientes fenómenos correlacionados:
P
O • Las naciones en desarrollo tienen acceso a tecnología de primer nivel,
W • están al alcance de individuos y organizaciones herramientas para el trabajo, para los
negocios y para los estudios, que no eran accesibles,
E • se genera y enriquece una masa crítica y una inercia que permiten mayor desarrollo más
R rápidamente; esto está dado por la acumulación y distribución de experiencias y de código,
E así como por la formación de comunidades colaborativas.
D
ES MUY IMPORTANTE EL APOYO ACADÉ MICO DE LAS
B UNIVERSIDADES AL SOFTWARE LIBRE, PARA QUE LOS NUEVOS
Y PROFESIONALES TENGAN UNA GAMA MAS GRANDE DE
CONOCIMIENTO EN DIFERENTES TIPOS DE HERRAMIENTAS,
LENGUAJES DE PROGRAMACIÓ N, ETC.
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
DESARROLLO DE SOFTWARE LIBRE EN
38 NUESTRO MEDIO (2)
El gobierno debería usar y apoyar el software libre.
P
O ¿Por qué?
W
E • Porque así no se exportan grandes capitales.
R • Porque así se genera riqueza intelectual.
• Porque el apoyo económico y moral a universidades y organizaciones de
E educación que lo promueven significa un beneficio indirecto enorme, tanto para el
D gobierno mismo como para la población en general.
• Porque la creación de laboratorios de software libre colocará a países en
B desarrollo en una posición tecnológicamente competitiva con el resto de las
Y naciones de primer mundo.
• Porque se elimina la dependencia de monopolios.
• Porque significa grandes ahorros.
G • Porque permite un nacionalismo sano.
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
DESARROLLO DE SOFTWARE LIBRE EN
39 NUESTRO MEDIO (3)
El software libre es un eje estratégico para los países en desarrollo:
P
O Desarrollo sustentable
El modelo económico del software libre privilegia la pequeña y mediana industria local de
W servicios, mientras el propietario favorece la concentración de riqueza en pocas multinacionales
E
R Creación de empleos calificados
E Y de alto valor agregado de proximidad. Crear una industria automotriz nacional necesita
D inversiones ingentes. Crear una industria de servicios en software libre solo necesita materia
gris. . . y una buena conexión Internet.
B
Protección contra los vínculos impuestos por quien impulsa la propiedad intelectual
Y
Control de la tecnología : la informática es el sistema nervioso del estado.
G
Reducción de costos
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
P
O
W
E
R 4
E
D
B CONCLUSIONES
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
41 CONCLUSIONES
P
O
W
E Software con licencia propietaria.
R Es un software sujeto a varias limitaciones: se debe pagar la licencia (se compra), se está
E sujeto a las posibles limitaciones técnicas de estos programas y las que la licencia impone.
D
El software libre, en cambio, no está sujeto a estas limitaciones de mejora puesto que su
licencia lo permite explícitamente. Está disponible en forma de código fuente abierto y, por lo
B tanto, todo el mundo y puede acceder y puede emplear como quiera.
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
42 VENTAJAS DEL SOFTWARE LIBRE
P Inversión pública e innovación tecnológica
O • Todas las mejoras que se realicen no tienen restricciones
W • Se fomenta la innovación tecnológica del país
E
R Escrutinio público
• Proceso de corrección de errores muy dinámico
E
D Independencia del proveedor
• Disponemos del código fuente del programa
B • No estamos supeditados a las condiciones del mercado de nuestro proveedor
Y
Idioma
• Traducción
G • Corrección ortográfica y gramatical
N Mejora de la presencia de nuestra lengua
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
43 VENTAJAS DEL SOFTWARE LIBRE (2)
P
O
W
E
R
E Datos personales, privacidad y seguridad
• Los sistemas de almacenamiento y recuperación de la información son públicos
D
•Más dificultad para introducir código malicioso, espía o de control remoto
• Seguridad nacional
B
Y Garantía de continuidad
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
44 CRITERIOS PARA LA SELECCIÓ N DE
SOFTWARE
P
O
W Universalidad y accesibilidad
E • Que el software sea de amplia difusión y tenga un precio asequible
• Que el software incluya la posibilidad de ejecutarse sobre máquinas con recursos limitados.
R • Que se garantice la accesibilidad en cualquier plataforma tecnológica.
E • Garantizar la accesibilidad a personas con escasos conocimientos.
D
B Dependencia tecnológica. Protocolos y formatos de intercambio de datos. Extensibilidad y
Y adaptabilidad
• Es necesario que el software use protocolos y formatos estándar.
• Es necesario que el software sea extensible y adaptable, utilizando interfaces abiertas y
G públicas
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
45 CRITERIOS PARA LA SELECCIÓ N DE
SOFTWARE (2)
P
O
W Idioma
• Es necesario que el programa disponga de una versión en nuestro idioma
E • Es necesario que se garantice el servicio técnico sobre la versión traducida.
R • Libre traducción y adaptación.
E
D
Seguridad y privacidad
B • Riesgo de filtración.
Y • Riesgo de imposibilidad de acceso.
• Riesgo de manipulación.
G Soporte técnico y servicios
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
46 CONTRAS
P
O
W
E Soporte Técnico
R • Sino se tiene un programador de la aplicación, esperar a que solucionen el bug, el tiempo de
E respuesta depende de: si el software sigue en desarrollo, el número de desarrolladores, etc.
D En la mayoría de los casos la respuesta es más rápida que en un software comercial.
B Cambios locales del software
Y • Riesgo de incompatiblidad con siguientes versiones
¿Cómo se harán las actualizaciones de huecos de seguridad?.
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
ARTICULOS VINCULADOS CON LA
47 PRESENTACIÓ N
P
O
W
E •La Catedral y el Bazar Eric S. Raymond
R
E •Software Libre: Una oportunidad y una necesidad para el desarrollo del mundo digital
D Roberto Di Cosmo
•La empresa ante el software libre Juan Antonio Martínez
B
Y •El software libre como un importante motor de las economías en desarrollo Sandino Araico
Sánchez, Bruno Antonio Unna Ruiz
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
48
P
O
W
E
R
E
D
COMENTARIOS, PREGUNTAS, RECLAMOS... ETC !!!
B
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia
P
O
W
E
R
E MUCHAS GRACIAS !!!
D
B
Y
G
N
U
Ing. Alberto Grájeda Chacón UPB – Cochabamba Bolivia