It’s wonderful that we have many open source software choices. It’s not so easy to know which one to pick. And, as with any product or technology that outlives its usefulness, it’s hard to know when to seek a replacement.

Sometimes, the path is obvious: The program doesn’t live up to its promises or its technical architecture doesn’t fit into your corporate IT environment. But other times, the decision criteria are less clear.

The first issue is when to make a change and consider replacements. For most, the time to question the project is when the existing software is a constant source of trouble or the project appears to be in difficulties. If you wait until the program fails or the project collapses, you won’t have the time to make an educated decision on its replacement.

Here’s how to tell when it’s time to stay the course with an application and when it’s time to cut and run.

Case in point: SDI and SDN

Some fields are based almost entirely on open source software. That’s a plus, because it suggests that you can find one that meets your needs. But it’s also a frustration, because it means you have to make difficult choices.

To highlight the issues, let’s consider one hot networking field. At the Open Infrastructure Summit, Ian Wells, a Cisco distinguished engineer, pointed out the broad range of open source software-defined infrastructure (SDI)and software-defined network (SDN) programs, identifying more than a dozen of them. The list includes Central Office Re-architected as a Datacenter, Open Network Automation Platform, OpenSwitch Network Operating System, Open vSwitch—and on and on they go. Complicating matters, some projects cover much of the same ground, such as the SDN programs Tungsten Fabric (formerly OpenContrail), OpenDaylight, and Trellis. Even SDN experts can be confused by so many projects.

So the first problem is that, while SDI’s end goal is to make life easier for tech management, an IT team first has to evaluate many confusing and complicated projects before making an informed decision. Doing your homework takes time. You also need to consider who is supporting the project. If you are building from scratch, there is one set of concerns; if you need to support an existing hardware infrastructure, there is another.

Often, numerous projects all claim to solve the same problem, but they all have a different approach. You need to check each of them (including examining the source code) to see which one matches your needs.

What is a useful project? Rather than get bogged down in technical details, ask these simple questions:

• Does it help me?
• Does it do what I need?
• Does it work?
• If not, how sure am I that it will work one day? Can I make it better? Can I fix it?

If your answers are yes, then devote resources to it. If not, look for another project that meets your needs.

But with open source, there’s more to it than finding the best technology fit for your company.

Well says you must ask yourself, “Which of these are useful? Which ones do you want to use? Can you deploy them? Have other people deployed them? Heck, have the people working on these projects deployed them? Do they have use cases? Or, is it just a thin veneer? Is this someone’s [personal] project created with an ulterior motive?”

In short, it’s not enough to look at a project. You need to look at how the software is used in the real world.

The open source lifecycle

One way to compare the options is to look at a project’s state in the hype cycle. Wells and Kyle Mestery, also a Cisco distinguished engineer, put together their take on Gartner’s Hype Cycle methodology in the context of open source networking development (see figure). Following along may help you to know when to jump on a project, when to surf its success, and when to abandon it.

The Open Source Networking Hype Cycle. Credit: Ian Wells and Kyle Mestery, Cisco distinguished engineers

When an open source project starts, it may get a lot of buzz. You may be so energized by what you read that you rush into work proclaiming that XBANG is exactly what you need to work on, because when the project matures, it will be the answer to your problems (at least your problems related to SDI, application development, etc.).

Not so fast, kids. As Mestery says, “Peak excitement can be very peaky, and it does not guarantee overall success.”

So, be careful of hot, new projects. They may cool down before they become useful.

Initial excitement inevitably wanes, says Mestery. That doesn’t mean the project will fail or won’t fit your needs. But the software will go through a period of disaffection, as shown in the figure above. It always does. That’s fine.

Affection for the disaffected

After the excitement, people move on to other newer, more exciting projects, Mestery says. But if a project delivers the goods, it continues to develop, starts appearing in beta tests, and eventually moves to production.

Pay attention to what happens to a project when it is in the “feed box of disaffection” stage. Are people still working on the project? If they are, Mestery says, “don’t worry, it’s OK. This is where concrete work gets done when interest drops off.”

It’s in these so-called disaffected projects that you can sometimes find the most useful code. Look closely. Does the project still have active developers? Does it answer your needs? Is the software moving into production? If so, it’s time for you and your developers to get on the bandwagon—or build a new wagon to climb on.

What matters, Wells says, is whether the project solves problems and whether it has technical and business value. If it does, it will recover from the disaffection phase and find its way to the “mesa of assimilation” stage. “This is where a technology just becomes an accepted part of the landscape,” Mestery explains.

You could think of an open source project as being assimilated into an IT landscape when you no longer need to sell anyone else on its use. Beyond assimilation is commoditization, where you look for something else to build on top, Mestery says. At that point in the software lifecycle, “you don’t realize that you’re using a technology, but you’re still using it,” he says. One easy example: Secure Socket Layer (SSL).

When things go wrong

Not all projects become as accepted and ordinary as SSL.

Some projects fail. Indeed, most open source projects fail. Several years ago, then RedMonk analyst Donnie Berkholz reported that more than 98 percent of all GitHub projects saw no development after their first year.

Sometimes, even major open source projects lose their way. Perhaps the best known of these is CyanogenMod, an Android-based mobile operating system. It became very popular and earned more than 10 million users. But, while its code was good—indeed, it lives on as LineageOS—CyanogenMod’s founder fumbled its commercialization and the main program disappeared.

Another example is OpenOffice, a once well-known program that was abandoned by Oracle. Programmers kept turning in improvements, such as adding Microsoft OpenXML format compatibility, but the remaining code committers ignored these changes. So the active programmers ended up forking the code into today’s very successful LibreOffice.

The moral here is that poor management can kill good software. But, with open source, good projects need not die. If code is useful, it will be used.

For the most part, open source projects fail for all the reasons other computing projects fail. In a 2017 study examining GitHub projects that had been abandoned, the authors found, “Modern open source projects fail due to reasons related to project characteristics (41 projects; e.g., low maintainability), followed by reasons related to the project team (39 projects; e.g., lack of time or interest of the main contributor) and environment reasons (30 projects; e.g., project was usurped by a competitor or legal issues).”

According to Mestery and Wells, the reasons projects end up on the scrap heap include:

• The project has run its course and is no longer useful.
• It picked the wrong problem to solve or the problem changed.
• Developers left the project and moved on to new “hotness,” so there is no longer a community to help add value.

The first two scenarios happen more often than you might think. Wells says, “For whatever reason, the problem with it is well-defined or apps, or perhaps the problem is no longer valid. For example, you know how to use a 10 megabit link in a data center; any further work on optimizing this has passed, and it’s time to start something new.”

You can tell which projects may fail, Mestery and Wells say, by looking for the following problems:

• Does the project lack a diverse community?
• How many active committers does it have? If it’s only a few, what happens when those people get bored?
• Does the committee gate-keep all commits or demand special intellectual property rights? Does the community fail to value individual or corporate contributions?
• Does the project use continuous testing?

The experts mean more than one thing by “a diverse community.” By their definition, the project participants aren’t tied to one gender or race, as you’d expect. They also mean the project has developers from more than one company; when a program is tied to a single business, its viability is questionable.

Projects also should have welcoming cultures. The more insular a project, the greater the chance it will fail.

One way to learn this from outside: Successful projects have a code of conduct. Programs are made by people, not code-producing machines. Every project has its bad actors who are ready to poison projects. Without a code of conduct, projects must cope with personal problems on the fly, an effort that often fails miserably.

While a few projects can succeed based on a management model of a benevolent dictator for life, such as Linuxand Python, they’re the exception and not the rule.

The intellectual property issue is critical. It’s especially troublesome as some “open source” projects, such as Confluent, Elastic MongoDB, and Redis are moving to cloud-unfriendly open core licensing models. MariaDB CEO Michael Howard calls this approach “strip-mining open source.”

“No one wants to think about software licensing issues, but you have to look at the licensing aspects,” says Wells. As you evaluate a project, pay attention to who gets which rights.

“If you don’t have anybody asking questions, if nobody’s making contributions, if there doesn’t seem to be any new adoptions, nobody seems to be adding dependencies, and if you’re not seeing any other signs the people are using it, that’s a potential big warning sign,” says David A. Wheeler, lead for two projects with the Linux Foundation’s Core Infrastructure Initiative. “It may all be fine, but it’s worth checking to see if the project is dying.”

Finally, the fundamental question is whether the project is going where you need it to go. If it doesn’t fulfill your requirements, because of project drift or another other reason, you need to be ready to cut your losses and find a better approach.

When a project is on the trash pile

Some projects no longer have any life to them. Maybe there’s something useful still in the code, but the project itself is dead.

“Even highly successful open source projects may eventually stop being useful to their creators or users as business plans change or new technologies and innovations replace them,” says Wheeler.

How do you know? The Linux Foundation sums it up: A dead or dying project has problems, including:

• Unresolved differences about the direction of development and lost energy from formerly involved contributors.
• A decline in the project that coincides with members of your team, or the community asking questions about whether it should continue, be ended, or be left outright.
• The code is no longer patched or updated by the community to resolve acknowledged problems or security vulnerabilities.
• Users are no longer requesting patches and maintenance updates.

What if the code is important for your company? Consider forking it yourself. This worked for the LibreOffice developers. It can work for you.

If you have the time for code archaeology—and the project looks like it’s the answer to your prayers—go ahead and dig in. Just don’t count on it working for you without a lot of effort.

When a project really is done

After considering all these aspects, you should be ready to find projects that work for you. Be wary of too much enthusiasm for the hottest of projects. Look for programs with the right virtues and few, if any, vices. If you do that, you can find the open source programs you need for your company’s success.

When to jump on—and off—an open source project: Lessons for leaders

• Be wary of hot, new projects.
• Give extra credit to diverse open source communities.
• Open source projects can display danger signs. Look for them.