Open-Source Lösungen modifizieren

Open-Source Lösungen modifizieren

Marc Ruef
von Marc Ruef
Lesezeit: 3 Minuten

Bei der Initiierung eines Software-Projekts stehen viele unserer Kunden vor der Frage, ob sie sich auf quelloffene Projekte oder auf kommerzielle Lösungen abstützen sollen. Gerade im Webbereich stehen eine Vielzahl unterschiedlicher Content Management Systeme mit verschiedenen Lizenzmodellen zur Verfügung.

Im Zuge des bestehenden Kostendrucks entscheidet sich so mancher Kunde dafür, auf eine freie Lösung zu setzen. Technische Mitarbeiter sehen darin oftmals weniger den kommerziellen Faktor als Killerkriterium, sondern die Möglichkeit, aufgrund der Offenheit der Lösung eigene Anpassungen einbringen zu können. Dadurch verspricht man sich ein hohes Mass an Flexibilität.

Selbstverständlich wird diesen Aspekten gut und gerne ein hohes Gewicht beigemessen. Dennoch vergisst man gerne in der treibenden Euphorie, dass Anpassungen an quelloffenen Projekten umfangreiche Abhängigkeiten mit sich tragen. Diese können und werden sich mittel- und langfristig ebenfalls negativ auf die Sicherheit einer Lösung auswirken.

Software-Development am Beispiel einer Webapplikation

Wird eine individuelle Anpassung an einem Produkt vorgenommen, erschliessen sich zwar neue Funktionalitäten. Gleichzeitig entfernt man sich aber vom offiziellen Release. Dies bedeutet, dass man vielleicht den Support des Produkts verliert. Zudem bedeutet dies aber ebenfalls, dass sich Patches unter Umständen nicht mehr ohne weiteres einspielen lassen. Ebenso grundlegende Produkt-Upgrades, die voraussichtlich alle eigenen Änderungen überschreiben würden.

Will man eigene Anpassungen an einer Lösung vornehmen, muss man die grundlegende Qualität einer allgemeinen Software-Entwicklung berücksichtigen. Damit lassen sich kleinere Anpassungen nicht mehr mal nebenher realisieren. Man braucht Entwicklungs- und Test-Systeme. Man braucht einen Prozess, um die Änderungen in die produktive Umgebung übertragen zu lassen. Man braucht eine Abnahme und einen Dokumentationsprozess. etc.

Je länger man ein Produkt betreut und sich durch die individuellen Anpassungen vom offiziellen Release entfernt, desto schwieriger wird es, sich am ursprünglichen Produkt zu orientieren. Sehr schnell hat man eigentlich eine eigene und mehr oder weniger eigenständige Lösung.

Jene Vorteile, die quelloffenen Produkten anhaften, gehen damit zwangsweise verloren. Denn so müsste man die eigenen Änderungen ebenfalls publik machen (ins ursprüngliche Projekt zurückfliessen lassen), um zum Beispiel von der Community profitieren zu können. Doch nur die wenigsten Unternehmen können diesem ideologischen Ansatz einen Vorteil abgewinnen. Zu gross wird die eigene Leistung eingeschätzt, die man dann nicht ohne finanzielle Entlöhnung teilen möchte.

Aus diesem Gründen ist so manches Unternehmen in monetärer Hinsicht mittel- und langfristig besser beraten, wenn es sich auf rein kommerzielle Lösungen verlässt. Im produktiven Betrieb wird Support und Stabilität gerne über Flexibilität, Transparenz und Ideologie gesetzt. Das ist sehr schade, denn werden quelloffene Lösungen richtig betrieben, können damit die Vorteile aller Herangehensweisen vereint werden.

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Hochschulen, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

×
Cyber Threat Intelligence

Cyber Threat Intelligence

Marc Ruef

3D Printing

3D Printing

Marc Ruef

Contact Tracing App DP3T

Contact Tracing App DP3T

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv