Open Source IDE and You

Mike Kerner MikeKerner at
Sun Jun 8 20:23:12 EDT 2014

I would also like to have a "class" on hacking the IDE, so when we are
breaking things to look cool, we aren't doing something that will make our
work harder to accept.

On Sun, Jun 8, 2014 at 7:31 PM, Richard Gaskin <ambassador at>

> In another thread the topic came up about moving our open source process
> forward with the IDE.  Let me describe some of the current options already
> on the table, and invite your suggestions for others:
> There are challenges with any open source project, and with LiveCode
> they're made even more complex by not being able to easily use
> off-the-shelf systems for our unique stack file structure.
> So in the interest of helping to find ways to move things forward with
> what we have now, members of the community and the core team at RunRev have
> been taking on some initiatives toward that end.
> As with just about any component in any software project, we can expect
> that the IDE we currently use will eventually be replaced with something
> better suited for the engine as it evolves.
> Ideally that process will include a lot of community contribution, and
> indeed Ben and others at RunRev have noted that much of the long-term
> planning revolves around community-driven components.  However, dependent
> as it is on specific engine features that don't yet exist, I wouldn't
> expect it soon.
> In the meantime, there are bugs in the IDE and opportunities for
> refinement, and these can be done with the assistance of the community if
> anyone here is up for it.
> In broad terms:
> - Forums as a central working group resource we can use to explore ideas,
> assemble teams, and manage projects
> - Experimental "FIX:" protocol in the bug database
> - Forking to explore radical design initiatives
> In more detail:
> Forums as Working Groups
> ------------------------
> To help move things along, Heather elevated my privileges in the forums so
> we can create new sections as needed to form working groups for IDE
> projects:
> <>
> The protocol used there is an attempt to bring some of the things I've
> seen work with other projects into this community:
> Topics are initially flagged as "Brainstorm", encouraging folks to discuss
> ideas and explore the range of things they'd like to work on.
> Once a given scope has become sufficiently well defined to be actionable,
> and with a team and a team leader to make it happen, we can make a separate
> thread for that with the heading of "Project:".
> A few projects are underway there, mostly on the documentation side but
> we've seen interest from some members of the community in helping with a
> triage on RevOnline, which seems a good focus while we're all still
> exploring the process because it's very valuable to the community and when
> it breaks people are vocal about it. :)
> EXPERIMENTAL "FIX:" protocol
> -----------------------------
> I really do need to stress that this is EXPERIMENTAL, so please do not
> participate in this EXPERIMENTAL protocol if you require that your fixes be
> acted on immediately.  Have I stressed that it's EXPERIMENTAL enough?
>  Okay, here's the deal:
> If you have the time to fix a bug that's bugging you in the IDE, that's
> the best first step because at that point we have at least one copy of the
> IDE where that bug no longer exists.
> To share the fix with the core team, paste the code in your original bug
> report for the item, along with the object reference and line numbers of
> the script it belongs in.  Once you've done that, change the Summary field
> to be prefixed with "FIX:", so the team can see it's flagged as a report
> that also includes a fix.
> Of course any FIX item, like any bug report, must have a recipe.  If the
> recipe takes more than a single line in the Message Box to execute, please
> also include a sample test so the team can not only readily identify the
> problem, but also so that they can add it into their testing system to
> minimize possible regressions in the future.
> Did I note that this protocol is EXPERIMENTAL?  On the RunRev side, things
> are hectic and complex. They're willing to experiment with this protocol to
> see if it's helpful, but if we see submissions lacking in quality or absent
> of sample stacks, it won't help at all.  So right now this is EXPERIMENTAL,
> and it's up to us to make sure it's actually helpful.
> Forking the IDE
> ---------------
> The IDE is licensed under the permissive MIT license, just as the MetaCard
> IDE was in 2003, so anyone can modify it however they like.
> While forking can risk audience fragmentation, it can be a good choice for
> impatient people or radical visionaries. :)  And it can be a good choice
> for making specialized IDEs for specific niches, like education.
> With a fork you're completely unencumbered by whatever long-term
> considerations the core dev team has to accommodate, or any backward
> compatibility any community members may expect.  You can do whatever you
> like, and sometimes this can be a good way to explore ideas.
> In my own view, the risk to audience fragmentation is really only a
> learnability issue, since things like the User Guide by necessity will only
> document the IDE that ships with the main distribution from
> But if you want to make sweeping changes beyond what RunRev can
> accommodate, or just want to explore radical new designs without worrying
> about compatibility, fork away.  That's what the GPL is all about, learning
> and proliferation.
> Another option along these lines worth mentioning is building an entirely
> new IDE, either forking MetaCard or building it from scratch as Mats
> Wilstrand did with rIDE:
> <>
> rIDE is an ambitious project, and rather exemplary in the the way Mats has
> embraced open source process and actively invites contributions.
> Other Options
> -------------
> What would you like to contribute, and what obstacles have you found that
> have prevented you from doing so?
> Let's figure it out together, and make the best LiveCode ever.
> --
>   Richard Gaskin
>   LiveCode Community Manager
>   richard at
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:

On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."

More information about the Use-livecode mailing list