Rev_rant part 4
Bernard Devlin
revolution at knowledgeworks.plus.com
Wed Nov 15 08:28:34 EST 2006
Dave said:
>>
The point is that all those technologies could be replaced by RunRev
and the whole system would be much more stable. They are finding it
really hard to find the right people because of all the different
technologies and tools involved. In short it would be much better and
reliable to use RunRev and would save them money and allow them to
extend their system much more easily.
<<
If your development team really were convinced by you that Rev would
solve lots of their interoperability issues, staffing issues, and
save them money, then I don't see that they would have been put off
by the cost of annual update packs. Maybe they are used to using
free scripting languages and compilers, so paying anything for Rev
might be a hurdle for them. I noticed elsewhere in this thread that
you have added:
>>
The problem is that when they read the sales small print (in this case)
and see support is not included.
<<
Can you tell us which other tools they use that come with free
support from the vendor? I don't know of any. Or is it really just
the withdrawal of 1 year of free updates as part of the purchase
price that is putting them off?
Assuming that you did manage to convince them on the technical merits
of Rev versus their other tools, I find it hard to understand how
they have justified NOT switching to Rev on the grounds of the cost
of the annual updates. Why don't you approach Runrev and see if you
can get 1 year of free updates for your team, and in return you could
serve as a marketing case study for Runrev showing how it solved all
your department's problems?
Can I also ask you: are you actually employed as a member of this
team, or are you working for this organization in some other
capacity? I was a member of a development team that really did not
appreciate people from outside our team coming to us recommending
other technologies. We would politely listen to them, then find
plenty of technical and non-technical reasons why we couldn't follow
the path they were suggesting. Sometimes we were right to do that,
sometimes we were wrong.
Bernard
More information about the use-livecode
mailing list