Delphi 10.2 LINUX Entwicklung

[bytecook]

Zitat:

Zitat von Codehunter (Beitrag 1384184)

Zitat:

Zitat von MichaelT (Beitrag 1384146)

Aber keine Sorgen, die Pfennigfuchser regen sich bei 900 EURO jährlich für BW Entwickelerarbeitplatz Lizenzen auch schon auf. Es gibt zuwenige Unternehmer und zuviel in Miete hausender unselbstständig Erwerbstätige die eher für das liebe Geschau bezahlt werden.

Als Nicht-Schweizer: Was ist "das liebe Geschau"? :)

Wie ich vormals schon schrieb, jeder hat seine eigene Sicht der Dinge. Sicher liegt auch auf unserer Seite (Brötchengeber) einiges im Argen. Letztendlich breche ich es mal auf die Frage herunter, ob der Bedarf an Funktionalität entwicklerseitig mit dem Zugewinn an Features und Preisen delphiseitig skaliert. Zumindest was uns betrifft, geht da die Schere immer weiter auseinander.

Interessant wäre die Frage, was passieren würde wenn Emba sein Lizenzmodell auf so ein Adobe-like Abo umstellen würde. Quasi Subscription für alle. Könnte mir vorstellen dass es dann günstiger werden müsste, weil man solche "Geizkrägen wie mich" mit ins Boot holen würde die sonst nur alle 5 Jahre mal eine Lizenz kaufen.

Bring die Embas nicht auf dumme Ideen :P Ich hab nach wie vor CS6 Extended, und arbeite neuerdings mit Affinity Designer sowie Affinity Photo als Ersatz für CS Live. Ein Adobemodell würde eher kontraproduktiv wirken, eine Subscription parallel zum derzeitigen Maintenance Modell wäre denkbar (Siehe Modo Lizenzmodelle, http://Foundry.com). Als vorbildliches Bezahlmodell sehe ich das "Substance Live Model" von http://www.allegorithmic.com/

Und - aus dem Unternehmerblickwinkel betrachtet - hängt der Einsatz eines teureren Produktes nur vom Mehrwert für das Unternehmen ab. Bin kein "Centfuchser", aber ich habe heuer sogar unsere VisualStudio Lizenz gedroppt, weil es entwicklungtechnisch kaum mehr Sinn macht. (Wir verwendeten VS nur zur Entwicklung von Win CE 7 Applikationen).

[Codehunter]

Zitat:

Zitat von bytecook (Beitrag 1384190)

Bring die Embas nicht auf dumme Ideen :P

Ich bin sicher, die brauchen mich Querulanten nicht dazu ;-)

Zitat:

Zitat von bytecook (Beitrag 1384190)

Und - aus dem Unternehmerblickwinkel betrachtet - hängt der Einsatz eines teureren Produktes nur vom Mehrwert für das Unternehmen ab. Bin kein "Centfuchser", aber ich habe heuer sogar unsere VisualStudio Lizenz gedroppt, weil es entwicklungtechnisch kaum mehr Sinn macht. (Wir verwendeten VS nur zur Entwicklung von Win CE 7 Applikationen).

Für WinCE hatte ich mal kurzzeitig Lazarus ins Auge gefasst. Allerdings löste sich das Problem rechtzeitig durch die Hintertür, weil sich bei dem betreffenden, überalterten Gerätepark die nicht mehr beschaffbaren Akkus verabschiedeten. Danach konnte ich das Ganze zum Glück Richtung Android abbiegen, was mir wenigstens ein XE4 mit Mobile Addon einbrachte :-)

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1384184)

Interessant wäre die Frage, was passieren würde wenn Emba sein Lizenzmodell auf so ein Adobe-like Abo umstellen würde. Quasi Subscription für alle. Könnte mir vorstellen dass es dann günstiger werden müsste, weil man solche "Geizkrägen wie mich" mit ins Boot holen würde die sonst nur alle 5 Jahre mal eine Lizenz kaufen.

Eigentlich haben wir das ja bereits. Aktuell kann man keine neue Version und kein Update erwerben, ohne das erste Jahr Update Subscription mit dazu zu bekommen (und natürlich auch zu bezahlen). Ziel dabei ist es natürlich, daß diese Kunden ihre Subscription auch regelmäßig verlängern. Wie ja schon mehrfach von verschiedenen Seiten hier dargelegt wurde, ist das auch mit Abstand die günstigste Variante um auf dem Stand zu bleiben. Die Preisgestaltung der Updates und der update-fähigen Versionen ist auch bewusst darauf ausgelegt. Lediglich im Zuge eines Amnesty-Updates, bei dem auch ältere Versionen upgrade-berechtigt sind, kann man noch halbwegs ein Schnäppchen machen. Dabei sind die oben angesprochenen 5 Jahre durchaus realistisch bis knapp anzusehen. Allerdings muss man dann auch wirklich diese asketische Haltung durchziehen und sich ein Update innerhalb dieses Zeitraums verkneifen; andernfalls zahlt man drauf.

Ganz außer Acht gelassen ist dabei aber der sich aufstauende Portierungsaufwand bei so großen Versionswechseln. Was sonst eher fließend bzw. auf mehrere Jahre verteilt abläuft, muss in so einem Fall in einem oft recht umfangreichen Portierungsprojekt durchgeführt werden, für das eigentlich im täglichen Geschäft keine Zeit bleibt. Nicht selten wird dabei dann auf externe Helfer ( 8-) ) zurückgegriffen, wobei sowas dann ja auch nicht kostenneutral bleibt.

Untern Strich halte ich eine Update-Subscription, bei der man seine Projekte natürlich auch weitestgehend zeitnah aktuell hält, für die kostengünstigere und stressfreiere Alternative. (Obwohl eine solche Aussage eigentlich schon geschäftsschädigend ist, da ich ja unter anderem auch gerade mit solchen Projekten mein Geld verdiene.)

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1384201)

Obwohl eine solche Aussage eigentlich schon geschäftsschädigend ist, da ich ja unter anderem auch gerade mit solchen Projekten mein Geld verdiene.

Fehlt dann nur noch eine Update-Subscription von dir, bei der Du die Änderungen für den Versionswechsel bei der direkten Folgeversion übernimmst (Preis natürlich trotzdem projektspezifisch). :stupid:

[Codehunter]

Ich könnte nicht behaupten, dass es einen exzessiven Portierungsaufwand nach sich gezogen hätte als ich von D7 -> XE4 -> Seattle migriert bin. Aber das ist seeeeehr subjektiv und arg von den Projekten abhängig. Darum stimme ich euch schon zu, dass es sicher auch Fälle gibt wo eine Subscription allein schon unter diesem Gesichtspunkt sinnvoll wird. Wenn man schon Geld ausgibt, dann lieber nicht für sinnlos verplemperte Arbeitsstunden.

Leider gefällt sich mein Chef in der Rolle des Frosches im Kochtopf. Etwas fertiges einzukaufen ist verdammt heißes Wasser. Während die Neuerfindung diverser Räder durch die Mitarbeiter eher zu einer langsamen Erwärmung führt. Und unseren Frosch will niemand aus seinem Topf hüpfen sehen :-(

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1384204)

Leider gefällt sich mein Chef in der Rolle des Frosches im Kochtopf. Etwas fertiges einzukaufen ist verdammt heißes Wasser. Während die Neuerfindung diverser Räder durch die Mitarbeiter eher zu einer langsamen Erwärmung führt. Und unseren Frosch will niemand aus seinem Topf hüpfen sehen :-(

Vielleicht sollte mal jemand vorrechnen was die eigenen Mitarbeiter in der Zeit gekostet haben im Vergleich zu einer meist noch deutlich umfassenderen Fremdlösung. Ich bin auch eher dafür viel selbst zu machen, aber dabei sollte man eben nicht vergessen, dass die eigenen Mitarbeiter zwar konstante Kosten verursachen, aber in der Zeit auch produktiveren Tätigkeiten nachgehen könnten und damit am Ende mehr kosten.

Aber ich kenne diese Argumentationen natürlich und gehe davon aus, dass auch dir das alles klar ist.

Es gibt für Delphi ja auch diverse Produktivitätstools, mit denen man schlicht das selbe Ziel deutlich schneller erreichen kann. Im Vergleich zur gesparten Zeit sind diese sehr billig, aber trotzdem sind es zusätzliche Ausgaben, so dass auch da wiederum oft eher gespart wird.

// EDIT:

Zitat:

Zitat von Codehunter (Beitrag 1384204)

Ich könnte nicht behaupten, dass es einen exzessiven Portierungsaufwand nach sich gezogen hätte als ich von D7 -> XE4 -> Seattle migriert bin. Aber das ist seeeeehr subjektiv und arg von den Projekten abhängig.

Oh ja. Bei uns war das eine sehr umfangreiche Baustelle bei der Umstellung Delphi 5 --> Delphi XE wegen Unicode. Manche Folgefehler sind auch erst Jahre später aufgefallen.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1384214)

Vielleicht sollte mal jemand vorrechnen was die eigenen Mitarbeiter in der Zeit gekostet haben im Vergleich zu einer meist noch deutlich umfassenderen Fremdlösung. Ich bin auch eher dafür viel selbst zu machen, aber dabei sollte man eben nicht vergessen, dass die eigenen Mitarbeiter zwar konstante Kosten verursachen, aber in der Zeit auch produktiveren Tätigkeiten nachgehen könnten und damit am Ende mehr kosten.

Powerpoint, BWL, Youtube-Video, Whiteboard, Schmierzettel, Fachliteratur, Steuerberater. Ich hab da mein Pulver vergeblich verschossen. Hast du vielleicht andere Ansätze? ;-)

Zitat:

Zitat von jaenicke (Beitrag 1384214)

Bei uns war das eine sehr umfangreiche Baustelle bei der Umstellung Delphi 5 --> Delphi XE wegen Unicode. Manche Folgefehler sind auch erst Jahre später aufgefallen.

Ehrlich gesagt irritieren mich all die Horrorgeschichten rund um Unicode schon seit Jahren ein wenig. Auch das mag fallspezifisch sein aber bei uns gab es da nur an der Schnittstelle zu diversen Datenbanken Reibereien und war mit dem Umstieg auf Unidac und aktuellere DBMS ratzfatz erledigt. Allerdings war der Umbau von BDE zu Unidac damals ein Kraftakt.

Vor XE4 wurde mir jahrelang meine Marotte vorgehalten, dass ich SQL-Querystrings in Ressourcen-DLLs ausgelagert habe. Seit der Umstellung machen das hier alle so. Wie das nur kommt ^^

[sh17]

Hmm, also ich finde es ja nicht schlecht, das Embarcadero 3th-party FMXLinux supportet, ich hoffe nur dass das irgendwann integraler Bestandteil von Delphi wird.

http://forms.embarcadero.com/WebinarFMXLinuxandDelphi

[Codehunter]

Zitat:

Zitat von sh17 (Beitrag 1386483)

Hmm, also ich finde es ja nicht schlecht, das Embarcadero 3th-party FMXLinux supportet, ich hoffe nur dass das irgendwann integraler Bestandteil von Delphi wird.

Da brauch ich keine :glaskugel: um zu ahnen, dass das keine gute Idee ist. Eigentlich wie mit Microsoft und Windows: Je mehr aufgekauft und integriert wird, umso pottiger, aber teurer wird das Gesamtkonstrukt. Beide Firmen ( E und M ) haben nicht den nötigen Elan dafür. Kleinere Features fallen aus dem produktstrategischen Fokus. Frei am Markt haben die Entwickler viel mehr Interesse daran, ihre Lösungen zu verbessern. Aber es scheint ja zur Zeit Mode zu sein, 3rd Party-Lösungen gerade so weit zu entwickeln, dass Embadera neugierig wird, nur um dann gewinnbringend abzustoßen. Das mag Delphi als IDE augenscheinlich aufwerten, Delphi als Ökosystem ist es dagegen abträglich.

[Harry Stahl]

Bei unserem letzten Delphi-Frühstück in Köln (http://wiki.delphitreff.de/) habe ich einen kurzen Vortrag über FMXLinux gehalten. Ich habe die wesentlichen Inhalte dazu jetzt auch als neuen Blog-Eintrag (Nr. 15, "Kurze Einführung zu FMXLinux") in meinem Firemonkey-Blog online gestellt, evtl. ist es ja auch für den einen oder anderen hier von Interesse:

http://www.devpage.de/blog/firemonkey.htm