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
rich...@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
