New Indy License Pricing

[Richard Gaskin]

Andrew Kluthe wrote:

 > Richard,
 >
 > It's not an issue of earnestness or integrity but of what has been
 > delivered vs what we were told was going to be delivered.
 >
 > There is a huge gap between the way things looked when they were
 > presented to us in April 2013 and the way they look today.
...
 > Will things all be delivered? Yeah, probably. But how many more major
 > version numbers will it take?

We agree that the Road Map as presented and added to since April 2013 is 
being followed faithfully, and the only question you and I have (in 
contrast to those who try to raise doubts about their integrity) isn't 
at all about "what" is being delivered, but merely "when".

I mentioned Steven McConnell because not since Fred Brooks have I found 
a writer whose explorations of software project management are as well 
researched.  In his book Code Complete he notes that more than 80% of 
software projects are over budget, many by a factor of four and 
significant minority by a factor of 16, sometimes more.

Variance between estimated time and actual is affected by many things, 
but one of the biggest is the scope of unknowns introduced by dependency 
on code beyond the control of the team.   With seven platform APIs to 
map LC's internal logic to, we can expect variance to be on the higher 
end of industry averages.

Software project estimation remains a key focus of some of the best 
minds of our industry specifically because getting it right consistently 
proves elusive.

There's a lot that could be said about the challenges inherent in 
estimating, and methods to reduce variance.  And anyone here who's been 
able to consistently beat industry averages is encouraged to share their 
demonstrated experience here.

For myself, when I'm able to beat industry averages in large part it's 
because 90% of my code was written in Edinburgh over many years by 
people much smarter than me.  That's a big part of what keeps me patient 
with the anticipatable delays with LC's Road Map delivery.


 > How many of them will turn into additional kickstarters when their
 > revenue stream dries up?

I doubt there'd be much ROI in a third crowd-funding effort, so I'm not 
all that worried about that.

As for the second one, they promised a proof-of-concept build within a 
year of closing, and it was delivered last week.  Sure, it has a long 
way to go until it's production-ready, as we would expect.  But until 
it's released any contributions to that campaign for licenses haven't 
kicked in yet, so that one isn't a concern for me.


 > Are many of these features going to end up being mac specific when
 > it gets down to finding out how hard they are to make cross platform?

As much as I enjoy my Macs, I'm doing so much more work on Ubuntu these 
days that that's an ongoing question for me too.

But in practice I've been relieved to find that I'm just not seeing that.

So far most of the 2500+ fixes and enhancements put into place over the 
last year and a half benefit all platforms.  Any Mac-specific work at 
this point seems to be limited to the minimum needed to maintain that 
platform as a viable deployment option, such as replacing QT after Apple 
deprecated it and moving to Cocoa as that became necessary.

On the contrary, as an Ubuntu user I've been more than pleased by the 
team's efforts with greater GDK integration in v7.  And since like many 
of us here I make most of my money from Windows deployments, it's been 
good to see how much attention they've been giving the rendering 
subsystem to maintain compatibility there with newer display APIs.


 > That's what I mean when I say trust. Brand fetishism just isn't
 > enough to live on anymore. The actual performance as a company
 > lately, frankly, sucks. Since, I know you are going to want examples
 > of why someone might feel this way:
 >
 > - On-rev (do I really need to say more? Search the list for on-rev)

On-rev is a separate service that doesn't affect my use of LiveCode, and 
given how cheap and plentiful hosting is these days I've never used it 
as I'm already up to my armpits in servers.

That said, it is course run by the same company, so I can appreciate how 
subscribers to that service may have a different view of the company 
than I do, because we rely on them for different things.

There's a lot to be said for the "bowling alley" strategy Geoff Moore 
describes in The Gorilla Game.  But I don't run Kevin's company and he 
doesn't run mine, and we both like it that way.  I got out of the 
hosting business 15 years ago when the margins plummeted.

On balance I feel compelled to note that I have several friends who are 
quite pleased with the service, and since I've never used it myself I 
have no opinion about it beyond that.


 > -The documentation is scattered, sparse, and most of the code samples
 > are images. Fun.

A complete overhaul of all documentation has been underway for some time 
(it's not a small task), and as recently as last week I met with Kevin 
to discuss ways we can speed that along by leveraging the community 
documentation team we've assembled.  Yes, it would be nice to have that 
more quickly, and with any luck we will.

As for images, the code examples I see are in the Dictionary and the 78 
tutorials included in the install, all in plain text.  Where are code 
examples provided as images?  I agree that those should be text.


 > -The website is going down an awful lot rendering the point above
 > moot as it's not available.

Yes, the DDoS attacks were annoying for everyone, but it seems the 
safeguards they put into place last week have held up well since.

The taxonomy definitely needs further refinement, and in addition to the 
work Steven Crighton is doing on that I discussed concerns like yours 
with Kevin last week, and with Steven we're working out a plan to not 
only make things easier to find, but also keep them easier to find as 
the inevitable changes are introduced.

That said, if you have specific examples of resources you'd expect to 
find there but haven't, it would be very helpful to hear what you were 
looking for and how you went about looking for it, so we can try to 
incorporate those expectations into a revised taxonomy.


 > -Everything i mentioned above about the disappointments that followed
 > the "delivery" of the kickstarter campaign.

No argument there; behind stated schedule is simply behind stated 
schedule.  Given that any estimate cannot reflect actual costs the best 
alternative might be to follow the path most companies take by keeping 
their development schedule concealed.  Personally, I prefer the 
openness, though apparently it could do with more caveats well communicated.


 > Runrev's track record isn't dishonesty, it's being confident that
 > they can follow through on the things they set out to do and do them
 > well. So this admittance from Kevin that they spent 2x what they
 > raised on the kickstarter to build Livecode 7 continues to point to
 > that.

All things considered, compared to industry averages a 2x variation for 
the scope they bit off isn't bad. :)

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com