This meeting was supported by JISC and - Self-Archiving and Open Archives

Putting Eprints Software into the User Community: summary report

Summary report of an invitation-only roundtable workshop on June 23, 2004, London
organised by JISC and the School of Electronics and Computer Science (ECS) at Southampton University

See also Programme and proceedings

In a highly successful workshop that attracted over 100% of the booked delegates, invited users and stakeholders in Eprints software from around the world met to consider increased sharing and communications to ensure the continued sustainability and development of Eprints, the most widely used software for creating institutional archives. This report summarises the major proposals to emerge from the workshop, and highlights areas for further investigation.

The meeting was structured with sessions on technical issues, user issues, and business and funding issues. Each session included a short presentation and extended roundtable discussion. In addition there were breakout sessions to consider technical and user issues in more detail. Each discussion was framed by the need for appropriate business models to support identified actions. The programme provides links to the formal presentations and reports from each sesssion.

As well as taking account of the formal materials, this report is based on contemporaneous notes of the discussions - for which we are grateful to Harry Mason of Southampton University and William Nixon of Glasgow University - and on subesquent feedback and comment. Thanks are also due to Philip Hunter and Bill Hubbard who acted as rapporteurs for the breakout groups and later provided notes on these sessions.

Users of Eprints are invited to continue this dialogue to bring forward actions from the workshop.

1 Major proposals

1.1 Establish new community structure led by management/steering group (see chart), with separate groups for developers (technical), repository administrators and end-users (depositors), and end-user focus groups to inform administrators

1.2 Formulate project requirements list matrix. List requirements, different user types rank each feature separately. Negotiation behind the scenes, but overall view permanently available. Concrete features. Includes time column. Prior roadmap needed.
Management: stakeholders, etc., add to project requirements list based on feedback from user groups. Project requirements list is central meeting place for developers and admins (see chart)

1.3 Set up wiki: multilingual; documentation; current development; Eprints 3. May subsume mailing lists, etc.

1.4 Set up SIGs:
SIG for language issues
Technical devlopers SIG, etc.

Issues for further investigation

2 Funding

2.1 Funding sources: OSI, JISC, research councils, HEFCE (RAE)

2.2 JISC could be involved in management group for steering/funding.
Management group to control funding
Who's on management committee? Long term developers and stakeholders; anyone who's raised money
Size: ~10

2.3 "Funding bodies will fund open source projects such as Eprints, especially where such projects have international impact"

2.4 Translation might lead to new funding sources

3 Business models

3.1 'Preferred user status' models:

3.1.1 MySQL funding model: pay to change development priority
Documentation: code/technical docs/instructions. Maybe community doc support

3.1.2 Offer paid-for priority version. Cost depends on size / configuration / ...

3.1.3 Offer users chance to pay directly for help

3.1.4 Need to increase perceived value among institutional leaders and managers to succeed with 'preferred user status' models

3.2 GNU-style funding, can pay if you choose, if institutions want to support it. Donation concealed as price of software ('shrinkwrap charge')

3.3 Require commercial license for in depth support

3.3.1 Institutions that provide commercial servcices and support for Eprints pay to use Eprints ('revenue sharing')
If users are going to pay, must have enhanced services and support

3.4 Per-feature commissions

3.5 W3C, TEI models offer 'access to knowledge' (influence?)

3.6 Do people care it's free software? "Yes!" "Would pay for premium version"
Many institutional users (e.g. Wellcome Trust) will pay and will not use unsupported open source software

3.7 c.f. DSpace has premium value-added services within MIT, not at Federation level

3.8 CG: One-off funding sporadic. Preference is MySQL model; preferred support, development influence, etc.

3.9 Stick with OSS? CG: Has to be OSS. Currently OSS Cathedral.
"More adoption if OSS. Ubiquity would get funding from HE controlling bodies. Will be embedded into academia."

4 Technical issues

4.1 Internationalisation - multi-lingual. SIG for language issues

4.2 Technical SIG

4.3 Specify platform for easier installation

4.4 'Dis-integrated' EPrints system; describe core applications and APIs to allow third-party applications; applications can be used by third-party systems with parallel reference implementation as standard. Modules developed independently

4.5 Provide support for institutional configurations.

4.6 Architecture must be documented.

4.7 c.f. DSpace Committers Group can apply code changes - five members

4.8 Future features

4.8.1 Multiple views on single archive. i.e. subsets for departments in large repository. Different style sheet and content (JP: done this, 3 lines + 2 functions)

4.8.2 Dynamic Sets: new data structure. Described by search terms etc., built both automatically and manually

4.8.3 Import/Export plugins; work with sets, eg RSS export. Plugins can be installed by dropping in dir, shared etc. Other, e.g. MP3 text to speech, subscription service

4.8.4 Web based configuration. If not, Web based, automatically parseable at least - automatic GUI tools can be written

4.9 Eprints 3

4.9.1 Better to restart: better data models, more robust, extensible, flexible.
Revision control, no modification of archived records. Get rid of archive/buffer/deletion/inbox
EP2->3 easy to export data, harder to do config. Translations must be maintained. Tool exists.

4.9.2 How best to share effort?
Code/documentation: doc easier to share than code.
Wiki to manage development.
CG: Abstracted layers of config (XML) also allow third-party automatic tools.

5 Users issues

5.1 Need new community model, forums to discuss direction; user group, steering group, different needs of users/institutions, priorities (see major proposals)

5.2 Two camps: interface design, technical structure. How to link these together?

6 Conclusions

Eprints needs 'stop gap' money. When institutional repositories (IRs) are established funding will not be a problem Institutional repositories and Eprints have a healthy future

7 Delegate list (attended)

Steve Hitchcock, 1 July 2004, updated 21 July 2004
Putting Eprints Software into the User Community supported by
JISC and - Self-Archiving and Open Archives