SPEC Kit 340: Open Source Software · 45
inexperienced staff member. In-house modifications to the OSS software can make this more challenging. The strategy
for overcoming this challenge is to make extensive comments within the changed coding.
Gap in web design skills. Had to use existing resources. Difficult to organize functional teams to create requirements or
user-stories. Developers filled gaps. Lack of a mature service model to offer support.
Having the skill sets to support the product over the long term. Having a voice in governance within the open source
community. Software bugs with little or no support to fix issues. To overcome, we try to purchase vendor/3rd party
support.
Highly skilled in-house staff required in lieu of vendor support. Deep customizations can create a local fork that is hard
to upgrade for a new upstream release. The power to customize is addicting. Sometimes it’s better to adjust the local
workflow to fit a 90% good enough tool than to spend time building that last 10%.
Immature technology: chose only established and mainstream product. Lack of support: chose only product with
available paid support. Lack of control on product and feature direction.
Increased deployment time for unfamiliar products: admins must spend more time learning software upfront. Users
expect sys admins to be source of expertise for deployed products: have to educate users about becoming self-servant
with available documentation and knowledge bases. Alignment of local project timelines with those of OSS products.
Initial hardware needs: repurposed hardware from other project. Reliance on locally developed expertise: limit the
amount of customization.
Institutional IT department has had difficulty supporting large data, bandwidth, and open source philosophy in general.
Core system needed considerable development beyond basic functions. Version updates not always scheduled or based
on an upgrade path. Poor implementation and documentation.
It still creates IT debt that we need to manage. The communities are not big enough to always add value. We have a
greater need for technical documentation when we release an OSS software.
Keeping up with software updates. Training overhead for new staff.
Lack of documentation: communication on listservs and forums.
Lack of documentation and support can slow adoption. Sustainability problems can lead to abandoned projects.
Skepticism on part of non-technical stakeholders.
Lack of necessary elements: have developed our own or contributed to community work to do same. Lack of
documentation.
Lack of staffing: we haven’t really resolved this. Lack of training in specific areas: fortunately our location between
two large metropolitan areas has made this fairly easy to obtain. Lack of policies and procedures for OSS: we have
established a work team and are starting to address this.
Learning curve. Staff time. Server capacity.
Learning curve: overcome by online training resources. Recovering from patches to customized software: overcome by
before/after detailed checklists. Training and maintenance: overcome by building in new routine tasks for maintenance
and cutting back on other services.
Maintain thorough documentation of local implementation &customization decisions. Failsafe upgrades: need to make
sure locally developed plugins, etc. don’t crash with each new upgrade. Maintain sandbox environment to thoroughly
test upgrades before pushing to production. Version control of development vs. production servers.
inexperienced staff member. In-house modifications to the OSS software can make this more challenging. The strategy
for overcoming this challenge is to make extensive comments within the changed coding.
Gap in web design skills. Had to use existing resources. Difficult to organize functional teams to create requirements or
user-stories. Developers filled gaps. Lack of a mature service model to offer support.
Having the skill sets to support the product over the long term. Having a voice in governance within the open source
community. Software bugs with little or no support to fix issues. To overcome, we try to purchase vendor/3rd party
support.
Highly skilled in-house staff required in lieu of vendor support. Deep customizations can create a local fork that is hard
to upgrade for a new upstream release. The power to customize is addicting. Sometimes it’s better to adjust the local
workflow to fit a 90% good enough tool than to spend time building that last 10%.
Immature technology: chose only established and mainstream product. Lack of support: chose only product with
available paid support. Lack of control on product and feature direction.
Increased deployment time for unfamiliar products: admins must spend more time learning software upfront. Users
expect sys admins to be source of expertise for deployed products: have to educate users about becoming self-servant
with available documentation and knowledge bases. Alignment of local project timelines with those of OSS products.
Initial hardware needs: repurposed hardware from other project. Reliance on locally developed expertise: limit the
amount of customization.
Institutional IT department has had difficulty supporting large data, bandwidth, and open source philosophy in general.
Core system needed considerable development beyond basic functions. Version updates not always scheduled or based
on an upgrade path. Poor implementation and documentation.
It still creates IT debt that we need to manage. The communities are not big enough to always add value. We have a
greater need for technical documentation when we release an OSS software.
Keeping up with software updates. Training overhead for new staff.
Lack of documentation: communication on listservs and forums.
Lack of documentation and support can slow adoption. Sustainability problems can lead to abandoned projects.
Skepticism on part of non-technical stakeholders.
Lack of necessary elements: have developed our own or contributed to community work to do same. Lack of
documentation.
Lack of staffing: we haven’t really resolved this. Lack of training in specific areas: fortunately our location between
two large metropolitan areas has made this fairly easy to obtain. Lack of policies and procedures for OSS: we have
established a work team and are starting to address this.
Learning curve. Staff time. Server capacity.
Learning curve: overcome by online training resources. Recovering from patches to customized software: overcome by
before/after detailed checklists. Training and maintenance: overcome by building in new routine tasks for maintenance
and cutting back on other services.
Maintain thorough documentation of local implementation &customization decisions. Failsafe upgrades: need to make
sure locally developed plugins, etc. don’t crash with each new upgrade. Maintain sandbox environment to thoroughly
test upgrades before pushing to production. Version control of development vs. production servers.
