Just two cents, maybe even a single cent: at the point where you're writing
follow-up contracts to maintain or extend software written for contract,
you should probably look into hiring someone. This is a symptom of a lack
of investment in things you need.
On Fri, Aug 15, 2014 at 11:49 AM, BWS Johnson <[log in to unmask]>
> > 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
> > 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.