Source code provided vs Open Source vs Free software Open Source comprises:

Transcription

1

2 Source code provided vs Open Source vs Free software Open Source comprises: Access to the source code for the project A license characteristically with: Rights The right to redistribute Source code provided Derive new system s from the software core Responsibilities Maintaining the integrity of the authors code No discrimination Distribution of the license with the code

3 Regional support Issues of scalability (very large digital repositories) Issues of security (complex multi tier security requirements) Functionality specific available in a particular product Not always an absolute choice: Open source versions vs Supported versions Open source offered via a hosted service provider Supported open source

4 All public internet systems have potential vulnerabilities, including: Cross site scripting SQL injection Javascript & other injection techniques Spoofing of various sorts Open source Code may have vulnerabilities However: it is open to immediate inspection & correction

5

6 The platform for publicising the activity of your library Giving the library control over content presentation Consolidating all services in a single portal

7 Content Management is the glue Opportunities for patron community communication and engagement: Web 2.0 Services: Wiki, Tagging News, events, activities Portal functions IFLA Website: Drupal Canberra Hospital Joomla

8 Managing your institutional repository of assets A workflow system to management asset submission in a distributed manner An archival management tool for long term management of the digital assets

9 Distributing the submission of digital assets across the organisation Workflow Consolidating and preserving your assets Asset management Asset audits Integration with OPAC DSPACE FEDORA GreenStone

10 Nice user front end & out of the box operation Java based Very widely used especially in Universities Good workflow integration & search interface Limited web services layer interfaces (API s)

11 New Zealand Digital Library Project Wide installed base Non university institutions Distributed in co operation with UNESCO Good cross platform installation capability Not as strong as Dspace in the built in end user workflow/submission

12 Flexible Extensible Digital Object and Repository Architecture Java based Characterised by a set of repository services and functions A workflow & front end also need to be added (there are open source projects for this) Fedora has a better services level layer than Dspace/Greenstone A toolkit or architecture rather than a solution

13 Internal institutional document repositories Large scale document collections for internal use Overlap with digital library Multiple approaches: Digital library software (as an intranet) Document management open source systems WinIsys database software

14 Simplifying the complexity for your end users Click through access to online database subscriptions Making the client experience easier: Shibboleth EzProxy (not Open source/freeware, but low cost)

15 A web based view into your collection Standard functionality: OPAC, cataloguing, circulation, acquisitions, serials management Should no longer be an island but a part of the whole Z39.50 for sharing resources with other parliamentary libraries Web based OPAC Web 2.0 services

16 A rich choice of options Evergreen Koha PMB WinISYS based Gnuteca. And others Where to begin?

17 The workshop framework: Open Suse Linux (Virtualised) Apache, MySQL, PERL, Zebra: Koha Workshop Focus Multi dimensional evaluation of Open Source Architecture Functionality Database design Code design Community & Support

18

19 Copy an existing language set Translate each of the pages OPAC:52 pages Staff client: 363 pages

20 Methods Hands on evaluation (download and install or online demo sites) Literature and community documentation Presentations about the software

21 A database schema evaluation will focus on several things: Richness of the scheme this is indicative of the functional depth of the system Table normalisation a series of steps to achieve a database design that allows efficient access in a relational database, minimising redundancy of data Management of bibliographic free text data

22 Language specific knowledge will yield greater insights Review degree of code documentation Review object orientation or code reuse Review flexibility for multi lingual operation

23 Look for a roadmap Look at discussion groups Look at code releases major and minor Eg Crucial: look at organisations that can provide technical support for internal or cloud based hosting

24 Stable, well understood platform: Linux, Apache, MySQL, Perl Template based language configuration allows relatively simple extension to new languages More scalable with v3.0 the use of Zebra addresses some of the major deficits in scalability Have tested with collections > 600,000 items in size

25 Variable quality of code Partially 2 tier/3 tier design. Partial separation of code from form design with templates, but not MVC design

26 When implementing any system make sure you have good support arrangements: internally or commercially

27 Building the ICT Library Service Definition, Service Plan, Needs assessment Team formation & governance Launching Internal commitment Professional development Sustainable support models Regional support serves? Hosted Services? Open source systems with strong communities/backing Koha... and DSpace

28 An online summary of open source systems relevant to libraries Reports.pl Marshal Breeding s yearly report for ALA

29 Dr Edmund Balnaves Prosentient Systems Pty Ltd 72/330 Wattle St, Ultimo NSW 2007