¿Organización convincente para avanzar hacia SIG de código abierto? [cerrado]

Después de pasar la mayor parte del año en este sitio, veo cuán grande es la comunidad SIG de código abierto. Solía ​​pensar que era ESRI y nada más. Dicho esto, ¿cómo comienzas a empujar o convencer a otros de que los programas de código abierto pueden ser más beneficiosos que los productos ESRI?

No estoy preguntando específicamente sobre las características de uno frente al otro, sino que realmente estoy tratando de convencer a los superiores de que se muden a un producto similar que proporcione resultados comparables en términos de productividad, eficiencia y producto final.

Supongo que lo que se reduce al final es, al final del día, ¿los ahorros de costos superan el tiempo que podría tomar para que el personal de GIS se aclimate al software de código abierto?

Para empezar, descartaría toda la premisa de código abierto vs propiedad y la vería en términos de "¿la Herramienta A logra lo que necesitamos de una mejor manera que la Herramienta B que estamos usando ahora?"

Luego, haga un seguimiento con demostraciones y ejemplos tangibles de dónde la herramienta que está sugiriendo como alternativa ofrece mejores resultados o tiene un precio de adquisición, un precio de mantenimiento, una curva de aprendizaje, etc., más baratos. Sea justo y equilibrado, no pase por alto las áreas donde la alternativa es débil o tiene huecos.

Un punto a menudo planteado contra el código abierto y para fines comerciales es el soporte, tener a alguien al teléfono o correo electrónico para responder preguntas. Observe bien el apoyo que la organización está obteniendo ahora de las herramientas pagas. ¿Cuántas veces y con qué profundidad son respondidas las preguntas por el soporte técnico pagado en comparación con "desde Internet"? En realidad, recopilar datos y ejemplos para esto. Como antes, sea justo y equilibrado.

Si las respuestas a cualquiera de estas exploraciones son extremadamente pesadas por un lado u otro, es probable que no se hayan hecho suficientes deberes. No es un gran valor en productos de esta naturaleza, y hay también un gran valor en el código abierto. La pregunta es si esos puntos de valor se alinean con su negocio.

También recuerde que no es una propuesta de todo o nada. El S en GIS es System, una red de partes y procesos interconectados. Agregue o reemplace componentes con código abierto, donde eso tenga sentido.

Y finalmente, solo úsalo tú mismo. Cuando alguien pregunta, "¿cómo te fue ...?" ¡Mostrarles!

Mi proceso ha sido instalar y encontrar proyectos / campeones para utilizarlo "bajo" el radar.
Hacer pequeños proyectos que tengan una alta tasa de éxito y lograr que otros estén en la misma página con usted tendrá enormes efectos. También usar el software en un entorno no presurizado lo ayudará a lograr el éxito y le ayudará a aprender a lograrlo.

Cuando comprenda mejor cuáles son sus fortalezas / debilidades, podrá aplicarlo como una herramienta en proyectos más grandes. Esto también mantendrá su integridad unida, permitiendo que otros vean que no está tratando de "tirar" el sistema sino de aumentarlo.

Cuando puede agregar usuarios consumados sin pagar los enormes costos de la administración de licencias establecida. Luego trabaje duro para agregar pagos específicos del proyecto a los desarrolladores del sistema operativo. Esto hará que el ROI sea mucho más fácil de rastrear y presentar.

Se podría decir mucho más sobre este tema. Estoy seguro de que otros también tendrán excelentes consejos. Sin embargo, sigamos siendo constructivos o probablemente se votará como "No constructivo"

No es probable que los gerentes corten a sus empleados de las herramientas ESRI probadas a tiempo sin el apoyo de base. Imagine la alternativa: supongamos que su empresa solo utiliza herramientas de código abierto para realizar el trabajo relacionado con SIG. Si se le impusieran todas las herramientas ESRI repentinas, habría una reducción significativa en la productividad a corto plazo. Por el contrario, es más probable que los gerentes prueben las aguas y vean cómo funcionará una posible transición de herramientas; después de todo, son en última instancia responsables de los resultados.

Adoptaría un enfoque de base y convencería al personal de GIS de cambiar a FOSS en lugar de los superiores . Una bonificación única igual a las tarifas de licencia de un año divididas entre los empleados proporcionaría un buen incentivo. Una vez que el personal de GIS realmente adopte FOSS, los gerentes se darán cuenta de los posibles ahorros de costos y es probable que opten por la transición.

Mucho dependerá de qué componentes de ESRI esté usando su organización. Identifique dónde cambiar a código abierto puede ser más beneficioso.

Si utiliza principalmente ESRI para cartografía o soluciones móviles, puede descubrir que las alternativas pueden costarle más que ESRI. Se pueden obtener ganancias reales cuando está utilizando web gis o haciendo mucho procesamiento, que es donde se destacan las soluciones de código abierto.

Una migración lenta sería menos arriesgada. Siempre que surjan problemas de presupuesto junto con el costo del software, ofrezca soluciones que ahorren dinero, una a la vez a medida que surjan. Cada vez que un proyecto presente una solución de código abierto que pueda manejar la tarea en cuestión, mencione los ahorros y pregunte: "¿Por qué gastar eso en software cuando podemos gastarlo en algo más útil?". Es posible que se incorporen nuevos proyectos que requieran la compra de nuevo software y personal. Siempre que surjan discusiones sobre la reducción de costos, pregunte por qué la organización no está reduciendo el costo del software para que tenga que reducirse en otros lugares, especialmente cuando las soluciones viables funcionan y son completamente gratuitas. En esos momentos, ofrezca utilizar la solución Open Source y ahorre dinero a la organización.

Cuando ingresen nuevos empleados, deles acceso inmediato a aplicaciones de código abierto, con software propietario para que lleguen "según sea necesario". Cuando necesiten algo costoso, pídales que completen una solicitud de software con el motivo por el que lo necesitan, y luego responda con una pregunta. "¿No funciona este software que ya está instalado?" Eventualmente, entregue estos nuevos empleados para ayudar a los empleados establecidos a aprender los accesos directos de la manera de Código Abierto. Entregue a los nuevos empleados una insignia de honor o al empleado de la semana por hacerlo. Conviértalos en las nuevas organizaciones de primera línea para la innovación

Por último, cuando la gerencia le pregunta: "¿Pero por qué no he oído hablar de este software antes?" Simplemente responda la verdad: "¿Un vendedor intentó vendérselo o lo vio en un puesto de vendedores?" ... y "Eso se debe a que, en última instancia, nadie necesita que usemos este software, además de nosotros mismos, porque somos los únicos que nos beneficiamos".

Con el tiempo, algunas de las computadoras de una gran organización pueden reemplazarse con sistemas completos de pila abierta, como Ubuntu, para manejar casi todo, mientras que algunas otras pueden tener aplicaciones mixtas que están en algún estado de transición a alternativas de código abierto, como Gol. Sin embargo, puede haber otras personas en su organización que necesiten apegarse por completo a los sistemas propietarios. No hay una alternativa de código abierto para todo; empujando demasiado lejos, disparos de retroceso demasiado rápidos.

La cantidad de tiempo que se dedica a aprender aplicaciones y sistemas operativos es MÁS INADECUADA. Esta es una gran cantidad de tiempo que pasamos, en nuestro tiempo libre, familiarizándonos con el nuevo software; es principalmente un proceso inconsciente de aprendizaje. El enfoque de migración lenta (con saltos ocasionales) es el mejor, de lo contrario surgirán decepciones más tarde, y con eso vienen las recomendaciones inevitables contra los productos que de otro modo serían beneficiosos para cualquier organización.

Para construir sobre lo que algunos otros han mencionado, las restricciones presupuestarias pueden ser muy útiles.

En mi lugar de trabajo, tenemos un número sorprendentemente limitado de licencias de Esri para distribuir, y el personal a menudo se siente frustrado por su incapacidad para realizar el trabajo SIG necesario. La gente recurre a tácticas como esperar hasta después del horario comercial para obtener una licencia para el día siguiente. En este entorno, descubrí que las personas eran muy receptivas a las herramientas de código abierto.

Estoy de acuerdo con los comentarios que argumentan a favor de migraciones lentas y pequeños proyectos, y la falta de énfasis del código abierto frente al propietario. Si la gente puede ver eso , puedo tener mi propio software SIG sin la molestia de compartir licencias, la gente lo probará por sí misma. También he notado que una vez que las personas tienen una instalación de QGIS en ejecución, comienzan a pedir a otros usuarios que confíen menos en los formatos propietarios de Esri.

¡Lento pero seguro!