Potential TODOs awaiting proposals

Student summer or co-op projects

This wiki page contains project ideas and resources for students and mentors. Candidates who start a project with skills matching the Requires field will be able to be productive on a given project faster and will probably accomplish more over the course of the project, but project mentors are willing to help you develop those skills (particularly understanding of OpenSRF and Evergreen) if you don't already have them.

Don't feel constrained by this list - if you have other project ideas, feel free to let us know on the mailing list.

Suggested Projects (in no particular order)

Port OpenSRF to the GNU Build System
  • Benefits: Simplifies the install process and improves portability
  • Requires: Experience with the GNU Build System
  • Explanation: The current install process is a home-grown process using Make and some local install scripts. Replacing this with the GNU build tools will create a more formalized and well-understood install and configure process.
Create Configuration file editor / generator
  • Benefits: Simplifies install process
  • Requires: Understanding of the OpenSRF and Evergreen configuration files
  • Explanation: Currently, Evergreen and OpenSRF and their dependencies use a number of configuration files in different locations on the system. This complicates the install process. A single interface for entering settings and having those settings propagate to the various configuration files would improve the install process.
Create one or more system packages for different flavors of Linux
  • Benefits: Makes it possible to install OpenSRF and/or Evergreen using the standard package management tools for one or more Linux distributions.
  • Requires: The ability to create and test packages in at least one format, or the ability to learn this skill. Learning to create packages will probably take most people a week for the basics, two weeks for more complex packages. Some basic scripting knowledge would help with creating reasonable default configuration files at install time.
  • Expalanation: The current install process requires system administrators to install a mix of native system packages, Perl and Python modules, and locally compiled code. Native system package formats such as .rpm (Fedora, Red Hat, SuSE, etc), .deb (Debian, Ubuntu), and ebuilds (Gentoo) removes most of the steps involved in the current install process by ensuring that all package dependencies are installed and by automating much of the system-dependent configuration. To successfully complete this project, you may be required to create system packages for the external dependencies that do not currently have system packages available on a given distribution (for example, Perl and Python modules). This is a good thing - it should offer a gentle introduction to system packaging before tackling OpenSRF as a single package, and you might have the opportunity to become a maintainer of that package for that distribution.
Improve Platform Independence
  • Benefits: Encourages the spread of Evergreen by broadening the set of operating systems the software will run on.
  • Requires: Understanding of the Evergreen installation process and understanding of the development tools available on the destination platform.
  • Explanation: Currently, Linux is the only widely deployed operating system in use with Evergreen. We would like to broaden the scope to include FreeBSD, OpenSolaris, and possibly OS X. Though a full port to Windows is outside the scope of this project, porting a subset of the software to Windows given appropriate Windows expertise is also an option.
Log Analysis Tools
  • Benefits: Allows for easier reporting and troubleshooting
  • Requires: Understanding of Evergreen log file output and layout as well as a firm grasp on Unix utilities (e.g. grep, cut, etc.)
  • Explanation: Most log parsing is done by hand with ad-hoc scripts. A simple user interface (web or shell-based) to analyze certain transaction and error information in the logs would be a great benefit to administrators who don't wish to build local custom scripts
Development of more explicit error messages and error handling / defensive programming
  • Benefits: The system should respond in a more expressive manner to both expected and unexpected events.
  • Requires: Understanding of Evergreen components and how they piece together in a running system.
  • Explanation: Many of the existing system messages are esoteric in nature and often only provide a small amount of information to administrators. More expressive error handling would allow for faster resolution of bugs and misconfiguration errors.
Unit tests / Unit testing framework
  • Benefits: In particular, automated unit tests will speed up the release process by allowing developers to rely on a known set of existing tests instead of building ad-hoc testing scripts or hand testing.
  • Requires: Knowledge of the tested components
  • Explanation: There are 2 general types of unit tests for Evergreen: those which test standalone components and those which test published methods. Standalone component tests have a smaller scope and are generally simpler. Published API tests stress various layers of the system and generally need to be able to accommodate a wider range of responses.
Testing/demo data generation tools
  • Benefits: Access to an automatically generated set of test data will not only allow for broader, more rigorous testing, it will allow developers to drop and re-create databases for quick development turnaround.
  • Requires: Understanding of Evergreen objects and a basic understanding of how objects interact within a relational database.
  • Explanation: In some regards, this project could be an extension of the unit testing framework. However, it serves the broader purpose of allowing users to quickly generate data for demos and a common dataset for bug verification.
Create a Migration Toolkit for Migrating from one ILS to Evergreen
  • Benefits: A common toolkit for institutions migrating from the selected ILS to Evergreen
  • Requires: Knowledge of the export processes from the selected ILS, import and policy definition processes for Evergreen.
  • Explanation: All ILSs are different in crucial ways with respect to how the store and export bibliographic, transaction, and policy information. Creating a toolkit for a single ILS will not only provide institutions that use that ILS a migration toolkit, it could be used as the basis for a broader set of migration toolkits.
Create a Ruby/PHP OpenSRF Client Library
  • Benefits: Additional OpenSRF libraries will allow for easier development of ILS plugins for existing and future Ruby/PHP applications. It also opens the door the general OpenSRF development from the Ruby and PHP communities.
  • Requires: Understanding of OpenSRF
  • Explanation: OpenSRF currently has client libraries in Perl, C, and Python. New libraries generally broaden the scope of OpenSRF, which makes it more applicable in more places, even where Evergreen is not in use.
Create Plugins or Integration Toolkits for Third-party Patron Interfaces (a.k.a. OPACs)
  • Benefits: Current users of a given system will have the ability to migrate to Evergreen without changing patron interfaces
  • Requires: Understanding of how to access the needed data in Evergreen as well as how to integrate with the chosen interface.
  • Explanation: Third party OPACs including VuFind, Scriblio, Blacklight, etc., offer enhanced search and discovery interfaces for library patrons and typically offer some level of “plug and play” infrastructure. Writing a plugin for a particular interface would allow all Evergreen users to take advantage of the interface.


  • Dan Scott: denials at gmail.com
  • Sally Murphy: error23 at gmail.com
  • Mike Rylander: mrylander at gmail.com
  • Bill Erickson: billserickson at gmail.com


Development Proposals under discussion

Easing user installation, deployment and maintenance; or Getting FIT

  • it's long, so see it here

OpenSRF over HTTP in JavaScript

  • Give browsers the ability to use most of the advanced features of OpenSRF, like stateful sessions and streaming responses. Read the proposal here.
  • update A Python implementation of the HTTP translator has been developed as well as the OpenSRF Javascript library which takes advantage of the gateway. After the Python gateway is given a good workout, porting it to C will be the next step.

Other projects

Academic Reserves

Installation (server)

probably to become the Build/Package/Deploy proposal pending from miker

  • “Gentoo ebuild, RPM, and Debian .deb files for installing Evergreen.”

Notification System

Patron Records

Patron Self-registration

  • Anticipated to be long, so Look here!
  • mentioned on #OpenILS-Evergreen by Stompro, 7/20/07
  • 11/3/2010 - this feature is mentioned on the evergreen 2.0 features list. Says backend part is done.

Self serve password reset

Simple Self Check Client

Telephone Notification

development_proposals.txt · Last modified: 2011/03/14 14:33 by dbs
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Debian Driven by DokuWiki

© 2008-2013 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a member of Software Freedom Conservancy.