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

Un amigo ha escrito un lenguaje de programación. Tiene una sintaxis que recuerda a SGML. Ha escrito un intérprete para ello y un IDE. Él y sus colegas lo usan internamente como lenguaje del lado del servidor. También se puede usar para escribir herramientas de línea de comandos.

Quiere ponerlo a disposición del público, con la expectativa de que la gente compre una licencia para usarlo. Quiere mantener el código expresando la implementación del lenguaje para sí mismo, ya que hay un poco de propiedad intelectual ligada a él.

Sigo diciéndole que el día de los lenguajes de programación de código cerrado se ha ido. Yo digo: "Mira todos los idiomas principales: la gran mayoría son de código abierto. También tendrás que hacerlo de código abierto si quieres que alguien fuera de la empresa preste atención a lo que has creado".

¿Le estoy dando buenos consejos o todavía hay espacio para los idiomas patentados por los que paga?

LUEGO

Den preguntó: "... ¿podría explicar también cómo un idioma puede ser de código cerrado?"

Le dije: "@Haz que tengas un buen punto. Supongo que lo que mi amigo quiere evitar es la situación en la que Microsoft elabora un lenguaje similar a Java, lo llama J ++ y luego se mete en un litigio con Sun sobre su Java-ness ¿Cómo protege una sintaxis y una metodología de programación de ser secuestrada por una compañía cuya implementación podría sacarlo del negocio? "

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

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

Pero sí, el mundo necesita urgentemente idiomas de nicho para cubrir 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 usan de manera rutinaria en situaciones altamente especializadas y ganan 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 pagar para que se resuelva.
3. Un cuerpo de código preescrito, documentación, tutoriales y habilidades que permitirán a los clientes ponerlo a trabajar de inmediato y comenzar a resolver problemas de inmediato.

Los problemas mencionados al depender de 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 idioma 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 ++ no es ninguno, es un estándar no libre y no patentado.

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

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

¿Su lenguaje hace algo por lo que pagarán suficientes personas?

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

Si alguno de estos o algo comparable es el caso, entonces el modelo de negocio probablemente funcionará. De lo contrario, probablemente no sea así: tarde o temprano, alguien va a llegar a 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 gerente se opondría de inmediato: ¿qué pasaría -a nuestra base de código codificada en el nuevo idioma- si la pequeña empresa que proporciona la implementación del lenguaje se declara en bancarrota? ¡Este argumento probablemente prohibiría a cualquiera comprar la implementación del lenguaje!

^{Por el contrario, los clientes pueden evaluar gravemente una implementación de lenguaje de software libre, que siempre podría manejar su servicio a otro proveedor, si la compañía original que lo ha escrito quiebra.}

Desde la perspectiva del cliente, el costo de adoptar un nuevo lenguaje no está en la licencia de la implementación, sino en las habilidades requeridas 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, una gramática formal de un idioma puede mantenerse en secreto y estar legalmente protegida (NDA, etc.) y cobrar tarifas por su uso.

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

En estos días, la mayoría de las empresas eligen primero las tecnologías disponibles públicamente, sin importar cuánto trabajo sea laborioso para lograr el mismo efecto que un enfoque de fuente cerrada haría. Luego, si los gastos generales son muy grandes, entonces recurren a una solución estándar de la industria : lenguajes patentados estandarizados (por ejemplo, Matlab), con buena penetración y soporte.

Los idiomas internos generalmente se crean como DSL (idiomas específicos del dominio), y en estos días el esfuerzo es menor que comprar un DSL de otra persona y adaptarlo. Además, los DSL son muy específicos para el dominio del problema.

Ahora, no desanimemos a su amigo de monetizar su idioma. Hay formas de hacerlo, vendiéndola a una empresa grande y establecida, o haciendo que algunos inversores 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. Entonces él podría salir y hablar con estos tipos sin dar detalles sobre su solución y hacer que esos tipos paguen; esto no es imposible, pero no es muy probable.

Tuve esta discusión yo mismo cuando uno de mis clientes consideró desarrollar aplicaciones importantes usando ColdFusion. Personalmente, no puedo pensar en ningún motivo para usar CF (y pagarlo) cuando puedo usar PHP (y no pagarlo). Sin embargo, CF tiene una gran compañía detrás que apacigua los fobia a los OSS (trata con suficientes gerentes de TI y eventualmente te encontrarás con algunos de ellos) y es lo suficientemente bueno como para que suficientes desarrolladores realmente lo prefieran.

Sin embargo, la trampa es, por supuesto, que tu amigo necesita encontrar algo lo suficientemente bueno y con suficiente respaldo detrás de él. El primero no es un 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 de, por ejemplo, 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 inventar algo que eclipse a PHP, Python y amigos y negocios lo suficientemente inteligentes como para venderlo a uno de los jugadores más grandes y de mayor 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 críticas o características clave que faltan.

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

Su amigo estaría mucho mejor vendiendo productos o servicios complementarios. Brindar apoyo, capacitación, consultoría. Obtenga un pago 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 restricciones adecuadas).

Si bien odio desanimar a tu 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 de trabajo al hacer que los gerentes se vean con los ojos cruzados en la pantalla mientras piensas bien !!! "). Para bien o para mal, actualmente hay muy poco mercado para las herramientas de desarrollo de "pago por juego", ya que la cantidad y calidad de las herramientas gratuitas es excelente. (Sea testigo de lenguajes 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 ...). Le deseo la mejor de las suertes con este esfuerzo.

Puede. Si esto es:

• bueno y / o suficientemente ú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 gerentes malvados a los que no les gustaría pagar grandes sumas de dinero; nunca dijiste que tu amigo está pidiendo una fortuna por la licencia. ¿Qué pasa si él pide $ 500 anuales y le ahorra a la empresa un par de cientos de horas de trabajo cada año? Cualquier gerente inteligente lo tomaría.

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

Como gerente de proyecto, debo tener en cuenta:

• El tiempo que lleva 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 lenguaje resuelve un problema que difícilmente se puede resolver con otros idiomas?
• ¿Se admitirá este idioma en 5 años? ¿El cliente debe hacer otra solicitud?

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

El cuarto punto es el que se aplica solo a los idiomas de código cerrado, como los que dependen de terceros, que pueden existir o no dentro de 5 años. 5 años antes a partir de ahora, las aplicaciones móviles no eran tan importantes como hoy, ¿el lenguaje de entonces se adaptará a la situación actual y me permitirá escribir aplicaciones móviles también? ¿Será incluso compatible con los nuevos requisitos? Si existe tal requisito para mi cliente, ¿puedo contactar al 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, sospecharía mucho de ello y preferiría no usar el lenguaje, a menos que reciba promesas muy sólidas. y el lenguaje ofrece algo que ningún otro me permite hacer.