Reface pricing

[Brian K. White]

----- Original Message ----- 
From: "Fairlight" <fairlite at fairlite.com>
To: "filePro Mailing List" <filepro-list at lists.celestial.com>
Sent: Friday, May 18, 2007 1:28 PM
Subject: Reface pricing


> You know...I just read the full list of what Reface does.  All the 
> features
> sound great, all the requirements are reasonable (although I have to 
> wonder
> when they talked resolution if they accomodated font scaling [like 125% of
> normal like my ATI used to be set...so many applications don't that I had
> to drop it and start squinting]).
>
> My one problem with it in theory if I were to propose it to someone for 
> use
> isn't so much the pricing on the whole in terms of buying the development
> kit.  It's the concept of paying that much and being limited to 'x' 
> screens
> before you pay more money for yet more screens from the same exact 
> software.
> Especially if you get to be profficient and are doing 100% of the work and
> never call them again.  I can't see that going over very well, having had
> firsthand experience with a lot of people's expectations of software
> purchases and experiences with various vendors.
>
> People have complained over the years that fP's licensing makes
> increasingly less sense for developers, and nobody really likes to be
> nickel and dimed to death.  People have an expectation that when they buy
> something, they bought it and can use it reasonably in an unlimited
> fashion, more or less.
>
> If I see Reface hitting difficulties in adoption, it's in this one
> area--how it's licensed.  That's like fP adopting a model that says that
> the runtimes might be limited to 'x' users, but the development system
> is limited to 50 tables and you have to pay to add 10-table blocks at a
> premium.  I just don't see that flying--and shouldn't give Bud any "wise"
> ideas, not that he seems to read anything anyone says or sockets would 
> have
> been bundled.  But by the same token, I think it's going to be a rough
> sell for Sound Ideas, personally.
>
> I guess it depends on if that's really a software thing, or if it's
> considered a support contract because they'll do so much one-to-one.  If
> it's support, they're still better off from a perception point of view
> splitting out extended support and unleashing the product limitation-wise.
> Especially when someone gets profficient enough that they no longer need
> more than once in a blue moon support.  People -really- don't like limits
> on their software.  I'm having a hard time imagining any positive reaction
> to that kind of pricing -structure-.  It's not the numbers.  They could
> probably charge a couple grand more for the devkit...just not milk it per
> screen count.  It's that people hate running up against arbitrary limits
> for something they've paid a hefty amount for.  Users, I can see and it's
> sensible.  Screens, not so much.
>
> I mean, I'm just thinking about it, and I've seen places with like 80+ fP
> files, and you know, 5-10 screens each for many of them.  They might not
> all need refacing, but it'd be pretty easy to run through the first 100
> screens and then some, depending on the application.

The web site says you have to map not only every screen but every popup 
message.

How many screens do we have?
# find ./filepro -name 'screen.*' |wc -l
4296

How many screens have we modified in the last week?
# find ./filepro -name 'screen.*' -mtime -8 |wc -l
15

Today?
# find ./filepro -name 'screen.*' -mtime -1 |wc -l
8

How many msgbox?
# find ./filepro -name 'prc.*' |xargs grep msgbox |wc -l
13134

Errorbox?
# find ./filepro -name 'prc.*' |xargs grep errorbox |wc -l
13910

Browse lookups?
# find ./filepro -name 'prc.*' |xargs grep "lookup .* b=\"" |wc -l
9623

Listbox?
# find ./filepro -name 'prc.*' |xargs grep listbox |wc -l
3491

Show popup?
# find ./filepro -name 'prc.*' |xargs grep "show popup" |wc -l
3085

Input popup?
# find ./filepro -name 'prc.*' |xargs grep "input popup" |wc -l
21307

Menu? (the processing command)
# find ./filepro -name 'prc.*' |xargs egrep "(:|;) *menu " |wc -l
569

Menus?
# find ./fp/menus ! -name '*\.-*' |wc -l
433

And this still hasn't counted the opening dialogs of all the rclerk & 
rreport commands.
(index selection and search criteria dialogs, browse screens, etc...)
All the system commands which might contain anything.
Non-filepro interactive programs called from filepro menus and system 
commands.
-pq dialogs
God knows what else...


OK that all sounds pretty scary but...

listboxes, menu commands, msgbox, errorbox, input popup, show popup, and 
browse lookups all appear to fall under "generated on the fly by dynamic 
form functions" and don't count as screens and sound like they don't require 
much in the way of developer work to get integrated into a reface screen. 
PHEW huge releif!

Up to 12 related screens may be put into tabs and count as a single 
"pc-screen"
Wow another huge break. Not to mention being a nice user interface hack to 
your existing app.

And, out of those 4296 screens,
How many screens actually accessed in the last 20 hours on a busy production 
box?
(Ideally I'd rather see screens accessed in the last 30 days, but backups 
cause all screens to look accessed at least once a day, but this should 
still be a reasonable ballpark for "screens that are actually used")
# find ./filepro -name 'screen.*' -amin -1200 |wc -l
395

Still not a trivial undertaking, but, depending on how streamlined the 
designer is, maybe not all that crazy.
All depends how fast you can burn through defining things in the designer.

Pricing and possible license manager hassels getting in the way of my 
current perfect flexability are another conversation entirely.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!


> What I saw with the screenshots though...looked GREAT.  That -is-
> definitely impressive!  That's the kind of thing that makes you want to
> pick it up and play with it just because it's cool.
>
> I just hope the technical merits outweigh the perceptions on the pricing
> model they adopted for prospective buyers.
>
> mark->
> -- 
> Fairlight->   ||| "I resent being confused with the  | Fairlight 
> Consulting
>  __/\__      ||| nitwits of the universe!" --Foggy, |
> <__<>__>     ||| "Last of the Summer Wine"          | 
> http://www.fairlite.com
>    \/        |||                                    | info at fairlite.com
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list