Si tu cliente es un gobierno la ventaja mayor es que el gobierno es el propietario y no un tercero, eso se traduce en la practica en que cuando se compra un desarrollo en un sistema privativo la vida depende del dueño del sistema privativo, que bien sabemos como se manipula en combinacion con los fabricantes de hardware, además implica contratos ocultos de duración indefinida como también es fácil de ver. Estas razones son igualmente validas para cualquier empresa privada.<br>
<br><div class="gmail_quote">El 4 de enero de 2010 13:02, Raimon <span dir="ltr"><<a href="mailto:r.artis@gmail.com">r.artis@gmail.com</a>></span> escribió:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Cuando vendes un programa, como digamos un "Punto de venta" o "sistema de comandas para restaurant" con o sin codigo abierto hecho sobre la plataforma que sea, creo que es un producto (puedes dar o no servicio y cobrarlo de cualquier forma despues). Un cuadro o una escultura no los puedes considerar como servicios aunque quepan en tu definicion<br>
Saludos de México<br><br><div class="gmail_quote">El 4 de enero de 2010 10:36, Omar Bautista González <span dir="ltr"><<a href="mailto:omarbautistag@gmail.com" target="_blank">omarbautistag@gmail.com</a>></span> escribió:<div>
<div></div><div class="h5"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Parece que estamos utilizando términos parecidos para distintos<br>
objetos. Es decir, una cosa es el significado y otra es el<br>
significante.<br>
<br>
Por eso, cuando me refiero al término SERVICIO, me refiero<br>
precisamente a cosas que no le atribuyes la categoría servicio, como<br>
yo sí lo hago.<br>
<br>
Yo me refiero al término servicio a todo aquello que genera una<br>
entrada económica en una persona cuando implica un trabajo manual o<br>
intelectual. De ese modo, el servicio difiere notablemente de la venta<br>
de un producto como si fuera de un supermercado, tal como dije antes.<br>
No es lo mismo vender un servicio para poner a funcionar una<br>
maquinaria que vender los productos de esa maquinaria al por mayor o<br>
al por menor.<br>
<br>
En conclusión, se mantiene en pié la idea de que el software difiere<br>
en gran medida del privativo porque su entrada económica depende más<br>
del servicio que de la venta de productos realizados.<br>
<br>
Gracias por continuar la discusión,<br>
<br>
<br>
<br>
2010/1/1 Ismael Luceno <<a href="mailto:ismael.luceno@gmail.com" target="_blank">ismael.luceno@gmail.com</a>>:<br>
> Omar Bautista González escribió:<br>
>> Yo no conozco otros modelos, también espero que me envíen por aquí<br>
>> para aprender.<br>
>><br>
>> Att.<br>
><br>
> Algunos ejemplos de cosas que no son servicios de valor agregado:<br>
> * Desarrollo de software a medida.<br>
> * Mejoras específicas a software existente.<br>
> * Mantenimiento (complicado pero viable).<br>
> * Consultoría relacionada a la selección y/o desarrollo de software.<br>
> * "Charlas empresariales".<br>
><br>
> Nada de esto es extraño al software privativo... ¿qué nos cambia el<br>
> licenciamiento?<br>
><br>
> Como decía antes, la única peculiaridad es que alguien debe asumir el<br>
> costo de desarrollo por adelantado, y por tanto el riesgo :). Desde ese<br>
> punto de vista el desarrollo de software libre es más seguro ;).<br>
><br>
> El software libre no nos impone ningún modelo de negocio, o modelo de<br>
> desarrollo, y tomar malas decisiones no depende de que el software sea<br>
> libre o no. No hay nada mágico en el software libre desde este punto de<br>
> vista.<br>
><br>
> Un buen negocio de software es un buen negocio independientemente de si<br>
> es software libre o no.<br>
><br>
> Hay una verdad que debemos admitir: que a nadie le gusta pagar por el<br>
> soporte, es simplemente un mal necesario.<br>
><br>
> Lo que a todos nos gusta es el software que funciona y funciona bien,<br>
> está bien documentado, es fácil de instalar y mantener, y por encima de<br>
> todo es robusto (seguridad, contingencia, verificación de integridad,<br>
> auto-reparación, etc.).<br>
><br>
> Un modelo basado en soporte solo escala si el producto es deficiente.<br>
><br>
><br>
> _______________________________________________<br>
> Discusion mailing list<br>
> <a href="mailto:Discusion@fsfla.org" target="_blank">Discusion@fsfla.org</a><br>
> <a href="http://www.fsfla.org/cgi-bin/mailman/listinfo/discusion" target="_blank">http://www.fsfla.org/cgi-bin/mailman/listinfo/discusion</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Omar Bautista González<br>
- Coordinador de Investigación para el Desarrollo,<br>
Diseño, Monitoreo y Evaluación<br>
Visión Mundial República Dominicana<br>
- Colaborador en investigación social del movimiento del software<br>
libre en República Dominicana<br>
_______________________________________________<br>
Discusion mailing list<br>
<a href="mailto:Discusion@fsfla.org" target="_blank">Discusion@fsfla.org</a><br>
<a href="http://www.fsfla.org/cgi-bin/mailman/listinfo/discusion" target="_blank">http://www.fsfla.org/cgi-bin/mailman/listinfo/discusion</a><br>
</blockquote></div></div></div><br>
</blockquote></div><br>