Kann eine geschlossene Programmiersprache überleben? [geschlossen]

Ein Freund hat eine Programmiersprache geschrieben. Die Syntax erinnert an SGML. Er hat einen Dolmetscher dafür und eine IDE geschrieben. Er und seine Kollegen verwenden es intern als serverseitige Sprache. Es kann auch zum Schreiben von Befehlszeilentools verwendet werden.

Er möchte es der Öffentlichkeit zugänglich machen, in der Erwartung, dass Menschen eine Lizenz erwerben, um es zu nutzen. Er möchte den Code, der die Sprachimplementierung zum Ausdruck bringt, für sich behalten, da einiges an geistigem Eigentum darin enthalten ist.

Ich sage ihm immer wieder, dass der Tag der Closed-Source-Programmiersprachen vorbei ist. Ich sage: "Sehen Sie sich alle wichtigen Sprachen an: Die überwiegende Mehrheit sind Open-Source-Sprachen. Sie müssen auch Open-Source-Sprachen verwenden, wenn Sie möchten, dass jemand außerhalb des Unternehmens dem, was Sie erstellt haben, Aufmerksamkeit schenkt."

Gebe ich ihm gute Ratschläge oder gibt es noch Platz für proprietäre Sprachen, für die Sie bezahlen?

SPÄTER

Den fragte: "... könntest du bitte auch erklären, wie eine Sprache als geschlossene Quelle betrachtet werden kann?"

Ich sagte: "@Den Sie machen einen guten Punkt. Was mein Freund vermeiden möchte, ist die Situation, in der Microsoft eine Java-ähnliche Sprache erfunden hat, sie als J ++ bezeichnet und dann mit Sun über ihre Java-Fähigkeit in einen Rechtsstreit gerät Wie schützen Sie eine Syntax und eine Programmiermethode davor, von einem Unternehmen entführt zu werden, dessen Implementierung Sie aus dem Geschäft bringen könnte? "

Die Antwort lautet ja und nein. Es hängt von den kommerziellen Motivationen der potenziellen Kunden und den Attributen der Sprache und den von ihr gelösten Problemen ab.

Nein, die Welt braucht keine andere Allzweck-Computersprache, die von einer Einzelperson oder einem kleinen Team erstellt wurde. Als Perl, Python, Ruby, Java und Javascript erstellt wurden, gab es ein Vakuum zu füllen, proprietäre Sprachen waren teuer und die Eintrittsbarriere war niedrig. Rebol wurde ursprünglich bezahlt und ist jetzt kostenlos. Schauen Sie sich C # an und sehen Sie, wie viel schwieriger es jetzt ist und wie viel größer die Teams sind, selbst für Sprachen, die mehr oder weniger kostenlos sind.

Aber ja, die Welt braucht dringend Nischensprachen, um eine ganze Reihe spezifischer Rollen zu besetzen, und sie werden gut dafür bezahlt. Ich kann Ihnen keine Beispiele nennen, da weder Sie noch ich jemals von den meisten gehört haben, aber sie werden routinemäßig in hochspezialisierten Situationen eingesetzt und verdienen Geld für ihre Schöpfer. Lösen Sie ein Problem und Sie werden bezahlt.

Damit Ihr Freund Geld verdienen kann, benötigt er eines oder mehrere der drei Dinge.

1. Eine identifizierbare technische Nische, für die seine Sprache die beste verfügbare Lösung ist, vorzugsweise mit einer angemessen hohen Eintrittsbarriere, um die Konkurrenz zu bremsen.
2. Ein identifizierbares Kundensegment mit einem Problem, das seine Sprache lösen kann, sowie die Zahlungsfähigkeit, um es zu lösen.
3. Eine Sammlung von vorab geschriebenem Code, Dokumentationen, Tutorials und Fertigkeiten, mit denen Kunden ihn sofort in Betrieb nehmen und Probleme sofort lösen können.

Probleme, die bei der Verwendung kleiner Unternehmen auftreten, sind nicht nur auf Programmiersprachen beschränkt und lassen sich mit kommerziellen Mitteln leicht lösen.

Offenlegung: Ich bin der Autor eines kommerziellen Programmiersprachensystems (Powerflex), das vielen Menschen beim Aufbau von Softwaregeschäften geholfen hat. Dieses Fenster wurde geschlossen, als das Internetfenster geöffnet wurde.

Eine Sprache ist keine Open-Source- oder Closed-Source-Sprache. Beispielsweise ist G ++ Open Source, während MSVC ++ Closed Source ist. ISO C ++ ist weder noch, es ist ein nicht freier, nicht proprietärer Standard.

Ihr Freund könnte eine nicht optimierende Open-Source-Implementierung veröffentlichen und den ausgefallenen Optimierungs-Compiler verkaufen. Das interessante geistige Eigentum wird für eine einfache Implementierung nicht benötigt.

Eine existierende Sprache, die mit diesem Modell funktioniert, ist PHP / Zend Server

Tut seine Sprache etwas, wofür genug Leute bezahlen werden?

Das ist wirklich das Einzige, was darüber entscheidet, ob ein Geschäftsmodell funktioniert. Haben Sie einen großen Markt von Benutzern, die groß genug sind, um sich keine Gedanken über Lizenzkosten zu machen? Unterstützt die Sprache Geräte oder Standards, ohne die die Kunden nicht leben können, und die sonst nichts unterstützt? Ist es so wahnsinnig toll, dass die Kunden die besten und intelligentesten Programmierer einstellen und mit dieser Sprache enorme Produktivitätssteigerungen erzielen können, und versteht das Management diesen Kompromiss ?

Wenn einer dieser Punkte oder etwas Vergleichbares zutrifft, wird das Geschäftsmodell wahrscheinlich funktionieren. Andernfalls wird dies wahrscheinlich nicht der Fall sein: Früher oder später wird jemand eine Kostensenkungsmaßnahme entwickeln, bei der auf eine billigere Alternative umgestellt wird.

Ich glaube, nein, es gibt keinen Platz für eine neue Sprache mit einer proprietären Implementierung, die von einer kleinen Firma vertrieben wird.

Erstens haben Entwickler viele andere kostenlose (zumindest als "in beer" und häufig als "in speech") Sprachimplementierungen, und sie werden sich nicht die Mühe machen, eine (teure) Sprache auszuprobieren.

Zweitens würde jeder Manager sofort Einwände erheben: Was würde mit unserer in der neuen Sprache codierten Codebasis passieren, wenn das kleine Unternehmen, das die Sprachimplementierung bereitstellt, bankrott geht? Dieses Argument würde wahrscheinlich jedermann verbieten, die Sprachimplementierung zu kaufen!

^{Im Gegensatz dazu kann eine Implementierung einer freien Softwaresprache von Kunden grob bewertet werden, die ihren Dienst immer an einen anderen Anbieter abwickeln könnten, wenn das ursprüngliche Unternehmen, das sie geschrieben hat, in Konkurs geht.}

Aus Sicht des Kunden hängen die Kosten für die Einführung einer neuen Sprache nicht von der Lizenz der Implementierung ab, sondern von den Fähigkeiten, die für deren Verwendung erforderlich sind.

Und es gibt viele freie Software-Sprachimplementierungen, die fast unbenutzt sind.

Eine Sprache kann nicht als geschlossene Quelle betrachtet werden. Die Compiler- und Laufzeitbibliotheken können als Closed Source ausgeführt werden. Eine formale Grammatik einer Sprache kann jedoch geheim gehalten und rechtlich geschützt werden (NDAs usw.) und Gebühren für die Verwendung erhoben werden.

Ihr Freund könnte geistiges Eigentum oder Patent beanspruchen, wenn die Sprache so neu und neu ist. Ich selbst habe große Zweifel, dass dies die Mühe wert wäre.

Heutzutage entscheiden sich die meisten Unternehmen zuerst für öffentlich verfügbare Technologien, egal wie mühsam es ist, denselben Effekt zu erzielen, den ein Closed-Source-Ansatz erzielen würde. Wenn der Overhead sehr groß ist, wird eine branchenübliche Lösung verwendet - standardisierte proprietäre Sprachen (z. B. Matlab) mit guter Durchdringung und Unterstützung.

Inhouse-Sprachen werden in der Regel als DSLs (domänenspezifische Sprachen) erstellt, und heutzutage ist der Aufwand geringer als der Kauf eines DSL von jemand anderem und dessen Anpassung. Auch DSLs sind sehr spezifisch für die Problemdomäne.

Lassen Sie uns Ihren Freund nicht davon abhalten, seine Sprache zu monetarisieren. Es gibt Möglichkeiten, dies zu tun - es an ein großes, etabliertes Unternehmen zu verkaufen oder einige Investoren dazu zu bringen, die Idee zu kaufen und darin zu investieren -, aber sein Hauptproblem bei der Herangehensweise besteht darin, dass er eine Lösung entwickelt, ohne das Entwicklungsproblem zu untersuchen. Und das ist nicht das Problem, was er für das Problem hält, sondern was seine potenziellen Kunden für das Problem halten. Also konnte er mit diesen Leuten reden, ohne Details über seine Lösung preiszugeben und sie zum Bezahlen zu bewegen - das ist nicht unmöglich, aber nicht sehr wahrscheinlich.

Ich habe diese Diskussion selbst geführt, als einer meiner Kunden erwog, wichtige Anwendungen mit ColdFusion zu entwickeln. Persönlich kann ich mir keinen Grund vorstellen, CF zu benutzen (und dafür zu bezahlen), wenn ich PHP benutzen kann (und nicht dafür zu bezahlen). Hinter CF steckt jedoch ein großes Unternehmen, das die OSS-Phobiker befriedet (mit genügend IT-Managern zu tun zu haben und auf einige davon irgendwann zu stoßen).

Der Haken dabei ist natürlich, dass sich Ihr Freund etwas Gutes einfallen lassen muss und genügend Rückendeckung hat. Ersteres ist heutzutage bei all den ausgereiften Open-Source-Plattformen kein einfacher Trick, und letzteres erfordert die Unterstützung einer Partei, die mindestens so groß ist wie beispielsweise Adobe.

Ganz zu schweigen von der Tatsache, dass selbst CF heutzutage im Vergleich zu OSS einen marginalen Marktanteil hat.

Wenn Ihr Freund brillant genug ist, um etwas zu erfinden, das PHP, Python und Freunde in den Schatten stellt, und das geschäftstüchtig genug ist, um es an einen der größeren und seriöseren Anbieter auf dem Markt zu verkaufen, lautet die Antwort "vielleicht". Ansonsten ist es ein klares "Nein".

Ich denke, die Antwort ist in diesem Fall ein klares Nein. Wenn eine neue Sprache von einer kleinen Einheit gesteuert wird , besteht ein hohes Risiko, dass kritische Fehler oder wichtige Funktionen fehlen.

Wenn diese Sprache proprietär ist, dann sind Sie als Benutzer absolut verrückt, wenn sich die Sprache nicht in die Richtung entwickelt, in die Sie sie benötigen, in dem Tempo, das Sie es benötigen. Wenn die Sprache frei ist, können Sie Geld oder Arbeitskraft in das Problem stecken (was zumindest für größere Unternehmen eine Option ist).

Ihr Freund ist besser dran, wenn er ergänzende Dienstleistungen oder Produkte verkauft. Unterstützen, schulen, beraten. Sie werden dafür bezahlt, dass Sie speziell angeforderte Funktionen hinzufügen. Bereitstellung von Tools (z. B. in Form von kommerziellen Plugins für gängige IDEs). Stellen Sie einige Bibliotheken unter einem kommerziellen Lizenzmodell bereit (wobei die Quelle jedoch unter geeigneten Einschränkungen enthalten ist).

Obwohl ich es hasse, Ihren Freund zu entmutigen, denke ich, dass es heutzutage unwahrscheinlich ist, dass er es schafft, die Leute davon zu überzeugen, für Entwicklungstools zu bezahlen, es sei denn, dieses Tool bietet einen unglaublich großen Produktivitätsgewinn (wie in "Produziert funktionierende Software, indem Manager die Augen verschränken" am bildschirm beim nachdenken gute gedanken !!! "). Gut oder schlecht, es gibt heutzutage sehr wenig Markt für "Pay-for-Play" -Entwicklungswerkzeuge, da die Quantität und Qualität der kostenlosen Werkzeuge ausgezeichnet ist. (Zeugen von Sprachen wie Java, Ruby, Python, Clojure - IDEs wie Eclipse und LightTable - Datenbanken wie MySQL und PostgreSQL - die Liste geht weiter und weiter und weiter und weiter ...). Ich wünsche ihm viel Glück bei diesem Unterfangen.

Es kann. Wenn es ist:

• gut und / oder nützlich genug
• wenn es leicht anwendbar ist und
• wenn es nicht zu teuer ist

Eigentlich - für den Anfang sollte es auf 2 erste Elemente wirklich stark und sehr im Vergleich zu seinem tatsächlichen Wert reduziert sein.

Ich sehe die meisten Leute, die sich über böse Manager beschweren, die nicht gerne viel Geld dafür bezahlen - Sie haben nie gesagt, Ihr Freund bittet um ein Vermögen für die Lizenz. Was ist, wenn er jährlich 500 US-Dollar verlangt und dadurch ein paar Hundert Arbeitsstunden pro Jahr eingespart werden? Jeder kluge Manager würde es ergreifen.

Das hängt davon ab, ob die Sprache etwas bietet, das genial genug ist, dass ich (als Vertreter des Kunden) bereit bin, dafür Geld zu zahlen.

Als Projektmanager muss ich berücksichtigen:

• Die Zeit, die benötigt wird, um diese neue Sprache zu lernen / zu beherrschen.
• Der Effizienzgewinn (Zeit bis zur Auslieferung) im Vergleich zu anderen Sprachen. Und überfordert es die Zeit, es zu lernen?
• Löst diese Sprache ein Problem, das mit anderen Sprachen kaum zu lösen ist?
• Wird diese Sprache in 5 Jahren noch unterstützt, sollte der Kunde eine andere Anfrage stellen?

Die ersten drei Punkte gelten für jede Sprache, und besonders die erste ist für jede neue Sprache schwer zu überwinden, da ich die Zeit mit sehr geringer Produktivität mit etwas begründen muss, und das ist besser so.

Der vierte Punkt ist derjenige, der nur für Closed-Source-Sprachen gilt, da ich von Dritten abhängig bin, die in 5 Jahren möglicherweise existieren oder nicht. Vor 5 Jahren waren mobile Apps noch keine so große Sache wie heute. Wird sich die Sprache dann an die aktuelle Situation anpassen und es mir ermöglichen, auch mobile Apps zu schreiben? Wird es überhaupt mit den neuen Anforderungen kompatibel sein? Kann ich mich an den Entwickler dieser Sprache wenden und einen Upgrade-Antrag stellen, wenn dies für meinen Kunden erforderlich ist?

Wenn eine dieser Fragen mit "nein" beantwortet wird, kann es die beste Sprache der Welt sein, ich kann es nicht verwenden. Und wenn ich höre, dass es eine einzelne Person gibt, die diese Sprache in ihrer "Freizeit" erfunden hat und jetzt als Ein-Mann-Firma arbeitet, wäre ich sehr misstrauisch und würde die Sprache lieber nicht verwenden, es sei denn, ich bekomme sehr solide Versprechungen und die Sprache bietet etwas, was mir kein anderer erlaubt.