Open Source IDE and You

[Richard Gaskin]

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:
<http://forums.livecode.com/viewforum.php?f=67>

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 
LiveCode.com.

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:
<http://forums.livecode.com/viewforum.php?f=79>

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 livecode.org