hair-pulling frustration

[Richard Gaskin]

Richmond wrote:

> Obviously Dr Hawkins is not over-enamoured of the Open Source
> theory: LiveCode is paid for in a different way [the "I'll
> scratch your back if you'll scratch mine" way] than the
> 'standard' commercial way [I pay you, and you do ALL the work].

I think you and I may be a rare breed.  I know folks in both the 
proprietary and open source worlds who feel the other is the embodiment 
of evil, but I see only an inherent symbiosis in which each side not 
only benefits the other, but perhaps even to the point of mutually 
beneficial dependency.  Where would open source be without support from 
proprietary vendors, and where would those vendors be without the tools 
and infrastructure the open source world provides?  Heck, these days 
both Apple and Microsoft promote Linux - I think it's safe to say both 
worlds can get along well at this point by working together.

With developer tools, the argument for open source is undeniable:  of 
the Top 100 Programming Languages on the TIOBE list, all but a small 
handful from multi-billion-dollar companies are open source.

Since the turn of the century, the range of great tools available under 
open source licenses has exploded.  There's simply no way a smaller 
player like LiveCode could ever hope to make it into the Top 50 without 
at least an open source option.


> Part of the problem is that Livecode is NOT like GIMP (for instance):
> GIMP is 100% Open Source, while Livecode both IS and ISN'T Open Source,
> and RunRev has to play a terrible balancing act keeping both camps 
> happy.

This is another of the distinctions between consumer tools and developer 
tools:

As a consumer took, GIMP does well under GPL because it doesn't need to 
support developers building proprietary apps with it.

As a developer tool, LiveCode needs to provide an option for proprietary 
deployment.  And as a complex work, it needs considerable resources to 
be maintained.

The dual-license model used by MySQL and others seems a good fit 
covering both sides.


> If, on buying the non-free version and it turns out to be "dicky"
> I shall be even more trenchant in my response than Dr Hawkins.

And perhaps rightly so.

The issue with testing, however, is very different from the decision to 
move from "Release Candidate" to "Stable" (in which case it really ought 
to be stable):

With testing, the primary beneficiary is ourselves.

I've been a beta tester for Adobe, Asymetrix, Oracle, Triton, Silicon 
Graphics, Canonical, and others, and I've never been paid nor expected I 
would be.   I did it because the quality of my own work is dependent on 
theirs, and I've been in the business long enough to appreciate how the 
complexity of software requires beta testing.

When I have no serious investment in a tool, I don't bother.  But for 
tools my business relies on, testing them to make sure they do what I 
need has never struck me as anything other that just part of running a 
business that relies on software.

I also do a stress test on new hard drives before I put them into 
production.  And I test drive cars before I buy them.  Just seems like a 
prudent thing to do.


> He does, however, state that 'stable' versions are not much better than
> the others, and that is where the problem lies.

To a degree I would agree with that.  Obviously a quick review of the 
change logs shows how much effort is expended to fixing show-stoppers 
during the test cycle, but in all fairness to Dr. Hawkins the issue 
Chipp found with the Quit item on Mac is an odd one that one could 
reasonably be assumed would not warrant "Stable".

It'll be interesting to hear how that one happened.  I think it's safe 
to say no one at RunRev saw it and said, "Nah, good enough, ship it 
anyway".  I'd wager that somehow it never showed up in their daily work 
for some reason, even with their large and growing set of automated 
regression testing tools, and no doubt this issue has been added to that 
suite since.


> Several times I have stated that in my opinion RunRev are being
> swept along into a sort of feature bloat which prevents them
> from sorting out little 'niggles' in existing features. I se no
> reason to change that opinion.

Perfectly valid.  We all have our own preferences, and one of the 
reasons I left the dev tools world long ago and have no intention of 
returning to it is that it's full of a great many very smart people who 
can each come up with compelling reasons to need very different things.

Some prefer we aim for a completely bug-free version, holding off all 
new development until that's done.  But there's never been a completely 
bug-free app of this scope in the history of software, and with things 
like Apple's deprecation of QT, their pending deprecation of Carbon, 
Ubuntu's pending deprecation of 32-bit, Windows' ever-changing rendering 
models, and other things in the business environment over which no one 
at RunRev has any control, it's hard for them to come back to us and 
demand we use outdated OS version until they deliver the world's first 
bug-free dev tool.

I tend to favor performance, even though I know full well Knuth's maxim, 
"Premature optimization is the root of all evil."

And others need things like Unicode, which required sweeping revision of 
nearly every code module, while others need mobile native controls, and 
others need PDF support, and others need something else.

It's a tough balancing act.

On the whole, given the scope of v7 and the number of true show-stoppers 
being at this point one (if there are others please let me know), it's 
not bad for a code base of some 800,000 lines and growing.

And I'm happy to advocate for further review of the process that moves 
the designation from "Release Candidate" to "Stable".

But for that to move from an abstract "Just do more!" to specific 
actionable tasks, it would be very helpful if I could get the bug report 
numbers to make it possible for me to advocate for those bugs.

-- 
  Richard Gaskin
  LiveCode Community Manager
  richard at livecode.org