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

[Christophe Dupriez]

Dear Michele (copy to the community),

May be I am basically wrong seing DSpace as a community of practice 
making a tool to promote the dissemination of the "good" Open 
Repositories practices.
If I understand correctly your plans, DSpace is primarly a community of 
developpers where users requirements are tackled inside individual 
institutions and "mostly technical" problems are shared outside. I am 
sorry that my "dream" is different but I will play the "real game" ! I 
will follow the Claudia Juergen's advice: "Small contributions are 
beautiful".

To be constructive and pragmatic, my main technical challenge remains: 
adding "thesaurus based" query expansion to DSpace to be able to mimic 
PubMed searches exhaustivity and precision in DSpace (we now have 75 
thousands documents in our internal repository. MeSH is 30 thousands 
subjects headings). I will keep focused on this.

Have a nice day!

Christophe

Michele Kimpton a écrit :
> Dear Christophe and DSpace community,
>
> One of the main projects the Foundation ( not federation, and I point 
> this out as they are completely different) has taken on is to put 
> together a team from the community and get funding for DSpace 2.0.  
> The work to be done will involve core architectural changes- under the 
> hood, so to speak- that will be somewhat transparent to many end 
> users.  However, these changes will have large implications down the 
> road, in a good way, for the community at large.
>
> One of the complaints is to be able to easily change the UI, or create 
> multiple UI's,  Web 2.0 interactions,ect., is due to the fact the code 
> is not modular ( as Tim points out). One of the main goals of 2.0 is 
> to make it more modular so organizations can "plug and play", meaning 
> choose the interface(s) they prefer.  It also allows many more 
> developers to participate in the process- as their contributions can 
> be rolled into the releases much more easily, given the code will not 
> have complex interdependencies with the rest of the core code ( we hope).
>
> If we are successful in putting together a modular architecture- than 
> we can have multiple UI's, asset stores, workflows ect.  As there are 
> no dedicated developers within the community or the Foundation working 
> full time on DSpace- it is important to empower the community to be 
> able to contribute code that fits their organizational needs- and 
> therefore we must put an architecture in place that supports this 
> process.  We hope to start the work for DSpace 2.0 this winter.
>
> Once 2.0 is in place we can start a process where users can assess 
> user needs and feature requests(developers can do this now on source 
> forge) but realize the work to develop those features will still need 
> to be done within the community, and maybe the community will be 
> willing to pay for development time to make it happen collaboratively, 
> but that remains to be seen.  I plan on hiring a Technology Director 
> within the Foundation to help lead this process(2.0 and beyond).  We 
> have secured some of the funding and developer time to do the work 
> required.  I hope to secure the remaining funding needed over the next 
> few months.  If anyone in the community would like to help me in this 
> process( getting funding, donating developer time, volunteering I 
> welcome your help.
>
>
> sincerely,
> Michele
> DSpace Foundation Director
> On Nov 15, 2007, at 3:09 AM, Christophe Dupriez wrote:
>
>> Hi Tim, (copy to Michele, Dorothea and the Tech list)
>>
>> Thanks for your views and congratulations for your work with IDEALS.
>>
>> Just to be sure to be well understood: I am not in any way proposing 
>> to disturb developpers, I am speaking about organising USERS so they 
>> express their needs, build concensus and propose developers to build 
>> prototypes they can evaluate. I am also proposing to organize better 
>> the commitment process to improve consistency and reliability. This 
>> will ask for inter-institutional efforts so I also propose 
>> institutions to finance parts of those processes. This is the key of 
>> adequation and perenity.
>>
>> I am not saying nothing of this is done now, I am just proposing this 
>> to be improved under the drive of the Federation.
>>
>> Wishing you and all a very nice day!
>>
>> Christophe Dupriez
>>
>> Tim Donohue a écrit :
>>> All,
>>>
>>> As a Committer, I'm going to go ahead and step out on limb here, and 
>>> admit that I agree with most of what has been put forth by both 
>>> Dorothea and Christophe.  That being said, I'm not claiming to speak 
>>> on behalf of all the Committers :)
>>>
>>> I would *love* a more beautified DSpace...a clean, "flashy", web-2.0 
>>> interface, a modular system that is easy to extend via 
>>> plugins/add-ons, an *easy* way to share/install those 
>>> plugins/add-ons between institutions, and an *easy* way to upgrade 
>>> core DSpace (without merge nightmares between your local 
>>> hacks/customizations and the features of the new version).
>>>
>>> I'm also in full support of working towards better needs assessment. 
>>> But, at the same time, a part of me feels that different 
>>> institutions will have some different needs based on how they are 
>>> using of DSpace. So, in the end, allowing for easy 
>>> extensions/modules, and easy sharing of these community-developed 
>>> features is a great way to go.
>>>
>>> That being said, I'd like to mention just a few things to look 
>>> forward to with 1.5 and beyond:
>>>
>>> 1) I believe there will be vast strides to beautifying DSpace UI, 
>>> once we all get our hands on Manakin in 1.5 (many thanks to Scott P 
>>> & all at Texas A&M).  The modularity within Manakin should also 
>>> allow us to all develop new an interesting Themes & Aspects, which 
>>> should be much more shareable amongst institutions. (But, we also 
>>> need to find a place to actually post these for sharing!)
>>>
>>> 2) I believe that our move towards the Maven build system (thanks to 
>>> Mark D) with 1.5 will be a huge step in the right direction for 
>>> better modularity within DSpace, and better separation between the 
>>> core API and various Interfaces (Manakin, JSP, OAI-PMH, LNI, etc.).  
>>> There are still a few kinks here, but we're learning quickly and 
>>> attempting to make things easier to manage as separate modules (and 
>>> also easier to upgrade!).  The goal here is to hopefully help allow 
>>> community-developed customizatins/add-ons to flourish and not be a 
>>> continual pain in managing/updating.  In addition, we want to make 
>>> them more easily shareable between institutions (i.e. without the 
>>> pain of merging local code, etc.).  I'm not claiming this will all 
>>> be figured out or 100% perfect in 1.5...but, it is a goal I'm hoping 
>>> we can get to by 1.6 or 2.0 (or whatever comes after 1.5).
>>>
>>> As a Committer, I also feel obligated to mention that the Committers 
>>> are  all volunteers.  We are working hard to make DSpace better for 
>>> all of us, but there's only so much we can do (and largely our 
>>> development work is defined by our the individual interests of the 
>>> institutions which pay our salaries).  Therefore, DSpace is still 
>>> dependent on new features/ideas/functionality being proposed & 
>>> developed/prototyped by an active user community.  The Committers 
>>> may be able to step in and help out (when their institutions allow), 
>>> but I believe an active community is still necessary.  Remember, the 
>>> Committers are often just highly-active community members!  Case in 
>>> point: I was only asked to become a Committer after my giving back 
>>> to the community (in the form of DSpace tutorials and Q&A on 
>>> listservs), as well as the large amount of work in designing, 
>>> re-designing & developing the Configurable Submission (which my 
>>> institution allowed me the opportunity to take on).
>>>
>>> I'm really glad to see these discussions taking place!  It means we 
>>> do have people in the community who care strongly about DSpace and 
>>> are willing to share their opinions and suggestions for moving 
>>> forward.  I encourage you to continue to help drive DSpace in the 
>>> right direction!
>>>
>>> Ok...that's my diatribe or rather long $0.02 :)
>>>
>>> - Tim
>>>
>>>
>>> Christophe Dupriez wrote:
>>>> Hi !
>>>>
>>>> At PoisonCentre.be, we use DSpace for scientific (medical) 
>>>> information collection, organisation and internal re-publication, 
>>>> e.g. Knowledge sharing (not ETDs)!
>>>>
>>>> I find rather funny that this discussion occurs in the technical 
>>>> thread and not the general one.
>>>> The technicities are the reasons we meet, the subjects vary!
>>>>
>>>> I share most of Dorothea opinions.
>>>>
>>>> I strongly support the creation of a DSpace group for user needs 
>>>> assesment.
>>>> The output of this group should be:
>>>> 1) use cases,
>>>> 2) value of thoses use cases for the institutions we represent,
>>>> 3) essential "user side" characteristics of the corresponding 
>>>> functionalities those uses cases imply.
>>>>
>>>>  From there:
>>>> 1) a "designer board" could propose functionalities (no buzzwords!) 
>>>> to fulfill those needs.
>>>> 2) developpers would be invited to find "mentors" within the users 
>>>> groups and to produce a prototype.
>>>> 3) User group would then discuss prototypes results and would 
>>>> choose those that must be worked further for inclusion in DSpace 
>>>> trunk.
>>>> 4) Committers would work on "mature prototypes" (user proof) to 
>>>> make them 100% compliant to DSpace architecture and coding standards.
>>>>
>>>> IMHO, this process should be tightly driven by the Foundation and 
>>>> financed by institutions taking advantage of DSpace know how, 
>>>> technology and emulation.
>>>>
>>>> It seems to me that project IDEALS is an example of this:
>>>> https://services.ideals.uiuc.edu/wiki/bin/view/IDEALS/RequirementsProduction 
>>>>
>>>>
>>>> An example of the "users requirements" challenges we could achieve 
>>>> for DSpace:
>>>> http://www.vufind.org/
>>>> http://zoombox.gmu.edu/vufind/
>>>>
>>>> For my institution, I need now to fulfill the challenge of 
>>>> crosslinking different DSpace instances (or collections) to have 
>>>> one serve as an authority list for some fields of others (and to 
>>>> use those relations in searches).
>>>>
>>>> Have a nice day!
>>>>
>>>> Christophe Dupriez
>>>> christophe.dupriez at poisoncentre.be
>>>> dupriez at destin.be
>>>>
>>>> Dorothea Salo a écrit :
>>>>> On Nov 13, 2007 1:23 PM, Susan Teague Rector <seteague at vcu.edu> 
>>>>> wrote:
>>>>>
>>>>>
>>>>>> Our debate here is centered on future support of ETDs in DSpace. 
>>>>>> We've
>>>>>> had to do quite a bit of customization to support ETDs (thank 
>>>>>> goodness
>>>>>> for Tim Donahue's code :)! Does anyone know if there are future 
>>>>>> plans to
>>>>>> better support ETDs in DSpace?
>>>>>>
>>>>>
>>>>> With the understanding that I'm not a DSpace committer and not
>>>>> involved in any way with DSpace or the DSpace Foundation except as
>>>>> DSpace user and occasional bug or patch submitter...
>>>>>
>>>>> My sense is that DSpace development has only vaguely and loosely been
>>>>> guided by real-world use cases not arising from its inner circle of
>>>>> contributing institutions. E.g., repeated emails to the tech and dev
>>>>> lists concerning metadata-only deposits (the use case there generally
>>>>> being institutional-bibliography development), ETD management, true
>>>>> dark archiving, etc. etc. have not been answered by development
>>>>> initiatives, or often by anything but "why would you even want that?"
>>>>> incomprehension or "just hack it in like everybody else!"
>>>>> condescension.
>>>>>
>>>>> There are hacks for some of these uses, yes... but from a sysadmin's
>>>>> perspective, hacks endanger smooth upgrade paths, and from the
>>>>> perspective of many librarians, hacks are entirely out of reach
>>>>> because IT rather than the librarian controls the box DSpace lives 
>>>>> on.
>>>>>
>>>>> When innovation has occurred around DSpace, it has generally died on
>>>>> the vine because of the aforementioned threat to smooth upgrade 
>>>>> paths.
>>>>> TAPIR and Researcher Pages may serve as the requisite gruesome
>>>>> warnings here; they died not because the ideas underlying them were
>>>>> bad (they emphatically weren't! if we still had TAPIR, Susan wouldn't
>>>>> have had to ask the question she just did!), but because almost 
>>>>> nobody
>>>>> dared adopt them. I see all kinds of nifty conference presentations
>>>>> involving DSpace mods -- but they provide me no practical benefit
>>>>> whatsoever, because the code isn't out there and I probably couldn't
>>>>> use it if it were!
>>>>>
>>>>> DSpace's lack of a plugin/mod API, coupled with the amazing spaghetti
>>>>> dinner under its hood, has stifled service innovation in the
>>>>> repository space for years, and will continue to do so until the
>>>>> defect is rectified. Neither EPrints nor Fedora is in a much better
>>>>> position just now, but in all honesty, I predict that the first
>>>>> platform to *have* a half-decent mod API (especially one that 
>>>>> welcomes
>>>>> mods written in friendlier languages than Java) will experience an
>>>>> explosion of innovations that will eat the other platforms' lunch.
>>>>> Manakin assuredly helps, but not quite enough.
>>>>>
>>>>> SWORD may also help, rather backhandedly, by providing an ingest path
>>>>> that doesn't rely on the horrendous web UI or the awkward batch
>>>>> ingester. We'll see; I'm hopeful. I'd far rather build an ETD app 
>>>>> that
>>>>> used SWORD to drop ETDs into DSpace than try to hack DSpace for ETDs
>>>>> myself, much less try to push the committer group to do so.
>>>>>
>>>>> It may be worth noting at this point that I put my votes where my
>>>>> mouth is; when the DSpace development survey came out, I put a mod 
>>>>> API
>>>>> at the very top of my desiderata. I encourage other repository
>>>>> managers with unmet needs to speak up for this! It's vastly more
>>>>> important for the long-term health of DSpace and the services we are
>>>>> building around it than are (for example) controlled vocabularies.
>>>>>
>>>>> Dorothea
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------- 
>>>>
>>>> This SF.net email is sponsored by: Splunk Inc.
>>>> Still grepping through log files to find problems?  Stop.
>>>> Now Search log events and configuration files using AJAX and a 
>>>> browser.
>>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> DSpace-tech mailing list
>>>> DSpace-tech at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>>>
>>
>> <christophe.dupriez.vcf>
>
>
>
>

-------------- 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/20071116/ca5523e9/attachment.vcf