What I've Learned About Open Source Software

Open source software requires a little tinkering, but too much fiddling creates headaches

By Beth Schultz , ITworld |  Open Source, lessons learned, open source Add a new comment

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
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 bschultz5824@gmail.com.

ITworld LIVE

Open SourceWhite Papers & Webcasts

White Paper

CIO Quickpulse: Drivers for Enterprise Virtualization Diversification

Open source is a key driving force as organizations consider second-vendor virtualization adoption to attain more diversity, data center power and agility.

White Paper

Consolidating SAP Applications to Linux on Power by IDC

IDC studied a group of enterprises that had deployed SAP applications on IBM Power Systems servers running Linux server operating environments and had been working with those systems for several years. Learn about the results...

White Paper

An Interactive eGuide: Open Source

By now, enterprises are well aware of the benefits of open-source software, which boasts a clean design, reliability, and maintainability, as well as support for standards and community values. But perhaps the biggest benefit is quality; since open-source software users have access to source code, bug fixes and enhancements come from multiple sources, often resulting in superior software.

See more White Papers | Webcasts

Ask a question

Ask a Question