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

[Tansley, Robert]

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.

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.

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.

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.

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.)  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

- Trying to start conversations about this very topic!

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".

 Robert TANSLEY / HP Labs / MIT Visiting Researcher
 http://www.hpl.hp.com/personal/Robert_Tansley/