¿Cómo compites efectivamente con un proyecto de código abierto?


36

Una empresa con un sólido proyecto de código abierto que compite contra un producto tradicional de código cerrado parece imposible de superar.

Leí este artículo en el que el autor presenta este escenario:

Supongamos que uno pudiera dividir un mercado de software, digamos administración de red, entre dos productos. Uno hizo todo lo posible y costó $ 1 millón, y el otro solo hizo el 10%, pero fue gratuito y abierto.

El precio de la solución comercial filtraría automáticamente una gran cantidad de usuarios, y esas personas tendrían que recurrir al código abierto. Pero algunos usuarios estarían satisfechos con la funcionalidad del 10% y la elegirían directamente.

Por ejemplo, tengo una computadora Macintosh original en mi escritorio. Ejecuta un procesador de textos llamado MacWrite. Hace todo, con la excepción del corrector ortográfico, que necesito un procesador de textos para hacerlo. Puedo formatear párrafos, elegir fuentes, poner el texto en negrita o cursiva e incluso pegar imágenes y gráficos. Todo en una interfaz de usuario "lo que ves es lo que obtienes".

Ocupa 76K de espacio en disco. Eso es "K" como en "kilobyte".

Compare eso con Microsoft Word. Creo que la última vez que instalé solo Word era de unos 30 MB, muchas veces más grande que MacWrite, pero no lo uso por mucho más tiempo que MacWrite. Como yo, muchos usuarios están contentos con la funcionalidad básica. No necesitan todas las campanas y silbatos.

Pero volviendo a mi analogía. Al principio, la empresa comercial probablemente ignoraría el proyecto de código abierto. No representa una amenaza para su flujo de ingresos, entonces, ¿por qué deberían prestar atención a un advenedizo?

Sin embargo, si este proyecto es saludable y sostenible, en un año más o menos tal vez haga entre 15% y 20% de lo que hace el producto comercial. Esto debería desangrar a algunos usuarios más de su negocio, y tal vez ahora comiencen a prestar atención.

Lo más probable es que esta atención tome la forma de marketing contra el proyecto. Afirmarían que es demasiado pequeño o insuficiente para tomarlo en serio. Y a corto plazo esto probablemente funcionaría. Pero el simple hecho de que reconocieran el proyecto despertaría interés. Algunas personas determinarían por sí mismas que no era ni demasiado pequeño ni demasiado poco potente y comenzarían a usarlo.

Pasan uno o dos años más y ahora el proyecto representa hasta el 50% de la funcionalidad del producto comercial. La gente comienza a unirse al proyecto en masa. La empresa comercial ahora tiene que hacer algo. ¿Qué hacen? Añaden más características.

Recuerde, el producto comercial ya hizo el 100% de lo que la gente necesitaba. Entonces, ¿qué tipo de características podrían agregar? Los innecesarios Pueden cambiar el aspecto de la interfaz de usuario o agregar funciones fuera de la administración de la red. En cualquier caso, este desarrollo costará dinero, y eso comenzará a afectar los márgenes de la compañía.

Finalmente, con una comunidad saludable y esta afluencia de nuevos usuarios, el proyecto de código abierto eventualmente se acercará al 80% -90% de lo que hace el producto comercial. Después de agotar todas las vías de generación de ingresos, la empresa comercial todavía tiene una opción final: poner los tornillos a sus clientes restantes. Encuentre formas de cobrarles más, de obtener lo que puedan de su inversión, lo que finalmente alejará a sus clientes.

Farfetched? No lo creo. Solo hay dos requisitos principales:

Primero, encuentre un mercado donde el código abierto ofrezca una alternativa convincente, como la administración de la red.

Segundo, construir una comunidad sostenible alrededor del proyecto de código abierto.

Parece muy plausible. Si fueras una empresa de código cerrado, ¿cómo competirías?


2
Comentaristas: los comentarios están destinados a buscar aclaraciones, no para una discusión prolongada. Si tiene una solución, deje una respuesta. Si su solución ya está publicada, favor de votarla. Si desea discutir esta pregunta con otras personas, utilice el chat . Consulte las preguntas frecuentes para obtener más información.

8
En una respuesta subjetiva como esta, parte de la mejor información está en los comentarios.
Richard

demandar a los usuarios del producto de código abierto en.wikipedia.org/wiki/SCO/Linux_controversies
Ewan

Respuestas:


42

Como no puede competir en precio, compita en todos los otros puntos de venta que tiene el software:

  • caracteristicas
  • calidad
  • eficacia
  • integración con otro software
  • Servicio
  • apoyo
  • venta directa

Básicamente, haces lo que hacen todas las demás empresas cuando compiten con los precios: mantener el ritmo o cambiar el juego.


2
+1 para "Cambiar el juego", si no puedes vencer a tu oponente en sus términos, entonces solo tienes que encontrar los términos que más te convengan.
Matthieu M.

1
Una vez que comience a tener un competidor de código abierto al que realmente valga la pena prestarle atención, una buena manera de pensar en las estrategias comerciales que debe usar es pretender que también está a punto de abrir su proyecto. Cambie su negocio para que siga siendo rentable bajo esa condición, y usted está claro, ya sea que haya abierto su fuente o no
blueberryfields

Yo agregaría: Pregunte "¿quién dirige el asilo"? No dejes que los compañeros manejen el manicomio. Si se trata de programadores, los internos lo son.
mattnz

Creo que cambiar el juego lo hizo por mí. Creo que eso es todo lo que tienes al final.
Richard

1
Por supuesto, debe priorizar sus esfuerzos, y creo que están al revés en esta lista. El código abierto probablemente pueda competir en características, calidad y efectividad, y a veces en la integración con otro software, pero el servicio, el soporte y las ventas son puntos débiles en el código abierto y puntos importantes para los mercados de Big Co.
Kevin Vermeer

34

Al hacer que su producto sea mejor que la oferta de código abierto. Así es como Photoshop puede competir con GIMP.


2
Entonces, ¿es pura dominación de recursos?
Richard

11
No, los recursos no necesariamente hacen un mejor producto.
Stephen C

55
@TheLQ: aplicaciones como Notepad ++, EditPad Pro, incluso Emacs / Vim muestran hasta dónde puede llegar para diferenciar su "editor de texto" en el mercado.
Dean Harding

99
Photoshop es un buen ejemplo de mantener a raya a los clones simplemente por ser un muy buen producto.

44
No hay tal cosa como agotar todas las cosas posibles que puedes hacer.
Kyralessa

33

Creo que la pieza que menciona es muy engañosa, ya que ignora por completo la calidad de la oferta de código abierto. Hágase una pregunta ligeramente diferente pero relacionada:

¿Cómo puede sobrevivir una empresa para sobrevivir vendiendo software de código abierto?

Al ser un colaborador frecuente de algunos proyectos de código abierto, me siento razonablemente autorizado a arrojar algunas rondas de lodo donde lo merece.

Nada de lo que sigue se aplica a proyectos estrella de OSS como Linux, Firefox, MySQL o PostgreSQL. Estos son atípicos, ya que están respaldados por empresas y / o codificadores experimentados.

De todos modos, en cuanto a las razones por las que el cliente pagará por el software:

El OSS es propenso a tener una función de arrastre / Los clientes pagarán por un software más simple

Todos los contribuyentes de OSS tienen su característica favorita. Estos eventualmente encontrarán su camino en la base del código. Se necesita un liderazgo extremadamente experimentado, firme y carismático para evitar el problema, y ​​como cualquier otro individuo, muchos desarrolladores centrales de OSS carecen de al menos uno de estos rasgos.

Agregando insulto a la lesión, por cada característica no esencial que se cuela, otra no lo querrá y esto dará como resultado agregar opciones. Los codificadores tienden a amar las opciones, pero desde el punto de vista de la interfaz de usuario son un camino seguro hacia una muerte lenta y dolorosa por mil cortes.

Los usuarios finales quieren herramientas simples. Necesitan hacer su trabajo sin curva de aprendizaje o problemas. Quieren que sus herramientas tomen las decisiones correctas para ellos; No opciones. Si puede ofrecer algo más simple que la implementación independiente de OSS, obtendrá clientes que pagan.

OSS tiende a ser de baja calidad / Los clientes pagarán por una mayor calidad

No hay nada inherentemente malo en aprender a codificar contribuyendo a OSS, eso sí.

Sin embargo, debe decirse que por cada OSS o biblioteca de alta calidad que está respaldada por todo tipo de razones por corporaciones y codificadores experimentados, hay un océano de código de espagueti propenso a errores escrito por codificadores inexpertos que están contribuyendo con OSS en un esfuerzo para aprender programación, y quién tiene poca o ninguna idea de lo que están haciendo.

WordPress, por ejemplo, fue bifurcado desde B2 (diseñado por un estudiante) por un estudiante. Múltiples versiones y cantidades incalculables de cinta adhesiva más tarde, hace el trabajo. Pero bajo el capó, es una avalancha de errores con poco o ningún control de calidad. (La última vez que lo intenté, no pasó con éxito su propio conjunto de pruebas).

Los clientes pagarán por software bien mantenido y probado. Casi todos probarán las cosas gratis, eso sí, y muchos incluso tolerarán errores hasta cierto punto. Pero si sus ingresos dependen de ello, eventualmente buscarán software de mayor calidad y lo pagarán.

OSS tiende a tener un ciclo de desarrollo demasiado corto / Los clientes pagarán para evitar problemas

Esto es inherente al proceso de desarrollo. Las características de las mascotas que se introducen en la base del código deben publicarse en una escala de tiempo razonable. Si no lo son, el riesgo es que el proyecto OSS perderá algunos de sus contribuyentes.

A largo plazo, sin embargo, las compañías prefieren ciclos de lanzamiento largos; cuanto más largo, mejor. Es menos planificación y menos trabajo para el departamento de TI. No es gran cosa si los usuarios finales actualizan su navegador cada tres meses más o menos. Es una historia completamente diferente si está actualizando aplicaciones de misión crítica.

Hubo una discusión reciente sobre la aceleración del ciclo de lanzamiento en la lista de hackers de PostgreSQL. El argumento final en contra no era sobre el control de calidad y la necesidad de períodos de prueba beta extendidos. Era que algunas compañías ya estaban omitiendo cualquier otro lanzamiento, porque el ciclo de lanzamiento actual (1 año) ya era demasiado rápido para ellos.

Contraste con WordPress, que está debatiendo un ciclo de lanzamiento de 3 meses de vez en cuando a pesar de un ciclo ya demasiado corto. (Sus versiones beta son, para todos los efectos, la versión xy0 de cada lanzamiento).

Al tener algunos clientes que usan WordPress, puedo asegurarles que están más que felices de que los cuide para garantizar que sus sitios no exploten cuando se actualicen. Los clientes pagarán por no tener que preocuparse por este tipo de molestias.

OSS tiende a adoptar estándares abiertos sin pensar / Los clientes solo necesitan cosas para trabajar

La etiqueta de video HTML5 es un ejemplo aquí.

El caso de Mozilla para rechazar h.264 es que quieren un códec de código abierto. Y son absolutamente correctos en este sentido: lo último que quieren es estar en la lista de éxitos de los trolls de patentes; entonces empujan por Ogg.

El caso de Apple para adoptar h.264, por el contrario, es práctico: ya es ampliamente compatible y tiene una aceleración de hardware (lo que permite extender la vida útil de la batería de los iPhones); No hay tal cosa para Ogg.

Millones de dispositivos iOS vendidos más tarde, los sitios preocupados por entregar videos a estos usuarios de iOS admiten html5 / h.264. Dicho de otra manera, los clientes han hablado: no les importan los formatos abiertos.

La única compañía que está contenta con el resultado de esta batalla venenosa sobre los códecs es Adobe: los usuarios de Firefox, de hecho, seguirán necesitando Flash si quieren reproducir videos. Si un sitio importante cambia a videos solo para html5 / h.264, un codificador rápidamente creará una extensión o complemento para convertir las etiquetas de video necesarias en reproductores de video flash. (Incluso podría existir). En nombre de los estándares abiertos compatibles (que flash, por cierto, no lo es).

Nadie fue despedido por elegir IBM

Es una vieja broma de la industria, pero la verdad es que: cuando manejas un presupuesto de TI, no te despedirán por elegir lo que tus compañeros consideran el mejor de la raza.

Los grandes compradores corporativos que no desean correr riesgos continuarán comprando equipos de escritorio basados ​​en Microsoft, Office, SAP y lo que no; incluso si hay alternativas de código abierto. Mucho como la mierda sucede .

Cuando OSS se abre paso en entornos corporativos grandes, generalmente no se debe a que el CTO vio la luz y decidió usar herramientas gratuitas; más bien lo está canalizando un tercero que ofrece servicios (caros) en la parte superior.


3
"OSS tiende a tener un ciclo de desarrollo demasiado corto", pero si está utilizando OSS no necesita seguir el ritmo del último desarrollo, tiene la opción de usar la versión anterior de forma indefinida y actualizar solo cuando tenga sentido para su negocio . Con el software de código cerrado, dependiendo del plazo de licencia, esto a veces es más difícil. Además, si un software de código abierto deja de ser compatible con una versión anterior, tiene la opción de bifurcar la versión anterior y corregir errores / problemas de seguridad usted mismo. Con el código cerrado, no tiene esa opción, por lo que puede actualizar o quedarse con el error para siempre.
Lie Ryan

55
"Nadie fue despedido por elegir IBM" Pero, ¿qué pasa si el mejor software de la industria es de código abierto, por ejemplo, Apache? o, tal vez en unos años, si Android va a vencer a Nokia?
Lie Ryan

2
No tiene muchas opciones para elegir versiones antiguas indefinidamente cuando tienen agujeros de seguridad. Intente instalar WP 2.3 en un servidor web y vea cómo está antes de que un bot lo encuentre y lo piratee. Y no, la cinta adhesiva (es decir, las correcciones de seguridad de puertos posteriores) no es una opción razonable para Joe Average. Con OSS, usted también se ve obligado a actualizar o quedar atrapado con errores para siempre.
Denis de Bernardy

2
@Denis: un Joe Average teóricamente podría contratar a un Desarrollador de Jack para respaldar las soluciones de seguridad que necesita; Puede que no sea la mejor decisión comercial, pero él puede (y eso es lo que importa). Con el código cerrado, una vez que se detiene el soporte, el programa se congela para siempre (se puede argumentar que esto a veces es mejor, ya que solo tiene la opción simple de actualizar, por lo tanto, no necesita darle la oportunidad a un atacante de explotar su programa mientras estás contemplando si actualizar o no)
Lie Ryan

66
"OSS es propenso a presentar deslizamiento": Absolutamente no. La mayoría de los programas OSS son pequeños programas de hacer algo bien, aunque su visibilidad pública es menor que los grandes proyectos que intentan imitar a un competidor comercial monolítico.
tdammers

19

Creo que el quid del argumento, que "el producto comercial ya hizo el 100% de lo que la gente necesitaba", es donde el argumento se desmorona. Ningún producto puede afirmar que hace el 100% de lo que la gente necesita y, desde luego, no de la manera más eficiente (en términos de eficiencia del operador), fácil de usar y universalmente aceptada.

Si tal cosa fuera posible, entonces, por supuesto, lo único que queda por competir es el precio. Pero dado que es imposible una aplicación "mejor" objetiva y universalmente "más eficiente", siempre habrá más cosas que solo precios para competir.


Gracias por reventar un poco la burbuja para mí. Eso tiene sentido. :-)
richard

8

Hay algunos puntos buenos en ese artículo, pero, una vez más, el mundo real parece un montón de ejemplos en los que las empresas de código cerrado están bien. Aquí hay algunos

  1. Linux contra Windows
  2. PHP vs. ASP.NET
  3. [algo u otro] vs. Visual Studio
  4. GIMP vs. Photoshop (fue respondido antes que yo, pero realmente necesitaba un ejemplo que no fuera de MS :))
  5. vBulletin vs. 30+ otros paquetes de tablones de anuncios

El problema con el código abierto es que está abierto. Si tiene ese código, produce el producto A. Toda su competencia tiene el mismo código. Por lo tanto, pasa todo este tiempo escribiendo software, otros contribuyentes pueden hacerlo, pero si administra una empresa, está gastando recursos y, sin embargo, cualquiera puede venir y comenzar a vender exactamente lo mismo que ha pasado años. desarrollando. Por lo tanto, la mayor amenaza para una compañía de código abierto puede no ser necesariamente una compañía de código cerrado, sino las otras 5 compañías de código abierto.

Por otro lado, si desarrollo un software de código cerrado, sí, puedes copiar mis ideas, pero aún podría estar años por delante de ti en el desarrollo de software y para cuando entres en el mercado, ya podría tener el 90%.

Por último, en general, las empresas que no comparten código pero cobran por su software generan más ingresos que los proyectos de código abierto. Tan pronto como se generan esos ingresos, una parte de ellos se reinvierte no en ingeniería (lo que podría argumentar que podría ser gratuito si tiene muchos contribuyentes de código abierto) sino en marketing y promoción del producto y ahora está hablando de millones de dólares por que no existe el trabajo libre.

Al final del día, esta es la fórmula para su éxito: [innovación en ingeniería] x [marketing] = beneficio. Puede tener el mejor producto, pero si nadie lo sabe, nadie lo usa. Y claramente, si construyes algo malo, ninguna cantidad de publicidad lo va a salvar. Creo que muchos proyectos de código abierto siempre han tenido problemas con [marketing] cuando se trata de penetrar en los mercados generales de consumo.


1
La mayoría de los editores de texto y VS están en mercados separados.
alternativa

@alternative La mayoría de los IDE y VS están en mercados separados.
Andy

6

Un área donde la mayoría del software de código abierto no puede competir con el software propietario es en la curva de aprendizaje.

Históricamente, he tenido dificultades para incorporar todos menos algunos de los software de código abierto más populares en mi conjunto de herramientas. Por lo general, son geniales cuando los descubro, pero generalmente no experimento esta frustración inicial con el software propietario.

No estoy seguro de por qué este es el caso. Sin embargo, puedo decir que estoy más que dispuesto a pagar por el software que hace el trabajo con el mínimo esfuerzo de mi parte. Ese es el propósito del software después de todo.

Haga que sea más fácil de implementar que la competencia de código abierto y la gente pagará.


diferentes anécdotas, generalmente tengo menos problemas para aprender software de código abierto ya que a menudo tienen más manual / documentación y más foros de discusión a los que se puede llegar desde Google. Si bien no todo el software de código abierto tiene una excelente documentación o foros de discusión del mercado de accesorios, los que lo hacen suelen ser más fáciles de trabajar que la alternativa de código cerrado. Por ejemplo, descubrí que Python es mucho más fácil de aprender que Visual Basic .NET. Encontré más consejos y trucos sobre ajustar / arreglar el sistema Linux de los que solía tener cuando usaba Windows.
Lie Ryan

4

Usabilidad y características: lo único que tendrá un proyecto comercial de código cerrado que la mayoría de los proyectos de código abierto no tendrá es la capacidad de controlar una visión sólida de lo que se supone que es y debe hacer el producto.

Todo esto depende del tamaño / complejidad, pero un producto de software de un solo equipo más pequeño podrá enfocarse en el mercado al que están tratando de atraer. (Ese otro ejemplo: cómo BBEdit y TextMate pueden atraer a un grupo de personas dispuestas a pagar por un editor de texto dada la disponibilidad de jEdit, gEdit, etc.) ¿Qué ofrece TextMate que es lo suficientemente atractivo como para hacer que las personas gasten más de $ 20? - $ 30?)


Para responder a tu pregunta: ¡un montón de rumores de mac-fanboy! Nunca he visto algo que realmente me haya impresionado en ese editor.
alternativa

3

Al centrarse en problemas específicos del cliente. Muchas veces he visto organizaciones gastar miles de dólares en 'esa característica'.

Como producto de código abierto, tienen que enfocarse en las masas (desafortunadamente, las masas no compran ese software 10K +), como una fuente cercana para la organización de ganancias, si puede satisfacer la necesidad de sus clientes clave / críticos que seguirían más negocios.

Como @SnOrfus ya mencionó, el servicio y el soporte son críticos. ¡He visto millones de veces, las organizaciones prefieren el código cerrado sobre el código abierto (e incluso pagan más) para obtener la comodidad de poder encontrar a alguien solo_en_case!

(Esto podría ser un poco centrado en el cliente corporativo)


1

La solución comercial puede afirmar correctamente que su fortuna está alineada con el éxito de sus clientes. De esto se trata el posicionamiento del producto. Con algunas excepciones, las herramientas de código abierto generalmente se consideran el paraíso de los piratas informáticos, no exactamente una solución puntual centrada en el cliente.

Si su cliente necesita alguna función, tiene el poder financiero para entregarla a tiempo. Tiene la capacidad de proporcionar soporte 24x7 (y cobrar por él), la reparación garantizada de problemas críticos de nivel 0, el acceso a la tecnología de nueva generación mucho antes que la comunidad de código abierto si trabaja con OEM.

Úselos para su ventaja. Deje que el producto gratuito también esté en el mercado, no sea hostil. En todo caso, esto expande el mercado: en algún momento, los usuarios del producto gratuito pueden querer probar las ventajas y desventajas de su solución comercial.


1

En aras de la simplicidad, reduzcamos los factores de éxito de un software en tres "inversiones":

(Aquí, "inversión" es un término colectivo para actividades en las que tiene que pagar ahora, para recibir ingresos más adelante).

  • ventas y marketing
  • desarrollo (incluye código fuente, diseño de producto / interfaz de usuario, documentación y materiales de capacitación. Cantidad multiplicada por calidad. Cualquier producto de trabajo producido aquí puede replicarse a bajo costo a un número ilimitado de usuarios)
  • servicios (experiencia en el software y el dominio, y la capacidad de proporcionar mejoras de valor agregado por cliente)

El KPI para el desarrollo es simple: ¿puede desarrollar lo mismo mejor y más barato que otros? Parte de esto es pura inversión de recursos y la otra parte es la sabiduría del arquitecto y los diseñadores.

Para los servicios, tener acceso al código fuente del producto es una gran ventaja. Una compañía que no tiene acceso al código fuente a menudo no puede proporcionar el mismo nivel de servicio que otra compañía que tiene acceso.


Ahora volvamos a la pregunta del OP: ¿una empresa de código cerrado tiene una estrategia de supervivencia?

El artículo citado por OP parece ser autolimitado porque solo considera dos extremos:

  • Una compañía de código cerrado desarrolla todo el código fuente de su bolsillo y tiene cero líneas de código de código abierto.
  • Una empresa de código abierto adopta plenamente el principio y abre cada línea de código desarrollada.

¿Qué tal los terrenos intermedios?

  • ¿Varias compañías de software firman acuerdos de licencia cruzada para compartir parte del código fuente y / o API? (En el que una de las partes está orientada a los servicios).
  • Empresas que hacen un buen uso de componentes o bibliotecas de código abierto con licencia de estilo BSD (y hacen contribuciones en especie), sin abrir el código fuente del producto principal?
  • ¿Empresas que proporcionan el código fuente del software en progreso a través de un acuerdo de "vista previa comunitaria" por tiempo limitado?
  • "Fuente disponible": ¿compañías que proporcionan código fuente a clientes que pagan?

Mi punto de vista es que las empresas pueden sobrevivir si adoptan una estrategia de código fuente parcialmente abierta y parcialmente cerrada, y si les va bien en los tres frentes (marketing, desarrollo y servicios). Las empresas que adoptan una filosofía fiel a la apertura también pueden sobrevivir, y también tendrán que hacerlo bien en los mismos tres frentes.


Sin embargo, existe una advertencia: si un software es gratuito, ¿los clientes lo elegirán entre las alternativas, incluso si el software funcionó mal en algunas de las métricas?

  • ventas y marketing: ¿puede promocionar un producto casi sin costo a través del marketing viral?
  • desarrollo: ¿puede un proyecto de código abierto obtener la mayor parte de su diseño / desarrollo / documentación de voluntarios no remunerados? ¿Puede una empresa obtener beneficios de dicho proyecto?
  • servicios: ¿puede un proyecto de software revolucionar su dominio de software para hacerlo muy simple, de modo que todos puedan convertirse en expertos instantáneos, reduciendo la barrera de entrada a cero?

1

El proyecto de código abierto persigue al proyecto comercial en términos de características. Esto deja una especie de arbitraje temporal para que la empresa comercial compita en las características. Tienen que competir para implementar características constantemente para retener una ventaja sobre la compañía de código abierto. Es caro, pero puede funcionar.

Como han mencionado otras personas, las características pueden incluir documentación y facilidad de uso.

La corporación puede tratar de inculcar el bloqueo de proveedores, pero eso solo ralentiza la pérdida; no te gana ningún cliente.

Esto deja dos formas principales de mantener la participación en el mercado: soporte y explotación de la desconfianza gerencial del software de código abierto. Lamentablemente, esto último te llevará bastante lejos. Sin embargo, vender soporte funcionará, e incluso cuando el proyecto de código abierto se alcance lo suficiente como para que una compañía venda soporte para él, la solución comercial tendrá una ventaja al ser el titular y tener más experiencia, y también por la impresión de que son más familiarizado con su producto.

A largo plazo, es probable que te jodan, pero esto puede hacer que "el corto plazo" se convierta en "el futuro previsible".


Estoy de acuerdo contigo. Realmente creo que, a la larga, no se puede detener el código abierto. Es como la industria de la música y el cine ... puedes detener a las masas, y lo que las masas exigen, las masas obtienen. En el caso del código abierto frente al código cerrado, el código abierto (creo que a la larga) ofrecerá las características con el mejor precio y soporte.
Richard

1

Una cosa que nadie más ha mencionado es la documentación. Muchos programas realmente no necesitan mucho para ser utilizables (Firefox, Openoffice), pero si escribe una biblioteca, algún tipo de servidor, un lenguaje de programación o simplemente un programa realmente complicado, la documentación puede hacer que la suya se destaque.

Mejorar la documentación puede reducir la frustración de sus usuarios (haciéndolos más propensos a seguir usando su producto y sugerir usarlo en el futuro), y puede anunciar que el dinero está bien gastado porque sus clientes no pasarán tanto tiempo codificando (y tiempo == dinero).

Sin embargo, esto no es necesariamente de código abierto frente a código cerrado: prácticamente todo está mal documentado. Puede ser que su competidor esté en ese 1% de los proyectos que documentan bien las cosas, pero es poco probable;)


1

En pocas palabras, el truco es seguir redefiniendo al 100%. FOSS simplemente no tiene la misma escala y mano de obra que un proyecto comercial, y existen límites en cuanto a la competencia con un producto existente. La empresa de código cerrado usa ganchos de interfaz de usuario, por lo que el uso de un producto de la competencia se siente imposible debido a diferentes métodos abreviados de teclado. Además, siguen agregando características importantes que un competidor de FOSS simplemente nunca podría considerar. Por ejemplo, considere Visual Studio. Era solo un IDE de C ++, pero luego comenzaron a agrupar lenguajes y marcos completamente nuevos, como .NET. O Visual Studio 2010, que empaqueta una biblioteca de subprocesos de grado comercial (como en Intel vende un equivalente independiente) para C ++. FOSS simplemente no puede mantenerse al día con ese tipo de desarrollo y, a menudo, con la confiabilidad.


0

Apunte a los mercados empresariales tradicionales y sea popular.

Para muchas grandes empresas tradicionales se reduce a tres cosas:

  • un proveedor con el que pueden celebrar un contrato vinculante (capacidades y confiabilidad)
  • un proveedor con el que pueden hacer cumplir contractualmente un acuerdo de nivel de servicio específico (acelerar la calidad del soporte)
  • revisiones de Gartner (este es el equivalente moderno de "nadie es despedido por elegir IBM)

Los tres son seguidos sin pensar, y no son particularmente válidos. Los problemas de capacidad siempre están sobrevendidos, los acuerdos de nivel de servicio siempre tienen una excusa y Gartner solo encuesta al tipo de personas que escuchan a Gartner, pero cuando usted es gerencia media en un cuerpo que tiene una gran cantidad de gerencia media alta que se mete en problemas con la gerencia superior cuando la alta gerencia finalmente se entera de que ha habido una decisión descabellada que ha costado una gran cantidad de dinero, necesita documentación de un tercero que respalde su posición si desea salvar su trabajo. Incluso si sabe muy bien que desde un punto de vista técnico está tirando grandes cantidades de dinero por el inodoro, no vale la pena el riesgo de intentar hacer lo correcto.

¿Cuántos malos usos de SAP o SharePoint has visto en la industria? ¿Cuántos de ellos habrían sido mejores si se hubieran hecho en otra cosa que encajara mejor, pero no un gran nombre de la industria?

Utilizo muchas herramientas de Microsoft y tengo una cuenta de MSDN, pero honestamente obtengo mejor ayuda de la gente de MS en Twitter que a través del centro telefónico de MSDN. No puedo imaginar que recibiría una ayuda peor de la gente detrás y del proyecto de código abierto que lo que obtengo de personas que no son de soporte que tuitean en su tiempo libre, pero eso no entra en la ecuación de Responsabilidad / Gartner.


-2

Como dijo SnOrfus, vendemos las características que lo hacemos.

Por ejemplo: desarrollamos complementos con algunas características comunes y lo hacemos gratuito para descargar en el sitio de Wordpress. Al mismo tiempo, tenemos nuestro complemento de versión paga que tiene características profesionales.

Esto le ayuda a presentar su producto a personas masivas, es decir, el poder del código abierto y las personas.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.