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