The OPNFV project is strongly discouraging forking of its open source code, but that stance requires educating the telcos, which are relative newbies to open source and, according to some, don’t understand the pitfalls.

The term “forking” refers to the practice of working on programming problems that aren’t directly related to the main upstream coding project.

“There’s constant pressure to create something that is unique to OPNFV to satisfy, in the short term, carrier-specific requirements,” says Chris Wright, chief technologist with Red Hat and a participant in OPNFV. “We created an upstream-first culture from the very beginning.”

While Wright says there are three different kinds of forking, with two of them being fairly benign, temporary coding tangents, he lays out a strong case for the evils of forking “that is done outside of the upstream tree with no real credible plan for how you’re going to get those changes merged.”

“One concern is: You’re not actually participating in the upstream community,” he says. “As a downstream developer, your code isn’t benefiting from any of the eyes or expertise of the community. You’re creating something that could be incompatible with the upstream.”

He adds that code that comes from forking is “functionally equivalent to something proprietary,” and until it’s merged with the upstream trunk, “it’s not stable.” Also, if coders have done a lot of downstream work, the open source community has a harder task of validating that code than if it had been involved all along. And some hidden assumptions are potentially lost because they’re all wrapped together in a separate project.

All of Wright’s arguments are compelling, but there’s another camp of open source coders who feel that opposition to forking creates a backlash. Jacob Loveless, CEO of Lucera, a company that runs a network for financial services, participated on a panel at the recent OPNFV Summit. He is not opposed to forking, and he cites a YouTube video of Bryan Cantrill of Joyent who coined the term “forkaphobia.”

Cantrill says when he was at Sun, the company was “petrified” of forking. But it learned that trying to suppress forking actually caused more of it. When it said, “everyone can fork whenever they want,” people didn’t fork. “You really want to encourage forking,” he says.

“The illumOS operating system (formerly Sun's OpenSolaris), encourages forks, and it has extremely healthy downstream repositories and a vibrant return to upstream,” says Loveless.

But perhaps the OPNFV community is different, because it includes developers from telcos, and its goal is to create a “carrier-grade” open source platform to accelerate network functions virtualization (NFV). With all the focus on satisfying telco’s needs, it’s not surprising the telco participants would want to address specific network problems.

Wright says one reason community participants want to fork is because they “are responding to a set of commercial pressures, and they believe that going through the upstream is too slow and they won’t be able to converge on a solution to meet their commercial pressures.”

At the OPNFV Summit, Prodip Sen, the CTO of NFV at HP and chair of the OPNFV board of directors, said, “We shouldn’t be spending a whole lot of time on designing features. If someone has an idea about bringing a set of features in, good luck to them if they can get a number of people to work on the code.”

Wright says operators bring a lot of valuable knowledge about their networks to the upstream coding community. “It’s that early engagement that helps shape the project. If you just solve your boss’ problem today and then go away, that’s a way to lose all credibility.”