Salvete!
> My first thought was a project-based contract, too. But there are few > programmer projects that would require zero maintenance once finished. As > someone who has had to pick up projects "completed" by others, there > are > always bugs, gaps in documentation, and difficult upgrade paths. There could be follow up contracts for those problems, or they might be less of a hassle for in house staff to handle than trying to do absolutely errything from scratch. > > So I have no solutions to offer. Enticing people with telework is a good > idea. It's disappointing to see libraries (and higher ed more generally) > continuing to not invest in software development. We need developers. If we > cannot find the money for them, perhaps we should re-evaluate our > (budgetary?) priorities. > Anytime I see things which I think more than one Library would like to have I think "Caw, innit that what a Consortium is for?" One member alone might not be able to afford a swank techie, but perhaps pooling resources across Libraries would let you hire someone at an attractive salary for the long haul while getting all of the members' projects knocked out. It would also mean that you don't have to do any of those nasty follow up contracts since the person that made it would still be about. Cheers, Brooke
