How Do I Know When My Open Source Software is Outdated?

Like you, developers and architects around the world rely on open source packages every day.  But how do you know when they’re getting stale or obsolete?  Where do you look to find better, newer alternatives to the projects you’re using today?  How often should you go looking around for upgrades?  Let’s take a look at some best practices that will keep you on well-supported packages for the life of your project.  

Stale and Obsolete Packages  

Here are some ways to tell if your package is getting stale or is completely obsolete:

The bug fix train has stopped

• Whenever you look for updates on the project web site, there’s no sign of life.  No patches, bug fixes, or security updates of any kind.  No progress on support tickets.  The project mailing list is full of unanswered questions.  In other words, it’s a ghost town.

Releases are a thing of the past

• The regular cadence of major and minor releases has ceased.  The last mailing list message from the project owner is something like “I’ll try to get a release out this weekend if I can find the time.”   That was 7 months ago and there’s still no sign of it.

Committers are jumping ship

• A couple key committers have an open discussion about how some hot new project is better than the one they’re currently working on.  Shortly thereafter they disappear.  A few months go by and somebody else notices that these individuals are now committers on the other project.  The mailing list starts getting quiet, except for the project owner who refuses to steer in the new project’s direction.

The project home page says “replaced by Project X”

• It’s not uncommon for project owners and committers to rename a project when they come up with a new approach or architecture to a key problem.  It’s also unsurprising to see a new project spin out of an existing project that does essentially the same thing, but in a different way.  In this, the old project may continue while the new project gathers steam due to a better approach (or at least the promise of one).  Over time, the original project becomes abandoned as no new features are added and maintainers move away.

If you see these signs, prepare to make a switch.  If you’re lucky, others will have made the move ahead of you and paved the way with migration blog posts and articles.  You may also find data migration and testing tools to help smooth the transition.  In other cases, however, you may need to roll up your sleeves and create your own tools.  If you stick to popular projects, like the ones OpenLogic certifies, you’ll be less likely to get stuck in this situation and more likely to find help getting out if it does happen.  

Finding New Open Source  

There’s no shortage of open source projects in the world.  Popular sites like SourceForge (sf.net), github.com, code.google.com, and apache.org host thousands of open source packages.  OpenLogic tracks hundreds of thousands of packages on our free OLEX (OpenLogic Exchange) site.  All of these sites let you search for open source packages based on numerous criteria, including language and category, to make it easy to find packages that meet your needs.  They’re a very good first place to look when you have a specific need or just want to browse through projects to see if something catches your eye.  

You can also check the mailing lists and forums of the packages you already use.  Very frequently you’ll find mentions of new and related projects that can point you in the right direction.  In addition, hosting sites like github.com make it very easy to find derivative packages that have been forked from any particular package. Project dependency lists are also an excellent way to learn about new projects.  Finally, look up the owners and key committers on projects you find interesting.  Their bios will often point you toward more new projects that they participate in and find interesting.  

To summarize, it’s extremely easy to find interesting and popular new open source projects.  Use the community and you’ll quickly find more than enough.  In fact, the problem is usually narrowing down the list of candidates rather than trying to find a match for your use case.  If you need help making a decision, look at things like project longevity, number of committers, frequency of updates, project structure, the license used, the number of open support tickets, and other such factors.  OpenLogic does this as part of our certification process, which we also use to determine which packages we’ll support with commercial SLA’s.  (About 650 packages have made it onto our supported list so far.)    

How Often to Look for New Open Source  

Far from being static, the world of open source changes daily.  New projects come on-line, established ones gain critical mass, and unused ones fade into obsolescence.  In fact, this entire lifecycle can play out over the course of a year in highly competitive areas of cutting edge exploration.  More stable categories such as web servers see far less churn.  The Apache HTTP Server, for example, has enjoyed supremacy for over a decade, even though competitors like Nginx have gained significant traction over the last few years.  

As a rule of thumb, you should re-evaluate your open source-based technology stack every time you start a new project and at least annually for existing projects still undergoing substantial development.  If your software relies on rapidly evolving software, such as a NoSQL data store, taking a look around every six months would be beneficial.  And, of course, you’ll want to check as frequently as possible for critical security patches and other bug fixes.  Finally, you need to examine every new release you download, even minor bug fix releases, to ensure that project licensing hasn’t changed.  Over the last decade, OpenLogic has seen a number of major projects change significant licensing terms from one minor/bug fix release to the next.  We check for security problems, bug fixes, and legal issues every day and sends out results via our OpenUpdate email service.    

Conclusion  

It’s easy to tell when it’s time to look for a new open source project because your current one is slowly riding off into the sunset; the hard part is finding the time to look for the signs.  It’s also easy to find suitable replacements; the hard part is making sure your new project won’t go obsolete on you as fast as the last one did.  Finally, it’s easy to say you’re going to prioritize these tasks to make sure you’re up to date in every area that’s important to you; the hard part is actually doing it.  

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
.