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

[Robert Tansley]

I do have a great deal of sympathy with Dorothea's original point that
most development is guided by uses cases at the larger institutions,
in fact I started a conversation on this very point in the user group
meeting closing session -- and of course there was disagreement on how
to address it or even that there was an issue at all.

It's not hard to argue that plenty of innovation and contribution has
been stillborn -- a quick look at the patch queue is enough for that.
It's tempting and easy to lay the blame solely at the doorstop of the
technology, however there are many other issues:

- Most DSpace users have immediate requirements and limited resources,
and so do the minimum to get the functionality they need.  What's
needed here is an understanding by institutions of the increased
long-term costs of maintaining local customisations compared to the
upfront investment in developing something more generally useful.
Even the most wonderfully clean and modular system would only
ameliorate this problem and not eliminate it.

- No matter what tools we put in place, the existence of
well-supported and widely adopted add-ons is a chicken-and-egg
problem.  If people daren't adopt them, no one will work on them,
which means...  Yes, we can provide central tools for this but it's
about people stepping forward and actually doing the work.  In the
case of TAPIR (and I could stand to be corrected here) everyone pretty
much left it to Richard Jones to maintain it, which was clearly never
a sustainable solution.  TAPIR is a project on SourceForge to which
I'm sure Richard would have been more than happy to allow interested
contributors access.

- Potential contributors need to start a conversation early and be
flexible.  As I've said before, a contribution to DSpace is a
conversation, not a patch file.  Often people throw contributions over
the fence when they've no more time to work on it.  Share early, share
often, have a thick skin.

- When people do start these conversations, they should get
constructive feedback, but it's no one's job to do this yet, so often
it doesn't happen.

- There's no process whereby decisions can get made in a timely
manner.  The way things are now, pretty much anyone (certainly any
committer) can 'black ball' an idea or contribution.  We clearly need
something more agile.

So the technology is moving in the right direction now; once we have a
data model flexible enough to accommodate different use cases, and a
way to manage and distribute add-ons that include new UI pages,
business logic and have access to persistent storage, we'll be in
better shape.  However, just as importantly, we will also need better
education and communication, and people with time to give others
feedback on how to generalise their work.  I particularly like Mark's
advice, which I'll leave you with:

> You should be more aggressive in participating "in the community" on
> something like this,  prod the community to get more participation, and be
> flexible about the final outcome.

Rob