A very private thought but....
One thing that I think is worth remembering here is that a fair few of
the people on this list are already dedicated software professionals,
some of whom who make their living as developers on open source library
and information projects, others not. I'm not so convinced that the
missing silver bullet in innovative open source library applications is
developer time. I reckon there's already tons of it out there. The
problem isn't getting the time, the problem is coordinating it into
something that's of sufficient quality to be usable as a product we're
really proud of. I'm not sure that problem is any easier if you do it
with the current cohort of open source developers working in this area,
or a whole new resource. Indeed, it's one of those well written rules in
software that more bodes doesn't always mean more productivity. I'd also
add to this that I don't think people develop the ability to write good
solutions in this domain over night, it takes a long time to build up
the (sometimes excruciatingly subtle) experience needed.
Having worked for several LMS vendors, and often representing them on
standards groups and panels I can put my hand on my heart when I say
that LMS vendors are more than willing to devote time and energy to
forward and visionary thinking when the corporate entity thinks it's in
with a chance of owning or having a hand in the development of a
protocol or standard. It would be cynical for me to point to any current
standards bodies and their primary membership. Whilst let a hundred
flowers blossom is an age old open source (Linux poster child) approach,
you have to remember that it's always been done in the context of that
one glorious edifice, the linux kernel. That kernel evolves over time,
and it really doesn't matter if I think I have the best implementation
of lsof and someone else thinks they do, both have to be able to work
alongside each other, and one will win out over time, but the function
of the kernel never changes, and clients to that component never change.
The problem we have at the moment isn't so much developer effort as the
fact that it's incredibly hard to take any of the current best choices
for, say, catalog and acquisitions, and blend into that module say a
really good ILL implementation (And then recombine that into something
*really* innovative). The net result is that we've developed several
silo projects and it's really hard to recombine or reuse them in new
ways, here's where I suspect adding another cohort of developers might
even be destructive.
If what comes out of this new thought-experiment based resource is a set
of shared specs or understandings for all
Rubber-stamped-oss4lib-components (Lets not get into OpenRFP yet) for
the basic functions and how they relate, rather than diving into
developing even more code, then I reckon we might really be able to bang
some heads together.
Once upon a time, this community broke truly innovative ground in the
areas of data standards. If there's going to be innovation in open
source library solutions, I rather suspect it's going to be in the area
of standards again, maybe not protocols this time, but at the service
interface level, perhaps something more subtle yet, but I'm not sure
coder effort is the thing we're missing.
As I said, a very personal 2p (I can't find the cents character on my
nasty UK keyboard ;))
On Wed, 2007-11-07 at 15:03 -0500, Eric Schnell wrote:
> Adding onto George's comment...
> Google has been quite successful using this release time approach. It is
> likely that ALL of the ideas in Google Labs resulted from a 'mandate' that
> all developers use 20% of their time to work on any ideas NOT associated
> with the project they are assigned.
> For example, one individual was working on a way to 'buy Iceland.' While on
> the surface one could question the relevancy of such a 20% project, it is
> through such "not even close to a box" thinking that can result in some
> pretty cool ideas.
> So,yes. In theory, if a dozen library leaders/directors give up 20% time
> there could be some see tangible results, that in turn could be used to
> motivate other leaders to give their staff 20% time. Perhaps after seeing
> the results some leaders would be willing to give up 50% or 100% of a
> position. While this would prove be a very iterative and longitudinal
> process, it is better then where many of us are now.
> The big question is: where are the forward thinking visionary library
> leaders than are willing to step up to the plate and prime the process?
> -Eric Schnell
> -----Original Message-----
> From: oss4lib-discuss-bounces@...
> [mailto:oss4lib-discuss-bounces@...] On Behalf Of George
> Sent: Wednesday, November 07, 2007 12:52 PM
> To: OSS4Lib
> Subject: Re: [oss4lib-discuss] thought experiment
> Eric, et al,
> -- snip --
> Suppose then that, rather than attempting to get a number of library
> directors to hire, or release developers full-time to a project, they
> instead release someone for a few hours per week to work on some
> collaborative projects. Initially it would probably be much easier to
> convince people to invest a small block of developer time to Open
> Source projects. If the experiment was successful it would be much
> easier to make the "jump" to hiring, or releasing people full-time to
> develop software for the library community (the Mozilla model is an
> excellent example).
> Now, lets say that someone, and I won't mention names, at some large
> library conference, during some un-named discussion of technology -
> say maybe a discussion about the "Top Trends" was to bring this idea
> up during the forum....
> George Harmon
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> see also http://oss4lib.org/