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.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.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.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.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.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.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.2 Two camps: interface design, technical structure. How to link these together?