[DUG] XE8

Tue Apr 14 10:41:38 NZST 2015

Jeremy,

If they are going to *withdraw* entitlement (as reported by the OP) by
right associated with ownership of a license and make it contingent upon a
separate maintenance contract then yes, I expect to see a *commitment
*expressed
as well as an entitlement.

Note:  this isn't primarily about whether or not there will be any
updates/hotfixes to the current version, which a customer may not be in a
position to transition to, but whether that customer can *expect* to
receive any updates or hotfixes to the previous version they own a license
for and may be currently "stuck" on.

The expression of entitlement to updates and hotfixes for up to 3 prior
versions is offered as part of the value proposition of SA.

But there is no *commitment* to realise this value.  Historically EMBT have
abandoned each Delphi version as soon as a new version is released, almost
without exception.  Worse: in some cases they have regressed defects
previously fixed!  Based on that, an entitlement to updates to previous
versions is completely and utterly meaningless.  If EMBT had a track record
of actively and effectively supporting older versions then there wouldn't
be an issue.

But they don't.

It would be quite straightforward to commit to something along the lines of
"defects fixed in the current version *will* also be fixed in up to 3 prior
versions where affected by the same defect".

i.e. yes an "unknown", in terms of exactly what will be fixed, but a
quantified and express commitment that certain fixes applied in the current
version WILL be fixed in applicable, qualifying prior versions.  And to be
fair there are a LOT of *known* bugs reported in prior Delphi versions and
some of these are claimed to have been fixed in XE8.

So where are the updates to fix these for XE5, 6 and 7 ?

Some other things to bear in mind:

This is the same company that attempted to surreptitiously impose a
restriction in their EULA on the use of 3rd party products to extend the
capabilities of their own (the prohibition on the use of client/server
API's with Pro SKU in XE3).

This is the same company that attempted to impose a 5% price rise on [my!]
SA renewal in clear and direct contravention of their own terms and
conditions for imposing such a rise.

This is the same company that advertised and sold cross-platform
development in the Pro SKU to entice new users/customers, only to then
withdraw that capability.

Quite simply this is not a company that has earned the right to be trusted
implicitly when it comes to their license and contract terms.  Customers -
new and old - would be well advised to pay very close attention and to
interpret any vague or ambiguous terms in the context of the conduct of the
vendor.

An empty promise costs nothing to make.  EMBT's assessment that at least
some people will be naive enough to believe that it represents "value"
appears to be right on the money [sic].

There is of course an alternative approach:  If there is no intention of
providing updates to older versions then simply say so.  At least then the
value proposition could be more honestly evaluated.  The ever-benevolent,
butter-wouldn't-melt, fairy godmothers that some people seem to believe are
at the helm at EMBT would always have the option of providing such updates
as ex gratia on an ad-hoc basis if they wish, they simply wouldn't be
obliged to.

*But nothing in the current SA obliges them to either*.

On 13 April 2015 at 17:45, Jeremy North <jeremy.north at gmail.com> wrote:

> So you want them to quantify an unknown.
>
> Good luck with that. Perhaps it's just the areas of the industry you touch
> that's in trouble.
>
>
>
> Sent from my iPhone
>
> On 13 Apr 2015, at 3:20 pm, Jolyon Smith <jsmith at deltics.co.nz> wrote:
>
> If this is what get's dismissed as pedantry these days then the industry
> is in deeper trouble than I imagined.  It used to be called "paying
> attention to important details" and "sounding notes of caution where
> warranted".
>
> An Entitlement is not the same as an Obligation or even an Expectation,
> and ignoring the distinction is a recipe for disaster in any contract
> negotiation (which is what a license and support agreement is, lest we
> forget).
>
> On 13 April 2015 at 16:26, Jeremy North <jeremy.north at gmail.com> wrote:
>
>> pedantic much?
>>
>> On Mon, Apr 13, 2015 at 1:52 PM, Jolyon Smith <jsmith at deltics.co.nz>
>> wrote:
>>
>>> Updates and hot fixes for up to two (2) years and three (3) major
>>>>> releases
>>>>
>>>>
>>>> This is meaningless unless there is also a money-where-your-mouth-is
>>>> commitment to *provide* updates and hotfixes for versions other than
>>>> the current one.
>>>>
>>>
>>> > This is actually what it says doesn't it.
>>>
>>> Not really.  It says that SA entitles you to *receive* updates and
>>> hot-fixes.  It says nothing about any commitment to *provide* any such
>>> updates or hot-fixes.  Of course, there is no way to predict just how bad a
>>> release is in order to determine how many updates or hotfixes would be
>>> required.
>>>
>>>
>>> On 13 April 2015 at 15:24, Jeremy North <jeremy.north at gmail.com> wrote:
>>>
>>>>
>>>> On Mon, Apr 13, 2015 at 12:56 PM, Jolyon Smith <jsmith at deltics.co.nz>
>>>> wrote:
>>>>
>>>>> Native mobile controls OSX iOS Android for many controls (eg DateTime
>>>>>> picker)
>>>>>
>>>>>
>>>>> In one review I read it was noted that this is a NO-OP on everything
>>>>> except iOS.  On all other platforms you still get the doppelganger
>>>>> FireMonkey controls, even if you have configured for "native".
>>>>>
>>>>>
>>>> The native controls are basically for iOS as mentioned - not all have
>>>> native support.
>>>>
>>>> The "doppelganger" fmx controls are good if you are creating a bespoke
>>>> look and feel for your corporate brand across all supported platforms.
>>>>
>>>>
>>>>>
>>>>> Updates and hot fixes for up to two (2) years and three (3) major
>>>>>> releases
>>>>>
>>>>>
>>>>> This is meaningless unless there is also a money-where-your-mouth-is
>>>>> commitment to *provide* updates and hotfixes for versions other than
>>>>> the current one.
>>>>>
>>>>
>>>> This is actually what it says doesn't it. The intention is apply fixes
>>>> to previous versions. I understand it won't be all fixes as some will not
>>>> be possible without breaking interface compatibility.
>>>>
>>>> If it is done as they say, it will be a welcome change but then again,
>>>> how can we trust a company that can't even keep their newsgroups
>>>> operational consistently and have drones looking at submitted requests and
>>>> closing them with nonsensical resolutions.
>>>>
>>>>
>>>>
>>>>> When was the last time EMBT released more than a token update or
>>>>> hotfix for anything other than the current version ?  Is their any
>>>>> commitment to do better in this regards in the future ?
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> NZ Borland Developers Group - Delphi mailing list
>>>> Post: delphi at listserver.123.net.nz
>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz
>>>> with Subject: unsubscribe
>>>>
>>>
>>>
>>> _______________________________________________
>>> NZ Borland Developers Group - Delphi mailing list
>>> Post: delphi at listserver.123.net.nz
>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
>>> Subject: unsubscribe
>>>
>>
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at listserver.123.net.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
>> Subject: unsubscribe
>>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20150414/71f81d09/attachment-0001.html 