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.
Here are some ways to tell if your package is getting stale or is completely obsolete:
The bug fix train has stopped
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.
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.)
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.
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.
Allowed tags: <a> link, <b> bold, <i> italics
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.