¿Puede sobrevivir un lenguaje de programación de código cerrado? [cerrado]

La respuesta es sí, y no. Depende de las motivaciones comerciales de los clientes potenciales y los atributos del lenguaje y los problemas que resuelve.

No, el mundo no necesita otro lenguaje informático de propósito general creado por un individuo o un pequeño equipo. Cuando se crearon Perl, Python, Ruby, Java y Javascript, había que llenar un vacío, los lenguajes propietarios eran caros y la barrera de entrada era baja. Rebol es uno que comenzó pagando y ahora es gratis. Mire C # y vaya a ver cuánto más difícil es ahora y cuánto más grandes son los equipos, incluso para los idiomas que son más o menos gratuitos.

Pero sí, el mundo necesita con urgencia nichos de idiomas para cumplir una amplia gama de roles específicos y pagará bien por ellos. No puedo citar sus ejemplos porque ni usted ni yo hemos oído hablar de la mayoría de ellos, pero se utilizan de forma rutinaria en situaciones altamente especializadas y hacen dinero para sus creadores. Resuelve un problema y te pagarán.

Entonces, para que tu amigo gane dinero, necesita una o más de tres cosas.

1. Un nicho técnico identificable para el cual su idioma es la mejor solución disponible, preferiblemente con una barrera de entrada razonablemente alta para frenar a los competidores.
2. Un segmento de clientes identificable con un problema que su lenguaje puede resolver, así como la capacidad de pago para que se resuelva.
3. Un cuerpo de código preescrito, documentación, tutoriales y habilidades que permitirán a los clientes ponerlo en práctica de inmediato y comenzar a resolver problemas de inmediato.

Los problemas mencionados al confiar en pequeñas empresas no son exclusivos de los lenguajes de programación, y se resuelven fácilmente por medios comerciales.

Divulgación: Soy el autor de un sistema de lenguaje de programación comercial (Powerflex) que ayudó a muchas personas a construir negocios de software. Esa ventana se cerró cuando se abrió la ventana de Internet.

Un lenguaje no es de código abierto o de código cerrado como tal. Por ejemplo, G ++ es de código abierto, mientras que MSVC ++ es de código cerrado. ISO C ++ tampoco es una norma no propietaria no libre.

Tu amigo podría lanzar una implementación de optimización de código abierto y vender el compilador de optimización de lujo. La interesante propiedad intelectual no será necesaria para una implementación sencilla.

Un idioma existente que funciona con este modelo es PHP / Zend Server

¿Su lenguaje hace algo que la gente suficiente pagará?

Eso es realmente lo único que decide si un modelo de negocio funcionará. ¿Tiene un gran mercado de usuarios lo suficientemente grandes como para no preocuparse por los costos de licencias? ¿El idioma es compatible con dispositivos o estándares con los que los clientes no pueden vivir y que nada más admite? ¿Es tan increíble que los clientes puedan contratar a los mejores y más brillantes programadores y lograr enormes aumentos de productividad con solo usar este lenguaje, y la gerencia entiende esa compensación ?

Si cualquiera de estos o algo comparable es el caso, entonces el modelo de negocio probablemente funcionará. De lo contrario, probablemente no lo haga: tarde o temprano, alguien presentará una medida de reducción de costos que implica cambiar a una alternativa más barata.

Creo que no, no hay espacio para un nuevo lenguaje con una implementación propietaria vendida por una pequeña empresa.

Primero, los desarrolladores tienen muchas otras implementaciones de lenguaje gratuitas (al menos como "en cerveza" y, a menudo, como "en voz"), y no se molestarán en probar un lenguaje (caro).

En segundo lugar, cualquier administrador se opondría de inmediato: ¿qué pasaría con nuestra base de código codificada en el nuevo idioma, si la pequeña empresa que proporciona la implementación del idioma se declara en quiebra? ¡Este argumento probablemente prohibiría a cualquiera comprar la implementación del lenguaje!

^{En contraste, una implementación de lenguaje de software libre puede ser ampliamente evaluada por los clientes, que siempre podría manejar su servicio a otro proveedor, si la compañía original que lo escribió quiebra.}

Desde la perspectiva del cliente, el costo de adoptar un nuevo idioma no está en la licencia de la implementación, sino en las habilidades necesarias para usarlo.

Y hay muchas implementaciones de lenguaje de software libre que casi no se utilizan.

Un idioma no puede ser de código cerrado. Su compilador y las bibliotecas en tiempo de ejecución pueden ser de código cerrado. Sin embargo, la gramática formal de un idioma se puede mantener en secreto y estar legalmente protegida (NDA, etc.) y las tarifas cobradas para su uso.

Tu amigo podría reclamar propiedad intelectual o patente si el lenguaje es tan nuevo y novedoso. Yo mismo tengo muchas dudas de que valdría la pena el esfuerzo.

En estos días, la mayoría de las compañías eligen primero las tecnologías disponibles públicamente, sin importar el trabajo laborioso que sea para lograr el mismo efecto que un enfoque de fuente cerrada. Luego, si la sobrecarga es muy grande, entonces van a una solución estándar de la industria : lenguajes patentados estandarizados (por ejemplo, Matlab), con buena penetración y soporte.

Los lenguajes internos se construyen generalmente como DSL (lenguajes específicos de dominio), y en estos días el esfuerzo es más pequeño que comprar un DSL de alguien más y adaptarlo. Además, los DSL son muy específicos para el dominio del problema.

Ahora, no desalentemos a tu amigo de monetizar su idioma. Hay formas de hacerlo, vendiéndolo a una compañía grande y establecida, o haciendo que algunos inversionistas compren la idea e inviertan en ella, pero su principal problema es que desarrolló una solución sin investigar el problema del desarrollo. Y ese no es el problema lo que él considera el problema, es lo que sus clientes potenciales consideran el problema. Así que él podría salir y hablar con estos compañeros sin dar detalles sobre su solución y hacer que esos muchachos paguen. Esto no es imposible, pero no es muy probable.

Yo mismo tuve esta discusión cuando uno de mis clientes consideró desarrollar aplicaciones importantes utilizando ColdFusion. Personalmente no puedo pensar en ninguna razón para usar CF (y pagar por ello) cuando puedo usar PHP (y no pagar por ello). Sin embargo, CF tiene una gran empresa detrás que pacifica a los fobiacos de OSS (lidiar con suficientes administradores de TI y con toda seguridad se encontrará con algunos de ellos) y es lo suficientemente bueno como para que los desarrolladores realmente lo prefieran.

Sin embargo, el problema es, por supuesto, que tu amigo necesita encontrar algo lo suficientemente bueno y con suficiente respaldo detrás. El primero no es un simple truco en estos días con todas las plataformas de código abierto completamente maduras, y el último requiere el respaldo de una fiesta al menos del tamaño, por ejemplo, de Adobe.

Sin mencionar el hecho de que incluso CF tiene una cuota de mercado marginal en estos días en comparación con OSS.

En resumen, si su amigo es lo suficientemente brillante como para encontrar algo que supere a PHP, Python y amigos y lo suficientemente inteligente como para venderlo a uno de los jugadores más grandes y con mejor reputación en el mercado , la respuesta es "tal vez". De lo contrario, es un rotundo "no".

Creo que la respuesta es un no definitivo en este caso. Tener un nuevo lenguaje impulsado por una entidad pequeña provoca un alto riesgo de fallas importantes o faltan características clave.

Si ese idioma es propietario, entonces, como usuario, estás absolutamente jodido si el idioma no evoluciona en la dirección en la que lo necesitas al ritmo que lo necesitas. Si el idioma es gratuito, puede dedicar dinero o personal al problema (lo que al menos para las empresas más grandes es una opción).

Su amigo estaría mucho mejor vendiendo servicios o productos complementarios. Proporcionar apoyo, formación, consultoría. Se les paga por agregar funciones específicamente solicitadas. Proporcionar herramientas (por ejemplo, en forma de complementos comerciales para IDE populares). Proporcione algunas bibliotecas bajo un modelo de licencia comercial (pero aún con la fuente incluida bajo las restricciones adecuadas).

Aunque odio desalentar a su amigo, creo que es poco probable que logre convencer a la gente de que pague por las herramientas de desarrollo en estos días, a menos que esta herramienta proporcione una ganancia increíblemente enorme en productividad (como en "produce software operativo haciendo que los gerentes busquen bizco en la pantalla mientras pensaba buenos pensamientos !!! "). Para bien o para mal, en estos días hay muy poco mercado para las herramientas de desarrollo de "pago por juego", ya que la cantidad y la calidad de las herramientas gratuitas es excelente. (Lenguajes de testigos como Java, Ruby, Python, Clojure - IDE como Eclipse y LightTable - bases de datos como MySQL y PostgreSQL - la lista sigue y sigue y sigue y sigue y sigue y sigue ...). Le deseo la mejor de las suertes en este esfuerzo.

Se puede. Si es:

• lo suficientemente bueno y / o útil
• si es aplicable lo suficientemente fácil y
• si no es demasiado caro

En realidad, para empezar, debería ser realmente fuerte en 2 primeros artículos y muy descontado en comparación con su valor real.

Veo que la mayoría de las personas se quejan de los gerentes malvados a los que no les gustaría pagar mucho dinero por ello. Nunca dijiste que tu amigo está pidiendo una fortuna por la licencia. ¿Qué pasa si él pide $ 500 al año y le ahorra a la compañía un par de cientos de horas de trabajo cada año? Cualquier administrador inteligente lo tomaría.

Eso depende de si el lenguaje ofrece o no algo lo suficientemente ingenioso como para que yo (representante del cliente) esté dispuesto a pagar por ello.

Como gerente de proyecto debo tener en cuenta:

• El tiempo que toma aprender / dominar ese nuevo idioma.
• La ganancia de eficiencia (tiempo hasta la entrega) en comparación con otros idiomas. ¿Y supera el tiempo para aprenderlo?
• ¿Este idioma resuelve un problema que difícilmente se puede resolver con otros idiomas?
• ¿Este idioma seguirá siendo admitido en 5 años, debería el cliente hacer otra solicitud?

Los primeros 3 puntos se aplican a todos los idiomas y, especialmente, el primero es difícil de superar para cada nuevo idioma, porque necesito razonar el tiempo de muy baja productividad con algo, y es mejor que sea uno bueno.

El cuarto punto es el que se aplica solo a los lenguajes de código cerrado, al igual que con aquellos que dependen de terceros, que pueden existir o no en los próximos 5 años. 5 años antes a partir de ahora, las aplicaciones móviles no eran tan importantes como hoy, ¿el idioma se adaptará a la situación actual y me permitirá escribir aplicaciones móviles también? ¿Será incluso compatible con los nuevos requisitos? Si hay un requisito para mi cliente, ¿puedo comunicarme con el desarrollador de ese idioma y presentar una solicitud de actualización?

Si alguna de esas preguntas se responde con "no", entonces puede ser el mejor idioma del mundo, no puedo usarlo. Y si escucho que hay una sola persona que inventó este lenguaje en su "tiempo libre" y ahora trabaja como una compañía de un solo hombre, sería muy sospechoso al respecto y no usaría el lenguaje, a menos que reciba promesas muy sólidas. y el lenguaje ofrece algo que ningún otro me permite hacer.