[Dspace-general] DSpace development priorities: starting a discussion

Christophe Dupriez christophe.dupriez at destin.be
Fri Aug 8 03:50:36 EDT 2008


Hi Mark H.,

Terminology:
* developers: IT specialists able to implement / modify DSpace
* users: Information Management specialists able to manage a repository
* end users: anybody able to understand documents contained in a repository

If I follow your thoughts, we should set up some kind of collaborative 
process to define what is (should be) DSpace and fuel developers with 
precise needs definitions / development ideas.

I would agree with you, but please remind:
1) developers have a very short term validation of their work (their 
local application works or not) that users do not have (you only know 
after months/years if your repository is succesfull or not).
2) developers have to formalize their thoughts in a very formal 
language. Users must formalize their projects in the language that will 
be best understood by their funding authorities or by their local 
end-users: cultural differences not always easy to share with DSpace 
community

Just to explain that the cost/benefit equation of collaboration is not 
the same for users than for developers... Some "reward" of experience 
sharing must imbedded in DSpace community management.

So the question, how do we set up / animate a collaborative process 
between DSpace users?

In each institution, the users create documents to request funding, 
organise projects, define tasks of co-workers. Many of those documents 
are readily available on the Web. Some even on DSpace site. One may want 
to propose a frame to organize those documents and identify "blanks" to 
be filled. For instance:
* What are the different kind of repositories (main missions)? I see (at 
least):
   1) Institutional repositories: provide a permanent storage for the 
production of an institution
   2) Subject repositories: provide reference documents on a given topic 
family, worldwide. Will need to interconnect with institutional repositories
   3) National repositories: provide a reference storage of informations 
needed to fulfill a national legal obligations. Will need to 
interconnect with other National repositories
   4) Local repositories: provide local knowledge workers with the 
reference documents they need for their daily work
   Personaly, I work on repository types 2 (WindMusic), 3(Dangerous 
Chemical Products sold in Belgium) and 4(Documents useful for 
PoisonCentre MDs)
* What are the public of those different kind of repositories? What are 
the needs of those public?
* What are the needs / missions of institutions organizing those 
repositories?
* What are the strategy and the tactics those institutions would like to 
follow to make their repositories succesfull?  
* What cross-institutional content initiaves could multiply the impact 
of DSpace initiative (for instance, integration with OCLC services and 
WorldCat) ?
* Priorities: What are their short term needs ? Longer term needs?
* What are the use cases for DSpace?
* What would be the ideal path for each use case?
* How many steps does each use case involve today (if possible)? How 
many could be if DSpace would be improved?
* What need to be developed?

Improving the "WHY" will certainly enlighten the "HOW"...

Have a nice day!

Christophe

Mark H. Wood a écrit :
> Some things to keep in mind:
>
> o  There is no commercial or employment relationship between end-users
>    and developers here.  Anybody who wants something done must
>    accomplish it either by his own (or his organization's) labor, or
>    by moral suasion -- appealing to the value of improving the
>    commons, or the good feeling that comes from having done something
>    well.
>
>    The good news is that, *because* there is no mechanism of
>    compulsion, moral suasion works tolerably well in such situaions.
>
> o  On the other hand, there is most definitely an employment
>    relationship between the developer and his own institution.  If I
>    want to work on some aspect of DSpace, I have to convince my
>    supervisor that the work will benefit the institution sufficiently
>    to account for the cost of my time.  It's difficult, but not
>    impossible, to sell intangible benefits like building up the
>    commons, but it is much easier to sell features that we need
>    ourselves.  The result is that the needs of one's own institution
>    *usually* come first.
>
> o  Just expounding a need of your institution may cause someone
>    elsewhere to realize, "hey, we could use that too -- and we have
>    the resources to build it."  So we do all need to talk about our
>    needs and wishes, even if we can't realize them ourselves.
>
> o  Code is not all there is.  If your institution can't create code,
>    could it contribute documentation or user-interface design?  Could
>    you volunteer to monitor a tracker and provide short monthly
>    postings on item turnover, or moderate a task force, or maintain a
>    most-popular-request list?
>
> o  One of the most effective ways to poison a community project is to
>    try to manage contributors as if you have some authority over them.
>    They know better.  Any community member (coder or not) who feels
>    that his contributions are unappreciated has *nothing to lose* by
>    ceasing to contribute, because the only reward for contribution is
>    already denied him.  Because the project is held in common, he can
>    still work on it for those who *do* reward him.
>
>
> And a few questions:
>
> On Thu, Aug 07, 2008 at 03:02:25PM +0200, Christophe Dupriez wrote:
>   
>> 1) Apply the 80/20 rule: Create an immediatley applicable DSpace package
>> which answers to 80% of the needs of 80% of the smaller institutions
>> which would be happy to not hire any developer (and keep their money to
>> hire a very good application manager) to have an enthusiastic result
>> **that the DSpace foundation would guarantee to sustain on the long
>> term, always providing an easy upgrade path from one version to the next**
>>     
>
> Has this not already been done?  How do we know?  What remains to be
> done in order to satisfy the 80%?
>
>   
>> 2) The sponsors should be institutions gathering to provide resources
>> (money, people, organisation skills) to obtain this result in a
>> reasonable time frame (18 months). The Foundation would coordinate this
>> committe, animate the process with a democratic "1 participating
>> institution = 1 vote" decision process
>>     
>
> Doesn't this just entrench the plutocracy?  Those lacking resources to
> support development have no vote.  Did I misunderstand?
>
>
> And some suggested reading:
>
>   _The Cathedral and the Bazaar_, by Eric S. Raymond.
>
>   An exploration of the economics, psychology, and sociology of
>   development by community.  If you want to know how to motivate
>   participants in a project like DSpace, or just understand why some
>   of them behave so oddly, this is a good place to start.
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: christophe_dupriez.vcf
Type: text/x-vcard
Size: 454 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080808/a2693bf2/attachment.vcf


More information about the Dspace-general mailing list