260 likes | 386 Views
Cross University Open-Source Collaboration. Offer rationale for open collaboration and share experiences. Goal. I will be asking questions of you throughout!. Overview of Presentation. Why open source software (OSS)? Rescomp's Environment and Experience Your Environment and Experience
E N D
Offer rationale for open collaboration and share experiences Goal I will be asking questions of you throughout!
Overview of Presentation • Why open source software (OSS)? • Rescomp's Environment and Experience • Your Environment and Experience • Moving forward • Discussion
Open vs Closed • Open • Dependent on community rather than vendor • Can customize as needed • Potentially larger support base • Closed • Vulnerable to vendor's business decisions • Staff aren't necessarily needed for modifications http://www.edtechmag.com/higher/may-june-2007/focus.html
Must we be open? • Public funding – public goods • Student staff may learn more from OSS • It's not obvious either way. • However, 'should' or 'can'...it's fun!
Observations • Residential Networks within Universities have a number of shared “problem domains”. • Not all Residential Networks have the same problem domains or resources. • Resnet provides a coordination point for those who could benefit from working together.
Example Projects • Kuali – Core systems infrastructure and apps • Sakai – Educational Collaboration • Tillikum – Housing Info Managment • NetReg – Network Access Control • VT WSUS – Windows Patch Management • And many more...how will we know what's available?!
Rescomp's Environment • Approximately 50 staff members • 8000 node network • Customer support for ~7000 residents • 30 *nix or BSD servers • 8 student staff working on software • Oversight by peer review and several career staff
Rescomp's Experience • Bugzilla – 6 years of use • TWiki – 1.5 years of use • Mailman – 1 instance for more than 6 years • PostgreSQL – several instances for most of site for 6 years • Request Tracker – in development Have not opened in-house applications but have participated in wider OSS community through various uses.
Issue Tracking • In-House • We have an integrated helpdesk that frontline support staff use. • Also a web-based computer lab issue tracker • OSS • Bugzilla – for use internally for both software and non-software requests • Request Tracker – replacement for simple Mailman lists
Bugzilla • Business Need • Issue Tracking • Procurement • Technical Challenges • Requires management of LAMP stack • Results • Met small group needs over 6 years • Awkward for non-software issues
Documentation/Collaboration • In-House • Docbook SGML wrapper • OSS • Twiki – Used for team coordination, meeting minutes, one-off issue tracking • Mailman archives for searching • Subversion hooks into Bugzilla
TWiki • Business Need • Centralized site-wide documentation • Technical Challenge • Maintenance • Performance • Results • Increased and more useful documentation • Additions through plugins were very useful
User Management • In-House • Sync scripts in cron written in perl • OSS • OpenLDAP – Used for several purposes as well as user management • Samba – Used in combination with OpenLDAP for Windows integration • Jxplorer – Manipulation of LDAP directory • PostgreSQL – Long term reliable storage of user data for use in web apps
PostgreSQL • Business Need • Storage of user information • Technical Challenge • Requires tuning • Results • Received fantastic support through community mailing lists, IRC, and documentation.
Server Management • In-House • ConfMan – Configuration management • Misc scripts in crons • OSS • Nagios – Monitoring and issue tracking with Bugzilla • FreeBSD – Our OS of choice • NFS, PAM, LDAP – Technologies we used to provide a consistent working environment
FreeBSD Operating System • Business Need • Support for windows workstations • Technical Challenges • Managing many server configurations with small part-time staff. • Results • Easily manageable lightweight server infrastructure • Great support from mailing lists and documentation
Our In-House Software • Current Applications • NAC • Helpdesk • Web-based Computer Lab Management • Hour tracking for front-line support staff • Security Case Handler
Q/A and Info Gathering • What is your environment like? • What has been your experience with OSS? • What have you written in-house?
Possible Approaches • Rewrite applications together • Release what we have and let others modify • Sanitize & Generalize • Agree on standards that allow interoperation and then divide and conquer
Challenges for Opening Up • Would require a high degree of customizations • Ontology and Business Logic specific to departmental groups, i.e. alphabet soups. • IP Conflicts with University
Will opening up work for you? • We've heard about a few environments. • We've seen some challenges and approaches. • How can we find out?
What have people tried? • Who has: • ...tried incorporating someone's work? • ...released their in-house software?
What could be next? • Community Portal - Sakai? • Standards Group - Kuali? • Sharing what we have: • Software Registry, e.g. Sourceforge • Mailing lists • BoF – Tuesday 11:30am in IR/PS
Discussion • Will Open Source work for ResNet? • Is Kuali enough? • How can we avoid “design by committee”? • What can we do now?
Evaluations • Go to “Presentation Evaluations” at: http://resnetsymposium.org/resnet2007