http://opensource.com/education/14/4/evergreen-library-system
As a systems librarian at an academic institution, I am a conduit between those who want to access the resources our library offers and my colleagues who describe the resources on behalf of researchers. I direct our limited development resources so that our systems can best meet the needs of all of our users. In their paper, Schwarz and Takhteyev claim that software freedom makes "it possible for the modifications to be done by those actors who have the best information about their value [and] are best equipped to carry them out."
Evergreen, as an open source library system, enables me to invest my time so that my work benefits not only our institution, but all other Evergreen-using institutions when I offer my local work to the project as a whole. This focus on the improvement of the project as a whole, rather than site-specific enhancements, is a broadly shared principle of our development community.
Until we adopted Evergreen in 2009, our university used a proprietary solution that only allowed limited tailoring of the HTML interface via a proprietary macro language. There was no way to improve the interface used by library workers; and while batch operations were possible (assuming you had paid for the "API" training course), there were no guarantees of data integrity for such operations. The time and effort learning to customize that proprietary system was largely wasted: there was no other context in which that expertise could be reused, and although private forums allowed sites to share customizations, the lack of open communication and standard version control infrastructure impeded the collective effort. Feature requests and bug fixes depended entirely on the limited resources of a single company.
In contrast, the ability to modify any of the source code in Evergreen—from user-facing HTML that uses Perl's robust and broadly adopted Template::Toolkit module, down to business logic buried in PostgreSQL database-level triggers—enables us to directly satisfy the needs of our users and rewards those who invest their energy in working on Evergreen with skills that are directly transferrable to other projects. For example, many newcomers to Evergreen quickly develop PostgreSQL skills with tutorials that we have shared such as Introduction to SQL for Evergreen administrators and full-text search in PostgreSQL.
The use of standard open source infrastructure such as open mailing lists, bug trackers, and git repositories enables our development community to make the most efficient use of our time. Our institution has contributed enhancements including integration with other arcane library systems (such as OpenURL resolvers), a password reset mechanism, and the publication of schema.org structured data about libraries and their resources in HTML pages for easier consumption by search engines. But we have in turn benefited many times over from other community enhancements such as support for citation management utilities, LDAP authentication, responsive web design, and accessibility enhancements.
The Evergreen project is about more than just code, however: we joined the Software Freedom Conservancy in 2011 so that a neutral third party can hold community assets such as trademarks, domain names, and funds for efforts such as our annual international conference. This organizational structure, combined with the licensing of our code under the General Public License and our documentation under the Creative Commons-Attribution-ShareAlike license, eliminates concerns that any single participant in our community can hijack our collective efforts and frees us to collaborate in mutually trusting relationships.
A major benefit of working with open source is the freedom to share the knowledge and skills that I have acquired by participating in the Evergreen community. Computer science students at our university have learned about open source community culture and tools such as bug tracking, mailing lists, and IRC through talks I have given on the Google Summer of Code program and tutorials I have led on subjects such as git and enhancing HTML5 webpages with RDFa structured data. These practical sessions (grounded in my work with Evergreen) offer a software development-oriented balance to coursework that is often more academic and abstract.
Finally, we collaborate with fellow projects such as Koha on improving Perl modules such as MARC::Record that deal with relatively arcane library standards. Open source projects are stronger because we do not view competition between projects as a zero-sum game; instead, we work with our peers to improve the foundation of our efforts for everyone.
As a systems librarian at an academic institution, I am a conduit between those who want to access the resources our library offers and my colleagues who describe the resources on behalf of researchers. I direct our limited development resources so that our systems can best meet the needs of all of our users. In their paper, Schwarz and Takhteyev claim that software freedom makes "it possible for the modifications to be done by those actors who have the best information about their value [and] are best equipped to carry them out."
Evergreen, as an open source library system, enables me to invest my time so that my work benefits not only our institution, but all other Evergreen-using institutions when I offer my local work to the project as a whole. This focus on the improvement of the project as a whole, rather than site-specific enhancements, is a broadly shared principle of our development community.
Until we adopted Evergreen in 2009, our university used a proprietary solution that only allowed limited tailoring of the HTML interface via a proprietary macro language. There was no way to improve the interface used by library workers; and while batch operations were possible (assuming you had paid for the "API" training course), there were no guarantees of data integrity for such operations. The time and effort learning to customize that proprietary system was largely wasted: there was no other context in which that expertise could be reused, and although private forums allowed sites to share customizations, the lack of open communication and standard version control infrastructure impeded the collective effort. Feature requests and bug fixes depended entirely on the limited resources of a single company.
In contrast, the ability to modify any of the source code in Evergreen—from user-facing HTML that uses Perl's robust and broadly adopted Template::Toolkit module, down to business logic buried in PostgreSQL database-level triggers—enables us to directly satisfy the needs of our users and rewards those who invest their energy in working on Evergreen with skills that are directly transferrable to other projects. For example, many newcomers to Evergreen quickly develop PostgreSQL skills with tutorials that we have shared such as Introduction to SQL for Evergreen administrators and full-text search in PostgreSQL.
The use of standard open source infrastructure such as open mailing lists, bug trackers, and git repositories enables our development community to make the most efficient use of our time. Our institution has contributed enhancements including integration with other arcane library systems (such as OpenURL resolvers), a password reset mechanism, and the publication of schema.org structured data about libraries and their resources in HTML pages for easier consumption by search engines. But we have in turn benefited many times over from other community enhancements such as support for citation management utilities, LDAP authentication, responsive web design, and accessibility enhancements.
The Evergreen project is about more than just code, however: we joined the Software Freedom Conservancy in 2011 so that a neutral third party can hold community assets such as trademarks, domain names, and funds for efforts such as our annual international conference. This organizational structure, combined with the licensing of our code under the General Public License and our documentation under the Creative Commons-Attribution-ShareAlike license, eliminates concerns that any single participant in our community can hijack our collective efforts and frees us to collaborate in mutually trusting relationships.
A major benefit of working with open source is the freedom to share the knowledge and skills that I have acquired by participating in the Evergreen community. Computer science students at our university have learned about open source community culture and tools such as bug tracking, mailing lists, and IRC through talks I have given on the Google Summer of Code program and tutorials I have led on subjects such as git and enhancing HTML5 webpages with RDFa structured data. These practical sessions (grounded in my work with Evergreen) offer a software development-oriented balance to coursework that is often more academic and abstract.
Finally, we collaborate with fellow projects such as Koha on improving Perl modules such as MARC::Record that deal with relatively arcane library standards. Open source projects are stronger because we do not view competition between projects as a zero-sum game; instead, we work with our peers to improve the foundation of our efforts for everyone.
No comments:
Post a Comment