Ist Delphi so Bedeutungslos ?

[QuickAndDirty]

Zitat von BUG:

Zitat von QuickAndDirty:

Ich verstehe nicht was das angeblich verhindern soll.

Der Aufwand einen Fork zu betreuen, sollte wohl auch nicht unterschätzt werden ... schon das Einpflegen der Patches aus dem Hauptprojekt sollte einem zu tun geben.

Ein überzeugendes Projekt sollte, wenn erstmal ein initialer Aufwand geleistet wurde ein Community entwickeln die den entsprechenden Aufwand leistet, zumal wenn die Zielgruppe Unternehmen sind, die ja schon mal jemand Bezahltes abstellen Features in ein genutztes Open Source Tool einzupflegen. (Siehe QT bindings in Lazarus)

[Medium]

Bei FPC kommt jedoch auch wieder in Spiel, dass es eigentlich ja keine Konkurrenz zu Delphi ist. EMB will Delphi als Enterprise Produkt vertreiben, bzw. führen sie sich zumindest so auf. Leider vergessen sie dabei, dass das Kunden umsorgen genau der Teil ist, den man in diesem Segment gerne bezahlt wenn es passt. Das Produkt selbst ist doch nur Werkzeug. Ich muss jemandem haben, bei dem ich mich darauf verlassen kann, dass er mir mit Rat und Tat 24/7 auf's Pferd helfen kann, insbesondere beim Bugfixing. Das ist der Teil, der mein Zeitkontingent schont, und der echten Geldwert hat. FÜr beide Seiten.

Bei FPC kommt dieser ganze Gedanke ja überhaupt nicht zum tragen, das liegt auch in der OS-Natur. Eine Firma, die OS als Tools einsetzt, muss sich darüber im Klaren sein, dass sie sich selbst eine interne Support- und Pflegeabteilung halten muss um die Endprodukt-Entwickler bei Laune zu halten. Auch ein Geschäftsmodell, tun manche auch, aber der überwiegende Teil möchte doch für ein Produkt bezahlen, bei dem er den Nutzen der Zeitersparnis durch Abgabe dieser Verantwortungen erhält. Welches Tool jetzt genau dahinter steht ist fast schon zweitrangig. Das ist aber der graduelle Unterschied zwischen Hobby, Business und Enterprise.
Wir könnten uns FPC z.B. nicht leisten. Wir brauchen eine Umgebung, die einfach läuft, mit der wir unsere Software zügig bauen können, mit deren Erlös wir unsere Kaffeekasse aufbessern. Der administrative Aufwand für FPC passt einfach nicht rein, und wenn es hakelt - ja sollen dann einfach mal eben alle Projekte für X Zeit angehalten werden, bis die Community zumindest schon mal auf das (hier fiktive) Problem aufmerksam wurde? Wenn man keinen hat, der an soetwas intensiv in Vollzeit arbeitet, oder jemanden, den man dafür bezahlt, stelle ich mir das als Softwarehaus schwierig vor.

FPC zielt auf Hobby oder Enterprise (mit eigener FPC-Abteilung), Delphi zielt zumindest dem Anschein nach auf Business und Enterprise, kann aber die dafür nötige Qualität im Moment nicht liefern. Sowohl im Produkt, als auch im ganzen Drumrum.

[sh17]

Ich bin eigentlich noch nicht in die Not gekommen, bei Emba direkt Support in Anspruch zu nehmen. Und wenn das wg eines Bugs in Delphi so wäre, sieht man ja, was daraus wird. Mit gefällt halt nur nicht die Richtung von Delphi. Immer mehr Komponenten von Drittherstellern werden einverleibt bzw andere geben die Unterstützung komplett auf. Und da sind viele gute Komponenten dabei. z.B. TPrintPreview. Das sieht man schon an den Indy-Komponenten. Ich möchte die nicht in der IDE. Ich möchte den aktuellen Trunk verwenden und selbst entscheiden. Nur setzen andere Teile in der IDE wieder auf den Indys auf, also kann ich hier Verrenkungen mit Pfaden usw. anstellen. Ich möchte eine IDE mit ordentlichem Compiler, Debugger und den Grundlagen - meinetwegen VCL oder FireMonkey. oder QT oder oder. Aber alles andere...

Mein Idee war nur eine zweite Firma mit mehr Interesse für den Kunden am Markt zu platzieren, die Support für FPC mit (irgend einer) IDE für finanzielle Entlohnung bietet. Wobei FPC soweit geändert wird/wurde, um Delphi-Projekte/Kunden direkt abgreifen zu können. Quasi als ernstzunehmende Alternative. RemObjects machts vor - finde ich