[Dspace-general] Scope of DSpace (Was: Dublin Core Registry question)

[Murray Altheim]

Tansley, Robert wrote:
> Hi Murray,
> 
>>One question that is sometimes not asked about a project: when does
>>one declare it completed? It's possible to continue to add features
>>ad infinitum, and as with many software projects -- particularly open
>>source ones managed by many -- they bloat out way beyond their initial
>>requirements. Is there some sense of a completion schedule for DSPace,
>>or is it expected to continually enlarge its code base until it has
>>passed into the great software heaven in the sky (where all the good
>>software goes), or does it finally end up in software hell, after
>>that one wafer thin line of code too many?
>>
>>It would seem that there would reach a point of diminishing returns
>>regarding features, when consolidation, documentation, and reaching
>>a point of code stability might be in order. Is there some point in
>>mind for DSpace?
> 
> Great questions.  In fact it touches on a theme I'm hoping to cover and
> start discussion around in presentations I'm giving at the DSpace user
> group meeting in Sydney next week.

Sad I won't have a chance to be there. Hopefully any papers or
transcripts will be posted and announced to this list (hint: that
would be valuable and appreciated).

> It's true that DSpace can't simply keep growing in all directions,
> encompassing thousands of features.  However, I don't think we yet know
> enough about exactly what we need out of systems like DSpace.  That was
> one of the reasons for releasing it as open source in the first place:
> the idea was to get something out there, and let the community mould it
> to its emerging needs, rather than to try and decide a priori/in
> isolation what was needed.

Certainly -- the field is very new and as far as I'm concerned, this
will likely be among the hottest areas for IT development for the
next decade. We live in a world of disordered information, and don't
often have ready and convenient access to digital content online, at
least the kinds of content that we'll increasingly be seeing in what
we're now calling digital libraries.

The software that provides us with the foundation for our research
into the field and into how we can better serve peoples' needs will
certainly change over time, likely very rapidly.

> The questions "what should DSpace be?  What should it do?  What
> shouldn't it do?  How should it fit in with other
> systems/technologies/servces?" are interesting questions in their own
> right, as interesting to me as research questions as many of the more
> technical decisions made when developing the system.  DSpace clearly
> can't be all things to all people, so we need to decide where it sits in
> the ecosystem of tools, technologies and services out there in this
> space.  However this should be a conclusion arrived at by the community
> as a whole -- HP (and I believe MIT) don't believe it's our place or
> would be the best approach to dictate this to everyone else.  It's
> precisely this uncertainty in exactly what's required and possible in
> terms of technologies and services that makes DSpace such an interesting
> project and why open source is the right vehicle for it.

Rather than trying to make decisions, or suggest decisions be made by
the DSpace community, might I suggest a path? Modularization. As much
as is reasonable, DSpace features should be modularized, so that there
is a core DSpace engine, with almost all services plug-and-play. In
this way it permits the community to deliberately fragment into
interest areas, building the modular tools the subcommunities are
interested in, and allowing implementors to create installations that
suit their needs without overburdening them with an enormously complex
base package. E.g., so if somebody doesn't need OAI features, or they
want a local system rather than an online one, they choose the modules
they need (or there is an install system to permit them to do so easily).

I realize this takes a higher level architectural approach, one that is
sometimes difficult in a rather amorphous, fast-moving development like
DSpace. And I confess -- there might already be modularization efforts
going on in DSpace that I'm not aware of -- I haven't spent much time
with the code myself.

> Until now, the majority of work on DSpace has been in the area of user
> interface functionality.  I think that's been for two reasons:
> 
> - UI changes are easy to demonstrate and show to those holding the purse
> strings
> 
> - For the majority, it seems the most immediate problem is how to get
> actual content into their repositories, and additional features that
> give faculty members utility and demonstrate increased impact of their
> work are a way to entice them.

In my own work (which is currently somewhere around 150K linesof Java
code), I'd say that the majority of my time has been spent in similar
fashion. Anyone who's done UI work would attest to it being as close to
hell as one can get in software development. Tedious work. But it's
where the rubber meets the road, if one's users are the rubber or the
road (some of these metaphors have limited usefulness).

> Moving forward, we definitely need some consolidation, documentation and
> so forth.  This has been the hardest thing to get wider community
> involvement in: it seems people like creating new features, but don't
> like the attendant bug fixing, QA, documentation and other 'weeding'
> tasks (and/or they perceive this as the committer group's task.)

Well, this is true in professional corporate environments too. Everyone
wants to be an architect and designer; nobody wants to sit in the back
room and do QA, fixing other people's bugs. And a good documentation
person is like finding a good bass player. Everybody wants to wear
spandex and stand at the front of the stage playing guitar. We all know
who Pete Townsend and Keith Richards are, but how many have heard of
John Entwhistle or Bill Wyman? The latter two are QA guys. The trick is
to locate people who like standing in the back and providing the
foundation. They're hard to find, but HP and MIT might be able to help
here, dunno.

>  So, what I've been trying to push for moving forward is:
> 
> - More community involvement in the 'weeding'
> 
> - Decoupling parts of the system (modularising) so that complexity can
> be contained.  I envisage DSpace having a core set of functionality,
> with a rich selection of add-ons, many of which might not be required by
> everyone

I should have read ahead. I see we agree...

> - Trying to start conversations about this very topic!

Glad to be of any help in that regard.

> As for DSpace being 'complete', actually I hope that will never happen
> :-)  Software is like biology, in that there is a common word used to
> describe a completely stable object: "Dead".

I agree, but death can also happen when the lake fills up with
algae. Modularization is one good solution to that, and I'm happy
to see you mention it. Any on this list who might know me know
I've long been a big fan of modularization.

Robert, thanks very much. In looking across the DL space right
now things are changing fast, and DSpace is poised to inhabit
a great niche within that, particularly if the package is flexible
enough to be used in varying applications. I look forward to watching
things grow, and as I'm able in the future to participate in design
and coding. And yes, I've played both guitar and bass before.

Murray

......................................................................
Murray Altheim                          http://www.altheim.com/murray/
Strategic Systems Development Manager
The Open University Library and Learning Resources Centre
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

     Short of taking the current president of the United States
     by the scruff of the neck and dunking his head deep into the
     rapidly melting Arctic ice cap, what more did the Earth need
     to do to make someone listen to its cry for help?
                                -- Simon Schama, The Story So Far
     http://www.guardian.co.uk/g2/story/0,3604,1675173,00.html