I wasn't intending to blame you or any other member of this list - and I
indeed assess it as honorable that you try to find reasons why this
situation has developed as it is now and thus defend RunRev.

MC is an open source project outside of RunRev's role. It's not theirs
to maintain, it's ours.

Of course, I fully agree. We do our own maintenance and I have
contributed to it, as you know. But it is another matter when that
maintenance is made more difficult because of new features (for that
matter new engines and standalone builders) that are extremely
troublesome to integrate.

What would you like to contribute?

I am not sure if I understand your question. Contribute to the MC IDE,
or to Revolution/Livecode?

For those afflicted by a short term memory I could draw up a lengthy
list, but there is another way: Just search the archives of the RunRev
lists and also the bug reports.

Just to pick out one point:

Presently I am working in a cooperative project for integrating embedded
Lua into Livecode, which will speed up image-processing by a factor of
100 or more. Kevin has already invited us to write a RunRev newsletter
article about that when we are ready.

Another example: Here is part of a recent message from Jim Ault (of
March, 25), and you can watch the videostream from the URL below:

Last Saturday I did a volunteer presentation for the Live Livecode
Code group that featured your stack Seamless Tiles Generator 2
One of my goals was to let more people know about your outstanding
work with image data and conversions.

There is a 50 minute recording of this on UStream.
Jim Ault
Las Vegas
-------------------------
message from m.schonewi...@economy-x-talk.com
You can watch Jim's presentation here:
<http://www.ustream.tv/recorded/13430477>

At that time - 2004 - RunRev had also given up its principle to allow
the possibility of total customization of the Rev IDE (a principle

introduced and observed by Scott Raney for Metacard) by
encrypting the

standalone builder.

Right, but as I noted earlier they've since fixed this by moving the
build process into the engine.

When they have now moved the build process into the engine, why is the
standalone builder still encrypted?

I've seen nothing worse than disinterest from RunRev with regard to
MC, and often some very direct support of our effort even though it
has almost nothing to do with their business plan. Never have I seen
any indication of any attempt to thwart MC.

You may be right, it may be just "disinterest" in a negligible minority,
not a purposeful attempt to thwart MC. But the actual outcome of this
attitude are the difficulties we presently encounter.
I think commitments should be observed no matter whether they affect a
minority or not.

I have never fully understood and accepted the protection of the Rev
Standalone Builder. (snip)
but I believe these fears are unfounded, as

there are surely means to guarantee a proper licensing process
without

necessarily encrypting the standalone builder.

It's happened once before, with SuperCard and Digital Chisel. I can't
blame RunRev for not wanting to be the second example.

Didn't you just state that the build process has been moved into the
engine, so - again - why maintain the protection of the Rev standalone
builder?

And, would it be possible to get access to the privileged information

Richard and Klaus received for creating the MC standalone builder?

Offhand I don't think that would be a problem, but I'm not Kevin so I
should probably run the request by him first.

He'll probably ask what the purpose is, esp. given that an updated SB
for MC is already well underway. What should I tell him?

Tell him I am keenly interested in the inner workings of Livecode as I
have been all the time. This would enable me to make proposals and
contributions for future improved standalone builders, too.

--
Richard Gaskin
Fourth World

Let me make a concluding statement:

As a member of the tolerated "MC IDE user group" and at the same time as
a holder of a commercial license for Revolution/Livecode since the
beginning (and presently up to 2013) I reserve the natural right to make
recommendations and to criticize points and developments which I think
need attention.

If I sometimes sound too aggressive, this is not meant to attack someone
personally, but rather an attempt to make points clearer.

I am interested both in maintaining the MC IDE and in further developing
Livecode, and I have supported these processes actively for many years.

My main platform for development at present is the MC IDE along with a
number of add-ons I have developed myself. Here I am in a similar
situation as Richard, whose main platform is also not Livecode, but a
development of his own on the basis of the MC IDE (Is that correct?).

The reasons for that are many - and I will not elaborate them here again.

I will not rule out that at some point in the future I could switch over
to Livecode altogether, when a level of maturity has been reached that
will make working with Livecode comfortable for me.