Un langage de programmation open source peut-il survivre? [fermé]

Un ami a écrit un langage de programmation. Il a une syntaxe qui rappelle SGML. Il a écrit un interprète pour cela, et un IDE. Lui et ses collègues l'utilisent en interne comme langage côté serveur. Il peut également être utilisé pour écrire des outils de ligne de commande.

Il veut le mettre à la disposition du public, dans l'espoir que les gens achèteront une licence pour l'utiliser. Il veut garder le code exprimant l'implémentation du langage pour lui-même, car il y a un peu de propriété intellectuelle attachée.

Je continue de lui dire que le jour des langages de programmation à code source fermé est révolu. Je dis: "Regardez toutes les langues principales: la grande majorité sont open-source. Vous devrez aussi opter pour l'open-source si vous voulez que quelqu'un en dehors de l'entreprise prête attention à ce que vous avez construit."

Suis-je en train de lui donner de bons conseils ou y a-t-il encore de la place pour les langages propriétaires pour lesquels vous payez?

PLUS TARD

Den a demandé: "... pourriez-vous également expliquer comment une langue peut être fermée?"

J'ai dit: "@Den, vous faites valoir un bon point. Ce que mon ami veut éviter, je suppose, est la situation où Microsoft prépare un langage semblable à Java, l'appelle J ++, puis entre en litige avec Sun au sujet de son Java-ness . Comment protégez-vous une syntaxe et une méthodologie de programmation contre le piratage par une entreprise dont la mise en œuvre pourrait vous mettre hors service? "

La réponse est oui et non. Cela dépend des motivations commerciales des clients potentiels et des attributs de la langue et des problèmes qu'elle résout.

Non, le monde n'a pas besoin d'un autre langage informatique à usage général créé par un individu ou une petite équipe. Lorsque Perl, Python, Ruby, Java et Javascript ont été créés, il y avait un vide à combler, les langages propriétaires coûtaient cher et la barrière à l'entrée était faible. Rebol est celui qui a commencé payé et est maintenant gratuit. Regardez C # et allez voir à quel point c'est plus difficile maintenant et à quel point les équipes sont plus grandes, même pour les langages plus ou moins libres.

Mais oui, le monde a grandement besoin de langues de niche pour remplir toute une gamme de rôles spécifiques et en paiera bien le prix. Je ne peux pas vous citer d'exemples car ni vous ni moi n'avons jamais entendu parler de la plupart d'entre eux, mais ils sont couramment utilisés dans des situations hautement spécialisées et ils rapportent de l'argent à leurs créateurs. Résolvez un problème et vous serez payé.

Donc, pour que votre ami gagne de l'argent, il a besoin d'une ou plusieurs des trois choses.

1. Un créneau technique identifiable pour lequel sa langue est la meilleure solution disponible, de préférence avec une barrière à l'entrée raisonnablement élevée pour ralentir les concurrents.
2. Un segment de clientèle identifiable avec un problème que sa langue peut résoudre ainsi que la capacité de payer pour le résoudre.
3. Un corps de code pré-écrit, de documentation, de tutoriels et de compétences qui permettra aux clients de le mettre en œuvre immédiatement et de commencer à résoudre les problèmes immédiatement.

Les problèmes mentionnés dans le recours aux petites entreprises ne sont pas propres aux langages de programmation et sont facilement résolus par des moyens commerciaux.

Divulgation: Je suis l'auteur d'un système de langage de programmation commercial (Powerflex) qui a aidé beaucoup de gens à créer des entreprises de logiciels. Cette fenêtre s'est fermée lorsque la fenêtre Internet s'est ouverte.

Une langue n'est pas open-source ou fermée en tant que telle. Par exemple, G ++ est open source tandis que MSVC ++ est open source. ISO C ++ n'est ni l'un ni l'autre, c'est une norme non libre non propriétaire.

Votre ami pourrait publier une implémentation Open-Source non optimisante et vendre le compilateur optimisateur de fantaisie. L'intéressante propriété intellectuelle ne sera pas nécessaire pour une mise en œuvre simple.

Un langage existant qui fonctionne avec ce modèle est PHP / Zend Server

Sa langue fait-elle quelque chose que suffisamment de gens paieront?

C'est vraiment la seule chose qui décide si un modèle d'entreprise fonctionnera. Avez-vous un grand marché d'utilisateurs suffisamment grand pour ne pas vous soucier des coûts de licence? La langue prend-elle en charge des appareils ou des normes dont les clients ne peuvent pas se passer et que rien d'autre ne prend en charge? Est-il si incroyablement génial que les clients puissent embaucher les plus grands et les plus brillants programmeurs et réaliser d'énormes augmentations de productivité simplement en utilisant ce langage, et la direction comprend-elle ce compromis ?

Si l'un de ces éléments ou quelque chose de comparable est le cas, le modèle d'entreprise fonctionnera probablement. Sinon, ce ne sera probablement pas le cas: tôt ou tard, quelqu'un va proposer une mesure de réduction des coûts qui implique de passer à une alternative moins chère.

Je crois que non, il n'y a pas de place pour un nouveau langage avec une implémentation propriétaire vendue par une petite entreprise.

Premièrement, les développeurs ont de nombreuses autres implémentations de langage libres (au moins aussi "dans la bière", et souvent "dans la parole"), et ils ne prendront pas la peine d'essayer un langage (cher).

Deuxièmement, tout gestionnaire s'opposerait immédiatement: qu'arriverait-il à notre base de code codé dans la nouvelle langue- si la petite entreprise fournissant la mise en œuvre de la langue faisait faillite? Cet argument interdirait probablement à quiconque d'acheter l'implémentation du langage!

^{En revanche, une implémentation de langage logiciel libre peut être grossièrement évaluée par les clients, qui pourraient toujours gérer leur service à un autre fournisseur, si l'entreprise d'origine qui l'a écrite fait faillite.}

Du point de vue du client, le coût de l'adoption d'une nouvelle langue n'est pas dans la licence de l'implémentation, mais dans les compétences requises pour l'utiliser.

Et il existe de nombreuses implémentations de langage logiciel libre qui sont presque inutilisées.

Une langue ne peut pas être fermée. Son compilateur et ses bibliothèques d'exécution peuvent être à source fermée. Une grammaire formelle d'une langue peut cependant être gardée secrète et être légalement protégée (NDA, etc.) et les frais perçus pour l'utilisation.

Votre ami pourrait revendiquer la propriété intellectuelle ou un brevet si la langue est si nouvelle et si nouvelle. Je doute moi-même que cela en vaille la peine.

De nos jours, la plupart des entreprises choisissent d'abord les technologies accessibles au public, quel que soit le travail laborieux que cela représente pour obtenir le même effet qu'une approche de source fermée ferait. Ensuite, si les frais généraux sont super importants, ils vont vers une solution standard de l'industrie - des langages propriétaires standardisés (par exemple Matlab), avec une bonne pénétration et un bon support.

Les langues internes sont généralement construites en tant que DSL (langues spécifiques au domaine), et ces jours-ci, l'effort est plus petit que d'acheter une DSL de quelqu'un d'autre et de l'adapter. De plus, les DSL sont très spécifiques au domaine problématique.

Maintenant, ne décourageons pas votre ami de monétiser sa langue. Il existe des moyens de le faire - le vendre à une grande entreprise établie ou faire en sorte que certains investisseurs achètent l'idée et y investissent -, mais son principal problème d'approche est qu'il a développé une solution sans rechercher le problème de développement. Et ce n'est pas le problème qu'il considère comme le problème, c'est ce que ses clients potentiels considèrent comme le problème. Donc, il pourrait sortir et parler avec ces gars sans donner de détails sur sa solution et faire payer ces gars - ce n'est pas impossible mais pas très probable cependant.

J'ai moi-même eu cette discussion lorsqu'un de mes clients a envisagé de développer des applications majeures à l'aide de ColdFusion. Personnellement, je ne vois aucune raison d'utiliser CF (et de le payer) quand je peux utiliser PHP (et ne pas le payer). Cependant, CF a une grande entreprise derrière elle qui pacifie les OSS-phobiacs (faites affaire avec suffisamment de responsables informatiques et vous êtes obligé d'en rencontrer certains) et c'est assez bon pour que suffisamment de développeurs le préfèrent.

Cependant, le problème est, bien sûr, que votre ami doit trouver quelque chose d'assez bon et suffisamment de soutien derrière. Le premier n'est pas une mince affaire ces jours-ci avec toutes les plates-formes open source parfaitement matures, et le dernier nécessite le soutien d'une partie au moins de la taille, par exemple, d'Adobe.

Sans parler du fait que même CF a une part de marché marginale de nos jours par rapport à OSS.

En résumé, si votre ami est assez brillant pour proposer quelque chose qui surpasse PHP, Python et les amis et les entreprises assez avertis pour le vendre à l'un des acteurs les plus importants et les plus réputés du marché, la réponse est "peut-être". Sinon, c'est un "non" retentissant.

Je pense que la réponse est un non catégorique dans ce cas. Le fait d'avoir un nouveau langage piloté par une petite entité entraîne un risque élevé de bogues critiques ou de fonctionnalités clés manquantes.

Si cette langue est propriétaire, en tant qu'utilisateur, vous êtes absolument foutu si la langue n'évolue pas dans la direction où vous en avez besoin au rythme auquel vous en avez besoin. Si la langue est gratuite, vous pouvez jeter de l'argent ou de la main-d'œuvre sur le problème (ce qui, au moins pour les grandes entreprises, est une option).

Votre ami ferait bien mieux de vendre des services ou des produits complémentaires. Fournir support, formation, conseil. Soyez payé pour l'ajout de fonctionnalités spécifiquement demandées. Fournir des outils (par exemple sous la forme de plugins commerciaux pour les IDE populaires). Fournir certaines bibliothèques sous un modèle de licence commerciale (mais toujours avec la source incluse dans les restrictions appropriées).

Bien que je déteste décourager votre ami, je pense qu'il est peu probable qu'il parvienne à convaincre les gens de payer pour les outils de développement de nos jours à moins que cet outil n'apporte un gain de productivité incroyablement énorme (comme dans «produit un logiciel de travail en ayant les gestionnaires l'air croisé) à l'écran en pensant bien !!! "). Pour le meilleur ou pour le pire, il y a très peu de marché pour les outils de développement "pay-for-play" de nos jours car la quantité et la qualité des outils gratuits sont excellentes. (Langages témoins tels que Java, Ruby, Python, Clojure - IDE comme Eclipse et LightTable - bases de données telles que MySQL et PostgreSQL - la liste s'allonge encore et encore et encore et encore et encore ...). Je lui souhaite bonne chance dans cette entreprise.

Ça peut. Si c'est:

• bon et / ou assez utile
• s'il est applicable assez facilement et
• si ce n'est pas trop cher

En fait - pour commencer, il devrait être vraiment fort sur les 2 premiers articles et très réduit par rapport à sa valeur réelle.

Je vois la plupart des gens se plaindre de mauvais gestionnaires qui n'aimeront pas payer beaucoup d'argent pour cela - vous n'avez jamais dit que votre ami demandait une fortune pour la licence. Que se passe-t-il s'il demande 500 $ par an et que cela fait économiser quelques centaines d'heures de travail à l'entreprise chaque année? Tout gestionnaire intelligent le saisirait.

Cela dépend si la langue offre quelque chose d'assez ingénieux pour que je (représentant le client) soit prêt à payer pour cela.

En tant que chef de projet, je dois prendre en considération:

• Le temps qu'il faut pour apprendre / maîtriser cette nouvelle langue.
• Le gain d'efficacité (délai de livraison) par rapport aux autres langues. Et cela surpasse-t-il le temps de l'apprendre?
• Cette langue résout-elle un problème qui peut difficilement être résolu avec d'autres langues?
• Cette langue sera-t-elle toujours prise en charge dans 5 ans, si le client fait une autre demande?

Les 3 premiers points s'appliquent à toutes les langues et en particulier la première est difficile à surmonter pour chaque nouvelle langue, car je dois raisonner le temps de très faible productivité avec quelque chose, et il vaut mieux être bon.

Le 4ème point est celui qui ne s'applique qu'aux langues à code source fermé, comme avec celles dont je suis tributaire de tiers, qui pourraient ou non exister dans 5 ans. 5 ans plus tôt, les applications mobiles n'étaient plus aussi importantes qu'aujourd'hui, la langue s'adaptera-t-elle à la situation actuelle et me permettra-t-elle également d'écrire des applications mobiles? Sera-t-il même compatible avec les nouvelles exigences? S'il existe une telle exigence pour mon client, puis-je contacter le développeur de cette langue et déposer une demande de mise à niveau?

Si vous répondez «non» à l'une de ces questions, cela peut être la meilleure langue du monde, je ne peux pas l'utiliser. Et si j'entends qu'il y a une seule personne qui a inventé cette langue dans son "temps libre" et qui travaille maintenant comme une entreprise individuelle, je serais très méfiant à ce sujet et je n'utiliserais pas la langue, sauf si je reçois des promesses très solides et la langue offre quelque chose qu'aucune autre ne me permet de faire.