Open source collaboration [WAS: Re: Rev vs. AJAX... Ajax vs TAOO]

Mark Wieder mwieder at
Mon Oct 17 02:36:07 EDT 2005


Sunday, October 16, 2005, 8:27:55 PM, you wrote:

> Can you tell us a bit more about projects you've worked on where
> multiple team members needed to work on different controls in the same
> window at the same time?

Sure, but that may be missing the point a bit.

The "problem" is that stacks are monolithic, while most other
development environments use separate files: .c files, .java files,
etc. Splitting a stack into substack files helps - different
developers can work on different parts of a project that way, but a
stack is the smallest atomic unit that can be parceled out.

One problem is that as stack size grows the stack either must be split
into separate substack files to distribute the work or one developer's
work responsibility keeps growing. And splitting a stack into separate
files can require architectural changes that may have consequences
down the line. Another problem with this is that development on a
stack progresses serially (only one developer can work on a stack at a
time, then hand it off to another) versus in parallel (multiple
programmers can tackle different parts at the same time).

I've worked on java projects with 10 or so developers all crafting
pieces of a single application. Let's say someone adds a new routine
to a source file and then wants to add a reference to it to a header
file common to several source files. That developer needs to check out
the header file, make the change, and check it back in. Then when
another developer wants to make a change to the common header file
they check it out, add their change, and check it back in. Nobody can
check out the file while it's being worked on so that changes don't
overwrite each other.

Let's say there are five of us working on a project together spread
out over the world. We either have to divide the work into separate
stacks or we have to email our finished work in token-passing style.
This limits the sort of collaborative projects that can be taken on
with runrev (libraries, for example, are typically single-developer

-Mark Wieder
 mwieder at

More information about the Use-livecode mailing list