Print

Print


Thanks for sharing this.  A few comments on your take-aways:

    * governance - the VUFind community could use a bit more structure and the application of project management

We formed the VuFind administration group last year largely to address this issue...  but the group hasn't been very active.  I definitely think we need to make an effort at next week's conference to discuss how we can improve this situation.  We have a lot of people doing great work on VuFind, but most loyalties are (understandably and appropriately) to local institutions first and the VuFind project second.  Since I work at the university that originated the software and have more time than most to view it at the project level, I've had a disproportionate influence on where the project has gone over the past year or so.  I'm pretty happy with how things have turned out so far, but I would welcome the addition of a bit more structure if we can find a way to ensure that others are able to contribute regularly without having an undue burden placed upon them.

    * patches - member-submitted patches need to be incorporated to the code to a greater degree; a couple of us felt our contributions were not accepted

I think the "ignored patch" situation dates back to the time that the VuFind project was temporarily between developers at Villanova.  The resulting period of slow activity allowed work to pile up, and by the time the backlog was examined, the software had moved on too far for certain old patches to apply.  I feel that the situation has changed dramatically at this point -- I try to look at new patches as soon as I can, and I take the time to test patches and work with contributors to make them ready for inclusion in the trunk.  If there are still old unresolved patches that are important to people, please bring them to my attention.  I'll be happy to provide support in bringing them up to date for the latest version of the software.

I also really encourage complaining in public (i.e. on vufind-tech and vufind-general) if there are issues -- I think some of the early VuFind adopters dropped out of the public eye due to frustration with VuFind's temporary leadership vacuum.  However, things have changed a lot since then -- we have very active mailing lists, and I'm very interested in working with people to solve problems.  It helps if I know what the problems are, though!

    * authorities - a greater emphasis needs to be placed on integrating the profession's good work done in regards to named authorities

Agreed -- and something I've been working on (thanks largely to Ya'aqov Ziso, and with significant help from Ralph LeVan and members of the XC team).  I'll be presenting on our work so far at next week's conference, and additional collaborators are welcome!

    * local customizations - a possible solution to the "straying" issue may be the implementation of some sort of local code base, something Blacklight apparent has

I have been working on hooks throughout VuFind to make it easier to override or configure existing functionality without actually editing existing code: the "theme inheritance" mechanism, the record drivers, search objects, recommendations modules, even the way MARC import rules are set up.  Some of these things could probably stand to be documented better -- often the way of open source software.  I'm always open to adding new ways of customizing things in more places -- feel free to send me suggestions and requests.  I believe that Blacklight lets you create local overrides to any piece of the existing software thanks to the way the Rails environment is set up; VuFind's PHP environment isn't quite so structured, though evolution is always possible.  However, no matter how clever you get, this is a situation where there is no magic bullet -- if the base code changes too much, the override code will break.  All any project can do is try to minimize disruptive changes and to provide good hooks for customization.  Personally, I think just about the best thing anyone can do is learn to use change management software effectively -- no matter how well-designed the base software is, something like Git or Subversion will still make life easier when used appropriately.

    * "light" flavor - given the spectrum of programming skills available in libraries, some thought a VUFind "Light" may be in order

Perhaps the DEB package we've had since the 1.0 release qualifies as this -- installing it under Ubuntu is nearly a trivial process, so you can get the package up and running very quickly.  The only thing I can think of that would make this even easier would be some kind of GUI configuration tool to eliminate the need for editing ini files directly.  Not a high priority on my own to-do list right now...  but it might make a great project for some ambitious grad student somewhere.

    * repository - there is a need for a central place for the community to share local hacks, normalization routines, changes to the Solr indexer, etc.

We have a wiki (http://vufind.org/wiki/) and a JIRA instance (http://vufind.org/jira/) both open to the public...  not to mention the aforementioned mailing lists.  There should be an appropriate forum for sharing just about anything.  If you have suggestions on making this all more accessible, please share them!

Anyway, thanks again for taking the time to arrange this event -- it sounds like it was worth the effort.

- Demian

> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Eric Lease Morgan
> Sent: Friday, September 03, 2010 11:40 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] vufind user's group meeting
> 
> An inaugural VUFind "Midwest" Users Group Meeting was held at Western
> Michigan University today, and I described my experiences there in the
> (fledgling) CRRA Blog. From the last paragraph:
> 
>   In summary, the meeting was definitely a success. Discussion was
>   thorough and focused. I believe we used our time wisely, and no
>   one went away thinking it had been wasted. I do not think the
>   group was representative of the whole VUFind community. We were
>   more skilled than most. We agreed that VUFINd was not broken, but
>   we did outline a number of ways it could be improved. We all
>   agreed that the implementation of VUFind in our institutions
>   represents a giant step forward compared to where we were at
>   least a few years ago.  oss++
> 
>   http://tinyurl.com/283n4kq
> 
> Any errors in interpretation are mine and mine alone.
> 
> P.S. "Thanks folks, it was both fun and useful."
> 
> --
> Eric Lease Morgan
> University of Notre Dame