MC IDE - next steps

David Bovill david at anon.nu
Tue Aug 26 10:10:01 EDT 2003


Richard Gaskin wrote:
> 
> Every project needs an owner.  Not in the legal sense of property, but in
> the terms of responsibility.

Yes. maybe it is better to let leadership emerge based on work done and
contributions to the group. Neutrality and the ability to bring people
together around the project would be important qualities.

> - Who wants to be the team leader on this?  And should the project lead be a
> rotating position, maybe annually or semi-annually?
> 

Think 6 months sounds good -  a year can be a lot even in established
groups.

> It seems reasonable to expect that the project lead would at a minimum take
> care of folding contributions into a master build and making that build
> available for testing from time to time.
> 

I think an open group should form, sort out an agreed hosting for the
project and process for contributions, as well as archiving past and
future engines. I'd propose that this group elect a project leader after
a fixed time - say 3 months with some form of rotation every fixed
period thereafter.

> - What other responsibilities are needed?
> 

The project needs a clear and agreed statement of purpose and some
agreed principles that derive from this purpose. The purpose should
clarify the nature of the project to which all members of the group
subscribe. At the moment we have something along the lines of:

	"To maintain and develop a minimal open source interface to the MC (now
Revolution) engine based on the original MC IDE"

This needs more clarification, in particular in which fundamental ways
the "open source interface" differs in aims, objectives and
implementation" from the full RunRev IDE.

> - Where should these builds be posted? (Scott, can we have a spot on the
> metacard.com server for that?)
> 

I think some server space from RunRev would be a good idea. My
understanding is that Scott / RunRev are willing to support a community
initiative in this area, but not to lead it. I think it would be very
positive if we could persuade Scott to support the initial process.

I would propose that it would be healthy for the group to have an
independent voice that feedback to RunRev, someone from RunRev would
ideally be an equal particiapant of the group.

As an open source project I would suggest that we would benefit from
hosting it with an organisation that provides free hosting and
services for open source initiatives. One such project in Sourceforge
which will provide 100MB of server space for free for a project of this
nature. Binaries from this site can be automatically posted to a page on
the RunRev web site. There are other less known service which provide
similar support to open source projects, which I'd be happy to research 
and report back on.

...
> 
> As for the overall goal, for myself I prefer as few changes as possible and
> it seems a lot of others here feel the same.  

Yes. Start with hosting the MC IDE.

> So maybe we focus on a plugin
> system first so anyone can add new goodies at ant time without complicating
> the IDE itself.
> 

This sounds a good initial project when we are up and running.

> We could use RevNet to distribute plugins, 

I would support such a move.

> 
> I would be happy to volunteer to manage the plugin architecture, with
> feedback and approval on any specifics from the others here of course.
> 

Please - maybe a draft document? Is there one already? I'd like some 
input on this too.

> Another task that would be useful would be to write the glue routines that
> would enable us to open the Transcript Dictionary from within MC.  Any
> takers?
> 

Documentation is an interest. So I am happy to take this forward for a 
while...

> The plugins and Help modifications would cover most everything I'd need.
> What other changes would we consider necessary to get started (as opposed to
> the nice-to-haves, which could be added later)?
> 

I'd stress, neutral independent hosting, structural relationship with 
RunRev and explicitly and clearly laying out the core purpose and 
principles of the project.

david




More information about the metacard mailing list