Andrew Kluthe wrote:
> I totally understand what you're talking about there, but between
> a full time gig, very young children, and freelance work at night.
> I just don't know where I'd find the time to be effective at giving
> them the level of detail that they need.
I hear you. The only reason I'm in a position to volunteer as much time
as I do is because I have a responsibility to my company and those of my
clients, which are dependent on LC as the foundation of their product lines.
But LC is useful for a great many different workflows, and not all of
them are as invested in it as the ones I help steward, so it's nice when
folks have the time to submit reports but fully understandable if they
don't.
> In short, the request for us to invest this much time in helping them
> figure it out is almost as stressful as the actual problems.
>
> The Us (community) vs Them (RunRev) that persists is the result that
> most of the people started using this software when it was still
> proprietary. It's a big step for many of us to transition to.
I've seen this dynamic before, and I believe it has less to do with dual
licensing than the nature of development tools themselves.
I served on the advisory boards for Oracle Media Objects, Allegiant
SuperCard, and Gain Momentum, and with each the relationship between the
vendor and the community was in various ways challenging on both sides.
We had many long meetings between the Gain team, a team from Irix, and
my client, just to try to get robust video playback, and ultimately
someone one my client's team had to write custom C code to pull it off.
A number of critical features SuperCard developers relied on weren't in
the engine at all but provided through externals, a good many of which
were written by a team member in his spare time. This meant funky
syntax and design compromises, but they got us through the day well
enough to move on to other challenges.
With quality, all of them faced a daunting task that's quite literally
orders of magnitude beyond the scope of testing requirements for
anything we build with these tools:
In the apps we make with xTalks, we use a subset of the language in very
specific ways that constrain the range of possibilities the users will
encounter.
But in the xTalk engines themselves, rather than providing "features" in
the consumer software sense, they deliver thousands of tokens that can
be combined and recombined in a combinatorial explosion of possibilities.
Of all the xTalks, the only one that came close to the scope of
automated testing the LC team uses was HyperCard, but theirs was much
more limited (and of course stopped being enhanced when the toolkit died
20 years ago).
But since the range of possible combinations is large enough to be
reasonably considered close to infinite, the scope of any automated
testing can only accommodate a slender minority of all possible
combinations.
They add to it as bugs are encountered, but given the nature of the task
it can never be a replacement for live testing in the wild. No
automated test suite can be, for any product, which is why all software,
from simple consumer apps to operating systems, rely on outside Beta
testers as a critical component of quality assurance.
And despite everyone's best efforts, all software always has bugs,
according to McConnel's research at the rate of about 15 to 20 per KLOC.
> I'm sorry to say v7 is not a production quality toolset for those
> without tons of extra time on their hands.
> As a result, I have done no new development that wasn't a one off
> utility for something simple in livecode since it went open source.
> I'm too afraid to lose my lunch (or for users to lose theirs) to
> these issues.
Which issues in the RQCC are yours? I'd be happy to take some time to
review them to see if they can be bumped up in the queue.
> When one of my livecode apps needs an overhaul, I've been selecting
> other tools/technologies to rewrite it in because of how long all
> of this has been building up to and in the works.
I had considered a similar move myself for many years before LC went
open source, since no developer tool has a chance of being taken
seriously in the 21st century without at least an open source option.
But I've been unable to find any for which the cost of a complete
rewrite is lower than the much cost of seeing a couple bugs fixed.
What language are you migrating your code to?
> It seems like lately there has been this big move to say "Well,
> there isn't actually a problem. People just aren't pitching in
> to help us like they should."
I've heard sentiments like that from the community but not from anyone
at RunRev, which is among the reasons I try to skim past vague
complaints to focus on specific actionable issues, trying to sort
through the noise to find the signal.
I'll be the first to say LiveCode is a FUBAR project, every bit as much
as every xTalk before it, Ubuntu and most other operating systems,
nearly every commercial app I've used, and the series of recent
oops-we-missed-it-but-we'll-get-it-this-next-time releases from Apple,
the most powerful tech multinational on earth, with the OS they depend
on the most to power their wealth.
Software is hard. And the more complex the system, the harder it is.
I just spend time lending a hand where it benefits my business to do so.
When I find the perfect dev tool that's every bit as productive as
LiveCode but also entirely bug-free, I'll gladly ride my magic flying
pony to pick up a copy. But I fear that choice of vehicle is as likely
as the destination. :)
So for now I just file a bug report and cut some code as needed to get
through the day in a world defined by limitations.
Maybe I think to small, but I'm not alone. I know some have encountered
true show-stoppers in LiveCode for which no workaround can be found, but
I also know a great many people shipping apps to thousands of happy
users, so maybe my interest isn't entirely misplaced.
--
Richard Gaskin
LiveCode Community Manager
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode