In einem praktischen Administrationsfall sollte in einem CRM-System die Umwandlung eines „Interessenten“ (Lead) in ein „Verkaufspotential“ (Opportunity) so angepasst werden, dass drei zusätzliche Datenfelder automatisch übernommen werden. Funktional handelt es sich um eine triviale Anforderung: Drei Felder existieren sowohl im Ausgangs- als auch im Zielobjekt, und ihre Werte sollen beim Konvertierungsvorgang übertragen werden. Technisch erwies sich die Anpassung jedoch als überraschend aufwendig.

In der verwendeten Software – dem Open-Source-CRM  SuiteCRM – existiert keine Administrationsoberfläche, über die sich die Feldzuordnung der Lead-Umwandlung konfigurieren ließe. Stattdessen ist die Konfiguration in einer PHP-Metadatendatei hinterlegt (`convertdefs.php`). Die Realisierung der gewünschte Änderung war nicht intuitiv erkennbar, eine Dokumentation war dazu nicht auffindbar. Zwar konnte durch eine Anpassung der Datei die Änderung erreicht werden, doch zeigte sich sofort eine zweite Ebene von Komplexität:
Eine solche Änderung sollte aus Gründen der Update-Stabilität nicht im Kern der Software erfolgen, sondern als sogenannter „Custom Override“. Der Versuch, diese technisch korrekte Vorgehensweise umzusetzen, führte jedoch wiederholt zu Systemfehlern (HTTP-Fehler 500), die erst nach längerer Analyse von Dateirechten, Cache-Verzeichnissen und internen Reparaturmechanismen behoben werden konnten.

Der funktionale Kern der Aufgabe – das Übertragen dreier Datenfelder – war also nicht schwierig. Die eigentliche Arbeit bestand in der Identifikation des in der Logik der Software angelegten Verfahrens und in der Navigation durch eine mehrschichtige Konfigurationsstruktur, deren Verhalten für Administratoren kaum transparent ist.

Dieses kleine Beispiel illustriert eine strukturelle Beobachtung, die ich in meinem Aufsatz „Zur Überwindung einer suboptimalen Versorgung mit freier Open-Source-Software am Beispiel von CiviCRM“ entwickele. Dort argumentiere ich, dass freie Softwaresysteme nicht unbedingt unter einem Mangel an funktionalen Kernfeatures leiden, sondern unter einer Unterversorgung bei den transaktionskostensenkenden Komponenten: Dokumentation, Administrierbarkeit, UX, Installations- und Konfigurationslogik. Diese Elemente stellen aus ökonomischer Sicht ein Kollektivgut innerhalb der Softwaregemeinschaft dar und Unterliegen den Problemen der Kollektivgutbeschaffung nach Olson und den Governance-Herausforderungen nach Ostrom. Ihr Nutzen verteilt sich auf alle Nutzer, während der individuelle Anreiz zu ihrer Bereitstellung für einzelne Entwickler oder Organisationen relativ gering bleibt.

Das Ergebnis ist ein stabiles, aber suboptimales Gleichgewicht:
Die Software selbst funktioniert und ist frei verfügbar, doch ihre effektive Nutzung erfordert häufig spezialisiertes Wissen. Dadurch entsteht ein Markt für Implementierungs- und Integrationsdienstleistungen, der die strukturellen Defizite teilweise kompensiert, sie aber nicht notwendigerweise beseitigt.

Die hier beschriebene Episode zeigt diesen Mechanismus im Kleinen. Die gewünschte Funktionalität war bereits vorhanden; dennoch erforderte ihre Nutzung einen erheblichen administrativen Aufwand. Die eigentliche Herausforderung bestand nicht darin, neue Software zu entwickeln, sondern darin, vorhandene Software in einer Weise zu konfigurieren, die von der Systemarchitektur unterstützt wird, aber alles andere als offensichtlich ist.

Zugleich deutet der Fall auf eine mögliche Verschiebung dieses Gleichgewichts hin. Werkzeuge der KI-gestützten Analyse und Assistenz können einen Teil der bislang erforderlichen Spezialkenntnisse kompensieren und damit die Transaktionskosten für technisch versierte Nutzer deutlich senken. Ob dies langfristig zu einer strukturellen Verbesserung der Software selbst führt oder lediglich zu einer neuen Balance zwischen Nutzern, Dienstleistern und Werkzeugen, bleibt jedoch eine offene Frage.