[Dspace-general] [Dspace-tech] Development goals

[MacKenzie Smith]

Dorothea,
> I think there's an additional issue that may prove even more difficult
> to address: the problem of a technical infrastructure widely adopted
> by non-technical people.
>   
We should establish that this is actually the norm (as you point out 
later) and in every industry,
not just libraries or archives. Business managers theoretically know 
what they need, but do
not (should not) be expected to write the software to accomplish those 
goals.
> I haven't taken a look at the wiki to be sure, but my gestalt sense is
> that a substantial majority of DSpace instances live in academic
> libraries and academic-library consortia. As the general run of
> academic librarians goes, *I am highly technical*. (Tim Donohue is an
> outright anomaly.)
>   
I think you're right that the majority of DSpace adopters right now are 
in the library or
related domains. At least the visible ones. But those institutions are 
taking various
approaches to defining and managing their repository services. Some have 
one-person-to-
do-everything, and some have much more fine-grained support. As one 
example, at MIT
we have a dedicated product manager (not hands-on technical, but quite 
capable of writing
requirements and talking to developers), a dedicated developer, and a 
sysadmin to look
after the production system day-to-day. I wish I had more staff to help 
out, but this is
what we could support for the moment.

The one-person-who-does-it-all model is definitely not going to scale 
for the sorts of
DSpace applications that we're seeing. And if you look at the staffing 
models for
other production systems like ILSes or course management systems no one 
would
expect one person to deal with every aspect of them (including writing 
the software).

These are complex problems that we're just beginning to understand, so 
expect to see
plenty of dead ends and throw-away code before it's over. In other 
words, *more*
investment, not less, at this stage of the game.
> As I said, though, I'm
> atypical *on the technical high end* of librarianship. I don't think
> DSpace has ever come to terms with what that means. It's not end-user
> cluelessness that's the problem, as it is with many open-source
> packages. It's cluelessness *in the managers of the software*, which
> is a different and rather nastier problem.
>   
I will argue strenuously that service managers (or product managers, or 
program managers,
or whatever you prefer to call that role) should *not* be trying to hack 
the system.
They should be, and are, asking for changes that they think will improve 
the service
they run. But who to ask? There are two paths: ask local developers 
(MIT's case) or
ask the DSpace developer community at large. Obviously the former has a 
better chance
of actually getting done, but the latter happens sometimes.

For example, your request for an easier, less technical way to configure 
the system that
doesn't require programming skills is very reasonable, but it would take 
a developer
a lot of time to implement that, and it would be to the benefit of the 
whole community
rather than a single institutions (especially the ones that have 
developers who might
do this work, but who don't particularly need it themselves). So how to 
get that done?
You could hire a developer of your own to do it. Or talk your 
institution (or CIC)
into pooling its resources to hire a developer at the Foundation to do 
the work. etc.

> - Since discussion of DSpace development is (understandably!) heavily
> tilted toward developers and people with developer-level skills, the
> developer community has very little access to and therefore
> comprehension of rubber-meets-road requirements and procedures in
> real-world library contexts.
Also a generalization. Many DSpace developers are confronted daily with 
local service
managers that want stuff. The problem as I see it is that those product 
roadmaps aren't
being widely shared by their service managers (at least not on the 
DSpace lists) so we
don't know where they converge or differ. That's what I'd like to see 
improved, but I
wonder how much agreement there really is between institutions about the 
right way
for repository services to evolve... what you perceive as indifference 
from developers
may actually be indifference from the service managers that decide what 
those
developers should work on... so you may be arguing with the wrong people.
> - It has historically been extremely difficult for an individual at my
> level of technical savvy or below to be heard by DSpace developers.
>   
So (not to belabor the point) but could you ask Ken and Nolan to give you a
dedicated developer for a year? If repository services are a priority 
for your institution,
can you make the case that you need more resources to do what you 
believe it should?
> On the other hand,
> open-source developers are notorious for disdain of non-technical
> input and the people who provide it, and DSpace has unfortunately not
> departed from that pattern.
I know most of the DSpace developers, and they all march to some 
business need or
other, usually determined by their managers (or those who sell services 
to library managers).
But as several of the highly-visible developers have pointed out, none 
of them work for the
"DSpace community", they work for a particular university  or company or 
institute and
they usually aren't at liberty to work on whatever they like.
> - A communication and contribution path for non-technical DSpace
> managers. For the sake of everyone's sanity, it should probably be
> wholly separate from the developer community, though someone should
> have the job of summarizing useful suggestions to one of the developer
> lists (and again, I would happily volunteer). Dspace-general is not a
> good venue, because too many DSpace managers have abandoned it, or
> consider it an announcement list only.
>   
I heartily share your desire for this, and have tried repeatedly to 
create such a forum without
success. So how do we do it, and get people to use it?

MacKenzie

-- 
MacKenzie Smith
Associate Director for Technology
MIT Libraries