[MC_IDE] Quick Poll

[Richard Gaskin]

Thanks for your reply.  I think we're pretty much in agreement on the 
things you covered, so let me just address this one area to see if I can 
provide a little clarification:


On 3/31/11 10:12 AM, Wilhelm Sanke wrote:
> 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.
...
> When they have now moved the build process into the engine, why is the
> standalone builder still encrypted?

My understanding of Kevin's agreement with Scott on acquisition of the 
engine was that RunRev not do anything specifically to prevent an 
alternative IDE from being developed and enhanced.

I do not believe that these terms went so far as requiring Kevin to 
limit the scope of what he can do with the product he acquired so that 
it's especially convenient for our of volunteers to maintain MC.  That 
would have been impractically onerous, and Raney is nothing if not 
practical; he would never have asked for that.

I feel Kevin has held up his end of the bargain admirably, going out of 
his way several times to make work on alternate IDEs easier than it 
might have been.

I can't blame him for not making it a higher priority to do even more. 
As the keeper of the engine, all of us depend on his team to prioritize 
his own company's ROI first and foremost; if RunRev goes, the future of 
the MC IDE would at best be in doubt, and at worst would have no engine 
to drive it at all.

One of the areas any software business owner is free to do as he chooses 
is to determine the model used for demo versions, and I believe this is 
the only area where his needs have caused us any difficulty at all -- 
and even then he still directed his staff to provide whatever assistance 
was needed to help us achieve our goals.


Some background on the differences in the demo model and how it plays 
our with locked stacks:

Raney's demo version was feature-limited, but Kevin feels a time-limited 
model is more appropriate for his own business.  I may have my own 
opinions, but Kevin runs his own business and I run mine and we both 
like it that way. :)

You may recall that MC's license enforcement was also encrypted, the 
only difference being which stack was encypted:  in Rev it's the 
Standalone Builder, and in MC it was Home.  But in both cases the reason 
was the same:  license enforcement.

AFAIK Scott Raney never gave the password to the MC Home stack to anyone 
in the MC IDE project.  The mctools.mc stack was made available under an 
open source license of our choosing, but the Home stack on which it 
depended remained locked with no means of accessing its code.

Raney never needed to lock his SB because it wasn't relevant to his 
business model.  He felt that if people wanted to make standalones with 
only 10 executable lines per script they could knock themselves out. But 
standalone building is directly relevant to Kevin's model, as outlined 
in the LC license agreement which expressly forbids any standalone from 
also building its own standalones.

FWIW, Kevin has said that if you have a specific app that really NEEDS 
to make standalones he would be willing to take the time to discuss the 
possibility of a unique license agreement to allow that.  But the 
off-the-shelf license prohibits it.

I don't know to what degree the current engine-based binding method may 
be restricted to the IDE engine only, or whether it could theoretically 
be used by the standalone engine.  I'll get clarification from him on that.

As for why he locks his own standalone builder, that's entirely up to 
him.  What the engine does is primarily the bit-level binding stuff 
(embedding the engine, icons, and UAC info), and there's a lot of other 
steps involved in making a working set of builds (which is why mine 
remains so weak at this point).  I have no idea what else his SB is 
doing, and given the variety of deployment options I wouldn't be 
surprised if at least some of the license enforcement is handled in scripts.

The upside to all of this for us MC folks is that RunRev's move to 
engine-based license enforcement finally freed us up from the last 
locked stack in the MC environment, Home.  Now you can make your own 
Home stack any way you want to do whatever you want.


With that background, let's step back and look at the big picture:

The ONLY area in which it's at all inconvenient to do darn near anything 
you want with any IDE you can dream up is standalone building.

In every other respect, what RunRev has provided for us MC users goes 
well beyond what he provides most other customers in terms of engine 
enhancements and info on undocumented features.

And even with standalone building, he still devoted resources to making 
sure we can at least get the job done.

So we're free to do whatever we want with all aspects of developing 
software with the LiveCode language.

I'm committed to providing a standalone builder that'll more than 
address our needs.

If we can kindly move past that, it would seem a more interesting 
question might be:

What else do we want to do to make MC more powerful for our work?

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv