Aktuell befindet sich der Leitfaden in Erstellung und wurde noch keinem Review unterzogen. Es können daher fehlerhafte, lückenhafte oder unvollständige Informationen enthalten sein.

Open Source

  1. Open Source
    1. Einleitung
    2. Was ist Open Source?
    3. Motivation und Chancen
      1. …in der Optimierung der eigenen Entwicklungsprozesse
      2. …in der Umsetzung von betriebswirtschaftlichen Anforderungen
      3. …in der Außendarstellung
      4. …im Upskilling von Entwicklern
    4. Ausbaustufen
    5. Lizenzen

Einleitung

Open Source hat es in der ABAP-Entwicklung besonders schwer Fuß zu fassen. Immer noch halten sich Einwände, dass der Einsatz von frei verfügbarer Software in den geschäftskritischen SAP-Systemen mit den Unternehmensdaten gar nicht möglich oder zu rechtfertigen sei. Dabei gibt es für viele der berechtigten Einwände Lösungen, um die Risiken zu minimieren und die Chancen, die Open-Source-Software bietet, nutzen zu können. In anderen Programmierumfeldern überwiegen die Chancen bereits lange gegenüber den Restrisiken und es wurden Prozesse und Tools geschaffen, um Open-Source-Bestandteile effektiv in den eigenen Entwicklungsprozess zu integrieren. Dieses Kapitel soll Ihnen einen Überblick zum aktuellen Stand von Open Source in der ABAP-Entwicklung geben sowie Prozesse und Tools vorstellen, um…

  1. …Open-Source-Projekte in die eigenen Lösungen zu integrieren (Einsatz von Open Source)
  2. …an Open-Source-Projekten mitzuwirken (Beteiligung an Open Source)
  3. …eigene Lösungen als Open-Source-Projekt bereitzustellen (Entwicklung von Open Source).

Eine Open-Source-Strategie muss jedes Unternehmen für sich selbst erschließen. Hier finden Sie eine Arbeitsgrundlage und Erfahrungsberichte.

Was ist Open Source?

Open Source Software (OSS) ist Software, welche unter einer Open-Source-Lizenz bereitgestellt wird. In allen drei zuvor genannten Anwendungsfällen ist die Lizenz maßgeblich für die Nutzung, die Modifikation und die Weiterverbreitung des bereitgestellten Codings. Zudem muss dieses frei verfügbar sein, also nicht nur einer bestimmten Gruppe an Personen bereitgestellt werden. Dies ermöglicht es Ihnen zum Beispiel den Quellcode einer Anwendung vor dem Einsatz zu prüfen und die Binärdateien zur Ausführung selbst zu erzeugen, anstatt darauf zu vertrauen, dass die bereitgestellten Dateien auch zu dem Quellcode gehören. Bugs können Sie im Zweifel selbst beheben, statt auf den Softwareanbieter warten zu müssen oder auf Support angewiesen zu sein. Zusatzfunktionalität und Integrationen können Sie selbst entwickeln und auch anderen Nutzern der Software bereitstellen. Versprochene Features wie Ende-zu-Ende-Verschlüsselung und deaktivierte Telemetrie können Sie selbst überprüfen.

SAP S/4HANA ist nicht “Open Source” nur weil Sie als Entwickler den von der SAP geschriebenen Quellcode lesen können. Open Source ist viel mehr als die bloße Bereitstellung des Codings gegenüber dem Kunden und thematisiert die freie Nutzung, Modifikation und Weiterverbreitung ohne in einem Kundenverhältnis mit dem Softwareanbieter zu stehen.

Motivation und Chancen

Warum sollten Sie sich mit Open Source in der ABAP-Entwicklung beschäftigen? Langsam aber stetig steigt die Anzahl an Szenarien, in denen Ihnen Open Source, und auch Open-Source-ABAP, im Alltag begegnet, statt, dass Sie danach selbst aktiv suchen müssen. Die Anzahl an in der Open Source Community verfügbaren ABAP-Projekten wächst - auf dotabap.org werden zum Zeitpunkt der Erstellung dieses Kapitels 299 Projekte gelistet. Die SAP selbst veröffentlicht Software als Open-Source-Projekte, wie zum Beispiel Code Pal for ABAP oder auch den RAP Generator und diverse Tutorials oder Lerninhalte, wie zum Beispiel RAP100 oder Fiori Elements Feature Showcase for RAP. Sich dem kategorisch zu verschließen führt zunehmend mehr zu verpassten Chancen…

…in der Optimierung der eigenen Entwicklungsprozesse

  1. Mit Tools wie ABAP Cleaner, Code Pal for ABAP und abapOpenChecks können Sie Entwickler entlasten bei der Umsetzung von Entwicklungsrichtlinien und Best Practices, in dem diese teilweise automatisiert umgesetzt und in anderen Teilen statisch geprüft und Entwickler aktiv auf Findings hingewiesen werden. Und das weit über den Umfang der im SAP-Standard ausgelieferten Möglichkeiten hinaus (ABAP Formatter / Pretty Printer, ABAP Test Cockpit). Mit zJoule können Sie unabhängig vom Joule-Rollout der SAP bereits KI-Unterstützung in der ABAP-Entwicklung einsetzen.
  2. Mit abapGit bietet sich Ihnen die Möglichkeit Ihre Entwicklungsprozesse Technologie-übergreifend mit einheitlichem Tooling zu harmonisieren und Ihre gesamte Unternehmenscodebase in einer Single Source of Truth zu verwalten, statt ABAP als Special Snowflake mit Sonderregeln zu betrachten. Sie können Code Reviews mit dafür ausgelegtem Tooling durchführen. Sie können angefangene Änderungen automatisiert zurücknehmen, wenn sie der Fachbereich nach Entwicklungszeit doch nicht mehr haben möchte ohne große manuelle Rückbauaufwände. Und das alles sogar bei Systemen ab SAP Basis 7.02.
  3. Mit Hilfe von abaplint können Sie außerhalb eines SAP-Systems ABAP Coding prüfen, entwickeln und mit dem Transpiler sogar ausführen. Sie können so Continuous Integration Pipelines aufsetzen ohne dafür spezielle SAP-Systeme kostenintensiv aufsetzen zu müssen und statische Codeanalyse und Unit Tests ausführen (mit Einschränkungen im Vergleich zu “nativer” Ausführung in ABAP-Systemen).
  4. Über Generatoren wie den RAP Generator oder ABAP OpenAPI Generator können Sie Boilerplate-Coding generieren und müssen dieses anschließend nur anpassen. So lassen sich Entwicklungsaufwände sparen und insbesondere auch schnell Prototypen aufsetzen.

…in der Umsetzung von betriebswirtschaftlichen Anforderungen

  1. Mit abap2xlsx können Sie die kreativen Anforderungen der Fachbereiche zur Erstellung, zum Auslesen und zur Änderung von Excel-Dateien umsetzen. Und das schon ab SAP Basis 7.31. Sie müssen so nicht Ihre Prozesse anpassen, weil die OLE-basierte SAP API für Excel-Mappen keine Hintergrundjobs unterstützt und ein installiertes Microsoft Office beim Anwender erwartet. Sie müssen insbesondere auch nicht den Entwicklungsaufwand investieren selbst eine Codebase zu implementieren und zu warten, die sich mit der Konvertierung und den Umgang mit Excel-Dateien befasst. Und Sie müssen auch nicht in Anbetracht des Implementierungsaufwands die Anforderung als nicht verhältnismäßig umsetzbar abweisen sondern können auf der Arbeit aufsetzen, die andere sich bereits gemacht haben.
  2. Ähnlich verhält es sich bei anderen technischen Problemstellungen, zu denen es bereits etablierte Open-Source-Lösungen gibt. Beispielsweise ABAP Logger anstelle eigener Wrapper-Klassen um die Funktionsbausteine des Business Application Log. Oder ajson als JSON-Bibliothek für ab SAP Basis 7.02.

…in der Außendarstellung

  1. Sie können bewerten, ob wiederverwendbare Komponenten Ihrer ABAP-basierten Lösungen nicht auch als Open-Source-Projekt Sinn machen würden. Coding, welches nicht in Konkurrenz Ihr Geschäftsmodell umsetzt, sondern die Optimierung des Entwicklungsprozesses oder übergreifenden Themen wie der User Experience, Revisionssicherheit oder ähnlichem dient, könnte auch von anderen Unternehmen genutzt werden. Wenn Sie diese Komponenten als frei verfügbare Software publizieren, ermöglichen Sie externe Beteiligungen an der Entwicklung von denen Sie profitieren können.
    Zusätzlich kann dies als Aushängeschild im Recruiting neuer Entwickler dienen. Diese sehen direkt, dass Sie modern entwickeln und sich nicht scheuen den Quellcode nach außen zu zeigen.
    Beispiele: IBM, Microsoft, rku.it, Schwarz IT
  2. Wenn Ihr Unternehmen Dienstleistungen zur Verfügung stellt, die über Schnittstellen mit Partnern/Kunden umgesetzt werden, welche diese auch in Ihren SAP-Systemen mittels ABAP implementieren, können Sie eine Open Source SDK bereitstellen, welche Ihre API implementiert. Die Nutzer der SDK haben direkt eine Möglichkeit Issues zu öffnen oder ergänzende Features selbst per Pull Request vorzuschlagen und Ihren Implementierungsaufwand erheblich zu verringern oder mehr Funktionalität in Ihrer Software anzubieten. Sie können intern die SDK selbst einsetzen oder für Integrationstests verwenden.
    Beispiele: ABAP SDK für Azure, ABAP SDK für Google Cloud, AWS SDK für SAP ABAP, Microsoft AI SDK für ABAP, ABAP SDK for IBM watsonx

…im Upskilling von Entwicklern

  1. Durch die Auseinandersetzung mit externen Bibliotheken und deren Implementierung können Sie Ihre Kenntnisse erweitern mit Blick auf objektorientiertes Design und Softwarearchitektur. Sie können mit neuen Technologien oder Ansätzen vertraut werden und das direkt mit produktivem Quellcode, statt Demobeispielen. Dieser Effekt verstärkt sich insbesondere bei der Beteiligung durch eigene Features oder Bugfixes und Code Reviews.

Sie sehen es gibt viele Stellen an denen Open Source, auch in der ABAP-Entwicklung, einen erheblichen Mehrwert liefern kann. Eine Auseinandersetzung mit dem Thema lohnt sich daher in jedem Fall, selbst wenn nur einige der oben genannten Punkte in Ihrem Fall relevant sind.

Ausbaustufen

Eine mögliche Herangehensweise an das Thema ist die verschiedenen Anwendungsfälle als aufeinander aufbauend zu sehen:

  1. Sie können sich zunächst mit dem Thema befassen, wie Sie Open Source Tools in Ihren Entwicklungsprozess integrieren und damit unmittelbar einen Mehrwert erzielen. Dabei geht es zunächst noch nicht um Open-Source-Softwarebestandteile, die sich in Ihrem Coding befinden, sondern lediglich um Tools, die in Ihrem Entwicklungsprozess und damit auch nur in Ihrer Entwicklungssystemlandschaft einziehen würden. Dies ist oft der am einfachsten zu betrachtende Fall und ein guter Einstiegspunkt in das Thema.
    Diese Ausbaustufe ist in Einsatz von Open Source beschrieben.
    1. Diese Stufe lässt sich optional erweitern mit der Nutzung von Open-Source-Bibliotheken in Ihren entwickelten Softwarelösungen. In diesem Fall erreichen die Open-Source-Bestandteile auch Ihr Produktivsystem oder werden mit als Bestandteil Ihrer Software ausgeliefert.

  2. Als nächstes können Sie die Beteiligung an Open-Source-Projekten ins Auge fassen. Dabei erweitern oder verändern Sie eine Open-Source-Bibliothek und stellen diese Anpassungen der Community wieder zur Verfügung, sodass auch andere Unternehmen davon profitieren können. Damit Entwickler so sich beteiligen können, muss in Ihrem Unternehmen eine Richtlinie vorhanden sein, wie dies konkret ausgestaltet werden kann.
    Diese Stufe wird in Beteiligung an Open Source behandelt.

  3. Die letzte Stufe ist die Entwicklung eigener Software als Open-Source-Software. In diesem Fall bieten Sie selbst ausgewählte Komponenten Ihrer eigenen Softwarelösungen als Open-Source-Software an und ermöglichen es so, dass andere sie einsetzen, aber auch sich daran beteiligen können.
    Diese Stufe wird in Entwicklung von Open Source thematisiert.

Die einzelnen Stufen bieten unterschiedliche Chancen, aber kommen auch mit unterschiedlichen Risiken und Aufwänden. Diese werden in den genannten Unterkapiteln aufgegriffen.

Lizenzen

Die Lizenz einer Software ist ausschlaggebend dafür, wie Sie sie einsetzen können. Konkret in Bezug auf Open Source macht eine Open-Source-Lizenz eine Software zur Open Source Software. Open-Source-Lizenzen gewähren ausdrücklich Rechte gegebenüber dem Lizenznehmer, geben ihm aber auf Pflichten auf, wie der mit der Software umzugehen hat. Wenn Sie ein Softwareprojekt finden, welches seinen Quellcode öffentlich zugänglich publiziert hat, aber keine Lizenz zu finden ist, dann handelt es sich nicht um Open Source, sondern lediglich um Source Available. Bei einer Einführung von Open Source sollten Sie sich in Ihrem Unternehmen schlau machen, ob beziehungsweise wer sich mit dem Lizenzthema beschäftigt. Gerade in größeren Unternehmen, die viele verschiedene Programmiersprachen einsetzen, kann es eine zentrale Instanz geben, die sich um Kompatibilität der Lizenzen beim Einsatz von Open-Source-Komponenten kümmert.

TODO Aspekte von Lizenzen

In nachfolgender Tabelle finden Sie populäre Open-Source-Lizenzen, die auch in der ABAP-Entwicklung verwendet werden (Quelle dotabap.org). Details finden Sie zum Beispiel unter choosealicense beziehungsweise choosealicense Appendix.

MIT Apache 2.0 GPL 3.0 GPL 2.0
Rechte
Kommerzielle Nutzung Erlaubt Erlaubt Erlaubt Erlaubt
Weiterverbreitung Erlaubt Erlaubt Erlaubt Erlaubt
Modifikation Erlaubt Erlaubt Erlaubt Erlaubt
Pflichten
Veröffentlichung von Quellcode zu Modifikationen Erforderlich Erforderlich
Angabe der Lizenz / Copyright im eigenen Produkt Erforderlich Erforderlich Erforderlich Erforderlich
Nutzung der selben Lizenz für Modifikationen Erforderlich Erforderlich
Limitierungen
Haftung Eingeschränkt Eingeschränkt Eingeschränkt Eingeschränkt
Garantie Eingeschränkt Eingeschränkt Eingeschränkt Eingeschränkt

TODO: Bereitstellung von Lizenzen in ABAP-Code…

Inhalte

← Qualitätssicherung und -Monitoring Rahmenbedingungen →