Bananenprinzip – Wikipedia

Bananenprinzip ist ein sarkastischer Ausdruck für die Idee, ein noch unreifes (sprich: mangelhaftes) Produkt könne beim Verbraucher reifen. Grundlage ist die Tatsache, dass Bananen unreif geerntet, grün ausgeliefert und erst nach einer Reifezeit beim Zwischenhändler oder gar beim Endverbraucher genießbar werden.

Positiver Effekt für einen Wirtschaftsbetrieb ist, dass interne Prüf- und Qualitätssicherungsmaßnahmen teilweise eingespart werden können. Die Fehler des Produktes werden durch die Kundenrückmeldungen und Beschwerden ermittelt.^[1] Der Vorgang wird von den Herstellern daher auch als „kundenseitige Anpassung“ bezeichnet. Letztlich finanziert der Kunde aber durch seinen Kauf die Fertigentwicklung des eingeschränkt nutzbaren Produktes mit.

Der Ausdruck wird vorrangig in Wirtschaftszweigen verwendet, die mit Software oder Kraftfahrzeugen^[2][3] zu tun haben. Eine Kerneigenschaft von Software liegt darin, dass ihre Veränderung nach der Auslieferung beim Kunden zu potentiell sehr geringen Kosten für den Anbieter möglich ist. Insbesondere können die Kosten dabei weitgehend unabhängig von der Anzahl der auszuliefernden Produkte sein, etwa, wenn Updates über das Internet erfolgen. Dies ist bei physischen Veränderungen, auch etwa Rückrufen von Autoherstellern, naturgemäß anders.

Als Folge davon sind schnelle und verhältnismäßig kostengünstigere Anpassungen in allen Warengruppen möglich, die wesentlich von einfach updatebarer Software gesteuert werden – etwa auch Hardwarekomponenten in Computern und andere technische Bauteile.

Die günstige Replizierbarkeit von Software steht im Gegensatz zu hohen Kosten bei der Softwareentwicklung, insbesondere auch zu einem hohen Kostenanteil der Bereiche Qualitätssicherung und Tests. Aufgrund dessen besteht ein hohes herstellerseitiges Interesse, die Kosten dieser Phase zu senken.

Von Bananenware, Bananen-Software oder Bananaware^[4] spricht man meist dann, wenn es auf Kundenseite zu einer diesbezüglichen Unzufriedenheit gekommen ist, das heißt, die Software oder ein Update des Programms oder der Internetseite vor der Weitergabe an den Käufer oder Nutzer nicht ausreichend getestet wurde. Dabei werden die Programme gleich zur Verfügung gestellt, ohne ausreichende Fehlersuche in Betatests – oder gar ohne jemals einen Alphatest durchgeführt zu haben. Die betreffenden Hersteller weisen oft darauf hin, dass es unmöglich sei, alle Endanwender-Konfigurationen auf dadurch möglicherweise auftretende Fehler zu testen. Die Behebung durch Aktualisierungen nach Problembeschreibungen sei daher nicht nur kostengünstiger, sondern auch die einzig realistische Möglichkeit.

Die Anwender können die bereits bezahlte Software oder Leistung oft nicht oder nur eingeschränkt nutzen. Sie müssen nach der Beschwerde beim Hersteller auf die Aktualisierung warten, dafür manchmal extra zahlen und bei einem verbesserten Programm Daten erneut einpflegen. Zudem müssen bei durch den Kunden erweiterbaren Produkten möglicherweise Eigenentwicklungen an die aktualisierte Version angepasst werden.

Bei Computerspielen tritt dieses Prinzip ebenfalls oft auf.^[5] Patches sind nötig, bis das Spiel zufriedenstellend läuft. Der Trend etabliert sich auch bei den Konsolenspielen, da Konsolen inzwischen mit dem Internet verbunden werden und so Patches nachgeliefert werden können. Zuvor erforderten kritische Softwarefehler die Einsendung und den Austausch des Spielmediums, das für den Hersteller entsprechend kostenaufwendig werden konnte.

Durch das Internet und die Entwicklung quelloffener Programme hat sich jedoch die Rolle des (End-)Anwenders gewandelt. Er erhält oft kein fertiges Produkt, sondern eine über das Netz abrufbare Dienstleistung. Entsprechende Anpassungen der Programme und regelmäßige Aktualisierungen (Updates) sind dabei oft inbegriffen. Bei einigen Programmentwicklern haben sich dafür die Begriffe Continuous Beta^[6] oder Perpetual Beta (beides englisch/lateinisch/griechisch frei übersetzt etwa für dauerhafte Vorab-Version oder umgangssprachlich ständige Bananenware) eingebürgert. Der Nutzer soll dabei als Mitentwickler (englisch Co-Developer) im Prozess der Weiterentwicklung eines Programmes angesehen werden.^[7]

• Bananenprinzip – Glossareintrag beim Projekt Magazin

1. ↑ Martin Sonnenschein, Harald Zapp, Axel Freyberg: Customer Energy: Wie Unternehmen lernen, die Macht des Kunden für sich zu nutzen. Gabler, 2006, ISBN 978-3-409-14264-9, S. 120.
2. ↑ Henning Wallentowitz, Arndt Freialdenhoven, Ingo Olschewski: Strategien in der Automobilindustrie: Technologietrends und Marktentwicklungen. Vieweg & Teubner, 2008, ISBN 978-3-8348-0725-0, S. 9.
3. ↑ Rückrufaktionen-Rekord: Autoentwicklung nach dem Bananenprinzip. Spiegel Online Auto, 15. Dezember 2003 (abgerufen am 29. April 2011).
4. ↑ Thomas Hirschbiegl: Temporäre Leichenstarre. In: Berliner Zeitung, 31. März 1999.
5. ↑ Thomas Hirschbiegl: Das Bananenprinzip. In: Berliner Zeitung, 20. Juni 2001.
6. ↑ Frank Mühlenbeck, Klemens Skibick: Verkaufsweg Social Commerce – Blogs, Podcasts, Communities & Co. Wie man mit Web 2.0 Marketing Geld verdient. 2007, ISBN 3-8334-9686-X, S. 20.
7. ↑ Tim O’Reilly: What is Web 2.0? Kapitel 4/2: End of the Software Release Cycle.