CommitterPhoneConf01Nov2004

From DSpace Wiki

Notes from committer phone conference, 01-Nov-2004

Jim Downing, Richard Jones, Ralph LeVan, Gabriela Mircea, Richard Rodgers, Robert Tansley (notes), Scott Yeadon

[edit] Committer's available resources to work on DSpace 2.0

Richard Jones:

Theses Alive project coming to an end -- probably take about a month or so to finish up. Then becoming official library staff.

Continuing to support & work with DSpace -- most ongoing work is going to involve DSpace -- e.g. SHERPA Edinburgh research archive

Not sure how much time to work on DSpace 2.0 -- would like to be involved in discussion -- may be able to contribute development if in alignment with local project

Ralph LeVan:

Continues to have interest in interoperability -- OAI & SRW Longer-term interest in authority control DSpace 2.0 -- Interest in discussion, though probably not development

Jim Downing

Very keen to be part of DSpace 2.0 effort -- likely 1/3 of time to DSpace 2.0 until the end of 2005

Gabriela Mircea

Only DSpace tech person on Toronto Soon starting 2nd project -- can spend 1/2 time on DSpace About 20% of this (10% total) could be spent on DSpace 2.0 Main interests are modularity & internationalisation

Scott Yeadon:

Very interested in DSpace 2.0 -- can spend 75%-100% of time on DSpace 2.0 (.75 -> 1) ANU also has 2nd developer -- Australian Partnership for sustainable repo's based around DSpace

Richard Rodgers:

Richard hopes to spend 2/3 -> 3/4 of time to DSpace 2.0 development, particularly storage layer (as part of project to integrate DSpace + SRB)

other MIT folk: hopefully 25% of FTE -- dependent on alignment with local requirements

Potentially 50% FTE from SIMILE team, as DSpace 2.0 is intended deployment channel for SIMILE technologies and they have vested interest

Robert Tansley:

Full time DSpace 2.0 -- likely to be only HP contributor to DSpace 2.0

[edit] Discussion of process

Jim: don't think we have enough committers for a real Bazaar-style approach

(post-meeting addendum) I think the _development_ should be open. If and when the 4-5 man project materializes it will inevitably have a profound effect on the direction of the code development. It doesn't need exclusive access to the code, and 2.0 doesn't need to wait for the project. Giving a closed group exclusive access would alienate (and probably annoy) anyone who'd already been working on the 2.0 code, and would result in the same community building problems we've been experiencing with version 1, once the end product was handed over.

Not too many developers. 3-7 developers would be good, so decisions can be made quickly by vote -- e.g. 24/48 hour turnaround to do that (backed up by Scott)

(post-meeting addendum) I'm actually thinking that it would be good to have a periodically elected group of 3 (or 5) architect or senior developers to whom decisions are passed for arbitration if the entire development community (which I don't think should be limited in number) can't agree quickly. For people familiar with python, I'm thinking that this "architecture senate" would play the role Guido Van Rossum plays for python - making clearly backed up decisions made in good time that the community is by and large content with.

Ralph -- developers' opinions should count more than 'theoreticians'.

Rob -- Architect has to be developer -- developers not necessarily have to be architects

Richard R: Mentions prototype-based approach

Jim: Should prototype only selected pieces, not 100s of prototypes testing every direction -- need to be focussed

Scott: Question about 1.x and 2.0 -- do we branch them? Try and feed/migrate components from 1.x to 2.0?

Richard R: We need to manage them in parallel, important that 1.x has carries on to maintain momentum

Ralph: manage in parallel -- customisations to 1.x not assumed fit to 2.0 -- we should be bunt to developers about this, rather than make promises that can't be fulfilled

Rob: Likely to end up similar to Apache HTTPD 1.3 & 2.0 threads -- 2.0 starts off with less functionality, but catches up over time. 1.3 is alive and continue to be maintained, but increasingly, new features tend to be added to 2.0 due to improved architecture

Jim (post-meeting addendum): It's worth pointing out the similarities and differences here. HTTPD was modular both before and after the major version change, I believe it was the new threading models in 2.0 (and the variety that had to be supported) that gave module developers a headache. In DSpace the nature of extensions will (hopefully) change completely, but the code required for any particular extension should be better defined and simpler to understand.

Basically I agree with Ralph. As a maintainer of a customised version of DSpace myself I'd regard the effort of porting my mods into plugins for 2.0 easily worth it, if it meant I didn't have to maintain a whole parallel branch anymore.

Ralph: Committers should flesh out an architecture by prototyping the body of it with a particular 'seed' application, e.g. e-publishing

Jim: building around storage layer prototype would be a good 'seed'

Rob: Consensus seems to be that there needs to be a longer on-ramp/overlap period of architectural discussion and prototypes and development project

Richard J: question of how easy to obtain 4 or 5 dedicated developers?

Ralph: How many open source repo efforts can this community sustain? Have we talked to the FEDORA people? Shouldn't we make a common cause?

Richard R: FEDORA & DSpace originally addressed different niches -- but DSpace 2.0 means this is less the case now

Ralph: There is fair amount of common interest: for example, DSpace could provide the UI, FEDORA the rich dissemination procedure

Agreement that more communication and cooperation between projects should occur