Mark Wieder wrote:
Richard-
Sunday, June 8, 2014, 11:28:28 AM, you wrote:
A secret is a willful attempt to conceal, but we have no indication that
anyone's doing that.
So before anyone runs off to the hardware store to grab pitchforks for
storming the castle over some imagined IDE conspiracy, please kindly
take a moment to consider only what I wrote
Here is what you wrote:
There is an IDE rewrite underway, and a very large-scope effort to
improve overall rendering.
One of the problems with my admittedly-lengthy writing style is that it
can make posts too long to read - I had also written:
The IDE rewrite is AFAIK very early-stage, a logical necessity
from the Open Language initiative and the implications thereof
related to extensibility. I imagine we'll be hearing more about
it as it begins to move from sketchpad to code, but right now
it's all about supporting OL so I don't believe there's much
concrete that can be said about it until OL gets fleshed out more.
AFAIK there is no version of the engine in any usable form that supports
Open Language (on the contrary, I would imagine there are many deep
design decisions still being fleshed out), so it would not be possible
for the folks at RunRev to be secretly using an IDE dependent on it.
As Jacque noted, the core dev team has been discussing plans for a new
IDE for a long time.
Evolution of features and design are an inherent part of the process for
all software, and a glance at the Road Map makes it clear that it will
only become increasingly necessary for RunRev as well.
I just think it'll be more productive if we can discuss future
development options with a presumption of good intentions.
As you know, I've been pushing for open-sourcing the IDE for over a
year now, but so far I've seen no move in that direction. If you're
privy to some information that the rest of us are not, then perhaps
you have a better word for it than "secret", because it's certainly
news to me.
If something is merely unknown, using "unknown" may be a good choice. :)
As the current acting Community Manager, the nature of the role requires
me to help find ways to remove obstacles that may be preventing anyone
from doing what they want to do in this open source project.
To recap where we are with the IDE in terms of open source process:
The IDE files are on GitHub, and even better are licensed under the very
permissive MIT license:
<https://github.com/runrev/livecode-ide/blob/master/IDE%20License.txt>
We use LiveCode because it represents a very different way of working,
but that same benefit for us poses unique challenges as an open source
project.
As you know better than most, off-the-shelf versioning systems don't
handle LiveCode's unique structure for stack files, leaving it for us to
invent our own way to make that happen.
Good work has been done along those lines (and a lot of that by you -
thank you for helping to bring it as far as it's come), and many options
exist for ways to do productive work even now, before we have an even
better system in place.
But ultimately the bigger issue here isn't a technical one of all, but
the central challenge with all open source projects: Finding people
with the time and skills to contribute.
The skills required go beyond just LiveCode proficiency. As with any
open source project, there has to be a willingness to work within a wide
range of divergent interests and goals, and a sometimes-dizzying variety
of design visions.
Very few of us in the LiveCode universe have much hands-on experience
with this sort of process. I've made only modest contributions to the
Ubuntu project (and thankfully none of them in C++ code <g>), most of
LiveCode's user base makes and uses only proprietary software, and
RunRev themselves have been open source just over a year. We're all
learning as we go.
It complicates things further that the nature of LiveCode stack files
currently precludes us from easily using off-the-shelf systems to help
support the process.
But I still believe we can do it.
There are some very smart, inventive people both here in the community
and on the core dev team, and we all share the common vision of both
sides working together productively to make the best LiveCode the world
has seen.
To help this along, we have the good fortune of having bugs in the IDE,
which are of course annoying but also allow us an opportunity:
If we prioritize addressing bugs in the current IDE right now, we'll not
only have fewer bugs, but more importantly we will have found the team
members and processes that can guide bigger objectives.
This email has already gotten too long, so let me outline some of the
ways we can work on the IDE today in a separate post.
--
Richard Gaskin
LiveCode Community Manager
richard at livecode.org
_______________________________________________
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
