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

[david bovill]

On 17 Oct 2005, at 08:36, Mark Wieder wrote:

> Richard-
>
> 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?

First Scenario
The most obvious example for me is at the handler level. I have a lot  
of functions that I re-use. Some of them are in libraries and some of  
them in a stack - like Scripters scrap book. I often sketch them,  
document them and don't quite finish them. When I reuse them, perhaps  
to port them to another platform or make them more generic, or  
faster, I then have to update them in the various stacks that use them.

Now this work is slower because it is not shared work. Other people  
are doing exactly the same work - it is waisted duplicate effort. I  
cannot share my 10 MB script library easily - so I started to port it  
to CVS with a 1MB front end. Now moving over to subversion. This  
would allow anyone to update a single function - speed it up, fix a bug.

When coding I can hit a function key and search though the handlers  
to see documentation and if I have written something like this a few  
years back - now if i could search a socially filtered repository of  
all Rev developers....

Second Scenario
I need to work in an open source development community. I work with  
other developers in other languages and create the rich clients for  
front ends. This often works as follows - i sketch out how the call  
would work locally. I call a button. This button knows nothing about  
the context of Rev - it is a black box which receives data and return  
data. It is a little slower than using a library or embedding the  
function in the stack itself, but it has the following advantages:

     1) It is more granular.
     2) It is easier to understand the purpose of the object - no  
need to figure out the stack and abstract the bit you want.
     3) The code and documentation acts as a specification for other  
developers
     3) It is easy for a python / java / perl / php programmer to  
replace and enhance the functionality with open source code.

Third Scenario
Skinning. Rev can be a fabulous tool for creating skins. The stack is  
the skin (which can be exported to XUL / XML) and worked on by other  
open source developers. For this you want to be able to drag and drop  
objects (groups?) which have been refined and bug-fixed by an open  
source development process. The rev "table-object" or an outline  
field would be examples here - but there are many many more.

Stack based approach
is robust and works. It works because it is easy within the existing  
tools for Rev. It requires minimal development. For now it works  
better than the above approach - but this is the reason why so many  
development efforts have not been fully integrated into the Rev  
community. There are three or four tree view or calendar objects  
or... out there but it is simply easier to do-it-yourself in Rev -  
than find and research which stacks are out there, hack someone elses  
stack, figure it out, modify it and copy it to your application. Then  
you have the same problem if you want to publish your work.

Publishing Economics
It is worth publishing a stack (sometimes). But not a component or a  
handler. If it were a four click process - find, download - modify -  
then re-publish - all within the Rev environment then the economics  
would change and more people would do this, and the chicken-and-egg  
dis-economics would reverse to create of positive cycle of  
incremental improvements.


> 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
> items).
>
> -- 
> -Mark Wieder
>  mwieder at ahsoftware.net
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>