Build vs. Buy vs. Open Source CSG Fall 2003 Meeting Jon Giltner University of Colorado at Boulder

Build vs. Buy vs. Open Source Panel Questions 1. When it comes to open source, what is the primary motivator: open source as way to fill a gap in commercial offerings; open source as a way to seek independence from commercial providers; or open source as a way to justify in-house software development projects (for programmers who can't stop writing code or so that the software has any hope of external deployment).

Build vs. Buy vs. Open Source Panel Questions 2. How many in-house developers do you have? Are they dedicated developers, or are they IT generalists or support people who get tasked with developing as needed? Do you make heavy use of student programmers?

Build vs. Buy vs. Open Source Panel Questions 3. Do you have a development group that bids on (charges for) building administrative applications for other departments? 4. Have you ever outsourced development? Do you have any notable successes or failures in outsourcing?

Build vs. Buy vs. Open Source Panel Questions 5. Outside the central IT function, how many developers are there in campus departments creating applications? Is this generally encouraged or considered a problem?

Build vs. Buy vs. Open Source Panel Questions 6. Do you provide any services based on open source software that you simply would not provide if the software weren’t available as open source?

Build vs. Buy vs. Open Source Context: Boulder Campus

Build vs. Buy vs. Open Source #1 – Primary Motivator for Open Source Historically – Low Initial cost of ownership. Seen as way to quickly and cheaply get base functionality. Yes, vendor independence and/or access to source is a factor. Historically, only way for “grass roots” services to get initiated.

Build vs. Buy vs. Open Source #2 – In-house Developers Approx. 30 in-house developers, depending on criteria for counting. About 10 are explicitly staffed as full-time programmer/analysts. Many IT generalists / technical support staff programming and scripting both in-house used utilities and end-user services students tasked with development projects. Mostly utilities for internal use.

Build vs. Buy vs. Open Source #3 – For-hire In-house development of campus applications. Yes – we have a group who charges for development of applications for other departments. Typically this development is more of an integration effort, extracting and tailoring data from SIS/HR for departmental application. Still support some legacy apps developed in-house for other departments. Creates conflict of priorities between “paying customers” and internal development needs.

Build vs. Buy vs. Open Source #4 – Have we Outsourced? Nope.

Build vs. Buy vs. Open Source #5 – Other campus developers How many? –Hard to say, but a handful of high visibility development. No well established or enforced campus guidelines leads to disjoint applications using varying technologies. Deployment of Student Portal will help focus development for student services. Introduces question of how ITS supports services developed by other groups.

Build vs. Buy vs. Open Source #6 – Open source services that wouldn’t be otherwise True End-user services: none BUT: Availability of open source solutions has impacted timeliness and feature set. Most recent example: uPortal.

Build vs. Buy vs. Open Source Breakdown of Services Open Source –Mail Services: Sendmail, IMAP, Webmail –Student Portal: uPortal –Web and Web application servers – Apache/Tomcat Bought –Administrative systems –Departmental business systems –CRM –Directory Server: SunONE –Calendaring: SunONE –Contemplating: Web Access Management Built –System monitoring and reporting –Data management –Current Web-based student service suite –Ad-hoc set of both on-line and terminal-based business applications