Losfahren kannst du damit schon seit langem.
Wir reden hier ja um die "Getränkehalter" ;-)


Ich verstehe die Bedenken, hatte ich lange auch, nur wenn ich mir die "fertigen" Lösungen (kostenpflichtig) anschaue, sind diese weit hinten, bezogen auf den heutigen Stand der Technik. Diese sind alles andere als "fertig". Das hat mich zum Umdenken gebracht.


Das Beispiel der Source-Texte hat es deutlich gemacht, wie schnell und einfach es geht wünsche umzusetzen.
Wenn du neben den Source-Texten auch noch weitere Informationen haben willst (Kategorien, Labels, ...), wie lange würden die "fertigen" Lösungen benötigen, um solch ein Feature zu implementieren? ... falls überhaupt.
Ich habe hier eine Lösung zur Verfügung gestellt und das innerhalb von ein paar Minuten.
Und mit dieser Lösung hast du mehr Möglichkeiten als es die anderen bieten.


Markdown war nur ein Beispiel. Markdown ist halt passend, weil dies immer stärker in den Vordergrund kommt. (Z.B.: jede Doku in Github wird mit Markdown geschrieben)
Könnte aber auch mit JSON gemacht werden und es mit ein wenig HTML & Javascript darstellen lassen. Das ganze wird im IDE wie im Browser dargestellt.
Bei Bedarf kann ich da auch gerne unterstützen, kann aber auch jeder anderer der ein wenig sich mit HTML auskennt. Es gibt auch genug Beispielcode im Internet das man sofort via Copy/Paste verwenden könnte.


Du kannst dir gerne mein Projekt auf GitHub anschauen. Die Scripts habe ich alle mit Bash geschrieben.
Kann man aber auch mit Python, Node.js oder was auch immer machen wenn etwas zusätzlich benötigt wird.


Wenn du ein "fertiges" Produkt nimmst, und du brauchst eine Erweiterung, dann machst du das ja auch nicht selbst sondern du beauftragst den Hersteller (falls er das machen kann/will).
Genauso machst du es auch bei Open Source Projekten.
Der Unterschied ist nur, du bist nicht an den Hersteller gebunden. Jeder der sich in diesem Gebiet etwas auskennt kann das machen, schneller, einfacher, unkomplizierter, transparenter, kostengünstiger.


Die stärken der "fertigen" Produkten liegt wo anders.
Wenn du z.B. signierte Deployments benötigst, oder eine Zertifizierte Software brauchst, dann würde ich dir die kostenpflichtigen Lösungen empfehlen.


Was den RDi Betrifft:
Ich habe die RDi Phase hinter mich gelassen.
Jahrelang habe ich nur mit diesem gearbeitet (und würde es auch noch tun, wenn der SEU die einzige alternative wäre).
Ich habe auch einige Jahre im mit GIT im RDi und Sourcen in Source-Files gearbeitet.
Ist funktioniert alles grundsätzlich und ist besser als nichts.
Nur im täglichen leben hat mich einiges gestört, war nicht praktisch und teilweise eingeschränkt.
Der RDi selbst ist sowieso immer mehrere Generationen hinter dem "richtigen" Eclipse.
Deshalb bevorzuge ich den VSCode. Mein Build-Tool kannst du aber genauso auch mit RDi benützen.


Zu SRVPGM:
Mein Weg ist: 1 Modul = 1 SRVPGM
Ändere ich etwas im Modul werden automatisch alle abhängigen Sourcen mit kompiliert.
D.h. ändere füge ich eine Spalte hinzu, werden alle Module & PGMs neu erstellt, die darauf referenzieren. Und dann noch alle Module & PGMs die auf die zuvor neu erstellten Module zugreifen usw. usw.
Gerade bei DB Erweiterungen kann das einen Rattenschwanz an neu zu erstellenden Objekten mit sich führen.
Der Vorteil hier ist jedoch, dass der Entwickler weniger Fehlerquellen verursachen kann und ich durch die erneuten Kompiles diverse Prüfungen habe auf die ich nicht verzichten will.
So machen das übrigens auch die "fertige" Lösungen.