Alaskas neues Lizenzmodell für die PGDBE - ab dem 1.7.2023

[Tom]

Hier gibt es dazu Informationen:

https://www.alaska-software.com/product ... -qanda.cxp

Und hier die Übersicht der Lizenzgebühren:

https://www.alaska-software.com/product ... t-list.cxp

Habt Ihr Euch damit schon befasst?

[Manfred]

[Marcus Herz]

JA, die Preise sind nicht ganz ohne, vor allem, weil bisher ja nichts berechnet wurde, DBF kostet nichts, ADS nur Anschaffung,
Hatte in Göttingen schon für Gesprächsstoff gesorgt, da war noch die Definition, was als Client zu verstehen ist, nicht transparent.
Da wird wohl Überzeugungsarbeit mit den Kunden nötig sein.
Bei anderen Datenbanken ist es ja durchaus üblich, jährliche Lizenzgebühren. Aber den Vergleich haben wohl die wenigsten unserer Kunden.

PS: PQclass kommt ohne die PGDBE aus

[Tom]

Es sind ja im Vorfeld einige Gespräche mit Firmen geführt worden, von denen bekannt war, dass sie auf die Anwendung der PGDBE setzen würden, und auch ich habe vor ungefähr zwei Jahren, meine ich, ein längeres Gespräch mit Steffen über dieses Thema gehabt, weil es natürlich, äh, nicht so gut angekommen wäre, wenn man dieses Modell etabliert hätte, ohne das im Vorfeld zu kommunizieren und abzustimmen. Ich habe die Idee seinerzeit begrüßt, zumal die PGDBE ja weit mehr leistet als nur ein Datenbankmodell zu wrappen; und außerdem ist es in Ordnung, wenn man als Hersteller mit seiner originären Arbeit Geld verdienen will.

Ich wühle mich noch durch die Q&A, um zu verstehen, was das eigentlich für uns bedeuten wird, administrativ, aber auch, was unsere Softwarepflegeverträge anbetrifft. Vor allem aber beschäftigt mich das vertragsseitig. Wenn unsere Kunden Verträge mit Alaska abschließen müssen, wäre das problematisch, denke ich, aber dann gibt es ja noch das Coupon-Modell. Eine andere Frage ist die, was mit dem Lizenzmanagement passiert, wenn Alaska oder auch wir selbst als Firma nicht mehr zur Verfügung stehen sollten, aus welchen Gründen auch immer. Das ist ja nicht wie in der Karo-Einfach-Version der ADSDBE, wo man die ADS-Nutzung einfach abschalten kann und man arbeitet halt auf Dateiebene weiter.

[Marcus Herz]

Softwarepflegeverträge

Da wird wohl nichts drinstehen, dass ab 1.7 Runtime Lizenzgebühren anfallen.
Lass hören, wie du den Kunden neue Softwarepflegeverträge anbietest und wie die drauf reagieren.
In meinen Fällen müsste ich die bestehenden kündigen und neue anbieten

[Tom]

In meinen Fällen müsste ich die bestehenden kündigen und neue anbieten

Bei uns ist die PGDBE-Nutzung ohnehin als Lizenzerweiterung geplant, und gekündigt werden muss da nix - es gibt einfach Addenden zu den Pflegeverträgen, die dann halt im Rahmen der Lizenzerweiterung obligatorisch sind.

Aber es ist nicht ganz unproblematisch, das ganze. Aus zwei Vertragspartnern werden plötzlich drei, mehr oder weniger.

[Werner_Bayern]

Servus,

mich hats schon gewundert, warum hier nicht schon längst ein großer Aufschrei erfolgte. Aber, es arbeiten ja noch nicht viele mit der PGDBE.

Ich finde jetzt schon den jährlichen Kaufzwang, um an Updates und Fehlerbereinigungen (wozu wir bisher sehr viel selbst dazu beigetragen haben, gerade zur PGDBE, mind. 20 PDRs) zu kommen - gerade nach der letzten Preiserhöhung - heftig. Vergleicht das mal mit anderen Entwicklungssystemen!

Die meisten Entwickler hier sind ja Einzelkämpfer und haben sicherlich nicht 500+ Kunden, die monatlich viel Geld abdrücken. Wir verkaufen unsere Xbase++ - Anwendungen hier im ländlichen Bereich ausschließlich gegen Einmalzahlung. Da will keiner monatlich oder jährlich bezahlen. Die ersten 2 Jahre sind Fehler-Updates sowieso kostenlos, das schreibt das Gesetz schon vor! Ca. 30% unserer mittelständischen Anwender zahlen eine monatl. Pauschale von 29,--, dann bekommen sie alle Updates und Support (bis zu 45 Min. / Monat) kostenlos.

Jetzt im Nachhinein Lizenzgebühren zu verlangen geht gar nicht! Ich finde, dass in den Preisen der Xbase++ - Updates die PGDBE mehr als enthalten ist. Wir bekommen ja seit Jahren so gut wie keine Innovationen / längst übliche Standards mit den Updates:

• SFTP

• PDF

• Designer mit 2-Way-IDE

• Designer für die Tabellen mit grafischer Darstellung der Abhängigkeiten

• State-of-the-art - Tool zur manuellen Bearbeitung von Tabellen

• eine IDE (Workbench) mit funktionierender Syntaxhilfe, intelligenter Autovervollständigung, echter Mehrbenutzerfunktionalität (wer hat wann was geändert) etc.

• echte WEB-Anwendungen mit nativen Apps für iPhone und Android

• Controls wie Dashboard, Charts, Smart-Controls (Gauge, etc.), Multimedia (Kamera, Video etc.), HTML

• aktuelles, modernes UI

• Report-Generator

• Sozial Netzwerk Controls zu Facebook, Tweeter, Linkedln, Tumblr, Pinterest, Instagram, TikTok, WhatsApp

• Literatur für Einsteiger und Profis

• 64-bit

• Mehrsprachigkeit

• Versionsverwaltung

Ich hab jetzt alleine die letzten 10 Jahre eine 5stellige Summe (!) an Updates bezahlt. Die PGDBE war ein wesentlicher Faktor, dies zu tun. Jetzt, wo wir die meisten Anwendungen darauf umgestellt haben, ohne Vorankündigung zusätzliche Lizenzgebühren zu verlangen... Woran erinnert mich das nur?

Ich hör jetzt lieber auf...

[AUGE_OHR]

hi,

man kauft also ein Produkt wovon Teile "kostenpflichtig" werden mit einer "Jährlichen" Lizenz
der nächste Schritt wäre das man Xbase++ selbst "begrenzt" in der Laufzeit ...

es wäre mal Zeit das der Verein für seine Mitglieder was tut ...
ich glaube NICHT das die MEHRHEIT damit einverstanden ist was Alaska "verlangt"

[ramses]

Hallo zusammen

ich habe den ursprünglichen Beitrag selbst gelöscht.

[hel-systems]

Beitrag von AUGE_OHR » Do, 15. Jun 2023 1:21
> man kauft also ein Produkt wovon Teile "kostenpflichtig" werden mit einer "Jährlichen" Lizenz
> der nächste Schritt wäre das man Xbase++ selbst "begrenzt" in der Laufzeit ...

ich habe das so verstanden, dass es beim Kunden nicht abläuft, auch nach dem ersten bezahlten Jahr. Man kann dann nur keine neuere Version von xBase++ fürs erstellen verwenden.

Ich finde es trotzdem sehr seltsam (und habe mich sehr geärgert): seit Jahren von Postgre zu reden, Migrationspfade zu erstellen und plötzlich soll das ganze kosten. Da hätte man vorher drauf hinweisen sollen.

Meine Meinung: zu einem Programpaket wie xBase++ gehört in der heutigen Zeit eine vernünftige Datenbank dazu. Aber es fehlt ja an so vielen Ecken was ...

Zum Glück gibt es ja von Marcus PQclass, finde ich sowieso den besseren Ansatz.

Bis dann
Helmut

[ramses]

Hallo zusammen

ich habe den ursprünglichen Beitrag selbst gelöscht.

[Tom]

Nun, mal abseits des üblichen und nicht unerwarteten Genörgels (zum Gutteil von Leuten, die nicht betroffen sind, weil sie die Technologie nie einsetzen wollten und werden).

Ich denke, von der ersten Planung - die anderthalb Dekaden auf dem Buckel hat - bis heute hat sich das Investitionsvolumen für diese Technologie vermutlich vermehrfacht, und noch ist das Ding ja nicht so rund, dass man es guten Gewissens auf kritische Großkunden loslassen würde, allerdings fehlt nicht mehr viel (wobei ich bezweifeln würde, dass das innerhalb der nächsten sechs Wochen kommt, aber - wir werden sehen). Bei allem Verständnis für die Kritik daran, dass jetzt etwas sozusagen hinterrücks (ganz zutreffend ist das nicht, es wurden ja viele Gespräche im Vorfeld geführt) kostenpflichtig wird, für das man gemeint hat, via Subskription, die hin und wieder ihr Geld nicht wert war, die Entwicklung mitzufinanzieren und von dem man glaubte, es mindestens aufgrund dieser Subskription auch (und zwar royalty-free) nutzen zu dürfen, muss ich doch für eine realistische Einschätzung der Situation werben. Der Markt wird nicht größer, eher im Gegenteil, und wenn auch nicht in diesem Jahrzehnt, so dürfte doch im Jahrzehnt danach die Ziellinie allmählich in den Blick kommen. Was Alaska mit der PGDBE ermöglicht, das ist, das Legacy-Zeug noch ein paar Jahre über die Kante zu retten. Es gibt Alternativen, und zwar schon sehr, sehr lange - ich habe schon vor zwanzig Jahren mit SQL-Servern gequatscht und Daten ausgetauscht, und ich bin da sicher nicht der einzige, allerdings auf Schnittstellenebene. Für die Migration des Kerns war nie die Zeit, weil uns unsere Kunden und Mitbewerber vor sich hergetrieben haben und andere Dinge wichtiger waren. Ein paar Stellschrauben hier und da, gewiss, und vielleicht ein Tupfer Impersonation und noch ein Hauch Normalisierung, aber die liebgewonnene, dateibasierte ISAM-Geschichte blieb. Nicht allen Admins und IT-Abteilungen immer einfach zu erklären, davon abgesehen krass unsicher und ein beliebtes Primärziel für Ransomware.

Wenn die PGDBE jetzt so weit ist, dass sie im Echtbetrieb auch unter Last genutzt werden kann, dann bedeutet das auch für diejenigen unter uns, dass die Zeit der Migration gekommen sein könnte, denn diese Migration macht nicht sehr viel Arbeit, vermehrt aber den Wert der Anwendung. Diese unfassbare Arbeitseinsparung, die sie mit sich bringt, lässt sich Alaska jetzt bezahlen, weil sie diese Arbeit gemacht haben. Und weil ja nicht alle von uns das nutzen werden. Davon abgesehen muss niemand. Ich kann das aus wirtschaftlicher Perspektive nachvollziehen, aber, ja, moralische Kritik ist auch berechtigt.

Werner, Deine Aufzählung in allen Ehren, aber wir reden hier über Xbase++. Wir reden nicht über C# oder Angular. Wir reden über eine Handvoll Leute gegen mehrere tausend Leute. Klar, all das wäre schön zu haben, aber es wäre auch schön, Milliardär zu sein (habe ich mir jedenfalls sagen lassen). Aber um Milliardär werden zu wollen, sollte man vorher mindestens Multimillionär sein. So jemanden sehe ich hier nicht.

Allerdings. Ich habe das Lizenzmodell noch immer nicht ganz verstanden.

[ramses]

Hallo zusammen

ich habe den ursprünglichen Beitrag selbst gelöscht.

[georg]

Hallo,


dann schliesse ich mich schon mal an als einer, der die PGDBE nicht nutzt (und auch nicht nutzen will/wird), sondern schon sehr lange übe eine Klassen-Lösung von Hector Peroza auf MySQL zugreift. Ich bin in Rente, mache nebenher ein wenig Support, und habe keine Produkte bei Kunden laufen - ich sehe das entspannt. Daher habe ich bei der Ankündigung von Alaska auch nicht nachgehakt, fand es aber schon seltsam.

Die PGDBE dient dazu, den dBase-/Clipper-Sprachstandard zur Datenbehandlung am Leben zu erhalten. Wenn man sich davon löst, wird die ganze Sache entspannter.

Tja, ich lese gespannt weiter mit, was sich tut.

[Werner_Bayern]

Servus Tom,

keine Ahnung, warum Du hier für Alaska so wirbst und die Preiserhöhung gutheißt. Vermutlich warst Du aber einer derjenigen, die vorher konsultiert wurden?

In folgenden Punkten wage ich Dir zu widersprechen

• Die, die bisher geantwortet haben, arbeiten sehr wohl mit PG, aber nicht alle mit der PGDBE - aus gutem Grund.

• Hinterrücks: Keine Ahnung, welche Gespräche im Vorfeld geführt wurden, aber für uns alle hier trifft das offensichtlich nicht zu. Es gab bisher - zumindest für mich - keine Vorankündigungen. Dann sollen sich doch mal alle melden, die diesem Entscheidungsprozess zugestimmt haben.

• Sag doch mal, welche Neuerungen - und ich meine explizit keine BUG-Fixes - bei Dir die x-Tausend € / Jahr (Lizenz für jeden Entwickler pro Jahr) in den letzten 5 Jahren gerechtfertigt haben?

• Die PGDBE ist sowas von weit entfernt im Echtbetrieb unter Last akzeptable Ergebnisse zu liefern! Siehe meine Beiträge dazu hier.

• Es sind auch nach Jahren (u. a. von mir gemeldeter Fehler) immer noch PDRs (öffentlich und nicht öffentlich) offen, die ohne Code-Anpassung zu Datenfehlern führen!

• Meine Aufzählung: Xbase++ darf also nicht im 3. Jahrtausend nach Christi Geburt ankommen? Du findest es okay und akzeptierst es, dass längst überfällige Anpassungen an den Stand der Technik nicht umgesetzt werden, aber trotzdem Updates (was zum Großteil m. M. n. Fehlerbereinigungen sind) mindestens soviel kosten, als bei anderen Entwicklungsumgebungen, die den Stand der Technik haben? Machst Du nicht bei Ausschreibungen oder Förderprojekten mit?

Wir arbeiten u. a. mit einem Xbase++ - Entwickler zusammen, der intensiv den ADS einsetzt. Seit Jahren bekniee ich ihn, doch endlich auf PG umzustellen: Ist schneller, flexibler, moderner und kostenlos. What the fuck - was würde das jetzt für all seine Kunden bedeuten? Sie haben für den ADS bezahlt und jetzt müssten sie nochmal für den kostenlosen PG (quelloffen) bis in alle Ewigkeit pro Jahr bezahlen? Sag mir einen Programmiersprachen-Hersteller, der Geld für den PG - Connector verlangt!

Nichts für ungut.

[brandelh]

Ich werde die PGDBE nie nutzen, erinnere mich aber an die Einführung des Registrierungszwangs von Xbase++ selbst.

Nix als Ärger bei jeder Hardware Änderung und sagen wir es mal so ... wer will umgeht das einfach !
Somit Ärger für die, welche sich an die Verträge halten, aber keine zusätzlichen Einnahmen von denen, die sie umgehen.

Dass Alaska mehr Einnahmen erhofft, kann man verstehen, aber wie soll das ablaufen ?

Der Software Hersteller (also Ihr) muss dann beim Kunden prüfen wieviel Lizenzen er hat ?
Ihr müsst dann die Gebühren einsammeln und an Alaska weitergeben ?
Wer zahlt euch den Mehraufwand.

Oder der Kunde muss sich die von Alaska holen, wie Serverlizenzen von Microsoft ?
Ich kann mir gut vorstellen, dass im Verkaufsgespräch der dann sagt, aber XYZ braucht sowas nicht ....

Ich persönlich hätte immer den direkten Weg zum SQL Server genommen (entweder API oder ODBC) und
hielt die PGDBE für einen Fehler ... vor Ewigkeiten wurde ich für diese Aussage verbal glattgebügelt - war es in Berlin oder 2012 ... vor Ewigkeiten eben

Da ich wohl doch nicht mit 63 in Pension gehe, erlebe ich vielleicht ja noch die Xbase 3.0 - aber das ist eine andere Geschichte und für mich nicht mehr relevant.

[Tom]

Hallo, Werner.

Ich schrieb weiter oben etwas über die Konsultationen vorher.

Und ich stimme Dir ja vielem zu, aber ich sehe auch einfach die - vor allem wirtschaftlichen - Notwendigkeiten. Ich sage nicht, dass ich glücklich bin oder gar den Wunsch verspüre, Freudentänze aufzuführen, aber zumindest ich kann mit einem Modell gut leben, bei dem es - in der teuersten Variante - um ganze 2,50 € pro Connection im Monat geht. Wenn dadurch gewährleistet werden kann, dass die dazugehörige Dienstleistung längerfristig und in entsprechender Qualität (!) geliefert wird, kann ich, wie gesagt, damit leben. Aber ich kann auch die Verärgerung verstehen.

Aber. Drittes Jahrtausend hin oder her - wir kennen die Größenverhältnisse und wissen um sie. Und auch wenn so manches Jahr ohne direkt erkennbaren Gegenwert der Subskriptionsgebühren blieb, ist doch einiges passiert.

[Jan]

Man mag die PGDBE mögen oder nicht. Aber es ist halt eine Strategie, wie ich bei bestehendem Code auf SQL umsteigen kann. Praktisch eine Fortführung des Migrationsgedankens, wie von Clipper mit DOS-Oberfläche auf Xbase++ mit GUI-Oberfläche. Man nehme Bestandscode, setze vielleicht einen Schalter, compiliere neu, alles läuft weiter wie gewohnt. Und ich kann nach und nach alles umstellen, wenn ich will. Ansich doch eine tolle Sache.

Ich persönlich nutze die PGDBE nicht. Es gibt aber bei einem Kunden Gespräche, die dort vielleicht einzuführen.

Ich hatte vorher nur auf der Konferenz vom neuen Lizenzmodell gehört. Sonst nie. Für mich war das also in der Tat ziemlich überraschend.

Ich finde den Zeitrahmen von Ankündigung per Newsletter und Start arg kurz. Immerhin müssen alle, die die PGDBE nutzen, das intern klären wie das gehandhabt werden soll. Und das dann möglicherweise auch noch mit dem Kunden klären. Das alles in nicht einmal drei Wochen?

Und was ist mit den Kunden, die den Newsletter nicht bekommen? Oder nicht vollständig lesen (weil ist ja eh bloß Werbung, oder was für Argumente auch immer). Wie bekommen die Bescheid? Ich hätte bei einer Lizenzänderung eine offizielle Mail nur zu dem Thema von Alaska erwartet.

Es gab früher schon Zusatzprodukte, die man zusätzlich lizensieren musste. Z. B. die Tools. Und den ADS-Zugriff. Da war Alaska nett und hat das mit der 2.0 alles in ein Paket geschoben, wo wir keine zusätzlichen Kosten mehr haben dafür. Jetzt gibt es also mal wieder etwas, was zusätzlich kostet.

Wobei es natürlich unschön ist die PGDBE erst groß zu propagieren, und dann, nachdem man die umgesetzt und produktiv eingesetzt hat, nach mehreren Jahren mit der Zusatzlizenz um die Ecke zu kommen. Wenn wir das schon unschön finden was werden unsere Kunden dazu sagen?

Mir ist ebenfalls unklar, wie das funktioniert. Oben ist ja schon angesprochen worden: Was, wenn ich als Entwickler ausfalle? Was wenn das Programm noch läuft aber nicht weiter gewartet wird? Was wenn Alaska ausfallen sollte (was ich nicht hoffe und erwarte. Aber es sind schon andere Firmen nicht mehr da ...). Was passiert wenn die Lizenz abgelaufen ist? Steht dann der Laden still? Ohne jede Vorwarnung?

Und das mit den Coupons und Lizenzen habe ich nicht so ganz verstanden. Wenn ich das brauchen würde würde ich da garantiert Mails an Alaska schicken um das im Detail zu klären.

Und warum kann ich eine Lizenz nicht erhöhen? Alaska schreibt, das ginge nicht. Begründet das aber mit der jährlichen Laufzeit. OK, nachvollziehbar (aber nicht gut). Aber was ist mit der nächsten Erneuerung? Aktuell klingt das so als könne ich die Anzahl gar nicht ändern.

Und was ist mit denen, wo das doch im Laufe eines Jahres angepasst werden muß? Weil mein Kunde da neue Abteilungen mit neuen Clients eingerichtet hat? Weil mein Kunde expandiert? Soll ich dem sagen: Schön für Dich, aber die neuen Mitarbeiter werden leider nicht mit meiner Software arbeiten können? Wie gesagt, ich verstehe die Begründung von Alaska. Aber praxisnah ist das trotzdem nicht.

Insgesamt finde ich die Zusatzlizenz in Ordnung. Nur die Vorgehensweise und die Handhabung sind zumindest diskussionswürdig.

Jan

[Tom]

Hallo, Jan.

Die Lizenzierung ist ein Subkriptionsmodell. Du kannst nach dem Ablauf weiter damit arbeiten, aber Du bekommst keine Updates mehr. Das ist wie mit Xbase++ selbst. Wenn Du also ausfällst oder Alaska, kann der Kunde das trotzdem weiter nutzen, und zwar beliebig lange.

[brandelh]

das verstehe ich nicht, die Updates bekommst doch DU als Software Entwickler

Erscheint mir alles sehr nebulös, aber ich brauche es ja auch nicht

[Tom]

die Updates bekommst doch DU als Software Entwickler

Und Du lieferst sie dann aus. Wenn ein Kunde ein PGDBE-Update bekommt, aber keine aktive Lizenz mehr hat, kann er nicht (mit ihr) weiterarbeiten, nehme ich an. Ich gehe davon aus, dass im Moment des DBE-Loads irgendeine Validierung stattfinden wird.

[sammler0002]

Moin zusammen,

ich habe durch den Newsletter das erste mal von dem neuen Lizenzmodell erfahren.

Wir sind gerade auf lange Sicht am überlegen wo es bei uns hin geht. Aktuell ist es noch ein ADS Server - PostgreSQL war als Umstieg zumindest mit in der Überlegung.

Tom, vielleicht kannst Du ein paar Fragen, die sich mir aktuell stellen beantworten, Du scheinst ja etwas im Thema zu sein.

Ich hab es so verstanden, dass man eine die PGDBE als Subscr. kauft und selbest wenn man die Subscr. nicht verlängert, kann man ganz normal damit weiter arbeiten, bekommt aber natürlich keine Updates. So wie es letztlich auch mit der Subscr. für Xbase++ ist.

In den FAQ steht:

Kann ich eine Client-Lizenz oder einen Lizenz-Coupon kündigen?

Ja, natürlich, Sie können eine Client-Lizenz oder einen Lizenz-Coupon jederzeit kündigen.

Das bedeutet, dass Sie Ihre Anwendung weiterhin bei Ihrem Kunden einsetzen können. Aus lizenzrechtlicher Sicht ist es Ihnen jedoch nicht gestattet, die Installation auf eine neuere Xbase++ Version zu aktualisieren, die nach dem Ende-Datum Ihrer Client-Lizenz oder Ihres Lizenz-Coupons veröffentlicht wurde.

Heißt das, dass wenn ich keine PGDBE Subscr. habe, darf ich auch meine Xbase++ Programme nicht mehr mit einer aktuelleren Xbase++ Version entwickeln, sofern meine Xbase++ Subscr. länger läuft als meine PGDBE Subscr.?


Weiterhin steht in den FAQ:

Wie kann ich eine bereits gekündigte Client-Lizenz oder einen Lizenz-Coupon wiedereinsetzen?

Um eine gekündigte Client-Lizenz oder einen Lizenz-Coupon wieder zu aktivieren, ermitteln wir den seit der Kündigung verstrichenen Zeitraum. Dieser Zeitraum sowie die aktuellen Lizenzgebühren bilden die Grundlage für die Berechnung der Wiedereinsetzungsgebühr.

Heißt das, wenn ich bis zum 31.12.2023 eine gültigen Subscr. für PGDBE hatte und diese aber erst am 01.01.2025 wieder erneuern will, dass ich dann nicht die normale Gebühr für 1 Jahr (01.01.-31.12.2025) bezahlen muss, sondern die Gebühr vom 01.01.2024-31.02.2025?

Wenn ich eine Xbase++ Subscr. erneuere, nachdem sie ausgelaufen war, zahle ich doch auch nur für den neuen Zeitraum, nicht für den, in dem ich keine Subscr. hatte ...

Oder habe ich da jetzt etwas total durcheinander gebracht?

P.S. wir entwickeln nur für uns selbst, nicht für Kunden.

[Jan]

Philipp,

das alles gilt für Dich nur, wenn Du die PGDBE nutzen willst (also die sanfte Migration von dbf nach SQL mit Nutzung der Db...-Funktionen). Willst Du direkt mit SQL auf PostgreSQL zugreifen, betrifft Dich das nicht.

Jan

[steffen.pirsig]

Hallo Leute,

also eigentlich habe ich es mir abgewöhnt in Diskussionen unserer Kunden oder ehemaliger Kunden einzubrechen und Dinge zurecht zu rücken. Es ist nun mal so, dass Menschen unterschiedlich sind und demzufolge auch unterschiedliche Sichtweisen entwickeln. Das ist gut, leider gibt es zu wenige Menschen, die über Selbiges reflektieren und erkennen, dass Ihre persönliche Sichtweise oder Erfahrung nicht zwingend Allgemeingültigkeit hat und/oder zu einem hohen Maß den eigenen Rand/Rahmenbedingungen geschuldet ist.

Okay was für eine Einleitung, jetzt aber zum Punkt, und ich plaudere jetzt mal aus dem Nähkästchen.

1. Es gibt Kunden – gott-sei-dank nicht viele - bei Alaska Software, denen Xbase++ mittlerweile geschenkt wurde. Dies inkl. kostenlosen Updates für mehrere Jahre. Dies alles, weil sie unzufrieden mit Xbase++ waren und damit diese Kunden schmerzlos weg von Xbase++ kommen können dieser Deal. Einzige Anforderung, über die Vereinbarung Stillschweigen zu bewahren und unseren technischen Support/die Firma in Ruhe zu lassen.

2. Es gibt auch Kunden, die verwenden technische Merkmale unseres Produktes in Szenarien, die durch unseren Support mehrmalig zum Scheitern verurteilt wurden. Obwohl wir explizit darauf hinwiesen, wie es anders gehen könnte, wird uns dann erklärt, wie es besser geht und warum das so gemacht werden muss. Das Unangenehme ist, dass dann im Nachhinein trotzdem Alaska Software schuld ist, wenn die Lösung beim Kunden nicht geht oder nicht akzeptiert wird.

Noch der kleine Kommentar, Tom hat recht. Nörgeln von Leuten, die nicht betroffen sind. Ich kenne nicht alle hier persönlich, aber interessanterweise kenne ich Alle, die "nörgeln" - indirekt, weil ich in den letzten 10 Jahren damit beschäftigt war zwischen Mitarbeitern (Support, CRM, Info) und Kunden zu moderieren/zu de-eskalieren oder aber auch den Kunden zurecht zu weisen, weil dieser sich im Ton/Umgang mit dem Personal vergriffen hat. Kann man alles verstehen, ist auch mein Job sozusagen, aber es ist schon interessant, dass dies dann die Leute sind, die Dinge kaputtreden und nicht wirklich wertvolle Debatten mittragen.

Abschließend noch der Hinweis und die Bitte, wenn Ihr Bedenken oder Fragen zu der geplanten Lizenzänderung habt, dann kommuniziert doch gerne mit Alaska Software direkt via info@alaska-software.com. Wir sind ein lernfähiges Unternehmen - machen übrigens viel viel mehr als hier reden , damit würdet ihr im Übrigen nicht nur euren Bedarf klarstellen, sondern eventuell einen Aspekt für andere in der Community ansprechen.

Dies mit besten Grüßen
Steffen F. Pirsig
Chief Architekt
Alaska Software Inc., Germany

P.S.: Dieser Post ist im Besonderen für die Forumsteilnehmer, die hier vorwiegend lesen.

[Werner_Bayern]

Willst Du direkt mit SQL auf PostgreSQL zugreifen, betrifft Dich das nicht.

Wie meinst Du das?