Open Source Management: Dealing With New OSS Releases

The first quarter of this year has be a busy time in open source management. JBoss has had two releases in the 7.1 series, the Apache web server has had two releases in the 2.4 series and Ruby on Rails has had two releases in the 3.2 series just to name a few. This may sound like a flurry of new releases, but is really par for the course. In the open source world releases happen all the time. Most open source projects take the release early, release often motto to heart. And for good reason too, it results in better software.

Release schedules, like everything else in software engineering, are always a trade off. The downside of rapid release cycles is that users have to deal with those releases. Dealing with any particular release is usually pretty easy, but dealing with all the releases of all your dependencies can be quite difficult. Our applications, for example, usually depend on a hundred or more individual open source components. I suspect that most projects have similar levels of open source dependency. Just keeping track of all the releases across a dependency set that large is difficult.

Just ignoring releases of the open source you depend on is a bad idea. (Though it is a pretty common approach to this issue.) Open source projects don't release just for the fun of it. When they release a new version there are usually very good reasons. Those reasons almost always include security, performance and productivity.

Security improvements

New releases of any software component are likely to include some security improvements. Open source components are no exception. Open source software is probably more secure, on the whole, than proprietary software, but that does not mean it's perfect. Most open source projects are quick to fix any security issues as soon as they are discovered. Dissemination of such fixes happen by releasing a new version of the component. If you are not using the latest release of a component, the version you are using probably has at least one known vulnerability.

Performance improvements

Open source software tends to get faster over time. Odds are that the most recent release of any open source component is faster than the one that came before it. If you are not using the newest version of a component you are missing out on that performance improvement. As we all know, speed is a feature. A very valuable feature.

Productivity improvements

Functionality improvements are easily the most common changes made to any software. Much more common than security fixes or performance improvements. This should not be surprising, developers write open source software because they want better tools. Your development teams could be writing better software and getting it done more quickly by using all the improvements being continually added to the open source you use. But only if you are staying up-to-date.

How to stay up-to-date

Now we get down to the nitty-gritty. I really wish I could tell you how to easily deal with new OSS releases, but I can't. Even here at OpenLogic staying up-to-date is a continual struggle. I do have a little bit of advice, though.

A stitch in time saves nine

Upgrade to each new release as soon as possible. It is always easier to upgrade one step at a time. If you don't stay on top of upgrading and miss a bunch of releases the upgrade process is bound to be painful. If you ever do fall behind, and you probably will, do the upgrades as soon as you notice, the problem will only get worse if you wait.

Notifcations

Find a way to get notified when new releases are shipped. Subscribe to the mailing list and create an email filter to flag release notices. Sign up for a release notification service like OpenUpdate. If the project has a blog, subscribe to it. Anything to increase the likelihood that you, or your team, will notice when a release is published.

Commit to staying up-to-date

If you are a manager make it clear to your development team(s) that you understand the importance of being up-to-date and make time in the schedule for those chores. If you are a developer educate your manager about the importance of keeping the open source you depend on up-to-date. Building a culture that values security, performance and productivity is the only way to ensure that your organization continually benefits from up-to-date open source dependencies.

Ask for advice

I said earlier that I did not have any silver bullets, but maybe you do? How does your organization deal with staying up-to-date and managing their open source? Have you tried something that works really well? Or things that failed miserably? If so I'd love to hear about it.

For the latest package versions, check out OLEX (OpenLogic Exchange), where we provide on-demand access to more than 330,000 open source packages, and over 500 of these open source packages have been certified by OpenLogic for use in the enterprise. The OpenLogic Certified Library is comprised of these certified open source packages. Every open source package included in the Certified Library is supported, indemnified, and maintained by OpenLogic.



Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.Follow @openlogic
Follow @OSCloudServices

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.