Date: Thu, 28 Mar 2024 21:51:00 -0400 (EDT)
Message-ID: <2008573728.29442.1711677060348@lyrasis1-roc-mp1>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_29441_1289492727.1711677060348"
------=_Part_29441_1289492727.1711677060348
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Tech=
nology Goals
Over the last few years, the Steering Group along with various strategic=
working groups have validated the following vision statements which descri=
be the goals of the DSpace open source product:
- DSpace will focus on the fundamentals of the modern "Institutional Repo=
sitory" use case. We are striving to meet the IR needs of the next 5-10 yea=
rs.
- DSpace will be "lean", with agility and flexibility as primary goals.=
li>
- DSpace will include a "core" set of functionality that can be "extended=
" (think plugins) or have "hooks" (integration points) to complementary ser=
vices/tools
- DSpace will be designed in such a way that it can be easily/quickly con=
figured to integrate with new & future tools/services in the larger dig=
ital scholarship "ecosystem"
- DSpace will support low-cost, hosted solutions and deployments (by feat=
uring an easy, "just works" setup)
Assumptions
It is worth being aware that several assumptions are made in the draftin=
g of this strategic plan for technology:
- We do NOT plan to rewrite DSpace from scratch, for the following reason=
s:=20
- We have a highly active (and global) development community on the exist=
ing platform. We are averaging 50+ contributors in recent major releases. W=
e also have a very active and healthy set of service providers.
- A complete rewrite would require significant funding and centralized re=
sources, neither of which are currently available. There also seem to be fe=
w (if any) grant opportunities to rebuild existing, established platforms.<=
/li>
- A complete rewrite is very risky in the open source world. While in som=
e cases it can succeed, it also can run the risk of fragmenting or fracturi=
ng a user community or developer community.
- We ARE aiming for a potentially substantial leap forward in user experi=
ence / web user interface.=20
- We've heard the feedback that neither of the two UIs (JSPUI or XMLUI) p=
rovides an optimal user or administrative experience. So, a User Interface =
rewrite or major refactoring would be "on the table".
- The below actions and goals are ambitious, but we believe they are achi=
evable provided that
- We can also achieve our Sustainability goal of increasing project reven=
ue to hire a Product Manager, and
- Institutional stakeholders are willing to commit developers to spend ti=
me working on organized development sprints under the direction of the DSpa=
ce Technical Lead to achieve the deliverables.
Based on this proposed value proposition and assumptions, the Steering G=
roup recommends the following actions corresponding to each goal:
Goal 1: DS=
pace will focus on the fundamentals of the modern "Institutional Repository=
" use case.
In November 2002, DSpace was initially announced as an out-of-the-box "i=
nstitutional repository software platform" (see DSpace 1.0 release announcement). While that=
basic goal has not changed, the common needs and use cases of an "institut=
ional repository" have changed significantly in the last decade or so. =
; Therefore, this goal is oriented towards striving to retain DSpace's nich=
e while revitalizing it to meet current and future use cases associated wit=
h the modern repository platform.
- Action 1A: Verify and validate the needs of a "modern =
institutional repository". This is instrumental in formalizing the value pr=
oposition of DSpace.
- Action 1B: Survey the community on Technology Roadmap =
/ drafted feature rankings
- Ranking of features or validation of our Technology Roadmap
- Also an opportunity to possibly gather volunteers for specific feature =
projects
- Action 1C: Identify minimum set of functionality/featu=
res for 'IR-core' and refactor codebase to provide this. This core may not =
be functional as-is, since it may require plugins that aren't extensions (e=
.g. authN)
Goal 2: DSpace will be "lean=
", with agility and flexibility as primary goals
Since its initial release in 2002, numerous features, configurations and=
options have been added to the DSpace codebase in an ongoing effort to kee=
p up with the changing needs of its user base. While many of these changes =
have helped us to achieve new use cases, in some instances they have also c=
omplicated the codebase and made setup and upgrades more complex. Therefore=
, this goal is oriented towards cleaning up (and simplifying) the codebase =
and its configuration options, while also working towards avoiding duplicat=
ion (of code and development efforts). We feel DSpace can be a "leaner" pla=
tform, which will allow the codebase to better adapt to the needs of the fu=
ture and simplify its maintenance, setup and upgrade processes.
To be "lean", the DSpace technology platform should avoid duplicativ=
e functionality except where necessary to meet use cases or achieve "f=
lexibility" goals. Where unnecessary duplicative functionality alread=
y exists, the technology team should choose a "best option" solution, or pr=
opose building a new solution when a "best option" does not exist.
- Action 2A: Converge on a single, out-of-the-box user i=
nterface (UI). DSpace will no longer be released with multiple User Interfa=
ces (JSPUI vs XMLUI). A single user interface should be developed as =
DSpace's out-of-the-box UI. Early discussions on the requirements of this s=
ingle UI (and some brainstormed candidates) are at Brainstorms on a Future UI.
- Action 2B: Converge on a single, out-of-the-box search=
/browse system. DSpace will only support Apache Solr for search/brows=
e, and the older, deprecated Lucene and DB search/browse system should be r=
emoved.
- Action 2C: Converge on a single, built-in statistical =
engine. DSpace will only support a single, built-in statistical engine (bas=
ed on Apache Solr), and support for Elastic Search statistics should remove=
d or migrated to an optional module. Support for Google Analytics will be r=
etained, as it's an optional integration with an external statistics engine=
.
- Action 2D: Develop a basic User Interface "style / lay=
out guide". In order to ensure a consistent user experience across all page=
s/features within the User Interface, we should provide basic guidelines fo=
r layout and styling of common page elements, etc. Examples may include bas=
ic guidelines for how errors/warnings/notices should be displayed, what cla=
ss(es) to use for types of buttons, etc.
Goal 3: DSpace can be "extended" (think plugins) or hav=
e "hooks" (integration points) to complementary services/tools
There will obviously be limitations to what DSpace can and should do, so=
we need to have ways to support plugins/addons/extensions to that core fun=
ctionality. Not all users of DSpace will need to achieve the same set of Us=
e Cases, so we will need to define which are "core" and which would be bett=
er implemented as plugins/extensions (either centrally supported or third-p=
arty supported).
- Action 3A: Define a family of specifications/interface=
s/tooling for 'implementation' plugins (like authN, storage, persistent ID =
services, etc).
- Action 3B: Define a family of specifications/interface=
s for functional extensions to 'core' DSpace ( working title: 'modules'), a=
nd refactor existing bundled code to conform to new model (if appropriate/c=
ost-effective).
- Action 3C: Provide infrastructure/tools for a module r=
egistry, where users can discover, and install modular extensions. Likely i=
nclude both modules maintained by committers and community contributions.=
li>
- Action 3D: Devise a flexible but rigorous system of ve=
rsioning all components (core, module, etc) where compatibility requirement=
s can be checked/enforced by the build/deploy tools.
- Action 3E: Define and expose new interfaces (in 'core'=
DSpace and possibly modules) to allow local customized code to run: 'integ=
ration points'.
- Action 3F: (Highly dependent on UI architectural work)=
Provide a user-discoverable registry/library of user interface templates (=
working title: 'themes'), that can be installed and adapted for local use.&=
nbsp;
Goal 4: DSpac=
e will be designed in such a way that it can be easily/quickly configured t=
o integrate with new & future tools/services in the larger digital scho=
larship "ecosystem"
In order to continue to play a key role in the larger digital scholarshi=
p "ecosystem", DSpace must provide ways to both share and consume data/cont=
ent from external services. We should strive to make all information in DSp=
ace "shareable", and also ease the process of adding information to DSpace =
by providing Administrators with tools to consume data from other locations=
.
DSpace should provide easy and out of the box integration with external =
services in the following areas:
Action 4A: Support ingest of complete metadata reco=
rds (items) from external services, with or without files. External service=
s may include: CrossRef, DataCite, PubMed, ORCID works, SH=
ARE, etc.
Action 4B: Provide the ability to consume external =
authority control sources to enrich specific metadata fields. Externa=
l authority control services may include: ORCID or VIVO for author/contribu=
tor data, Fundref for funder metadata, Sherpa Romeo for Publisher OA polici=
es information, etc.
Action 4C: Expose DSpace metadata and content =
to external services. Allowing pushing metadata and content to external API=
s, or allowing external services to harvest (pull) information from a DSpac=
e repository. For example, DSpace content should be made available to Eu=
ropeana, OpenAIRE, RIOXX compliant harvesters (UK), SHA=
RE
Action 4D: Expose DSpace usage data to externa=
l services.
Action 4E: Integrate with external Authenticat=
ion and Single Sign on services. Examples may include: UK Federat=
ion, OpenAthens, OpenID, Google/Facebook/Linkedin/ORCID authe=
ntication
- Action 4F: Integrate with external services providing =
identifiers (Handle, DOI, DataCite, ...)
- Action 4G: Integrate with external storage and backup =
services (DuraCloud, Amazon Glacier/S3, Arkivum, Archivem=
atica, ...)
To integrate with parallel projects and initiatives (fedora, hydra, isla=
ndora) we first need to pin down the use cases of what those integrations w=
ill bring to DSpace, or what these will bring to the other platforms. They =
currently do not fit immediately in any of these five areas.
Goal 5: DSpace will support low-cost, hosted solutions and deployments=
(by featuring an easy, "just works" setup)
DSpace should be easy to install without requiring Java development expe=
rtise, to configure without requiring server access, and to monitor from wi=
thin the application. Basic configuration options, including the look and f=
eel and selecting themes should be accessible from within the DSpace online=
administration area.
- Action 5A: Improve and simplify the installation exper=
ience for DSpace. This may include, but is not limited to...=20
- Investigate download, packaging and installation tools for Java web app=
lications to make it easier to build a working system. (What do similar sys=
tems use?)
- Examine options for lightweight installation, with most configuration t=
aking place from the web interface upon first use (see for example WordPress, etc)
- Action 5B: Improve and assist with the upgrade experie=
nce for DSpace, especially in terms of simplifying the management of local =
customizations (branding, custom themes, etc). This may include, but is not=
limited to...=20
- Investigate options to assist with upgrades (for example highlighting c=
hanges from core code or configurations)
- Action 5C: Make configuration and basic theming an eas=
ier experience for hosted or low-cost deployments by migrating most options=
to the administrative interface. Some examples include..=20
- Move configuration of basic theme configuration options (colours, logo)=
into administrative interface;
- Allow most configurations to be edited (and refreshed) from the adminis=
trative interface
- Action 5D: Ensure data is never solely stored in "tran=
sient" technologies (e.g. Solr indexes or other such indexes) where it coul=
d be accidentally corrupted or lost. All DSpace data should be stored in a =
stable, persistent data storage system (e.g. database, filesystem), and the=
n indexed from that location into tools like Solr, etc.
- Action 5E: Provide recommendations around scaling and =
load-balancing large DSpace instances.
- Action 5F: Provide administrators with additional syst=
em reporting features within the UI. Example use cases may include..=20
- Alert administrators when new upgrades are available
- Alert administrators when common system issues or misconfigurations are=
encountered (e.g. "Solr is not accessible / working", "assetstore is unava=
ilable / unattached", "space in assetstore is low");
- See A=
dmin UI - System Alerts via Admin UI for more examples.
------=_Part_29441_1289492727.1711677060348--