One thing about open source software is that it invites tinkering - an adjustment here, a little tweak there and, presto!, you've got the perfect implementation for your particular needs. Problem is, too much fiddling around can turn software from business friend to foe. John Turner, director of network and systems, has learned this lesson well in his 14 years making software decisions at Brandeis University, in Waltham, MA. In this interview with contributing writer Beth Schultz, Turner reflects on ...
John Turner, Director of Network and Systems, Brandeis University, Waltham, MA
CUSTOMIZING SOFTWARE: In the old days, we were pretty footloose and fancy free with making customizations to our software, and now we're paying the price of having to undo all those things. That's caused us to really look back and ask, 'What the heck were we thinking? Why did we go in, modify the source code, recompile and think that that was going to be a great thing down the line when there are 50,000 tickets in a trouble-ticket system that can't be updated?' Now we know to either make changes and contribute back to the source or stick with the plain vanilla.
BEING A GOOD OPEN SOURCE CITIZEN: A lot of times, we took open source software, used it, saw opportunities to make some changes but never contributed those changes back upstream. Later on down the line, there have been updates to the software and they're incompatible with the changes that we've made. If we contributed our changes back to the community, we'd be fairly well-assured that when an update comes out we wouldn't be out of line or incompatible.
TAKING THE HARD LINE: We do not modify software at all now. We do a vanilla install or find something else that works better. In some cases, we've actually turned to paid software, and we found a lot of times that the cost is not as great as we had expected, especially if you look at long-term development efforts.
MOVING FROM OPEN SOURCE TO COMMERCIAL SOFTWARE: For our monitoring software, we were using NetSaint, which was a great product but never got a lot of good development effort on the configuration side and became impossible to maintain. So we looked at what we could do. We could write something, but we knew that was the wrong thing to do because we're not code developers, we're a university. So we decided to go with Hyperic which is a commercially supported piece of software.
BEING HELD HOSTAGE BY SOFTWARE: We were on an unsupported version of our mailing list software, an open source product called Sympa, and that's caused us a lot of upgrade issues and nightmares. We were held hostage by the changes we made to Sympa.
BEING BLINDSIDED BY SOFTWARE: When we customized software, maybe we did it with some naiveté and perhaps we underestimated the importance of a piece of software - but you never know how ingrained something will become in your organization. A great example is our use of software from ArsDigita, an MIT spinoff. ArsDigita was the Facebook of its day in many ways, and we thought the company would be around forever, but it disappeared in the dot-bomb era.
LIVING A SOCIAL NETWORKING NIGHTMARE: We built a huge online community around the ArsDigita Community System, and did a lot of customization. ACS has become one of institution's more important pieces of software -- it does forums on campus, handles polling, votes, events, and all sorts of fun things. But, we're running a version that's unsupportable. There's no way for us to upgrade because it's been so heavily customized--it's no longer ACS, it's now Brandeis' code base of ACS. Even now, we have no idea what we're going to do with this. Every time we look at it we just shudder and turn away. It's actually required us to maintain staff that has programming skills or, because it's programmed in an obscure language, to teach new staff old programming skills. It's the only thing on campus that's like it, and it's incredibly important for the university on a day-to-day basis. There'd be a lot of pain if this disappeared. We felt like we were developing in a toolset that was compatible but the reality is we went too far.
What do you know now that you wish you'd known then? Share your tales here or contact Beth Schultz, at firstname.lastname@example.org.