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:[email protected]] On Behalf Of
> Eric Lease Morgan
> Sent: Friday, September 03, 2010 11:40 PM
> To: [email protected]
> 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