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
_______________________________________________
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
