Richtige Preisfindung für „Waren“ und Dienstleistungen in Second Life

Viele Leute tun sich schwer, wenn es darum geht, für ihre Waren und Dienstleistungen in Second Life den richtigen Preis zu finden. Dies ist keine ganz einfache Materie und es gibt dabei einen gewaltigen Unterschied zwischen Waren, wie beispielsweise Schuhen, und Dienstleistungen als solche.

Der Unterschied dabei ist: eine Ware kann ich, einmal erstellt, ohne weitere Arbeitszeit und Produktionskosten (z.B. Bilderuploads) beliebig oft verkaufen. Einmal gebaut, ist die Ware beliebig kopierbar und verursacht keine Produktionskosten mehr, aber je nachdem, wie man es mit seinen Kunden hält, Supportkosten.

Dienstleistungen dagegen, wie beispielsweise Skripte schreiben, sind immer projektbezogen und die Einnahmen daher normal an das Projekt gebunden. Daher sind die Preise für Dienstleistungen ungleich höher als für Waren, da sich bei den Waren die Gestehungskosten über die verkaufte Menge einspielen – man muss einfach nur genug davon verkaufen und schon hat man seine Kosten und irgendwann noch einen Profit. Bei Dienstleistungen dagegen kriegt man dies vor allem über seine Bezahlung.

Und dann ist die ganz einfache Frage diese: Second Life ist für fast alle ja ein Hobby – wieviel Gewinn will man in Wirklichkeit machen oder gar keinen? Richtig Geld machen in Second Life nur wenige, für viele ist und bleibt es eben ein schönes Hobby,  mehr nicht.

Wenn ich Gewinn machen will und davon leben, dann muss ich den Markt genau beobachten und recherchieren, was an Preisen im jeweiligen Metier so üblich ist – und dann noch jemanden natürlich finden, der auch gewillt ist, meinen Preis zu bezahlen. Denn merke: in vielen Bereichen in Second Life gibt es ein Überangebot an Dienstleistern, was zu einem gehörigen Preiswettbewerb führt und man kann nur die Preise nehmen, die der Markt zu zahlen bereit ist.

Angenommen als, ich möchte pro Stunde Skripten oder fortgeschrittene Bildbearbeitung als Einnahme den gesetzlichen Mindestlohn von 8,50€ einnehmen – dann führt muss ich ca. 2.200 L$ pro Stunde berechnen. Je nachdem, welche Permissions mein Kunde bei den Skripten haben will, berechnet man dann noch ein wenig mehr.

Wenn der Kunde Stundenpreisen eher abgeneigt sein sollte, dann liegt die Kunst darin, eine möglichst gute Pauschale zu berechnen, in der die vermutete Arbeitszeit enthalten ist.

Es gibt beispielsweise Fotografen in Second Life, die für ein in Adobe Photoshop bearbeitetes Bild durchaus 2.000 L$ und mehr verlangen. Wenn man sich dann überlegt, dass sie daran wohl eine Stunde arbeiten, klingt der Preis für SL-Verhältnisse schon sehr hoch, aber wenn man als Maßstab die Stundensätze realer Grafiker nimmt, dann bewegen wir uns da locker im Bereich von 30-60€ und mehr.

Das bedeutet nichts anderes, als dass man je nach Umfang der Bildbearbeitung dieselbe Arbeit für 1/10 des Preises bekommt, den ein Grafiker einer Bildagentur nehmen würde. Wobei das natürlich nichts über die Qualität aussagt, die kann man aber vorher in Erfahrung bringen und manche sind darin ja richtig gut.

Damit will ich sagen: manche Preise sind gemessen an Second Life schon viel Geld – gemessen daran, was die Dienstleistung aber im wirklichen Leben kostet, eine Kleinigkeit, für die in der freien Wirtschaft niemand ernsthaft anfängt, auch nur die Maus zu schubsen.

Viele Kunden in Second Life aber denken darüber absolut nicht nach und meinen, dass man bereitwillig für 100 L$, was ca. 39 Cent entspricht, beliebigen Terror ertragen muss, dass es nur kracht – und diese Kunden wundern sich dann nur gehörig, wenn die Dienstleister in Second Life darüber entnervt reagieren. Es hat eben alles seinen Preis, nur manchmal stimmen die Relationen einfach nicht.

Der Weg der Software oder: auf den Schultern von Riesen stehen

Die moderne Entwicklung von Software hat es so an sich, dass die Programmierer oft das Rad nicht mehr neu erfinden müssen, sondern sich bereits existierender Programmbibliotheken für alle möglichen Bereiche, wie beispielsweise Verschlüsselung, dem Abspielen von MP3s, Videos u.v.m. bedienen können. Der Entwickler nutzt die Schnittstellen der entsprechenden Bibliothek und baut sie in sein Produkt ein, fertig. Natürlich muss er damit auch ab und an sein Projekt der Bibliothek anpassen, wenn sich diese ändern sollte.

konqueror-web-browser

Das hier, werte Leser, ist Konqueror. Der Mehrzahl von euch wird Konqueror nichts sagen, es handelt sich dabei um den alten Dateimanager des Desktop Environments KDE unter *nix. Konqueror war schon immer fähig, als Webbrowser zu fungieren und hatte dazu eine eigene, kleine Websiterenderingengine namens KHTML eingebaut plus eine Javascriptengine namens KJS. KHTML war recht flott, leichtgewichtig und einfach in eigene Programme einzubauen.

KHTML kennt heute kaum noch einer, es wird auch nicht mehr weiter entwickelt. Als Apple im Jahre 2003 seinen eigenen Webbrowser namens Safari vorstellte, ging ein Raunen durch die Webszene. Denn in dieser Email meldete sich ein gewisser Don Melton bei den KDE-Entwicklern und verkündete der erstaunten Welt in der Mailingliste, dass Apples neuer Webbrowser auf einem Fork von KHTML mit KJS basieren würde. Dieser Fork, also eine auf Grundlage von KHTML unabhängige Weiterentwicklung trug damals den Namen WebCore, das Gesamtprojekt hörte auf den Namen Webkit.

Die KDE-Leute waren verzückt und gleichzeitig die Macher bei Mozilla verärgert, dass Apple nicht deren ebenfalls quelloffene Engine Gecko benutzt hatte. Gecko war den Entwicklern bei Apple zu groß, zu schwer einzubauen und zu langsam, aber KHTML genau richtig. Dafür konnte Gecko aber auch deutlich mehr Webseiten korrekt anzeigen, als dies bei KHTML der Fall war.

Webkit wuchs und gedieh und findet sich heute auf jedem Smartphone und Rechner als Engine, es ist die Basis für Safari und war die Basis für Google Chrome. An der Entwicklung von Webkit sind unter der Federführung Apples viele, bekannte Firmen beteiligt. Google verabschiedete sich allerdings 2013 von Webkit und gründete seinen eigenen Fork namens Blink. Der Grund dürfte einfach sein, dass man sich so aus der technischen Abhängigkeit von Apple befreien wollte. Ebenso verwendet bis heute der Second Life Viewer Webkit als Viewerkomponente.

Mozilla arbeitet übrigens selber schon seit längerem an einer vollkommen neuen Renderingengine namens Servo, die in einer dafür eigens geschaffenen Programmiersprache namens Rust implementiert wird. Man darf gespannt sein, was dabei am Ende herauskommen wird.