Was bei uns offen ist, und was nicht

Am 20. August haben wir Compiler und Kommandozeilen-Werkzeug aus unserem privaten Repository nach github.com/cordango geschoben. Drei Tage später ließ es sich mit einer einzigen Zeile installieren. Danach hat jemand auf die Daten der GitHub-Organisation geschaut und daraus geschlossen, wir hätten in derselben Woche mit Cordango angefangen. Nach sieben Wochen mit wenig Schlaf liest sich das komisch.

Deshalb hier die unspektakuläre Fassung. Was wirklich darin liegt, was Sie damit machen können, was nicht, und wo wir die Grenze gezogen haben zwischen dem offenen Teil und dem, den wir verkaufen.

Kurz gesagt

cordango/cordango steht unter Apache-2.0. Darin liegen das Format, mit dem wir eine Anwendung beschreiben, die Prüfung, ob so eine Beschreibung gültig ist, und der Generator, der daraus eine echte Anwendung macht, die Ihnen gehört.

Cordango als Produkt ist die gehostete Plattform, auf der Unternehmen arbeiten. Die liegt nicht im Repository und wird auch nicht dort landen.

Beide Hälften lesen dieselbe Datei.

Was Sie damit tatsächlich tun können

Installieren Sie die CLI, schreiben Sie eine App-Definition und führen Sie zwei Befehle aus:

cordango check    ist diese Beschreibung gültig
cordango build    daraus eine laufende Anwendung machen

Was bei build herauskommt, ist ein ganz normales Repository. Hinten ASP.NET Core und EF Core, vorne Vue und Vuetify, dazu ein Dockerfile, eine Compose-Datei und Migrationen, die man lesen kann. Entitäten, eine REST-API, Rollen und feldgenaue Rechte, die auf dem Server durchgesetzt werden, Anmeldung, ein Einrichtungsbildschirm beim ersten Start und ein Demo-Datenbestand, damit beim ersten Öffnen nicht alles leer ist.

Von uns hängt davon nichts ab. Kein Lizenzserver, kein Konto, kein Nachhausetelefonieren. Löschen Sie danach die ganze Werkzeugkette, und es baut trotzdem.

Dazu gibt es cordango import, das eine Anwendung aus einer Cordango-Instanz holt und wieder zu Dateien macht, sowie cordango login und cordango publish für den umgekehrten Weg.

Anfangen würde ich mit cordango check, weil es auf einem Laptop ohne Konto und ohne Netz läuft. Das war Absicht, und darauf komme ich gleich zurück.

Was Sie damit nicht tun können

Cordango selbst können Sie daraus nicht betreiben. Bei Open Core denken viele an eine selbst betreibbare Fassung des Produkts, aus der die teuren Teile entfernt wurden. Das ist es nicht. Es liest dieselbe Datei wie die Plattform, und darin besteht die ganze Verbindung zwischen beiden.

Der Generator hat heute ein funktionierendes Ziel, dotnet-vue. Node, Python und React stehen im Readme, weil die Richtung dorthin geht, und nicht, weil Sie sie schon benutzen könnten. Der Schalter nimmt sie noch nicht an. PostgreSQL ist die einzige Datenbank.

Und das Ganze ist Pre-Alpha. Es funktioniert von vorne bis hinten, und stabil ist daran nichts.

Wo die Grenze verläuft

Unser erster Reflex war, entlang der Funktionen zu schneiden. Das offenlegen, was leicht wegzugeben ist, und das behalten, was am längsten gedauert hat. Das ist der naheliegende Weg, und ich halte ihn inzwischen für den falschen. Am Ende steht dabei etwas, mit dem niemand etwas zu Ende bringen kann, ohne zu zahlen. Das ist eine Demo mit einer Lizenzdatei darauf.

Also haben wir entlang der Aufgabe geschnitten.

Eine Anwendung zu schreiben und zu prüfen, ob sie stimmt, ist eine Aufgabe. Die ist offen, vollständig, und sie läuft offline ohne Konto. Denn eine Prüfung, die nur gegen fremde Server läuft, ist keine Prüfung. Das ist ein API-Aufruf.

Viele Unternehmen auf einem System zu betreiben, ist eine andere Aufgabe. Das ist die Plattform, und die bleibt bei uns. Das gemeinsame Unternehmensfundament, aus dem jede App im Arbeitsbereich liest, der Assistent, der mit Ihnen eine App baut, die Firmenrecherche, die Mechanik, die ein großes Zahlenmodell richtig hält, während mehrere Leute daran arbeiten. Nichts davon liegt im Repository.

Das gleich beim ersten Mal richtig zu treffen, war wichtiger als sonst, weil sich Apache-2.0 nicht zurücknehmen lässt. Was einmal draußen ist, bleibt draußen. Die Diskussion musste vor dem Knopfdruck stattfinden und nicht danach.

Was ich an Ihrer Stelle wissen wollte

Der Generator verweigert den Build, statt stillschweigend weniger zu liefern, als Ihre Definition verlangt. Kann er etwas nicht, hört er auf und nennt Ihnen den Code und die genaue Stelle in Ihrer Datei, an der es hängt.

Sie können das mit einem Schalter übergehen. Dann schreibt er jede Lücke ins erzeugte Readme und in einen Bauvermerk, der beim Projekt bleibt. So kann ein unvollständiger Build später nicht mehr als vollständiger durchgehen, und genau das war die Sorge.

Das gefällt mir besser, als ich erwartet hätte. (Nebenbei lässt sich unsere Roadmap an den Diagnosecodes ablesen, was beim Einbauen nicht der Plan war.)

Schauen Sie es sich an

github.com/cordango ist die Organisation. docs.cordango.com ist die Dokumentation, und sie ging an dem Tag online, an dem sich das Werkzeug installieren ließ. Ein Werkzeug, dessen Handbuch noch nicht geschrieben ist, ist nämlich nicht wirklich installierbar. Der Quickstart führt von null zu einer laufenden Anwendung, und Concepts erklärt die App-Definition, falls Sie das Format verstehen wollen, bevor Sie etwas installieren.

Wenn Sie etwas erzeugen und der Build verweigert sich, schicken Sie mir den Diagnosecode. An dieser Liste entscheiden wir, was als Nächstes drankommt, und das meiste darauf sind heute Dinge, zu denen wir noch nicht gekommen sind, und nicht Dinge, die wir nicht können.