SPEC Kit 340: Open Source Software · 65
We learned (the hard way) from our first experience with putting OSS developed elsewhere into production (about 10
years ago) that having vendor support and an active community around an OSS application are very important. With the
OSS that we have developed locally (eXtensible Catalog and IR+), we have been unable to provide either of these things
to potential users of our software, and have thus found ourselves in this same position with our own software of being
unable to sustain the software on our own. While we still strongly support OSS and continue to implement additional
OSS applications, we now make sure that vendor support and an active user community are already in place before we
proceed with deploying the software.
We take a broad view of OSS and answered based on that approach, not limiting the scope to library-specific OSS. Our
answers would be different were this more clearly defined, perhaps. Also, it suffices to say that our philosophy is simple:
open source first, vendor only when there’s no viable OS option. For example, we run our own data centre, and for that
infrastructure from operating system to virtualization platform, it is all OS there’s no VMware, Citrix, etc.
We’re transitioning from using mostly closed software to preferring mostly open software, so we’re not yet where
we want to be. We’re working out more formal policies with campus technology transfer to allow us to release GPL
software at our own discretion. We choose to use more OSS than vendor software because we have a tight budget but
a great IT staff. With much of our software support burden being internal, it doesn’t leave a lot of time to take the extra
steps to polish, release, and support OSS software. But it’s still a major goal for us.
While we use OSS, our unwritten policy is to use hosted, out-of-the-box solutions wherever possible. OSS is used to fill
in the gaps.
We learned (the hard way) from our first experience with putting OSS developed elsewhere into production (about 10
years ago) that having vendor support and an active community around an OSS application are very important. With the
OSS that we have developed locally (eXtensible Catalog and IR+), we have been unable to provide either of these things
to potential users of our software, and have thus found ourselves in this same position with our own software of being
unable to sustain the software on our own. While we still strongly support OSS and continue to implement additional
OSS applications, we now make sure that vendor support and an active user community are already in place before we
proceed with deploying the software.
We take a broad view of OSS and answered based on that approach, not limiting the scope to library-specific OSS. Our
answers would be different were this more clearly defined, perhaps. Also, it suffices to say that our philosophy is simple:
open source first, vendor only when there’s no viable OS option. For example, we run our own data centre, and for that
infrastructure from operating system to virtualization platform, it is all OS there’s no VMware, Citrix, etc.
We’re transitioning from using mostly closed software to preferring mostly open software, so we’re not yet where
we want to be. We’re working out more formal policies with campus technology transfer to allow us to release GPL
software at our own discretion. We choose to use more OSS than vendor software because we have a tight budget but
a great IT staff. With much of our software support burden being internal, it doesn’t leave a lot of time to take the extra
steps to polish, release, and support OSS software. But it’s still a major goal for us.
While we use OSS, our unwritten policy is to use hosted, out-of-the-box solutions wherever possible. OSS is used to fill
in the gaps.
